Building a full production grade website seems extreme, but giving a prebuilt website to a front end candidate and asking them to add a few simple pages or features is basically fizzbuzz type vetting. I also like it when coding "challenges" are timeboxed to say 1-2 hours. This keeps the time expectations reasonable for both the interviewer who has to read a bunch of candidates' challenges and the interviewee who has to do them for (potentially) a bunch of gigs.
The type of coding challenge a company asks (interview questions also) can be one of the most important data points to use to judge a company's culture...
Yes exactly, this is overboard. We have "take home test" (I hate that term but haven't come up with anything better) for both our front-end and back-end candidates. They're
(a) Short - 45 minutes to an hour
(b) Only as complex as necessary (for the front end we provide and end-point serving JSON, for example, so they don't have to worry about that)
(c) Real problems we've run into, distilled down into a form appropriate for an interview
(d) Made up of problems that we were having candidates do on the whiteboard before we developed the at-home test, meaning they're not super complex
I think that at-home coding is the perfect second step to an interview (after a phone screen). It's more realistic than whiteboard coding. You have the internet at your fingertips. You don't have the pressure of an interviewer sitting there. You have syntax checking. From my side, I don't have to waste 30 - 60 minutes on a bad candidate. And, assuming the code is good, reviewing it provides an awesome first hour of an in person interview. And the problems I give you to take home would have been given to you in person anyway, so you're not spending any more time than you would have if you'd just come in for an interview.
The issue here is that the tests he's being given are bad examples of a take home test, not that take home tests are bad ipso facto.
Yes absolutely. They're all problems that we've solved in the process of building out our product. In addition to that, as I mentioned, we originally gave them as white board questions, so we're well aware of the issues that come up when solving the problems and the effort required to resolve the issues.
Our front-end test is a bit longer than the back-end test with a tradeoff of a shorter in person interview, but the front-end test shouldn't take more than 90 minutes.
One of our problems is a small matching algorithm. Another is a thread safety problem. The front-end test consists of pulling JSON data from a server, formatting it, and posting a single action back to the server. It sounds like we're in a minority though. Reading these other posts it seems like a lot of the tests are very onerous (build a small trading system? that is a ton of work).
> They're all problems that we've solved in the process of building out our product
Have you gotten feedback on the questions? It's easy to say that it's a valid question, but when you're close to the problem, it's easy to make a mistake since you might encounter a specific sort of problem that others might not be nearly as familiar with.
The difference to me I think is that yours are very specific, and "build a small trading system" can be very general. If it's timeboxed, there might be only so much that you can do--i.e. you might not be expected to complete the task. You want to test someone's knowledge, without being too 'in depth'. A candidate that can solve a problem on his own in 30 minutes isn't necessarily better than a candidate who can solve the problem in 10 minutes with the assistance of Google.
If a company asked me that, I'd tell them thanks but no thanks and end the interview. Ask me a few questions, have me solve your riddles, see if I'd work well with your team/company. But building an entire production ready site? Ain't nobody got time for that.
Pretty sure no interviewer ever asked for a production ready site, this is just hyperbole from you and the author of this article.
If I were a front end developer, I would much prefer to be asked to write a quick, tailored to fit within the time allotment (e.g. one hour) web site rather than answering obscure coding puzzles that probably have little relevance with what I'll actually be doing at the company.
As the interviewer, I would phrase it as: "Build as much as you can in one hour, with the following functionalities in order of decreased priorities: login, cart, etc...".
Then I would judge you on how much of it you built, how solid each of the features are, etc. In my book, you can choose to go broad (build a lot of features, albeit superficially) or broad (only a few features, but well designed, tested, clean code).
> Pretty sure no interviewer ever asked for a production ready site this is just hyperbole from you and the author of this article.
How can you be so sure? Were you there? You're essentially calling the author a liar without even pretending to have access to more data than that author. Thats just rude.
If you know something that the rest of us don't that would lead you to make such a forceful assertion, please share.
> Pretty sure no interviewer ever asked for a production ready site, this is just hyperbole from you and the author of this article.
I'm sad to say that this is untrue, and that in writing this article I have not exaggerated the requirements in the least. I'm not going to name the company, but the requirements of the challenge indicate that it should be something you would be comfortable putting in production.
The "challenge" is a repo on the company's github. I'm sure you could probably easily find it with a bit of sleuthing.
I never claimed this happened to me, I was speaking hypothetically to the authors situation.
I have had companies ask for an idea or some sort of feature to develop for the company and refused because it was essentially a "do some work for us and we might hire you" deal.
I wouldn't end the interview then and there. Instead, I'd pull out a copy of my generic freelance contract, fill in my billable rate for the project after reviewing the scope, and end the interview after they refused to sign it.
My opinion is that companies that think unpaid "code challenges" are a good idea don't respect my time enough as an individual to be worth it to work for. It's a signal that they're either going to have an awful work/life balance or that they are filled with unjustifiably arrogant "rockstars" in a caustic environment of petty elitism (or both). The latter signal applies especially if the company's product is some web "application" for the young-20-something set.
The code challenge is usually just one part of the interview process to see if you can produce a quality product within a certain amount of time. It's not designed to tell every single thing you outlined in your post. It's meant to provide some signal before the actual on-site interview occurs. The on-site interview is expensive on the company's part, it is easier to filter out people who can't solve a simple full-stack solution. Companies who ask things like these are looking for people who understand both front and back ends. In short, just knowing either front or backend but not both, is not enough for the company.
I have to say, that headline font is awful and the link highlighting on the blog's front page is worse. There is a bit of oddness in declaring yourself a front-end person by talking about not needing to be tested as a back-end person when you're applying for a front-end job yet having a blog with a such a jarring front-end.
I hope one day we can get to the point where we discuss the content of a post on HN, and not cast subjective opinion about its presentation.
I don't think there is anything wrong with the headline font. I'm not too fond of the link highlighting used on the front page, but it's fine. Really. And you can be a "front end person" and have very, very little to do with design these days. Entire webapps are made on the front-end.
Presentation is always important. It doesn't matter if it's a scientific paper or blog, presenting in a clear and intelligible way is critical to communication in all forms.
As for the content:
I've dealt with numerous developers who only want to do one thing, only backend, only front-end, only design. I've constantly run into shenanigans when working with such people in a fast paced dynamic environment. "I can't work on the frontend till the backend api is finished", "I can't work on the backend till the frontend data requirements are defined", "I can't work on the frontend till the UI/UX are defined". It's a never ending requirements dependency argument.
More capable full stack people are able to mock or fake the bits that are as of yet undefined allowing them to continue working on their core piece while gaining a better understand of the system as a whole. This allows them to contribute to the product definition at all levels instead of just living in their own little piece of it, waiting for definition from outside.
So, I decided to treat your awful comment like you decided to treat the original article.
> I have to
That's not true. You don't have to reply. No one is requiring you do that. You've already started off by lying. This means anything else you might want to contribute is awful and worthless.
> say
You didn't. You typed it out. I'm pretty sure you didn't "say" anything. And now you are trying to be confusing. That's just awful.
> , that headline font is awful
Well, that's your opinion. Your opinion is worthless because you haven't validated your credentials.
> and the link highlighting on the blog's front page is worse.
So, not the page we were directed to. Did you happen to check out his Facebook page, too? Did you decide to comment on his awful dinner choice last night?
> There is a bit of oddness
This whole sentence is odd. In fact, that sentence is far worse than anything the OP did. You would say it's awful. In this case, you'd be right, because it's a shit sentence.
> in declaring yourself a front-end person by talking about not needing to be tested as a back-end person
That's not what he's doing. He's saying he's a front-end person, and was tested for back-end work. He's not saying he's a front-end person by talking about not needing to be tested as a back-end person.
Those are two completely different things. If you don't immediately understand why, I apologize, but you wrote the awful and confusing sentence.
> when you're applying for a front-end job yet having a blog with a such a jarring front-end.
What's jarring about it? Surely you aren't speaking of the design. That would be a designer, not a front-end person. And we've established he's not apply for a designer's position.
Unless you are suggesting all designers should be expert programmers? Because that's the only way what you said remotely makes any sense.
His complaints seem to be that this method of take-home-project is not as good as the method of hiring the candidate to work in the office temporarily for week's trial. That is true, but this is still superior to a typical interview. (Also not all candidates and not all employers can spare a week to do a trial.)
Nevertheless you should never agree to complete a full production project without being paid.
Is it? I "interviewed" at one YC funded startup in particular and they asked me to build a trivially small and simple js application (even though I applied for a DevOps position, but I guess devops is different for everyone...). The only communication up to this point was over e-mail and I sent a resume.
I built it. It worked. Then they said my application was not aesthetic enough and said thank you for your time.
The whole thing seemed backwards...
In my opinion (as someone who has been going through the process for a few years now throughout undergrad with internships and now looking for a full time job at the end of my masters), very few companies do the "coding" problem right.
I don't want to work for you if you ask me to write a nested for loop and regurgitate the overhead involved in searching a b-tree. I also don't want to work for you if you ask me to build a application with no pre-defined criteria.
In my opinion...the best coding question you can ask me is fizzbuzz types of questions or pseudo-code for something complex (to see if the candidate can think through the steps of solving the complex problem without having to waste the time solving it).
Lately I have been solving coding challenges. For the sake of solving them only. I submit them, wait for "good job!" or "nice work!" and move on to the next challenge--at the next company. After a few months or years of doing this, I may decide to advance to technical phone screens on shared documents. I'll try that for a while. After that who knows...
I understand the desire for a challenge, but you might consider not submitting them. Effort goes into advancing a candidate's application at each stage, so someone out there is wasting their time so you can get your "good job!" boost.
It's a tough market. It can take years to hone your problem-solving skills. And years after that to hone your technical-phone-screen-on-shared-document skills. This takes deliberate practice. When I'm ready to advance to the next stage, I will.
There is a serious point: companies often aren't forthcoming about day-to-day working conditions. But the response you get to your puzzle solving activities can be telling.
Even "small" programming assignments take a lot of time. Several years ago, I applied for a job as a developer for a financial trading system. The take-home assignment was to build a small trading system that received buy and sell orders from the command line, and executed trades when the price matched. The input was just: buy/sell, price and number of shares.
This functionality is pretty simple, but it still took many hours to code. My feeling was that they thought it would perhaps take an hour to do. It was fun and interesting to do, but it took much longer than I thought. I think the companies giving the challenges should have their own engineers do the task, so they get a good handle on how much they are asking from the applicant. And of course it also depends on if it is a buyer's or seller's market (jobwise that is, not in terms of my "trading" system). If there is a lot of competition for developers, maybe they should give too big projects.
We used to ask job candidates to do something similar.
Since then, publishing code samples became the normal thing to do, so we simply require code samples instead, and give out the coding task only when they have nothing at all to share with us.
If you're in the job market, publishing some sample code, even if it's just a throwaway toy instead of, say, a full blown OSS project, can be a great tool for people to evaluate you as a candidate.
I would never go to an interview which wanted to present me with a code challenge, and I don't have publicly available code repositories for you to browse.
What I do have is years of experience building mission critical applications that move millions of dollars per day in transactions, and I have a solid track record of being easy to work with. I am good at what I do and I work hard to be an asset to any company that employs me, and I work hard to be enjoyable to work with.
If you can't be good enough to figure that out from a conversation and looking at my track record, why would I work for you?
BTW, I haven't had to look for a job in over 13 years - although I've worked for several companies during that time.
tl;dr: if companies know that they are going to miss quality candidates with a code challenge, and are ok with that, it's ok to have one. If candidates are ok with giving some companies the miss because they won't put up with a challenge, that's ok too. And code challenges are good for some types of positions and not others.
I agree that companies are excluding people such as yourself with these coding challenges. That's their right, just as it is your right to not apply to any companies that require such challenges.
If someone is finding good candidates with a coding challenge, that's great. If someone is finding good jobs while avoiding coding challenges, that's great too.
I will say that there's some nuance implied in your comment that simply isn't present in any of the github/coding challenge blog posts that have popped up on HN over the last few days.
Whether a coding challenge is appropriate doesn't just depend on the company or the candidate--it also depends on the position! It's far easier to test junior/mid level skills than senior skills in a 1-2 hour task. Geez, some of the skills you mention above would be hard to test in a 1-2 day task.
When you are looking for esoteric, softer, or more senior skills (requirements gathering, or architecture), you need other ways of evaluating candidates beyond a code challenge. Things like what you suggest: conversations, references, etc. Of course, there are some "senior" folks out there who aren't great coders even though they talk a good game, and if coding is what the position requires, a code challenge is fine.
> What I do have is years of experience building mission critical applications that move millions of dollars per day in transactions, and I have a solid track record of being easy to work with.
> If you can't be good enough to figure that out from a conversation and looking at my track record, why would I work for you?
Just because you can get something done, that doesn't mean you did it by writing well-thought-out, sanely structured, maintainable, readable, useful code. I mean, you probably aren't bad if you're bragging about yourself like this, but who really knows until the code is visible?
The language and environment we work in isn't known for high-quality coders. Quite the opposite. Filtering out the wheat from the chaff is basically a requirement, even for the people that seem good after a phone screen and an in-person interview.
"Just because you can get something done, that doesn't mean you did it by writing well-thought-out, sanely structured, maintainable, readable, useful code."
At no point did I claim to 'just get things done'. YOU said that. What I wrote was that I have years of experience building mission critical applications (which, of course, I would not claim if I could not prove).
It's not hard to prove or disprove if someone knows what they are talking about. I view 'coding challenges' as a sign that the company is not confident in their ability to assess people. It's a red flag to me. It's an amateur move. It tells me a LOT about the company from the inside, and it's not good.
'Coding challenges' are for companies who don't understand the skill set they are hiring for. I've hired plenty of devs over the years as well - we've had some bad ass programmers who worked for us, and I never needed a coding challenge to figure out who to hire.
Totally agree. I am so busy creating and making real products, that I just don't have time for silly quizzes or challenges. If you like my work, hire me. If you don't, then don't waste my time. I was seeking employment in the Bay area briefly and did three code tests. Absolute waste of time that didn't reflect my skill, diligence or anything for that matter. After I realized that these techniques were the norm, I quit looking. I have way better things to do with my time.
Pro tip: these tests are filtering mechanism on only one candidate funnel. Go figure out a way to get in through another funnel. Impress someone at a meetup, send a targetted email. If you can't distinguish yourself from the masses, you are the masses.
Personally, I wouldn't bother. Asinine requirements are usually the product of asinine leadership and toxic environment. Just find another company to apply to.
On the other hand, as someone currently looking for my first dev job, I'd /much/ rather have a take home code challenge, where I can work at my usual pace, with my usual tools, without stress than have to do a code challenge while someone hovers over my shoulder. The take homes have been time intensive - I would say the average one has taken about 15 hours to do, but I feel they much better reflect my ability to code than real time nervous coding.
Your perspective changes when you need to find that extra 15 hours of time while also working full time. Apply to 2-3 companies at once, and all of a sudden 30-45 hours are added on to your normal work week.
I actually had one of these and I won't do another one either.
Here's the gist of how it went down:
1) first part was the "personality" interview. Two "HR" people blew smoke up my ass for about 30 minutes about how awesome my site and my work was, then asked me to do a "code challenge". I agreed - I mean, how bad could it be?
2) The code challenge. I was given a PSD with a straight forward design. Asked to code it, make sure it worked in legacy browsers, publish on a server and show them the code on GitHub
3) Passed and then was asked to come back and explain some of my coding decisions. I was told this was more for show and I was already in effect hired, I just had to pass this last hurdle. It turned out to be a very confrontational, inquisition type of an interview. Not at all the type of laid back code review I'm used it.
I got pretty frustrated by the two "Senior" devs who seemed to take great pride in tearing my code and my decisions apart. After my first heated exchange with one of the devs, I actually asked them how many of the sites listed in the gallery on their site they actually tested and validated the code on. They said "All of them, why do you ask?" I told them I actually ran all of their sites through the W3C validation site and none of them passed. Every single one had over 60 errors on it. I basically said, "If standards are so important to you, then why are you holding people who don't even work for your company to a higher standard than those who actually do?"
There was a long silence and then I finally spoke up and said, "Clearly, this company has its priorities in the wrong order. Thank you for time, but I'm not interested." and got up and walked out.
I got several worried calls from the company recruiter, but by then I was so pissed at how much of my time they had wasted, and vowed never to do something like it again.
c) Push the interviewer to defend their decisions, and see how they react. If you can't defend your decision to intelligent people with strong opinions (!== assholes automatically), you won't make a good developer
> I basically said, "If standards are so important to you, then why are you holding people who don't even work for your company to a higher standard than those who actually do?"
Well, you want to hire people who are better than you, not worse than you. Hiring bar at a good company should go up, not down, as it grows.
I'm amused that you take so personally the concept of a professional who's not familiar with your competencies trying to evaluate your ability. Which by the way is more than just pumping out code, it also involves defending difficult decisions to your peers. If you can't handle a little pressure from a code review, find a new career.
I think the problem can be that many times there aren't difficult decisions to be made to solve most coding challenges. Getting grilled over trivialities or obvious decisions makes the interviewer seem either incompetent or like a micro-manager, neither of which would make me seem happy to work with them.
There's a difference between evaluating abilities and trying to engage him in a pissing contest. Interviews should determine if the candidate will deliver what he's being paid for, nitpicking and flamewars can be saved for future coffee break entertainment. "It's not my solution therefore it's shit" is not what code review should be about.
I happen to really like coding challenges. I much prefer them to a "technical interview" situation, which I find very stressful--trying to answer difficult questions in real time.
However, the coding challenges I've done for applications have always been in the vein of "solve this interesting puzzle and show us how you did it", not "do some boring day-to-day work, but do it for free".
With the exception of my current employer, who asked me to make a small static site with some JS oddities (about 6 hours total), they've all been fairly simple challenges just to get a grip on my thinking process, not really have me do the routine stuff.
I agree and disagree. I am a candidate and prefer coding challenges provided they are reasonable. Meaning, if you are wanting to check the person's ability in x, check the person ability in x, not y. So for example give a starter code with part that would showcase person talent in x is left out. Yes, this involves prior effort on the part of the company to come up with this exercise and on the person. I don't quite vouch for code samples, because it is very difficult to understand where they came up with the ideas and who wrote the code, and if it was a multi-person project. In the former case, it is a very controlled experiment and one you designed, so one can judge much better.
While I agree that the request to build, deploy and open source the code of a website is a bit too much, I think you are exaggerating a little bit on the why's you wouldn't do it.
"I'm not equipped to do your challenge" - really?
"Engineers aren't different" - again, really?
Rhetorical question: you don't want the job, do you?
I am not sure if the issue is with the hiring process, or with the candidates' ego here. Candidates. Plural. As the article's author doesn't seem to be the only one.
Apparently there is a lot of people that believe they are rockstars and they don't need the job, the job needs them.
Challenges like this help to figure out non technical skills as well, like: how committed a candidate is; how much he wants that job.
I'd rather hire a junior that is committed than a senior that is not.
When I work for a company, I want to make sure that whatever I am working on will help the company succeed. I want to be part of that success. This is commitment.
I am not there just to get the pay check for my 9 to 5 hours and move on to another company because they offered me extra $5 bucks.
If only modern companies had a similar view toward their employees. The fact is, whatever your particular situation, most companies don't return the exuberant loyalty you have for them. Although some have managers who are skilled enough salesmen to make you believe otherwise.
I agree and that is the main reason that made me move on from previous companies that I've worked for. However, I never used this fact as an excuse to care less about the work I am doing.
Your boss may like you, but your company couldn't care less if you were hit by a bus tomorrow. Sure, you'd get a mention and a small office party with stale cookies and cheap pizza, but you'd be forgotten within the year.
That only works if the company shares that commitment and wants to share the rewards of that success. In my (admittedly not small-startup) experience, that is not often the case.
There are a lot of jobs going around these days. Employers no longer have the luxury to treat prospective hires poorly. This is the employer's problem, not the candidates.
Personally, I've asked potential hires for work product demonstrations. However, two crucial differences: 1) I paid them for their time, and 2) the task was on a real part of our infrastructure, the code they produced eventually being used in production. Everyone was happy with this situation.
I'd say that's a much more fair way to go about it. If you're going to ask someone to do work for you, that should be a paying gig, and it should be a task worth doing. If you're looking for a free sample a public repo or a task that fits within the parameters of a normal interview time would be better alternatives.
Depends on your definition of committed. If being committed to you means taking the better part of a day, weekend, etc. to exhaustively go through a "code challenge" for one job opportunity, that's one thing. For the average job seeker, if you've got ten recruiters that you're in contact with and one of those ten want you to dedicate that much time to their position and the other nine want to put you on the phone with an engineer and bring you on-site, how attractive is that one job? For someone already working more than full-time, probably not very.
I think the long and short of it is that being committed to a job has nothing to do with whether you'll tolerate a code challenge. Being "committed enough" to finishing a task to unlock the gate to actually speaking with a company's engineering team is completely orthogonal to how much you care about what you're paid to do when you have a job.
I'm sorry, but an employer gets more out of the employee than the employee gets out of the employer. Otherwise the company would not be making a profit. But you know, maths.
Apparently there is a lot of people that believe they are rockstars and they don't need the job, the job needs them.
Here's a novel idea: both the candidate and the job need each other. If the job didn't need a candidate, then why are you looking to hire someone new?
Humility goes both ways. So does the arrogance. You reap what you sow.
I'd rather hire a junior that is committed than a senior that is not.
As long as you're prepared to deal with the difference between the output of a junior and the output of a senior, then you're okay. Word of advice, though: you'd best hold on to your own seniors.
I understand the point the author's trying to make.
For me, personally, this would be the better choice to judge my skills - and probably would lead to better chances for me to get the job. I suck at these braindead trick questions that are considered 'clever'. I'm not comfortable around a whiteboard only, being grilled by one or more other people while thinking.
I'm not slow, not really anyway. But I'm faster and better the more I know about the stuff at hand. I'll be good on the job, I'll suck solving math puzzles that some guy just read about in a book that ranks high on Amazon's list of code puzzle collections..
So - I'm glad that there's both. The author obviously would've preferred to show his skills live, in a discussion. This guy here would be happy to hand you a (small, mind you - I agree with the time-sink argument) finished project and discuss _that_ afterwards.
To my mind the ideal challenge is no more than 4 hours. You make an appointment. At the agreed time, the hiring company emails you the requirements. If you have clarification question, they remain available throughout the challenge time to answer them. From a hiring point of view the challenge should have some vague areas in the requirements in order to test whether the candidate is a coder or a developer who asks decent clarification questions. The challenge requires no special tools to do, either JS in a browser or Python or something like that. The exact requirments of the dev environment are specified at the time the appointment is made, i.e. if you want the person to develop in Python 2.6.3 or to use JS with backbone.js, then the candidate can get set up in a few minutes and be ready.
I consider 4 hours to be a max. 45 minutes is a bit short IMHO and does not allow for including unit tests. Also, I believe that a good challenge should ask for a complete set of unit tests as well.
But a full working MVP is way overboard and is too complex for the hirer to make meaningful decisions based on the outcome.
Any challenge should be followed up by an interview in which questions focus on the solution as developed by the candidate. The why of choices and the intent are important factors, probably more important than the actual code.
Write a program to fetch some data from S3 using these credentials we made you, perform some analysis on them (algorithm question, generally with recursion) and then display the final output. And write a test for it.
We provide a stubbed-out Rails project on Github so they don't have to know all the details about S3.
With this we test three things:
1) Can they quickly find missing info on Google/Stack Overflow (S3 stubs)
2) Can they handle recursion? (Algorithm question)
3) Can they write a test?
Then we go over their submission on Skype. It's worked pretty well for us.
You have no idea how the "challenge" was completed. A candidate could have rent-a-coder-ed the project, refactored it a bit, and slapped their name on it.
Sure, if you ask no follow-up questions after the challenge is completed. However, with a few well-placed questions about the implementation and some inspection of the code, it'll be quite clear whether you're talking to the author or not.
We once gave a (non-web-dev) programming "challenge" (I thought it was a joke/insult given the candidate's claimed experience) to a senior dev candidate. Mind you, this was on-site. I even tested it by putting our newly hired grad to the test and he aced it within 20 minutes. We gave the candidate an hour to complete it (and added a 30 minute extension when he was struggling).
The challenge involved developing something against an SDK (interacting with a camera) and we gave him internet access and the SDK examples to work off of. In the end, he produced something not quite what we were asking, but he was sure to claim it as his work. Although it wasn't ideal, I was prepared to say that he "passed" the assignment, because he was close and I was sympathetic to factors of stress and nervousness.
As he was toured around the facility, I inspected the code and saw that he was completely passing off one of the SDK examples as his own work (diffs showed only two variable names had been changed). The reason his code didn't quite do what we wanted, is that he wasn't even able to tweak the SDK example to do what we asked. He was a complete fraud and never mind technical ability, we couldn't have dishonesty like that on the team.
Before that interview I thought those kind of challenges were a joke, but after this I saw their value. Of course, their value depends highly on how their are implemented and targeted, but dismiss their usefulness at your own peril.
This is a lopsided view. You don't indicate how long your "newly hired grad" was working there, whether the "SDK" was an in-house SDK or a third-party one, what the candidate's resume skills were in comparison to the kind of programming around the SDK your test was designed for, etc.
These are all relevant details, because except for the most trivial of SDKs and their appropriate domains, a thoughtful, skilled developer might spend an entire hour simply reading through the SDK and/or its documentation to get a handle on its capabilities.
So I don't get that your story is an anecdote in support of the potential usefulness of code challenges. Instead, what I gather from your story is that your company prefers candidates who practice cowboy, shoot-from-the-hip programming instead of thoughtfully approaching a new, unfamiliar SDK and pondering how it might be used to solve problems related to the domain it was built for, then applying this thoughtful process to provide a solution to a problem. In fact, if I'm given a non-trivial SDK and told "write a program that does X using this SDK; you have one hour", my response might be something very similar to the above, directed at the person giving the "assignment" out, followed by a polite but firm indication that the company doesn't meet my requirements.
>You don't indicate how long your "newly hired grad" was working there, whether the "SDK" was an in-house SDK or a third-party one, what the candidate's resume skills were in comparison to the kind of programming around the SDK your test was designed for, etc.
I wanted to avoid writing a novel, so I left out some of those details you're interested in. Trust me, when this "test" was first suggested, I was wary of it myself and did everything in my power to make it very achievable. That's why I considered it a joke, it was not nearly difficult enough to assess the level of seniority this candidate was claiming. This was someone with 10+ years of development experience, in the same field, experience with the language and environment we used. On paper and even on the phone, he made himself sound like the perfect candidate. In fact, before the on-site interview, I thought he had it in the bag and was excited to get some help on the team.
The SDKs in question were for a camera (to get images from the camera) and OpenCV, which is well known in imaging circles. The test was to receive a video stream from the camera (there was an example showing how to do this and I made it clear I didn't mind if he made that example his starting point) and to subtract consecutive images to create an image representing the "difference" between the two images. Not a meaningful result and one could barely call it image processing, but it would show us the candidates abilities to interact with multiple well-documented SDKs to accomplish a very simple task. If someone who claims to have years of experience with image processing can't accomplish subtracting two consecutive images and drawing the result to the screen, given all the tools to do this, there's a big problem.
Our new grad was mostly a tester and an occasional developer. He had less than a year of experience. He completed in 20 minutes without supervision.
>Instead, what I gather from your story is that your company prefers candidates who practice cowboy, shoot-from-the-hip programming instead of thoughtfully approaching a new, unfamiliar SDK and pondering how it might be used to solve problems related to the domain it was built for, then applying this thoughtful process to provide a solution to a problem. In fact, if I'm given a non-trivial SDK and told "write a program that does X using this SDK; you have one hour", my response might be something very similar to the above, directed at the person giving the "assignment" out, followed by a polite but firm indication that the company doesn't meet my requirements.
While I am fully aware that there are severe limitations to the usefulness of a test like this, in this situation, it saved us from a terrible hire (this test wasn't the only indication that he wasn't who he claimed to be).
In all honesty, you sound like a fairly thorny/difficult person to work with and in your hypothetical scenario where the test caused you spurn the position, it would have inadvertently done its job.
I'm often surprised by what people will take umbrage at. It's one thing to decide that it's a seller's market, and that therefore you'll interview somewhere where they'll buy you lunch and offer you a six figure salary and generous share allocation after nothing more than a cozy chat. But it's quite another to become actively offended by the effrontery of a company demanding that you demonstrate the very skills they're hoping to hire you to apply on a daily basis!
What are people worried about? I have to say I can't help but assume the worst. Because what have they been doing for their career as a professional programmer, if when asked to actually write a program, they can't actually do it? Even with an example right in front of them?
Don't forget that in this particular example we have a supposed senior programmer! Somebody applying for this sort of job should, I feel, be able to actually program. Even if they've never seen the library before. In fact good candidates should be barely fazed by an unknown language! What is the "senior" bit for, if not this? At the very least, perhaps the candidate could admit that they seem to have found themselves interviewing for the wrong sort of role, and one that makes better use of their other skills would be more suitable? That might be a better tactic than storming off in a huff.
But I've never stormed out of an interview in a huff - so what do I know.
There's a reasonable expectation to have to demonstrate one's skills in an interview. Whether any given test or set of questions actually is valid for doing that is another matter entirely.
Put another way: it's just as unreasonable for a company to expect a developer's skills to be measured by contrived tests or to demand they spend any unpaid time at all doing "work" (e.g. projects), as it is for a candidate to expect a company to effectively kiss his butt and lay out red carpet just because he decided to apply.
I agree that there certainly are problems that would make a good "code challenge" question, but I'd argue that there are better tools for weeding out poor candidates. I also think that there's a big difference between on-site challenges and "here's what we'd like to have you do, call us back when you've got something" challenges.
I wonder whether the same companies that insist that job candidates spend a day of their lives on a "code challenge" are the same ones complaining about good developers being impossible to find.
The worst thing about code-challenges, is they never give feed back.
We're sorry, but what you produced is not good enough. We're not going to tell you what you missed.
At least technology tells you what you missed. If you have a standard, have it documented so that I'm not firing a bullet into the dark. Chances are I'm just as good as you; but you won't know because I haven't seen your coding style. You're on my project, you code like me. I'm on yours, you better believe I'll code like you.
And then there is the times they like to dismiss you for it but have some other reason and use it as a cover. So you worry about your code not being perfect and you develop a ritual to validate yourself before it goes through a compiler. Yep, I write my code three(avg) times now. 10 lines, over and over until it's a effing poem. It's called ocd.
Coding challenges, pfft, worthless. There is only one company that I did a coding challenge for in the past year and it's because they were really awesome people. - I'm here to make a product and work with a team. I'm not here to explain shit to you just so you can tell me to look up the documentation. If I take the time to explain my code to you, you better well explain why you think something is better rather then telling me to google it.
> The worst thing about code-challenges, is they never give feed back. We're sorry, but what you produced is not good enough. We're not going to tell you what you missed.
This is most interviews in general, and I hate that. When interviewing candidates I try to give actionable feedback to each of them, regardless of whether it results in whiny emails back (and it often does). There was only one case in recent memory where I couldn't because he'd gotten literally nothing right while bragging about how fun it was to write thousand-line functions. Eek.
Your td;dr: should go at the top.
Having started working at a company that asked me to do one of these, it was different specifically in that it was paid. This means it's not a waste of anyone's time. A time-constrained, feature-rich project shows a number of things about a programmer including how they handle pressure, how they prioritize their tasks, whether their estimates are reasonable, and whether they know about what you're hiring them for.
I get approached all the time by recruiters who supposedly love my work and want me to interview with their clients. It's getting harder to tell them that I'm not interested in a job. My consulting is doing okay and I'm actually starting to hire out some work. Why would I give that up, for a dice roll with a good chance of losing on whether or not my new boss turns out to be an asshole?
106 comments
[ 3.3 ms ] story [ 173 ms ] threadThe type of coding challenge a company asks (interview questions also) can be one of the most important data points to use to judge a company's culture...
(a) Short - 45 minutes to an hour
(b) Only as complex as necessary (for the front end we provide and end-point serving JSON, for example, so they don't have to worry about that)
(c) Real problems we've run into, distilled down into a form appropriate for an interview
(d) Made up of problems that we were having candidates do on the whiteboard before we developed the at-home test, meaning they're not super complex
I think that at-home coding is the perfect second step to an interview (after a phone screen). It's more realistic than whiteboard coding. You have the internet at your fingertips. You don't have the pressure of an interviewer sitting there. You have syntax checking. From my side, I don't have to waste 30 - 60 minutes on a bad candidate. And, assuming the code is good, reviewing it provides an awesome first hour of an in person interview. And the problems I give you to take home would have been given to you in person anyway, so you're not spending any more time than you would have if you'd just come in for an interview.
The issue here is that the tests he's being given are bad examples of a take home test, not that take home tests are bad ipso facto.
Our front-end test is a bit longer than the back-end test with a tradeoff of a shorter in person interview, but the front-end test shouldn't take more than 90 minutes.
One of our problems is a small matching algorithm. Another is a thread safety problem. The front-end test consists of pulling JSON data from a server, formatting it, and posting a single action back to the server. It sounds like we're in a minority though. Reading these other posts it seems like a lot of the tests are very onerous (build a small trading system? that is a ton of work).
Have you gotten feedback on the questions? It's easy to say that it's a valid question, but when you're close to the problem, it's easy to make a mistake since you might encounter a specific sort of problem that others might not be nearly as familiar with.
The difference to me I think is that yours are very specific, and "build a small trading system" can be very general. If it's timeboxed, there might be only so much that you can do--i.e. you might not be expected to complete the task. You want to test someone's knowledge, without being too 'in depth'. A candidate that can solve a problem on his own in 30 minutes isn't necessarily better than a candidate who can solve the problem in 10 minutes with the assistance of Google.
0.02
If I were a front end developer, I would much prefer to be asked to write a quick, tailored to fit within the time allotment (e.g. one hour) web site rather than answering obscure coding puzzles that probably have little relevance with what I'll actually be doing at the company.
As the interviewer, I would phrase it as: "Build as much as you can in one hour, with the following functionalities in order of decreased priorities: login, cart, etc...".
Then I would judge you on how much of it you built, how solid each of the features are, etc. In my book, you can choose to go broad (build a lot of features, albeit superficially) or broad (only a few features, but well designed, tested, clean code).
How can you be so sure? Were you there? You're essentially calling the author a liar without even pretending to have access to more data than that author. Thats just rude.
If you know something that the rest of us don't that would lead you to make such a forceful assertion, please share.
I'm sad to say that this is untrue, and that in writing this article I have not exaggerated the requirements in the least. I'm not going to name the company, but the requirements of the challenge indicate that it should be something you would be comfortable putting in production.
The "challenge" is a repo on the company's github. I'm sure you could probably easily find it with a bit of sleuthing.
I have had companies ask for an idea or some sort of feature to develop for the company and refused because it was essentially a "do some work for us and we might hire you" deal.
My opinion is that companies that think unpaid "code challenges" are a good idea don't respect my time enough as an individual to be worth it to work for. It's a signal that they're either going to have an awful work/life balance or that they are filled with unjustifiably arrogant "rockstars" in a caustic environment of petty elitism (or both). The latter signal applies especially if the company's product is some web "application" for the young-20-something set.
I had someone offer me a paid test. I refused because I am too busy.
By requiring coding tests, employers and managers may be accidentally selecting only desperate candidates.
I don't think there is anything wrong with the headline font. I'm not too fond of the link highlighting used on the front page, but it's fine. Really. And you can be a "front end person" and have very, very little to do with design these days. Entire webapps are made on the front-end.
As for the content:
I've dealt with numerous developers who only want to do one thing, only backend, only front-end, only design. I've constantly run into shenanigans when working with such people in a fast paced dynamic environment. "I can't work on the frontend till the backend api is finished", "I can't work on the backend till the frontend data requirements are defined", "I can't work on the frontend till the UI/UX are defined". It's a never ending requirements dependency argument.
More capable full stack people are able to mock or fake the bits that are as of yet undefined allowing them to continue working on their core piece while gaining a better understand of the system as a whole. This allows them to contribute to the product definition at all levels instead of just living in their own little piece of it, waiting for definition from outside.
> I have to
That's not true. You don't have to reply. No one is requiring you do that. You've already started off by lying. This means anything else you might want to contribute is awful and worthless.
> say
You didn't. You typed it out. I'm pretty sure you didn't "say" anything. And now you are trying to be confusing. That's just awful.
> , that headline font is awful
Well, that's your opinion. Your opinion is worthless because you haven't validated your credentials.
> and the link highlighting on the blog's front page is worse.
So, not the page we were directed to. Did you happen to check out his Facebook page, too? Did you decide to comment on his awful dinner choice last night?
> There is a bit of oddness
This whole sentence is odd. In fact, that sentence is far worse than anything the OP did. You would say it's awful. In this case, you'd be right, because it's a shit sentence.
> in declaring yourself a front-end person by talking about not needing to be tested as a back-end person
That's not what he's doing. He's saying he's a front-end person, and was tested for back-end work. He's not saying he's a front-end person by talking about not needing to be tested as a back-end person.
Those are two completely different things. If you don't immediately understand why, I apologize, but you wrote the awful and confusing sentence.
> when you're applying for a front-end job yet having a blog with a such a jarring front-end.
What's jarring about it? Surely you aren't speaking of the design. That would be a designer, not a front-end person. And we've established he's not apply for a designer's position.
Unless you are suggesting all designers should be expert programmers? Because that's the only way what you said remotely makes any sense.
Awful, just awful.
Nevertheless you should never agree to complete a full production project without being paid.
I built it. It worked. Then they said my application was not aesthetic enough and said thank you for your time.
The whole thing seemed backwards...
In my opinion (as someone who has been going through the process for a few years now throughout undergrad with internships and now looking for a full time job at the end of my masters), very few companies do the "coding" problem right.
I don't want to work for you if you ask me to write a nested for loop and regurgitate the overhead involved in searching a b-tree. I also don't want to work for you if you ask me to build a application with no pre-defined criteria.
In my opinion...the best coding question you can ask me is fizzbuzz types of questions or pseudo-code for something complex (to see if the candidate can think through the steps of solving the complex problem without having to waste the time solving it).
So far not a single company has done the below.
There is a serious point: companies often aren't forthcoming about day-to-day working conditions. But the response you get to your puzzle solving activities can be telling.
This functionality is pretty simple, but it still took many hours to code. My feeling was that they thought it would perhaps take an hour to do. It was fun and interesting to do, but it took much longer than I thought. I think the companies giving the challenges should have their own engineers do the task, so they get a good handle on how much they are asking from the applicant. And of course it also depends on if it is a buyer's or seller's market (jobwise that is, not in terms of my "trading" system). If there is a lot of competition for developers, maybe they should give too big projects.
Since then, publishing code samples became the normal thing to do, so we simply require code samples instead, and give out the coding task only when they have nothing at all to share with us.
If you're in the job market, publishing some sample code, even if it's just a throwaway toy instead of, say, a full blown OSS project, can be a great tool for people to evaluate you as a candidate.
What I do have is years of experience building mission critical applications that move millions of dollars per day in transactions, and I have a solid track record of being easy to work with. I am good at what I do and I work hard to be an asset to any company that employs me, and I work hard to be enjoyable to work with.
If you can't be good enough to figure that out from a conversation and looking at my track record, why would I work for you?
BTW, I haven't had to look for a job in over 13 years - although I've worked for several companies during that time.
I agree that companies are excluding people such as yourself with these coding challenges. That's their right, just as it is your right to not apply to any companies that require such challenges.
If someone is finding good candidates with a coding challenge, that's great. If someone is finding good jobs while avoiding coding challenges, that's great too.
I will say that there's some nuance implied in your comment that simply isn't present in any of the github/coding challenge blog posts that have popped up on HN over the last few days.
Whether a coding challenge is appropriate doesn't just depend on the company or the candidate--it also depends on the position! It's far easier to test junior/mid level skills than senior skills in a 1-2 hour task. Geez, some of the skills you mention above would be hard to test in a 1-2 day task.
When you are looking for esoteric, softer, or more senior skills (requirements gathering, or architecture), you need other ways of evaluating candidates beyond a code challenge. Things like what you suggest: conversations, references, etc. Of course, there are some "senior" folks out there who aren't great coders even though they talk a good game, and if coding is what the position requires, a code challenge is fine.
I work with several people who have over a decade of experience with "mission critical" applications and do not have the commensurate skills.
> If you can't be good enough to figure that out from a conversation and looking at my track record, why would I work for you?
Just because you can get something done, that doesn't mean you did it by writing well-thought-out, sanely structured, maintainable, readable, useful code. I mean, you probably aren't bad if you're bragging about yourself like this, but who really knows until the code is visible?
The language and environment we work in isn't known for high-quality coders. Quite the opposite. Filtering out the wheat from the chaff is basically a requirement, even for the people that seem good after a phone screen and an in-person interview.
At no point did I claim to 'just get things done'. YOU said that. What I wrote was that I have years of experience building mission critical applications (which, of course, I would not claim if I could not prove).
It's not hard to prove or disprove if someone knows what they are talking about. I view 'coding challenges' as a sign that the company is not confident in their ability to assess people. It's a red flag to me. It's an amateur move. It tells me a LOT about the company from the inside, and it's not good.
'Coding challenges' are for companies who don't understand the skill set they are hiring for. I've hired plenty of devs over the years as well - we've had some bad ass programmers who worked for us, and I never needed a coding challenge to figure out who to hire.
Here's the gist of how it went down:
1) first part was the "personality" interview. Two "HR" people blew smoke up my ass for about 30 minutes about how awesome my site and my work was, then asked me to do a "code challenge". I agreed - I mean, how bad could it be?
2) The code challenge. I was given a PSD with a straight forward design. Asked to code it, make sure it worked in legacy browsers, publish on a server and show them the code on GitHub
3) Passed and then was asked to come back and explain some of my coding decisions. I was told this was more for show and I was already in effect hired, I just had to pass this last hurdle. It turned out to be a very confrontational, inquisition type of an interview. Not at all the type of laid back code review I'm used it.
I got pretty frustrated by the two "Senior" devs who seemed to take great pride in tearing my code and my decisions apart. After my first heated exchange with one of the devs, I actually asked them how many of the sites listed in the gallery on their site they actually tested and validated the code on. They said "All of them, why do you ask?" I told them I actually ran all of their sites through the W3C validation site and none of them passed. Every single one had over 60 errors on it. I basically said, "If standards are so important to you, then why are you holding people who don't even work for your company to a higher standard than those who actually do?"
There was a long silence and then I finally spoke up and said, "Clearly, this company has its priorities in the wrong order. Thank you for time, but I'm not interested." and got up and walked out.
I got several worried calls from the company recruiter, but by then I was so pissed at how much of my time they had wasted, and vowed never to do something like it again.
Two possibilities:
a) You got a glimpse of how your life on the job would look like.
b) Just like qualified specialists can be terrible interviewees, they can be terrible interviewers. They just screwed up.
Well, you want to hire people who are better than you, not worse than you. Hiring bar at a good company should go up, not down, as it grows.
However, the coding challenges I've done for applications have always been in the vein of "solve this interesting puzzle and show us how you did it", not "do some boring day-to-day work, but do it for free".
With the exception of my current employer, who asked me to make a small static site with some JS oddities (about 6 hours total), they've all been fairly simple challenges just to get a grip on my thinking process, not really have me do the routine stuff.
"I'm not equipped to do your challenge" - really?
"Engineers aren't different" - again, really?
Rhetorical question: you don't want the job, do you?
I am not sure if the issue is with the hiring process, or with the candidates' ego here. Candidates. Plural. As the article's author doesn't seem to be the only one.
Apparently there is a lot of people that believe they are rockstars and they don't need the job, the job needs them. Challenges like this help to figure out non technical skills as well, like: how committed a candidate is; how much he wants that job.
I'd rather hire a junior that is committed than a senior that is not.
Your boss may like you, but your company couldn't care less if you were hit by a bus tomorrow. Sure, you'd get a mention and a small office party with stale cookies and cheap pizza, but you'd be forgotten within the year.
Personally, I've asked potential hires for work product demonstrations. However, two crucial differences: 1) I paid them for their time, and 2) the task was on a real part of our infrastructure, the code they produced eventually being used in production. Everyone was happy with this situation.
I think the long and short of it is that being committed to a job has nothing to do with whether you'll tolerate a code challenge. Being "committed enough" to finishing a task to unlock the gate to actually speaking with a company's engineering team is completely orthogonal to how much you care about what you're paid to do when you have a job.
Here's a novel idea: both the candidate and the job need each other. If the job didn't need a candidate, then why are you looking to hire someone new?
Humility goes both ways. So does the arrogance. You reap what you sow.
I'd rather hire a junior that is committed than a senior that is not.
As long as you're prepared to deal with the difference between the output of a junior and the output of a senior, then you're okay. Word of advice, though: you'd best hold on to your own seniors.
For me, personally, this would be the better choice to judge my skills - and probably would lead to better chances for me to get the job. I suck at these braindead trick questions that are considered 'clever'. I'm not comfortable around a whiteboard only, being grilled by one or more other people while thinking.
I'm not slow, not really anyway. But I'm faster and better the more I know about the stuff at hand. I'll be good on the job, I'll suck solving math puzzles that some guy just read about in a book that ranks high on Amazon's list of code puzzle collections..
So - I'm glad that there's both. The author obviously would've preferred to show his skills live, in a discussion. This guy here would be happy to hand you a (small, mind you - I agree with the time-sink argument) finished project and discuss _that_ afterwards.
I consider 4 hours to be a max. 45 minutes is a bit short IMHO and does not allow for including unit tests. Also, I believe that a good challenge should ask for a complete set of unit tests as well.
But a full working MVP is way overboard and is too complex for the hirer to make meaningful decisions based on the outcome.
Any challenge should be followed up by an interview in which questions focus on the solution as developed by the candidate. The why of choices and the intent are important factors, probably more important than the actual code.
Write a program to fetch some data from S3 using these credentials we made you, perform some analysis on them (algorithm question, generally with recursion) and then display the final output. And write a test for it.
We provide a stubbed-out Rails project on Github so they don't have to know all the details about S3.
With this we test three things:
1) Can they quickly find missing info on Google/Stack Overflow (S3 stubs)
2) Can they handle recursion? (Algorithm question)
3) Can they write a test?
Then we go over their submission on Skype. It's worked pretty well for us.
Sure, if you ask no follow-up questions after the challenge is completed. However, with a few well-placed questions about the implementation and some inspection of the code, it'll be quite clear whether you're talking to the author or not.
We once gave a (non-web-dev) programming "challenge" (I thought it was a joke/insult given the candidate's claimed experience) to a senior dev candidate. Mind you, this was on-site. I even tested it by putting our newly hired grad to the test and he aced it within 20 minutes. We gave the candidate an hour to complete it (and added a 30 minute extension when he was struggling).
The challenge involved developing something against an SDK (interacting with a camera) and we gave him internet access and the SDK examples to work off of. In the end, he produced something not quite what we were asking, but he was sure to claim it as his work. Although it wasn't ideal, I was prepared to say that he "passed" the assignment, because he was close and I was sympathetic to factors of stress and nervousness.
As he was toured around the facility, I inspected the code and saw that he was completely passing off one of the SDK examples as his own work (diffs showed only two variable names had been changed). The reason his code didn't quite do what we wanted, is that he wasn't even able to tweak the SDK example to do what we asked. He was a complete fraud and never mind technical ability, we couldn't have dishonesty like that on the team.
Before that interview I thought those kind of challenges were a joke, but after this I saw their value. Of course, their value depends highly on how their are implemented and targeted, but dismiss their usefulness at your own peril.
These are all relevant details, because except for the most trivial of SDKs and their appropriate domains, a thoughtful, skilled developer might spend an entire hour simply reading through the SDK and/or its documentation to get a handle on its capabilities.
So I don't get that your story is an anecdote in support of the potential usefulness of code challenges. Instead, what I gather from your story is that your company prefers candidates who practice cowboy, shoot-from-the-hip programming instead of thoughtfully approaching a new, unfamiliar SDK and pondering how it might be used to solve problems related to the domain it was built for, then applying this thoughtful process to provide a solution to a problem. In fact, if I'm given a non-trivial SDK and told "write a program that does X using this SDK; you have one hour", my response might be something very similar to the above, directed at the person giving the "assignment" out, followed by a polite but firm indication that the company doesn't meet my requirements.
I wanted to avoid writing a novel, so I left out some of those details you're interested in. Trust me, when this "test" was first suggested, I was wary of it myself and did everything in my power to make it very achievable. That's why I considered it a joke, it was not nearly difficult enough to assess the level of seniority this candidate was claiming. This was someone with 10+ years of development experience, in the same field, experience with the language and environment we used. On paper and even on the phone, he made himself sound like the perfect candidate. In fact, before the on-site interview, I thought he had it in the bag and was excited to get some help on the team.
The SDKs in question were for a camera (to get images from the camera) and OpenCV, which is well known in imaging circles. The test was to receive a video stream from the camera (there was an example showing how to do this and I made it clear I didn't mind if he made that example his starting point) and to subtract consecutive images to create an image representing the "difference" between the two images. Not a meaningful result and one could barely call it image processing, but it would show us the candidates abilities to interact with multiple well-documented SDKs to accomplish a very simple task. If someone who claims to have years of experience with image processing can't accomplish subtracting two consecutive images and drawing the result to the screen, given all the tools to do this, there's a big problem.
Our new grad was mostly a tester and an occasional developer. He had less than a year of experience. He completed in 20 minutes without supervision.
>Instead, what I gather from your story is that your company prefers candidates who practice cowboy, shoot-from-the-hip programming instead of thoughtfully approaching a new, unfamiliar SDK and pondering how it might be used to solve problems related to the domain it was built for, then applying this thoughtful process to provide a solution to a problem. In fact, if I'm given a non-trivial SDK and told "write a program that does X using this SDK; you have one hour", my response might be something very similar to the above, directed at the person giving the "assignment" out, followed by a polite but firm indication that the company doesn't meet my requirements.
While I am fully aware that there are severe limitations to the usefulness of a test like this, in this situation, it saved us from a terrible hire (this test wasn't the only indication that he wasn't who he claimed to be).
In all honesty, you sound like a fairly thorny/difficult person to work with and in your hypothetical scenario where the test caused you spurn the position, it would have inadvertently done its job.
What are people worried about? I have to say I can't help but assume the worst. Because what have they been doing for their career as a professional programmer, if when asked to actually write a program, they can't actually do it? Even with an example right in front of them?
Don't forget that in this particular example we have a supposed senior programmer! Somebody applying for this sort of job should, I feel, be able to actually program. Even if they've never seen the library before. In fact good candidates should be barely fazed by an unknown language! What is the "senior" bit for, if not this? At the very least, perhaps the candidate could admit that they seem to have found themselves interviewing for the wrong sort of role, and one that makes better use of their other skills would be more suitable? That might be a better tactic than storming off in a huff.
But I've never stormed out of an interview in a huff - so what do I know.
Put another way: it's just as unreasonable for a company to expect a developer's skills to be measured by contrived tests or to demand they spend any unpaid time at all doing "work" (e.g. projects), as it is for a candidate to expect a company to effectively kiss his butt and lay out red carpet just because he decided to apply.
We're sorry, but what you produced is not good enough. We're not going to tell you what you missed.
At least technology tells you what you missed. If you have a standard, have it documented so that I'm not firing a bullet into the dark. Chances are I'm just as good as you; but you won't know because I haven't seen your coding style. You're on my project, you code like me. I'm on yours, you better believe I'll code like you.
And then there is the times they like to dismiss you for it but have some other reason and use it as a cover. So you worry about your code not being perfect and you develop a ritual to validate yourself before it goes through a compiler. Yep, I write my code three(avg) times now. 10 lines, over and over until it's a effing poem. It's called ocd.
Coding challenges, pfft, worthless. There is only one company that I did a coding challenge for in the past year and it's because they were really awesome people. - I'm here to make a product and work with a team. I'm not here to explain shit to you just so you can tell me to look up the documentation. If I take the time to explain my code to you, you better well explain why you think something is better rather then telling me to google it.
fufff, I needed that.
This is most interviews in general, and I hate that. When interviewing candidates I try to give actionable feedback to each of them, regardless of whether it results in whiny emails back (and it often does). There was only one case in recent memory where I couldn't because he'd gotten literally nothing right while bragging about how fun it was to write thousand-line functions. Eek.