Backend Developer interview question
What observability does a backend service need?
A backend needs structured logs, metrics for rates/errors/latency, distributed traces, and correlation IDs. Instrument business-critical paths so an alert leads to a diagnosable question.
Direct answer
What a strong answer covers
How it works
Observability means being able to ask new questions about a running system without shipping new code. That takes three signals tied together: structured logs with a request ID and no secrets, metrics for request rate, error rate, latency distribution, and saturation of each dependency, and traces that show where a slow request spent its time across services. Alerts should be based on user-facing symptoms such as error budget burn, and every alert should link to a dashboard and a runbook that turn the page into a diagnosis.
Example
A checkout trace links the gateway, order service and database span, while a latency histogram shows whether the regression affects p95 or all requests. When p99 doubled after a deploy, the trace waterfall showed the extra time inside a new retry loop against the pricing service, which the metrics alone could not attribute.
Common mistakes
- Logging entire request bodies and leaking tokens or personal data into the log platform.
- Alerting on CPU or memory instead of on what users experience.
- Emitting averages instead of histograms and never seeing the slow tail.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.