Fog Creek Software
Discussion Board

Bringing Code Samples to Interviews

I have heard anecdotes about people bringing code samples with them to interviews.

How does this work?  Has anyone done this or been wowed by a candidate who has?  Any advice or stories that you can share?

I am proud of the work I've done, and I want to clearly communicate the scope of my contribution.  But a method or class in isolation doesn't necessarily tell you much.  Good code is often boring code, as the need to do something "tricky" usually means there's a better way.

I've thought about making some kind of a portfolio of the stuff I've written, with background description, DB schemas, diagrams of the general flow, etc. to help get a discussion going during the interview and to save time re-drawing them on a whiteboard.  Is this overkill?  Should I just work on a quick verbal summary of the project I can rattle off, and go practice the questions at instead?

David Carlson
Monday, November 25, 2002

At my last interview (at which I got the job), they asked for a code sample of 100 lines. of code. After some thought, I decided to submit what was essentially a whole class (albeit a small one) - edited slightly so as not to disclose company secrets and a small snippet of windows code.

I feel the point is to show consistent variable naming, function naming, parameter use and so forth. In C or C++ you probably want to show you have plenty of pointer skills.

Mr Jack
Monday, November 25, 2002

It goes both ways, code samples.

I have bought in slightly bad ones (complex errors only) and used them to determine if the people who read them know what they are talking about.

If they say that the samples are good I talk up my rate.

Otherwise, if they pick up the flaws I know I am talking to peers.

Monday, November 25, 2002

I remember one guy I interviewed brought in about 50 pages of code samples (most of it generated by the ATL wizard I might add).

I had a leaf through it and found a bug and then showed him the code and asked if he could work out why it was a bug. Very revealing. I think it was more useful to see his reasoning process and understanding of the code than if he could churn out hundreds of lines a day.

John C
Monday, November 25, 2002

Some questions related to the subject:

Is it a good idea to make CV references to my Open Source projects?

Is it good idea to mention during the interview that I paricipated/created in Open Source projects?

I can think of a situation when such a reference can actually make negative result - guys (usually human resources people) in a company which develops mostly for Windows will look on my Linux project, say "Ok, this is a Linux geek" and send my CV to the /dev/null.

Monday, November 25, 2002

Yep.  Anybody that mentions /dev/null metaphorically is a linux geek and the HR folks would have been justified in sending your resume to the 'recycle bin'.

Monday, November 25, 2002

My previous employer asked prospective interviewees for a code sample and a writing sample.  These were read and evaluated by technical staff before the candidate was brought in for an interview.

My current employer asked for code samples, but I just brought them to the interview rather than sending them in advance.

DeMarco and Lister in "Peopleware" recommend using code samples to evaluate employment candidates.  I think it is a good idea, but there are some problems with it.

The biggest problem, for the interviewee, is to have code samples available.  Code we are working on for our employer is often proprietary. I tried to get permission to use some code listings from my last job, but was denied.  All I could find to use was a little Python script, but it turned out to be adequate.  You may want to build up a portfolio to have something available when you need it.

Be careful about what you use.  At my employer that asked for samples in advance, the reviewer was supposed to check to be sure that the sample wasn't proprietary code that the candidate wasn't allowed to give out.  If it was, the sample was returned and the candidate immediately dropped from further consideration.

Monday, November 25, 2002

Mr Jack has it right. We ask for code samples, and what we are looking for is good coding style. This means easy to read, consistent variable naming, well laid out, no devious tricks when they are not needed. Highly complex code would have been less useful to us, unless we could tell that the complexity was absolutely necessary.

It doesn't necessarily have to be  code from work. We would take home project code as long as it was professionally written, and a few hundered lines is fine. We don't have the time to look at more than that anyway.

David Clayworth
Monday, November 25, 2002

Asking for code samples is a waste of time. It is almost impossible to determine if the code was written by the submitter. Unless they do something stupid like submit a code sample that you know is floating around on the internet and claiming it as their own.

Better to have them write som code for you as part of the interview. That way you know it is their code.

Ichabod Crane
Monday, November 25, 2002

Having candidates write code during the interviews is probably the best way to gauge their code-writing skills, although there will be people who are so nervous in an interview that they may do poorly here.

Code samples have been more useful to me in the pre-interview stage -- some candidates have provided some really awful code.  One of them got hired to replace me, but I didn't really have much input in that process.  Someone else provided a decent sample I could read, made it through the interviews, and turned out to be one of the smartest people I've ever worked with.

Another alternative to bringing code samples is to do a quick demo of an existing app -- although this may not be possible for developers who've been working on proprietary apps.

Monday, November 25, 2002

"Is it good idea to mention during the interview that I paricipated/created in Open Source projects?"

Depends on the job doesn't it? If you are scared of upsetting people in a more "button down" environment then you might consider if you'd be happy there anyway.

If you do want to submit that work and are worried then how about not bothering to shout about it being "Open Source", with capitals and all, and just talking about "a project I worked on"

After all, if I wanted a politician I wouldn't advertise for a programmer.

Robert Moir
Monday, November 25, 2002

