Anduril Coding: What to Expect

Does Anduril do LeetCode? Yes. People hear "defense contractor" and brace for something exotic, and that's the first thing to unlearn. The Anduril software-engineer coding interview is a fairly conventional data-structures-and-algorithms loop. The phone screen is commonly two Medium problems in about an hour in a collaborative shared editor, and live onsite coding rounds follow it. The recurring problems are recognizable Mediums. No marathon take-home. The prompt, though, is vague on purpose, and the interviewer expects you to clarify it before you write a line. Then you're graded on shipping working code that holds up as the problem escalates, more than on landing the tightest possible Big-O.

The coding also shifts by team, because Anduril hires into a named team. Autonomy and embedded work leans toward C++, with Rust in real use on the vehicle software, so screens there are more likely to run in a systems language. The Lattice platform and full-stack side is a more familiar application layer of services and a web surface, where you generally code in your strongest language and a general-purpose choice like Python is welcome. Perception and mission-software teams sit in between. The Anduril Stack covers the per-team stack and how to choose a language for your screen. One gate spans every team. Anduril's work is export-controlled, so roles require a US person (a citizen, lawful permanent resident, or protected individual), and some also require a clearance. Check your eligibility before you put in the weeks.

The Anduril angle

The problems are ordinary. The difficulty is in how you're judged. You get an under-specified prompt on purpose, and the interviewer watches whether you pin down the requirements before you commit to an approach. Then the problem grows under you in phases. Your code still running after the ground shifts counts for more than an optimal first pass. Spend a week on Hard-tier dynamic programming and exotic graph theory and you've prepared for a different firm. You'll also have skipped the two habits that decide the round: clarifying a fuzzy spec out loud, and writing code that survives the next twist. Complexity still matters, just less than working code does. Ship an obvious O(n²) where a clean O(n) was sitting there and it will be noticed.

The shape of a coding round

First comes a technical phone screen of roughly an hour in a shared editor, commonly two Medium problems, sometimes bundled as a single multi-part exercise. Clear that and the onsite is usually two coding rounds of about an hour each, next to one system-design-or-object-oriented-design round and a behavioral conversation with a senior leader. Decisions tend to come fast. Often it's a day or two after each round. With no separate take-home build, the live rounds carry the whole coding signal.

The prompt arrives underspecified on purpose, and the first test is whether you ask about the gap or quietly code around it. Nail down the inputs, the ranges, what counts as valid and what the output should be, out loud, before you reach for an approach. From there the problem escalates in gates. A clean version comes first. Then the interviewer widens it: uneven or ragged inputs, tricky edge cases, inputs that are invalid or have no solution at all, then a new constraint on the same problem. You don't have to finish every gate to advance. The interviewer is reading how far you get and how you get there. Narrate your reasoning and keep the code runnable at each step, instead of chasing a perfect final answer in silence.

Take a representative escalation. Two teams of players stand in two rows, and you arrange them by height so that nobody blocks a shorter player behind them. Solve that, and the prompt grows. The teams are now uneven, with empty positions that let players shift, and you have to decide whether a valid arrangement is even possible. Another common shape starts as the shortest straight-line distance between two points. Then obstacles go in the way and you need the shortest path around them, which quietly turns a geometry warm-up into a grid search. Both patterns are standard. What the interviewer wants to see is you extending your solution while the prompt keeps growing.

The Anduril angle

Robustness is a core part of the grade here. One recurring problem has you evaluate an expression in reverse-Polish notation, then keeps adding demands. Handle a power operator, accept non-integer numbers, reject malformed input cleanly, and write your own test cases as you go. That last part is the tell. Anduril builds systems where bad input is a fact of life. An interview that rewards you for reaching for the ugly cases yourself is testing the instinct the job needs. Think empty inputs, a single element, out-of-range values, the unsolvable configuration. Treat edge cases and your own tests as part of the deliverable. Say what you're checking and why before anyone asks.

The problems wear a defense skin

There's no secret Anduril problem list to memorize, and hunting for one is a distraction. The recurring problems are ordinary Medium patterns dressed in the domain. The signature is a border-sensor question: place detection towers along a border and return the minimum sensor range that covers every crossing. That is binary search on the answer with a two-pointer sweep, the same shape as the classic heaters problem. It shows up often enough to recognize on sight. A second favorite gives you a run of sensor or temperature readings and asks how many steps until a higher one, which is a monotonic stack. Grid problems arrive as island-counting, as gates and walls where you flood distances out from fixed points, and as best-path searches. All of them are breadth-first or depth-first traversal underneath.

Away from the defense framing, the plain versions surface too: grouping anagrams with a hash map, ordering a course schedule with a topological sort, sorting a binary array in linear time. The ceiling stays at Medium. A Hard shows up now and then, but the named problems that recur all sit at Medium. So aim to own the ordinary patterns cold: binary search, the monotonic stack, grid traversal, hashing and topological sort. Know them well enough to spot through a costume and then carry through the escalation the interviewer stacks on top. A longer problem list buys less than that.

Work standard Medium problems end to end until they compile and run, because the live round grades working code. Then rehearse the escalation itself. Take a clean solution and break your own assumptions on purpose: feed it ragged input, an empty case, an unsolvable configuration, and patch it in place the way the interview will ask you to. Drill a Medium-heavy list of the common patterns to fluency, and build the habit of clarifying first and testing your own edges. That covers far more of this loop than any amount of Hard-tier grinding.

The lessons in this section

The lessons below split the loop into the patterns you need at your fingertips and the stack you code in. If you're still calibrating what to drill, start with the patterns. Already know your team and want to pick a screen language? Start with the stack.

Common questions