a companion discussion area for blog.codinghorror.com

How to Hire a Programmer


I have given some thought to your article. And now feel compelled to reply.

Detailed phone screens (#4) with the questions your illustrated is only appropriate for developers that do not have a portfolio.

Specific questions such as those you [presented in #4] are ridiculous for experienced developers. The phone interview format as you presented is essentially a time-based test of algorithm syntactics.

It does NOT allow developers to demonstrate ability to deliver quality solutions. It does not reflect developer ability to research options (using Google/internet blogs/etc). It does not reflect best-solution usually derived from iterative refactoring and testing.

I have encountered many candidates that pass your tests with stellar results. And some of those candidates can even write short code pieces in a time-test environment.
But those same candidates cannot write quality code nor deliver on required features. They are horrible developers.

Your questions do not highlight the candidates’s ability to deliver results. Usually it is not about “how fast can they produce” but more about “the substance and quality of what is produce”.

The best phone interview uses screen sharing and agile-style code reviews. Ask the candidate to provide code samples of their work… work that they are proud of. Walk through their code with them; analyzing pros and cons of the implementation and architectures. Discuss feature requirements and testing. Review the coding style, motivating factors, the refactoring, encapsulation, coupling, APIs, documentation of that code.

Another great approach is to present new code samples and ask the candidate to perform online, on-the-fly review of the code: discuss the implementation, style, etc. Ask them to provide their thoughts and analysis.

#1 is ridiculous for developers with a portfolio (#2). Only entry-levels should be give #1 or online tests. If the candidate is not entry-level, then they MUST provide samples of their code (written by them).

#2 and #4 performed with code reviews [as discussed above] gives really good indications of enthusiasm, comprehension, completeness of feature, representations of the candidate’s version of “quality delivery”, and more.

#5 is a great follow-up to candidates passing #2 & #4.


Another Great and useful post by Jeff Atwood. but I am little disagree with you in some points to kept in mind while hiring a programmer.


Interesting article. As a general matter, I don’t look for programmers - I look for problem solvers.

While much of what I read in this post is good in theory, practically, it is not workable. Too much effort on the part of the interviewer.

You want to learn about skills? Post a repo on github with problems. Direct the candidate to that. There will be a readme. The code should have problems as to not working and not compiling. Instruct them to fork, fix, and submit a patch. Did they write tests? Did they make one big checkin or several? You can also add hypothetical use cases and problems for them to answer. Writing is a key skill in this industry. Do they just answer in tech terms? Or, do they mix in business analysis.

Through this process, which takes no time on the part of the interviewer - except to review the submission - you can learn a lot. The candidate may be a senior developer - but through this process - you will have a gauge of what kind of senior dev he/she is.




What you say is very interesting. I’m a passionate software engineer but I have a problem. I stutter a little when talking to people and I have fear to not pass my future interviews due to this problem and because I think I have some kind of social anxiety disorder… What can you say to me? Thanks.


These methods only fit if you’re a google level company. i.e. you can
1.) Afford the risk of filtering out a good candidate (which is bound to happen with the way you interview)
2.) Afford the high paycheck that anyone who passes this gauntlet deserves.

If you’re not, then please burn in hell. I always hated small-time startups taking more time to hire than it would to actually develop their project.


Ask the candidate to provide code samples of their work… work that they are proud of.

I’ve never understood this. I’ve been asked for code samples a couple of times in the last twenty years of developer interviews, and I just don’t get it.

I work for companies, producing software that they own. So I have no rights to that software and would be violating my contract if I was to show it to anyone outside the company. Not only that, but in any company with a long-lived code base it will modified and rewritten by numerous other developers, so finding a self-contained piece of code that I wrote by myself would be difficult, to say the least.

I can pull some code from the open source projects I’ve worked on, but that’s hardly representative of what I’d be writing in a professional job with budgets and deadlines. So unless you want to hire people who’ll walk out the door with code you’ve paid them to write, you’re basically asking me to sit down and write some dummy code which will never be used for anything other than a talking point in an interview. I don’t get it.


