How I hire engineers for a small SaaS

I find hiring one of the toughest things I do as a founder, and it's crucial to get right. I’ve hired engineers into large online retailers, a Fortune 500 company, and for my own small SaaS. A failed hire is bad for the company, the team and the hire themselves. Learning from my mistakes and successes, I’ve developed a process and tools that make a failed hire much less likely. Even if the candidate is not successful, we respect their time and make it a good overall experience for them.

Job description

Job descriptions are typically a bulleted list of hard skills plus some generic soft skills like 'team player' and 'detail-oriented'.

I've found that asking for the type of systems a candidate has worked on is better than just languages and frameworks. A Rails app could be an internal CRM with 10 users, a static website, or a SaaS platform with tens of thousands of users. An engineer who's worked on the SaaS has probably dealt with performance issues, production uptime being critical, competing demands on their time: the kind of things that differentiate an engineer from a coder. Things that are hard to learn without experience.

On soft skills we try to do a bit better than using hackneyed phrases like 'team player' and 'detail-oriented'. They don't do enough to let candidates screen themselves out since they're hollow and overused. Instead, we know the kind of people we want to work with, so we paint a picture of what their days would look like.

For example, we'll write: ‘You'll be working with our product manager daily on requirements and how best to solve problems, still leaving space for uninterrupted development. But you’re not a developer that puts their headphones on, disappears for three days, and then submits a monster PR’.

There's a place for that kind of developer. Perhaps they're working on a complex algorithm with clear parameters where they can work solo for days. That's just not how we work. We're a small team who constantly collaborate, while respecting the need for focussed development time. We want candidates to read our job description and screen themselves in or out because they know how they work best.

Review applications

Reviewing applications is always a bit of a slog. My technique is to typically take a couple of passes over them as I found it the fastest way to process the volume.

Those that get discarded immediately haven’t bothered to read the job description and don’t have one of our must haves. Interestingly, we’d occasionally get applications where they don’t fit a must have but they explain why. These show an attention to detail and enthusiasm that puts them through to the next round purely on that basis.

The next easy passes are cover letters or CVs that are very poorly presented: mistakes to the point of being hard to understand or clearly a copy/paste from an earlier application (Dear Nokia, I’d love to work…).

Spelling and grammar mistakes require subjectivity. To start with I was a bit too judgemental when I hit a spelling or grammar mistake. Really, we all make mistakes in spite of checkers, so to focus too much on this can throw away good candidates making a strong effort. My bar here now is ‘hard to understand’ or 'sloppy'. Clear and understandable written communication is vital, so working with someone whose writing needs to be re-read to understand it would be tiring.

The hundreds of CVs and cover letters present themselves in all kinds of ways. There are those written in Word with the default theme, to fancy, crafted interactive websites. I appreciate good design. The trap I try to avoid here is getting dazzled by a slick CV. I’ve hired someone with a pretty CV, only to fire them a month later. We're not hiring a designer, so it is pointless to judge how well they can design a CV. At the same time, they should be able to present themselves in a good way, with an eye to at least avoid gaudy or sloppy design.

When reviewing cover letters and CVs I try to keep subjectivity out of it as much as possible and focus on facts: do they satisfy the criteria from the job ad. This leaves room for where subjectivity is needed, the screening call.

Screening call

I find screening calls fascinating. The picture of a candidate I have in my mind from reading their CV and cover letter often jars with what it’s like to arrange a call and chat with them.

The scheduling process itself weeds out some candidates. We start by sending a templated email describing the call and how to schedule. Scheduling is easy, with a calendar link and options for the candidate themselves to cancel/reschedule if plans change. Even though it’s a concise, descriptive mail, there are those who ask questions like ‘are we going to do Skype?’ (when we detail Zoom and how to use it) or reply with ‘when are you available?' instead of using the calendar link. There are also a good number of last minute cancellations and no-shows without explanation. Those who can't follow basic directions or show courtesy are disqualified.