My current employer gave me a sample exercise to code up and send in before they agreed to interview me.  Sadly, they stopped this practice and as a result at least one developer who never would have passed muster ended up being hired.

I appreciated the fact that they challenged me.  It made me want to give them the best damn code I could write, and I did.

Now, as far as asking for examples of past work, that may not always be possible due to the fact that your employer owns whatever code you write.

Monday, November 25, 2002

For my first job I had to submit a stool sample.

Mmmmmm.  Food service.

Nat Ersoz
Monday, November 25, 2002

Nat, I've eaten there.

Must be a manager
Tuesday, November 26, 2002

Unlike Mr. Crane, I don't care if the applicant is also the author of the code sample they bring to an interview.

If applicant walks in with, for example, Herb Sutter's exception safe stack implementation, that's a pretty good sign that (a) applicant can recognize good code (b) applicant learns from good sources.  If the applicant can then (c) explain the code intelligently - well, what more were you hoping to get out of that portion of an interview?

Tuesday, November 26, 2002

"My current employer gave me a sample exercise to code up and send in before they agreed to interview me. "

In my opinion, there is no better way to test a candidate’s aptitude. The way they solve problems tells you a lot, even if they just search the internet for the answer. You get to see how they code, how they think, and how they apply solutions to problems. Just make sure the questions don’t require a lot of domain knowledge. They should be general enough that anyone could answer.

Printed code samples don’t tell me much. They show that they can write well formed code, but that is about it. And as someone said, you have no idea if they even wrote it all.

But the big one; “Coding at the interview is BAD”. You’re asking people, who are naturally nervous, to snap themselves into the “zone” on command. It flies in the face of everything else Peopleware says about management. Its hypocritical to say that your developers work best in a state of “flow” and then turn around and hire based on ultra-pressure coding in an unfamiliar environment…. Can you tell I didn’t like this section of Peopleware yet? Just please, don’t do this to people.

Tuesday, November 26, 2002


Shouldn't you ask the prospective candidate to atleast show a bit of what his primary job would be?

Prakash S
Tuesday, November 26, 2002


You're not asking them to produce ultimate code. You're asking them to solve a small and simple problem and looking at the steps they take and the way they write. More importantly you are in a position to spot mistakes in their code and see if they understand them.

Of course, it's not equal to seeing what they can do under good work conditions but it's still far, far better than not making them code at all.

At the interview for my current job, I was shown a peice of code and asked to find problems with it. That seemed a pretty good interview exercise.

Mr Jack
Tuesday, November 26, 2002

History has shown that no matter who you hire, you will need to have some ramp-up time. This can take anywhere from six months to a full year (some industries are even longer). Many people advocate hiring the best “thinkers” over those who have the most domain knowledge because teaching someone about your domain is a lot easier that teaching someone to “think” correctly (I would argue its impossible).

I send a candidate a sample database and some sample code. The sample code is a small application (two windows with menus) with limited functionality. I have them add the following to the application:

1. Produce a report that calculates the average sales for each customer over a specified date range. The report should be run from the “Report Menu”.

2. Add an email address field to the customer table. Add this field to the customer editor interface.

3. Add the ability to send an email to the customer’s email address.

4. Add the ability to export the list of customers to a file. Use any delimiter you wish.

Sometimes there are a few more, depending on who I’m interviewing. The goal is too see how they “think”. While I’m looking for specific things in their answers, there isn’t a single correct answer to these.

Tuesday, November 26, 2002

At our company, I ask prospective programmers for code samples in advance and ask them to write some code during the interview.  I will favor programmers who provide sample code that I can actually run.  In my experience, programmers who code for fun (and are therefore able to provide a non-proprietary working program) tend to be top performers.

Kevin Clary
Tuesday, November 26, 2002

[If you do want to submit that work and are worried then how about not bothering to shout about it being "Open Source", with capitals and all, and just talking about "a project I worked on"]

The use of capitals denotes that the application most likely uses a OSI certified license, such as the BSD license, and associates itself with "Open Source" movement as opposed to the Free Software Foundation's "Free Software" movement with it's strict adherence to the GNU license and philosophy.

It might seem like they are shouting but it actually serves a purpose to make the distinction. Quite interesting stuff I think.

Ian Stallings
Tuesday, November 26, 2002

Personally, I would never accept a job at a company that wanted a sample of my code.

To me, this speaks volumes about the focus at  the company and it's not good.

I've interviewed a number of people where I work now (some of them hired) and, quite frankly, I couldn't care less about any sample code they might have brought with them. The single most important thing I need to know is:

Can I work with this person?

If the answer is no, then it's not likely anyone else at the company would be able to either. And if that's the case, then who cares how talented they are?

Assuming they aren't complete sociopaths, the next thing I want to know is:

Is this person afraid to think?

Does the person have common sense and know when to use it? Again, if the answer is no, then who cares about their coding talents?

We've all met people in our industry who are quite talented but are terrified of thinking on their own. I don't want, or need, a person who I have to direct. I want someone who is going to contribute.

If the candidate is sociable and exhibits common sense, then there's a reasonable chance their work is of good quality. In the off chance it's not, you can train them to improve their work habits. No amount of training is going to fix an anti-social, cubicle denizen, no matter how talented.

