Code Samples and Interviews?

Question

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.

Answer 1

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.

Answer 2

I agree. Even if the code is plagiarized, a candidate who can talk intelligently about is is more than half way there. :)

Answer 3

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.

Answer 4

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.

Answer 5

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.