The Programming Interview

I’m not a huge fan of the programming interview–on either side of the table. The signal-to-noise ratio for identifying successful candidates is frustrating. The programming questions that you’re asked to solve haven’t been real Computer Science questions for decades, and since Boyer-Moore nobody in their right mind has re-implemented strstr.

Even more fun is when these coding exercises are expected to be written on a whiteboard. For example, a question I was asked looked something like this: “Given matcher("abba", "red blue blue red"); implement function matcher(pattern, teststring) and return true if the provided string follows the pattern and false otherwise.”

You might, upon seeing this, immediately think it’s easy: you’ve got a space-delimited pattern. Split it up and compare!

That works, and then immediately you’re peppered with questions about how else you could do it, or what the complexity is. Calculating the complexity and speed is in most cases a distant third to the goals of “making it work,” and “making it maintainable.” The only relevant question, especially on the front end, is “does the JS frame in which this code is running yield in under 16ms for your use case?” The followup question is, “is this the tallest tentpole in that JS frame?” I’ll trade algorithmic complexity for ease of maintenance every time. We can talk about the “named” algorithms in that space once we realize it’s a performance bottleneck, but in building user interfaces with a budget of 16ms (60Hz refresh rate) that’s rarely necessary.

So maybe instead of taking advantage of the space-delimited matching, you recognize that this question is nothing more than a pretty interface to a regular expression. In order to meet the API design goals, however, you have to generate the regular expression, and then run it against the provided test string. You could cache the regular expression (the new RegExp(); call is the slowest piece of this code) but that is cheating. A simple version looks like this:

At this point you’ve managed to come up with two solutions for the problem, with varying performance characteristics. The regular expression builder you’ve written makes it easy to handle the next question you were inevitably going to be asked, “how would you do it if the test string weren’t space delimited?” But what if you came up with the regular expression solution first? Well, clearly you’re going to be asked to implement it without using a regular expression. The amusing thing about asking that question is that it is likely that the interviewer themselves has not implemented it without a regular expression. Much less have they come up with a solution on a whiteboard. But say you’re a masochist and have nothing better to do on your Saturday night in San Francisco with interviews bookending the weekend. You might write something like this in incredibly tiny print on the whiteboard in your hotel room:

And then you’ve got a solution that nobody can complain about, right? But realistically, that’s not the case. If you had somehow managed to write all of this code inside your single hour-long interview you’ll immediately be asked, “what are the remaining optimizations you could make to improve the performance? How could you make it more maintainable?” Easy: teach the original developer how to write regular expressions.

Here’s a performance comparison on JSPerf of these approaches. Amusingly, at a minimum of 78,000 operations per second, you’d be far more suited to optimize for function length over anything else if it’s being served as JavaScript to the client.

I don’t mean to pick on this question too much, but it pretty clearly demonstrates why nobody in their right mind would ever create a function like that. And I’m probably the only interviewee who has ever gone back and finished the problem as posed as an exercise in thinking through problems.

Toward Better Interviews

Please make your questions appropriate to the interview and to the job. Feel free to steal my favorite interview question for front end developers: “Implement debouncing in JavaScript.” It tests all sorts of wonderful things, all of which you use on a nearly daily basis:

  • Scoping.
  • Understanding of this.
  • Asynchronous behavior.
  • Prototype hijacking.
  • arguments “array.”
  • Binding.
  • “Currying.”

There’s a lot to discuss, and best of all it easily fits on a whiteboard at about 8 lines of code.

It takes more work to identify questions which directly apply to the work that you do while demonstrating mastery of skills. Invest time and energy into coming up with interview questions which strongly correlate with the how well an interviewee will do in the position.

I hope to ruin function matcher(pattern, teststring) as an interview question with this post. The first two answers are trivial, the last needlessly complex. The best part about the debouncing question is that, even if you can rote reproduce it, without knowing every one of the constituent components you can’t field questions on it. Go ahead and prepare for that question if I’m interviewing you–you’ll end up brushing up on a lot of the things that I’ll want to know you’re capable of in your day-to-day job. It’s a win-win.