Staff Software Engineer

Who you are

• You reason about a system from its failure modes first. Handed an unfamiliar service under real load, you can name the three ways it breaks before you've read every line, and you can tell the difference between a system that's correct and one that merely hasn't failed yet. You form a working model fast, notice when it's wrong, and update. You write clearly, because clear writing is evidence of clear thought, and because the invariant you can't state in one sentence is one you haven't actually proven
• You treat agents as a tool you verify, never as an oracle you trust. You can still do the work by hand: trace a latency regression to its root cause, design a cache invalidation scheme, prove an invariant holds under a race you constructed yourself. That mastery is what lets you look at code an agent produced and say why it's right, or refuse to ship it
• You've probably built or rebuilt a system that serves real traffic under a hard latency budget, designed the correctness checks a team came to depend on without asking whether they still held, or debugged a production failure that only showed up under load nobody had tested for. Adjacent roads count fully: high-throughput data platforms, real-time serving infra, distributed systems under load anywhere it was unforgiving. We care about the artifact and the reasoning more than where you built it

What the job involves

• Agents write much of the code here now
• That only works because something else holds the line: a serving layer fast enough to answer at scale, and a body of rules an agent's output has to pass before it counts as shipped
• Today those two systems live with a very small team
• This seat is a third builder at the same depth, on the half of that substrate that needs the deepest systems background: the data and serving path, and the reliability floor underneath it, with no ops team to catch what falls through
• There's a sibling seat, Agent Systems, that owns the harnesses judging whether a loop's code or content output is correct
• This seat owns the invariant-level gates guarding the serving path and the reliability floor underneath all of it: a different altitude of the same problem
• This is the same class of problem as the two systems above, handed to someone who owns it end to end: distributed systems and correctness under real load, with the architecture decisions actually yours to make
• A serving layer at real scale, real latency. Hundreds of thousands of pages get rebuilt every night and served globally inside a hard latency budget. Every layer between a request and an answer, caching, indexing, the data path underneath, has to fit inside that budget, and it gets harder to hold as the page count grows
• A governed multi-agent build loop. Agent loops here run a full build to a shipped artifact, governed entirely by automated gates: deterministic checks, written as software, that decide what an agent's output is allowed to do, and where a judgment call needs a second, adversarial model instead of a human's eyes. Humans own the design of those gates and the failure modes they exist to catch. Your slice is the invariant layer underneath: the gates that hold when the serving path itself is what changed
• Correctness you can prove, not just observe. A green checkmark is a claim. The gates that decide whether millions of pages are correct, or whether an agent's output is safe to ship, need to be defended by invariant and by test, not by a demo that happened to work once
• Reliability with no net. There's no dedicated ops team standing behind this. When something breaks at 3am, the person who designed the system is the one who explains why it broke and what invariant would have caught it sooner. Correctness and uptime are your problem from design through the pager
• A partial rebuild is still a live system. When a nightly rebuild fails partway through, the cache underneath has to decide what's stale, what's safe to keep serving, and what the reliability floor needs to catch before a customer sees a wrong answer. That interaction, not the rebuild itself, is where the hard bugs live
• The ground moves under you. Every model generation changes what an agent loop can be trusted to do unsupervised, which means the gates and the serving layer both get rebuilt while they're running, not designed once and left alone
• If reading that energizes you, keep going. If it feels overwhelming or underspecified, this isn't the right fit
• The serving and data path. The infrastructure that rebuilds a huge page surface nightly and answers requests globally inside a hard latency budget. You own the architecture of what gets cached, what gets indexed, and what gets recomputed, and you defend the number when it's under pressure, not just when it's easy
• A slice of the enforcement layer, at the invariant level. The gates that decide whether the serving and data path holds under the load and the changes an agent introduces. Judging a single agent's code or content output belongs to the neighboring Agent Systems seat; you design these as software, as invariants and tests, not as prose policy someone reads and forgets
• The reliability floor. Uptime, correctness, and failure modes for systems that run unattended. You build the observability that tells you a system is wrong before a customer does, and you're the person paged when it doesn't
• The performance envelope. Where the system's real bottleneck is, and what it costs in latency or dollars to move it. You make that tradeoff explicit and defensible instead of folklore
• Your seat charter. Within your first quarter you co-sign a charter for this seat. It names one machine-checkable number that proves the seat is working, and a written split of what you decide freely versus what you bring to the founder to decide
• You will use the craft you already own (distributed systems, performance engineering, systems design defended under questioning) and grow into the layer above: designing the governance a multi-agent build loop runs inside, and the invariants that let autonomy scale without a human checking every step

The application process

• We don't run traditional engineering interviews
• Async video screen. About 15 minutes, on your own time. It replaces the recruiter screen. We want to see how you think, not how you present
• Calls with company stakeholders. Short conversations with the team you'd build beside
• Conversation with the founder. How you model the system above, where you push back, and whether you can defend the argument live
• Paid work trial. Real work, in our real environment, on the systems above. We watch how you get grounded, whether you write the invariant before the build, and whether your self-assessment is honest
• If the work above reads like yours but your resume is unconventional, apply anyway. We hire on the work and the reasoning, not the pedigree

Benefits

• Full health coverage: All premiums covered for you and your family. Medical, dental, vision.
• Daily catered lunch: For the LA team. One less thing to think about during the workday.
• Unlimited PTO: That we actually expect you to use. Recharge is not optional, it is structural.
• Remote flexibility: An LA headquarters with full remote support. Work where you do your best thinking.
• Free garage parking and commuter assistance