Design a Doubly Linked List

"Implement a doubly linked list, with insert, delete, and search." That's the whole prompt, and candidates report it more than any other from-scratch data-structure ask here. It looks trivial for about a minute. Then the interviewer starts deleting the node at the tail, then the node at the head, then the only node in a one-element list. They're watching whether your pointers stay consistent or leave a dangling reference behind. Keeping pointer invariants true through every operation and every boundary is the whole skill. On a vehicle, that same list might be a real-time buffer.

A doubly linked list is a good probe because it has almost no algorithmic content and almost all invariant content. There's no clever trick to find. Every method is four or five pointer assignments. The score is whether they hold the structure together on an empty list, a one-node list, or an operation that lands on the first or last element. Get the order of the assignments wrong and you splice a node out of the forward chain but leave it hanging in the backward one. Skip a boundary and a delete on the head walks into a null pointer. The interviewer wants to see you handle those cases on purpose, before they ask.

The Anduril angle

Anduril makes you build the data structure by hand because its systems run on hand-built ones. The autonomy and Lattice stacks live close to the metal, in C++ and Rust on embedded computers wired to sensors. A garbage-collected standard-library list you can forget about isn't an option there. You own the memory and the pointers. A link left inconsistent is a corruption bug on a machine you can't attach a debugger to in the field. So the round grades what the job does. Keep the prev-and-next invariant true through insert, delete and reverse. Reach for the boundary cases (the empty list, the single node, the head and the tail) unprompted. Name the invariant before you write a method. Handle the ends deliberately instead of patching them after a test fails.