What's wrong with bringing code to a programming job interview ?

Question

I'm baffled by the responses to another question that say you shouldn't bring a code portfolio to a programming job interview.

Why the heck not ? Others recommend this; it's even one of the "classic" stories in Peopleware:

“It would be ludicrous to think of hiring a juggler without first seeing him perform. That’s just common sense. Yet when you set out to hire an engineer or a designer or a programmer or a group manager, the rules of common sense are often suspended. You don’t ask to see a design or a program or anything. In fact, the interview is just talk.”

So, what gives ? Any "war stories" of what went wrong when you showed up with a code portfolio ? Or of when you interviewed a candidate who had one ?

Answer 1

I have been asked for code at a job interview. The safest thing would probably bring some example code/portfolio with you, so at least you have something to show when prompted.

Answer 2

I think the whole concept is that good managers want to see if you can think. I have been asked riddles and asked to solve logic puzzles at interviews. My code could be copy paste or even stolen .

Just the process of seeing the steps a person goes through will give you a good idea of their logical ability to solve problems.

Answer 3

My view on this subject is that you need not bring a code portfolio to an interview, unless expressly asked to. It just acts as an interruption in the flow of the interview as the interviewer might have planned. Additionally, what proof can you furnish that the code in your portfolio is indeed your own, not lifted off the internet or taken from a colleague? Lastly, what use would the portfolio be if none of your previous code is actually relevant to the new situation?

In addition, many companies hold the code of their employees as legally copyrighted. After all, you would be sharing the internal details of the software created in your previous company, even if you did write it yourself.

Interviewers usually like to stress on how well the prospective candidate will be able to adjust in the new company's environment and how familiar he/she is with the technologies they work on. Many interviewers may actually ask you to write a short code snippet to demonstrate your logical thinking and how you deal with problems in general.

Answer 4

I would ask for code only if I like the guy anyway. And then I would prefer if it's available somewhere in the internet in the public repository. But the decision hire/no hire would be made by then anyway. It's no use to look at the code upfront because you could never be sure it have been written by the person who handles it to you.

Answer 5

Code samples may 'wow' interviewers just looking for buzzwords and gimmicks but respectable interviewers will look for problem solving skills and the ability to reason on the fly. Most interesting code will be too long for the interviewer to really interpret and will probably go to waste.

That said, it's not a BAD thing to bring code samples so long as you don't force them upon the interviewer. It's just a bad prioritization to place on something that really doesn't extol your benefits properly.

Answer 6

I have never taken code with me to an interview and I have never had someone bring code when I'm interviewing them. If I want to see a code sample I will ask the candidate to submit it before the interview so I have plenty of time to examine it. If I was handed a code sample in person I would not have enough time to grok its substance.

Should you provide a code sample if it's not asked for? I say no, and here's why: When I ask you for a code sample, it's a test I'm trying to see if you fail. There are two possible results I give after reviewing a code sample:

Good Code Sample: INDETERMINATE (i.e. other factors will determine 100% if you are a HIRE)

Poor Code Sample: NO HIRE

So, now that you know that, would you like to volunteer to take that test if I haven't asked you to?

Answer 7

I've done a lot of interviewing over the years, but I've never asked for, or been show, any code. It is not what I'm looking for. First off, I'm trying to establish whether you can work in a team cooperatively. I'm also keen to see if you understand how to deal with all those compromises that employment implies. For a developer, I'm looking to see the way that you approach problems, and your stubbornness to persevere after setbacks.

Obviously, I'll want to get a feel for your level of understanding of the art of programming. If you profess a particular skill, i'll ask you a few technical questions.

I'd never want to see the code you've written. How could I be certain that it is yours, unaided? How could I give it, in the interview time, enough time to inspect and appreciate the finer points? How would I know the time it took you to write?

There is a world of difference between writing a program in tranquility, and the skill of working in a team, under pressure, having to make compromises, cooperate, and make decisions on where to focus your resources.

Answer 8

During my Job interview there was no mention of 'code this for me'. More like, we have this problem, how would you solve it. (In general for example with a design pattern)

Answer 9

Bear in mind that the code you've created as an employee of a company is most likely a property of that company - that's a pretty solid reason not to have it on a flash drive in your pocket when you're going to a job interview.

Also if I would be interested in the way you code I would ask you to do that in front of me right on the interview instead of reviewing some canned stuff.

Answer 10

Any non-trivial software application is usually produced by a whole team, not simple enough to understand at first glance. It is likely not easy to look at the entire solution/project and clearly distinguish code written by someone else other than yourself when showing the code to an outsider for the first time. I suspect the interviewer(s) does not have time during the actual interview session to slowly peruse and study your code and attempt to understand the low-level architecture and design of the application(s) you have previously worked on. Be prepared to go through time-consuming walkthroughs if you wish to get points across.

On many cases, our line of work makes us are more likely to enter an already-running project; maintaining/enchancing existing code and applications, rather than write "beautiful" code from scratch. My coding contributions are usually delivered in pieces to refactoring and fixing existing code base that are both massive and ugly. Such stuff are difficult to showcase with gleeming pride.

Also, as mentioned by others, bringing out to open the source code of previous organisations has many undesirable legal implications.

When I wish to see the coding style of interviewees, the interview can include an off-session development exercise. The interviewee would then submit the exercise content for later perusal. But during the interview session itself, it is spending that time getting to know the interviewee's personality, passion, mental and thinking models, problem solving skills, etc.

Answer 11

You can really shoot yourself and your potential employer in the foot by taking code to the interview. The company you work for may own some/all of your code and if they find out they Will fight to be compensated for their "loss".

Another time it's bad is if the new job is a similar role or similar company to the old one. If you jump ship and have ever taken any of your previous employer's code there the previous employer can have a field day, even if the code was only glanced over and then put away.

The only sort of code you should bring with you to an interview is OSS code, and even then only if that code is actually out in the wild. I have had occasion to write GPL'd code (some of my finest for small internal testing utils) at all of my previous employers but because we never released the binaries to anyone we had no obligation to release the source either. In that case, the new employers had no right to access that source and I couldn't show it to them :(

Answer 12

Engineers and Programmer do not have to bring code samples because they are already facing a technical interview. If the candidate knows his stuff, he will not struggle with the questions. There is no chance of faking the technical answers. The candidate has either done that before or not. There is no room for interpretation.

Answer 13

tl;dr: I have always brought code to interviews. There are enough interesting problems out there that you can quickly write up something representative and tuck that in your bag.

My portfolio includes my resume, my CV (a different sort of document), important slides from presentations (downloaded from JavaOne, for example), code samples (created on my own time on my own computer), interesting design documents (for example, how I would do it now if I had to do it over), runtime images (downloaded from publication site), etc.

Never ever ever put anything in your portfolio that even hints of being a previous employers property or IP.

That said, one of the great things about doing public presentations is that you can download a screenshot from the publication website. You have to give proper credit to the publishing entity for appropriate fair-use, of course.

All that said, I interview people who want to work here who aren't carrying a code sample with them. That's largely a factor of experience: many of them are new graduates. My expectations are significantly higher for experienced professionals, though. My filters are pretty thick, too: we would rather be overworked than hire a single bad person.