Several years ago, there was a candidate who interviewed for a position on my team.
I and another colleague were the “discuss system design stuff for an hour” team. It became clearer as we spoke that the candidate knew barely a fraction of what they claimed, and pointedly flailed with absolute nonsense answers even when my colleague or I tried to throw them a line to get back on track - like, it was clear they had no idea what the concepts being discussed were. Moreover, after some pointed questioning, the candidate admitted that the systems she said she had built at a previous job were, in fact, largely set up by someone else, and that she had just made some changes after everything was initially set up. A few more pointed questions uncovered a handful of additional blatant misrepresentations, at which point we called that portion of the interview done.
As a result of these discoveries, I submitted written feedback for the candidate. We use a 1-5 rubric - “definitely not” through “holy fuck throw money at this person”, more or less. I gave the candidate a 0, and specified that we had caught them lying about significant aspects of their experience and knowledge, that the candidate essentially admitted as much when we presented them with the obvious incongruencies, and that that level of disingenuous behavior is at odds with not only our technical standards, but ethical ones as well.
Later, we all met to compare notes. Another dev pair evaluated the “take-home project” (which I took when I applied - it’s not that hard) and called it “perfect”. The thing is, we prescribe that you should be able to complete the exercise in a couple hours, and absolutely shouldn’t spend more than like 4-5 on it… but we don’t really track the time taken to do the thing. I am 100% confident that the candidate worked for DAYS on that fucker. Anyways: the chat with the manager, and the “culture fit” meeting apparently went well for them, and because the takehome exercise result was “excellent”, those engineers thought that the candidate would probably be great at cranking out tickets. I objected strongly and consistently in the clearest terms possible that we’d be setting ourselves up for failure by bringing this person in, and diminishing the overall effectiveness of the team.
My concerns were overruled. The candidate has been on my team since then, to my intense frustration. They have an apparent inability to understand normal git workflows, and insist on using a GUI that has created issues multiple times for the rest of the team. They are the specific reason why we tightened down all of our internal git project permissions from “you’re all devs, you know what you’re doing” to a minimal set of perms tightly scoped to our GitHub workflows. I have wasted weeks of development time un-fucking shit that this dev has broken. They are, by an order of magnitude, the most pain-in-the-ass member of the team, to the extent that even our manager has effectively siloed them off from the rest of us by mostly pointing this dev at peripheral busy tasks so that they don’t touch code that actually matters.
Before you ask: the person in question is a member of four protected categories, so they’re effectively un-fireable. I also found out about a year after the hire that they only even got the position they did because they needed visa sponsorship, and that title was the lowest level that corporate would do that for.
TL;DR: tests/project evals are absolute useful tools that can and often should contribute to a technical hiring decision. But they should NEVER be used as a basis for overriding conclusions reached from actual discussions, unless the technical challenge was executed in a fully-controlled environment (which I have done, and it was actually a much more pleasant process than I was worried it would be).
Edit: realizing that that was a bit of a rant, sorry. Guess I just needed to bitch for a moment about the deeply incompetent person at my work who consistently makes my job harder every time I have to interact with them.
I feel your pain. I once worked at a place that hired an “expert” as a senior dev who asked me on the first day, “what is this import on the first line of this code??? I’ve never seen this before. 🤔” They were unfamiliar with the concept of packages and importing them… Senior dev, hired specifically because they were an expert in a specific language…
They’d call me upwards of 12 times a day for help with the most basic of tasks with anything technical, to include how to install the basic runtime to be able to run code in that language.
For me that’s the biggest mistake your company is making.
I’m all for giving someone an opportunity if you think they might be good, and I’d be cautious accepting an individual’s rejection, no matter how strong, since they could be wrong for any number of reasons… however you have to be able to fire someone especially early on in their employment.
If you’ve sponsored their visa, then (at least in my country) there are still ways to fire them. You just need to help them find a new more appropriate job - maybe even one inside the current company.
If someone is capable of “completing” a task by paying someone else to do it… then perhaps they have potential as a manager for example. Delegating tasks to other people is a real skill - and apparently an area your company is lacking (the most important ability is knowing who to give your task to… and they put this guy on your team! Wtf). Obviously don’t start as a manager but maybe put them on that career track. Make him an assistant to a manager for example.
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.
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.
Several years ago, there was a candidate who interviewed for a position on my team.
I and another colleague were the “discuss system design stuff for an hour” team. It became clearer as we spoke that the candidate knew barely a fraction of what they claimed, and pointedly flailed with absolute nonsense answers even when my colleague or I tried to throw them a line to get back on track - like, it was clear they had no idea what the concepts being discussed were. Moreover, after some pointed questioning, the candidate admitted that the systems she said she had built at a previous job were, in fact, largely set up by someone else, and that she had just made some changes after everything was initially set up. A few more pointed questions uncovered a handful of additional blatant misrepresentations, at which point we called that portion of the interview done.
As a result of these discoveries, I submitted written feedback for the candidate. We use a 1-5 rubric - “definitely not” through “holy fuck throw money at this person”, more or less. I gave the candidate a 0, and specified that we had caught them lying about significant aspects of their experience and knowledge, that the candidate essentially admitted as much when we presented them with the obvious incongruencies, and that that level of disingenuous behavior is at odds with not only our technical standards, but ethical ones as well.
Later, we all met to compare notes. Another dev pair evaluated the “take-home project” (which I took when I applied - it’s not that hard) and called it “perfect”. The thing is, we prescribe that you should be able to complete the exercise in a couple hours, and absolutely shouldn’t spend more than like 4-5 on it… but we don’t really track the time taken to do the thing. I am 100% confident that the candidate worked for DAYS on that fucker. Anyways: the chat with the manager, and the “culture fit” meeting apparently went well for them, and because the takehome exercise result was “excellent”, those engineers thought that the candidate would probably be great at cranking out tickets. I objected strongly and consistently in the clearest terms possible that we’d be setting ourselves up for failure by bringing this person in, and diminishing the overall effectiveness of the team.
My concerns were overruled. The candidate has been on my team since then, to my intense frustration. They have an apparent inability to understand normal git workflows, and insist on using a GUI that has created issues multiple times for the rest of the team. They are the specific reason why we tightened down all of our internal git project permissions from “you’re all devs, you know what you’re doing” to a minimal set of perms tightly scoped to our GitHub workflows. I have wasted weeks of development time un-fucking shit that this dev has broken. They are, by an order of magnitude, the most pain-in-the-ass member of the team, to the extent that even our manager has effectively siloed them off from the rest of us by mostly pointing this dev at peripheral busy tasks so that they don’t touch code that actually matters.
Before you ask: the person in question is a member of four protected categories, so they’re effectively un-fireable. I also found out about a year after the hire that they only even got the position they did because they needed visa sponsorship, and that title was the lowest level that corporate would do that for.
TL;DR: tests/project evals are absolute useful tools that can and often should contribute to a technical hiring decision. But they should NEVER be used as a basis for overriding conclusions reached from actual discussions, unless the technical challenge was executed in a fully-controlled environment (which I have done, and it was actually a much more pleasant process than I was worried it would be).
Edit: realizing that that was a bit of a rant, sorry. Guess I just needed to bitch for a moment about the deeply incompetent person at my work who consistently makes my job harder every time I have to interact with them.
I feel your pain. I once worked at a place that hired an “expert” as a senior dev who asked me on the first day, “what is this
importon the first line of this code??? I’ve never seen this before. 🤔” They were unfamiliar with the concept of packages and importing them… Senior dev, hired specifically because they were an expert in a specific language…They’d call me upwards of 12 times a day for help with the most basic of tasks with anything technical, to include how to install the basic runtime to be able to run code in that language.
(I’m speaking quasi cryptically on purpose.)
For me that’s the biggest mistake your company is making.
I’m all for giving someone an opportunity if you think they might be good, and I’d be cautious accepting an individual’s rejection, no matter how strong, since they could be wrong for any number of reasons… however you have to be able to fire someone especially early on in their employment.
If you’ve sponsored their visa, then (at least in my country) there are still ways to fire them. You just need to help them find a new more appropriate job - maybe even one inside the current company.
If someone is capable of “completing” a task by paying someone else to do it… then perhaps they have potential as a manager for example. Delegating tasks to other people is a real skill - and apparently an area your company is lacking (the most important ability is knowing who to give your task to… and they put this guy on your team! Wtf). Obviously don’t start as a manager but maybe put them on that career track. Make him an assistant to a manager for example.
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:
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.
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.