Ask HN: Companies that ask for sample code before interview
I like to get opinions on what people think when companies they are interviewing asks for sample code for screening candidates.
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: 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. Another big factor, which I don't think you said explicitly, is that oftentimes the majority of applicants for a software development position seem to lack the actual ability to write code. There are many horror stories from folks doing hiring where they experienced applicants who seemed to lack the ability to write even simple, small applications. Granted, some of those situations could have been caused by pressure and nervousness, but other times it isn't. Some of those folks just can't code at all, but they applied anyway. It's something I didn't mention, but you're completely right. 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. In my experience, the horror stories are the _norm_ when interviewing for publicly-listed positions. I understand that some people don't perform well under pressure, but even so, that doesn't explain some of the things I've seen. 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. 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. 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/ You are much less likely to work with an idiot 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. Ahh, insight... 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?) runs code examples through standard analysis I am not saying that this would not be generally useful. In our case we're a specialised shop, without many short-listable applicants (we only ask code from candidates going forward to an interview), so it's no big deal for the tech lead to cast an eye over submitted code samples. Not looking for perfection here - just to give you a basic example, I had a candidate submit code that did not have a single comment in it. I mean even if you wrote the code in the first place with no comments (naughty you), surely you'd stick some in before you sent it to somebody you wanted a job from, eh? Obviously for the hotshot places that get hundreds of qualified applicants, that's a different story. Still, I think you can tell a lot about somebody's coding personality from looking at their stuff, not sure I'd trust a machine to do it. Similar things have been done. Here's one: I've heard of others but can't recall the names or what to Google for them. They started around the time Jeff Atwood wrote his FizzBuzz rant, iirc: http://www.codinghorror.com/blog/2007/02/why-cant-programmer... Since you asked... http://www.codeanthem.com I think this is a nice touch ;-) thanks for the tip on what to submit. I ended-up giving a small app I had done for a client. But, this may be better way to do it. Going one step further, I've preferred to see candidates with active open-source work available, and better yet, and active github account. 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? I'd see it as a great chance to show the interviewer in the most concrete way possible that you really know your stuff. 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! 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. I always mention the open source contributions of the team members to potential applicants and give them links that would enable them to find the source if they were so inclined. 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. This idea is awesome. I'm not interviewing these days, but someone please do it and report back on results. 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. Yeah, it would be a really hard sell for me to hire someone without a Github profile these days. I'm sure there are field where this may not be feasible, but it's a great and easy differentiator for us. You get a few false negatives, but virtually no false positives. I think you underestimate the false negatives you get with that idea. I can't be the only one who would rather do consulting or hacking at something that might at some point become a startup than doing open source. 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). It's tricky, I love open source and use it a lot. But likewise, after work I'm usually doing some work on my freelancing projects, half of which the client has rights to the source code for, but is not open source. Getting two "salaries" every month is useful for quickly building up equity. > I think you underestimate the false negatives you get with that idea. Maybe so, but false negatives are not nearly as disastrous as false positives. If someone hates github, I'd be fine looking at bitbucket, gitorious, etc too. =) I'm in a management position at a large ecommerce site. 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. I am a consultant and I work 12 hour days pretty frequently. When I get home at night I want to spend time with my gf, work out, play with the dog, etc. After work, the last thing I want to do is bang out more code. 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. 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). Yeah, you really need to ask for code tests not existing code you did outside of work. I wish it was normal practice. 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. 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. 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. Any programmer worth hiring has time to put together 200-500 lines of example code. Yeah, I think ideally any code sample they ask for should be something that any programmer competent for the position would be able to bang out in an hour. A twelve-hour project is unfair on the potential interviewee, but an hour is what you'd probably spend in travel time to an interview anyway. That would depend widely on what the code is supposed to do, how long it takes to set up the things my software should work with, etc, etc. In short, writing the code might not take that long, but all the other things you have to do would. > For instance, my employer requires that I can't admit that I work on (well known) open-source projects. Is this legally enforceable? What state? It doesn't matter: his employer can fire him for it. Even if they're legally forbidden from doing that, they can find a way to get rid of him without admitting the reason. IBM in Canada, from his LinkedIn. Not sure why it would be the case, but I suspect legal/patent type implications. 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. 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. 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. 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. They wanna see the quality of your code.
Your coding style says much about you. thanks all. This has certainly cleared-up my view. I am going to work on having some presentable code for the future. I agree, asking code is better than asking tricky questions or other irrelevant things. I think its great. If they don't like what they see, they don't waste my time interviewing further, and they know right away what they're going to get 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. 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.
Make it an example of what your best code looks like (OO, neat, testable & tested). Send the email to:
Y2hhbGxlbmdlQGRvdHNwb3RzLmNvbQo=