Hiring the Best Talent
It can be hard to interview a developer to see how they will fit into your team. Here are some tips to help you find the best talent for your company. While I will be talking about senior developers, I’ve used this setup for developers of all levels. I am going to focus on what to look for with senior devs, but just knock it down a few pegs for junior or mid developers. With a few tips you weed out any subpar talent and find the best fit for your team.
1. Get Into An Interviewing Mindset
When you’re interviewing a developer, you need to be in the right mindset. You need to be prepared to ask the right questions and listen to the answers. You need to be able to think on your feet and be ready to change your approach if necessary. Most importantly you need to put your daily tasks aside.
I have interviewed many candidates and have been interviewed many times myself. I can’t tell you how bad you make your company look when you show up to an interview annoyed to be there. I get it you might want to help get things done at your company, but it’s not just about the candidate impressing you, it’s about you impressing the candidate. You want them to want to work with you. Next, put yourself in their shoes. Have you ever talked to someone who didn’t want to be there and did you leave thinking “wow I really want to work with that guy”?
No! You probably thought “what a jerk”!
2. Ask The Right Questions
When you’re interviewing a developer, you need to ask the right questions. You need to prepare and in my opinion that means coding exercises. I know some people don’t like them, but I think they’re a great way to see how someone thinks. You can see how they approach a problem and how they solve it. You can see if they can think on their feet. However, you should try to make it as low stress of an experience as possible like a real day on the job.
2.1. Coding Exercises
You can find the sample repo I use for my interviews here. The repo is structured for the full interview. You should setup the interview to help lower people’s stress.
You can also use Github Codespaces to make it easier for the candidate to get started. They only need a web browser to be able to do the interview!
I like to introduce the interview as this is going to be similar to a day on the job. It is not pass or fail. We are using this structure to see where you range from super duper junior to super senior and we’ll end the interview when we feel like we have enough info. If you pair program at your company also ask them to try to think out loud. That is something you do regularly in a job where you pair and is super helpful when you need to explain your pull requests. This is a good skill for new hires to have!
Make sure you do this. This is a pro-tip because you can pull the rip cord if you quickly figure out someone would not be a good fit for your company.
Next, we’ll discuss each problem and what you as an interview are looking for. This is important because you want to make sure you’re not just looking for the answer, but how they got there.
2.1.1. Fizzbuzz
The first problem is Fizzbuzz. This is a classic problem that is easy to solve and shouldn’t be hard for someone as a senior. You should look for the following:
- Did they make it inclusive? The prompt asks for 1-100 most people forget to include 1 or 100.
- Did they use a for loop? Why did they pick their solution?
- Are they happy with their solution? If not, why?
2.1.2. Drone TDD
This is a problem that is a little more complex and a way to emulate true Test Driven Development. You tell the candidate to write enough code only to only pass the test. You should look for the following:
- Did they write too much code?
- Is the code easily refactorable?
- Are they explaining their thought process out loud?
In a normal role even if you don’t pair program or do TDD, I find myself explaining my thoughts during pull request reviews. This is a skill that is super underrated!
2.1.3.A String Calculator Kata
I typically don’t do this problem. I am either satisfied with what I’ve see out of a more junior candidate or I like to move onto the list one problem due to time constraints.
2.1.3.B ToDo Lists
This list example is a good way to see how they handel a more normal work day. This one I give them 3 options to work on next. This todo list isn’t great to say the least. All it does is add a new item. There’s no complete, delete, or reorganize.
I tell the candidate the scenario is this is a todo list application that you use for your weekly check-in with your boss.
There are 3 tasks we are going to ask to add to add similar to a jira board where you can pick a task.
They are the following:
- Have a clear list button so we can start the week off fresh
- Allow us to delete a task
- Allow us to mark a task as complete
- Put all completed tasks at the bottom of the list
What you want to see here is how they handel working on a team. If you pair tell them you are their pair in this scenario and they can ask you questions like you would a pair. Observe how they Google when they get stuck. Can they actually write code that makes sense? We put them on the spot so give them some grace, but I’ve interviewed at least one person that could answer any Angular trivia but couldn’t write a JS function. This covers that.
3. Listen To Their Answers
When you’re interviewing a developer, you need to listen to their answers. You need to pay attention to what they’re saying and how they’re saying it. I believe a general rule of thumb is a senior developer should be able to finish or be on track to finishing all of the problems. I also think most senior developers also share a fun tid bit I forgot or learned from them.
Finally, remember as you continue to do these interviews don’t be afraid to tweak it to your needs. Using this framework I’ve been able to recommend hiring a few great senior developers!