Fluidstack is a GPU “neocloud” that grew out of a distributed GPU network and now acquires power, designs and builds data centers, and operates the compute inside them for frontier AI labs. After an $830M Series A in mid-2026 and a valuation around $7.5B, they’re staffing multibillion-dollar buildouts across the US, Europe, and Asia. That context shapes the interview: they are not hiring people to babysit one Kubernetes cluster. They are hiring engineers who can keep thousands of H200s healthy, automate repair at fleet scale, and reason about hardware that fails in weird, silicon-level ways.
If you’ve read our Modal interview guide or the Together AI guide, the shape will feel familiar, but Fluidstack sits lower in the stack. Modal sells serverless GPU compute; Together sells inference. Fluidstack sells and operates the metal. The questions follow the metal.
One caveat before the specifics: Fluidstack is young and hiring fast, so the public interview sample is thin. The loop skeleton below comes from the handful of reported candidate experiences (Glassdoor, Blind, aggregator guides); the emphasis on fleet health, qualification, and hardware failure is extrapolated from their live job descriptions and from how neocloud peers like Modal, Together, CoreWeave, and Crusoe run their loops. Treat it as a well-grounded prior, not gospel, and weight whatever your recruiter tells you more heavily.
The loop, round by round
Reported experiences converge on a medium-difficulty process that runs about three weeks end to end. Product, data, and TPM loops differ in the middle, but the skeleton is consistent.
It opens with a recruiter screen, usually 30 minutes on your background, what you’ve actually owned, and logistics like location and level. Then a technical phone screen or first onsite round: a coding problem, typically LeetCode-medium, solved out loud under time pressure. Nothing exotic, but they watch how you handle edge cases and whether your code stays readable when you’re rushed.
The middle of the loop is where Fluidstack diverges from a generic startup. Expect a systems and architecture round anchored in what the team actually does, and for infrastructure roles a second technical round that goes deeper on operations and failure modes. The last stage is usually a behavioral round plus a conversation with a founder or a senior engineering lead, especially for early or senior hires.
The technical round is about fleet reality, not puzzles
The coding portion is real but not the point. A medium array/string or graph problem, sometimes a slightly harder variant where they care more about how you reason about a defect than whether you finish. If you can talk through invariants, complexity, and the edge case you almost missed, you’re doing well. The core coding patterns cover the bulk of what shows up; you don’t need to grind hards for this loop.
The systems conversation is where they separate people who’ve operated infrastructure from people who’ve only read about it. Recurring themes from reported loops and the job descriptions themselves:
- Kubernetes control-plane architecture, and where it stops being the right tool for bare-metal GPU fleets
- SLURM job scheduling and how batch scheduling for training differs from serving traffic
- Designing a fleet-health pipeline: metrics collection across thousands of nodes, detection, triage, and automated return-to-service
- GPU qualification and burn-in: how you’d validate a new node is healthy before it takes customer workloads
- Firmware-level telemetry via Redfish/BMC/IPMI, and what you do when a GPU is degraded but not dead
A representative prompt: “You have 5,000 GPUs across several sites. A subset starts throwing ECC errors intermittently. Design the system that detects this, decides whether to drain the node, and gets it back into service without a human in the loop.” A strong answer starts with the detection threshold and treats it as a cost tradeoff, not a constant: a single correctable ECC error is noise, but a rising rate on one device predicts failure, so you alert on trend and burst rate rather than any single event, because a jumpy threshold drains healthy nodes and quietly torches capacity. Draining is the interesting part. You can’t yank a node mid-run, so you cordon it from new work, signal the scheduler, and let a checkpointed training job reschedule off the bad rank at its next checkpoint boundary instead of killing thousands of GPU-hours. Then the node flows into an automated pipeline: re-run qualification, and if it fails, kick off the RMA workflow and only return it to the schedulable pool once it passes burn-in again. Throughout, you keep naming blast radius, because on a synchronous training run one degraded rank stalls the entire job, so the expensive mistake is being too slow to pull a bad node, and the other expensive mistake is being too eager and pulling good ones. Sitting in that tension out loud is what they’re listening for. This is closer to the system design guides hub material than to a whiteboard algorithm, but tuned for hardware you can physically break.
One concrete tell from their current postings: several roles explicitly list workflow engines like Temporal and Cadence, plus Prometheus and Grafana, and ask for fluency with AI tooling (Claude Code, Cursor, MCP servers, agentic frameworks). If you’ve built durable, retryable workflows or automated ops with an LLM in the loop, say so specifically.
Know the scope boundary before you walk in. The GPU-infrastructure and cloud-infrastructure roles end at the hardware and SRE layer: fleet health, qualification, scheduling, firmware telemetry. They do not touch the training or serving stack, so there’s no model code, no CUDA-kernel work, no inference optimization in these loops. If that’s the work you want, it’s a different interview (the CUDA-and-inference side looks more like the Together AI loop), so ask the recruiter which team you’re actually loading for.
Behavioral and founder rounds
The behavioral round looks for evidence of ownership and influence, not rehearsed narratives. Given the pace of construction, they care about times you drove something to completion when the requirements were fuzzy and the on-call pager was yours. Have two or three stories with real detail: what broke, what you decided, what the tradeoff cost, and what you’d do differently. Our STAR-method breakdown is a good structure to rehearse against, as long as you keep the specifics.
The founder or senior-lead round tends to probe mission fit and how you think about the AI-infrastructure bet. You don’t have to be a true believer, but you should have a real opinion on why power, land, and fleet reliability are the actual bottlenecks, not GPUs alone.
Compensation, location, and sponsorship
Fluidstack posts salary bands on individual job listings, which is the most reliable source. Across recent 2026 software engineering postings, base ranges have clustered between roughly $180K and $300K plus equity. Reading that spread by level: the lower end, about $180K–$210K, tracks senior individual contributors, and the upper end, about $260K–$300K, is staff and lead territory. One specific GPU-infrastructure listing showed $208K–$269K, which sits mid-band for a senior-to-staff role. Treat these as observed data points, not a guarantee for your level or location.
Because this is a fast-scaling private company, equity is a large and hard-to-value part of the package. Ask directly about the strike price, the current preferred-share price, the total shares outstanding, and the vesting schedule, then model a few outcomes yourself. Our total comp calculator helps you compare a base-plus-equity offer against a more liquid one, and levels.fyi is the best public cross-check for whether a band is competitive for the level.
On location: Fluidstack is headquartered in London and hires engineers there, alongside US offices in San Francisco, New York, Austin, and Seattle. So the ex-US presence isn’t only physical data-center sites; London is a real engineering hub, and most roles are onsite-leaning. Visa sponsorship isn’t stated consistently on the postings, and it varies by office and role, so don’t assume either way. Confirm it on the specific listing and raise it in the recruiter screen before you invest three weeks.
| Stage | Format and length | What Fluidstack screens for |
|---|---|---|
| Recruiter screen | ~30 min call | Background, ownership history, level, location and sponsorship fit |
| Technical (coding) | 45–60 min | LeetCode-medium out loud; edge cases, code clarity under time pressure |
| Technical (systems/ops) | 45–60 min | Fleet health, GPU qualification, Kubernetes + SLURM scheduling, hardware failure modes |
| Behavioral | ~45 min | Concrete ownership, influence, conflict resolution, driving fuzzy work to done |
| Founder / senior lead | 30–45 min | Mission fit, judgment on the compute/power bet, thoughtful questions |
Fluidstack sits on the AI-cloud beat alongside neocloud peers, and the whole segment is worth understanding before you interview; the AI-native company guides hub and the AI-startup difficulty index put the bar here in context against Modal, Together, CoreWeave, and Crusoe.
How to prep in the two weeks before
Spend most of your time on the systems round, because that’s the differentiator and it’s the hardest to fake. If you’ve never operated hardware at scale, read up on how ECC errors, thermal throttling, NVLink failures, and PCIe errors actually present, and practice describing a detection-to-remediation loop end to end. Warm up coding with a couple of medium problems so you’re fluent, not fresh. For behavioral, write down your ownership stories before you’re in the room so you’re not improvising specifics.
The thing that gets people through here isn’t a clever algorithm. It’s sounding like someone who has been paged at 3am because a rack went dark mid-training-run, and who has opinions about how to make sure it doesn’t happen again.
Practice the behavioral round:
