Recruiting junior developers is NOT the same as recruiting senior developers - a different approach is required.
Junior/graduate software developers are NOT senior developers with fewer years experience. And yet, many companies interview and assess juniors/graduates in pretty much the same way as they interview senior developers. You need to change your process for assessing juniors.
Senior developers are often assessed according to what they know, and are typically probed with questions to find to their level of expertise, i.e.
- What does this do, in that programming language?
- Explain some deep detail to me about some programming technology.
- How do you do (some professional software development process, like testing)?
And of course when you interview senior developers, the questions relate to your company technology stack! Such as JavaScript or C# or Java. Makes sense, right?
The thing that mostly matters with senior developers is their depth of technical knowledge.
BUT THIS APPROACH IS WRONG FOR JUNIORS/GRADUATES! Junior developers are not senior developers with less years experience.
So how to assess juniors/graduate developers?
When you hire a junior developer, DO LOOK mostly looking for *personal traits*. Hire juniors for the person, the attitude, the energy, the enthusiasm, the motivation, the evidence that they have already built something. Then, when they have come up to speed - you’ll have all those personal characteristics, plus they will have learned your technology environment. You'll have a superstar.
When you hire a junior developer, DO NOT look for how well they know your company technology stack - it does not matter!
Here’s what to look for:
The “whole person”.
When you read their resume and talk to them, what do you see? Do they seem to be someone energetic, enthusiastic, smart, motivated? How much do they want this job you have on offer? This person - the whole person - is who you will be working with for years to come - look at the big picture of who they are as a person.
Can they communicate well?
Can they discuss *their own* software projects in depth, can they explain the technical details *not in answer to your technical questions*, but instead ask them to explain in depth their favorite software projects that they have already built.
This is a critically important point ...... the context of your assessment should be what the candidate has done already, NOT your technology stack. It's about THEM, not about YOU. If you assess them based on how well they know your company technology stack you'll miss out on lots of great people.
Do they work hard to learn, is there evidence?
Is this someone who works hard to learn, is this someone who *chooses* to write code? Can you see that in their resume? Ask them the straight question “tell me about how much you choose to code and when and what you write”.
Have they *done anything*?
What have they *done* already? Have they built projects? Did they manage to get anything complete? Building a software project to completion is a huge challenge and take much effort and learning. Make sure you give credit for getting something built. You should be impressed if a junior managed to get something built. And if they built something end to end and brought it to market somehow then be doubly impressed..... don't just ignore this, it indicates ability to plan and show they have the drive to think through and follow through lots of small details.
Assessing specific technology knowledge.
I’ll honestly say that I think it’s close to irrelevant what specific programming syntax they know and what technical questions they can answer during an interview. Syntax and programming can be learned - as software developers we have spent our entire careers learning. It’s just not important if a junior knows some specific thing about JavaScript or C++. On the other hand, it is necessary to do some assessment of what they know technically. Do this by asking them to explain what they already know, NOT by probing them to see if they know what you think they should know.
You'll find something odd when you probe the specific technical skills/programming knowledge of juniors - they'll surprise you with how well they know certain specific technical facts, then they'll shake your faith when they seem to completely misunderstand other things. Don't mark them down for that misunderstanding .... it's because they lack experience, that's all.
The key to assessing junior developers, more than anything else - can they engage in a deep back and forth technical discussion?
The foundation of all team based software development is discussion. You NEED your team members to be able to carry out deep back and forth technical discussion. I'll emphasise again the topic should be things that they already know, the topic should NOT be the technologies of your company technology stack. Ask about what is their favourite software they have written - the software they are most proud of writing, ask more about it, ask more about it again, get curious about their software, what problems did they hit, what went well, what did not go well, what did they learn, what would they do differently if they built it again, why did they choose those technologies, what was their role in the project? Ask what technologies they find interesting, what has caught their attention? What would they like to learn? Why do they like that technology etc etc etc. Try to get into a deep, interesting, back and forth discussion about technology..... that's only going to happen if it is about stuff they have built or are interested in.
Finally.
The single thing to remember ….. junior developers are NOT senior developers with fewer years experience. If you assess them the same way then you’ll miss out on really great future team members.
And of course I am both technical recruiter and developer. Contact me if you want me to help you find great people andrew.stuart@supercoders.com.au
