Our engineering interview process

We’re building out our engineering team here at incident.io, and one of the things candidates usually ask early on is what to expect from the process. This is understandable, given they vary hugely from company to company.

In our case, the process isn’t a secret and you shouldn’t have to apply to find out what it is. If you're considering applying to join the team, or you're in the process already and wondering what comes next, this post is for you!

The process itself is pretty simple:

In this post, I'll go over each interview and explain why we do it, who you’ll speak to and how it works. I'll also share some tips on how best to prepare.

We iterate on all our interviews in response to how effective the team feel they are and the feedback we receive from candidates afterwards — the original post was a snapshot from February 2022, but we updated it in January 2024. There's lots more information in our Candidate Hub.

Initial call

Why do we do it?

This is primarily a chance to say hello, get to know each other, and discuss any initial questions you might have about the product, team or interview process itself. It’s also a chance to discuss expectations around timelines, location, visas and salary up front.

Who will I speak to?

This call will be with one of the founding team, and for engineering roles, that's usually me. We also partner with a small number of carefully chosen agencies, so it’s possible that if they've reached out to you on our behalf, you may also have a quick call with them first.

How does it work?

This interview is 20–30 minutes long, and done remotely over a video call. It consists of:

Brief introductions on both sides: we’re always particularly keen to hear how you came across us and what prompted you to apply.
Questions from you - perhaps about the product, the team, our culture, our tech stack or the interview process itself. Whatever’s on your mind.
Questions from us - I read every CV beforehand, and based on that and the discussion to this point, we may have a few quick questions.
Next steps - assuming you're still keen to move forward (which we hope you are) we'll talk next steps.

Tips on how to prepare

Think about whether you want to work at a small, fast-growing startup. If you’re not sure, what questions could you ask us that would help you make that decision? We care a lot about making this a fantastic place to work, but there’s a lot of ambiguity, the company will change frequently and we move very fast. It’s not for everyone!
If you want to learn more about us and the role before we chat, make sure you’ve re-read the job description. If you have time, other things to explore include our blog posts, :, roadmap, documentation, Slack community and of course, the product itself. Is this a team you’d want to be a part of, and a product you’d be excited to build?

1: Hiring manager interview

Why do we do it?

If all goes well, we’re going to spend a lot of time working together!

While we (obviously) care about your ability to solve problems, write code and design more complex systems, we think companies often focus far too hard on these topics at the expense of discussing everything else that goes into being a great product engineer, and part of a high performing team.

This interview is another “get to know you” style conversation and we like to do it early. It’s a chance for us to learn more about the way you think and how you like to design, build and ship products (and vice-versa).

Who will I speak to?

This interview is often with either the CTO (me) or CPO (Chris) and we’re usually joined by someone from the engineering team.

How does it work?

This interview is an hour long, and is done remotely over a video call.

We’d much rather have a great conversation than test your on-the-spot recall, so we send you the questions we’ll ask in advance. If you’re already wondering what they might be, why wait — here they are:

Tell us about a problem or challenge you’ve faced that you found particularly interesting or rewarding to solve. How did you approach the situation, and what was the outcome?
Can you describe a situation where you had to make compromises or trade-offs in order to deliver a project or product feature quickly? How did you approach those trade-offs and what was the result?
What does "having an impact" mean to you, and could you share an example of how you’ve made a notable impact in your current role
Imagine you join incident.io as a Product Engineer. What new feature or improvement to an existing feature would you like to see given what you know about the product?
We all collect valuable experiences throughout our careers. Can you share an example of a lesson you’ve learned that strongly resonated with you and is one you’d be eager to share with the team if you were to join incident.io?

Tips to prepare

Come with great examples which you’d be happy and comfortable talking about in depth, rather than pre-polished or rehearsed responses. We usually ask several follow-up questions.
Try and answer honestly and from your own perspective. We want to hear how you think and what you care about, not what you think we care about.
These questions touch on things which matter to us, the way we work and the work we do, and we imagine they’ll probably matter to you, too. While we’ll be leading the conversation, we love getting questions in return!

2: Coding challenge

Why do we do it?

A lot has been written on the various approaches to interviewing engineers using “coding challenges” in one form or another. I’ve used or been through many of them before myself, examples include:

Algorithmic problems, often solved in pseudocode
Take home tests, which you do in your own time
Live pairing, often via shared REPLs on the web
Build something from scratch in a language of your choice
Extend a boilerplate or “fill in the function” in an existing codebase
Send in a sample of work

There are probably many more, and some companies may even choose not to do anything at all. I think it’s fair to say that whichever approach you take, they all come with tradeoffs.

At incident.io, we’re a very small team early in our journey. We work collaboratively, under tight (self-imposed) constraints, perhaps with code we haven’t touched before (or at least haven’t touched in a while). We have an interview which we feel tests for that, amongst other things.

Who will I speak to?

This interview will usually be with two members of the engineering team (often myself and one other).

How does it work?

This interview is an hour long, and usually done remotely over a Zoom call.

