Interviewing Programmers
Posted March 1st, 2003 @ 07:36pm by Erik J. Barzeski
A few years ago I interviewed with Microsoft and was asked to generate code on the spot - on paper - to solve some problems. It had been a few years since my last C++ class, and I was deeper into Objective-C at that point, so I found it a frustrating activity. I didn't have any of the code I'd written previously to copy and paste, I didn't have the Net, I didn't have documentation. I didn't even have a compiler to warn me of a silly mistake (missing semicolons, etc.).
I walked away thinking "why didn't they just let me use my PowerBook to write code?" or "why couldn't I just show them my existing code?" I'd printed out a bunch of it - and brought several of my projects - for that purpose. No programmer is ever asked to generate code on paper except in an interview, and so asking for someone to demonstrate that skill is, it follows, not a very good indication of real-world ability.
As I was reading through this article titled How to Interview a Programmer, I found this quote by Matt Gerrans:
I don't like when I'm asked to write a program that does X on a piece of paper. Don't ask the candidate to write a program on paper. That is a waste of time and sweat. People don't write software on paper, they do it with computers using auto-completion, macros, indexed API documentation, and context-sensitive help. They think about it, refactor it, and even rewrite it. If you want to see a person's work, ask them to write some small module or implement some interface before the interview and bring the code on a notebook PC or on hard copy. Then you can review it and discuss the design, coding style, and decisions that went into it. This will give you a much more realistic and useful assessment of a person's work and style.
I specifically did not brush up on my C++ skills before my interview, because that's like cramming for an exam. You may do better, but you may also confuse yourself. Trust what you know and demonstrate it. You may do better, and you may do really well (because you studied an example that you were asked about - you sometimes get lucky), but then you're likely to disappoint the company when you show up for your first week of work.
That being said, the interview still went fairly well for me, and I learned quite a bit. Microsoft is famous for their interview questions and brainteasers, and I got quite a few, but I was happy to have mustered through and shown some good thoughts.
However, the Microsoft interviews differed quite a bit from the interviews I've had with Apple. With Apple, interviewees are much more likely to ask you personal questions (not too personal - just "what is your favorite movie, and why?" type of questions). Almost any topic can be analyzed, and so asking simple questions that don't require unreasonable or impractical feats (writing code on a piece of paper) perfectly well showcases an individual's mental capacity.
I thought I had a bit more to say about that, and I've interviewed no less than twenty or thirty developers myself for Freshly Squeezed Software, so I've seen it from both sides, really.
Hmmm, so much for an . Try this one on for size: The End.
Donate Life
Posted 01 Mar 2003 at 8:59pm #
"No programmer is ever asked to generate code on paper except in an interview, and so asking for someone to demonstrate that skill is, it follows, not a very good indication of real-world ability."
Maybe. But you must remember that for Microsoft it is probably not as important to hire every competent person they meet as it is to make sure that no incompetent people are hired. If you can't write code on paper, that doesn't mean you aren't competent, but if you can write wizardly code on paper, then you very likely are. Microsoft can afford to turn down people that they "should" have hired in order to make sure that everyone that they *do* hire is up to snuff.
Posted 01 Mar 2003 at 9:48pm #
I interviewed with Amazon.com once and had a very similar experience. I was asked to write a program to calculate fibonacci numbers. I gave them pseudo-code, but I think they really frowned on the fact that I didn't produce perfect Perl code right there on the spot.
I had the same reaction as you: such a request is ridiculous. In my normal programming environment I have access to technical books, API documentation, a compiler, and my own library of past code (so I can remember how I solved a particular problem before). The fact that I knew how to solve the problem generally should have been good enough...
Posted 02 Mar 2003 at 10:22am #
Eric-with-a-C has some commentary on my previous article on interviewing programmers. I also had a conversation with Jeff after I posted my article. I want to refine my point of view....
Posted 02 Mar 2003 at 11:55am #
I've interviewed a lot of programmers in my time and I suck at the technical side of the interview. This is why I quickly identify a pitbull in my organization -- this is someone who is more than willing to ask the complex questions that most folks are unwilling to do.
The pitbull is specifically instructed to not ask programming questions because of the reasons above... you're usually set of supporting tools aren't there... besides... really... when is the last time you wrote NEW code as opposed to STEALING someone else's and adapting it?
The pitbull asks abstract questions which force the candidate to demonstrate their structured thinking. WHO CARES if they can program in Perl/C++/Python... can they take a problem apart and psuedo-code a solution?
You can't fake thinking.
Posted 02 Mar 2003 at 6:27pm #
Interviews
When you get right down to it, I agree with Eric and not with Erik B., who has two separate
Posted 07 Mar 2003 at 5:18am #
News Roundup
APPLE Business 2.0 What Works: The Floor Plan With a Plan - "Retail design guru Paco Underhill explains the little
Posted 28 Apr 2006 at 12:11pm #
Interviewing programmers
Erik Barzeski has some interesting commentary on interviewing programmers, which was largely inspired by an article entitled "How to Interview...