Ask HN: What qualities do you look for in a junior developer?
I am currently hiring developers for a junior position again for my startup.
I say "again", because the first time round we had so many applicants (400+) that it was a tough challenge discerning the best candidates from the pool and had allocated 10 interviews a day. The interviews were so bad that I ultimately rejected all of the applicants. I also withdrew the position because it was wasting my time.
Preferably, I would like to hire senior developers instead, but they are too expensive for my budget.
I slogged it out for another 4 months and I'm giving it another go on hiring juniors. But would not like to make the same mistake.
70 comments
[ 5.4 ms ] story [ 119 ms ] threadJunior developers need to have high IQ and ability to code, everything else you will need to teach them anyway. Keep in mind that if you don't have time to teach them they will not be cheaper than seniors, unless all you need is bums on seats to fool investors or something nefarious like that.
Thanks for the laugh.
In your case, I'd say someone passionate enough to provide good value for the team. Just make sure you don't scare them away by making them feel they might "waste your time" ;-)
Maybe you shouldn't hire juniors? Junior devs are an investment and we owe them respect and genuine mentorship. By definition, they will 'waste your time'.
And frankly, if you can't afford seniors, your company's mentorship opportunities will be weak enough that the smart play for truly capable, career minded juniors would be to work elsewhere.
Hiring is not free -- in fact by the sounds of it the OP has already spend at least tens of hours unsuccessfully trying to hire someone.
Mentoring time is not free. You're also paying them to learn (read docs, rework code, etc) whether you realize it or not.
There's also a very non-zero chance you're incurring technical debt at a high rate, and that may not be apparent until you go to fix bugs (and cause 15 more every time you do) or add new features (and need to rebuild half the software to do so).
Knowing how to build good, maintainable and supportable software comes with experience and this is what you're paying a senior for.
* Take initiatives
* Knows how to learn new things, +/- fast (and loves it)
* Knows when its the wrong way (even if its too late) and turn back
From my little experience, you don't have to do big technical challenges to detect those. But again I have very little experience in the business (5 interns and 1 junior hires) Social habilities are important too, but don't get fooled by those who talk too much
Good luck !
EDIT: formatting
If they don't do it on their own, and don't seem interested in programming for their own benefit outside of the job, then don't hire them.
People who are new but enthusiastic and spend a lot of time learning on their own are who you want.
Subsequently, hiring too many junior developers can be a hinderance because there aren't enough people to coach and guide them. It adds technical debt to your organization and makes for a shitty experience for the junior dev. They need help and they need people who have the time to help them. It's easy for junior devs to feel inadequate and suffer in silence.
Finally, ask yourself why don't have the funds to hire a more experienced engineer. It may be a sign of an unhealthy organization or goals which are way too big. I say this from experience and the pain I felt as a result of not listening to my gut and pushing back ferociously. You think firing someone "sucks," try laying off a room of people you know, who you care about, and who have been good to you and your organization... bad goal setting will cause it.
I strongly disagree with this. We as an industry desperately need to stop propagating these myths about what makes a good developer. You're enthusiasm for programming outside of work has jack all to do with your ability to perform the job functions expected of a SWE. Is it a sign if you are into programming as a pass time? Sure, but it's by no means an indicator of the quality of said programming. We don't expect lawyers to be litigating cases in their free time and we would never tell an accounting firm to pass up any candidate who doesn't demonstrably love doing their taxes. People work 8+ hours a day in these jobs and otherwise have lives. One could even argue that other interests is better for the long term prospects of candidate because they are less likely to burn out. 8 hours a day is more than enough time to build up domain expertise given the ~260 days you can expect to spend doing this each day
Of the 30 or so engineers i have worked closely with over the last 6 years, nothing correlates better to the programmers ability than what i describe as "passion".
I do not share the stance that this requires someone to spend time outside of work on personal projects or burning the midnight oil on work. Instead, what i look for is a burning desire to be creative and solve problems, specifically with code. I give candidates a number of opportunities to express why coding is important to them, and what would they be doing in its absence. If i had to only ask a single interview question, it would be something to that effect.
While i don't mean to suggest every excellent programmer shares this passion, it has become the best single barometer i can find of gauging future ability. With midlevel and senior devs this task becomes a lot easier because you have so much experience to lean on. For juniors, passion is king.
You reference lawyers and doctors but they have already spent years in dedication of knowledge and experience. That's simply a bad comparison.
This is about a junior developer not mid-level or senior. At some point as another comment says you have enough experience to not focus on it outside of work. In the beginning if you don't have passion and a desire to learn which your time at work won't be sufficient for, it's probably a good indicator you won't be a good engineer.
Further your eight hours a day 260 days a year number is hogwash in the real world. No one gets eight hours of coding a day done unless they're prototyping in a cave isolated from the world. Communicating through pull requests, ticket systems, emails, slack, etc drive real productivity to somewhere between 3-6 hours a day depending on the company. So what it really means is you're talking 1.5x-2.25x the amount of time. That's assuming all learning is equal and the you're given tasks which linearly increase your knowledge (which is just nonsense). I for one would not want to hire someone who needs three or four years of work experience to overcome their "junior" title.
I'm also in no way advocating they work more than 40 hour weeks or donate their time to the company. They need to be passionate enough to push their knowledge over a series of plateaus.
A lot of people go to "code schools" now but lack passion. They want the pay thinking it'll be easy because of shitty and evil marketing campaigns that make false promises. That passion will prevent them from excelling at the work.
That said, I think there may be a deeper issue here. You want to hire seniors which suggests that your startup _needs_ seniors and the experience that they bring. But you're hiring juniors.
You're going to end up disappointed as you need senior developers at this point.
They're going to end up disappointed as they require senior developers in the team to learn from and grow.
(Perhaps unrelated, I think if you've interviewed 400 people and haven't found someone "good enough", the issue may not be with the candidates...)
- A genuinely nice person.
If I have two things, I'm pretty sure the rest will work out in the end.
I had a few students working with me. The one guy who asks questions when he doesn't understand something and who isn't afraid to say so, helps me the most.
I also like when I understand what skills a junior dev has (e.g. HTML, CSS, JavaScript vs Java), so I know what I can outsource to him and have a clue about how long it will take.
But I also learned, that the overhead of managing someone and helping them can eat up all my time. You need to balance it out and have a backlog of low priority tasks to throw at them.
* Technical education (college degree, classes, etc.)
* Hands-on technical experience. This can range from an internship, to just building computers for friends and family. Something that shows initiative.
* Some other work experience, even if it's a cashier at Dominos or a volunteer position at a library.
I avoid resumes of candidates that have degrees but no measurable hands-on experience outside of school. I find students that have gone through high school and college with absolutely no work experience to be entitled and often spoiled. I understand that is not a universal truth, but I've observed it enough to not bother with those candidates.
In the interview itself, I look for candidates who:
* Are excited about the job, learning new stuff.
* Don't have a bad attitude. This can often be evident when talking about your stack. If you have, say, a Java stack, and the candidate makes some offhand comment about how Ruby is so much better, it's a hint about how they'll act on the job.
* Can answer basic questions about the stack they'll be working on. I'm not talking algorithms here. This is mostly to test if they give a shit about the job enough to read up on the details for 20 minutes before coming in for an interview.
Sounds to me like what you really want are senior developers at a junior developer salary.
Junior developers need to be given time to make mistakes and learn. I know a senior developer might seem too expensive for your budget, but hiring a junior developer might ultimately cost more for your project over time. The time that they're going to take to have to ramp up and learn everything is probably going to eat into the time to deliver any sort of product. What I'm saying is that a junior developer is a time and money investment, and sometimes it just pays to hire a senior developer/contractor and have them get the project out.
Anyway... what I would look for in a junior developer isn't whether or not they're amazing at data structures etc. I could really give a rats ass as to whether or not they're able to do something like Codility. What I need to see is that they know at least some basics on how to code, and that they have the aptitude and motivation to learn.
The two most important qualities to me in a software developer is the ability to communicate and the ability to learn. Why is communication necessary, particularly in a junior developer? I need to know that they're willing to swallow their egos and come to someone for help. It's the fastest way to learn.
Hell, I feel like I learned much faster because I was able to swallow my pride and ask someone with seniority for help. It didn't mean that I would run to them at the first sign of a struggle, but if I was burning most of my day doing something that I felt wasn't really going to teach me much, but was causing me to struggle with something - I would go and ask someone senior for help.
That's the core of what I look for in any (junior) developer.
Its the skeleton on which everything else hangs.
Its not the only qualities but the most important ones.
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.
The way I would do it is to focus on side-activities. If a hardware engineer built a website for a side-project, that's a good sign. Anything that shows success outside their expected space. Smart, fast learners tend to pick up random knowledge and apply it quickly and successfully.
People who need hand-holding tend to know their core topic well enough (they spent years in college refining those skills), but are having difficulty learning anything outside those core topics.
With 400 apps you'll need to send them a quickie programming challenge to thin the herd.
But, some advice: if you get 400+ applicants again, just throw out all but ~50 without looking at them at all. That's too many to process, any you're wasting too much time trying for find the "best" ones. Randomly limiting your pool will make it easier to make a decision.
Also, I hope you don't go the traditional interview route (ie white boarding). I think more companies should do a "make your own interview process" where the candidates decide what to show off. Maybe that's walking you through a project, some live coding/pair programming, assessing your product, or a presentation on some aspect of technology (like functional programming, databases, security, etc). The one that impresses you the most wins.
Another approach: break your backlog into piecemeal tasks and hire senior freelancers to do fixed work for fixed costs.
Mainly, though, I look for enthusiasm and eagerness to learn, the ability to communicate clearly, and intelligence. I also look for a balance of self-determination and the willingness to work through a problem on their own but also enough sense to know when and how the to ask the right questions when needed. Finally, honesty. If they've fluffed up their resume that is a red flag.
You are not going to be hiring senior level developers who've misclassified themselves. Juniors are going to take work; there is no avoiding that. Adjust your expectations to that reality and you will have a better chance of pulling in an employee that will do well for you over time.
I think you will find you will save money in the long run if you hire senior developers if you actually do require senior-level development skills instead of expecting junior developers to do the same work for lower pay.
This feels like a red flag. Do you have existing, more senior, people that can oversee the work? If so, perhaps that's a valid trade-off. It won't reduce the overall cost though, just the monthly burn. More junior means slower delivery, or less quality. There's no free lunch.
It sounds like you're trying to hire cheap developers, not junior developers.
If you really want junior developers, you have to do a crazy thing; hire people that are actually junior (have very little experience) but have potential. If you'd done that 4 months ago you'd probably have some decent developers right now.