Skip to main content

Backend Engineer

How do you decide what to alert on for a service you own, so the on-call engineer is woken only for things that matter?

TechnicalSeniorTests: Reliability & observability
Drill this questionCreate a free account to answer out loud with Ava and get feedback.

What the interviewer is looking for

  • This question tests reliability & observability. Uses logs, metrics and traces to investigate, sets meaningful alerts and service objectives, and learns from incidents.
  • Strong answers: Alerting on user-facing symptoms and service level objectives rather than every metric, actionable alerts with runbooks, reviewing noisy alerts, and error budgets.
  • Likely follow-up: How do you get the team to agree on what the service level objective should be?

Another way it may be asked: Your on-call phone buzzes twenty times a night, mostly for nothing. How would you fix the alerting?

A structure to follow: Answer, explain, example, limits

  1. Step 1

    Answer

    Give your direct answer in the first sentence so the interviewer knows where you are going.

  2. Step 2

    Explain

    Say how it works or why you would do it that way, in plain words before jargon.

  3. Step 3

    Example

    Anchor it in something you have actually done or seen, with the detail that shows hands-on experience.

  4. Step 4

    Limits

    Say when your approach would not be the right one. It shows judgement.

This is guidance on shape, not a script. Use your own real experience and facts; never invent details to fill a gap. See the STAR guide and answer frameworks.

Common slips

  • Reciting a definition without showing you have applied it.
  • Using terms you cannot explain if asked a level deeper.
  • Claiming experience beyond what you can discuss in detail.

How to practise it

Say the answer in 90 seconds, then answer the follow-up as if it were a new question.

Browse all questions

How do you decide what to alert on for a service you own, so the on-call engineer is wo... | How to answer