Is this normal practice these days ? Does this tell anything about the company? I don't know what to make of this, but I tend to get a negative impression about such companies.
1. They immediately weed out the people who apply to a hundred jobs at once without actually considering the position.
2. It tells managers if the applicant understands the job. If the job is for an algorithm heavy position, does the code sample reflect knowledge in that arena or did they send a half-assed fizzbuzz implementation?
3. It gives some insight into taste. If a job applicant submits code that looks like crap it speaks to the quality of code you can expect to see from them. On the flip side, I've also seen beautiful code submitted from someone I didn't have in my top 5 list of people to talk to and it ended up getting them a job.
In the end, you shouldn't be offended by the request. It's not uncommon to get over 200 responses for a job opening, most of those coming from people who haven't really read it. It's a nice way to filter out bad submissions without resorting to using terrible HR software that analyzes resumes for keywords.
The past 3 positions I've hired for have had essentially identical applicant spectrums:
* 80% completely ignored the requirements and didn't provide requested the information. Our listings contain one or two questions to make sure they've been read. Things like "What is your favorite programming language?" or "What is your favorite technical blog?"
* Another 10% were not qualified as per the listing
* Half of the remaining 10% did not pass HR screening - usually this meant they were jerks to the HR lady or didn't have good references * Less than half of the remaining 5% were able to perform at any capacity during our very simple coding exercise.
By simple I mean things like "write a function that accepts an integer and returns the next largest prime" or "write a function that interpolates two strings".
We have fairly liberal hiring practices, but insist on being able to do the job we're hiring for. I feel sorry for any company that doesn't have a technical interview process in place.
For example, if you list C as your primary programming language, and you need a copy of K&R to remember that functions use "{}" brackets, you're not getting hired. I mean, please respect me enough to spend 30 minutes cramming before trying to bluff your way into a job.
My rule of thumb: Do not hire programmers without asking them to write code! Shy people who don't work well under pressure can submit github repositories instead.
You have to see as a benefit to you (assuming you're competent), because:
1) You are much less likely to work with an idiot (most of them won't even submit a code sample, or it will be so bad it will be rejected), and
2) Since they can see the level of quality of your work, landing the job and negotiating a higher salary will be easier than just going on your resume alone, which everyone has
For awhile I was always unsure of what to send as a coding sample since most of the code I work was either for my day job or for contracting. I didn't feel comfortable "making up" a purpose for code. If that's you, you can try answering a public coding challenge and submitting it to the employer, like this one http://dotspots.com/jobs/challenges/
I can't stress this enough. I ask for code samples and you would be amazed how many people look good on paper, and even interview reasonably, and yet send in the most awful code.
Now it is true that even great programmers have some code in the closet (or even on github) that they are not totally proud of, but anybody who sends that kind of code to a hiring manager shows that not only they write bad code but that they don't know that it's bad.
Personally, I think code samples are the single most important factor on which to base a hiring decision. After all, good code is what you are hiring for, in most cases. It also levels the playing field with people who are really shy or don't interview well for other reasons, or who lack the right experience on paper.
Actually, I am boggled that anybody would see this negatively.
I just assumed asking for code was stupid, since fakers could copy good code -- but I hadn't thought about the required taste in knowing what code to copy!
Obvious in hindsight, you have to think like a user (here, interviewer) to understand their problems.
An idea -- a web application that helps with hiring/interviewing? That is, keeps track of CVs and runs code examples through standard analysis, integrated with GMail, etc.
I am obviously not competent for doing this (see start of comment :-), so take it if anyone want it. (I assume it is already done?)
Make it an example of what your best code looks like (OO, neat, testable & tested). Send the email to:
Y2hhbGxlbmdlQGRvdHNwb3RzLmNvbQo=With a github account, you can see how someone interacts with projects, how they build their code (commit by commit), how they submit patches, how they communicate with others about their code, etc. This is all really important stuff for any developer working on a team.
If you don't see their code, and you don't have some live-coding exercises during your interview, how do you know if they can code or not?
Far from it giving me a negative impression, it gives me a positive one, far more positive than trick interview questions or aptitude tests or other nonsense like that.
Take them up on it, and take the chance to perform a reverse evaluation on how well your interviewer knows his stuff, it's a two way street!
I can see this being more of a problem in closed source places. But, remember that an interview is a two-way conversation. There is nothing wrong with asking questions like "so, what version control system do you use" and running away when they reply "err, tar?" or whatever your personal horrors are.
You get a few false negatives, but virtually no false positives.
And to top it of, I hate github (their functionality should be build into the git client, I shouldn't have to check a web page to see if anybody has ideas to improve my code).
I still code every day.
I expect to see code from candidates.
They can either send in code beforehand or walk me through some code they have written. Either way, I need to see some code, ask them questions about it, and see how well they can explain the decisions they made when writing the code.
Someone who cannot talk naturally, authoritatively and objectively about code they have written is not someone we need on the team.
Also, as someone else has said in the thread:
"It tests ... whether they have a passion for the field outside of the standard 9-5."
This is a great point. If a candidate for a programming job tells me they have zero code to show (because of NDA or whatever) then I instantly know that programming is just a job to them. Again, not the kind of person we want on a tight, motivated team.
After work, the last thing I want to do is bang out more code.
The largest issue with this is you can lose out on really good engineers who view technology as their work, but not their hobby. There is a great number of awesome engineers who only do work within their employment, and therefore won't have a good repository of code to show potential employers.
A good alternative to this is to simply present a coding challenge to solve during an alloted time period (day/week).
I can't remember ever being asked to submit a code sample (and I've been doing this longer than some of you have been alive).
I've had a few places ask me to write some code during an interview though. I'd much rather that employers judge me on the production code I've written than something I wrote "on the fly" during an interview.
Granted such companies are pre-lithic in nature, but none-the-less, employers will miss out on great people because they think publicly available code samples mean anything at all.
In short, writing the code might not take that long, but all the other things you have to do would.
Is this legally enforceable? What state?
My (unasked-for) advice if you are a programmer looking for a gig is to put a project in some publicly-visible place like github. Or try out google codejam or topcoder for practice.
When I first heard about the fizzbuzz tests and the results from them, I was rather surprised. Scary examples abound.
I'm less about the "code challenges" that some companies do, because that's usually just a lame useless task. I'm more about giving potential hires a real feature we want to make, or bug we want to fix, and see if they can do a quick rev 1 of it.
I agree, asking code is better than asking tricky questions or other irrelevant things.
Also, I simply will not expend any effort on your company unless I really want to work there before at least a phone call. And not a phone call with your internal recruiters, but a phone call with my future boss. After that, sure, I'll solve a relatively simple problem for you -- I'll invest up to 4 hours. But after that? There's too many jobs around, and too many companies that treat candidates as if there time has no value for me to expend any more time.