Fog Creek Software
Discussion Board

how many people to interview

For the people who have experience interviewing programmers, how many do you generally interview for one position? and if you have a coding test how much priority do you give to it in the hiring decision?

Thursday, February 27, 2003

You want a few people with various goals.  Bonus points if you can have the earlier interviewers give the later interviewers tips on what to double-check in the later interview.

Coding problems also reveal personality, perserverence, and style.  Don't treat them as a cut-and-dried sort of thing.  But they should be at the same level as any other interview section.

flamebait sr.
Thursday, February 27, 2003

If you know how to filter a resume, AND you know what you are looking for, you soould be able to do it in 3. 

People who interview 20 people are idiots who should be fired.

Thursday, February 27, 2003

"People who interview 20 people are idiots who should be fired."

My, my, people management not your cup o' tea then?

Say after me, "People who interview 20 people need more guidance."

There, not even that difficult, is it?

Practical Geezer
Friday, February 28, 2003


sometimes candidates cannot support their own resumes in an interview. I found that especially at the junior/intermediate level. 2 -3 years ago, it would take me about 100 - 300 resumes and about 5-10 interviews to find the right person.

If the first interviewee was really good and we had nothing schedulled for next day the candidate would get an offer by the end of the day. Else we would send him an offer by the end of next day.

Secondly, the number of interviews depends on the head hunters the company uses. We used about 3-5 agents at time but for about 2 years we had one agent that basically brought 8 people in in 8 interviews. She did an excellent job.

Also, a small company cannot afford bad people. It really needs people that can solve problems not create some instead. The end result was we were a good team of nice people and we had lots of fun working together.

Opposite, large companies can afford larger people turnaround so they would hire anybody who went through a decent interview.


Friday, February 28, 2003

"People who interview 20 people are idiots who should be fired."

Done much hiring in the last 2 years? You'd be absolutely amazed at the number of people who exagerate -- no -- who downright, flat out, no shame, LIE on their resumes. In this job market *everybody* is inflating both their skill sets and their experience. Most of the time you can't tell that from a resume. A resume can say anything the author wants it to say, and you'll be none the wiser until you actually speak with the person.

I'd say we average between 15 and 20 "interviews" before we actually make a decision. Most of those are short phone based interviews that we use as a "bozo-filter" to filter out the above mentioned liars. On average probably 4 to 6 actually get called in for a real interview, after they've passed the "bozo-filter".

If you can pick three resumes from a pile of 400 (which is typical these days) and even *one* turns out to be worth anything, then I'd say you need to switch to corporate HR or recruiting -- you'll make a fortune.

Anonymous Coward
Friday, February 28, 2003

If you are actually interviewing face to face how to tell if the person is a bozo or lier? Have them right code?

Friday, February 28, 2003

Interview until you've found the right person for the job, whether that takes one interview or a hundred.

