Interviewing can be a scary and daunting process. Some companies thrive on keeping their interviews a mystery, shared in hush tones in private groups. We want to explain exactly what our backend engineering interview process entails to make it fair and transparent for all our applicants.
This post explains what you should expect from each of our interviewing stages and how to prepare.
We have four interview stages:
Take-home or pair coding exercise
All interview stages are with engineers or engineering managers who work at Monzo and develop systems or manage engineers on a day to day basis. Interviews will typically contain a tenured engineer but may also contain observers who are learning to become interviewers themselves. Each interview will have time dedicated for you to ask questions about working at Monzo and working on a specific team.
Let’s break each of these stages down!
💬 Recruiter call
The majority of our hiring processes start out with a recruiter call. The recruiter will guide you throughout the interviewing process. They will go through the role you’ve applied for to make sure you are the right fit for the role and whether the organisation is the right fit for you. They will go through the interviewing process and be on-deck to answer any questions.
You’ll also learn what Monzo’s mission is, how backend engineers work towards that mission and how you can play a crucial part in us achieving it.
☎️ Initial call
The initial call is geared towards understanding your background and experience. We will have already read your CV so this is your opportunity to dive deeper into your contributions.
We like to focus on projects you’ve worked on recently as those will be most fresh on your mind. We want to get into the details of how the project manifested, how it was implemented, what trade-offs were made, what would you do differently in hindsight, and more.
You’ll be speaking to fellow engineers (maybe even your future team members). We like to hear about the technical details such as data structures, language choices, performance/reliability trade-offs and security considerations. Interviewing is a two-way street so feel free to ask engineers on this call how we do things you discuss at Monzo. We love talking about the work we do and our tech stack.
Spend time getting up to speed on a recent project you’ve worked on (ideally a project where you’ve had significant input). We won’t expect you do do any whiteboarding or show off any code but will ask you to explain your project.
🔬 Take-home / pair coding exercise
The aim of this stage is to gauge your coding ability and how you get computers to do your bidding. We understand that not everyone can devote the time for a take-home exercise and not everyone is comfortable with live coding.
You can choose if you’d like to:
Do a take-home exercise where we ask you to implement a small program. The exercise is entirely asynchronous and can be done in the comfort of your own IDE and your choice of programming language. We’ll then review your submission together on a call.
Take part in a pair coding exercise where you'll spend some time actively pairing with one of our engineers for an hour to implement a provided interface.
Preparing for the take-home exercise and review
Choose a familiar programming language where you can write idiomatic code. We’re looking for good layout and functional structure within your code and understanding of your choice of language and data structures.
We don’t set a time limit for the take-home exercise. We’re looking for programs that function as described in the task sheet, there are no bonus points for additional functionality. Don’t be afraid to ask clarifying questions to your recruiter if parts of the exercise are unclear.
As part of your submission, we recommend submitting a README file describing your program structure, how to get it up and running, and any trade-offs you’ve made during development. Feel free to include any bits you’d like to improve given more time.
Everyone that makes a submission will get scheduled to go through their task with a Monzo engineer. This is called the task review call. You’ve spent time working hard on your submission so it’s only fair that we review it appropriately. We will spend time before the call to go through your code and even try to run it. We’ll use your README file to guide this session.
During the review call, we’ll walk through your code, discuss the choice of language, the design of your implementation, data structures used and performance considerations. You’ll be sharing your screen so you’ll be able to walk through your code in the comfort of your own editor and at your own pace.
Preparing for the pair coding exercise
As an alternative to the take-home exercise, you can choose to do a pair coding exercise.
The pair coding exercise is a synchronous coding exercise where you and a Monzo engineer will pair-program for 45 minutes to implement some functions to satisfy an interface. We offer this in a wide variety of programming languages like Go, Python, Java and C#. We’ll provide some pre-written automated unit tests which assert the correct behaviour alongside clear descriptions of what functions you need to implement. We're always looking to add more programming languages to give a wide array of choice whilst allowing us to effectively help you during the exercise.
Choose a familiar programming language where you can write idiomatic code. We’re looking for good functional understanding of your choice of language and data structures. You’ll be sharing your screen and be driving the implementation, so you can choose the IDE and environment you are most comfortable in.
The pair coding exercise isn’t a speed test so it’s fine if you don’t finish all of it. We’re interested in how you approach the problem and how you iteratively implement the program. Throughout the exercise we’ll talk about your programming choices and data structure trade-offs.
The exercise is also not a ‘Leetcode’ style test. We’re not going to ask you to invert a binary tree or write a sorting algorithm. We’ve specifically designed an exercise which is practical and similar to something you would work on at Monzo on on a day to day basis.
This is not a test of knowledge of your programming language. Feel free to use the documentation and/or resources like Google and StackOverflow during the exercise. The interviewers will also be familiar with the language you’ve chosen so feel free to ask them any questions along the way.
🎨 Systems design
The systems design interview gives us insight in building scalable, reliable and fault-tolerant systems. You work with a Monzo engineer to design a system to solve a large technical problem (the problem will be a hypothetical, non-Monzo related problem). We’ll be integrating systems such as databases, queues, and more. You’ll be making trade-offs and we’ll be probing to understand what these are. We’ll be working with a collaborative sketching tool like Excalidraw or Google Draw.
You’ll need to help us understand the choices you’ve made and why, and any points such as edge cases, or uncertainties that you think are valuable to raise. We’ll ask questions, challenge assumptions, and possibly ask you to take on additional information that may precipitate a change to your system.
The most important thing in this session is to maintain a shared understanding with your design. By the end of the interview, we should be able to go away and describe your proposed solution to others. There are no points for neatness of diagrams but getting a shared understanding the information flow and performance/consistency/availability trade-offs of your system is key.
Getting familiar with a whiteboarding tool beforehand is helpful. We recommend Google Draw which is free. If there is a tool you prefer, feel free to mention it to the interviewer and we will be able to accommodate.
If you need a refresher, we recommend reading and understanding the trade-offs of various database and queue systems in Designing Data Intensive Applications (especially Section II). We often see folks implement textbook solutions. Instead we’re more interested in how you reason about designing systems from first principles.
It’s tempting to drop mentions of buzzword technologies that promise infinite scalability or take care of all consistency and availability. We will probe deeper on why you believe such a component makes sense. We recommend sticking with technologies which you are familiar with and can reason about the advantages and limitations. If you mention AWS or GCP services, we’ll want to reason about the trade-offs and underlying implementation details that make them suitable for the task at hand.
The behavioural interview is the final stage. This is where we talk through your experience as part of a team, working with other engineers, breaking down complex work and delivering on projects. A core part of our day to day is working alongside our team and the broader company to deliver to large scale goals incrementally and at scale.
Similar to the initial call, we’ll go in depth about situations you may have encountered, your thought process to delivering software and your methodology to navigate the complex world of humans and stakeholders. This interview will be conducted by engineers but will focus more on project discussion than deep diving into the technical detail.
Take some time to reflect on your past projects (if you have led a particular complex project or been a significant contributor to a project, these are good things to reflect on). Be sure to talk about the stakeholders involved and how everyone was kept aligned.
We also want to see how you work with others. If you were influential in rallying a particular effort or levelling up other engineers, there will be opportunity to touch on these points. It’s important to distinguish the things you led personally as opposed to efforts of others that you were involved in.
Once you’ve concluded all your interviews, we’ll get together to review your interviewer feedback and make a decision. We look at all elements of the interview process and discuss your strengths and development areas.
We have a Hiring Committee who go through all interviews and make the decision to make an offer. They also help spot, remove and educate on things like bias, tone of voice and alignment on values and behaviours, ensuring Monzo continuously improves the interview experience.
By doing this, we not only ensure that we can make a fair decision, but that we are able to get a really consistent view of which team within Monzo will best suit your skills and needs. We want to make sure that you’re in a space where you’ll get to work on the things you enjoy doing and are passionate about, but where you’ll also get the support and guidance you need to help you grow and develop at Monzo.
If we feel like there’s a good fit, we’ll make an offer 🎉. We hope that you join us!
💡 Interviewing Top Tips
Throughout all of the interview stages, there’s some common tips to keep in mind
We’re interviewing you, not your current or past team. We’re really interested in your personal contributions to the projects and work you talk about. Focus on framing your contribution and involvement.
It’s absolutely fine to not be super familiar with a concept and to say ‘I don’t know’. We’re more interested in how you reason about it with first principles thinking. There may also be concepts that we are not familiar with, we’ll ask you to explain these to us.
Ask us questions about what we’re working on and working at Monzo! Interviewing is a two-way street. As a candidate, you are also interviewing the company to see if it’s a good fit for your priorities.
Your Recruiter is your ally through the hiring process and is more than happy to directly answer or forward questions about the interviewing process, the role, and life at Monzo.
Technology can sometimes get in the way (such as a bad connection). Try as much as possible to get to a quiet place with reliable internet. It’s very important for us to be able to hear you so test your microphone setup beforehand. If you have trouble hearing or understanding us, please let us know! We will do whatever we can to accommodate you.