Staff Engineer - Distributed Systems

10+ years of engineering experience with deep, hands-on ownership of large-scale distributed systems, comparable scale strongly preferred: hundreds of services or thousands of instances, billions of daily events

You've carried sole accountability for a production system through real failures, not adjacent to it, not advising on it. Owned it

Deep command of queueing and async architectures, delivery semantics, ordering, backpressure, idempotency, exactly-once myths and at-least-once realities

Strong with multiple storage engines (SQL and NoSQL), you reason about consistency models, indexing at scale, and when each engine is the wrong choice

Expert-level depth in Redis or comparable in-memory systems, including their failure modes under memory pressure and network partition

Production experience on Kubernetes at scale, resource limits, autoscaling behavior, what actually happens when a node pool dies

Exceptional design communication, docs, diagrams, and RCAs that drive decisions across multiple teams

Fluent in Node.js and/or Go, enough to prototype your own proposals and ship fixes on the critical path

The critical paths of Workflows have named owners, capacity models, and tested failure modes, because you made it so

Incident count trends down while traffic grows double-digit percent month over month

Your design reviews are the ones engineers want their proposals to survive

Your scope has expanded on results, more systems, more surface, more trust

You've been injured in production. A lot. You've owned distributed systems at serious scale, through the outages, the migrations, the 3 AM discoveries, and every scar changed how you design

You've operated at staff scope, whatever your title said, the engineer everyone routed the hardest systems questions to

You think in failure modes by default: when you see a design, you instinctively ask what happens at the tail, under partition, at 10x load

You write design docs and RCAs that people reference years later, clear trade-offs, honest risks, real recommendations

You can disagree with a team and still make them better, influence through rigor and respect, not title

You'd rather prevent ten incidents quietly than be the hero of one loudly

You've made AI agents genuinely productive on complex systems, and know how to keep AI-generated code from becoming AI-generated incidents

GCP-native experience: Pub/Sub, Cloud Tasks, GKE, Firestore

You've done this job before under another name, "the systems person," principal engineer, architect-who-still-codes

Experience taking a 0→1 system to production alongside hardening mature ones