Skip to main content

Job Search: Technical Questions

Posted by kschaefe on August 13, 2009 at 7:56 AM PDT

The other day I posted some initial thoughts from my recent job search. Today, I wanted to talk a bit about technical questions. The questions I faced during my interviews (or before in timed tests) ranged from the obscure and puzzle-oriented to the practical and useful (albeit short). So, I've picked two questions to review to talk about what I liked and what I didn't, hoping to find out: what makes a good technical question? Question 1: In the language of your choice (or pseudocode), write an algorithm to efficiently reverse a string. Let me begin by saying that I think this is a horrible question. There are only three categories of answers: no answer (you can't solve the problem), the typical answer (n iterations), and the optimal answer (n/2 iterations). What is the question actually attempting to test? Strings? Arrays? Loops? Computational complexity? Or my memory? My issues with this question stem from the fact that it is completely contrived. When is the last time anyone ever needed to implement such an algorithm (outside of CSC 101)? It is also completely googleable; I was able to find the optimal solution in less than 60 seconds on Google. Most importantly, how does this question differentiate the respondants? Is the developer that gives the optimal answer really better than the the developer that gives the typical answer? My favorite answer to this question (in Java) is: new StringBuilder(string).reverse().toString() Question 2: Create an ER (or other) diagram to model the following [business specific problem]. This was a paragraph-long word problem, describing a small world (that was relavent to the business in question). I absolutely love this question. What is this question attempting to test? Obviously, you're ability to create an ER diagram, but also whether you can model a problem accurately. What types of assumptions do you make about the problem in your attempt to solve it? How do you tackle it? Entities first or build as you go? What I like most about this question is that you cannot google the answer. It is possible to google ER diagramming, but are not going to be able to find the actual solution. Most importantly, it tests how you think and whether you really grok the ER modeling process. If you've read my previous post, or perhaps just from this one, you'll notice that I place a premium on thinkers and problem-solvers. Perhaps, my bias comes from working in small companies where you need to solve a problem today with a technology that you didn't know about yesterday. So, what are some questions that you've encountered? What do you think makes a good question? What makes a bad one?

Related Topics >>


For Q1, do you have to take 32-bit unicode code points into account? In a face-to-face interview this could lead into a discussion of performance vs accuracy (if we don't support 32-bit code points we can make a faster algorithm - is this a performance critical part of the system?) and I18N support. I kind of like this question now.

I understand you're point regarding the first question, but this question was asked in a face-to-face interview. The shortest face-to-face I had was a half-day with eight different people (some in groups). That has to translate into over $1000 of resources spent on interviewing me, not to mention that those resouces are not able to be productive on their normal project. Shouldn't that type of weed-out question come earlier (on the phone)? Or is it that important to distinguish between those who know the optimal answer over those who know the typical answer?

I understand the point of the first question is that many programmers can't get it correct, or struggle with it. Unfortunately there are many bad programmers out there. With this questions, some of those quickly get weeded out. Congratulations, you might not suck as a programmer. Now, you can get on to more refined questions. As for contrived, well yes. But then, day-to-day works tends to deal with mountains of existing code which is not suitable for interview questions. Being a good programmer implies that you should be able to do the first question. Sure we want the implication in the other direction, but realistically the question does a good job of narrowing down the problem of hiring, IMO.