Bruce Rennie
Tuesday, November 26, 2002

Here we ask people to code a simple file parser with some formatted output. It's generally not a bad idea, since you get then to ask them about what they're doing and how they're doing it.
Typically we start out with a file along the lines of:
orderNo, Customer,ItemNo, ProductCode etc..
and ask them to produce an output consisting of
Order No,

ItemNo1, Product1

Since we've historically been in VB land I would expect them to produce a collection of order Classes keyed by order number each containing a collection of order items

Whats interesting is how their code looks, if they've commented any assumptions (e.g. OrderNumbers always have the same customer)

The best programmers we've seen tend to validate the input data in some way, often writing two versions. A quick n dirty version first with a note at the top of the parse routine saying that it's not very good and assumes the data is valid (possibly listing a few duff cases), followed by a second version which they write adding bells and whistles in data validation and output options which they keep on enhancing until we interrupt them.

The really smart ones ask early what sort of a solution we're expecting i.e. should they parse it into a Jet database then use Crystal for output or should they parse into memory then output some other way.

It's not perfect, and I'm sure we miss candidates who don't perform well under pressure.

Under different circumstances when I've been interviewing for embedded systems programmers I've asked questions like:

Hand compile the following code into assembler (assume you're a VERY stupid C compiler with no optimisation)

void TestFunction (int x)

  int y;
  int z;

  printf ("x is %d x squared is %d x cubed is %d",x,y,z);

int main()
    return 0;

Good embedded systems folks will do this with a stack frame and put the parameters on the stack the right way round for printf, (Possibly producing an optimised version)
Typically bad (embedded) programmers just get this wrong. They'll use registers all over the place passing the parameter in a register, won't use a stack frame and generally show no sign at all of ever having debugged C code down at the assembler level.
If someone didn't use a stack frame a quick prompt asking them to do it using one often brings good results or a very blank face. Some good candidates miss the idea that I want a VERY stupid C compiler and that the code has been simplified for ease of compilation rather than so you can optimise it.

In terms of bringing in sample code, I'd rather look at a finished application than code samples as it gives us something to talk about (e.g. problems etc)

Peter Ibbotson
Tuesday, November 26, 2002

A popular alternative is to ask the applicant to debug some code samples during the interview.  This happened to me once; I was blindsided with programming problems at an interview.  Interestingly, though I think I did relatively poorly (I stumbled around a lot and couldn't answer some of the questions), the person interviewing me was a fabulous programmer who was undoubtedly studying *how* I approached the problem rather than my final answer.  I may not have arrived at the best solution instantly, but the steps I moved through illustrated my knowledge of the language and programming in general.  I was later offered the job.

Anyvay, this can be a reasonable alternative to asking applicants to code during or bring code samples to the interview.

Brent P. Newhall
Tuesday, November 26, 2002

>>> Personally, I would never accept a job at a company that wanted a sample of my code. <<<

I am currently working for my fifth employer and have had exposure, via contracts, to a few others.  All of them had some problems, but one stood out as being somewhat out of the ordinary.  It could just do a much better job of hiring good people and getting them to work together.  This was the place that requested code and writing samples in advance for job candidates.  I should be cautious about extrapolating that experience, but I would be concerned about accepting a job at a company that didn't want a code sample.

Unfortunately, that company didn't survive the bubble.

Tuesday, November 26, 2002

Some places use code samples to validate the hirer, choosing esoteric or narrow samples the hirer knows inside out, but which are not necessarily good tests. These places hire people from almost exactly the same types of environments and become stale.

Other places use an intelligent interactive approach, often using samples as a springboard for discussion. These places do a much better job of assessing capability.

Rate the hirer
Tuesday, November 26, 2002

We have easy ways to get round the problem that code sample might not be written by the interviewee. Firstly we ask them to talk us through it, and ask questions about it, so if they've just copied it from somewhere we find that out quickly.

Secondly we are mainly interested in what they think good code looks like. If they don't care about maintainability then they will produce sample code with no comments but lots of complex programming tricks in, because they think that's what we are looking for. If they know what good code looks like they can probably write it.

David Clayworth
Wednesday, November 27, 2002

If you apply for a job as a chef, you're going to have let them taste your cooking.  If you apply as a singer, actor, or dancer, you'll have to sing, act, or dance in front of them or at least show them a tape.  But corporations mistakenly think they can identify good programmers by asking them to talk about what they do rather than demonstrate it.

It is almost impossible to hire GOOD programmers on a consistent basis without seeing their code.  The typical psychological/personality-based interview questions really only test your ability to smooth-talk and BS your way around.  Sure, smooth-talking has its purpose, but that's barely 10% of what makes a good programmer.  Leave the political BS and smooth talking up to the managers and (non-coding) analysts.

If I were hiring programmers, they'd be subjected to a full (weekend) day of coding and related activities.  And of course, I'd let them know that beforehand and I'd pay them something for their time.

T. Norman
Wednesday, December 4, 2002

*  Recent Topics

*  Fog Creek Home