Having been on the other side, hiring is really hard, and it's usually worse to have a bad developer in place than it is to have no developer. So the smart thin

Having been on the other side, hiring is really hard, and it's usually worse to have a bad developer in place than it is to have no developer. So the smart thing to do in most situations is err on the side of not hiring in marginal cases. > I did well enough in my honest opinion At a previous employer, I helped design the developer hiring process. The first step in the process was to ask candidates to pass a "do you even know C?" test. Simple stuff like writing a little string handling program from scratch and identifying coding errors in an existing file. It wasn't a lot of candidates, but a significant minority would actually argue with us when they failed these super basic tests, even after we pointed out their errors. I'm definitely not saying you are doing this, but it was not at all uncommon to have applicants that way overestimated their own skill. Hiring is just hard, from both sides. There's a lot on the line for all involved, and a wrong decision, in either direction, is costly for everyone.