On March 9, 2026, a company that did not exist two years earlier closed a $2 billion Series C at a $14.6 billion valuation. Nscale, founded in London in May 2024, calls it the largest Series C in European history. The round tells you what you are interviewing into: a GPU cloud spending that capital on data centers across Norway, the UK, Portugal, Iceland, Texas, West Virginia, and North Carolina. You would be joining a build-out, not a finished product.
Nscale describes itself as a full-stack hyperscaler engineered for AI. It designs and runs the data centers, racks the NVIDIA accelerators, wires the fabric, and sells the capacity as public cloud, private cloud, and managed clusters, with software like Control Center for cluster scaling and managed Kubernetes on top (SiliconANGLE, March 9 2026). The industry shorthand is “neocloud,” the same category as CoreWeave and Fluidstack, and adjacent on the software side to companies like Modal and Together AI. The round was led by Aker ASA and 8090 Industries, with NVIDIA, Dell, Nokia, Lenovo, and the trading firms Citadel, Jane Street, and Point72 also in (press release).
What Aker, NVIDIA, and Jane Street on the cap table tell you
The cap table maps what the company has to be good at: an energy company (Aker), a chip vendor (NVIDIA), a hardware maker (Dell), and latency-driven trading firms back a business whose engineers schedule and network dense GPU fleets at high occupancy. That is not abstract: Nscale has committed to a Stargate Norway venture with Aker aimed at roughly 100,000 GPUs and 230 megawatts, and to hosting on the order of 200,000 NVIDIA GB300 accelerators for Microsoft across Texas, the UK, and Portugal (SiliconANGLE).
Nscale is young, and grew fast enough to acquire the British engineering firm Future-tech and its roughly 60 data-center specialists in December (SiliconANGLE), so public interview write-ups are thin. What follows is built from the company’s open Greenhouse postings and how an infrastructure loop at this stage typically runs, not from candidate reports.
Who this loop is realistic for
The engineering openings cluster into a few tracks: platform and infrastructure (Kubernetes, orchestration, internal APIs), site reliability and GPU-fleet operations, plus network and data-center engineering. The postings skew senior, with titles like Senior Cloud Native Platform Engineer and Staff Infrastructure Software Engineer. The common thread is having run something real in production. If your background is pure application development, the infra tracks will be a stretch; this team wants people who have cordoned a bad node, not people who have only worked above one. Early-career candidates should ask which teams take junior hires before preparing.
On logistics: postings span the UK (London is HQ), Norway, Iceland, Portugal, and US cities including Houston and Seattle, and whether a role is on-site or hybrid depends on the team. No public posting states a visa policy; the UK Skilled Worker route carries a minimum-salary threshold, so if you need sponsorship, confirm with the recruiter that you would clear the bar for your level and location. Ask too which location the role is anchored to, whether it is on-site or hybrid, and, for an SRE or GPU-fleet-ops role, what the on-call rotation and pager load look like; expect real overnight incidents at this scale.
The loop, round by round
| Nscale round | Format | What it screens for | Example prompt |
|---|---|---|---|
| Recruiter screen | 30 min, phone | Motivation, level fit, location and logistics | “Why AI infrastructure, and why a company still building its footprint?” |
| Technical phone screen | 60 min, live coding or systems | Coding fluency, reliability instincts, clear reasoning | “Parse a stream of node telemetry and expose a rolling health summary.” |
| System design | 60 min | Multi-tenant GPU scheduling, isolation, failure handling | “Design the control plane that places training jobs on a shared GPU fleet.” |
| Platform / GPU-infra round | 60 min | Depth on Kubernetes, fabric, node lifecycle, or SRE | “A node starts throwing GPU Xid errors mid-job. Walk me through detection to drain.” |
| Behavioral / values | 45 min, often with a lead or founder | Working under ambiguity, ownership, why this company | “Tell me about an outage you owned end to end.” |
The durations and prompts above are reconstructed from public postings, not leaked from candidates; treat them as a representative shape whose exact sequence varies by team and level. A loop like this usually resolves in two to three weeks.
The system design round is a multi-tenant GPU problem
Everything the company bets on shows up here, and the prompt will not be a generic URL shortener. Expect something from the product: design the control plane that schedules many customers’ training and inference jobs onto shared GPUs, keeps tenants isolated, packs the hardware so few sit idle, and recovers when a node or rack fails. The tension is that a single training job may span hundreds of GPUs with tight all-reduce communication, so you cannot treat each accelerator as an independent unit the way a stateless web tier treats a CPU.
A strong answer separates the scheduling decision from the execution path, and knows the real tradeoff between a batch scheduler like Slurm and a Kubernetes-based approach: gang scheduling and topology awareness against the operational ecosystem and API surface. Talk about how you place a job so its GPUs share a fast interconnect, what happens to a 256-GPU run when one node dies, and how checkpointing bounds the blast radius. Expect follow-ups on storage, because feeding those GPUs means moving datasets and checkpoints at bandwidth a naive object-store design will choke on. An evening with the standard system design patterns pays off here, and the observability side is a high-ingest, columnar time-series problem. If you have built job-orchestration or workflow systems, this ground is familiar, with physical hardware as the hard constraint.
The infrastructure round, and why app engineers stumble
The platform round is where generalists underprepare: the questions go below the abstraction most application engineers live above. You might trace what happens when a GPU throws an Xid error mid-training: how you detect it, cordon and drain the node without killing healthy neighbors, signal the customer’s job, and return the hardware to the pool. Or the network: why InfiniBand versus RoCE matters for collective communication, what a fat-tree topology buys you, and where oversubscription bites.
You do not need to have run a data center. You do need to show you know a GPU cloud is a physical system with failure modes a pure software model hides. Candidates who can reason about node lifecycle, driver and firmware drift across a fleet, power headroom, and the difference between a soft and a hard failure read as people who have operated real infrastructure; those who treat every server as an interchangeable, always-healthy box do not. If your track is network or data-center engineering, the emphasis flips: your hardware fluency is assumed, and the round probes whether you can automate it and write correct, idempotent control code against flaky physical state.
Coding, and the behavioral round
The coding mostly lives in the technical phone screen, and it leans practical over puzzle. Think one solid data-structures problem weighted toward systems work: parse and aggregate a telemetry stream, handle time windows, get the edge cases right on late or duplicate events. Correctness and clear tests matter more than a clever trick. Platform tooling at neoclouds tends to be Go-heavy, so if the role touches the control plane, refreshing goroutines, channels, and context handling is time well spent. The other tracks differ: SRE candidates should expect a debugging or incident-response scenario rather than an algorithm puzzle, while network and data-center candidates get a fabric-design or capacity-planning discussion with lighter coding. Keep your complexity analysis sharp; the bar is solid engineering, not competitive-programming trivia.
The behavioral round is a real filter, not a formality. Nscale ships capacity on deadlines that hyperscalers and governments are watching, so interviewers want people who stay useful when the spec is half-written and the date is fixed. Bring one incident or project you can walk through in detail, including where it went sideways and what you changed afterward. Broad ownership claims come apart quickly when the interviewer was on call last week. To calibrate the bar, the AI-startup difficulty index and the broader set of AI-native company guides help.
Comp is in pounds, and there is no posted band
Nscale posts no pay band on its roles, and UK aggregators hold almost nothing trustworthy on a company founded in 2024, so treat any number online as a guess. The London roles pay in GBP, and copying a US GPU-cloud salary onto them is a mistake: the market rate and the tax treatment of equity are both different. Rather than anchor on an invented number, ask the recruiter for the base range for your level and location, the size of the grant, the instrument, and the vesting schedule. The instrument matters. A company this size is well past the limits for HMRC’s tax-advantaged EMI share-option scheme, which caps at 250 employees and £30 million of gross assets (HMRC), so expect unapproved options or RSUs, taxed differently and worth confirming before you compare offers.
Then value the equity against the $14.6 billion March 2026 valuation, remembering that the round’s preferred-share price is already months old and that private-company equity is worth what the next round and an exit decide. Cross-check base pay on UK sources like Glassdoor UK and levels.fyi where entries exist, and treat single data points with suspicion. A total-comp calculator puts competing offers on the same terms, and if you reach an offer, standard negotiation tactics apply; the room to negotiate is usually in the grant, not the base.
Where to spend the prep hours
Read the Series C announcement first and note the shape of the business: it makes money by keeping expensive hardware busy, which is why every technical round circles back to scheduling and failure recovery. Put your systems prep into multi-tenant GPU scheduling, Kubernetes internals, and the network fabric that ties a training cluster together, and spend an hour on how a large training run fails and recovers. A working grasp of Xid errors and gang scheduling is more than most software candidates bring.
Engineers who do well here like where two worlds collide: the software side, where you fight for consistency and correct control loops, and the physical side, where a GPU degrades, a link flaps, and a data hall has a power ceiling. If that sounds like the interesting part of the job rather than the annoying part, it is worth preparing seriously for.
Practice the behavioral round:
