Who do you hire and why?

Question

You are conducting interviews for a few (3) hypothetical software engineer positions that have just opened up in the company for which you work or own. The position involves a small team environment and implements leading edge technologies and methodologies.

• You have a stack of roughly 100 resumes. How do you pick your 20 phone interviewees? What stands out about what you see on their resumes?
• You choose 8 of the 20 phone interviewees to fly to the office. What about these 8 candidates made them shine above the rest?
• Finally, you offer 3 of them positions. How did you decide on these 3 out of the 100 applicants? What qualities did they have? What faults were you willing to let go? Did you have a hunch these were the ones from the get-go? How much do you let them negotiate their offer?

What do you consider the most important factors when hiring on someone new? Who shines and why?

Answer 1

Often times you can read through resumes and determine fairly quickly if the person will be any good. I would immediately toss any resumes with grammatical errors, misspellings, or any other "red flags".

Personally I would look for passion when talking to candidates. Get them to talk about one of their favorite projects, see what they like about it, what makes them tick. Also, soft skills such as interpersonal skills, writing ability, etc are more important than you may think. For example, the smartest person you hire will not be effective if they irritate everyone else on the team.

Spolsky has written extensively about this: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

Answer 2

You really should check out Joel Spolsky's Guerrilla Guide to Interviewing for a great guide on this subject.

Answer 3

I've never been involved in hiring myself, but I think that this is made out to be a much more complicated process than it should be.

The sad fact of the matter is that unless you are looking for a very specific skill, interviewing is a "buyer's market". It costs less to throw out a lot of unqualified candidates and risk losing some qualified ones, than to err in the other direction and waste time on unqualified ones. There will always be other programmers.

Programmers, like most people, make estimates and rely on hunches (and some prejudices). I think that if you had a stack of a 100 resumes and 10 people on your team, and you gave each resume to two people to skim, you could easily get rid of 80% of the resumes. That is how admission commmittees for graduate schools work, for example. Usually you just know. It's true that you may miss on some brilliant candidates (e.g., someone who's great but had a crappy GPA, a foreign background, or whatever), but you save time.

Then you do interviews. There's a limit to what you can do with phone interviews, but each phone interview is another screen and a chance to filter more people. You break it down to the amount you want to fly in and spend time on.

My own view (having not done hiring) is that the role of the onsite (when remote candidates are considered) is to confirm. In other word, don't use the onsite to decide if the candidate could potentially be considered for the role. Only bring him in when you feel that you would give him an offer and weren't able to demonstrate why not based on phone interviews and remote screenings.

I am also personally not a big fan of the beauty-contest style of interviewing: When you bring 20 people in, pick a few finalists, and decide between them. I feel that while chemistry is important, technical skills are the first order of business. I believe that it is particularly difficult to separate a person's ability from the personality you grew to like or dislike immediately from the meeting. I think it's much better to bring one qualified candidate at a time, see if there's a reason not to hire them, and if there isn't, to go ahead until you filled the quota. That's how dating and marriage works, and you just live with the possibility that you might have missed someone.

A related pet peeve that I've seen in most places: Don't bring people in, and as the first order of business sit them down to do a pen-and-paper test which is then reviewed with the team. The time to do these tests is in the initial screening. If the problem is that someone can cheat, figure out ways around it (e.g., limited amount of time, do it in real time on a shared editor, etc.). An interview should be about actual face-to-face communication! Don't waste people's time bringing them in if they could fail before they uttered a single word. If you brought someone in and failed them because they didn't perform well on a written test before you interviewed them in person, you just wasted plane tickets and hotels anyway.

Finally, a few things about rejections:

First, if someone will not get hired not matter what, let them know right away, don't wait until someone accepted the position. This behavior is common in academia but I've seen it in some organizations.

