How To Show Code Samples?
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?"
what am I supposed to show them?
Someone else's code
Thank God for evolution.
Like the other day, i was interviewing for a job and i said, "Well you know i did all the coding for Amazon.com right? but you see i can't show any of it to you because of the non-disclosure agreement"
For some reason i still haven't gotten a call back...
Just translate everything to brainfuck, and send that sourcecode. Problem solved.
(Some people claim that this brilliant---nay, genius---solution will just make things harder for you, but you can never tell until you try, right?)
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.
In Liberty, Rene
Work on an open-source project, and use that code.
Table-ized A.I.
Lacking <sarcasm> tags,
i.e. for bash scripting:
give yourself some common tasks:
create scripts for them...
i.e. create a script to fetch updates and notify you via mail(or some other means) when they are downloaded and ready for installation.
create a script that analyzes log files(yes these things have all been done by many others and you can download them in tool-kits...but that's not the point)
create a script that updates other scripts dynamically based on what they find out...
"Just Smile and Nod." --Huck
You should have side projects.
The big win with side projects that are entirely under your control is that the code is entirely your style. Almost all of the code that you write for work will have some legacy or shortcut warts, but your self-made utility code can be entirely of your own style and principles. This can be good or bad.
If you don't have any code that you can show, ask your prospective employer to concoct a reasonable example.
If you don't have any code of your own to show them, that tells them something. If they can't come up with a reasonable task for you to demonstrate your abilities, that tells you something.
Use uber obfuscated code: Example: #define w "Hk~HdA=Jk|Jk~LSyL[{M[wMcxNksNss:" http://www0.us.ioccc.org/years.html
Generally, when looking for software engineers or system administrators, I try to find the people who enjoy what they do enough that they don't mind doing it when they get off of work. If you haven't written anything interesting outside of work, and you're completely uninterested in doing so, then this automatically drops you down a notch among those that I would hire.
Beyond that, though, you can't show prospective employers things that you've done for other companies unless you own the source code. On the other hand, the company you wrote it for absolutely cannot bar you from producing derivative works from memory. That would result in devaluating your skill set, which is considered an unconscionable harm by our courts. Write something similar but less ambitious at home and present that instead.
Wake up - the future is arriving faster than you think.
Grab a couple computer science tests, some Knuth books, or ACM programming contest sheets.
Find a simple problem (one that'll take 10-30 minutes to code) and write it up nicely in a couple different languages. Use at least one OO language if you know one.
Discuss the projects you worked on, but tell them it was work for hire and stress that you respect the privacy of the other companies, but you brought other code samples for them to see.
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.
If you have been in the industry before and are looking to join a software company like M$ or others they will typically not ask for samples. If you get to the interview you will have to demonstrate in real time your skills.
It is a big red flag if a company asks for samples before hand. It usally indicates you are interviewing at non tech company or they have inferior managers whom can not weed out candidates well.
I used to ask applicants for 1000 lines of C++ they were proud of. Sometimes you get something really beautiful. Something that's at least decently designed and looks reliable is essential.
I've been known to send such samples back with "Your first buffer overflow is on line 42. Thank you for your interest." I couldn't afford to deal with sloppy coders in a hard real time environment.
10 PRINT "Sample Code" : 20 GOTO 10
If enithin kan gow rong it whil. (Murfey)
Make sure you contribute at least some of your time to open source projects. That you can show.
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.
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Christ. Is the site listed as your homepage the one you show to potential employers?
Shoot electrons at it, but every now and then leave one out.
...the future crusty old bastards are already drinking the Kool-Aid.
Oh yes, let me rush to burn up 4-8 hours of my time doing some contrived, over-specified programming exercise for each job application. I have a medium-sized stack of bug fixes and improvements to open-source projects I can point to, but that's not good enough for some companies: I have to do their extra-special lame example program, because I might not be uber enough to work at their uber-elite programming company.
Once upon a time I thought code samples might be a good idea, but now I'm starting to think that it makes a good lameness filter for my next job search. IMHO they just use up everybody's time for very little benefit; you'd almost be better off just hiring them at a low probationary pay rate and see how they actually perform in your work environment.
[b.belong('us') for b in bases if b.owner() == 'you']
Show some confidence - don't wear a suit to the 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.
Slacks if you're a PC, black jeans if you're a mac or *bsd, blue jeans if you're linux.
Dress shoes if you're a PC, loafers if you're a mac, runners if you're linux, boots or sandals if you're *bsd.
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.
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 crackberry if you're a PC, an iPhone if you're a mac, any flip-phone if you're linux, Chuck Norris if you're *bsd.
Your resume in Word if you're a PC, as a video clip if you're a mac, in openoffice if you're linux, and 7-bit clean ASCII if you're *bsd.
Hide your Zune if you're a PC, subtly show off your iPod if you're a mac, wow them with streamripper if you're linux, and run a script to make the sound of the drive heads seeking play "Take this job and shove it!" if you're *bsd.
A business card if you're a PC, a mini-dvd if you're a mac, a bootable distro dvd with customized splash screen, borwser, etc., if you're linux, your phone number and email address on the back of a beer coaster if you're *bsd.
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.
I did some smaller contract work on the cheap with the stipulation that I could use the code I wrote however I wanted. That's where most of my code samples come from. Smaller shops are often willing to compromise in ways bigger corps aren't, especially when it's possible for them to save money.
You could also just whip up a reasonably professional sample app and explain that your "real" code is locked up with your old employers. Companies worth working for, and recruiters worth talking to, will understand your situation. They probably have clauses in their standard employment contracts that restrict their employees in the same way, after all.
By the way, this is another good reason to contribute to Free Software.
Game... blouses.
I had something similar happen to me. The interview test question was worded "write a solution for find the exit path from a maze from any starting point". OK, college algorithms class stuff, I thought. I'm a bit rusty but I remember the general techniques.
As soon as I start throwing up code on the board they start adding conditions. It couldn't be a chunk of simple code that showed the algorithm, it had to also show good modularity and separation of concerns. Oh, I thought, so it's also a test of my design skills, that's good because really, what does knowing how to solve a maze show other than you can pass algorithms 101?
After a couple more rounds like this, with ever more abstract and arbitrary issues imposed, (like: "don't use exceptions that way, it's bad style" when I used them in a way that's common in both the libraries and the literature for that language) it finally struck me that these guys weren't looking for someone who knew how to solve a particular problem, they were looking to find someone who would solve the problem in exactly the same way they'd solve it. At that point I just blew off the rest of the interview and every time they raised an objection, I just responded, "yes, that's one way to do it, but not the only or necessarily the best" while changing my solution to match theirs.
I'm glad they didn't hire me though, I could sort of tell when I was sitting in the waiting area until well past the time they said they interview started in their offices in a soulless corporate office park that it was a soul-draining company.
Oh, and it's "shoot holes IN".
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.
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).
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
Should there be a Law?
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.
Go to OSCON this year, attend the sessions with Larry Wall, Guido van Rossum, Damien Conway, etc. Write down the code samples and then take those to the interview.
-- "In order to have power, I must be taken seriously." -Mojo Jojo
Ya know, I went out to a bar once and saw this beautiful blue-eyed brunette. Got her a few drinks and one thing led to another...she did not ask me to enumerate which chicks i've been with - she just expected me to make her a woman...
you get the picture
Being asked for code samples in an interview is bullshit. It has never happened to me.
Go find another employer, one who will discuss previous projects, pitfalls, solutions, science, the passion behind what you like to do and what you'd bring to the organization, stuff that demonstrates your ability and skill. No need to kiss and tell.
On behalf of the people that are the ones asking for code samples, your response answers 50% of what the employer is looking for.
We're not necesarily looking for someone with tons of open source experience, or who does lots of other work at home.
But for the sort of positions where you DO ask for sample code, you are intentionally looking for people who ARE programmers, not that just DO programming.
For high level positions, I generally ask for 5,000 lines.
The really top notch people are going to have SOMETHING they can provide. This could be work on an open source project, or some insane project they only do at home, or even some shareware tool they make some money off on the side.
But there's generally something.
If you don't have the code, then the question is no longer one about assesing your programming skills, it's now about assessing your personality and profressionalism. Will you make excuses? Will you write something just for the request? Will you offer to program something?
I've even had one guy who came to us from a bank that responded, "I can't show you the code, but I could give you the header files and documentation?" (he was hired)
Since you obviously don't have the code, bear this mind.
In India (at least until recently) it's fairly easy to hire people cheaply that can't afford or doesn't use a computer at home, for whom programming is something they were only trained for an just do at Their Job.
If someone is asking for code samples, at that point they DON'T want people of that calibre. They want GOOD people that they can give responsibility to and trust the decisions of safely.
Your job is to demonstrate that.
For the last 4 or 5 years that I was programming for a living I maintained a portfolio. I wrote a small application (about 2000 lines of code). I followed my own personal process for implementing it. I kept the planning, specification and design artifacts (fairly lightweight since I prefer to do something similar to XP).
Then I chose a couple of interesting areas in the code and annotated them. I explained what I was doing, why I chose a particular design approach, some aspects of my personal coding style, etc, etc.
The whole thing took me a month or two of working on my own. Then a little bit of time to keep it up to date (based on what I continued to learn over the years). While it was a toy problem, I found the exercise extremely useful for my own personal development. And when I applied for jobs I gave a link to my portfolio on my resume. This gave people a really good idea of what they were getting if they were to hire me.
I highly recommend any programmer to do the same. It *is* a fair amount of work in the short term, but the benefits far outweigh the costs. It's not just about getting a job. It's also about really understanding your own personal style.
I interview quite a lot. I used to ask people if they'd worked on open source projects so I could see examples of their code. Not one person I interviewed had contributed to an open source project. So I came up with my own code samples. I picked some code from Sun, an example from one of the O'Reilly books, and one more from the web. I ask candidates to read the code, tell me what it does, and what would they do to make it better. These are short code samples, all three print out on a single sheet of letter-size paper. This simple test takes about half an hour to talk through, and is surprisingly revealing about the skill level and knowledge of the language.
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.
8==8 Bones 8==8
You'll probably get away with it, but you are in fact violating the contract you signed.
And worse, you have just demonstrated to a potential future employer that you are untrustworthy in this respect. If you were a bank manager, would you hire someone to handle cash when they had a criminal record for fraud or theft?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Chaff is the husk around a grass seed. Wheat is what's separated from chaff, not weed. The chaff is the bad part.
In my recent job search, I had two companies ask me to do 4-6 hour coding exercises.
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.
I use the project I had to do for the SCJD exam process. Even though it's Java I can show that I fully understand OOD, low-level IO, concurrency, GUIs, networking, documentation, common coding standards, etc... Even if the job is using C# or C++ the example works very well and generally people are surprised at the difficulty and comprehensive nature of the project. It also shows that you can follow detailed, specific instructions that are full of loose ends. My advice is do the SCJD exam and you'll have a free and clear showpiece of code that includes many advanced development practices. For Java gigs, the cert can open doors as well.
In my last interview I was asked to do a similar task, but I was put off a bit because the interviewers were basically junior level programmers and they asked some really dumb questions about the SQL they had me write. After the experience I realized that asking a professional to write code in an interview is inappropriate. A senior developer should be able to simply discuss and ask questions to get a feel for a person's aptitude, but sadly these days most of the interviewers don't know much about development so they use scripted questions and on-the-spot tasks that tell them very little about the performance potential of a candidate. I didn't get the gig BTW, they told me straight to my face that I was way overqualified! Nice comment for the ego, but tough of the bank account!
You speculate that they turned down your application because it was too good?
So you didn't actually ask why they turned you down? You just sit there with a grudge, making most likely false assumptions. Smart move.
Ever crossed your mind that they might have found someone just as good, but with, perhaps more experience? Or asking less pay?
There are thousands of useful coding projnects over at Sourceforge: pick one or two that relate to tools you use, and help update or debug them. Post patches, and you'll have it online there as a matter of public record. If you management doesn't want you to publish such tools, gently steer them to the details of GPL licenses: GPL code is particularly good for this. Perl modules are particularly good for this, published over at CPAN.
At my last job interview, I was able to point to 3 products that they used that I'd contributed to at least 5 years previously, and one product they were contemplating using that I pointed them to bug fixes I'd published.
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. 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).
I absolutely concur. I'll usually be blunt and indicate that I'm interested in the solution methodology and not the specific answer, and I'll probably send the candidate down a dead-end road to see how he reacts.
... I probably can't teach you how to be less of an asshat. A bad attitude is destructive, no matter what degree of "leet skills" you think you have. Unless you're being harassed or threatened, walking out of an interview is a mistake.
During an interview a couple of years ago, the candidate was stunned when I said that I didn't have an answer to the problem, and that we'd solve it together. So I explained, "Son, life doesn't come with a User Manual, Reference Guide, or more importantly, an Answer Key in the back." I think he completely missed the point, and unsurprisingly, had little in the way of problem solving skills. Reminds me of a line in Men in Black - "Gentlemen, congratulations. You're everything we've come to expect from years of government training."
When I came out of college, I went on a particularly brutal interview. One section involved critical timing paths (I'm an EE,) and the interviewer tossed a simple schematic on the whiteboard. I looked at it for about 5 seconds, and told him what it did. He paused and asked, "Are you sure?" His tone clearly indicated that I was incorrect. I looked again, and stood my ground. I further pointed out that he had a potential setup/hold timing violation depending on what parts he was using. I spent over an hour with this guy, and he asked some seriously challenging questions. I found out after the fact that he was notorious for chewing-up and spitting-out candidates, and that his interviews rarely lasted more than 20 minutes (he was effectively the CTO, so time mattered.)
The lesson here is that a proper interview is geared toward making sure you have both technical chops and people skills that are compatible with the company. I can teach you new tech stuff
Make an open source project or open source one of your current side projects. Or contribute to an existing project.
Direct them to the projects' websites and/or online source code browser.
If someone wanted to see my code, I'd just send them to my git repo with many of my open source side projects.
If you're a coder and you don't have side projects ... you're not a coder :P