What process do you use to recruit programmers?

Question

What process do you use to recruit programmers?

we have a multi stage interview process...

Pre interviews... Resume review..... then if they are interesting :-

stage 1: come have a chat, talk about what you have done, discuss the position, dig a bit into they approach software development

stage 2: Coding Test

Stage 3: Generally discuss an offer

Each stage is usually a different day, so we can call it quits at any stage. what we dont have is a phone interview stage. I'm wondering if people find this useful? We basically would like to get to the point of saying "No" quicker so we can evaluate more people.

Related:

• Are written tests useful skill assessments for developers?
• What’s a good non-programming interview question when hiring a programmer?
• What are some essential software architect interview questions?
• Interview Questions for an Intern
• What do you think about using the Project Euler website as a candidate profiling tool?
• What interview question weeds out ‘bad’ applicants?
• Properties of good coding interview questions?
• When interviewing someone, should you ask why they’re looking for another job?

Answer 1

Why isn't that first part a phone interview? Why isn't the offer done over the phone? Seems a little inefficient. That's a lot of days.

Answer 2

Yes, I do find the phone interview necessary to save time. You can typically eliminate those who fudged their resumes in a short 15 minute phone screening. However, the rest of your stages look fairly comprehensive.

Answer 3

Phone screen if we suspect the candidate has communication problems, or something suspect about the candidates resume.

Then typically 2 face to face interfaces at two different times. It allows us to think about what happened during the first interface, and also only invest half the resources in the candidate if it turns out we will pass.

We ask different types of questions; I usually go heavy on technical details listed on the candidates resume. Another person will ask big picture design questions, and hit fit and goals of the candidate. One person probes for drive and interest. I usually always end up with asking the candidate for feedback, and provide the candidate with the feedback received by the end of each day. At the end of the 2nd interview I would discuss the possible offer, and if we are ready to make an offer discuss the offer letter itself. I always insist that the candidate think about it before making a decision.

/Allan

Answer 4

There are two levels of recruitment that we carry out for developers:

• Fresh College Graduates
• Experienced Developers

For the fresh graduates:

• An aptitude test, followed by a coding paper on their campus - this allows us to shortlist a handful of candidates (5-20 from more than a hundred who usually take this exam on campus).
• The shortlisted candidates are then asked to come to our premises for another round of coding test, followed by a technical interview.

For experienced developers:

• First an aptitude test.
• Then a coding paper.
• Then technical interview.

For other positions such as team lead, architect, project manager, etc. its a different set of steps.

Answer 5

Our first stage is an e-mail coding test; from a batch of "easy" and "hard" questions we send them one of each and allow two hours to respond with an answer. That weeds out a lot of the candidates quite quickly, although you will have to spend time re-examining the questions and tweaking them as necessary.

After that, phone screen(s) and HR conversation; if they pass all that then we bring them in for interviews.

Answer 6

For what I deem as best practices, Joel Spolsky has a comprehensive post on his blog entitled Joel's Guerilla Guide to Interviewing (version 3.0).

Answer 7

In addition to many of the techniques mentioned above, we have sometimes done a pair programming interview.

One or two interviewers sit down with the candidate and give them a problem that can be solved in 60-90 minutes. Visual Studio is prepped beforehand with a skeleton project, including a dummy unit test. We describe the problem on the whiteboard, then let the candidate start designing and coding.

The value in the exercise is that we get to see the candidate in action on a problem that's more complex than the typical whiteboard exercise (e.g., tell me if this linked list has a cycle). It gives us a good feel for what it would be like to work with the candidate, their personality, their attention to detail, their willingness to interact and ask questions.

