Recruiting engineers for small companies


Recruitment is hard and it is particularly hard when your company is small. Resources can be slim, engineers are in in high demand, time is short and recruiting the wrong person is costly. Most of my experience comes from (Australian or Dutch) start-ups with around 4 people in the dev team. Often we did not have a HR team, so responsibility was on us to recruit. Here are some of my notes from recruiting over the years.

Keep the interview process simple

One part of interviewing that is costly is the amount of time it takes. You don’t want to spend hours and hours interviewing candidates, and candidates don’t want to burn their time either. That being said you still need some time together to see if you can work well. I’ve settled on a 30m intro chat and a 2hr onsite. It’s relatively easy to organize and at the end of the process we should have a reasonable idea of what it’s like to work with the person.

Example process:

- Intro interview ~30m
- Onsite ~2hrs (can be virtual if needed)

Have the wider team involved in the interviews

This depends on your team structure, but if individuals on your team often interact with designer/product people, try to involve them during the onsite. This can be framed as a UI question or a high level product question during the onsite.

For example:

How would you design an age filter?

The point of the question is to see how the candidate communicates with the designer/product person. There’s usually no single right answer, but there are bad ones and your designer/product person can give you valuable feedback.

Set up a referral bonus

If you’re using recruiters or job matching websites, costs can be between 5-30% of the annual gross salary. I think it makes sense to offer a reasonable referral bonus (~2-5%) to employees even if your team is small because humans are more likely to remember things when there’s $$$. The worst case, is that someone is hired that already would have been hired, but considering how hard recruitment is at the moment I would say it’s worth the risk.

Scheduling an interview

It’s important to let the candidate know in advance what to expect of the interviews. Usually I just mention the structure of the interview in the interview request.


Hi Fred,

Thanks for your interest in Cactus! We would like to invite you to a 30 min call with myself and one other developer. We will be asking some high-level questions about your experiences and there will be an opportunity for you to ask questions of us.

Please send me some time slots this week or next when you’re available.

Thanks, Shane

I never used calendar apps because they always seem to make it harder than it should be…

Make the onsite collaborative

I think collaborative questions are a good way to determine if the candidate can work with the team. I tend to do this by asking high level questions which have many answers and usually require the candidate to ask clarification questions. For example

How would you model a patient?

Expected questions:

Sometimes a candidate will come up with an idea we’ve never seen before and then we have an opportunity to bounce ideas off each other.

Ask about hard requirements during the intro interview

It can be quite frustrating to reach the end of the onsite only for the candidate to fail miserably on a coding question because they never dealt with a particular data structure before. If you have something like that in the onsite, be sure to verify that the candidate knows about it during the intro interview. This can be particularly important for more junior candidates with varying experience/education.

Always try to link questions back to the team/position. For example, if you ask the candidate “do you prefer backend or frontend”, also explain the current teams preferences. Or if you ask “what’s your experience with end-to-end testing”, also explain what the current state of end-to-end testing is in the team.

Ask questions on opinionated topics

Some engineers have strong opinions, this can be great if it matches with your team culture, but it can cause issues if it doesn’t. I try to touch opinionated topics relevant to the team during the onsite organically.

Example topics:

It’s important not to get too involved in these discussions. If the candidate expresses a strong opinion that doesn’t match the team, I will mention how the team currently deals with it and then move on. Also, I don’t think a conflicting opinion necessarily means the candidate is not a fit, depending on the team, there may be appetite to try something different.

Show candidate the architecture/stack

During the onsite we would often ask the candidate to draw a stack that they worked on. Afterwards we would ask them some questions like scaling, security etc. Then we would flip it around and ask them to draw our stack. The candidate could ask as many questions as they want. This way the candidate has a good opportunity to see what they could be working on. It is also a good sign if the candidate asks us hard questions about our stack.

Show the candidate the engineering process and tools

It can be hard for candidates to get a feel of day to day life at the company. One way to give them insight is to simply show them the wider parts of the engineering process. For example if you’re using github, show the candidate what a PR looks like. Or if you are using Jira, show the candidate what a product ticket looks like.

Example interview templates

Intro interview

We usually ran this with 2 devs. One dev would lead the interview and make sure we are on time. The other dev would be responsible for asking most of the direct questions. The main reason for having 2 people involved is for perspective, however if time is short this interview can be run with one person.



Onsite interview

We ran this with at least 2 devs and tried to bring in our designer if he had time. Before each onsite, we would choose one dev to lead the interview. Then the sections were divided up between us. If we had time at the end of the interview, we would try to get the founder to meet the candidate.



The structure here is pretty specific to the team I was in at the time, so I’ve kept it quite high level. In general this should be tailored to the technical requirements of your team.

I think it’s particularly important that if there is a coding test that it should reflect work that the candidate might actually do at the company.