How to Hire a Programmer

Interesting ideas and I agree strongly with most of it, but I do take issues with a couple of points.

The consultancy or probationary period is the one I find most objectionable. This works fine if an individual is out of work, but the majority of people you’d want to hire are already employed and looking for a change. Asking them to quit a current role so that you can audition them for a month is something very few people would accept. There’s always the chance it won’t work out and now you’ve gone from employed and looking for a perfect fit to unemployed and needing to find a new role ASAP. An audition project that is smaller and can be worked on over a weekend or in free time can work great, I think.

In addition, although commitments to open source work is great I know many programmers who haven’t worked on anything that isn’t proprietary and confidential since college. It isn’t that they don’t love their work (although that is possible of course), but would rather spend free time with family and devote extra time, when it exists, towards advancing prospects with their employer by working on “nice-to-haves” there. In many cases this is an employee you’d love to have, but may completely lack a public portfolio.

I kind of disagree with Number 5. Small assignments are fine but what’s the line on how much to pay that person compared to the size of project/task that is given to him/her?

I also think that some companies are using that kind of a task to their advantage or can start using it that way, which isn’t nice if you don’t get hired in the end…

I was given a test after a face-to-face interview. I aced the test, then told I was a 98% fit (I had a good interview (2-3 hours prior to this “assignment”) with 2 senior programmers and CTO), then I didn’t get the job because I was “too confident”.

I blogged about the assignment and solution here: http://www.kanersan.com/blog.php?blogId=46

The company was providing private advertising solutions to businesses. They could’ve used the idea/theory of my solution in one of their projects but I did not get a dime out of it and spent a good day solving it… This is why I’m not happy.

I’m glad this works for you and it works for the unmarried prospective employee, but what about the rest of us? I don’t have time to code as a hobby anymore. And I have a family situation that requires me to have actual insurance so I don’t do contracting and would never agree to your week long contracting gig and a hiring process that looks to take another week or 2 beyond that. Regarding your “pitch” idea: really? Just …really? You’re picking the best introverted programmer based on a high-pressure sales pitch?

I love so many of your posts but it’s hard for me to even read this one.

“Hire for cultural fit”

I get what you mean, but you’re treading on an HR minefield in the US!

Be very careful that ‘cultural fit’ doesn’t become a code word for ‘guys I’d like to hang with who are non-disabled members of my age group, racial group, etc’.

Culture fit is good, but if your hiring process produces a homogenous employee group then that’s bad for business and possibly not legal.

Fit, fit, fit – #3 is the most important for me. I actually ask only a few technical questions just to be sure the person actually has the technical knowledge to match their resume. (In fact, an interview I did last week was laughable – the candidate claimed significant database experience but could not answer the question “what is the difference between an INNER and OUTER JOIN”.)

I was trained in “character-based interviewing” where certain characteristics (team work, problem solving, communication) are key in most jobs. I have found again and again that if a person demonstrates these characteristics, and has decent technical skills, the person will succeed. Then again, my current company requires a close working relationship between the business and the developers so “soft” skills are a must.

#2 isn’t generally applicable - I’ve generally worked for corporations, and they’ve paid me for my skills. They don’t want that code walking out the door with me, and between kids, a wife, and a life I haven’t always had time for doing programming on my own. And anyone who asks specifically for code that I’ve done for a previous employer is asking me to act unethically, and I’m not working for people who ask me to violate my ethics.

#5 is a ‘no-go’ for me as a candidate. I’ve had people try to do this before, and I told them no thanks. If I’m job hunting, then I’m looking for a real position. Offering me consulting work says to me that you don’t actually want to hire - you want to pay me less than I’m worth for a while, without all that hassle of having employees and paying unemployment, etc, etc.

Now I understand why you want #5, I really do. But from the candidate’s point of view, you look like you’re trying to take advantage.

Instead, state up front that you’re hiring the employee for a trial period (my present position says 3 months) and if they don’t work out DO NOT HESITATE to send them packing. If you can’t fire people who don’t belong at your company, then you shouldn’t be running a company.

One of the worst things is to get a candidate to “write software” on a whiteboard. No one writes code on a whiteboard. So don’t ask someone to do it. The candidate would be better off walking out of the interview than to be made to to that.

