this post was submitted on 20 Dec 2023
137 points (95.4% liked)

Programming

17435 readers
276 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] gravitas_deficiency@sh.itjust.works 8 points 11 months ago* (last edited 11 months ago) (1 children)

It wasn’t an individual’s rejection, though. My colleague who did the screen with me was 100% on the same page, and as far as I know provided a very similar response. We were just overruled because the assessment project we gave came back “good”.

Edit: to be more clear, it’s my pretty firm opinion at this point that the person in question is just straight up not a good engineer. They are:

  • they straight up do not listen. My colleagues and I have started 1) saying a thing 2) confirming comprehension by asking and then 3) confirming comprehension again by asking for a brief, very high level overview of what was just said. This person consistently just… doesn’t respond to step 3. I’m neurodivergent myself. This isn’t that. This is being a fucking idiot.
  • consistently and demonstrably unable to wrap their head around fairly basic git situations. I have tried at least a dozen times to express the importance of maintaining a clean and linear commit history on our working branches. I expect I will have to explain it again sometime soon. Along with how rebasing works. Or how the branch strategy of our projects are set up. Or to ask them, for the 87th time, to please fucking stop using whatever shitty git GUI client they’re using that often creates issues upstream for the rest of the team.
  • often brings up inapplicable or entirely irrelevant points in an attempt to look like they know something about anything
  • I know for a fact that at least one conversation I have had with them - in which I was genuinely trying to just point out some serious pitfalls they were about to run into - which was fundamentally misrepresented to the extent that I got pointed HR questions from my boss about the interaction. I am not the only person on the team they have tried this with.
  • as mentioned in my earlier comment, has repeatedly broken important shit in our stack and CI pipeline, and not only never fixes it, but doesn’t even say a fucking thing about it, even after it’s discovered, and it’s abundantly apparent that they broke the fucking thing. This generally causes a lot more work for myself or one of the other senior members of the team.

I have mentored people before, some very successfully. This person is un-mentorable. They are actively detrimental to our team overall. If I was in a position to do it, I’d immediately put them on a PIP for inability to perform their job as specified in their employment contract.

[–] JavaTheHutt@programming.dev 7 points 11 months ago

This person sounds like a future manager in the making. I've dealt with them in the past. If you're lucky, they'll somehow manage to find a better paying job elsewhere. More likely though is that if you want to get away from them you'll need to find a better paying job elsewhere, or change teams if possible.

To a certain extent, dealing with incompetent/adversarial colleagues can be a learning experience. You get better at designing/coding/communicating in a more idiot-proof fashion. But after a while it starts to hold you back as instead of being able grow, you instead have to stay behind and clean up after the others.