On Programming Interviews

Saturday, April 17, 2010 :: Tagged under: pablolife. ⏰ 3 minutes.


Hey! Thanks for reading! Just a reminder that I wrote this some years ago, and may have much more complicated feelings about this topic than I did when I wrote it. Happy to elaborate, feel free to reach out to me! 😄


Lots of great things have been written on the subject of programming interviews, but since I'll be entering the workforce very soon, I've taken away a few notes on how I would like to conduct them in the future, having just run the job search gauntlet.

Regarding phone screens, I learned a lot from Steve Yegge's post on his process. To summarize, he believes the candidate should demonstrate some basic proficiency and understanding in five areas to get the on-site: coding, OO design, scripting/regexes, data structures, and binary. It's alright if the candidate struggles a little, but if their answer to 'describe a function to sort an array of integers' is 'Collections.sort(array),' you might want to think twice about bringing them in.

Another advantage of living in 2010 is that we can actually see some code during a phone screen: one interviewer had me use EtherPad while on the phone with them, and I would probably do something similar.

More generally, diversity in the phone screen process will help you eliminate candidates who can talk big in one or a few fields, but don't have (or can't form) a more complete picture of what's going on.

If the candidate makes it to on-site, I would extend the diversity principle, but probably ask a few questions not listed above (if they demonstrated that they can write a regular expression in the phone screen, they don't need to show me one on-site). Here you could look at another round of fun brain- warpers that Joel Spolsky points out: pointers and recursion. I would love to write out a few problems as he has that just show they can read/write programs that use these techniques.

Brain teasers are a contested form in the interviews, but I love them too. Well, good ones anyways. I would like a candidate who smiles when they know a puzzle is headed their way. They would be very hintable, so I'm not anticipating an 'aha!' moment. An example of one of these that I think would rock, comes from Skorks:

Write a quine, in whatever language you like (for those who don't know, a quine is a program that prints its own source code without reading itself).

Now I've written about it, I probably wouldn't use it. A risk you run with any type of programming question that is meant to challenge is that they've run into it before, or researched the standard questions before arriving. While there's nothing wrong with researching beforehand, you probably want to see the candidate think, not just what they can remember. For this reason:

A few more notes:

The only flaw in my plan is, with all the material I've mentioned, I'd probably need more than 45 minutes to get a feel for a candidate, and I doubt I'd be given more than that at a time. I'll have to find a way to resolve this ^_^

Thanks for the read! Disagreed? Violent agreement!? Feel free to join my mailing list, drop me a line at , or leave a comment below! I'd love to hear from you 😄