Top 7 Error handling Interview Questions
Browse 7 real-world technical and behavioral interview questions about Error handling. Review scenarios, edge cases, and architectural best practices.
A promise rejects and nothing is awaiting it. What does Node do?
An unhandled promise rejection in Node.js means a promise failed before any code observed the error. Treat it as a bug, await or return the promise chain, and make the process-level handler a last-resort alarm.
Your logs are full of Cannot set headers after they are sent. Walk me through how a request gets into that state.
ERR_HTTP_HEADERS_SENT means an Express route tried to set status or headers after the response had already been sent. The usual cause is two response paths: missing return after res.send, async callbacks racing, or an error handler trying to respond after headers are committed.
How do you design the error contract for an API that other teams have to program against?
Treat errors as published contract: an HTTP status that classifies the failure, a stable machine-readable code the client branches on, a human message that carries no internal detail, per-field detail for validation, and an explicit statement of whether a retry is safe.
A request fails but your Express error-handling middleware never runs. How do you work out why?
An Express error handler is skipped when it is not registered after routes, lacks the four-argument signature, or an async error never reaches next(). Express 4 needs explicit next(err) for rejected promises; Express 5 forwards them automatically.
Your function returns nil on the success path, the caller checks err != nil, and the check fires anyway. What happened?
A Go interface is non-nil when it holds a concrete type, even if the concrete pointer value is nil. Returning a typed nil pointer as an error creates an interface value that fails err == nil checks.
Walk me through the middleware chain of an Express service. What has to come before what, and why?
Middleware runs in registration order, so ordering is behaviour rather than style: the request id precedes logging, the body parser precedes anything reading the body, authentication precedes authorisation, and the error handler goes last because Express only searches forward from the failure.
You stream the model's answer token by token to the browser. What does that change about error handling, guardrails and cost?
Streaming commits you to the response before you have seen it: the status code is already sent, any check that needs the whole output now runs after the user has read part of it, a mid-stream failure has no clean retry, and an abandoned tab keeps generating tokens you pay for. It also connects llm serving to the point an interviewer is testing.