Engineering and Data Internships at Monzo

Warren

I’m Warren, a third-year Computer Science  (CS) student at Cambridge. I’ve been interested in programming for a long time because I enjoy being able to create something, use it myself and show it to other people. I later became interested in cybersecurity through capture-the-flag competitions, so I was keen to put both interests into practice in a real engineering environment.

Like a lot of students, I applied quite broadly rather than having one perfectly planned destination. Monzo was one of the companies that stood out to me during the process: it was a recognisable product and because it’s a consumer bank, the work felt connected to something people use in their everyday lives.

Sophie

I’m Sophie, and I'm going into my third year of physics at Oxford. I've always liked maths, but I never really knew what to do with it. Then I found machine learning (ML) - and that was sort of that. It's maths you can actually build things with. 

Up until this summer, all my ML had been my own projects, on datasets somebody else had already tidied up, where the result only mattered to me. I wanted to find out what it looks like in a real company - when data is properly messy and a team is dependent on my model output. An internship was the only real way to do that. I applied to quite a few places, but the more I learnt about Monzo the more it became the one I actually wanted out of all of them, and being a Monzo customer myself was obviously an added perk! 

Warren

This was my first proper software engineering job, so I didn’t really know what to expect. I assumed that interns may be treated quite differently to permanent engineers, with lots of guardrails, very structured tasks and relatively small pieces of work. 

In reality, I was treated as a full member of the squad. I was given a broad problem and a lot of freedom to investigate it, propose a solution and develop it all the way to production. That came with more responsibility than I expected but I still had a lot of support. I could ask my team for input, get feedback on decisions and change direction when I learned something new.

Sophie 

I thought it would feel more corporate than it does. I was expecting set hours and a lot of process, and instead it's really flexible, hybrid working is encouraged and nobody minds when you start or finish, which is genuinely quite freeing. Everyone is also lovely, which sounds like exactly the  thing you'd say in a blog like this, but it kept surprising me all summer. If you're stuck, someone will help you, and they'll act like you did them a favour by asking.

I also wasn't ready for how nice the office is: free breakfast every day, lunch a couple of times a week, endless coffee and fruit, proper monitors and chairs. It sounds like a small thing, but it makes coming in something you actually want to do.

I did spend a lot of the summer heads down on my own project, but it never felt isolating. There was always someone happy to talk it through with me when I wanted a second opinion.

Warren

I worked in the Staff Security & Detection squad, which protects staff devices (e.g. from malware) and builds detection tools for teams like Security Operations and Internal Fraud.

My main project was improving how Monzo uses external threat intelligence. Monzo receives information about potential cyber threats, like IP addresses that have been associated with malicious activity, but one of our sources produced thousands of these pieces of information per day. Reviewing and investigating all of them manually wasn’t practical so the data was going unused.

My project automated that process, turning the threat information into something that Monzo can act on. Instead of someone having to repeatedly check thousands of indicators by hand, the system can look for signs of those threats in Monzo’s security data and alert the security team if it finds something relevant. I also designed the services to be useful beyond the initial use case, for anything relating to threat indicators. For example, to support more sources of threat information or help with areas like phishing detection, firewalls, and active investigations.

Sophie

I worked on the system that deals with payments we've blocked because they look like a scam. When that happens we ask the customer some questions about the payment, and an automated system uses their answers to decide what to do next. Customers can reply with a voice note instead of typing, and my project focused on whether that voice content should feed into the decision.

It was a mix of data work and machine learning engineering. The first part was rebuilding the dataset out of loads of source tables that were never really designed to be joined together, and being quite careful about which fields I was even allowed to use, because a lot of the ones that look most predictive only get filled in after the case has been resolved, so they'd leak the answer straight into the model.

Then the more interesting bit. Turning a rambling two minute voice note into something a gradient boosted tree can actually do anything with. I read dozens of transcripts myself and built up a taxonomy of the signals that kept coming up, then used an LLM to label transcripts against that schema at scale, so instead of a wall of text you get a structured set of features per customer. I built simpler ones alongside it too, like how someone chose to respond and how much they actually said. After that it was wiring it all into the existing pipeline, retraining the model with and without the new features and seeing what happened on held-out data. That last part, getting something into a real production codebase rather than a notebook, was completely new to me and probably what I got the most out of!

Warren

I had much more ownership than I expected from an internship. I was given the overall goal of a pipeline from threat intelligence into Monzo’s security logs, but it was up to me to decide what a useful and achievable version of that would look like.

I defined the scope of the project and owned the system design, figuring out how to make it extensible for other uses related to threat indicators. For any decisions where I wasn’t sure, I was able to discuss them with my team, but I was responsible for laying out the options and explaining the trade-offs.

Sophie

I came in with a rough guide for the project and that was about it. After that, it was on me to go to my project manager with an actual step-by-step plan for how I was going to tackle each part, down to which features were worth building and how I'd test whether they actually made a difference. 

At the start, I leaned on him a lot and honestly just wanted to be told what to do next. By the end, I was making decisions and starting things without checking first, which is a bigger shift than it sounds for twelve weeks. You get as much flexibility as you're willing to take here, which I loved. Nobody was going to hand me more ownership than I asked for, but the second I asked, it was mine.

Warren

The people at Monzo are very approachable, and I learned a lot from seeing how they work and reason about problems. Rather than just giving me the answer, they’d ask questions, point out trade-offs I hadn’t considered, and help me reach a better decision myself. 

Although I was the only one working on my project, and it was functionally quite separate from the rest of the team’s work, it involved much more collaboration than I expected. I needed context on threat intelligence from Security Operations, as well as feedback from my squad on system architecture. I also reviewed work from teammates and even found and fixed a bug in another team’s code, which made me feel truly part of the wider engineering organisation