@Clarence Risher

Then you are doing something wrong with your resume. Ask some help around to see if you have something on your resume that makes HR bin it.


#1 is not ridiculous at all, as Jeff mentioned. It is trivial and takes no time to solve it, but it proves you have rudimentary coding skills.

If you as a candidate have problems with this test, it would be a red flag for me. But for totally different reason - attitude problem. No task should be “below you” to perform, no matter how trivial. It shows how good a team player you are.

I would never focus attention on CODE, because it is learnable. Problem-solving and designing good solution is critical and scarce.


I guess this applies only to the “junior programmers” that sometimes are sent to the customer by large organizations, honestly, if after 31 years and millions of lines of codes written in a dozen different programming languages somebody asks me to write a program to display “hello world”, it means only that I am in the wrong job interview and I should immediately locate the nearest way out.


I like to see if the candidate can type. I give them the keyboard and ask them to show me what they’ve done. If they look at the keys, its off to a bad start.


Right on Martin. If you can’t touch type, then you can’t code!

We have established gurus teaching our teeks (IT learning units), so we don’t worry too much about an immediate type test, but our business is virtual and international, so a touch test is less important than a portfolio. Great article!


This sounds exactly like the interview process for big corporations such as Microsoft.


“At some point in the process you might want to think about how to convince that awesome programmer to work for you and not for somebody else.”


The strategy you’re outlining is extremely risk averse (mostly to the benefit of the company), heavyweight, and is going to lose a lot of good people. Maybe all of them. Personally, I would immediately conclude my time was being wasted, there was a cultural mismatch, and I would head elsewhere.


I am grateful for the sample phone screen questions, especially number 5. If I’m ever asked that question in a future interview, I’ll have the answer, but only because I read your blog. I haven’t messed with octal values in over 20 years. It’s a fine brain teaser; I might change it to “How is Halloween the same as Christmas”.

I really do enjoy your blog.


Hiring for cultural fit is very important - but you can’t really determine cultural fit unless you meet someone face-to-face first.

Phone screening is a good way of ensuring that the person you want to interview isn’t a total monkey, but we’ve found that it doesn’t save much time in the end, as we still have to interview the candidates that pass phone screening anyway, so we might as well just interview anyone who we feel qualifies based on their CV and agent recommendation, as we can kill several more birds that way.

We’ve done a lot of dev recruiting recently, and have streamlined our process to the following, as an example:

  • Candidate is evaluated based on CV and agent recommendation. We try not to be too picky at this stage, depending on how many CVs we get.

  • Candidate has initial face-to-face interview with 2 senior developers (to ask technical questions) and dev manager (to establish initial cultural fit). Any interviewer can veto the candidate at this stage and cut the interview short.

  • If initial interview is successful, a standardised audition project is given. This enables us to compare developers against each other, if need be, whilst still establishing the candidate’s core competency and coding style. The project is tailored to the technical and business environment of the company.

  • If the audition project passes, then we invite the candidate for a final interview, where they will meet a wider range of staff in a more informal setting, including the directors of the company. At this stage the technical evaluation is complete, but staff members can still veto the hire if they find the cultural fit or personality of the candidate to be a real issue. It happens quite frequently, actually - I’ve had several candidates that I felt were technically strong and a good cultural fit get booted out at the last second due to poor performance in the final interview.

For our company, this process has resulted in the least involvement from both parties, as we establish the majority of what we need from the initial review. The audition project is very useful, but I do believe it needs to be standardised, otherwise you can’t see how different developers stack up on the same tasks and sometimes that’s the only way to choose between them! The final interview is really just a sanity check.

Your optimal process will be different of course, but it should be streamlined and consistent, and not waste anyone’s time, if at all possible.


I’m going to take a stab in the dark and guess that you’ve never actually done this process that you’re recommending. I don’t know if you caught it while you were writing, but you actually just recommended having people come into your office to do paid work for up to two weeks before you’ve even met them in person. Somebody correct me if I’m completely off-base here, but isn’t that completely absurd?