#5 ensures that you only hire someone who is not currently working, and thereby seriously reducing your applicant pool. As other have said, it may work for Google, but will not work for a generic Fortune 500 company, unless there is something spectacular to motivate the applicant to jump through all those hoops. There are just too many willing employers who will not require as much.

Posted too soon, and stopped at #5. #6 is a real laugher. Not sure what market you are hiring in, but usually, in this part of the country, it is the employer who is pitching the candidate, especially one who has completed steps 1-5 successfully (around 10% in my experience would get past #4). Jeff, I think you have been around the Cali startup scene too long, and forgotten how things really work in the real world.

I think many developers these days are poor programmers because WE DO NOT PROGRAM ANY MORE. We simply use frameworks. And what is frameworks? Guides into making great and powerful applications.

I remember when I was a C programmer, I use to code a lot – from the ground up. Now I use Spring framework alongside with some ORM, and what I do? I simply inter-connect everything and I got

Given what’s available in the field, if you’re going to put your applicants through all that, it had better be one amazing job.

What do you do when your burned out from boring work at your current employer and aren’t really passionate about anything? It’s hard to get passionate again with programming as a hobby after spending 40+ hours in a week doing unenjoyable programming.

I’m with Matthew Kane and Bob T (figuratively).

Really? And after you have a good fight with the other super-hot leading edge colonies of brilliant coders in your area over this guy, have fun with the warm body you hire overseas.

No wonder American employers say there’s no one good in this country.

Sorry to be a curmudgeon.

I read your post, and overall it’s really interesting. I think the idea you’re getting at is (like other aspects of business) to reduce risk. Like you say, hiring programmers is tough and humans are complicated. Maybe another approach is to look at quantity over quality. That’s the whole idea behind continuous integration, right? Keep gathering information and make changes as necessary. The process you’ve suggested is really time and resource intensive. Imagine coming up with, supervising, and evaluating audition work, in addition to finding applicants, coding tests, telephone screens, resume reading, etc. It’s a lot of work for everyone involved.

Now imagine you need programmer(s) for a project. Hire the first candidate that meets some very minimal requirements (passes FizzBuzz, has required experience on paper, seems friendly and personality matches). Hire them on a contingent basis (ie you can be dismissed for any reason within the first 60-90 days or whatever, like in Ontario) and go. Repeat as necessary. You may go through a bunch of applicants, but that’s why the process is minimal; avoid cost but keep valuable information. You can change your requirements too. “Maybe looking for C++ devs isn’t what we really want”. “That question about why manhole covers are circular does seem to be a crappy question”.

Just throwing out ideas, but I have a sinking feeling that this approach might work better in some settings than what places do now.

I read most of your posts, and normally agree with you - but I think you’re way off here.

Let’s say I’m a good candidate. A great one. Maybe the best. Your company want me to jump through these silly little hoops for weeks trying to prove it. Company B looks at my resume, calls me in for an interview the next day, calls a few of my references right after the interview and makes me a good offer by phone which I’ve accepted before I even get home. You’ve lost me.

This is not hypothetical, it’s happened to me a number of times.

The only people left in your recruitment process are the guys and girls who aren’t being snapped up by your competitors. You have lost.

When I’m recruiting, I do it based on one interview in which I need to see some code the candidate has written and have him/her talk me through it and answer questions in a way that convinces me they wrote it themselves. That’s enough. If they suck, or they cause trouble, or whatever - then it’s obvious within the probation period anyway and it’s easy to get rid of them.

Under #4 (the phone screen section), I ask several of the exact same questions!

I suspect we have a common source in Mr. Steve Yegge: http://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions

To follow up on my previous comment: Ah, Jeff, I see that you do link to that same Steve Yegge post in your Getting the Interview Phone Screen Right article (http://www.codinghorror.com/blog/2008/01/getting-the-interview-phone-screen-right.html).

While I agree with some of the posters above that this interview process is very specific a certain type of programmer and a certain type of business… I’d love to encounter it. Sadly, my resume rarely makes it past HR, let alone to an actual skills assessment of any sort. Almost every time I’ve ever coded on a whiteboard or multiplayer notepad I’ve gotten an offer. For some of us, it’s getting that far that’s the problem.

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.