From their perspective, it gives them a feel for the way we work and whether they like us. (Remember, in an interview, you're also selling the candidate on your company.) For candidates who haven't paired or done test-driven development, it's a great hands-on experience.

You can't cover as much ground this way as you would in a more traditional interview, but I feel it gives valuable data. It's also somewhat artificial in that in a real pairing session, you wouldn't be biting your tongue and refraining from making suggestions.

I've seen at least two candidates rejected because of the pairing interview. One wasn't doing well anyway, and the pairing interview sealed the rejection. The other had been doing well with the other interviews, and he gave great whiteboard when we discussed the problem initially with him. But he absolutely could not code worth a damn, which surprised us as his resume indicated that he was very experienced.

Answer 8

As an interviewee, I get really put off when the "chat" part of the interview is separate and before the "test" part of the interview. I don't mind chatting first and then being asked to demonstrated programming skills, it's when the first selection criteria is based solely on the "chat".

I want to work for a company that hires people who can program who they like, not people they like who can program. There's a subtle but important distinction. I've walked away from interviews because I've been asked if I want the job just from a chat, because I reason "if you'd hire me after that what would be the quality of the other people I'd be working with."

Answer 9

read Jeff's post on "Getting the phone interview screen right"

Answer 10

• Make sure you get them to write some (at least) pseudocode during the interview.
• Take notes during the interview so you won't have to rely on your memory later on.
• Ideally have a standard template of areas/topics that you should consider for every candidate (only has to be a one-pager) so you remember to ask every candidate about everything that you care about (and you comparisons between candidates will be fair).
• I like to ask candidates a fairly easy question first -- something a bit open-ended. That way it gives them a bit of confidence and gets them talking, and hopefully leads to discussion.

I try and avoid straight question-and-answer interviews, since that doesn't give a good feeling for the candidate. Ideally the three of us (2 interviewers, 1 candidate) can have a bit of a conversation and get to know each other whilst also covering all the necessary topics of the interview. It makes for a more relaxed interview, and the whole point of the interview is to get an idea of what they're like technically and personally in a very short space of time.

Answer 11

Put some coding tests for example the FizzBuzz problem, and other related problems that your candidates must solve within a time frame.

Answer 12

A good approach that has worked for me (and on me) in the past is to start out asking the brain-dead-easiest questions you can about a technology on the applicant's resume. This helps break the ice and sets the interviewee at ease. Ramp up the difficulty of the questions until you find out where the ceiling of their knowledge is at. Finish off by having the applicant solve a simple programming problem (whiteboard is okay, but I prefer using a laptop) in your target language, just to make sure they can finish a piece of working code. The problem you choose should be something you've actually had to do at your job, in order to reduce the risk of them having heard the problem before.

Answer 13

We screen a lot of developers for our clients (we are an IT staffing/recruiting company). Sometimes we use some Brainbench tests for our candidates but mostly we do 90% of the screening and when they get to an in-house interview with our client the client usually tests them by having them them write some code, etc.

If the candidate has made it past our screens and the client initial interview then the code part is usually the final part.

Answer 14

"The Guerrilla Guide to Interviewing" (Joel Spolsky)

Answer 15

If you're hiring developers, there are two types of interviews and they depend on the experience level of the developer you want.

If you're hiring someone straight out of school or their first job as a developer, then you have to find out if they technically know what you're talking about and some of the previous responses address that.

However, if you're looking for experience, trying to test them in the interview process by asking for code or pseudo-code is a complete waste of time. If you're looking for an experienced developer, and I say this as having been on both sides of the desk and having started my career 30 years ago, there are at least two things more important than asking someone questions with syntax answers:

1) Check their references. See how they were in previous jobs. You want to know what kind of employee they were? Ask the people that used to work with them.

2) Ask META questions. The technicals details are NOTHING if the person isn't good at problem analysis or can't get along on a development team. Ask for HOW they would solve a problem, not what code they'd write to solve it.

This is all far more important than if they can write the most efficient sorting algorithm.

I've had people ask a couple of technical questions on phone screens and that's not too bad, depending on how many people you're sorting through and how much experience they should have. There's certainly nothing wrong with asking questions like "Have you ever used .NET remoting and, if so, how?" But taking time to to set up meetings, clearing people's schedules and wasting some of that time physically writing code? That's slow and inefficient to say nothing of the old "ask 10 programmers to code a routine" problem - how do you judge the results?

Talk to the person. Get a better feel for who they are. Ask them what challenges they overcame in previous positions and how they worked through it. How did they work together with other members of the team? What tools were used? Did they ever have to learn completely new tools without supervision? Do they know when to stop beating their heads against a brick wall and ask for help?

Answer 16

For experienced developers, I'm not really sure if "coding tests" should be part of interview or process, technical questions - yes, technical discussion about how particular problem was solved - most definitively as well as questions related to the particular technology (C++, C#, Java, etc.) to find out whether they really know what they say on their resumes.

I'm very bad with syntax on the whiteboard, I can do pseudo-code sure, no problem. However I've met people who asked me how to traverse trees and such. I've done that about 10 yrs. ago in college and I'm sure I could recall most of it in few or more minutes or after looking it up in wikipedia. My point is that while every developer should know all the theoretical computer science material the reality is that most of us forget because a lot of it is abstracted from us in C#, Java, etc. We all know how hash tables work and how efficient they really are, but do I have to write implementation of one during interview process? I earned (through hard work) my BS in comp. science and masters degrees and I know that if anyone went through similar problem they do know most of the low level stuff. (unless they list a school I've never heard of) I do agree however that when it comes to junior or entry level developers that we should ask them these questions and perhaps give them small coding test. Maybe.

Answer 17

Where I work we seem to have a few steps to the process that seems long but isn't really that bad:

1. Resume collection - This is usually on-line though I did submit my own in person by hand to get a job where I am now.

2. Phone screen - Which if I recall was a handful of questions that I'm not sure if anything there would have prevented me from getting to the next stage.

3. First interview with the manager - This is where I get to meet the person that would be my boss and ask some questions and get a view from someone inside the department I'd be working.

4. Fit interview - Next step is to have the team lead and a couple developers do a sort of group interview that lasts about an hour and then have a little handwritten test at the end.

5. Call with offer - The next step if all goes well is to get the offer of a position.

6. Come in and sign the offer and set a start date.

Answer 18

I'm very bad with syntax on the whiteboard, I can do pseudo-code sure, no problem. However I've met people who asked me how to traverse trees and such. I've done that about 10 yrs. ago in college and I'm sure I could recall most of it in few or more minutes or after looking it up in wikipedia.

ra170 has it completely correct. An experienced developer should not be given those "is Knuth your bedside reading?" kinds of questions during an interview. Not only is it a waste of time, it's also a bit insulting.