This assessment is fictional. The candidate, the companies and the systems are invented to show the format. It isn't based on any real interview.
| Candidate | Candidate A |
|---|---|
| Role | Staff SRE, Database Platform |
| Your environment | Series C payments company, about 400 Postgres clusters on Kubernetes across three regions |
| Round | The Pager Test, 45 minutes, interviewed by Vitaliy Mogilevskiy |
1. Recommendation: yes, with reservations
Candidate A has owned and operated a Postgres failover and drill system at a scale close to yours (about 140 clusters). They found its most dangerous failure mode without prompting and could explain it down to how a replacement pod gets its data. The reservation is change safety. Their team rolls configuration out to the whole fleet at once, and they reached for staged waves only when asked. At 400 clusters, that's the gap most likely to cause an incident. It's coachable, and the rest of your loop should test it directly (questions below).
Scale: strong yes · yes · yes, with reservations · not for this role · no. Always judged against your environment, not in the abstract.
2. The system and their role in it
Failover orchestration and weekly failover drills for about 140 Postgres clusters (Patroni on Kubernetes, two regions) at a logistics company. The Patroni setup predates them. Candidate A designed and built the drill scheduler, the pre-flight checks (replication lag, open transactions, pending schema changes) and the post-drill report, and was one of two engineers maintaining the operator.
They were precise about the line between their work and the team's. That's a good sign in itself.
3. Architecture depth: strong
They walked from an alert to the pod without hand-waving: one primary and two replicas per cluster across zones, etcd as Patroni's configuration store, connection pooling in front, and WAL archived to object storage. Asked how a replacement replica gets its data, they compared a base backup from a live replica (about 25 minutes for their largest 3 TB cluster) with restoring from the archive (about 90 minutes), and explained when they'd accept the extra load on a replica to save the time.
4. Failure-mode reasoning: strong
Unprompted, they named the weak spot: in one region, Patroni shared its etcd cluster with the Kubernetes control plane. An etcd brownout there would demote every primary in the region at once. They explained the blast radius, how they found it (a drill that stalled for a reason unrelated to the cluster being drilled) and the fix: a dedicated etcd per region plus Patroni's failsafe mode. This is exactly the kind of corner the role needs someone to see around.
5. Automation judgment: mixed
Strong: the drills are real automation with real adoption. Every cluster is in the weekly rotation, pre-flight checks abort cleanly, and last year three drills surfaced failures before customers did.
Weaker: Postgres and Patroni parameter changes ship as one release to every cluster. Asked how they'd limit the blast radius, they proposed waves by region with a health gate between them, but only after prompting. They hadn't considered stopping on the first failure, or how to back out a parameter that needs a restart.
Manual seam they know about: major-version upgrades are still a runbook a person follows. They have a sensible plan (logical replication and a cutover) but haven't run it across a fleet.
6. Where they'd need support
- Rollout safety at 400 clusters. Pair them with whoever owns change management today, and review your rollout tooling together in the first month.
- Fleet-wide major-version upgrades, which they haven't done yet.
- Your three-region topology, compared with their two.
7. What this round couldn't assess
Incident leadership under pressure, design writing, and influence across teams didn't come up in enough depth to judge. Questions for the rest of your loop:
- “Walk me through rolling out a restart-required Postgres parameter to 400 clusters. At what point do you stop?”
- “Tell me about a drill that failed. Who did you have to convince, and what changed afterward?”
- “Here's our three-region layout. Where does the configuration store live, and what happens when one region loses quorum?”
8. Take-home
Their take-home (a small reconciler) was clean, tested and idempotent. They chose to converge on a desired state rather than issue one-off commands, and could explain why that matters when a run is interrupted halfway.