How to Hire a Programmer

There's no magic bullet for hiring programmers. But I can share advice on a few techniques that I've seen work, that I've written about here and personally tried out over the years.

This is a companion discussion topic for the original blog entry at:
1 Like

Great ideas here. The only suggestion I would make is to replace point 5 … instead of having an ‘audition project’ why not just have a ‘probationary period’ (e.g. 3 months) during which time either the developer or the employer can decide to end it if things don’t work out. Its fairly common in development jobs in Australia.

Saying knowing how to program is actually different from actually knowing how to program.

One job that I applied for (and got hired) I was asked to do using a flowchart (this was long long time ago) of determining the day of the week given a specific date.

Once I finished the flowchart they gave it to a programmer who wrote the COBOL program for it and with a few changes it worked!

Lots of good points here. Number 2 is the only one I take issue with. I think there are solid developers (hopefully myself included) that do not have any sort of public portfolio.

I think for every dev contributing to open source projects, working on websites, and spending there time on stack overflow, there are five that work 50 hour weeks for large companies in government, automotive, health care, finance, etc. who don’t work on on products that are public and can’t show code they’ve written. It’s also tough when you work on a team of 50-100 in parallel and only pieces (maybe not even entire features) are solely written by you.

As for working on projects outside of work, maybe I just don’t possess the proper dose of passion but in my free time I want to spend time with friends, family, and other hobbies - that’s why it’s free time. But that doesn’t mean I don’t bring my best during business hours inside the halls of my office.

I think this division in mentality is a core difference between Silicon Valley startups and large corporations. Regardless though, I think you’re other metrics help to solidify a candiate and are excellent suggestions; I wish we exercised more them.

I think all this comes down to a simple rule:

Don’t hire anyone that you don’t already know, trust, and will fit in to your organization.

Now, how you get to know and trust any potential hire are details that can change depending on the situation. The steps that Jeff outlines above are good if you have had no contact with the applicant before the interview.

Personally, I’ve had good experience hiring grad students who already have some work experience and come recommended by their professor. It definitely helps to have strong connections to local universities, but hiring these kinds of students makes me fairly confident that they are: hard working, smart, experienced but still open-minded, and tend to have a good mindset for the place where I work.

In a similar vein to what TravisVT said about 2, I have concerns about 5. The time commitment alone is going to disqualify a lot of people who are currently employed and most corporates have employment contracts that specifically prohibit doing other work outside of office hours.

There should be a step 0 consisting of an introductory conversation to make sure that both sides know who they’re dealing with in terms of basic things like the kind of workplace you are, the kind of person you’re looking for and the recruitment process.

Last year I applied for a job through a consultant where all I knew was the name of the company and the content of their marketing website. The first communication I had with them was “do this code test”, then the next communication was “now answer this 5 question exam”. When the consultant told me they wanted me to come in for a “technical only” interview, I told him to get lost. It has to be a two way street, these people had sucked hours of my time without even giving me a hint of who they were and what they were offering. I got the impression they had no respect for what I might be looking for.

At another company, the manager contacted me directly and told me about what their recruiting process involved (e.g. how many code tests, interviews etc…) and the kind of working environment they offered. In the course of this conversation, it became apparent that the workplace culture was one of intense social engagement where the employees lives were centred around the job. While I could see the appeal of that kind of job for unattached people, I didn’t think it would be great for me as a father of young kids. I was able to self-select out of the process early rather than waste everyone’s time doing code tests etc…

Step 0: Introduce yourself, talk about your goals and outline the process.

Great post. I agree that companies should do all of this…But, it’s very one-sided. Granted, the best hires are ones who, like you said in 3, are already part of your community and want to work for you. Most of the time, though, an amazing programmer will be amazing for many companies. You also have to tell them what your company has to offer. Especially in this market, the interview process shouldn’t be about vetting the programmer, but figuring out if there’s a fit, for both sides.

I feel you’ll miss out on a lot of really good programmers if you approach interviews as a way to see if you want them to work for you. Interviews should be about figuring out if you can work together, and that goes both ways. In a sense, both sides should be interviewing each other.

