Almost two years ago to the day, I wrote an off-the-cuff article on my old blog entitled What not to ask technical people in interviews. Someone found it curious enough to post to Hacker News and I was flooded with opinions that were either for or against my assertions.

I'm now one of those people who are against what I did say to ask in an interview. Well, I'm still against what I was against back then... even more so, but, sadly, people still do it - ask pointless, esoteric technical questions when speaking with a programming candidate. Again, I'll reiterate that even if the candidate knows the answers well and can clearly explain why they know it, and how it can be applied to a project, it means squat.

So here it is. The one, definitive, all-encompassing list of 5 questions to ask.

How soon can you complete our programming assignment?

Of course, you must have a programming assignment, but I'll get back to that.

There are two things you really need to know to hire someone. The first of which is, "do you have the chops that you say you have, and are needed to work here?" How do you ascertain that? It's actually quite easy, and firing off pointless questions over the phone doesn't answer this question.

Think of how software developers work at your company. If it's like most companies, they are given concrete tasks to complete in the best way they see fit. The business defines a need and the technical team determines the best way to fulfill that need. Then everyone goes off to their desk, writes a bunch of code, has a few meetings here and there, a few beers may be split along the way, and in the end, there's some working product. So if you want to know that if a candidate can deliver in that environment, then give them that environment.

Yes, it does require some real work on your part, sorry.

No more using Google to find some random questions 10 minutes before you're scheduled to talk to the candidate and then performing a half-assed interview, at the end of which you have determined nothing of value, and then you offer your groundless opinion when someone asks you what you thought of the person.

Oh, you've never done that?

Look at your current work in process. What problems are you solving, what business needs must be filled, what products did you recently build? Take the answers to those questions, lock a team of three people in a room for a couple hours and develop a code base that you can publish to Github that will allow a person to try to solve the problem.

Do you build a lot of visualizations for reports? Pick one you've done recently, strip out all the really important code, and provide a set of guidelines for building out a solution.

Does your team write applications that manage drug tracking, or billing departments? Take your most valuable product, strip out all the important code, and lightly document what the purpose of the product is so that a candidate can attempt a solution.

Then when you have people who are interesting in joining your team, you give them the URL, give them an appropriate amount of time to complete it (half a day to a few days, depending on the complexity), let them know how to communicate with a team member, and then wait for their solution. That way, they can work on it much like they'd work on it if they were sitting next to you.

Some headphones, a cup of coffee nearby, a chat client fired up in case they have questions for you, etc.

That's what they'll be doing on a day to day basis, that's how they will provide value to the company, so evaluate them on exactly that.

How did you develop your solution?

Ok, they took a day or two, and now have some fancy code that they believe is a good enough solution to email to you. The candidate better be able to back it up, and you need to ensure they can put their money where their mouth is.

Face to face, looking at the same code, they need to clearly go through each module, each feature - or line by line if need be - and explain the code.

Just like a code review (which hopefully your team is doing). Provide feedback on what you think is good and what you think would need work, but at the end of the day, you need to objectively judge whether the code (1) solved the problem with sufficient coverage of your guidelines, and (2) is of adequate, professional quality to bring value to the team.

What do you want for lunch?

Ok, now on the the second of two things that you really care about.

Will this person fit in?

If you don't want to admit that part of it, that's fine, but that's what everyone who talks to the candidate is thinking either consciously or not. We want to work with people that we like and feel comfortable being around (or at least don't hate or get the creeps when the person is around).

So even if you didn't want to admit that it's what you're thinking, you need to. You are going to be around this person for at least 8 hours every day until one of you quits. That's more time that you spend with your family. You better be sure you want to work with that person.

So have them sit with some team members in the lunch room, buy them a deli sandwich or some pizza and just sit and talk. Doesn't even have to be all work related, just have a conversation. When a person's guard is down, even just a little bit, you'll start to see their real personality traits come through.

What questions do you have for me?

It's shocking how many people don't give the candidate the opportunity to ask questions about the team, company, work, etc. A potential teammate needs to be able to ask questions, and possibly alleviate their fears or uncertainty about working at your company.

When can you start?

If all the previous steps have not produced any red flags, you just need to pull the trigger. No need for three more meetings where everyone can hear themselves talk. Ask for a thumbs up, or thumbs down from everyone. If you have a quorum of thumbs up, send out an offer.

So there you have it, the list of questions you need to start asking. You're welcome. If you see me at a local conference, you can thank me with a beer or a coffee.

Seriously, though, with the high competition for software developers these days, you really do need to put in the effort to ensure that you bring on the best people to your team; ones that will provide immediate value and will be acceptable to work with. You can't afford to make a sub-par hire, and then go through the process again 6-12 months later when it doesn't work out.

When we switched to this model of recruitment, our quality of hires was immediately, and measurably, increased. It made it extremely easy to see who we wanted to bring on and who we would pass on. It had nothing to do with hunches, feelings or opinion (unless they passed the assignment phase, then it had everything to do with feelings and opinions).

It works! It really, really works!