Lesson 19 · Senior observability judgment

Mock senior observability interview pack

A retrieval-first mock pack for turning the whole observability course into clear, interview-grade answers you can say under pressure.

Your win: run a realistic senior observability mock interview on yourself, score your answers honestly, and turn weak spots into a focused review plan.

In plain English Plain English: answer out loud before checking the answer points. Recognition is not recall.

The format

This page works best if you treat it like a real interview. Answer first. Then check the points. Then answer again more cleanly.

The answer checklist A strong answer should usually include: (1) the mechanism, (2) the main trade-off or weakness, and (3) a repo-grounded consequence or example.

How to use this page like the strongest earlier lessons

Do not skim the answer points and move on. The value of this page is in the gap between what you recognize and what you can say clearly under pressure. That is why the rule is answer first, check second.

If an answer feels shaky, do not just mark it wrong. Ask yourself which part was missing: the mechanism, the trade-off, or the repo-grounded consequence. That makes your review much more targeted.

Round 1 · Signals and metrics

  1. Why is “measure everything” a bad instrumentation rule?
  2. Why is high-cardinality labeling dangerous?
  3. Why does Prometheus only keeping 2h locally not make the stack unusable?
  4. Why is Thanos the default Grafana datasource here?
  5. Why should you usually graph a counter with rate()?
  6. What is the difference between a dashboard and a signal?
Round 1 · Strong answer points
  1. Signal choice. More telemetry is not automatically better; the goal is useful, queryable evidence for real incidents.
  2. Cardinality. Near-unique labels explode time-series count and cost while making operations harder.
  3. Retention split. Prometheus handles short-retention scraping; Thanos provides long-term/global query.
  4. Datasource role. Grafana defaults to Thanos because Prometheus alone keeps only short local history.
  5. Counter truth. Raw counters only climb; rate() turns them into current operational speed and handles resets.
  6. Signal vs view. A dashboard is a presentation surface; the underlying signal is the telemetry and query behind it.

Round 2 · Alerting and reliability targets

  1. What makes an alert page-worthy instead of dashboard-worthy?
  2. Why do routing labels matter operationally?
  3. How would you describe the repo’s SLO maturity honestly?
  4. Why is burn-rate alerting more mature than raw threshold paging?
  5. Why is Alertmanager not the whole paging story here?
  6. What is the cleanest summary of the repo’s alerting pipeline?
Round 2 · Strong answer points
  1. Page quality. A page must be actionable, urgent, and owned by the right human.
  2. Routing labels. Labels such as app/severity drive grouping, routing, and escalation ownership.
  3. SLO honesty. The repo has SLO-like alert thresholds, not full formal SLO objects and burn-rate operations.
  4. Burn-rate value. Burn rate pages when the SLO is truly threatened instead of reacting to every brief spike.
  5. Human path. Alertmanager groups and routes, but Grafana OnCall carries schedules and escalation runtime state.
  6. Pipeline. Prometheus rule → Alertmanager routing/dedup → team OnCall webhook → Slack/Twilio escalation.

Round 3 · Traces, logs, cost, and review judgment

  1. Why is sampling an evidence-quality question, not just a cost question?
  2. Why are logs still necessary even when traces exist?
  3. How do you move across the three pillars during an incident?
  4. What makes Jaeger all-in-one an important repo detail?
  5. How would you review whether an observability change is useful or just noisy?
  6. How would you summarize this repo’s observability philosophy honestly?
Round 3 · Strong answer points
  1. Sampling trade-off. Sampling controls cost, but it also determines which traces remain as detailed incident evidence.
  2. Logs’ job. Metrics quantify, traces localize, logs still explain concrete failure context and messages.
  3. Workflow. Metrics say what, traces say where, logs say why; correlation links them.
  4. Repo detail. Jaeger all-in-one means the tracing backend is simpler and more pragmatic than a fully distributed deployment.
  5. Review lens. Ask what question the telemetry answers, how dependable it is, and what cost/blind spot it introduces.
  6. Repo philosophy. Practical self-hosted observability: real coverage, honest trade-offs, and no pretending the stack is more mature than it is.

Self-scoring rubric

ScoreMeaning
0I could not explain it without notes.
1I gave fragments, but the answer was incomplete or fuzzy.
2I explained the main idea, but missed the trade-off, weakness, or repo consequence.
3I gave a strong, clear answer with mechanism + trade-off/weakness + repo consequence.
Recovery map — where to go next Missed signals/metrics? Revisit Lessons 1–6. Missed alerting/SLOs? Revisit Lessons 7–8 plus 14–15. Missed traces/logs/debugging? Revisit Lessons 9–12 plus 16–17. Missed senior judgment? Revisit Lessons 13–18.

What this mock is really training

This page is not mainly testing whether you have seen the terms before. It is testing whether you can move from concept → trade-off → repo consequence smoothly enough to sound believable in a live conversation.

That is why the strongest answers here are rarely long. They are usually clean, honest, and well-structured. If you can keep that rhythm, the page has done its job.

Q1. The main rule of this mock pack is…

Retrieval first is what turns recognition into interview recall.
What are the three ingredients of a strong senior observability answer?
recall, then click to reveal
A clear mechanism or signal, the important trade-off or weakness, and a repo-grounded consequence or example.
If you want, I can now run this as a live mock senior observability interview and grade you answer by answer. Ask me.

Sources. This pack synthesizes the whole course into retrieval practice.