Great ideas here, though I also disagree with point 5. There are a lot of people who a) want to be employees not contractors and/or b) are currently employed (and are “content” if not “happy” at their current job - these are usually the most desirable hires, and requiring an “audition” contracting period means you’ll miss out on great people.

Also, I’ve used (I have no affiliation with them) for phone screens and found it very useful. I like the idea of codility and Interview Zen, but I’d worry about the interview questions being posted at various sites online (that I won’t mention here to avoid giving them pagerank :slight_smile: ).

Much like some of the commenters above, I think points 2 just eliminates 80% of the valuable workforce. And having something else to do than programming during your spare time is not the only reason, contractual agreements sometime mean everything you code during your spare time must be first submitted to your company before going public.

About point 1, in 20 years I never meet anyone who was not able to code during a programmer interview, but I guess we have less script kiddies in Europe (or, may be, better engineering schools).

To me the network is the most valuable thing, however, the worst programmers I ever met had been recruited because someone knew them, so this does not dismiss formal interviews with someone who doesn’t know the guy.

I would love to see an equivalent of “How to Hire a Systems Administrator”, which of course I’m currently struggling with…

I was with you until point 6. If I was asked to do that I would politely decline and carry on looking elsewhere for work. It seems more like a talent show audition than anything useful for me (the interviewee). I can see how it may be of value to the employer, plus the unwritten benefit of the occasional cringeworthy and uncomfortable presentation. That’s one of the reasons why shows like America’s got Talent are so popular after all right?

I’d much rather be put on the spot and have my area of expertise tested in a Q&A format so I can’t just cherry-pick my strong points.

Maybe it’s because I am more introverted, although still fine communicating and getting along with people. I wouldn’t have applied to a role that needed me to present as part of the job in the first place so I certainly wouldn’t expect it as part of an interview process.

Anyway, I’d be happy with any company doing the first 5 suggestions if I applied there.

Moneyball is an excellent allegory for software developers.

Can they code. That’s really all that matters. The only way to know if they can code, put them in front of a whiteboard and make them code. Everything else doesn’t really matter as much to me.

For those that don’t have time/desire to work on projects outside of their normal day job, understand that you are competing with people who are equally as smart, who put in just as much time at the office, but also work on projects outside of work.

The problem with the audition project is time.
If it’s something that can be done over a weekend then maybe this is fine (for most people at least).

But if you need someone to take a week or two away from work then your relying on them being able to get that time off from their current job or to quite their current job just on the risk of getting hired.

This is going to rule out many experienced candidates who may have family commitments and will want to use their limited holiday time to actually take their family on holiday.

I would struggle a little with 2 because I can only infrequently publish my code. However I have done a couple of presentations to user groups that are online, and I have a collection of StackOverflow accounts (one per employer). It’s not a completely unreasonable requirement, but it does suggest that you’re hiring at the top of the market. Whether that’s a top 5% graduate or a top 5% senior software engineer, it means you’re going to have to pay a premium to get those people interested.

Point 6 would wipe out pretty much every non-Merkin programmer I know. It’s a very USA-centric thing, and possibly even US-startup specific. And I do wonder if you’re selecting for people who are likely to quit on short notice because their out-of-hours project got funded.

I think this kind of process for interviews is really prevalent in the US, especially for big companies.
And when I read here and there how easy it is to get fired there, I don’t understand why you put such a barrier for the entry!

As a programmer, I’d feel insulted if I had to pass through 5 layers of requests and experiments until seeing someone face to face. I’d let go after the 2nd or third.
If a company is making his future employees pass through hell just to have a chance of going in, thanks but no thanks. That’s not the company I want to work for.

My 2 last job interviews (for 2 small companies in France) went in 2 shots: one on the phone, then face to face, where I was faced with 1 or 2 “programming” questions, then ~1 hour of discussions about what the job was, what I did before, and how comfortable I was feeling doing this job.
Now, these were (are) small companies, where there was no HR that was PAID to design lengthy interview processes. I directly talked to the guys I’d be working with, and I don’t think they made a mistake taking me. I’m still working in the 2nd one, as an happy programmer.

There’s a question of trust in an employer/employee relation. I had a 3 month trial after both my interviews, and I was absolutely ok with that. This period is made for that: if I didn’t fit, it would show in the first 3 months and I’d be thanked. No need for a 2 month recruiting process!


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.

I think it’s important to respect the candidates time. Paying a candidate for a project is the right thing to do.

I’ve seen application process where the candidate is asked to write a whole app. They said it should only take 2 hours, but from experience I know it would have taken at least a day to do it correctly. I strongly doubt that they would have checked the code other than compile and run. Due to this I didn’t even apply.

Nice tips, I’ve also written a few lines about the topic:

Just give person 4 problems from or similar site starting from really easy to any difficulty. Leave candidate for X hours and come back to check progress.
“portfolio”? Nice if you have one. Many don’t.
“audition project”? I don’t have free time for that.
“15 minute presentation”? As somebody mentioned - talent shows are not for me.