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

"High IQ"

Thanks for the laugh.

Most comments already get to the point. You can not hire a junior with senior or intermediate level skills.

It seems like you are in the same shoes as me at the moment. What I suggest you to do is to prepare a small test tasks they can do at home. This saves up time for you going through unnecessary extra interview processes and also shows some of their dedication and skills. I am not saying you should not have interviews, but it is hard to filter candidates just by resumes (and you can not have 400+ interviews).

Answering your question, I usually look out for the following:

1. After I sent the candidates the test task, but before they finish it (NOTE: I don't know they progress on it):

- Do they let me know when they have time to do the task (in case they are not able to it immediately) or do they just let time pass by.

- Do they come back with questions if they hit a wall somewhere.

- Do they let me know if they are not able to do the task (for whatever reason). At this point they are obviously out of the process, but they might re-apply at a later time.

- Communication is key at this level of the application process.

2. After I received the results of the test task

- Obviously did they finish the task in a reasonable quality. There are most likely mistakes in it, but this is irrelevant in case the general quality of the result is ok and the solution works as expected.

- The quality also reflects on how much time they spent testing their own solution.

- Did they finish all the sub-tasks (usually I also ask for documentation and tests) or did they just skip those.

- Did they try to find quick and dirty solutions or did they try to implement things properly (and most likely spent more time on it).

The best developer you can hire is somebody who does communicate pro-actively, is dedicated and develops maintainable solutions over "easy" ones. How much time they spent on the task and how proficient they were with the tools at hand (programming languages/frameworks) is not relevant in my opinion. If they were unfamiliar with the programming language for example and they spent the time during that task to learn part of it and delivered a proper solution with it, they got all my respect and I would be very likely to hire them.

You will also have to spent time reviewing the test task results, but I think this is less time-consuming than interviews. More than half of the candidates will probably jump off before you even see the results. For the other half you will learn how to distinguish a good from a bad solution quickly.

Learn and communicate, I don't think anyone would argue with that, but how do you judge that from talking to someone, reading their resume, or viewing their portfolio? That's the question. For a junior developer these are some things I look for:

I want to see evidence they are familiar with the tools; since I hire for enterprise Java that is: eclipse (or other ide), maven, and git. I don't expect them to know much, just evidence they've used them and are familiar with some the concepts they mask (i.e. the class path) or why they're important (ie version control).

I ask them to tell me about a project they've done and the data structures they used, then drill down just enough to see if they understand why they used them, and how they're implemented.

Depending on the work, I'll drill down into data structures a bit more, but otherwise, I don't focus on anything but familiarity with the basics.

If they're straight out of school I ask them what they're favorite CS class was.

One of my favorites is to ask about a tricky bug they've solved recently. This one either gets people talking, or they don't have anything. If they don't have anything, I'll probe, but if a candidate can't talk about this it's a strong signal to not hire (imo).

As an exampe, I interviewed a self taught guy one time, very green. He had written a few simple android apps, but had used notepad and the command line, so didn't know anything about Eclipse. I asked him about any datastructures he'd used in his apps and why. He was at a loss, and had only used arrays apparently. The guy had some positives; he had shipped two apps, which is something, working with primitive tools. But he also hadn't taught himself the "standard" tools, which we all do to a point.

When it comes to someone that green, I just don't have the time to train them. I once worked with an architect who was really good at training green developers, and his management gave him a funnel. They developed a really great (and cheap) team. Most of their devs stayed long term, but some got training and left after 1-2 years.

> Often we end up with a few who are strong technically and a few who are strong in personality and willingness. We always go with the latter.

Ever a candidate who's both? Great response, thanks!

Rarely. I'm from the public sector (a municipality) and the brutal truth is that we typically don't attract the best of the best. We don't pay enough and our reputation isn't great so we typically only attract the best of the best if they are having children (benefits) or come with some sort of ideology for wanting public service.