A sourced, dated breakdown of the Google DeepMind Software Engineer process for all levels (US/UK/global): every round, every reported question, and real candidate experiences.
Google DeepMind runs its own hiring loop, separate from standard Google product teams, even after the 2023 Brain merger pulled it onto Google's leveling ladder. For Software Engineer you should expect a recruiter screen, one or two technical phone screens, a virtual onsite of coding, system design, and team-lead rounds, then several non-technical interviews, and finally a hiring-committee review and team match. One thing separates the coding rounds from core Google: you work in CoderPad and your code is expected to run by the end of the round, not just look correct on a shared doc.
Two distinctions matter before you prepare. First, Software Engineer and Research Engineer are different tracks with different loops - Research Engineer adds ML quizzes, math, and ML-design rounds that most SWE candidates never see. This guide covers the Software Engineer loop and flags Research Engineer material where it bleeds over. Second, the process is slow: candidates across Blind and Glassdoor describe weeks-long silences between stages, and Glassdoor puts the SWE average at about 60 days against a 40-day company-wide figure. Plan your other interview loops around that.
A call covering your background, motivation, and which track (Software Engineer vs Research Engineer) and team area fit you. Recruiters also preview the loop; one candidate was told upfront the interviews would focus on coding, data structures, algorithms, and operating systems.
Tip Ask the recruiter exactly which rounds your loop contains - the mix of coding, CS-fundamentals discussion, and design varies by team, and candidates who asked got a straight answer.
One or two 45-60 minute live coding rounds in CoderPad. Problems are mostly LeetCode-medium (grid traversal, random-number generation, string and date manipulation), though some candidates report modified LC-hard problems with bit manipulation. Several reports describe a verbal CS-fundamentals discussion in the first 15 minutes - floating point representation, the Python GIL, memory management, concurrency - before the coding starts.
Tip Have runnable code with passing test cases by the end - candidates repeatedly flag this as the difference from core Google loops. And do not skip low-level CS theory; the verbal warm-up is where LeetCode-only prep fails.
Two to three further coding rounds, team-agnostic and LeetCode style. Most 2024-2025 reports say medium difficulty ("standard leetcode medium, nothing crazy"), while a minority describe uncommon LC-hard variants under time pressure. Dynamic programming and backtracking are in scope; exotic structures like suffix trees are not.
Tip Narrate your approach and complexity before typing, then get to working code fast. Interviewers are described as supportive, but running out of time on a hard variant is the most common reported failure.
The least standardized round. An October 2025 Glassdoor report describes a team-specific ML system-design round after two team-agnostic coding rounds. A Blind SWE instead got "describe a recent project in as much detail as possible" in place of a classic design prompt, and an L4 candidate called their design question ambiguous and unusual. Expect tradeoffs, scalability, and simplicity to be probed hard.
Tip Prepare one recent project you can walk through to arbitrary depth - architecture, tradeoffs, failure modes, what you would redo. That single asset covers both the project-based and the classic variants of this round.
Similar to Google's team-matching conversation: the lead of the team you would join asks some light technical questions about the team's domain plus mostly behavioral, Googleyness-style questions. Both a full-time SWE and an intern candidate describe this round the same way.
Tip Research the team's actual systems and papers before this call. Committee reviewers expect you to want DeepMind specifically - not just Google - and this round is where that shows or does not.
Three to four further behavioral and leadership interviews (one SWE called them "standard leadership stuff"), then a written packet goes to a hiring committee of people who did not interview you. Behavioral signal from every round feeds this review. Silence after the final round is common and does not reliably mean rejection - one candidate heard nothing for weeks, then got an offer.
Tip Treat every round as a behavioral round. Interviewers can log culture feedback from any conversation, and candidates report strong technical performance being sunk by weak collaboration signal.
DeepMind evaluates you as an engineer who can work inside a research lab, and that shapes every signal they collect. Working code over whiteboard correctness - the CoderPad convention means they want engineers who ship a running solution, handle edge cases live, and test as they go. Breadth of CS fundamentals - the verbal discussions on memory, concurrency, floating point, and linking test whether you understand the machine, because platform and research-infrastructure work at DeepMind sits close to it.
Judgment in ambiguity - the system-design round is deliberately less templated than FAANG loops. Whether you get an ML-serving design or "walk me through your last project," interviewers reward clear tradeoff reasoning and simple designs over box-drawing, and one candidate flagged that keeping the design simple was explicitly what the interviewer wanted.
Googleyness and research-lab fit - since the merger, DeepMind inherits Google's culture evaluation, and any interviewer can file behavioral feedback. The committee also reads for something Google product loops do not: evidence you can collaborate with researchers and that you want DeepMind's mission specifically. Candidates who cannot say why DeepMind rather than Google, or who know nothing about the lab's published work, report this counting against them despite solid technical rounds.
Every question below is based on candidate-reported interviews and labeled by how often it appears.
Tests: Comfort with randomness, distributions, and correctness reasoning in a live coding setting.
Approach: Clarify the target distribution and what primitives you may use, then reduce the problem to sampling you can prove uniform. Rejection sampling is the usual key insight for building one distribution from another.
Tests: Classic graph traversal, state encoding, and clean handling of visited cells and boundaries.
Approach: Decide early whether the problem is shortest-path (BFS) or reachability/enumeration (DFS/backtracking), and encode grid state explicitly. DeepMind expects the code to run, so write a small test grid before declaring victory.
Tests: Careful index reasoning and translating a mathematical definition into simple code.
Approach: A Hankel matrix is constant along anti-diagonals, so every element relates to a neighbor by a fixed index rule. Derive that rule on paper first; the implementation is then a short double loop with early exit.
Tests: Edge-case discipline: month lengths, leap years, year rollover - simple logic done flawlessly.
Approach: Enumerate the edge cases out loud before coding: end of month, end of year, February in a leap year. Table-drive the month lengths and isolate the leap-year rule in one tested helper.
Tests: Low-level bit fluency and the ability to derive an encoding scheme, not just recall one.
Approach: Work a tiny example by hand to find the bit-layout invariant, then express pack and unpack as masks and shifts that mirror each other. Verifying that decode(encode(x)) round-trips is the fastest live sanity check.
Tests: Whether you can land runnable code on an unfamiliar hard problem - the reported failure mode is simply running out of time.
Approach: Get a correct brute force running early, then optimize - a working slow solution beats an unfinished optimal one when the convention is that code must execute. State the intended optimal complexity so the interviewer sees where you were headed.
Tests: Partitioning, fault tolerance, and throughput reasoning for the data-heavy workloads DeepMind runs.
Approach: Frame it as partition, process, aggregate: shard the input, make workers idempotent and restartable, and pick a coordination strategy you can defend. Name the bottleneck (I/O, shuffle, or stragglers) before proposing fixes.
Tests: Adapting standard design tools (caching, batching, sharding) to model-serving latency and accelerator capacity.
Approach: An October 2025 candidate called this round team-specific where coding was team-agnostic, and a separate report called it the hardest round - tradeoffs, scalability, and keeping the design simple. Ask what the team serves, design to that, and resist adding components the prompt never asked for.
Tests: Real depth of ownership: whether you understand your own system's architecture, tradeoffs, and failure modes.
Approach: Pick a project where you owned architectural decisions and rehearse it in layers: problem, constraints, design, tradeoffs, what broke, what you would change. Expect follow-ups to drill until they find the edge of your understanding.
Tests: Whether you understand the machine under your code - theory only, no implementation required.
Approach: Multiple Blind posters describe a 15-minute low-level discussion opening the coding round. Review IEEE-754 basics, why the GIL limits CPU-bound threads, stack vs heap and common leak patterns, and threads vs processes vs async - crisp one-paragraph answers are the target.
Tests: Working knowledge of OS mechanics relevant to infrastructure and platform engineering.
Approach: Be ready to explain leak mechanisms (lost references, unbounded caches, forgotten frees) and the load-time story of a dynamically linked binary - symbol resolution, shared objects, and why it saves memory. Concrete examples beat textbook definitions.
Tests: Whether your ML knowledge survives without a framework - forward pass, backprop, and honest discussion of past work.
Approach: Practice a minimal NumPy MLP: layer forward passes, a loss, and gradient updates via the chain rule. This leans toward ML-adjacent SWE teams and the Research Engineer boundary - if your loop is pure platform SWE you may not see it, but candidates for ML-facing teams have.
Tests: Broad technical literacy across CS, ML, and math - a Research Engineer-style filter some SWE candidates historically hit.
Approach: This is adjacent-role territory: the structured quiz is a Research Engineer staple, and a 2024-2025 Blind reply suggests it has been dropped for plain SWE loops. Confirm with your recruiter; if your team is research-facing, skim ML basics and probability rather than deep-diving.
Tests: Genuine engagement with the lab's mission and research, which the hiring committee explicitly reads for.
Approach: Name specific DeepMind work that connects to your interests - a system, a paper, a product like AlphaFold-adjacent tooling - and link it to what you want to build. A generic big-tech answer is the reported failure mode here.
Tests: Collaboration under disagreement - central to Googleyness feedback that any interviewer can file.
Approach: Use a real disagreement with a technical core, show how you sought the other side's data, and land on a resolution where the best argument won - ideally not yours. Committees read for humility plus backbone, not victory stories.
Tests: Whether you fit this specific team and can collaborate with researchers, not just pass generic rounds.
Approach: Read the team's recent publications or systems and prepare two or three sharp questions about their roadmap. Both intern and full-time reports describe this round deciding team match, so treat it as the closing argument for your candidacy.
An experienced software engineer running the full DeepMind SWE loop, posting on Blind.
Counting everything, the loop was three coding rounds, one system design, one team-lead round (somewhat technical, but not really), and three to four purely non-technical interviews. Coding was standard LeetCode-medium, "nothing crazy." The system-design round was not a standard FAANG design interview - instead the candidate was asked to describe a recent project in as much detail as possible. The overall experience was positive, but the gaps between stages were frustratingly slow.
Takeaway: Prepare a deep walkthrough of one real project - it can be your entire design round - and budget for a slow, multi-week pipeline.
A software-engineering candidate reporting on Glassdoor in October 2025.
The loop was two LeetCode-style coding rounds, then an ML system-design round, then a Googliness round. The candidate noted the coding rounds are standard and team-agnostic while the design round is team-specific, and that coding happens in CoderPad where you execute your code. A separate reviewer from the same period called the design round the hardest - focused on tradeoffs, scalability, and keeping the design simple.
Takeaway: Practice running and testing your code live, and research your target team before the design round - it is built around their workload, not a generic prompt.
A candidate whose loop leaned toward the research-facing end of DeepMind engineering.
The first interview was quiz-like, sweeping across computer infrastructure, data structures and algorithms, ML topics (regression, SVMs, Bayesian networks), and math (calculus, probability). The coding round that followed brought two LeetCode-hard problems built on bit manipulation, including deriving the equations to encode and decode bit packets. The candidate found it markedly tougher than the medium-level loops other SWEs describe.
Takeaway: Loop difficulty varies sharply by team - research-facing teams can bolt Research Engineer-style breadth quizzes and hard coding onto the SWE process, so ask your recruiter exactly what your loop contains.
A candidate rejected after the coding rounds, posting a debrief on Blind.
The coding questions were modifications of uncommon LeetCode-hard problems rather than recognizable classics. The candidate understood the problems but took too long to reach complete solutions within the time limit, and was rejected. They noted the interviewers were supportive throughout rather than adversarial.
Takeaway: Speed to a working solution is the bar. Train on unfamiliar hard problems with a countdown timer, and get a correct brute force running before you chase the optimal answer.
A software-engineering intern candidate interviewing for the Research Platform team.
After clearing the technical interviews, the candidate faced a team-lead interview described as similar to Google's team-matching round: some technical questions about the team's work, but mostly behavioral, Googleyness-style questions. They came to Blind looking for advice on it, which is itself a signal - this round is underestimated.
Takeaway: The team-lead round is a real gate, not a formality. Know what the team builds, and bring specific reasons you want that team - not just DeepMind's brand.
Week 1 - Calibrate and rebuild fundamentals. Ask your recruiter which rounds your loop contains (coding count, whether design is classic or project-based, whether any ML content appears). Do eight to ten LeetCode mediums on grids, BFS/DFS, and strings in Python, running every solution end-to-end as you will in CoderPad. In parallel, start the verbal-CS review: floating point, stack vs heap, memory leaks, dynamic linking.
Week 2 - CoderPad discipline and hard-problem speed. Drill the DeepMind-specific skill: working code within the hour. Practice on a timer, always landing a running brute force early. Add dynamic programming and backtracking (in scope per candidate reports) and a session on bit manipulation - masks, shifts, and encode/decode round-trips. Rehearse one-paragraph spoken answers on the GIL, concurrency models, and threads vs async.
Week 3 - Design, both variants. Prepare the project deep-dive: one system you owned, rehearsed in layers down to failure modes and regrets, since several candidates got this instead of a standard prompt. Then run two or three timed classic drills - large-scale data processing and ML serving - practicing the habit 2025 reports reward: tradeoffs named out loud, and a design kept deliberately simple.
Week 4 - Team research, behavioral, and mocks. Write your specific answer to why DeepMind rather than Google, citing real DeepMind work. Read your target team's publications or systems and prepare questions for the team-lead round. Build four or five STAR stories on conflict, collaboration with researchers, and ownership - every interviewer can file Googleyness feedback, so none of these rounds is throwaway. Finish with a full mock interview under time pressure, coding aloud with running tests.
About 3.5/5. Glassdoor SWE applicants rate it 3/5 with a 60% positive experience, and most coding is LeetCode-medium. What raises the bar: your code must actually run in CoderPad, verbal CS-fundamentals questions punish LeetCode-only prep, and some loops use uncommon LC-hard variants.
Typically five to seven: a recruiter screen, one or two coding phone screens, two to three further coding rounds, one system-design round, a team-lead interview, and two to four non-technical rounds, followed by hiring-committee review and team match.
Roughly six to ten weeks. Glassdoor reports about 60 days on average for Software Engineer versus 40 company-wide, and candidates consistently describe long silences between stages. Weeks of post-loop silence does not reliably mean rejection - offers have arrived after them.
Yes - they are separate tracks with separate loops. Research Engineer adds ML/AI quizzes, math, ML-design rounds, and sometimes a code-review round. Software Engineer loops center on coding, CS fundamentals, system design, and behavioral rounds, though research-facing teams can blend in RE-style content.
Yes. Most 2024-2025 reports describe standard LeetCode-medium problems - grids, strings, dates - with dynamic programming and backtracking in scope. A minority report modified uncommon LC-hard problems, including bit manipulation. Unlike core Google, you code in CoderPad and are expected to have a running solution.
Yes, one round, but it varies: some candidates get a team-specific ML or distributed-systems design (called the hardest round in one 2025 report), while others are asked to describe a recent project in maximum detail instead. Prepare a deep project walkthrough either way.
Python is the safe default - it is what candidates report using in CoderPad, and verbal questions like explaining the Python GIL assume familiarity. Whatever you pick, choose the language you can write, run, and debug fastest, because working code within the hour is the bar.
Partially. Since the 2023 Brain merger, DeepMind engineers sit on Google's L3-L8 ladder and the loop includes Googleyness evaluation and a hiring-committee review. But DeepMind still runs its own process: CoderPad rounds where code must run, CS-fundamentals discussions, and team-specific design rounds.