(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Tuesday, November 28, 2006
Don't overthink the interview process
You’re sitting in an interview. The interviewer hands you a marker and points you to the whiteboard. “Please write a sort routine” she asks.
Now let’s assume you haven’t looked at sort algorithms since your undergraduate days. You sort in the database. Or you use a library sort. You are a firm believer that writing your own sort routine is a case of premature optimization.
I agree, you ought to point that out. But still… do your best to write a sort routine.
Why get into the philosophy of whether you should be writing sort routines on the job? Yes, almost everybody knows that you need to be thinking about other stuff most of the time. But the interviewer wants to know if you’re smart, and for better or for worse she’s selected a sort routine to see how you think.
Here’s my suggestion: do your best as cheerfully as possible. Talk through your code aloud. Ask a reasonable number of questions, enough to show you think through cases and requirements in more depth than the other 199 people who submitted a resume.
This is all to say that even if you don’t have QuickSort memorized (I don’t, and it’s two freaking lines in any language worth learning), there’s lots you can do to answer the basic questions “Is this person smart?” and “Are they experienced?”
Your goal is to show this off. Even if you don’t think the question is the best way to interview candidates, nothing is stopping you from using the question to demonstrate that you are smart and experienced:
(This was inspired by this discussion on Joel’s discussion board).
You’re sitting in an interview. The interviewer hands you a marker and points you to the whiteboard. “Please write a sort routine” she asks.
Now let’s assume you haven’t looked at sort algorithms since your undergraduate days. You sort in the database. Or you use a library sort. You are a firm believer that writing your own sort routine is a case of premature optimization.
I agree, you ought to point that out. But still… do your best to write a sort routine.
Why get into the philosophy of whether you should be writing sort routines on the job? Yes, almost everybody knows that you need to be thinking about other stuff most of the time. But the interviewer wants to know if you’re smart, and for better or for worse she’s selected a sort routine to see how you think.
Here’s my suggestion: do your best as cheerfully as possible. Talk through your code aloud. Ask a reasonable number of questions, enough to show you think through cases and requirements in more depth than the other 199 people who submitted a resume.
On one interview, I was asked to do a substring search. I did the usual routine, but I explained that there was a faster method. I couldn’t remember that it was Boyer-Moore, but I explained that it used lookup tables to advance more than one character at a time. I asked whether I should work out the exact routine as best I could. The interviewer was happy that I knew there was a faster way, and especially that I could discuss the tradeoffs of building a table against the size of the search space. I wasn’t asked to write Boyer-Moore, but I was offered the position.
This is all to say that even if you don’t have QuickSort memorized (I don’t, and it’s two freaking lines in any language worth learning), there’s lots you can do to answer the basic questions “Is this person smart?” and “Are they experienced?”
Your goal is to show this off. Even if you don’t think the question is the best way to interview candidates, nothing is stopping you from using the question to demonstrate that you are smart and experienced:
- Solve the problem as best you can;
- Add a disclaimer if it isn’t the kind of thing you think about all day;
- Use the opportunity to demonstrate your experience by exploring requirements, listing edge cases, or offering anecdotes from your experience.
(This was inspired by this discussion on Joel’s discussion board).
