Fog Creek Software
Discussion Board




Determining which resumes to interview

In the Guerrilla Guide to Interviewing ( http://www.joelonsoftware.com/articles/fog0000000073.html ), Joel talks about how to interview candidates to determine whether they are "Smart" and "Get things done." 

My question is, how do you identify which candidates to interview in the first place?

Maybe you're thinking, "Phone screen them first."

But -- how do you determine, from the 2000 resumes on the HR desk, which ones are appropriate to phone screen?

Will
Monday, February 25, 2002

I'm sure you could apply filters of arbitrary complexity, but chances are that you'd be just as successful by simply picking a random percentage of the resumes to phone screen.

A number of firms end up hiring less than 2% of applicants, and even those with "loose" standards and a tight market often end up hiring fewer than 10%.  You could either say that 90-98% of all people in the field aren't capable of doing any given job, or say that employers are randomly choosing 10% of applicants to interview, so 90% of the applicants are never even considered, for reasons that have nothing to do with their ability.  The latter seems more likely.

Hiring personal referrals only seems to be the most successful approach, btw.  Very limiting in a tight market, but this isn't a tight market.

James Montebello
Monday, February 25, 2002

most companies seem to be very specific these days in their reqs.  do all the people actually fit the "3-5 years, Java, Visual J++, C++, Cobol, Perl, blah blah blah...."  in my experience a lot of my friends throw in resumes when they can cover 80% of the requirements, can't you just weed out those that don't have 100%?  or in the future add another req. that isn't always needed-but might indicate that the person is brighter than average?

razib khan
Monday, February 25, 2002

1)  Require emailed plaintext resumés, and set up a special email account to accept them
2)  Use automatic tools like grep to search wanted terms.  Repeat until you have a manageable number.
3)  Pass survivors to anyone (with the same job) interested.  I'd find it fun to go through 10 or 20.  Maybe they can be in the kitchen or central place, for people to leaf through over a period of time.

I realize it doesn't help if there are 2K resumés on a desk somewhere.  Maybe you can iterate 3) a few times, but make sure to get a better system if you get so many.

Mr. Rogers
Monday, February 25, 2002

We ask that candidates sit a programming test. I've worked at a couple of places where we've done this and it weeds out the chaff like you wouldn't believe :-)

At my current place, I had the pleasure of writing the test and I tried to pose questions that were designed to reveal as much about the candidate as possible e.g. a slightly incomplete/ambiguous spec for a programming task to see if they picked up on it and if so, how they handled it, some short essay-style questions to see how well they can express themselves, etc.

Taka Muraoka
Monday, February 25, 2002

James Montebello says, "A number of firms end up hiring less than 2% of applicants."  We will end up hiring far fewer than 2%, more like 0.1%, since we have a handful of openings and, as I said, there are literally thousands of resumes.  (I neglected to mention that we are in the Houston area, home of both Enron and Compaq, so there are plenty of resumes to wade through.)

razib khan and Mr. Rogers both suggest going through the resumes looking (or grepping) for wanted terms.  The problems with this approach (which appears to be the one that we have been taking) are (a) all of the resumes look alike after awhile and (b) this tells you who has experience with XYZ technology, but doesn't tell you who is "Smart and Gets Things Done."

Taka Muraoka talks about a programming test.  I think we do have some sort of exercise that we are developing, but it will only be given to candidates who pass the phone screen and are brought in for a technical interview.

Mostly, to weed out resumes, we have to rely on the personal referral method mentioned by James.

I think the big problem is that there are an awful lot of mediocre programmers who got programming jobs during the big tech run-up of the late 90's only because companies were desperate for bodies.  Now all of these folks are out there looking for work.

Will
Tuesday, February 26, 2002

Hmm.  If I were in the job market right now, for employment at a company I would consider starting a high quality open-source competitor.  Then they'll know who the hell I am, and have a stake in hiring me.  ;-)

