On hiring good engineers

An interview with a Google HR person was brought to my attention. Apart from the fact that Google dehumanises their employees by calling this area "People Operations", the following quote was interesting:

On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.

This seems fairly obvious to me, but technical candidates will probably have to live with this bankrupt assessment method for a while yet.

I have done my fair share of interviewing; I am not an HR professional, but I am often called upon to assess the technical side of candidates. I'm fairly happy with my hit rate, and since it is quite simple I will share some of it here. It's worth noting, this probably only works for vacancies up to intermediate levels of technical depth. It worked well for me at Ramboll Informatik, it worked well for KMD, it worked well during my time with the Grameen Foundation and with IT Synergy. I don't think it will work well if you're hiring for a position requiring a very vertical and deep skillset.

When speaking with the candidate, I rarely take more than fifteen to twenty minutes. This is partially because there's a lot of other non-technical people who want their slots in the interview process (sigh); it's also because it doesn't take a long time to spot a candidate who has the right mindset.

Mindset over CV.

Since fifteen minutes isn't a long time, I can't waste time on questions like "how long have you programmed in C#" or "what kind of classes did you do at university". And since every single job description ever written comprehensively fails to describe the job in any meaningful fashion, it's a safer bet to hire someone who can do the job described but who won't break down if it turns out that the new DBA hire also needs to know how to tune hardware.

A simple approach to interviewing doesn't deserve a long blog post. I ask questions which reveal the professional inquisitiveness characteristic of problem solvers. The questions are mostly freeform, and they do not require paper and pencil. The questions are hard to impossible to prepare for, and in most cases the specifics of the candidate's answer matter less than the way the answer is delivered. How long the answer is, the degree of animation, articulation of clear opinions.

Here are some of the questions I ask. I have annotated the first few to illustrate intent.

  • In previous projects, what technical limitations did you work under that you wanted to change thereby improving the quality of your work? - Here we're looking for a combination of two things: diplomacy, and an individual sense of what good engineering is; not just a knowledge of corporate guidelines and methods.
  • When is it a good reason to use non-current software versions, for example as developer toolchain or libraries? - A lot of engineers will fall back to stories about corporate standards or licenses forcing obsolete versions. Some will consider more interesting aspects like API changes. A few will tell stories about terrible library updates that they felt were detrimental. This type of question is good for getting an impression of the engineer's experience and independent judgment.
  • What is hard about working in a team of 2, and what is hard about working in a team of twelve? - Good question for provoking stories. Stories are always good.
  • When you first learned to program, what was the most difficult thing to understand? - Same as above; added benefit, it improves the conversational nature of the interview. I always lead with a story about how C pointers always drove me up the wall.
  • Have you ever picked up a project that was in maintenance mode, and not to be developed from scratch? How was this different? What made it easier, what made it harder?
  • Exposure to other languages and operating systems? - I am looking here for professional inquisitiveness. I find this to be sine qua non. Google helps a lot here also.
  • Have you ever seen code in a system that you could see should have been split off in a module and vice versa? What is too little modularisation and what is too much?
  • Tell us a little about the best designed source code you ever saw and also the worst.
  • Ever done web development? Tables vs divs. How do you feel about using either for UI layout?
  • Why do you think an Oracle installation is so many Gb when a postgresql or myqsl installation is only some megabytes? Why the huge footprint? Why is Outlook so big compared to say Thunderbird or Eudora?
  • Say you have a db driven web UI system with many users. It does a lot of complicated things. There's a bug. When a user sometimes enters a value in a specific box and clicks OK, sometimes it gets written to the database and sometimes not. They cannot reproduce the problem but you know it's real and not imagined. How do you proceed if it's your responsibility to get it fixed?
  • If you could make all programmers follow one good practise or change one thing about how they work, what would that be?
  • If you have to hire a programmer and you have too many applicants to interview, what question would you ask them to exclude as many as possible as quickly as possible?

A little practical note: this is a list I accumulated over a period of time. I do not ask all of these questions in one interview; there is usually only time for 3 or 4 in one fifteen minute slot. But that is often enough; at least at the level at which I have had experience conducting technical skill assessments.