I've seen a number of questions since I've been here where, in the answer, someone has asserted that they would never use portfolios or code samples coded outside of the interview process to judge a candidate, because there is a possibility of that code having been written by someone else. I find myself surprised by this.

The way I see it, if I ask someone to come in and solve a simple problem on the spot, there is very little I can learn from it. I don't work for a company like Google where jobs are sought after and I can demand a day of someone's time. But a substantial piece of hobby-written code can tell me a lot.

Yes, there is the possibility of plagiarism, but they're going to have to be very well coached to get through an hour long discussion about that code. And should that be the case, they'll have to be very quick learners to get through their 3-month probation (during which I can get rid of them with no reason and with no notice). If they become good programmers that quickly, fair enough, I've been duped, but I still have a good programmer.

In the end, the cost to our company and the benefit to the candidate of plagiarism is very minimal.

This got me to thinking about other industries. Artists, photographers, designers all use portfolios and nobody worries too much about plagiarism there. An author will get funded for a book based on chapters he has written in his own time. You wouldn't ask an architect to come in and draw design specs for a house at the interview.

So what makes us different? Why is it so important to put someone in front of a computer and make them code up a data merge or a factorial calculator, sometimes without access to the very tools we use day-to-day, like the internet? What is wrong with the idea of a code portfolio?

I'm genuinely interested to know, in case I am potentially making a huge mistake which just hasn't burned me yet.

5 Answers 5


My objection to a portfolio has nothing to do with the risk that the company gets duped by someone that is copying code from the internet or, more likely, passing off code written by a team of developers as their work. As you rightly point out, you can learn at least as much by having a developer talk about a project they're generally familiar with for an hour as you can by having them code a factorial calculator from scratch.

My objection to a portfolio is that requiring a portfolio eliminates many talented developers from consideration. Since I, unlike an artist or photographer, don't retain copyright to the code I produce-- it belongs to my employer and/or to the firm that contracted with my employer-- I can't show the vast majority of the "interesting" code I've written. If I'm coding on my own time, it's generally going to be a side project at work that makes my life easier or that just bugs me which again I'm not going to be able to show in a portfolio. I've got tons of posts in various forums, but most of those are, by design, relatively shallow. There is a pretty substantial population of solid developers that are in a similar position-- their interesting code is owned by someone else. And if you're not a top-tier company, you're missing out on the solid developers that are happy to come in, work hard for 8 hours, and then head home to be with their family rather than developing for fun outside of work.

A technical interview where all candidates are asked to code something from scratch at least provides a level playing field. Assuming that you do a reasonable job of doing the phone screen and that you can narrow the candidates down to a reasonable list, I'd much rather as a candidate be given a problem to solve that you know is going to take 8 hours of effort than to come up with a coherent portfolio of toy apps that have no copyright problems.

  • 1
    +1 Good answer. Follow up question: if I ask for a code sample, what prevents the candidate you describe from choosing to spend 8 hours solving a contrived problem of their own, rather than a contrived problem of my choosing? I would respect that a lot.
    – pdr
    Mar 24, 2011 at 0:03
  • 3
    A common, contrived problem like a specific Project Euler problem should get you better results and be more considerate of the candidates than having candidates come up with their own problems. It's kind to the candidates because there is a well-defined stopping point-- no one is going to feel pressure to spend gobs of time polishing a UI or adding "one more feature". It's better for you because it's far easier to compare candidates when they're solving similar problems. Otherwise, it's hard not to be influenced by who had the coolest idea or whose visuals were best. Mar 24, 2011 at 0:22
  • Granted, having code samples is a more reasonable expectation for a client-side web developer, but the best interview format I've ever encountered consisted of sitting down and looking at code that I'd written, sharing thoughts on things I liked, wished I'd done better, etc... and then looking at code that the interviewing devs had written and doing the same. Much more value to both parties than a firing-squad-style interview, IMO. Google's acceptable-false-negatives approach is the reason I wouldn't want to work for them. It's clumsy, inelegant and wasteful. Just like their JavaScript. Jun 22, 2013 at 17:11

First of all, we are engineers, not artists. We work in a team, so in our real work experience, "our" code is often the result of teamwork, because that's how real work is usually done. There is not that much professional code I could claim sole ownership for.

Second, most code in my hypothetical portfolio would be code I could not show to anyone, because it is confidential. Code I've created for my personal pet projects doesn't necessarily reflect all of my skills and my typical work behaviour.


