In my experience, these take home projects are woefully underspecified. Do they know this and expect me to email them with "good questions"? Or want me to not email them and "fill in the blanks" on my own? Do they want something that "just works"? Or something that is "reusable"? And so on. There's a reason we don't write production code by just throwing a document over the wall.
>>>>In my experience, these take home projects are woefully underspecified.
Completely agree.
I'm still not sure what these "challenges" even prove. If you're a developer, you should have reams of examples of code, a github account with work, and plenty of other avenues for people to check if you can do basic coding from scratch. Even a junior developer will/should have several examples of work they've done while in school.
I've been in a lot of "technical" interviews and once they start asking coding questions, I usually ask them if they've looked at my online portfolio, or the examples on my github account. 95% of the time, I'm able to pull an example which deals directly with that they're asking.
Doing this has two effects. One, it proves I can do what they're asking. And two, it puts the responsibility back on the interviewer. It's like asking, "Did you do your due diligence, or are you wasting my time asking me this question?"
We do this at my job. We try to come up with projects that are good fits for the candidate, usually a small version of a problem we've recently dealt with.
It's not a first line, though. We tend to start by actively recruiting/headhunting. We cherish recommendations from current or past employees, but we'll also open the position to all on the off chance we get a good application through traditional routes. HR only becomes involved with the process after an offer has been accepted or if the hiring manager has questions/concerns.
After an informal lunch with the hiring manager, you'll be invited to meet with some senior developers for about an hour. These meetings are mostly to figure out what the candidate thinks their strengths and weaknesses are and gives us a chance to talk about the stuff we plan to work on in the near and not-so-near future.
Once we have a fairly basic understanding of each other, we'll come up with a project. Think your strength is on the front end? Here's an API we wrote. Build a widget with the data. Think you're strongest at databases? Great, here's a database project.
We don't care if you have a lot of questions or if you fill in the blanks. We give as little direction as possible at first on purpose. Write it in whatever language you want to write it in. We want to see how the candidate works. If they ask questions, great. If they don't, great. Do they ship something?
We make sure to stress there's no wrong answers. At all. The projects are designed around your perceived strengths because we'll figure out your weaknesses and will compensate for those during the 90-day trial period all new hires have to go through anyway.
The point is to see something we can discuss in a later, final round. Even failure to complete is acceptable, so long as you can articulate why.
None of this is hard and fast. We have had candidates who, for whatever reason, can't or won't write code outside of their current position. We'll adjust. Our process isn't rigid at all. We try our best to take a holistic approach. It's only bit us in the ass twice, mostly due to culture issues because the hiring manager made his decisions unilaterally. Since then, all senior devs and a few others on the team meet all candidates before hire and can give management input.