Sophie

Monzo has a really strong 1:1 culture. You can message pretty much anyone and go for a coffee or hop on a Google Meet just to chat about their job, how they got into it, careers, your project, or life in general. I had so many of these conversations, and they were easily my favourite part of the whole summer.

It was amazing how many clever people I met from completely different backgrounds. Most of them had nothing to do with my project, but I’d still come away with a better idea of what I want to do next. And when I was properly stuck, having someone happily bounce ideas around with me for half an hour made such a difference. 

Warren

One of the biggest things I learnt was how much communication goes into engineering. Because I was the only one on my project, I imagined most of my time would be spent independently writing code. In practice, making the project genuinely useful meant speaking to different squads, tapping into specialist knowledge, documenting design decisions, and making sure I was solving the right problem. 

I also learnt the value of planning before jumping into implementation. At the start, I was eager to get stuck into writing code, but I quickly felt overwhelmed because several key decisions were still up in the air. Writing a proposal, breaking the work down into tickets, and proactively asking for feedback made the rest of the project far smoother. I knew the theory before, but building for a live production system really brought that lesson home. 

Sophie

Just how much of ML is really about understanding your data. You get a result out of a model, it looks a bit off, and the real skill is tracing it back to the source and finding out it was a data issue all along. That happened to me more than once, and it’s not something you can easily be taught - you just have to get caught out by it a few times.

I also learnt about the things that quietly ruin a model, especially data leakage, which I’d read about but never encountered in the wild. So many of the columns that look most predictive are ones that only get filled in after a case is closed, so you're constantly asking yourself what was actually knowable the exact moment the model ran. And feature importance isn't the same as a feature being genuinely useful; a model can lean heavily on an input you've given it and still make no better decisions, which I don't think I'd have believed until I watched it happen.

The other big takeaway was getting changes into a real codebase and production pipeline, complete with tests, reviews, and code that dozens of engineers have touched before you. I could never have learnt that on my own in a comfy Jupyter notebook with a squeaky-clean dataset somebody else had already prepped for me

Sophie

Honestly, it’s far less like the ML you study at uni than I expected - and all the more interesting for it! The models aren’t weird or overcomplicated; they’re gradient-boosted trees doing a well-defined job, and almost nobody spends their time on architecture or tweaking hyperparameters. It all goes on the features: where the data behind them comes from, and whether the evaluation framework you’ve built actually means anything.

So most of my summer was feature engineering: working out what’s worth feeding the model, building it, checking how much the model leans on it, and being honest about whether that turned into better decisions on unseen data. You also end up caring about different metrics than you’d expect - precision and recall at the exact threshold where the system acts, rather than just an accuracy figure, because that’s the part a real customer feels.

A lot of it is infrastructure too, which I enjoyed far more than I thought I would. Getting features through a pipeline properly with tests, ensuring what you measure offline is what actually runs in production

Sophie

The bits I found most interesting were the ones where I had to work out why a result was what it was. To test whether the transcripts were worth anything I set up runs where the model was trained with and without each group of features, so I could isolate the transcript itself rather than everything that came with it, and compared them on held-out data with bootstrapped confidence intervals so I wasn't reading noise as a real difference.

The transcripts came out flat, and my first instinct was that I'd broken something, so I went looking for the bug. Wiring, whether the feature was making it through, whether the text was even reaching the model. It clearly was, because the model's attribution to that part of the input jumped severalfold as soon as the transcript went in. It was reading it, it just wasn't getting anything extra out of it. I also froze one trained model and rescored it across the different groups instead of retraining every time, so noise from retraining couldn't pass itself off as a real difference.

In the end, it wasn't a bug at all, our test split just didn't have many of the cases we cared about, so there wasn't enough there to see an effect either way. Working that out meant taking my own pipeline apart piece by piece, which I genuinely enjoyed a lot more than I expected to.

Warren

This was my first software engineering job, so my previous experience was mainly university and personal projects. In those projects, the goal is usually to make something work and demonstrate it once. At Monzo, you also have to think about how it could fail, how we’ll know if it’s failing, the value and impact it brings, and what effect it can have on other teams and systems.

I was also surprised by how good the developer experience was. Monzo’s platform takes care of a lot of the common infrastructure involved in working with microservices, so we can spend more time thinking about actual business logic while maintaining a strong process around design, code review, testing, and safely deploying changes. 

Sophie

Definitely apply! Even if the data science description doesn't totally call out to you, Monzo is really flexible about letting you work on something you're actually interested in, which is how I ended up on an ML team in FinCrime, which was so cool.

Also, just be yourself in the interview. I ended up talking about project work and interests that had nothing to do with the question we were meant to be answering, and I think that showed my personality way better than any data science answer could have. They really do value that here

And don't be put off if your degree is a bit unorthodox. I'm one of very few interns who doesn't do CS, and it hasn't put me at a disadvantage at all. If you can do the assessments and the interview, they don't care what you studied; it's all about learning on the job, being curious, and being willing to work hard

Warren

100% apply, and don’t self-select out. Most people underestimate themselves, and you don’t need to already know Go or anything else used by Monzo, because the onboarding process is quite comprehensive.

I also really liked the application process: it was focused, it didn’t feel drawn out, and the questions gave me a good opportunity to show how I think and approach problems.

If what you’ve read here resonates and you’re passionate about making money work for everyone, we’re hiring machine learning engineers, data analysts, backend engineers, and many more roles across Monzo! Take a look at our careers page to see if we have the right role for you.