Second, if somebody is a finalist but not your first choice and you are waiting on the first choice, let that person know the situation, or even state that there is a waitlist. (Ideally you'll never be in this situation by avoiding beauty-contents). If you just delay your response, you are creating problems for other organizations (since the candidate may be a first-choice somewhere else but preferring your organization) and they do the same to you. This is actually a well-recognized cause of deadlock in academic hiring. This is also fair to the candidate. I would personally prefer to work for a less-attractive organization that wanted me as their first choice than a more attractive one that only got me because the person they wanted didn't accept. Nobody (well, most people) don't want to be defaults, and I feel that it makes you start on the wrong foot.

Third, do everything to make your process fast or you will miss candidates. I know a few organizations where the whole procedure for opening up the headcount starts after a candidate has been identified. Sometimes even months and years, by which the candidate is long gone. If you know your company has a lengthy process, do everything you can to ensure that once you find the right candidate you can make an immediate offer within up to a week. Have the mandate for it!

Finally, I personally believe that the further someone got in your process, the more information they deserve about why they did not make it all the way. (And I'll skip the dating analogies this time). If someone sent a resume and are just a bad fit, have the courtesy of acknowledging in a form letter, but don't sweet-talk it. If you write that "you are a great candidate, but bla bla bla" and the person is not great, it's a joke. Just say "your background does not match our needs, period". However, if someone made it further in, such as a few phone interviews or even an onsite, try to explain why they didn't get the job. Don't open it to contention, but explain in a personal message. I'd rather know that a place felt that I was not sufficiently versed in algorithms, for example, than to get a form letter. Form letters belong to situations where there has been no mutual investment. If someone spent the time to make the trip, try to at least be informative.

Answer 4

You might also consider taking a look at Programming Interviews Exposed. It's primarily aimed at people being interviewed, but it doesn't take a great leap of logic to figure out that it's useful for someone wanting to come up with interview questions. It also gives a few hints on what would be considered a "good" answer.

Answer 5

Steve Yegge has a some good blog posts about interviewing:

• The Truth About Interviewing
• The Five Essential Phone Screen Questions

Answer 6

There are two main criterion that I use.

1) What are their talents (I.E. Thought Patterns)? A resume doesn't tell you a whole lot, but there is some things. If it's well lad out, you see that they are organized. If it's full of technical terms and bloat, you ca see that they need to really feel like they're good at things. A phone interview can do a little bit more. It lets you get a feel for the personality.

2) Are they passionate about the stuff the position covers? If it's programming, I expect to see projects they work on after hours, or communities they're involved in. Who is in their feed reader? What is the podcasts they listen to?

When sorting resumes, I look at how they lay out the resume. What information they choose to include tells me a lot about how they think. The way they organize it does too.

The 20 people who I think are the most passionate and whose talents fit the role I'm hiring for get phone interviews.

When I'm on the phone, I start asking the simple questions. I don't have them write out pseudo code, but I ask them about their community involvement, open source projects. What do they love working on, what do they hate. Etc.

The 8 people who are most passionate and whose talents fit the role I'm hiring for get flown out.

Then I do an all day intensive. I spend an hour with them, then I send them to work with the team for 2-3 hours. Then I spend another couple hours with them.

The 3 most promising I'd offer a position. They would have to A) Work well with the team. Collaboration is key. B) Really be A's on the skill set I need.

How much can they negotiate? Depends on how bad I want them. People who fit best obviously have more leeway. People who don't don't.

As mentioned already, JoelonSoftware's Guerrila Interviewing guide is GREAT. So is First: Break All The Rules.

Answer 7

I've interviewed many people recently, and here are my thoughts:

We ask very low-level questions on a phone screen, and also have a pre-screen set of problems. These problems show us that the candidate can at least fizz-buzz (which is half the battle) and can defend their code. The questions are generally keywords, because any good candidate will follow up past a definition to application or practicality. If a candidate doesn't know a specific term, we will hint at the concept, and most of the successful ones will pick up on it and elaborate, because even if people use different words, the concept is the same.

We also ask a lot of soft skill questions, because if a candidate can program, we need to know they fit in with the existing group of people. We aren't looking to hire people who are here for a year and leave. While I do recognize people don't plan careers anymore (myself included) with a company, the industry we are in has a relatively high learning curve to do any serious work and we don't want high turnover.

If a candidate can code, can answer questions about database design, language specific questions (in the language they are most comfortable in) and willingly says "I don't know" when they truly have no idea (instead of BSing us) we decide to bring them in for an on-site tour and interview.

The on-site is basically follow up questions. If you got something wrong or didn't know, I want to know if you've studied up and researched an answer (this tells me you care). We also ask higher level questions, like how would the candidate solve a specific problem or architect the solution. The biggest portion of our on-site, however, is how they interact with us. If they freak out or stress about our workplace security, it's a no-go. We are a high-stress company (for whatever reason). If they seem interested, don't tick off the HR reps with their questions, and can show they enjoy software, we generally extend an offer.

edit: I'd also like to add that we try to phone screen every resume we get. People can write some HORRIBLE resume's and turn out to be really excellent developers. It's a skill like everything else, and if you don't practice it much (because you are good) then you won't be on the shiny pile, but could be well worth the time.

Answer 8

I'm glad to see that Joel finally got rid of his "ask Aha questions" advice--ugh.

Interviewing is a skill. One can take the easy way out by getting one of those "Big Book of 1000 interview questions"---and assume your candidates have the "Big Book of 1000 interview answers," written by the same author.

Or you can find out the only two things that (in my opinion) matter:

1. Can the person (quickly learn to) do the work?
2. Is the person a good fit for culture of the team.

You have a stack of roughly 100 resumes. How do you pick your 20 phone interviewees? What stands out about what you see on their resumes?

BZZZT! Wrong answer!

Step 0: Throw all all those dead trees--they're useless. Those 'trees represent what someone did for someone else in the past. Past performance is no indication of future returns. It also doesn't answer the two things that matter above.

Step 1: Create an exercise (or two) that is moderately challenging and (important!) represents the type of work you're doing right now. If you need to create a registration system for your new social media site, then make a simplified version of that your exercise.

