Interviewing people for a software house has its constraints. Engineers work for different clients, in different technology stacks. There’s no real way to check the culture fit or the specific tools. I wrote more about this topic here.
So how can we design a good tech interview for a software house?
Constraints
Let’s start with making some constraints:
- we have one hour for the tech part of the interview
- there was an interview with someone from the people team already, which means that if the candidate passes our stage, they are hired to the software house
- the candidate is going to have another interview with the end client (not a must)
- we don’t know which client yet
Decision making
How do we know if the candidate is good and we should hire them? We can’t do A/B tests so it’s challenging to test different hypotheses and verify if they make sense. We need to rely a lot on our instinct and make some assumptions.
One thing that can help us is to learn how to articulate our decision making process. We could avoid just relying on “well, I guess she was ok”. There’s one check that I always do after an interview: I ask myself if I would like to work with that person.
We should also look at our set of questions and understand what is a good answer to us. Therefore, we should be careful with testing new questions during the interview because it could affect our assessment.
Check for signals
It’s clear that in one hour we won’t be able to verify the candidate against every possible situation. Therefore to make a better decision at the end of the interview, we need to constantly be looking for different signals. The ones that I would pay attention to are:
- Do they know the basics, so that they would at least know how to look them up?
- Can they solve problems?
- Can they explain their thought process?
- Do they listen to your questions or suggestions?
- Do they answer in a structured way or rather list out everything they know in the hope they would hit the correct answer?
Types of interview questions
We can use different types of questions to cover different areas and make space for the aforementioned signals to appear.
Specific technical questions
For these questions it’s easy to determine if the candidate knows the answer. But we should refrain from asking encyclopedic questions, the ones that could be easily looked up in Google or learned by heart. We could give the candidate small code examples that could use a few language constructs and ask them to reason about the code and walk us through the process. Hopefully it could also cover multiple topics so that we kill two birds with one stone and check if they know other topics as well, instead of testing them in isolation.
Example: How would you write a function isOverAge so that the adultUsers contains only users that are at least 18 years old?
const users = [{name: 'john', age: 18}, {name:'danny', age: 13}];
const adultUsers = users.filter(isOverAge(18));We can verify if they understand how filtering works as well as checking if they understand closures in JavaScript. It also opens an opportunity to talk more about immutability, functional programming, currying etc.
Coding exercise
No matter how well the candidate answers the questions, I would always give them a coding challenge. Even if they are not familiar with the syntax of the language their ultimate goal is to solve problems, so the theory and the knowledge of the language itself is not enough.
I prefer to state problems that make use of basic data structures. I don’t expect them to know all the complicated algorithms, but some of them are more common than we may think. I especially like to ask questions related to trees because they could be used in many day-to-day scenarios e.g. traversing a file system or any nested structure in general (e.g. content structure in CMS) or implementing a tree view on UI.
Open-ended design questions
These questions usually don’t have good or bad answers. But they leave plenty of opportunities to look for the signals.
- We can check if the candidate understands the trade-offs or just follows a path of a first decision
- Does the candidate make assumptions or try to get as much information as possible?
- Has the candidate experienced such a scenario in the past?
- Can they solve problems? The interview problem is probably one-of-a-kind so they have to improvise.
- Do they know different components of the software ecosystem? If they haven’t even heard about some of them they would never suggest it. We can give them hints to move their attention to a certain problem and check if they come up with the solution.
There is a whole topic of system design interview questions. There are books about it and plenty of videos on YouTube with mock interviews. But big tech companies usually have way more time to run such interview exercises. We need to cram this into an 1 hour interview together with other questions so it needs to be something shorter. That could be for example a single use case of a system. Sometimes I need to drop this section if I see a candidate struggling with previous secions.
Resume drill
We could start the interview with it. Resume is something that the candidate could feel most comfortable with. After all, it’s their own story, and skills. We could use this time to check additional things that are not directly part of this interview. Did they mention infrastructure? Try to dig into this topic – we may discover that it’s an area where they want to grow. Even if failed the other parts of the interview – we could still consider them because of that.
We can also discover that they mentioned it but actually haven’t actively participated in the project. This could be an alert that they put untrue information into their resume.
Candidate’s questions
It is important to leave some space for questions from a candidate. But this again is an opportunity for us to look for even more signals. We can sense what they’re looking for at their job, what motivates them, or what experience they had in the past.
Summary
Designing a tech interview for a software house has some challenges. Most notably we may not know the final client and their culture and technology stack. We’re also limited in time (but that’s probably a challenge with all company types).
To be the most efficient when it comes to interviewing we need to know what we’re looking for. We need to be able to articulate our decision process and be able to answer if we would like to work with that person. We could benefit from understanding the questions we ask and what a good answer means.
During an interview we need to look for signals:
- Do they know the basics?
- Can they solve problems?
- Can they explain their thought process?
- Do they listen to us?
- Do they answer in a structured way?
We search for the signals during the whole interview which could be made from:
- specific technical questions
- the ones that are easy to assess if the answer is correct
- hopefully covering multiple topics at once
- these could be short code snippets to go through and understand what they’re doing
- coding exercise
- proving that the candidate can solve problems
- usually revolving around data structures and basic algorithms
- open ended design questions
- that show their approach to trade-offs and challenging the status quo
- that show their knowledge of basic system components
- that show their ability to improvise as these interview questions are usually one-of-a-kind
- resume drill
- where we could discover the candidate’s hidden gems
- or where we could catch them in a lie
- the candidate’s questions
- that show their motivation and their experience
