You have to realize that hiring a junior developer means you will be spending a good portion of your time and energy on mentorship and compensating for their la

You have to realize that hiring a junior developer means you will be spending a good portion of your time and energy on mentorship and compensating for their lack of skill and experience. This is an investment and one well worth making both for the mentee and mentor. You want your senior developers to be spending some portion of their time with the junior developers on your team. If you're not prepared to make this investment don't hire a junior developer: get a competent contractor instead. If you are willing to proceed the next step is setting up your hiring process. I've used a loose, informal specification for a rather simple program as a take-home exercise. It takes around 3-4 hours to complete for a reasonably-experience programmer and can be completed in any language that the applicant is most comfortable with. When designing this specification I made sure that the language was clear and intentionally left some requirements vague. It is intended to be representative of a typical specification for a low-risk feature or system that you might encounter on the job: a few paragraphs detailing the problem, a description of the API, the inputs, the expected outputs, etc. What's interesting about using this exercise with junior developers is seeing how they interpret the specification. Most developers out of school aren't trained to think in terms of specifications, requirements, etc. Your junior applicants will typically write some code to start solving the problem. They will skip translating requirements from the specification into tests. They won't think of the bounds on inputs or outputs. Often they will start writing code and implement the first thing that "works" (for some definition of "works"). This is wonderful! It gives you plenty of leading questions when you invite them in for a code review session. A good, naive solution is great. It gives you opportunities to talk about edge cases, tests, assumptions, invariants, performance, etc. The more you can get them to talk the better! If they seem enthusiastic and are capable of taking a leading question and connecting the dots then you have a great candidate.