We’ve designed this interview to be representative of the kind of work we do here. We’ve taken a very small self-contained utility we wrote for ourselves to solve an actual, real world problem, added a test suite, then removed two features and introduced a bug which breaks the tests. We’ll ask you to get the tests passing again and implement one of the two features.

The interview will go something like this:

We’ll send you a zipped up version of the code in the language you prefer, and ask you to open it up in an editor of your choice
We’ll set some expectations - you can use any editors and tools you like, Google is absolutely fine and you can use us as a sounding board if you need to.
You’re welcome to talk us through your initial thoughts as you explore the codebase, or orient yourself solo. We know for some people verbalising their thoughts whilst absorbing new information is harder than quickly reading everything on your own first. That’s absolutely fine!
We’ll then ask you to go ahead and debug the code to fix the failing test suite
Once the test suite is passing, we’ll ask you to implement one of two small features explained in the README

Tips to prepare?

Pick a language and a setup that you know well. We currently support Go, Typescript, Ruby and Python. If your favourite language isn’t one of those, please let us know and we can discuss how best to move forward.
Make sure that as far as possible the computer, editor and peripherals are the ones you know best. If you’ve recently decided to learn VIM, I applaud you, but we want to see you solve the problem, not debug your keybindings.

3: System Design

Why do we do it?

We spend a lot of time writing code to solve problems, but the work often starts way before then. As a team, a lot of what we do is working together to think through how we’d build a new feature or product in the first place.

This interview is designed to replicate a discussion where we talk through a potential product idea, think through the technical implications and design the system we’d have to build to power it.

This is also a chance to discuss a lot of very interesting problems you encounter when building applications for the web. If you haven’t done a lot of work with web applications and distributed systems, you might find this slightly harder than some of the other interviews, but don’t worry, we’ll guide you through it!

Who will I speak to?

Similar to the coding challenge, this interview will usually be with two members of the engineering team.

How does it work?

This interview is 1 hour long, and usually done on-site in our office.

It will go a little like this:

We’ll present you with a potential product for us to build. It’ll be a real product idea, so it’s the kind of conversation we would commonly have here at incident.io HQ.
We’ll explain the high level scope of the problem, and let you ask any questions you might have up front.
We’ll build out a solution, with you leading on the design - ideally focussing on the simplest working solution to start with.
We’ll then take your initial and expand on it together. What could go wrong with our design? How would we know if it did? How could we avoid or address the issue?

Tips to prepare

Familiarise yourself with some of the core building blocks of systems and why we’d want to use them - databases, queues, CDNs, caches.
Think through some hypothetical systems, how do you go from “idea” to “something we could actually build”? How would you represent a basic web application? Now how would you extend or optimise it for your specific use case?
Think through common failure cases in web applications. How could your design fail? How can we make it more resilient? Reading incident post mortem reports is a great way to get your brain thinking about failure cases
Being able to articulate your ideas clearly is important to us (and for this interview). Whilst we're definitely not assessing your artistic abilities(!), it's often useful to visualise systems to help us get on the same page. You'll have access to a whiteboard, paper and pens if needed, so it's worth practicing using them beforehand.

4: Culture

Why do we do it?

We've already covered a lot of what we're looking for in the interview process by this point, but it’s all been quite focussed on product and engineering.

There’s a lot more to the team we're building here at incident.io and this is a chance to have more of a two way conversation, to dig into whether this is somewhere you'd really love to work.

Who will I speak to?

Up until this point, you’ll have met a small number of the incident.io team, most of them either founders or engineers. However, we have all sorts of amazing people you’ll get to work with if you come here. This is your chance to meet some more of them!

You'll likely be speaking with two people you’ve not met already, often the founders and/or someone from operations, customer success or sales.

How does it work?

We have a few questions and topics we’d like to cover and we’ll use those as a guide, but we’re expecting you to come with questions of your own, so don’t hold back. This interview is a great chance for you to ask us about the things that matter to you.

A few topics we might cover include:

Motivation - what gives you energy? How can we give you more of that?
Feedback - what does great feedback look like for you?
Culture - is there anything you love to see from a company culture? Why?
Conflict - disagreement can be good, how do we ensure we keep it healthy and learn from it?

Tips to prepare

Reflect on what you want from your job — are there any things you’ve particularly enjoyed or not enjoyed in past roles? Why?
Were there any times in your career which were particularly formative for you? Why?
If you've had any difficult conversations with your team or manager, how did you/they react? What did you learn?

That's it!

As with any startup, our success is going to be built on hiring great people.

Interviews are clearly a key part of that, so we care deeply about our process and we spend a lot of time on it. It's also important that interviews work both ways, and there's time for candidates to evaluate us. We know our process isn't perfect at either (and probably never will be) but it's working for us, and we'll keep iterating!

Our hope is that by sharing this kind of information openly, we can demystify the process and make it a little more accessible to the people we want to hire.

Maybe that's you? In which case shoot me an email or check out our roles - we look forward to meeting you!