How To Show Code Samples? 485
Todd writes "I've been looking around at 'help wanted' advertisements for programming jobs, and almost all of them demand that you not only have professional experience, but also that you show samples of your work. This got me wondering; with the work product, trade secret, and non-disclosure laws/agreements, how exactly can you show work that you've done in a professional capacity to a prospective employer without violating the privacy of the company for which the code was written? For instance, I can't say I've written many BASH scripts (at least, not large ones) for myself personally, but the assortment of such scripts written for my current job is wide and varied indeed. I can't very well just deliver these scripts, or even small portions thereof, to third parties to help demonstrate my scripting prowess. With that in mind, what am I supposed to show them?"
Ask for a test problem (Score:5, Informative)
I usually explain that various NDAs prevent me from disclosing code I've written of significance, and suggest that I be asked to complete a programming exercise.
Most employers have a set at the ready these days, and I usually respond with the 1 hour answer and the 1 day answer, the later showing an evolution of the former, with polish and usually a more generic solution.
Been there (Score:4, Informative)
I've been in that situation. My potential future employer asked to see some of my code. What I did was:
1) I directed them to some open-source code I'd written.
2) I told them that I could not show them the code I was working on at my current job, but I said they could ask my colleague about the quality of that code.
One good thing about 2) is that it also tells the future employer that you're not going to show *their* code around after you leave. Oh, and I got the job, although I chose to go to another company.
Re:Sample Code (Score:3, Informative)
I've shown some good code to people, and they start saying whats wrong with it without knowing what it's about. For instance, I interviewed with some small startup (some 5 dudes coding in a studio), and I showed them some heavy ajax code, and they said it would be too slow for a high traffic site. I told them it was an internal application with high functionality, and he proceeded to show me a simple html page with no javascript and told me "see this is high performance". I think its just deceit when the person interviewing you doesn't have a strong skill set and feels intimidated by a good candidate who will make him/her look bad.
Some won't actually mind... (Score:4, Informative)
would THEY like you to show work you did for them, later on, to OTHER employers?
Some company won't actually mind.
Not every single line of code a developper may write while working in a place is of utmost strategic importance and has to remain secret or otherwise the company will go bankrupt.
The developer should ask his/her supervisors for proper clearance to show some code that isn't a vital part for the company's survival on the market place. i.e.: Maybe you can't show the source code of the product the company is selling, but you can show the source code to tools you have developed to simplify your work.
In fact some places even authorize you to release such non-critical side project under open-source licenses.
Of course this is much easier when you work in a small company. If there are 10'000 developers in you company it's hard to check everyone's code for clearances.
...
Of course as other /.ers have said, the home projects are much better candidates to be shown in an interview.
Unless you work for a paranoid "sell your soul" companies which insist everything developer while under contract belongs, even home projects.
Re:Be smart (Score:1, Informative)
How indeed...
http://www.blackducksoftware.com/protex
Re:Strategy (Score:4, Informative)
I am corrected, Previously I responded that something was the dumbest post, but you win.
Really, do you think that you are so awesome that the crappy little code sample that you are showing me is going to blow my mind. Do you realize how unlikely it is that your sample code is even remotely related to the problem I am working on at that moment?
I want to see an example of what you have written in the past for a few reasons:
1. It shows me your style. Do you design before coding? this is usually evident by simple elegant solutions. An experienced programmer/engineer can tell alot from a small sample.
2. This is much more fair than me presenting you with some problem out of the blue. I am giving you as much time as you want to compose your solution. This is the audition part of the process.
3. I will be asking you questions about this example code to determine that it was in fact you who designed/wrote it, and to understand the thought process that you followed. This has 2 purposes.
a. I figure out if you are trying to bs me.
b. You get a chance to see what the caliber of your peers will be based upon the quality of my questions ( and I am working on the spot, without a net).
Interviewing should not be considered combat. I want to like you, and I want to hire you. I am asking 4-8 of my staff to take an hour out of their day to talk with you and see if you will be an asset to our organization.
A great interview is a conversation, not an interrogation. We both have something that the other wants and we are conversing to see if we are a mutual fit.
Ask (Score:3, Informative)
Periodically when you are working (long, long before you are looking for a new job) ask your supervisor if you can use a particular chunk of code as a code sample in your portfolio. Don't pick a mission-critical routine or something business-centric (those won't translate much into most job interviews anyway).
I've been doing that since my first programming dig and only been denied once.
Make sure you attribute the copyright and permission accordingly and keep the permission in a safe place (CYA).
Show some confidence - don't wear a suit to the (Score:4, Informative)
interview.
A good-quality shirt if you're a PC, a turtleneck if you're a mac, a T-shirt if you're linux, or a leather jacket if you're *bsd.
You left out a hemp safari shirt.
Slacks if you're a PC, black jeans if you're a mac or *bsd, blue jeans if you're linux.
Cargo shorts.
No hat if you're a PC, a kepi if you're a mac, a ballcap if you're linux (a red one if you're Fedora/RHEL), and a shaved head if you're *bsd.
Beret.
A briefcase if you're a PC, a leather portfolio if you're a mac, a softsider if you're linux, and a pull-behind carrying a 4u server if you're *bsd.
A backpack.
Coca-cola if you're a PC, bottled water if you're a mac, real beer (not that 5% piss) if you're linux, shots if you're *bsd.
Camelback of fruit juice and bottle of homebrew.
Falcon
Obvious Answer (Score:2, Informative)
My manager once went down to a local university to tell the students something about the real world with regards to the job market (and to plant some recruitment seeds while he was at it). This same question came up: what do you show?
Some people have mentioned that contributions to open source are a great solution, but interview time is not the time to start joining projects. Fortunately, there's an obvious answer...
The important thing is to demonstrate ability, so the only thing that matters is that the code works and shows you know what you're doing. My manager said the best piece of sample code ever submitted was by a guy who wrote some code specifically for the purpose of interviewing. You'll know what they want to see if you're interviewing and you have plenty of experience with that proprietary stuff you can't show off. Make it work.
The code doesn't have to simple, but let's not make the code request any more complicated than it has to be.
Re:Be smart (Score:3, Informative)
You don't. (Score:3, Informative)
Instead, show them an executable version (or video of one running) and give narration on how you managed to resolve certain issues, letting them see the results of your work. It's probably vague enough to prevent disclosing any major trade secrets and still gives some idea of your overall capabilities.
For added protection though, you might want to have your employer agree to let you have an executable version of any software you write (or at least, some form of pre-recorded clippings of the software in action using dummy information) for your portfolio beforehand.
Showing off actual code is definitely a bad idea for a number of reasons. First off, it's a huge breach of security as it could expose potential exploit point in the software. Next, it's obviously going to be a legal nightmare should that code show up somewhere you've been with it. Finally, code by itself just isn't that interesting to look at unless you can see it in action. It's unlikely the one's hiring you will be able to read and understand any code you show them, but they can probably recognize the benefits of your code through comparisons of it against something else that performs a similar function. If they see that the code is somehow faster or does a better job than the item it's compared with, it'd probably be good reason for anyone to consider hiring you on as a developer.
Provide a printed copy during the interview (Score:1, Informative)
One method I have seen used in similar situation is to offer to being in a printed copy of the code that will not be left behind.
They can peruse it during the interview but they can't keep it.
OT - small point (Score:3, Informative)
Chaff is the husk around a grass seed. Wheat is what's separated from chaff, not weed. The chaff is the bad part.
Re:I've already done my share of "code samples," t (Score:3, Informative)
In the first case, I went to town creating fully-commented, production-quality code complete with automated tests. It was more than they asked for. In that case, it didn't matter, I was turned down for the job. The solution was so damn good that I think they thought I copied it from the web, even though I had not.
In the second case, I produced code that looked more like a proof-of-concept. It worked and matched what they were asking for. But, it wasn't properly documented, wasn't production-quality, and didn't include the automated tests. It was clearly my own creation, but I again was turned down for the job. They said my code wasn't good enough.
So, apparently there isn't a happy medium. If you solve the problem to their required level, then they think your code is shit. Actually go all out and give them more than what they ask for and they think you've copied it.
Either way, I put in over 10 hours and got absolutely nothing from it. I agree that if a company asks you to do a programming exercise on your own time, then add them to your 'lame' filter and walk away.
Re:In my most recent interview (Score:2, Informative)
If you want to show our stuff, suggest pairing (Score:3, Informative)
As a hiring manager I find preconceived code samples worthless. There is only one way to know if someone can code during an interview, and that is to pair program with him/her.
I use a technique I learned from Rob Mee at Pivotal Labs [pivotallabs.com]. I spend roughly an hour test driving a simple project with the interviewee that Rob specifically crafted to determine the capabilities of the candidate, from the basic level of competency up to that Rockstar ability to spot the elegant solution intuitively.
During an hour of pairing with someone you get a good idea of what they can do, much better than you can from reading pre-fabricated code samples or merely asking quiz questions (whether about stuff someone can memorize from a book or silly brain teasers).