forgotten gentleman
Tuesday, February 26, 2002

forgotten: I am a big believer in always having a publically available sample of work, either as an open source project or a hobby project. It's one thing I find that can really help make your resume stand out and show that you are a "smart guy who gets things done".  Additionally, its a good way to keep your development skills sharp and learn new areas. I'm currently working on a freeware Java IDE (shameless plug: http://www.gexperts.com) and I've learned a lot about Java internals that has benefited me in my day to day job.

I'm surprised actually that more people don't do this. If I had a nickel for everytime I see a post on a job newsgroup asking how to get an IT job with no/minimal experience I'd be a rich man.

Gerald Nunn
Tuesday, February 26, 2002

Will mentioned that his company was in the process of putting a test but only for those who had passed a phone interview and were coming in for a tech interview.

We ask that candidates sit the test *first* before we even talk to them. Here in Australia, the bulk of IT hiring is done through recruitment agencies so we get the agencies to supervise the tests and all we have to do is mark them. Only if the candidate is any good do we then talk to them.

This saves a huge amount of time since after the agencies have done a first cull of the applicants, we only have to spend about 5 minutes per person marking their test before spending 1 hour plus in an interview. By the time we meet them, we *know* they can cut it technically and the interview can focus on their personal qualities.

Taka
Tuesday, February 26, 2002

I am going to have to agree with the poster that suggested viewable work. Whether it be a side-project or they have commit access on an Open Source team, it would mean a lot to me to know that my people are in it "for the love of the game".

Alex Russell
Wednesday, February 27, 2002

I don't know how many people you have interviewed at your current job (the requirements change for each company).  I would suggest trying a handful of people you "think" look good on resume. Put them through a repeatable interview  where you can break down the different areas you are interested in.

If you don't think they worked out -- understand what they lacked in and determine if you can see that quality on a resume.  If it is something that you cannot determine on a resume, that might be something for a phone interview. 

I personally am reluctant to do phone interviews because when I was looking for a job I would typically blow off a company that gave any sort of complex phone interview.  I never minded clarifying some points or experience and then setting up an interview.

Interviewing and finding good a fit is a learned practice.

Wyvn
Wednesday, February 27, 2002

We often resort to phone screens to determine who to call in for an interview.  The screen can be fairly extensive if, for example, the candidate is distant and must be flown in.

As for simply sifting through the resumes prior to interviews or phone screens, there are a few things I look for.  In my book, right up there with "Smart" and "Gets Things Done" is "Knows How To Communicate". Typically this correlates well with the other two traits, but there are exceptions.  So I notice how many spelling and grammatical errors there are, and whether the resume "reads well" and is organized or laid out so that the info I'm interested in is easy to find.  And I note whether the resume is concise, whether the candidate can condense to and present the essential info.  One former mentor of mine had a rule of thumb: he allowed a candidate one page of resume for every ten years of experience.

There are exceptions.  I've seen ESL candidates who are not fluent in English but who do just fine if you can exchange enough detail with them about their tasks and let them work on, say, driver and kernel code.  But I would not let them near a GUI, CLI, or any other user interface that a customer might see.  And regarding the page/decade rule, I have learned that I need to take into account cultural factors.  Many of our candidates come from India where, apparently, the resume guidelines lead to more like a page or more per year of experience. So if see that style of resume and they're from India, I know they haven't been here long enough to learn the American style.

Regarding "Gets Things Done", helpful clues are that the candidate uses active rather than passive voice, and describes accomplishments in crisp terms rather than vague ones.

Of course, all of these clues are things that a candidate can learn to polish their resume, so their presence is no guarantee of quality.  Likewise, there are some people who are smart in technical matters and can get things done but, darn it, have never learned how to write a good resume. But since resume filtering is a game of chance anyway, these clues can still be useful in the filtering process.

Grimace
Wednesday, February 27, 2002

*  Recent Topics

*  Fog Creek Home