My strategy with screening calls is to talk to as many hopefuls as possible and discard the majority. There has been very little subjectivity up to this point, now is the time to get a feel for if we could work together. We strictly limit calls to ten minutes. Ten minutes respects everyone's time and forces focus on getting that subjective feel rather than working through skills and experience.

It's always a video call. Working remotely, video calls are how we build deeper connections. They help us pull together as a team like Trello comments or Slack channels can’t. Candidates who don’t want to use video are out. This may seem harsh, but when I’ve overlooked it in the past it should’ve been a red flag.

Poor quality audio / a flaky internet connection is a bit more difficult to hold against some candidates. If it is bad to the point of not being able to communicate, there’s no alternative we can use, and the same is repeated at interview, they are not going to be easy to work with. This will also rule them out. While we do offer coworking membership as a perk, it’s up to candidates to come up with a call solution for the recruitment process, even if we have to switch to voice only telephone.

We spend the ten minutes having a general chat. It's much more like a coffee date than an interview. I steer it away from any script the candidate has prepared or going through their CV. It's about getting a feel for if we could work together, that we're on the same wavelength, and that we'd enjoy collaborating. The challenge with some candidates is getting the switch from formal interview thinking to seeing their personality shine through.

A majority fail at this stage. A few for the logistical test. Then others where conversation doesn’t flow. Some push push push over the ten minutes as if it’d help their chances. And talking with some feels like we’re missing each other’s meaning.

These ten minute screening calls are an excellent way to respect everyone’s time. Only those who have a good chance of being hired need to invest a couple of hours in the next stages.

Coding Engineering test

“I don’t do coding tests” - I've heard that a few times. And I agree. Most coding tests are a waste of time, testing things that don’t reflect how well someone's going to do the job. They work in a fake sandbox that doesn’t replicate the real world of development. The scenarios are synthetic. Candidates are asked to code in a textbox without the editor / IDE / help they’d normally use.

Quality candidates do balk at doing coding tests. We specifically address these objections in the email inviting candidates to our test (it helps that I’m an engineer who’s really bad at coding tests). I respect those who hold fast and won't do a test, but we're looking for candidates who can see we've addressed the biggest problems with coding tests and are willing to at least give ours a try. We can't have stubborn, uncompromising people on our team, and here those who hold fast and refuse a test may tell us they'd be one of them.

Our test has two aims. First, to set a coding low bar. Second, to examine how they approach problems, communicate and deal with constraints.

The coding low bar is tested with just a couple of basic programming questions. They can choose to solve them in any language the team understands and use any editor / IDE they want. The questions are things a junior engineer could solve. There's no domain knowledge required or an existing codebase to thumb through. Shockingly, some fail these basic questions.

Next in the test we try to simulate engineering scenarios where we outline some broad problems. They're not asked to solve the problems themselves, rather to describe how they'd approach them. This critical thinking aspect of software engineering unearths both battle-hardened, experienced engineers, and promising talents who don't have as many years on paper, but think through problems deeply.

Here’s an example: performance optimisation. We first describe our team of product manager, engineer and support person and say that we always look to involve the team when issues are found. Then we outline a scenario where the engineer looks in the logs and can see an operation that used to take one minute is now taking 30 minutes. How do they approach this? Step one is to even decide if it is a problem. Candidates who pick this up start with a green tick. If they don’t, and jump straight into analysis, that isn’t a fail since this is a synthetic scenario, but does raise a question mark we want to examine more in the interview.

Another tick would be if they speak to the product manager and support to see how it could impact customers. Again, not a fail if they don’t. What this question is seeking to find out is how the candidate feels about premature optimisation, why and how to optimise. Some engineers want to ‘optimise all the things’. That doesn't cut it for our business. It's the hallmark of a developer who factors company and user needs into engineering decisions who collaborates with colleagues to decide if performance is a problem, decide how fast it needs to be, hones in on where it can be optimised most effectively, and then deploys and measures.

