How Not to Impress with Your Code Sample
I have seen some ridiculous stuff in the requisite code samples submitted by applicants to my current company. Names and specifics have been redacted for obvious reasons:
Code problems
Look, we all have to start somewhere. And I would be a mendacious motherfucker to say I haven't done these. But if you want to put your best foot forward, avoid the following:
- A single file that runs on for thousands of lines: PHP has the include() and require() functions. Use them.
- Not using functions: PHP has the function keyword. Use it.
- Meaningless variables: Using something like $i or $val is OK in a loop. Otherwise, use something that will make sense to people reading your code. You know, like interviewers.
- Mixing presentation and logic: Line after line of echo'd or print'd fixed HTML looks stupid, and so do you.
Comment problems
Even worse are the comments. People give these short shrift, but they shouldn't, because comments are there specifically for other people to read.
- Self-hating code: It's OK to put "FIXME -- this is really slow" in your code and come back to it. It's not OK to leave it there as a giant, neon sign that says, "Even I think I suck."
- Foul language in code: Should be obvious, but you'd be surprised.
- Saying your code sucks in vulgar terms: No joke, one said, "I don't know what the fuck I was thinking here." Oh really? I don't know what the fuck you were thinking by including this in your portfolio.
- Comments loaded with other people's initials: We're not interviewing JSG or LPG, so why are you showing us code that they wrote?
A serious problem
The worst thing, bar none, is the fact that we get code samples that include the usernames and passwords to working, production databases or servers.
I am an upstanding guy, and I'm not going to hack your current employer's clients. But you don't know that.
More importantly, it shows us that you don't have a basic understanding of security. And security is really, really important. I don't care what kind of impenitrable fortress of code you can build if you're going to hand over the keys as soon as you see something nice on Monster.com.
If you give it to the interviewer, it matters
If you are a good, conscientious candidate, you don't dress like a slob, you have a solid handshake and you have a meticulously-constructed résumé. So why let your code be wack? After all, we're not hiring you to be pretty, greet people and write about yourself (that's what blogs are for). We're hiring you to write really good code. So convince us you can do so.
update Addendum: It's also pitiful when people say they have no code because of confidentiality agreements. I'm glad you respect contracts, but show a little initiative and write some new code!
"We're not interviewing JSG or LPG, so why are you showing us code that they wrote?"
Because our code rawks ;)
Posted by: LPG on March 30, 2006 10:50 PM | permalinkI always thought the idea of code samples to be somewhat suspect. I understand why employers would like to see them, but my work which is equivalent in scope and complexity to what you are hiring me for doesn't belong to me. It belongs to my past and current employers, red flags should be equally raised by just potential employees giving you that code.
I can put something together, but then it isn't really a sample of the kind of work you expect me to do.
Posted by: Nephlm on March 31, 2006 11:26 AM | permalinkThat reminds me... Back in 1997, in my early days of messing around with Direct3D, I was in contact with someone who was writing a book on the subject.
In one of the .X files you see a lot of:
//this needs to be done, but I have no idea why
Which is a comment I added to one of his .X files. My name isn't anywhere on the disk or book, but my comment (and fix) made it on the CD. I was proud at the time.
The papers I wrote for two of the ShaderX books kind of took away from that glory. Speaking of ShaderX, I just got a $60 royalty check for the last six months. It's fun to tell people about my book royalties without mentioning how much money it actually is ;)
Posted by: Od-ll on March 31, 2006 12:03 PM | permalinknephlm:
Well, yeah, you can only learn so much in an interview; everything is suspect in that sense. But, that said, it helps form a more detailed picture than just counting "years of PHP" on their resume or testing their knowledge of things you can look up on php.net.
Posted by: Joe Grossberg on March 31, 2006 12:53 PM | permalinkOne thing we do is have a candidate to a test project. It is the same project for every candidate. Sure it is not super complex, but it is something I can be reasonably sure they did. We give a set time limit in days usually trying to put a weekend in there for them to complete the project.
It has been enlightening what people present as answers.
I've written a rejoinder to this article called "How Do I Impress With My Code Sample?" I'm interested to know what people *are* looking for in a code sample, and what *I* should be looking for if I receive code from prospective employees. If you click the link on my name below, it'll take you right to the article.
Posted by: Ryan on March 31, 2006 3:27 PM | permalink> Mixing presentation and content: Line after
> line of echo'd or print'd fixed HTML looks
> stupid, and so do you.
You're talking PHP here aren't you, not getting confused with "presentation vs. content" as in HTML vs CSS? and you realize PHP *is* a templating language, and in the Web environment (what PHP is for) you want precisely to display your dynamically generated resutls _in_ HTML. Maybe you mean something along the lines of MVC, separating presentation from the software logic.
Posted by: ct on March 31, 2006 3:31 PM | permalink>PHP *is* a templating language, and in the Web environment (what PHP is for) you want
>precisely to display your dynamically generated resutls _in_ HTML.
Most of what's on that dynamically generated page is just static HTML. There's no good reason to generate any significant portion of that static content by passing string literals to echo or print.
Posted by: Zak on March 31, 2006 4:00 PM | permalinkThe point of code samples is usually to find out if the candidate has an IQ above the average fencepost and can avoid making the mistakes you have presented...
In that case they *might* be smart enough to write code. If they can't even avoid these mistakes, they definately shouldn't be hired.
It's just another form of giving people enough rope to hang themselves with.
Posted by: Gus on March 31, 2006 4:35 PM | permalinkct:
You are correct. I have edited it accordingly.
Gus:
Exactly.
Posted by: Joe Grossberg on March 31, 2006 4:56 PM | permalinkIf a company requires a code sample I say the code that I work on is proprietary and belongs to the company for which I'm working.
If they still want a code sample I say they can do what they want with me on the interview but I'm not wasting my time prep'ing a code sample.
If they still insist I just refuse to interview.
Posted by: steve on March 31, 2006 7:11 PM | permalink"I'm not wasting my time prep'ing a code sample."
I wouldn't want to hire someone who considers this a waste of time. Either you are interested in the position and willing to put in some extra effort to get it, or you're not.
Then again, I don't like to hire someone who only codes for their employer.
Posted by: Joe Grossberg on March 31, 2006 7:24 PM | permalinkI would take XXX and fixme comments as a good sign. It is a mark of maturity:
1. The programmer recognizes there may be a problem.
2. The problem is not swept under the rug.
2. The programmer recognizes he is not perfect.
3. The programmer can prioritize. In writing non-trivial software, many issues will come up that cannot be addressed immediately. Knowing what needs to be done now is an important skill. Making release dates require this skill as well.
4. Some things that seem like they are important now turn out not to be.
5. Engineering is about balancing trade-offs, perfection may not be attainable.
6. Code is never "finished". new features are added, it must be adapted to new circumstances. Code that can be extended and adapted is more valuable than code that is optimized to the current situation but not flexible.
If I were looking at production code and I didn't run into any XXX and TODO's, I would be more suspicious about the quality of the code. If I were reviewing a candidate's submission and I ran code that deserved such a comment, I would be suspicious that the writer either did not understand the issues with his code, or refused to document them.
About code submissions. This is the type of requirement causes me to reject the employer. I work many hours a day on proprietary software. This is where my serious coding happens. In my free time, I pursue other hobbies. My off-hours programming activities are strictly for my own enjoyment, they are not designed buzzword compliant, complete, or interesting to anyone other than me. I refuse waste my free time working on empty resume fluff. My days of doing that (empty high school extracurricular activities) are over. I am an adult now, and I will do something worthwhile in my free time.
I'm sure my employer appreciates the fact that I won't submit our proprietary code to you. I hope they also appreciate my coding time is primarily devoted to them. Most people can only excel at one activity at a time. If I were working on a substantial project outside of work, either I would be doing a crappy job on my job, or a crappy job on the project, or I would be totally burnt out. I'm sure you would appreciate this from your own employees as well.
On the other hand, if I was asked to do some coding as part of the interview process, I would be more than happy to do so. I would also be happy to work through a design problem as part of the interview. It seems like a better way of assessing someones ability, because:
1. You know the candidate wrote it.
2. How can you evaluate a substantial piece of code in a short period of time (during the screening process). Even with an architectural overview, it would take you a couple weeks to come up to speed on most of the software I've ever worked on. A better question would be to ask me to take you through a high level overview of the architecture of something I've worked on. Being able to discuss a project that they claim to have worked on is an indicator of communication skills as well as evidence that they actually did what they claim.
3. You are assigning the project, you've picked a problem with various issues that need to be overcome, so you know what to look for in an answer. It gives the candidate a chance to talk about the trade-offs in his solution (all those XXX's).
Game companies seem to mostly do what Lorad said - present some kind of test or test project with a time limit.
I think that's the way to go. It can be a test as well as an indicator of them being able to do stuff in a certain timeframe.
Their samples may be months and months old, groomed over a long period, where as production stuff is often thrown out the door as soon as it works.
Posted by: Od-ll on April 1, 2006 12:32 AM | permalink"I wouldn't hire a cobbler who only repairs shoes at work."
"I wouldn't hire a painter who doesn't spend his evenings repainting his house."
"I wouldn't hire a biologist who doesn't spend his weekends at his home microscope."
Why would someone expect that programmers have to spend all their spare hours programming? Of what other career do we expect this?
Posted by: Kyralessa on April 1, 2006 12:40 PM | permalinkHey, programmers have to program at home if they spend all day blogging ;)
Posted by: Od-ll on April 1, 2006 12:47 PM | permalinkKyralessa:
Would you not expect less of a chef who eats TV dinners at home? I mean, maybe he can cook his ass off once he gets to the restaurant.
It's not a litmus test, but I believe that -- all things considered equal -- someone who loves what they're doing is going to be better at it. And programming affords us a wide range of interesting things to work on when we're not collecting a paycheck for it.
I'm not saying that they should "spend all their spare hours programming"; I'm saying that if their interest and excitement in development ends the minute they leave the office, then it provides a small, but meaningful, insight.
"Of what other career do we expect this?"
I would expect that a professional athlete would practice and train between games. I would expect that a musician would practice when he's not on stage. And I would expect that most (not all) great programmers don't just switch it off when it's 5pm.
I have seen exceptions, but most of the great programmers I've come across do *something* on their own time. And the ones that don't should be able to put something together for the interview process. It's what I did, when I (a Python guy) applied for a PHP opening.
Posted by: Joe Grossberg on April 2, 2006 8:14 AM | permalinkAnon.
"Most people can only excel at one activity at a time."
Bullshit.
But, otherwise, great comment.
Posted by: Joe Grossberg on April 2, 2006 8:34 AM | permalinkOne of the better ways to get job offers, earn street cred, and provide an excellent repository of code samples is to just write some open source software. If it sticks, then you're set. Look at how many OSS authors companies like Google, Yahoo, and Apple employ.
If you don't already have OSS contributions, then you probably have some personal bucket(s) of reusable code lying around that could easily be molded into one. It surprises me that more people don't do it (though I can't complain, because it makes it easier for people who do).
Posted by: Bob Ippolito on April 3, 2006 12:27 AM | permalinkI know the debate over "to code at home or not to" has been hashed out pretty recently in these comments, but i just wanted to add two cents more. When you talk about a musician practicing when she's off stage, or an athlete practicing when he's not at a game, you're talking about two activities (a game and a performance) that people don't usually spend more than a few hours a week doing. So yes, if I played the violin, and only played during my weekly performance, I'd only get in a few hours of playing a week. Same with a lot of athletes. So spending the rest of your week practicing is pretty damn important. We spend our full time jobs writing code. And we get to do some reasonably fun and interesting stuff while we're there (it's not like we're sitting around hacking COBOL). So yeah, i think it's reasonable that we would do some development outside work when the mood strikes us, but if we're not doing a ton of it, I think that's pretty reasonable too.
Posted by: Lori on April 3, 2006 9:51 PM | permalinkNo more comments! Either someone has violated Godwin's Law, I'm tired of the discussion or, most likely, the ten-week window has closed. You can, however, contact me through email.