Joe Grossberg published an article yesterday called How Not to Impress With Your Code Sample. He’s got some great points about things not to do (i.e., leaving database passwords in the code). But I’ve been a developer for about six years now, and I’m still confused as to what should go in a code sample.
In the past, I’ve used code samples where I took a complex function and wrote up a lot of documentation and comments around it. But I never felt very happy. A new employer would see that I could query from 12 tables, but can’t necessarily tell whether I did so elegantly, concisely, or performantly. And besides why do I need to join Abstract with Registration anyway?
If I needed a code sample now, I’d probably take some code I wrote for a recent Ruby project, because good Ruby is elegant, easy to read, and trendy. I’d probably submit a code sample which says “I can write a search indexing plugin in 7 lines of code.” For many employers, this would have the opposite effect: “It’s nice that Ryan can write a 7-line class, but can he write a 70-line class?” And if they’re not up on the Ruby hype, the grammar of Ruby might make it seem like a toy language — should I just submit a code sample in Logo?
Additionally, I’m a tech lead at work, which means one of my job responsibilities is to interview prospective software developers on their technical background and skills. I’ve never asked for a code sample, because I don’t know how to evaluate it. Do I want to see use of the latest API, or someone’s personal implementation of a quicksort? (If someone sends me a quicksort, should I be impressed that they know how to think that logically, or disappointed that they reinvented the wheel instead of calling Arrays.sort()?)
I’m interested to hear what other employers have to say. Why do you ask for a code sample? What impresses you? As an interviewer, what should impress me?
5 comments ↓
My favorite interview example is having the prospective employee make a tictactoe game. It is very simple but shows how they think in software development. If they create it using objects/inheritance and nice logic, I know they are the one for the job. If they hard code each section you know they aren’t ready
Code Complete 2ed has a checklist for creating high quality routines (page 185).
It also helps to run your code through a code analysis tool, like PC-Lint for C/C++.
Basically, what I would want is to be left with the impressions that:
* this person is reasonably logical
* this person is reasonably literate
* this person is reasonably well-informed about the technology
* this person is reasonably professional
* this person is someone whose code I wouldn’t loathe maintaining
In the same way that I would want to get these impressions about their personality through the interiew too. Except #5, which becomes “this person is someone whom I wouldn’t mind working with every week for years at a time”
John: funny, I would think exactly the opposite, if someone already uses an over-engineered monster for such a extremely simple problem I don’t want to think what kind of creature he will produce when he has to solve a complex problem.
object-oriented design is the roman numerals of computing. — Rob Pike
One easy way to impress me is to include unit tests as part of the code sample.
Joe’s suggestions above are hard to disagree with.
Leave a Comment