(At least, that's been my experience.)

Brent P. Newhall
Friday, February 28, 2003

You can't keep looking for the perfect candidate. He might never show up and in the mean time your project is accumulating delays. Keep the search phase short but very intensive. Interview as many as you can afford. Go with the best candidate in the crop.

Just me (Sir to you)
Friday, February 28, 2003

" Interview as many as you can afford. Go with the best candidate in the crop"

This sounds a lot like the "we don't have time to do a design" argument. As they say, "if you don't have time to do it right, when will you have time to do it again?"

Which does more damage? A delay in hiring the right person or hiring the wrong person and then watching them drag the entire team down?

If you're looking to hire someone long term to be a part of a solid team then take the time to find the right person. Period.

And Bella...oh's not even worth it.

Go Linux Go!
Friday, February 28, 2003

The best practice I have used for hiring is:

1: post job
2: wait a week while resumes come in
3: identify people you're interested in and email a short non-technical questionnaire.
4: Pick 10-15 candidates from the responses, and technically vet them (usually a 10-30 min interview in person or on phone).
5: Interview about 4 individuals in detail

Patrick Escarcega
Friday, February 28, 2003

Many of us on the other side of the interview process have had our time wasted and our persons abused and insulted by prima donnas creating an image of a "L33T" team too good for any human candidate, so they have cattle calls of candidates where nobody measures up and there is a sequence of uselessly graduated multiple interviews. What is called 'selectivity' often appears to be nothing more than an ego trip for the interviewers.  Sometimes, interviewing as a candidate feels a lot like a frat hazing.

The point is, there is a lot of merit in what Bella is saying. When I see companies interviewing a score of people I think that they basically don't know what they want.  And remember, it's not a beauty contest. The candidate as much has to judge your operation as you have to judge whether they're for real. It's possible that a company brings in a candidate that is highly experienced, productive and serious, and expects a modicum of respect, but is treated like a pledge to "Delta House" during the interview. The compatibility has to be mutual, and there's a lot of people on the street that are "slumming" with companies that they really are better than, in order to make ends meet. FWIW.

Use the phone to screen people. The people you physically bring in should practically be hireable on the spot but just need a more intensive verification of their personality and fit to the environment.

Bored Bystander
Friday, February 28, 2003

> Use the phone to screen people.

I agree. As a job seeker, I would sometimes request this as a 1st interview to save time and effort.  Nothing to lose, if they liked you, and you liked them, THEN you could come in. 
As a hiring mgr, however, phone interview doesn't save you anything, b/c they're the ones coming to you.  I guess you can do some interviewing off hours, OTOH.

Friday, February 28, 2003

Resumes that sport the "movie rental app" bullshit are still as transparent as ever.  If you have resume filtering skills, you should be able to see thru most lies, or at least, know if the guy is what you want.  (Experience in the same industry, etc.)  If you are inviting people in who turn out to be liars, you are not reading B/W THE LINES. 

For your typical mid-level coder, I can practically say "hire this guy site unseen" and it will work out.  Of course, it may take 100 resumes before I come across one that is such a clear fit.  but the point is, you should be able to see a dead-in fit a mile away, and only being those in.

Friday, February 28, 2003

In my experience, any cost overruns experience while waiting for the right person are more than worthwhile, compared to just hiring somebody who isn't best for the job.

OTOH, I'm not sure what I think about hiring people for a specific job anyway.  I'd rather have a team of great people who don't exactly fit specific perceived "needs" than a bunch of decent employees who match a job description perfectly.

Brent P. Newhall
Saturday, March 1, 2003

a. Make sure your job and interview requirements are crystal clear.
b. Have a programming test where the candidate actually sits down and writes code to solve 1 or 2 language-agnostic, CS 101/102 problems (like manipulating bytes, lists etc). Pick problems that have more than one solution including an easy brain dead inefficient solution. have a couple of your engineers take the test. It should be doable in 25-30 minutes by your best guy. Give the candidate 1 hour to 1:15 hours. Let them do it alone.
c. Tell the candidate to solve it first, then optimize or clean it up after. Some will ignore you and try for beauty first. That's indicative of unable to follow instructions/goals.
d. If your candidate can't pass the test, and I mean PASS the test, not almost get it, not still fixing his off by one index errors, then you're pretty much done. If you come back in and they're almost done fixing an index error or whatever, sit with them 5-15 minutes and watch them fix it. You'll likely be amazed at the ineptitude vs. resume bloat ratios out there.
e. See (d). This is an interview for a programmer. You'll have people in with fat resumes and great talking/interviewing skills, but find out they can't code. You'll grit your teeth letting seemingly great candidates go, but if they can't code up a CS101/102 problem that's all you need to know. Because when you do have a candidate in who nails your code test in 30-45 minutes, you'll know you have the real thing. I can't stress this enough. You will have people from the best schools with 5 years, 8 years+ programming on their resume who can't move bytes around an array in a nested loop. Let 'em go.

Explicit Coward
Wednesday, March 12, 2003

*  Recent Topics

*  Fog Creek Home