Northflank is a London-based developer platform that lets teams build, deploy, and scale workloads (apps, databases, GPUs, AI inference, and agents) on their own cloud, with Kubernetes automated away underneath. It’s an independent company, founded in 2019, running lean on a Series A led by Bain Capital Ventures (about $22M raised, per VentureBeat and BusinessWire). That last fact matters more than it looks: public company profiles put the team at roughly 20 people, and a group that small building infrastructure for thousands of other developers can’t afford a mis-hire, so the bar for systems judgment is high and the process is short on theater.
If you’re used to the big-company loop with five near-identical coding rounds, recalibrate. A company this size interviews to answer one question: can you own a hard, ambiguous piece of a production platform without a lot of hand-holding? Everything below is oriented around that.
What Northflank builds, and why it shapes every round
The product is a self-serve layer over Kubernetes that runs on your cloud account. Users push code, click through a few options, and get inference endpoints, notebooks, training jobs, databases, and CI/CD without touching a YAML file. Under the hood that means a multi-tenant control plane orchestrating other people’s containers, often GPU-bound and sometimes running untrusted code, across three major clouds.
So when an interviewer asks a design question, it isn’t abstract. The real problems they live with are the ones they’ll probe: safe execution of arbitrary user workloads, fair scheduling of scarce GPUs, tenant isolation, keeping a control plane up while a customer’s cluster misbehaves, and making Kubernetes’s rough edges invisible. If you’ve operated Kubernetes in anger, that experience is worth more here than a stack of solved dynamic-programming problems.
The likely round structure
Northflank doesn’t publish its interview stages, and I’m not going to invent a fixed count. What follows is the shape small platform teams typically run, inferred from the roles listed on their careers page and how companies at this size usually hire. Treat it as a map, not a schedule, and confirm the exact sequence with your recruiter on the first call.
Settle one eligibility filter before anything else: the engineering roles I saw are remote within UTC ± 2. In practice that covers the UK, most of Europe and Africa, and the western Middle East, and it rules out the Americas and nearly all of Asia-Pacific. Whether Northflank sponsors UK visas, relocates, or is strictly remote inside that band isn’t stated on the postings, so ask the recruiter rather than assuming.
The loop generally starts with a recruiter or founder screen: why Northflank, what you’ve actually operated, and a sanity check on level. From there you’re looking at one or two technical conversations with engineers, plus a design/systems round that maps directly onto their product. A small team usually folds in a founder conversation somewhere, because at this size culture and ownership aren’t a separate “values interview,” they’re baked into every call.
| Stage | Who runs it | What they’re actually screening for |
|---|---|---|
| Recruiter / founder screen | Recruiter or a founder | Motivation, real hands-on operating experience, level and time-zone fit |
| Technical conversation(s) | Backend or infra engineers | Depth in Go, Python, or Node.js; databases (SQL and NoSQL); how you debug and reason about production failures |
| Systems / design round | Senior engineer or founder | Distributed-systems judgment tied to their product: multi-tenant control plane, scheduling, isolation, availability |
| Take-home or pairing (role-dependent) | Engineering team | Real code quality and pragmatism on a scoped, product-adjacent problem |
| Founder / team fit | Founders and future teammates | Ownership, communication, whether you thrive with ambiguity and little process |
Confirm the specifics before you invest a weekend in prep. The middle rounds vary by role: a Cloud Infrastructure Engineer loop will weight ops and cloud far more than a Backend Software Engineer loop weights pure API design.
The systems questions that actually come up
The design round is where this interview is won or lost. The stack in their backend posting is Go, Python, or Node.js, with Docker, Kubernetes, the three big clouds, and message queues as the working vocabulary. Expect prompts phrased around what they do, not a generic “design Twitter.” Things in the spirit of:
- “A user submits a training job that needs 4 GPUs, but the cluster’s full. Walk me through scheduling and queuing that fairly across tenants.”
- “How would you isolate untrusted user code so one tenant can’t read another’s secrets or starve the node?”
- “Our control plane needs to stay responsive when a customer’s own cluster is degraded. How do you keep those failure domains separate?”
- “Design the pipeline that turns a git push into a running, health-checked deployment across AWS, GCP, and Azure.”
- “We serve model inference on GPU nodes with a p99 latency target. How do you hit it when a request lands on a cold node that still has to load the model into VRAM?”
Good answers here sound like someone who has been paged at 3am, not someone reciting a design template. Talk about blast radius, backpressure, idempotent retries, and what you’d actually monitor. When state comes up, be specific: know when you’d reach for a queue versus a database, and have a real opinion on SQL versus NoSQL for a given access pattern. If you claim a design scales, be ready to defend the bottleneck, whether that’s database indexing under a hot key or a rate limiter protecting the control-plane API. If systems design is rusty, the system design interview guides are the fastest way to reload the fundamentals.
Because the product leads with GPUs, inference, and agents, expect at least one prompt with real ML-serving texture instead of generic web-scale design. Be ready to break down the latency budget for an inference endpoint and where it goes: model load into VRAM, batching, and the request queue in front of it. Cold starts are the sharp edge, since spinning up a GPU node and pulling a multi-gigabyte model can dwarf the actual inference time, so have opinions on warm pools, pinning models to nodes, and the tradeoffs of scale-to-zero. Know how you’d autoscale on GPU utilization or queue depth rather than plain CPU or request count. I couldn’t confirm a separate ML or inference-specific role and loop distinct from the Backend and Cloud Infrastructure Engineer tracks, so assume this depth gets tested inside those interviews unless your recruiter says otherwise.
The company sits in the same self-serve, run-anywhere infra wave as a cluster of GPU and orchestration startups. If you want a feel for how these loops go, Modal’s interview guide covers serverless GPU, and Temporal’s guide covers workflow orchestration; both share Northflank’s bias toward operational depth over algorithm puzzles. The broader AI-native company interview guides hub is worth a skim for the pattern.
Coding: pragmatic, not competitive-programming
At a team this size, the coding bar is about whether your code would survive a real code review, not whether you can spot the trick to a hard graph problem in 20 minutes. Since Go is central to the stack, being comfortable with goroutines, channels, context cancellation, and error handling pays off; the Go interview questions guide maps that surface well. If there’s a take-home or a pairing session, treat it like production work: handle the error cases, write the test you’d actually want, and leave a note on the tradeoff you made and what you’d do with more time. Pragmatism reads as senior. Over-engineering a scoped problem reads as the opposite.
That said, don’t skip fundamentals entirely. A warm-up coding question is still common, and freezing on a straightforward one is an avoidable way to lose a round you’d otherwise pass on judgment.
Behavioral, at a 20-person company
There’s no Amazon-style bar-raiser here, but the fit conversation is real and it’s usually with a founder. The questions are concrete: a system you owned end to end, an incident you were on point for, a time you shipped under ambiguity with nobody telling you the right answer. Ownership is the trait they’re buying, because at this size you’ll be the person who owns a chunk of the platform, not a cog on a large team. Have two or three stories where you drove something, and structure them so the result is clear; the STAR method is enough scaffolding for that without sounding rehearsed.
Compensation, and the numbers you can actually source
Northflank publishes bands on its own job posts, which is more transparency than most startups give you. The Backend Software Engineer listing shows £75K–£104K base plus 0.05%–0.1% equity, for remote work within UTC ± 2. That’s a real, current figure from the company, but it’s exactly one role at one level. Don’t over-anchor on it: a Cloud Infrastructure Engineer or a more ML-leaning role will carry its own band, and the number moves with seniority and location. Equity value at a Series A company is a bet, not cash.
Before you talk numbers, get the equity picture straight: percentage is only half of it. Ask for the current preferred valuation, the strike price, the vesting schedule, and how many shares are outstanding, so you can turn “0.1%” into something you can reason about. A total comp calculator helps you compare a London base-plus-equity offer against, say, a US remote package on a common basis. And when the offer lands, your position is stronger than it feels; the salary negotiation playbook applies even at a small company, because a lean team that’s decided it wants you does not want to restart a search.
How to prep in the time you have
Spend most of it on the systems round, because that’s where the signal is and where generic prep fails you. Pull up Northflank’s own docs and changelog, deploy something on the free tier, and form opinions about how you’d have built the piece you touched. Then run one or two mock design sessions on multi-tenant orchestration and safe code execution until you can talk about failure domains without reaching for a script.
The candidates who do well here aren’t the ones who ground the most LeetCode. They’re the ones who’ve run real infrastructure, have scars to show for it, and can explain a tradeoff without hiding behind buzzwords. If that’s you, this is a company where the interview finally rewards the thing you’re actually good at.
Practice the behavioral round:
