Should I give an interview candidate a second chance if they failed to demonstrate their programming ability?

Question

Would you give a potential programmer a 2nd chance in an interview if the face to face interview went really well, great communication skills, great cultural fit for the team and general chemistry was good.

The candidate doesn't have a formal background (education wise) rather they have been taught on the job, but your gut feel is that they have a real raw talent that you can work with (I enjoy the mentoring).

The problem is, when I gave them our programming problem (which isn't particularly difficult) their solution failed some of the test cases, these weren't edge cases but core to the algorithm. I don't want to state the problem, as its rather lengthy.

I believe you could argue nerves, or the fact that as they have been taught on the job, they may have just not had the right teachers.

Should I let them try again?

[Edited] If anyone was interested, I ended up hiring them and it was a good decision!

Answer 1

Well, if you think that person has the raw talent and all of those others things you mentioned, then sure. I don't think simply failing to solve an interview question means you should not hire that person. Unless the question was just elementary and ridiculously easy. Otherwise, I think dismissing somone out of hand like that might increase one's Pointy-Haired-Boss factor by 10, to say that least.

Answer 2

It sounds like you like the person which is important. If you feel yourself to be a good judge of technical ability then why not? Those things are definitely extremely important.

As far as us judging whether or not the person should get a second chance.. you haven't provided us with enough details.

You didn't state the problem so it is hard to judge whether or not a candidate who failed it should be considered. You also haven't stated what cases his problem failed in. Were they obscure edge cases or were they core to the problem? Other than missing some cases, was the code quality sound?

If you want our opinion though, you provided too little of the right information for us to make a judgment.

Answer 3

Absolutely! Communication skills, cultural fit and raw ability is far more important. If someone has previously learned "on the job" they may have gaps in their knowledge. However, provided they can clearly demonstrate that they are able to successfully pick up new concepts and complete tasks, that's easy to work around.

Conversely, if they have the technical knowledge but don't fit in with the team or have appropriate communication skills, it will be an uphill battle in perpetuity. At least if someone is simply uneducated in a particular area you can provide training/mentoring to get past the sticking point.

Answer 4

Skills can be taught/learned/enhanced.

Personality/soft-skills/"fit" are either there or not there.

Rather than giving the person a standard test have them stand at a whiteboard and walk through their thought process. Listen to them and find out where they stumbled... perhaps the conclusion that was reached wasn't really too far out of step with how they interpretted your question.

Answer 5

I think the real key is that you would enjoy the mentoring aspect. Even if their skills are currently lacking, if you think they are teachable and a good fit and are willing to help them come up to speed technically (if needed), then by all means give them a chance. If you won't have time or the willingness and they aren't where they need to be technically, it won't do anyone any good to hire them and I think you may want a second technical interview to see if it was just nerves or there is a real lack of ability.

Answer 6

Maybe he has a skill to make a good impression but has no technical skills to do the job.

Answer 7

I would tutor them through the problem (as in pair programming), and then see if they can apply the concepts to another similar question (with the first to compare with, maybe). Can they can feed back what you thought you'd taught them?

If not either they're not as quick as you suspect, or your tutoring skills aren't maybe sufficient. But that's the pattern you're betting on.

If you try this, it would be interesting to hear back how it went.

Is it significant that you seem to be evading gender identification?

Answer 8

Agree it depends on the question. How easy/hard it was? How bad did he fail?

If the programming problem was to know some API letter by letter. If is reasonable to fail. That's the documentation for.

It is better to know if the candidate can think for him self and see the way it uses to solve problems.

At some point of my history, we use to evaluate candidates by playing Pente

The technology to be used was very new, and none know anything about it, so, none can pass the programming test

So we evaluate the problem solving capacity.

• Almost none knows the rules or the game for that matter.
• We gave him the directions. He must pay attention.
• We give him some basic strategies and then we play.

If the candidate didn't ask when he had question... errh bad signal.

If the candidate could't get the most basic directions... errr bad signal.

It turns out most of the developers that were using this method were very proficient.

Answer 9

It would depend on how long they've been on the job and how fundamental their error. Try and find out how much they've progressed in that time.

Answer 10

I consider pairing/coding with the person the most important part of the interview. If the person isn't able to write code that solves business programs, he isn't a programmer. Being able to work on the team comes next.

Answer 11

I guess it depends on how badly they did on the test. If they bombed it and you're still wanting to keep them, then why give the test at all?

I know that people are going to make mistakes, and I'll cut people some level of slack here, but judgment is important. If the candidate makes a dumb off-by-1 index error, I'm not going to sweat something like that. If the candidate says that he makes all his methods public to promote code reuse, that's a fatal mistake.

I like what Joel Spolsky has to say on the topic. You want the candidate to blow you away. If it's a "maybe", automatically translate that to "no" and move on. It's far better to turn away somebody good than to hire somebody bad. Going through the HR process with people is no fun at all.

Answer 12

Any number of coaches & writers in the industry have written on this point, and the one theme that recurs constantly is this: You cannot automate the detection of excellence. If you stop listening to your own sense of a candidate then you may as well stop hiring because you're going to start having problems immediately thereafter.

Answer 13

I think the self taught part is moot to bring up. Most of the junk I learned in school dripped out as I left the building. Most of the learning is on the job.. "how to learn c++ in ten years" springs to mind.

Being able to talk to the guy is crutial. Being able to express requirements and get back intelligent questions is crutial. I have a coworker with a dreadful accent. My boss can hardly undrestand a word from her. It makes meetings longer and much less productive. Things are done wrong and issues always come up because of misscommunication. Soft skills are very important.

Nerves:
I (after 5 c++ years) was asked the difference between a class and an object. I coudn't for the life of me figure out the answer. That is until I sat in my car. Nervs mess up ones thought process.

Invite him back for a second interview.. But don't give him quizes. I've yet to see one that's really good at judging skill.

Answer 14

I would give him a second chance.