Ahh, the infamous coding question. The very idea that a candidate might be asked to code during an interview caused some furor among commenters to a recent post by my colleague Dawn Kawamoto. I thought I'd provide a hiring manager's perspective. Confession: I ask at least one coding question of anyone who will be writing code. Here are the two major points you should know about it.

It's Not About The Algorithm

It's about solving a problem, not implementing a pattern. I ask a coding question to see how you solve problems. Depending on the job you're applying for, using some known algorithm might be the right approach, or it might not. What I really want to see, though, is whether you get to that algorithm. After all, algorithms and patterns are generally relatively easy to find. There are libraries that implement many of them, and there are textbooks that tell you how to accomplish them in numerous languages. The hard part is knowing when it's right to use a particular pattern or algorithm. This means that the coding questions I ask won't be, "Can you write a quicksort algorithm?" Rather, I'll ask a question like, "We're doing a project involving language analysis and want to look at phrase frequency. Can you write a utility that takes a list of phrases and orders them according to how frequently they're used?" A good answer will probably involve using a quicksort implementation. But what I'm most interested in is whether you recognize that. I'm looking for things like how you structure the code, how you approach the problem and what patterns you choose to apply. Unless this is a job where you'll be implementing algorithms, then you're welcome to actually perform the quicksort by calling qsort() or equivalent.

It Matches Your Job

Second, the question matches the work you'll do. If you're getting hired as a front-end JavaScript/CSS engineer, I don't think it's relevant to ask you how to work with b-trees. If you're being hired to work on indexing and big data parsing, then I'm not going to ask you how many piano tuners there are in the U.S. (OK, I'm probably not going to ask anyone that!)

Why We Do It

I think it's fair to find out how you think in ways that will be relevant to your job. For example:

• For a front-end CSS designer: I hand the candidate a picture of a three-column layout and say I want lines between each column that extend to the bottom of the page. This is a problem that calls for equal-height columns using CSS — a common pattern with a number of solutions, some more liquid than others.
• For a job requiring a lot of data parsing: I ask the phrase-sorting question above. Candidates who specify a bubble sort, or fail to consider that at high volume the sorting algorithm matters, are probably not going to do well.
• For a job building a website that takes in data from users: I ask a question that boils down to needing to sanitize input data. Knowing that it needs to be sanitized is the first hurdle. The second hurdle is doing it in a reasonable way.

None of these questions breaks new ground. They're all problems that have been around for years and that continue to be problems. No tricks. Just questions. Do you see why managers use these questions? Tell me in the comments below.