It's crazy how many coding tests are poorly designed and waste a candidate's time. I'm putting together a list of good practice for test design here: https://candidatecode.com/articles/coding_challenge_best_pra...
Feedback and contributions welcome
That's a problem even if you have reasonable expectations yourself, because the candidate probably has experienced some tests where the expectations haven't been reasonable. For a (real) example: marking candidates down for not having an analytics integration.
How does your candidate know that's not important to you, even though it was important to the last company?
> testing your experience, not your literal skill in pumping out code
Past a certain point, it gets much more efficient to discuss experience in an interview setting. Good coding tests should be designed to test the skills you care about most to produce a strong hiring signal for the next phase - it's difficult to showcase a full decade's worth of experience in 4-8 hours' worth of coding challenge.
> Anyone can pump out code
I've found that to be depressingly untrue amongst a significant percentage of engineering applicants.
- Unit tests? Yes. It will increase your standing.
- Docs? Absolutely. A must have. You will not be considered really otherwise.
- Deployment? See above.
- Support 5k requests? Not unless that is what the test is testing for, pay attention during phone interview about the role and it's requirements, the test will look for this and other generalizations.
- Clean code? Very, very important. Don't try to show how smart you are, show how audience aware you are. Most likely you will be working on a team, a team doesn't want a cowboy programmer.
Something you didn't mention but bodes really well for anything with a front-end interface: hosting. Executives hate running things themselves, so a hosted version will put you at the top of the list.