I have interviewed a lot of people during my time as a software practitioner. I have reached a point where I believe that quizzes and toy programming assignments are a waste of valuable bandwidth. Quizzes and toy programming assignments only serve to test what the interviewer knows. They are not an accurate way to gauge what a candidate knows. At this point in my career, I only accept this type of nonsense if, and only if, I am given the opportunity to administer my own test at the end of the interview.

The best way to assess a software practitioner's capabilities is to talk to him or her in a calm reassuring voice. Ask the candidate to discuss what his/her current position entails. When the candidate brings up an area of interest, ask him/her to elaborate on that area. The goal here is to get the candidate to let down his/her guard. No amount of coaching can prepare a candidate for the "soft touch" interrogation. Sooner or later, the noose is going to tighten around the neck of a candidate who is trying to BS his/her way through an interview.


I do ask for code sample for applicants and it does get referenced during the interview. However I usually give more weight to the whiteboard coding done during the interview.

Every developer interview I do involves going to the whiteboard to implement the solution to a simple problem. However, there are rules:

The applicant has to talk through the implementation as they are doing it.

  • I can gauge how they approach a problem.
  • I can see how well the can communicate.
  • I can gauge how fast they are with a clear target.

I have three problems whose implementations are all similar and I let them know they can reuse or refactor the code they've written.

  • I can see if they can pull back to take a look at the bigger picture.
  • I can see if they implement and refactor, or jump to generalizing.
  • I can get firmer idea of how well the order their thoughts.

The point of all this, of any interview is to try and get a good idea of the applicants capabilities and how they may match up with the job. The "practical" portion of the interview in my experience has helped quite a bit in that respect. It also helps me evaluate the sample code because I know that much more about the way the program.


A code sample is a pretty efficient way of weeding out candidates - I can judge a code sample in 5 - 10 minutes, but even a phone screen takes 15 minutes and needs scheduling (and isn't terribly useful in weeding out anything but the very bottom of the pile in my experience).

I think the main objections to code samples are two fold, and are easily overcome:

  • that requiring a code sample puts up an artificial barrier for some talented developers

Obviously, this is true. Any barrier in the application or hiring process may potentially weed out a desirable candidate. The important thing here is to know your audience - if you have 1000 resumes for your one opening, you can afford some false negatives in service of efficiency. If you have five resumes, you can afford some inefficiencies in the screening process.

What I think most people miss, though, is that interviewing and hiring is basically a game of "find a reason not to hire this person". For any decent job, there's a lot of qualified applicants - the last one standing is usually the one that didn't set off any red flags along the way. It's easy to see the best in people or be non-committal, but that doesn't do you any good in hiring because you'll end up with 10 different candidates that you're comfortable with. That doesn't get you any closer to a decision.

Every tidbit you collect along the way of reviewing, screening, interviewing, etc. could potentially trigger a no-hire decision. You have to balance the sensitivity of your no-hire trigger with your current (and potential future) prospects. If you're in a boring industry, with lots of legacy code, bureaucracy and poor salary (often things out of your control) then your trigger needs to be less sensitive than say, Google. Otherwise, you'll run the risk of never hiring anyone.

Personally, I find the easiest compromise for me has been to request but not require a code sample. If I get one, it's just an additional data point to evaluate the candidate with. Similarly, if I happen to have an acquaintance that has worked with the candidate in the past, I'll attach some weight to that acquaintance's opinions. Not having worked with anyone I know certainly doesn't disqualify any candidates though - it just means that my job in evaluating them is a bit harder (and will probably include a coding exercise if they make it to an interview). If your sample is poor (or my acquaintance bad mouths you), it's pretty much a no-hire. Those that provide a sample may or may not have a small leg up on those that don't in initial screening - depending on the quality and quantity of the resume stack and samples, more information may be better or worse than no information.

  • that samples are easily faked

Well, yeah. So are resumes - but we still collect those. Why? For three main reasons - a poor resume or sample is an easy no-hire, being caught faking a resume or sample is an easy no-hire, and they're good conversation topics in an interview. The quicker I can figure out the candidate is a dolt, the better for everyone.

If you're smart enough to plagiarize a good sample without being caught, talk intelligently about it, and get through the interview - I don't particularly have a problem with how you got past the screening. There may be some ethical concerns here, but that's not really my area of expertise, so I'm not going out of my way to evaluate moral character during an interview. To me, it's virtually the same as my boss asking me to interview someone who didn't get through the screening process as a favor. Once you're at the interview stage, it doesn't really matter how you got there since there's so much more and better information that will come out during the interview.

TL;DR - a code sample is a great screening tool, but you should think carefully whether you can do require it or not. Once past screening, weight the interview much higher than a sample.

Not the answer you're looking for? Browse other questions tagged or ask your own question.