Platform & Developer Experience
5 · Observability Engineer
Separating out into its own discipline right now — the platform family's equivalent of evaluation in the AI family.
What the job actually is
You make systems explicable: metrics, logs, traces, and the increasingly expensive question of which of them to keep. The reason this is becoming a standalone role is cost — telemetry volume grows faster than the systems producing it, and someone has to own cardinality, sampling strategy and the bill.
The parallel with evaluation is exact: observability is named in 42% of postings and titled in far fewer, which means most people assessed on it have never studied it deliberately.
Titles this hides behind
Prepare like this
- Understand cardinality properly. Why adding a user ID label to a Prometheus metric can cost six figures, and what you do instead.
- Know sampling strategies — head, tail, and why tail sampling is both what you want and operationally painful.
- Instrument something real with OpenTelemetry end to end, and be able to explain the collector's role.
- Have a cost story. Telemetry spend reduced without losing the signal that mattered — this is the interview's favourite territory.
Be ready for
- "Your observability bill is larger than your compute bill. What do you cut first?" Increasingly a real situation, and the reason the role exists.
- "A request is slow but every service reports healthy. How do you find it?"
- "Metrics, logs or traces — you can keep two. Choose and defend it."
Compensation
What this role tests
Themes, and where to learn them
These chapters are shared across every role that tests them, so preparation here compounds rather than being spent once.
Practice questions across all themes → · Back to Platform & Developer Experience →