Forward Deployed Engineer

About Antithesis We’re on a mission to redefine how modern distributed systems are tested and released. Our platform is trusted by engineering teams who demand rock-solid reliability, scalable performance, and deep technical visibility. Our platform doesn’t just assure system correctness and reliability, it exists because developers need something better. If you’ve ever experienced the pain of a production outage, had a bad week on-call, or had a release delayed by weeks because of one killer bug – you’ll understand exactly why we’re doing what we do. If you're passionate about developer-first products, system resilience, and correctness, we’d love to talk. About the Role The best way to learn what our platform should do next is to sit next to the people using it. That's this job. You'll embed with our customers, find where shipping reliable software is still too hard or too slow, and help build what Antithesis does next. What You’ll Do Almost every company we work with shows up with some version of this: "We're building a new system that we need to ship fast, but it can't fail. So every big change turns into weeks of careful review before we trust it. How can we use Antithesis to do this?" You're the person who shows up. From day one you help a customer get their system running inside Antithesis, make sure it's catching the bugs they care about most, chase down the real [... source excerpt omitted ...] o how they ship: their CI, their reviews, the way their agents write and check code. When it works, they merge big changes fast and trust that what they shipped holds. That's the customer-facing half. The other half is why we send an engineer. You notice what was slow, manual, or missing, and propose a fix. You work with our platform engineers to prototype it: a sharper way to find bugs, an easier way to fix them, or an agent skill that iterates on the results. Then you take it back to your customer to validate that it solves their problem. A lot of what makes Antithesis good today came out of that loop. What We Need: You've spent real time building or operating serious system [... source excerpt omitted ...] le. You know how systems break under concurrency, faults, and load in ways no test caught. The domain matters less than the instinct for where things go wrong. You've worked with customers as an engineer. You've been in the room where something's broken and you're the one who has to help, and you didn't hate it. You can read an unfamiliar codebase, instrument it, write a test, and debug something you've never seen before. When you hit a rough edge, you'd rather fix it than route around it. Here, your fix might ship to everyone. You can explain hard things to non-technical people without lecturing. You're up for five days a week in the office (DC, London, or SF) and occasiona