I'm actually launching a product to streamline the process if anyone is interested.
Before I spend time as a candidate I want to make sure the interviewer is seriously considering me for the position.
Oooohhhh or pay-what-you-want where the candidate sees what you paid. Use it as a signal to the candidate of how much you're interested in them.
Personally I only ever assign a code challenge after an initial general interview. Then code challenge which gets taken into a technical interview.
Me: Are you comfortable solving a small programming problem?
If the answer is yes: Here's a simple algorithmic problem you can solve in under 20-30 LOC. You can choose any language you wish, including psedocode. You can choose to write on paper or on this PC.
If the candidate seems nervous, I leave the room for a few minutes.
It can't find you the best developers. But it certainly helps weed out candidates who talk up a storm but can't actually code.
The correct answer to most sorting algo challenges in the real world is some variation on "use Array.sort"
I'm more interested in how people interpret requirements, how they resource knowledge, how they architect their code, how they test it, etc.
My recently retired pet challenge was to fetch and amalgamate responses from three different, unreliable, URLs and then return them in a single JSON document. For the web developers I was hiring it worked well.
RESPECT YOUR CANDIDATES Strictly timeboxed tasks ensure candidates don't feel pressured to devote silly amounts of time to interview coding exercises.
The biggest issue I've found as an dev looking for work is that, employers often want a full functioning, production grade, api, with tests, and some integration tests. These requirements cause the issues, and timeboxing would surely compound them?
I guess there's a learning curve for the potential employer, but as an employee I wouldn't want to potentially be a guinea pig while they get their act together when understanding how long a task should actually take.
The employer onboarding is designed to guide them towards the best practices I've discovered. 40 minute time limit and a clear expectation set in the challenge instructions that a "perfect" response is not possible in the time provided, so just do what you can and submit what you've got.
That avoids clustering responses near the top of the curve.
It also provides talking points for the interview. "So, given unlimited time and budget, where would you go from here to make this code production ready? If you needed to scale it to an OOM more throughout, where would you start optimising?" Etc.
http://www.gayle.com/blog/2013/09/18/companies-who-give-cand...
No real need for me to summarize it, it's all pretty well expressed in this blog post.