Today a lowly programing peon fails a devious whiteboarding interview torture trap! After candidate leaves, the interviewer asks their colleges, “why are there no good programmers available?”. Well…

Recently I’ve heard two common complaints, first from companies looking to hire not finding talent, and the second from programmers looking for new jobs only to find a degrading, demoralizing, and difficult interview process (re: @bascule's "Can you solve this problem for me on the whiteboard?"). If you don’t think these two trends have something to do with one another, think again.

I’ve been interviewing a fair bit since the Gowalla announcement. While I don’t mind the psycho-crazy-double-link-list-recursive-binary-tree-fizz-buzz-sorting-matrix-manipulation—whiteboard questions, they’re not my favorite. In fact, they’re no-ones favorite questions. Instead I appreciate interviews that focus on the position I’m applying for and have done adequate research into my background. As a general rule of thumb if you’re an interviewer, don’t as me a question that you wouldn’t mind me asking you.

Interviewer: “Do you have any questions for me?”

Me: “Yes! Given a singly linked list …”

If I did that to an interviewer they would think I was joking or be offended. Why would I not think the same?

So we all agree, whiteboarding questions aren’t the holy grail of interviewing techniques, instead here are a few things companies have done that I prefer and feel they gave a greater insight into how I would perform on the job.

Pair Programming

The first alternative, is pair programming. Pick a real problem, it can be open source, or it can be from your code base, as long as the interviewer and the candidate can understand and work on the problem in under an hour (or more depending on the length of the interview). Why do I like this method? It shows how I really work, and answers quite a few questions about how the company works. We get to have a real conversation about a real problem using real programming tools and hopefully do some real work. Doesn’t that sound great? But there are some down sides to this approach. This will require quite a bit more work on the interviewer’s side to pick a problem that is appropriate and short enough. It can also be easy to accidentally allow this technique to degrade into “pair whiteboarding”, which still misses the point. I think the effort is worth it. If a company can’t take the time to find a decent problem they probably won’t take the time to help me grow in my career.

Projects

My second favorite alternative, is a project. Only two companies I interviewed with asked for projects, though I’ve decided to accept a position with one of them (details coming soon!). Again the project should be related to the job at hand and not simply a take-home whiteboarding question. This allows the candidate to use their every day tools and resources- hello API docs - to produce code like they would be committing to your repo. It doesn’t even have to be coding based. It could be a presentation on a potential feature, or filing a bug report, or anything you want. The downside is the same as above, coming up with a meaningful project is harder then regurgitating the same questions we were asked out of college. But it is very rewarding to see someone’s true potential. A word of note, don’t use this to “weed” candidates out, programmers don’t have infinite time and the last thing we want to be doing is doing projects for a company that won’t follow up with us. Time box the project at 1~2hrs if it’s early on in the process, or more if its later in the interviews and you are really serious about the candidate. If you ask for a project first, don’t do whiteboarding later … that’s just redundant and disrespectful.

Brainstorming

Pick a question that the company has run into in the past or is currently facing and start a brainstorming session. Use this to see how the candidate approaches problems and leverages those around them for more information. In this scenario you’re deliverable is not run-able code but a solid understanding of the problem and at least one potentially viable solution. Make sure the interviewer isn’t just grilling the candidate and that it’s a joint session. It’s easy, it’s fun, it’s collaborative, and it’s useful. Feel free to use this with any other methods listed.

Work to Hire

I’ve never had a company offer this to me. Though I’ve worked for one that offered it. We gave a guaranteed six months full time work with a full-time offer by the 5th month if there was a good fit. It was nice for both parties involved because it gave enough time to let the honeymoon period wear off and see if there was a mutually beneficial relationship. The upsides are great, “have your cake and let it go if it doesn’t work for you too”, but there are some major downsides. Your team will lose productivity bringing new hires up to speed, and while this task should become easier over time, hiring a number of people just to let them go, is not a great idea. If you have a truly great candidate, you might lose them to a full-time job offer. That being said I would rather get a work-to-hire offer from a company then no offer at all.

Above all Else

Programmers: Ask what interview tactics a company uses early on. Suggest an alternative that you like from above if they whiteboard. Don’t be afraid to call out an interviewer on an irrelevant question, or at least ask for the motivation behind that question. Having a firm understanding of what the company wants will help you put your best foot forward.

Interviewers: Decide what qualities you’re looking for before a candidate comes to your office. If you care about team culture, leadership abilities, specific programming abilities or skills, then make sure the interview process reflects those values. Better yet, be up-front with the candidate. If you’re a large company and you will only accept PHD level fortran programmers, then say so. Also don’t expect a philosophy major with 7+ years of python to give you big O notation of every sort algorithm off the top of their head. Expect them to do python. Please read up on a candidates background and ask them specific questions related to your values before bringing them in. If you must whiteboard, explain why and what you’re looking for, be honest. Remember everything you do, says something about your company.

Good luck and happy interviewing.

If you have had a good experience with a interview method not mentioned here, or a useful comment, drop me a line on twitter @schneems or richard-AT-gowalla-DOT-com. Though be prepared to answer grueling series of programming questions before getting a firm reply ^_^