What should be a fair amount of time in an interview before rejecting a candidate? [closed]

Question

As a panelist for technical interviews, you often come across candidates who have all the requried educational qualifications, skill sets and experience level on resumes, but struggle to answer even the most basic questions.

Ideally, technical interviews should try to check different aspects of a candidate and test them on various skills. So, if the candidate falters on one aspect, one should test the other ones before coming to a conclusion. But often, if a candidates falters on the first few questions, the red flag rises up pretty quickly.

What in your opinion should be the bare minimum time spent with a candidate before making a fair accessment of his/her skills and suitability for the job?

Answer 1

In my experience, 20 minutes is enough for them to put their foot in their mouth. I've been on both sides of this.

The good thing about dragging it out with a few more questions than you feel are necessary, is that they will know they aren't appropriate for the position.

For example, if you say "implement an example of polymorphism on the white board", and they say "ummm...Polly who?", they won't go away saying "I wasn't hired because I'm [insert race/age/sex/etc here]". They will know they are unqualified.

It also helps them know what their deficiencies are, so they can further their own careers (probably not your goal, but it is a side effect I thought I should mention).

Answer 2

Short answer: 1 hour.

We have a standard 1 hour in-person technical interview (which comes after they've passed two phone screens) that we use to start off the interview day. If they don't pass that, we don't continue with the personality/culture/lunch portions of the interview - there's no point in wasting the interviewee's time or ours if they aren't a technical fit.

Technically speaking, if they can't answer the first question in the tech interview (a very, very simple programming problem on the whiteboard), then the rest of the interview is (probably) pointless. But the hour is scheduled out anyway, so I always have them go through the full set of questions. On very rare occasions, the person will end up recovering from a bad start and do really well on the later questions, and even come back and re-answer the early questions correctly. Those occasions make up for a few lost hours.

Answer 3

Try not to make any final judgements until the end of the interview. They may start off rough but have some great answers at the end.

Obvious exceptions would be if they're stark raving mad or something like that...

---

Update:

I suppose if they obviously disqualify themselves by demonstrating total lack of qualifications with nothing to compensate, that could also be a good time to end the interview. Example:

    interviewer: How long have you worked with .NET?
    candidate: I've actually never worked in .NET.
    interviewer: Um, you realize this is a .NET developer position?
    candidate: Yes.
    interviewer: ...Do you have experience with anything .NET-like?
    candidate: not really, no.
    [goodbyes, etc...]

Answer 4

I know seems redundant, but, What do you mean by "Basic Questions"?

By example, "Write a recursive function example" , "Write a mutual/indirect recursive function example" may be a "Basic Programming Question".

I have been applied both, and failed the 2nd. one, the first time.

It's also happen that you may want a C# programmer, you find a Java programmer, and call him for an interview, and when you do "C# Basic Questions", the candidate may failed.

So you may take in consideration, that skilled people, may fail some "Basic Questions", so it's better to say "How many Basic Questions ?" instead of "How much time applying Basic Questions" ;-)

Answer 5

Have a telephone interview first

This would save everyone a lot of time and it is very easy to ascertain pretty much the same stuff that you'd reject them for in a face-to-face interview.

It is much easier to tell someone over the phone "thanks for your time, bye" when you realize that they're unsuitable compared to having to show them out of the building, sign them out at reception, possibly arrange a taxi and generally hang about in order to be polite.

If your recruitment process consists of shortlisting CVs/resumes and then getting the candidates in for a face-to-face interview first, then it might be time to talk to management about updating procedures.

If, while on the telephone, you need them to talk through code, then email them a code snippet and ask them to explain it or ask them to talk you through some of their own code.

After filtering out by phone, the suitability of the candidates that come in for a face-to-face interview is much higher. I've found that rejections at this stage usually comes down to a deeper issue that would only surface in a face-to-face interview rather than "they can't program".

Answer 6

Try to look at your candidates objectively until the end. What did they answer? What did they have trouble with?

Depending on the position they are applying for, try to keep the 'clever' questions to a minimum. If his job will require him to build reports from a DB (a junior position), don't throw him questions that require advanced knowledge of math.

Sometimes it's about hiring the ones who show passion and willingness to learn.

Answer 7

If they fail fast, give them long enough that you can give them honest and candid feedback on why they failed. In the first 5 minutes, you might know by induction that there is a high probability that they are going to fail all your technical questions. Ask them those questions anyway. When they have missed 2 or 3 questions, you can terminate the interview, by giving them some concrete feedback. Examples:

We are looking for someone with deeper knowledge of data structures and algorithms. It would be worthwhile for you to review [sorting algorithms|dynamic programming|trees]

We are looking for someone with deeper knowledge of [Python|Java|SQL]. The person we will hire will need to understand [List comprehensions|Generics|Different join types]

It seems like you could improve on your [topic] skills. I would recommend [relevant book] if you're interested.

The key here is not wasting their time. Dragging an interview on too long is an obvious wast of time. Cutting it to short is a less obvious waste of their time. They've made the effort of going through your preinterview process (you do phone screens, right) and taken time to meet with you, so you owe them something as a consolation prize if they don't get the job.

Finally, I'll say, be gentle but firm when delivering the bad news. And be prepared for a wide variety of responses.

Answer 8

I think one hour is just about fair enough. Because if you make it too short it feels like a waste of time for both people, I mean sometimes people do have a rough start, but if they are going on in an hour and still doing bad......well then you know it's time.

Answer 9

I was once rejected in an interview in under 10 minutes. The interviewer was candid enough to mention that he did not find me to be a good fit.

In retrospect I thank him for that. The company ultimately hired a Physics grad for the job, I had computer science.

If you are a panelist and you know that what you are looking for isn't in this candidate, be upfront about it in a non-offending way. Dragging on a game where either parties are set to lose is a pretty bad place to be in. You don't need an hour to decide this, but don't rush into a decision either. Checking responses to a few basic questions should be good enough.

It can be much more damaging to a candidate's morale if he or she is rejected after 8 rounds, than after a single one.

Answer 10

Depends upon how the interview process has been structured.

If you are on a phone screen with someone and they are having problems, then maybe just switch over to easier questions or give them one more before wrapping things up and saying you will be in touch. These generally aren't expected to run long so you have the advantage of being able to end it gracefully without anyone feeling like they have been flatly rejected.

If you are conducting face to face interviews things get a bit trickier as you have to make sure your time isn't wasted as well as the candidates since they may report back on their impressions of the interview which might turn off another candidate that you may want. If you have a day long interview scheduled with multiple people, then at the lunch break time could be a good time as it will give some of the interviewers time to touch base and give their early impressions. If the candidate knows ahead of time that you may end things after lunch then they shouldn't take things too hard and if you pay for their lunch it will smooth things over quite a bit.

If you have less then a day worth of interviews lined up (i.e. before lunch or after lunch) then it really depends upon how they are doing during the interviewing process and what positions you have open. If someone is interviewing for a mid-level position but you have a junior position open an they seem like a good over all fit they might still accept a job offer if you tender one in which case it might make sense to continue with the interview but adjust the questions.

If they are doing poorly due to technical issues then Brandon DuRette's answer raises a good point in which you should just be honest and tell them what the short coming is. Most developers will appreciate this as they know where their weaknesses are now and can focus on improving as opposed to just an early end which leaves you wondering what you did wrong. To add to this a bit though, if you are using some sort of white board question, just show them the sort of answer you were looking for or explain it real quick before they go. This is one of those things that some developers will really appreciate so they can see how off target they were during the process.

If they are doing poorly due to personality conflicts then things are going to be a bit tougher as it can cause hard feelings depending upon how it is done and what is said. This is an area where having someone coordinating the whole interview process can help as that person could be responsible for letting the candidate know if they got the thumbs down from someone. Likewise, you might want to talk to someone in human resources for advice here because just saying you don't think the candidate would fit in with the company culture could leave the wrong impression if done the wrong way.

Answer 11

I usually start with a short hands on test (5-10 minutes) writing some simple code, and talk to the candidate a bit more in depth about the projects he was involved in, to see if he can express himself in other ways than writing code. It usually takes between 20 minutes (for unqualified candidates) and an 1-1.5 hours (for good candidates).

I found an almost 1 to 1 correlation between a candidates ability to handle the code writing test, to his ability to express himself later on, so I usually make the decision whether to continue the interview very quickly.