At my place of work we have a coding test that we issue to all applicants for the software engineering roles. Here are a few responses from our point of view...<p>1. We know you can probably code, you've already passed a phone conversation about your coding experience, but you may not have a GitHub profile (you might not be allowed to at your current place of work, or you might have experienced harassment through GitHub), so we're not going to penalise you for that.<p>2. We want to see your solution to a problem that we know REALLY well. We know the pitfalls, the places people often trip up, we know how to tell if your solution is going to be maintainable over the long term. That's why we want to see your solution to our problem, not just 'portfolio' code, or even a 'bugfix'. Not to mention the fact that the bugfix should be already done by the team, finding tasks that are low enough priority that we can give them to someone outside the team is actually difficult to do.<p>3. Our coding test is quite long (3 hours), but roughly capped, we ask candidates not to take longer than this. This is significantly less commitment for most than taking a day off work for a day of working/pair programming/etc. We do pair program later in the interview process, but not until we're pretty sure that bringing the candidate on-site isn't a waste of their time, and ours.<p>I realise that there are some devs who reject the idea of coding tests, but we have found it (in the form we do it) to provide some of the highest signal to noise ratio information in the interview process, and find it to be a really good balance of time commitments on both sides. Very few candidates drop out because of it.
Next blog post: Why I am unemployed<p>These coding tests are actually quite an equalizer in terms of interviews: you may be ace at answering all whiteboard/phone-screen questions, but when it comes down to actually coding -- something you are being hired to do, you can't crack it. On the other end: it lets people who may not be amazing at whiteboard questions the chance to show that despite that they can get things done.<p>When somebody interviews for a software engineering position, the goal of the company is to as quickly as possible get an objective opinion on the person by seeing how that person compares to other candidates they have seen. This is good for the candidate too, because who wants to be subjected to an arbitrary process?<p>All of the alternatives suggested in the article are fine, but they don't make the interview process very objective.<p>Things you can see during a coding test:<p>- How they tend to structure their code<p>- Do they like to over-engineer problems<p>- Do they dive right in or think things out<p>- How easy is their code to read?<p>- Are they experimental, do things in an interesting way?<p>- Are they prone to making bizarre design decisions<p>etc. etc.
Any time I see one of these rants I can't help but assume that the author has never been remotely involved with hiring from the other end.
The sheer volume of crap resumes you get from people that can't code is utterly astounding, especially from recruiters.
A simple blanket "Yeah sure here do this test first" is necessary to stop your engineers drowning, though even then you still get a whole bunch of recruiter forwarded candidates that simply cheat on any test you give them, automated phone or otherwise.<p>That said, if a company is actively trying to poach someone, asking them to do a coding test is rather stupid, since you wouldn't be going after them if you didn't know they were good.
These discussions are always frustrating, because both sides have perfectly sensible points.<p>From the employers' side: They really really really do get many candidates who cannot program at all. I've been on the hiring side and seen the applications, and the amount of worthless non-programmers out there is high. And it's not just for entry-level posts -- plenty of these people have a decade of experience and titles with "Senior" in them. A simple "can you write code" filter is absolutely essential for a hiring manager not to spend all their time interviewing terrible junk candidates.<p>From the developer's side: If they're any good at all, they really really really can get hired by a company they want to work for very quickly and with little effort, and so their motivation to jump through hoops is going to be low. If ten companies want to hire me, and two of them want me to spend half a day doing coding problems, well, guess who I'm going to get back to last/never.<p>The employers aren't stupid. The devs being interviewed aren't stupid. Everyone has totally sensible priorities.<p>So this really just comes down to individual situations. If you as an employer are having a hard time finding people and you're requiring a coding test... maybe quit requiring it, see if you get a broader applicant pool. If you as a developer are having a hard time finding a job and are rejecting employers that require a test... well, suck it up and do some of the tests.<p>But if a developer is happily employed or an employer is able to find good devs, well, maybe you've hit a good compromise point for now, but be willing to re-evaluate in the future.
It seems to me that there's a high-end piece of the market where none of this applies.<p>If you're really good, you can go your whole career without ever having to throw your resume over the wall and wade through this sort of filtering process. And if you have an experienced team who have worked with lots of good devs in the past, you can reach out directly to them and go straight to the hiring part of the interview.<p>It's only where those two ends have to interface with the rest of the hiring universe that you see friction like the author describes. If you're the guy who built Big Thing X and some random company tries to get you to spend 3 hours on their coding test, you're going to say no and they're never going to find anybody half as good as you. And if you're a team of Good Devs at a Genuinely Good Shop trying to hire with a job ad, you're going to get a thousand applicants who can't FizzBuzz and you'll develop scars in the form of coding tests.<p>I think the key as a developer is to rapidly get one's self into that category where you don't need to deal with this crap. The last time anybody dared hand me a coding test was a good fifteen years ago, and that was the last they ever heard from me.<p>I bet I'm nowhere near alone in that department.
Where I'm at now, I kind of skipped doing their customary coding test, because someone else vetted my competence.<p>Now that I think about it, having observed some discussions about other candidates' solutions, I don't know if I would have passed.<p>I can bring plenty of value to companies because I have broad knowledge, good taste, and devotion to product quality... but sometimes my first draft of a solution to an algorithmic problem is a little strange, or simply doesn't match the tastes of other reviewers for whatever reasons.<p>So I'm pretty skeptical about these things. They seem to me like a bad way to effectivize the process of judging someone's competence. I would rather have a real conversation about what they've done, and try to collaborate with them for a while.<p>If I can't find a candidate with whom I can have a good conversation and whom I trust without having them solve a puzzle, then I'd rather not hire anybody.
From my experience I kind of disagree that you can weed out non-programmers by looking at their Github profiles. This might work for people that have a lot of projects/contributions there, but it doesn't work for most Github users which have (if at all) only a few stargazers and no very active projects at all. So if we'd use Github data to weed out people based on their repos/stargazers count we would probably miss a lot of very good programmers that just don't happen to be active there.<p>A simple coding test (ideally in a live environment over Skype) on the other hand allows me to (very roughly) judge a programmer's general ability within 10-15 minutes: Does he/she know the standard libraries of the given programming language? How does he/she structure the code?<p>Simple problems that are roughly related to your field of work are suited best for this from my experience. For example, as we work a lot with graph data, one task we often use is to load a set of lists containing vertices and edges from a JSON file and convert that into a linked graph structure within Python.<p>When hiring senior people most of this is usually not applicable as you can rely more on recommendations and the previous work experience of the candidate, which should give you better information than Github profiles / live coding tests.
Try hiring and getting flooded by applicants who can hardly implement `min`. It would be a waste of the company's time to bring all those applicants in. So long as they're not asking for a ton of my time, I don't mind doing a simple screening.
At my last job, I was hire #3 and skipped the entire interview process (had worked with my boss for a couple of years already, so that was interview enough). As we ramped up the staff to 20+ we added rigorous interviews until it got to the point where I'm not sure I could have passed it, despite being one of the most productive members of my team in real engineering situations.<p>Similarly at my new company, our coding test is geared toward people with different responsibilities from mine. I'm very much big data / Spark, whereas the test is geared toward full stack developers. They skipped it for me, which is good -- I doubt I'd have passed it.<p>All this is to say, I am skeptical of code tests. I've seen some value (when we filter out really bad apples who can talk well but can't code) but I've seen a lot of negatives, too.
Yeah, the company I work for uses a coding test. It's a simple CLI program that is relevant to our product, business analytics, that we ask them to spend no more than 2-3 hours on. The test has several tasks to complete, we make it very clear that someone who completes only 1 task but has excellent code structure, unit tests etc etc is more likely to get the job than someone who just blitzes through all the tasks.<p>The task avoids assuming any knowledge of algorithms / advanced maths / databases or web frameworks. We're only interested in their approach to solve a problem with code, not what libraries they've spent years learning, or what project euler problems they've committed to memory.<p>I came up with the test after I was going round a job fair (for the free stuff) and was handed a coding test to produce a simple CLI twitter clone. I had no interest in applying for the job but I did the coding test anyway. It's only 2 hours of my time and I find coding / solving problems fun.<p>It's really helped us distinguish developers who see work as a 9-5 job that they only do because they must and those developers who just love solving problems. Maybe the technical skills of those 2 developers are roughly equal, but one of them is going to be far more valuable long term than the other. So far we've only hired one candidate after introducing the test, and they've been the best hire we've made.<p>As a side note, we always do a phone interview first so that we don't waste time (ours and theirs) giving the test to complete no-hopers.
We had a candidate who graduated from an Ivy League school who refused to take our code test with: "I went to ____, I shouldn't have to do this." We would have probably considered him if he asked "Can't you just look at my Github" like this person but as it stood we rejected him outright because someone with that attitude is not likely a cultural fit for us.<p>However, from the article point for point...<p>"I know how to code, and can show it" -- we don't have the time to read your entire blog and all your GitHub commits. We have hundreds of applicants.<p>"I have a day job, and several side projects: I won't spend a sizable chunk of my free time so they can tick some boxes about my coding skills." -- our software engineers have a job too, they can't spend several extra hours per candidate (when there may be hundreds) to look over your stuff. Second, the time it will take you to do this is WAY less than driving to the office for any of the other suggestions.<p>"work with them on the real job, and see how it feels" -- again, does not scale at all.<p>Maybe he has never been on the other side of the table. But we reject 48/50 people. Many of whom couldn't even do Fizz Buzz. The tech test is a way to make the process scale and make it so we don't waste time. If each of those 48 people cost even one hour of engineering time we just lost thousands of dollars.<p>Edit: on second thought, he did say the company reached out to him. We do tend to do things differently if we reach out specifically to a person. But we do that very rarely.
I don't like coding tests, but they are far better than the alternative: these typical multi-hour interviews involving lots of white-boarding fake code.<p>A venture-funded company who's entire technology stack is a basic Rails CRUD app grills you (in a room, or over the phone) about hypothetical uses of CS fundamentals that none of their own employees have touched since college.<p>I'd always rather establish my competency by submitting real working software I've written or solving some trivial coding challenges, rather than trying to solve these random brainteaser problems live in a high-stress, timed situation.
The prevalence of these tests and the emphasis employers place on them should really put to rest that nonsense about "your Github profile is your CV" once and for all.<p>Recruiters are generally non-technical and unable to judge the quality of your open source work, and employers generally don't give it more than a cursory glance. And while Github profiles are needlessly abstruse, I doubt even a portfolio specially curated for their viewing would fare much better. Employers just don't care; they know that it's a buyer's market for talent and that there are more than enough applicants willing to subject themselves to their interview process, however abusive or insulting it may be.<p>Since almost no one ever gets a job because of their open source work, why do employers still make such a big deal out of it, with some even going so far as to state that they won't look at a candidate without a Github profile? Because it shows "passion," and a "passionate" developer is one they think they can more easily take advantage of. That's it.
Code tests are:<p>1. Intrinsically unbiased.<p>2. Applicable for remote candidates.<p>3. Easily verifiable (unlike a github repo)<p>I'd take code tests over alternative interviewing methods any day.
If I am already employed or not desperate for work, I will not do your coding challenge unless you pay me for it. Why? Because you get most (all?) of the benefits of the exercise but I need to do all the effort. Actors do get payed for doing castings.
An X hr coding test is very different than an X hour interview.<p>The interview process is intended to be a bi-directional flow of information. Giving someone a X hour programming test means that for X hours, the company gets to learn about the developer, but the developer doesn't really learn about the company.<p>The company is the one paying salary, so they set the terms of the interaction. But the feel of disrespect for the developers time is real and valid. If you chose to do a coding test, do so respectfully to avoid insulting the person you potentially want to hire.
I take coding tests when they require up to 3 hours of my time. Once I had a company send me a coding test that they said should not require more than <i>20 hours</i>. And that was after a 20 minutes talk with the hiring manager. My first convo with anyone on the team.<p>Asking me to put 20 hours before even meeting the team is laughable. But, seriously, 2 hours is fine. It is fair since all candidates get the same test, plus it gives something to talk about during in-person interview and help avoid the f-ing coding at the whiteboard.
As a company interviewing candidates, we see the recruitment process much like a conversion funnel for any website: there will be a lot of hits on our spec, some people will apply, of which some will do the telephone interview, of which some will get through to the coding test, and so on.<p>If OP doesn't want to do a test, then he will just end up as one of the ones that didn't make it through the funnel. This then boils down to whether there are companies out there that will take him on his project's merit or whether OP is desperate for a job.<p>A couple points I disagree with:<p>* "My main gripe with coding tests is that they ask me for an investment of my time and resources so that they can gather information about me, but I'm getting nothing back." -- you can potentially progress to the next interview stage, you will refresh your memory on coding tests, etc. There is still something to be gained.<p>* "I've already expressed interest in their position." -- there is minimal effort required to apply for a job. As an interview we get swamped by CVs that all look equally similar - we often need something to distinguish between these CVs. We have seen a wide range of coding test submissions and from this you can glean how interested the candidate is.<p>Finally, while the OP's suggestions are sensible, they are not always practical for companies, especially when it scales. We can't afford to be distracted by bringing a candidate into the office and work with us especially if we have multiple candidates. Even if the company decided to bring someone in, and assuming the candidate is capable, it will take them the better of a day to get up to speed and running -- setting up the dev env, getting the source, building it, making sense of the application, making sense of the feature/bugfix, making sense of the coding style, etc. They won't be effective enough to actually check in working code.
Speaking as a hiring manager, I won't even TOUCH a technical candidate without a coding test. Nope, burned too many times with resumes that were utterly bogus. Not wasting my time. Ideally administered at the whiteboard in front of me, so I know you didn't pay someone $5 on a chat board to do it for you.<p>It's not a big one - primary goal is to validate that you've actually worked with a database before. Relevant to the job.<p>But seriously....<p>- The "Oracle Certified SQL Developer" who fessed up that she didn't know SQL (couldn't even write a basic query)<p>- People that couldn't identify how to join tables...<p>- The "Google / Motorola" Python Dev who didn't understand the difference between a list and dict (which is basic to the language, very first chapter of Dive Into Python)<p>- And massive inattention to detail (leaving out entire sections of the request in their query)<p>Someone else can go attempt to manage them. I'm busy....
I have also been frustrated and surprised by the technical interview process. For a Google interview, they had me cmd+tab-ing between a google hangout and a google doc (for the code). Why isn't there something simple and free that puts these two things together?<p>So I took the approach of trying to improve it by creating a small side-project that is just a simple collaborative code editor and WebRTC video/audio connection.<p>One-click deploy to Heroku, open-source, MIT licensed.<p><a href="https://github.com/crcastle/collaborative-code-conference#readme" rel="nofollow">https://github.com/crcastle/collaborative-code-conference#re...</a><p>Feedback welcome!
I really think this madness will only end if we all refuse to do coding tests, subject ourselves to multi-day interviews, etc. I do understand that this is easier to say when I have a job.
My previous company had what I think was a good hiring process: they required about 500 lines of Python code (it was a mainly django shop), and if your code was good, they'd ask you to go there one morning/afternoon and implement some minor feature in the development codebase.<p>For frontenders, the process was similar, but they'd ask you for some mix of JS/HTML/CSS.<p>The 500 was a somewhat arbitrary number, but it was basically "show us a good amount of what you have done". In my personal case, I sent them a link to one of my python libs in github, but some people without github sent some files like headers and implementation (like one or two guys for a ObjC role).<p>If you passed the initial code review, survived the day with the team, they would still ask for one or two contacts of previous co-workers, teachers, etc., just to have a chat. In the end, we had a very very good team there!
"I won't spend a sizable chunk of my free time so they can tick some boxes about my coding skills..." but you don't mind spending an entire day (for which you presumably took a day off work, if you're currently employed) doing it at their place of business?
It is strange how he mentions that one of their goals might be:<p><i>2 Only get the developers that are interested enough to perform their test in a ordered and timely manner.</i><p>and then dismiss it so lightly:<p><i>I've already expressed interest in their position. I have a day job, and several side projects: I won't spend a sizable chunk of my free time so they can tick some boxes about my coding skills.</i><p>Maybe they are not interested in people who have so little motivation.
When I want a full-time employment, companies get crazy about who they hire.<p>When I want a consulting gig, companies seem to give money to whoever comes first.<p>In the end it seems like getting an employment is a bad thing to do, since there is no real benefit of having a secure job for an engineer, because everyone is willing to pay her money for consulting stuff anyway.
Feedback from Reddit:<p><a href="https://www.reddit.com/r/programming/comments/4daew9/why_i_wont_do_your_coding_test/" rel="nofollow">https://www.reddit.com/r/programming/comments/4daew9/why_i_w...</a>
So far spending a day (or two) onsite and working on something together with the team has been the best option for me.
You:
- get to see what people are, how they work and what they do
They:
- learn whatever they need about your skills<p>So it's a win-win.
It may not help that the site for your cited example of a working app is returning an error:<p><a href="http://www.coverr.me/" rel="nofollow">http://www.coverr.me/</a><p>Though perhaps it's only meant for light load and HN is overwhelming it.
On the plus side, the really good companies who eschew shitty coding tests become even more attractive to good candidates.<p>If you are going to start a potential employment relationship by asking me to acquiesce so readily, it doesn't bode well.
Next blog post from the hiring company "why we continue to moan that we can't find devs despite having a shitty coding test".<p>I am with the blog poster here - fuck you and your coding test.<p>I lowered myself to do one recently, we walked through it in the next stage interview, where it became apparent the " tech leads" were incompetent muppets, who were intimidated when they saw a better solution then they had as their "approved" answer. Walking through slowly with them why their solution had poorer performance at both low and high volume, I was left with the distinct impression that the vast majority of the incompetent devs who would fail fizzbuzz are somehow doing the hiring.<p>Scary times!