Other areas we ask subjective questions on are outlining technical options to a non-technical manager, how to test, architecture decisions, dealing with legacy code, managing their time and priorities. Their answers give us a good feel for how they work, who they are, and what kind of systems and teams they’ve worked with before.

As an engineer who’s seen a lot of ways of working, I’m now pretty opinionated about the approaches which work best. I don’t know it all and I love to be challenged. We're looking for deep, critical thinking, and not just jumping straight in to code. If a candidate doesn't think like that they're out.

For those that pass the test, their answers prime for some good conversations in the interview.

Interview

The interview is around an hour, on a video call with two team members. It’s not a rule, but the best interviews tend to pan out as 1/3 standard questions, 1/3 digging into their test and CV for areas of concern / highlights, 1/3 selling our opportunity and answering their questions.

The standard questions are open-ended. We look for examples from their career: ’tell me a time when you were particularly proud of your work’. They prod in places that can expose values that don’t fit with ours: ‘what’s one of your weaknesses’, ‘what was your last professional mistake and how did you deal with it’. They are thought-provoking and not easy to generate stock answers to.

In the next third we dig into the candidate's test. I enjoy this part the most. It’s really interesting to explore why they answered the way they did. The discussion tells me a lot about how they’ll contribute. Can they challenge others in such a way we improve, can they listen and learn, or even concede when needed. We don’t want mavericks and we don’t want yes men. A real discussion about their answers shows who they are.

In the final third we sell our opportunity and answer their questions. It’s important to leave enough time and space for the candidate here. I'm looking for them to raise everything from relatively straightforward questions to those that show they’ve really done their homework on the company, product, people and opportunity. The worst candidates have no questions. This betrays at the very least that they aren’t curious people, and at the worst that they aren’t really interested in what we’re doing.

As soon as the interview is over I jump on a call with my co-interviewer to chat first impressions.

Post interview first impressions

I've been taking notes throughout the interview. This call helps me to round them out, adding where my co-interviewer picked up things I didn’t and to get their perspective.

It isn’t a long call and there’s no decision made. These 5-10 minutes seed other things for us to think about and revisit when we later review all the candidates in more detail.

Team coffees

By this stage we should have a couple of strong candidates that we could see ourselves hiring. If we’re struggling to get a couple it’s important not to get sucked into looking at all of the time and effort we’ve invested in the process and putting people through ‘just because’. It is hard work, but starting with a fresh round is better than a bad hire.

The remaining candidates are now introduced over message/email to individual team members and invited to arrange a short coffee call with them. Building a team spirit and serendipitous connections is tough remotely. I want our team to enjoy working together. Even if Julia is not going to work directly with Justine, they should still know them, what they do, and chat from time to time.

These calls rarely take anyone out of the process. But with a small team we have the luxury of getting more people involved and hopefully kindling that remote team spirit.

Decision

I feel that our hiring process gets a good balance of being thorough while respecting everyone’s time. When we get to the decision stage I’m confident we’ve explored the breadth of what it’d be like to work together and the strengths and weaknesses of the candidates. On weaknesses, I get worried if there’s no clear weakness in the candidate, because this means we just haven’t found it.

In most of the hires I’ve made we’ve uncovered some kind of weakness in the candidate during recruitment. Weaknesses could be any number of things like not having a good eye for design, no dedicated workspace at home, or they’ve never worked support. We probe this with the candidate and talk about if it could be a negative for us.

Regardless if it's me or someone else on the team that'll make the final decision, I want to hear multiple perspectives. Our background, culture and role give us certain prejudices and thinking. We must pull in others from the team to make firm, well-rounded decisions on hiring.

By this stage it’s usually clear who we should hire. It should not be forced. Ignoring niggling doubts without addressing them head on just because we are desperate to hire is a terrible idea (been there, done that).

Hiring is still one of the hardest things I do as the founder of a small SaaS. But it’s so rewarding when you connect with someone, they agree to join your mission, and they grow into a key part of the team.