Not to mention that this method (step 5 specifically), is likely only going to get you two types of applicants: Those that are completely and utterly dedicated to getting hired to your specific company, and people with nothing better to do with their time. I don’t consider myself to be in the very top tier of programmers, yet months before I graduated college I had more job offers than I knew what to do with. Not just “job offers,” but good job offers with reputable companies and competitve salaries. If a company had required me to do several days of work for them before even considering giving me an interview, guess what I would have done? If you guessed “dropped everything (including school, several actual job offers, and my very fulfilling part-time programming work) to work for you for a week or more just to audition for your company,” you are sorely mistaken.


Yes Robert, it is absurd. This is the outcome that should happen.

Interviewer: “We see that you have 10 years’ experience as a corporate engineer… We need you to take a week off of your current job and complete this project for us. After that, please come back to our office for a talent show.”

Interviewee: “I’m leaving….”

Interviewer: “Your hired!”

If you want to hire the best, you should be marketing to them. Not making them jump through hoops for you. If I asked even a young develop/engineer to do all of these requests and they walked out of the interview, I would run out into the hall and hire them. They know the true value of what we are working for and creating, not all the fluff.

Better questions would be about application design, modeling, and testing. If your interviewee can carry a conversation then it’s pretty much implied that they can code what you need. If they start talking about CSS when you mention application design, then that’s the only filter that you need.

Its old programmers that forget they were once a 24 year old with no professional experience come up with these crazy interviews. It’s becoming unfair. I don’t think I could solve some of these programming mind games in high pressure interviews.


I’m not a fan of #1 and #4. I know how to program, but I’ve been on interviews where I’ve be asked to write code on a white board and I looked like an idiot. Programming is done with a keyboard, with your eyes on a computer screen and seeing what happens with it. Writing code out by hand feels unnatural and I can’t think straight if I’m asked to do it like that.

Same thing with answering random programming questions over the phone. It’s different to be writing code on your own to solve problems you’re working out, than to try to speak about it to someone and answer their gotcha questions out of context.

I’m sure you can find great candidates like this, but I think you’ll also be weeding out great candidates. It seems like you’re trying to find one kind of thinker, but there are people who can get the job done and have a different perspective on things that won’t pass these tests.


Except for the guidelines 2, 3 and 5, all the other points are reasonable and pragmatic and I definitely agree that they would help hire a good candidate, however

  • 2. Ask to see their portfolio
  • This must be optional as many might not have the time to write their own blog but participation on StackOverflow or other programming websites is a good indication but making it one of these a pre-requisite and there is a good chance the interview can be an over-kill for the candidate.
  • 3. Hire for cultural fit
  • This is debatable as you have rightly mentioned not every business has a community around it. What is the alternate strategy would you adopt for the one's that don't ? Where do you draw the line?
  • 5. Give them an audition project
  • Well I am not sure how many people can sacrifice one week their work time to work on an interview project. This round can be a show stopper for many. Count me in. I can definitely agree with an assignment that can be completed within that day.

But overall an effective and tough screening to get a worthy employee but I am expecting another article from you which gives similar perspective from the employee who pass all these tests. :smiley:


Without going into how much I agree or disagree with whats been said, this article is making the bold assumption that a company gets flooded with applicants for a programming position, ranging from useless to awesome. This is so far from reality that I find it obsolete to form an opinion on the validity of the further arguments.

It’s like writing about how guys can weed out all the chicks offers in a club and pick the best one. How’s the weather on the planet you’re on?


While I agree with the need to test coding skills with all due respect I think a lot oof the ideas presented here are archaic at best. I think the more real world interaction you can get with the person the better.

Give them a quick project to work on a couple of nights before the interview and then do a ccode review. The process you describe above takes hours of time from the Candidate and the staff. You can do a code review in an hour and know more about the Candidate than you do by the above.

And a project? I would question anyone who would or would even ask someone to work for free and any senior level developer would laugh.

I went over this in some detail at this post. http://www.lonestarprod.com/?p=22