Posted by kschaefe
on August 13, 2009 at 7:56 AM PDT
More thoughts on my recent job search. This time focused on technical questions.
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?