I like to get opinions on what people think when companies they are interviewing asks for sample code for screening candidates.<p>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.
Code samples are informative to hiring managers for a few reasons:<p>1. They immediately weed out the people who apply to a hundred jobs at once without actually considering the position.<p>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?<p>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.<p>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.
This is pretty normal (although not common, per se) and is generally a good thing. Good employers want to confirm what they see on a resume, because there's so much fluff out there. There are multiple ways of doing this: coding tests, open source, code samples, etc, and it's just a matter of personal preference of the hiring manager.<p>You have to see as a benefit to you (assuming you're competent), because:<p>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<p>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<p>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 <a href="http://dotspots.com/jobs/challenges/" rel="nofollow">http://dotspots.com/jobs/challenges/</a>
Going one step further, I've preferred to see candidates with active open-source work available, and better yet, and active github account.<p>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.<p>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?
I'd see it as a great chance to show the interviewer in the most concrete way possible that you really know your stuff.<p>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.<p>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!
Not to get us off track, but has anyone ever asked a prospective employer to see a sample of their code? Taking a job is a big risk, and I'd certainly want to know what I was getting myself into code-wise.
If you are applying for a coding position, you should be glad that they are predominantly interested in your coding skills. There is no substitute for real code to judge that.
I personally put a link to my github account on my resume. One thing to bear in mind if you take this approach is that as long as you have a couple of good projects, quantity is more important than quality especially if you're new. It shows that you like what you do, and if nothing else shows that you've at least gotten some of your crappy code out of the way.
I'm in a management position at a large ecommerce site.<p>I still code every day.<p>I expect to see code from candidates.<p>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.<p>Someone who cannot talk naturally, authoritatively and objectively about code they have written is not someone we need on the team.<p>Also, as someone else has said in the thread:<p><i>"It tests ... whether they have a passion for the field outside of the standard 9-5."</i><p>This is a great point. If a candidate for a programming job tells me they have <i>zero</i> 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.
For certain types of positions I think its a really great litmus test. It tests a applicant's personal discipline in coding as well as whether they have a passion for the field outside of the standard 9-5.<p>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.<p>A good alternative to this is to simply present a coding challenge to solve during an alloted time period (day/week).
I <i>wish</i> it was normal practice.<p>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).<p>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.
My feeling is that code samples are good. One of the best programmers I recruited for a starup worked @ Wells Fargo and was getting an MBA (undergrad was chemistry). I fought hard for him to get the interview. He ended up getting the job because he nailed the coding exercises.
Requiring a code-sample will increase the false-negative rate quite a bit. A lot of employees can't provide samples of their work because of NDA, contract, or other legal reasons. In a perfect world, everyone would have some side-projects, but not everyone has the time for side-projects or is permitted to contribute to open-source projects. For instance, my employer requires that I can't admit that I work on (well known) open-source projects.<p>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.
Even more of a practice is to ask for you to code or solve problems or build a small something-or-other during the interview process. This seems pretty common.<p>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.<p>When I first heard about the fizzbuzz tests and the results from them, I was rather surprised. Scary examples abound.
When I hire, I want to see the hacker's github account =) Projects they work on, the community of hackers they're connected to, their insight to technology, that's all extremely important.<p>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.
If they are going to pay you to write code, it's reasonable for them to ask you for code. It's like asking a cook you want to hire to show you some of his dishes. Makes perfect sense. Obviously, writing free/open source software helps here.
thanks all. This has certainly cleared-up my view. I am going to work on having some presentable code for the future.<p>I agree, asking code is better than asking tricky questions or other irrelevant things.
Personally, I don't have a ton of code that isn't owned by someone -- either my current employer or a former employer (I delete all code from jobs I quit, but do have code left from consulting gigs). I obviously will not share any of the above. Other than that, I my personal projects tend towards the math heavy -- lots of R and matlab. Nothing like production code that I would write.<p>Also, I simply will not expend any effort on your company unless I <i>really</i> 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.