Ask HN: What qualities do you look for in a junior developer?

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.

We had over 400 applicants for a recent position.

Fairly giving them a time investment of 30 minutes (reading CV, tailoring technical interview, answering questions) would mean 200 hours of productivity loss. There is no way to defend this to a company, especially when hiring more than 1 a year.

If no coding challenge then it all comes down to the CV. You'll miss out on promising humble candidates who lack the CV buzzword bingo, and get burned on mediocre candidates whose parents paid for them to go through a top university. That's not fair to the talent either.

Of course if someone completes the coding challenge, you give them the time investment they deserve (8-16 hours spread over multiple employees). You save this time by declining those that do very poorly on the challenge, or refuse to do it out right.

You may not have an idea how awkward and depressing a technical phone interview is with a candidate that is not suited to the role. And delegating this to HR/Recruiters is a surefire way to increase noise and crash the hopes of people who pass the screen, but fail badly on future interviews.

Sounds like your chosen solution (junior developers) doesn't meet your requirement (time- and cost-efficient development).

What I want to see in junior developers is simply enthusiasm for programming and their ability to learn. Both are easy to spot by having a nice conversation with them and maybe pairing with them for a few hours.

> we had so many applicants (400+) that it was a tough challenge discerning the best candidates

You just want good candidates that fit your company. Then you /make/ them the best by teaching and mentoring them.

> I would like to hire senior developers instead, but they are too expensive for my budget

Sorry to say it but this sounds not like a good place for junior developers. You can't just put them in a senior position and expect results for cheaper payroll costs. They need to learn (experienced developers need to learn too, but juniors even more so).

My former company hired interns and junior level engineers regularly. If you are hiring jr devs because you can't afford sr people you are going to have a bad time. Jr Devs require constant attention early on if you want them to ever move pass the junior part. They need the ability to fall on their face occasionally and resources who can't point them in the right direction when they do. But if you can't afford to pay the Sr people your junior people are going to leave right around the point where they start really being a great value(that's 2-3 years in tops).

If you're looking for how to find hidden gems, my best advice is don't bother. Ask them fizz buzz (yes literally fizzbuzz), some basic OO vocab, and have them do an easy design problem. If they have a pulse and can do that, they're probably worth your time. For most devs of any level it's really hard to tell whether they will be valuable additions until you've actually worked with them. For a jr dev it's a pointless exercise. Find someone motivated, who seems like they can learn, and spend time putting in place a framework to make sure they have the tools to succeed.