| > But.. why? Does that reflect anything close to the job they would be doing? Yes? Yes. Figuring out how to make a computer solve problems is very much the job of a software developer. They will only encounter harder and less well defined tasks in their actual job. If they can’t do this and you hire them that is like hiring an opera singer who is mute, or a baker who is deadly alergic to flour. > putting them on the spot in an already tense situation and expecting them to code while you watch There are mitigating factors one can do. We make sure our hiring managers let the candidates know that there will be a coding challenge. We ask the candidates if they prefer to chat while they work through the task or prefer to be left alone and we acomodate what they choose. We let them know that whatever style they prefer it won’t change anything. > meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method That sounds very unpleasant. Sorry to hear that. Interviews are a two way street. You are interviewed and at the same time you are interviewing them. I think you were right in judging them, and you dodged a bulet there. By the sound of it you are a talented, and capable developer. It might be that you can’t imagine it, but there are people who apply for developer jobs, has a really good ability to talk about the job, they seemingly have the right experience, yet somehow they can’t program even super simple tasks. Even after you give them every acommodation immaginable to humankind. If you haven’t seen this yet you won’t believe it. If you have seen it you want a filter against this particular kind of candidate. I’m not saying that this filter goes always well. Every filter ever invented had both false positives and false negatives. We might lose a briliant developer because some quirk of the task throws them. It is sad. We are trying to minimise the chances of this, but it certainly happens. |