How to interview and hire junior developers
Today we are kicking off our hiring series! Stay tuned every Wednesday for more hiring tips for startups.
Hiring junior developers is becoming an increasingly attractive option as the technical talent drought continues. Actually, it's a really good option, but only if you know how to hire the right junior developer.
Before I go into the how, let's start with the when.
When should you hire a junior developer?
First off, you already have one or more senior technical people on your team. You also have the patience, willingness and time to train and mentor. I've met numerous business founders who hired recent graduates to build out their ideas, because they thought it was cheaper. Alas, it's not. Junior developers need guidance, otherwise you'll simply burn your money. If that's you, you can stop reading this post now, and google how to hire senior talent.
Assuming you're ready, your goal is to find a junior developer who will grow in the position and become an intermediate in no time. In addition to picking the right person, it's your responsibility to offer them the right environment to grow.
Finding potential
What makes hiring a good junior developer much harder than hiring a good senior developer, is that they have no past to look at. Young talent is unproven. You need to be really good at (or get really good at) reading potential. You are looking for two main things.
- A problem-solving mind set, coupled with a strong foundation. Drill into how they think. What are their analytical and logical thinking skills like? How well do they understand the basics of computer science?
- Strong communication skills. You are going to need to communicate with them to mentor them. Do they understand what you say? If they have questions, do they know how to ask it? Do you understand their questions?
This is in addition to the soft skills you want in all your employees, like the right attitude, leadership potential…etc.
Now that I have done many interviews, I noticed a pattern between strong foundation and the kind of education the candidate went through. With the hiring crunch, coding bootcamps are springing up everywhere, but I personally don't believe they're a good alternatives to universities.
Don't get me wrong, I do believe the university education system is far from perfect, and I look forward to that market being disrupted, but I haven't seen a good alternative yet. It simply seems that those who haven't gone through formal education tend to short-cut the basics. I've met with candidates who have developed nice web apps, but don't know what a class or an object is. These people will be hard to mentor.
The Technical Interview
Here are the different types of questions you need to cover in your interview. Each of them tests a different set of skills, so be sure to include questions for all types. Prepare the questions before the interview. And before the interview, make sure to test the questions on people who are familiar with the knowledge level of your candidates. This is very important in order to gauge how hard or easy your questions are.
Architecture
A junior developer should be able to architect new small features for your product, and be able to understand the reasoning behind the architecture in place.
Devise a basic problem and build more on top of it. For example, you can start with something like "Imagine an app where users can follow/unfollow other users. Explain the relationship model that you would implement to support this." Then you can add "Imagine you can sort your followers. How would you implement that?" And so on... The best place to create questions like this is from your own code base. It will be original and real.
The interviewee might not be able to come up with the most elegant solutions, or the most scalable ones. In most cases, they won't realize the drawbacks of their own solutions. That's okay. But they should be able to come up with something that does work (as in: no glaring problems with it).
When you point out ways to improve their solution, they should be able to understand you, and ask relevant questions. For example, if you explain how something is too coupled, or why it's not scalable, you should feel like your interviewee is taking this in and communicating back with ease.
Algorithms
Algorithm questions can be very insightful. They test both their problem solving skills and how strong of a foundation they have. While the architecture question tests high-level thought process, the algorithm question tests step by step low-level analytical skills.
Again, you should ask the question and if they get it right, make it harder. If they don't have an answer, give them a hint. The point here is to get a good idea of how they think, not to get a perfect answer on everything you ask.
An example of this would be asking:"Write an algorithm that divides one number by another, without using the division operator."Once they give you an answer, ask them to make it better than O(n). If they don't have an answer, hint "try a recursive function".
Puzzles
While algorithms test the combination of analytical skills and computer science background, puzzles isolate the analytical skills. Choose puzzles that have a correct solution. You will not get a lot of insight about your candidate from asking 'How many ping balls can you fit in a room?'. You can find some good examples here, although you might want to find less common questions.
UX/Product
You're not looking for a UX expert, but you are expecting enough common sense to not build horrible solutions when they are not given an explicit design. You definitely need someone you can talk to about UX and reason with.
Pick a UX weakness in your product and discuss with them what you can do about it. This way you can also get a sense of your candidate's knowledge of your product and the culture fit.
Fast Tech Questions
Discuss what is good and bad about the different programming languages they're familiar with. Discuss the libraries they've used. What are the things they consider before choosing a library? You can ask questions on OOL, inheritance, duck typing, design patterns, etc.
This is where you get a general sense of their level of experience and the knowledge they acquired through school or side projects.
The Programming Test
Give them a small assignment they can do in a few hours, and have them do it in your offices. Simulate the real thing. You should allow them to use Google, because in the real world they can. Ask them to develop it the way they would if it is going to be deployed tomorrow, not as a throw-away prototype. They should TDD and all.
Do not ask the FizzBuzz question. It is stupid simple, and simply not a good filter.
I like to choose a language or framework they are not familiar with, because in the real world you get to use new frameworks all the time. E.g. If they are familiar with javascript, ask them to write it in coffeescript and TDD in jasmine.
This covers the technical part of the interview, including the necessary communication skills to be able to mentor the new hire. For the non-technical part, stay tuned for tips on hiring the right people for your startup or small business in our hiring series.
Are you currently hiring a junior developer? What kind of experience/skills are you looking for and how are you testing for those skills? Let us know in the comments below!