Step 2: Post the rules for the exercise on your website, or (if you ignored step 0), send them to all of your 100 resume candidates.

Step 3: (money shot) The people who are motivated will respond! There will only be a few. Hurray! These are the people you want! Why? Why would you want to hire someone who won't do the work you ask them to do? The only thing that matters is a) did they follow instructions, b) does their answer seem reasonable?

Step 4: Any who you can say "yes" to both questions get a quick phone interview. The interview's purpose is to determine if the person can speak your language reasonably well and isn't a psycho recluse (if he/she says "my precioussssssssss" hang up).

Step 5: Bring 'em in. Make them write code on the whiteboard ("here's a database of animals, people and who owns what; show me how you would pull out the owners of cats in alphabetical order, skipping anyone who also owns a snake"). Give them a hard (but real-world example of the work you actually do) homework and a deadline.

Step 6: Anyone who failed the deadline (without a reasonable excuse) is out. Anyone who passed take a look at their code. Did they document? Do they have test cases? Are their variables well-named? Code well-formed?

Step 7: Make your choices.

Step 7.5: Determine if the person is a good fit for the team. How do you do that? This is the touchy-feely part. Have the candidate interact with the team. You can do a group lunch or an after-hours get together. Afterwards, get the team's input. Did they like the person? Was there anything that rubbed them the wrong way? Anyone have a gut-level reaction (good or bad)? Anyone feel there would be a problem?

If you have multiple candidates at this point, you probably don't want to dump them all on the team at once. Besides, giving the team free lunch two or three days in a row is not a bad thing. :)

Step 8: Bring the winner(s) in and hand them off to HR for the fill-out-the-paperwork dance.

Answer 9

Will give a tip I used, which automatically screened about 90% of the resumes.
I have an open source application in development. It is far from finished, and there is a bug or two in the installer.
My ad specifically required the candidate to install this application on their dev system (oh, and it will work only on linux...) and specify the text on the first screen.
It worked amazingly well,

So, without reviewing even one resume I screened those who had no idea on linux, Don't use FF/other advanced browser (means they are probably not good JS developers), they don't know their way around PHP and how to find bugs and all those who didn't even bother to read my ad and just sent their resumes.

Here is the example phpancake

Answer 10

Out of 100 CVs I would anticipate:

• Being able to cull 60-80 CVs by spending less than 30seconds on each;
• No more than 6 phone interviews; amd
• No more than 3 face to face interviews.

The reason for this is an hour spent on an interview consitutes as many as 6 (or more) hours of peoples time between reviewing CVs, phone interviews, 1-3 face to face interviews with typically 2-4 people in each so you want to do that to a minimal possible group.

If you get 100 CVs you will find some CVs that have basially been sent to every job. These are fairly easy to tell just from the CV. They may not have a cover letter and if they do it'll be very generic. You can pretty much dismiss these applications out of hand.

Also in this category are people who simply aren't qualified for the job (either over or under). Some may realize this. Many will not. Again I find this pretty easy to determine.

The next thing you want to do is look for CVs that are brief but to the point. You can fairly easily detect a lot of BS here too when people speak in vague lofty terms throwing about acronyms without mention of concrete accomplishments. Dismiss these too.

Basically you want to reduce it to a list of less than 10 of people who:

• have an effective CV;
• are enthusiastic about what they do;
• know something about what you do; and
• are keen to work for you.

If all of that takes you more than 2-3 hours for 100 CVs, you're not doing it right. In fact if you still have 10 left, you're probably lucky.

Next you want a phone interview--no more than 30 minutes--by you or a technical person you trust to weed out the serious fakers.

For those that make it, go to a real interview. Only have one person do this. Spend half an hour assessing purely technical ability. They must write some code on paper and assess a code snippet for problems. Very important. You may want to do a technical test too. Give them half an hour to answer questions.

Usually after the first half hour you have a pretty good idea if you want to proceed. If you do, bring in more people and go behavioural after the test. If not, just tell them the interview is over like there was nothing more. Again the point here is not to waste time on someone you're not going to hire. This is about your time and theirs. Noone should take this personally. There's a certain chemistry required to gel with a team and different people, all competent, will work in some environments that others in that group won't and vice versa.

Some companies may require or want a second interview. If you can avoid this, do it. I've passed on jobs I was keen on wheret they ended up being keen on me simply because they took too long. Some bigger companies may take 2-3+ months to go through the hiring process. That's fine if someone is working and looking but that process excludes people who aren't working who will tend to take something they're offered in this kind of market so don't rule yourself out for good yet unemployed candidates simply because you want to um and ah for 3 months.

Lastly if you find someone you like, just offer them the job. If you wait a week to go through all the candidates you may lose them and/or just waste more of your own time interviewing people you're not interested in.

If may be an employer's market but theres still a lot of dross out there and good people will find jobs. You need a streamlined process to ensure you have a chance of getting those people otherwise all you'll get are the people who could wait around for the process to end because noone else will hire them.