Question 1

operational vs programmer errors in Node — why distinguish?

Accepted Answer

Operational: expected runtime failures (network); programmer: bugs — crash and fix vs retry/handle. Joyent's guidance still influences interviews. Don't catch-all and continue after corrupted state.

Question 2

Why is try/catch around an async function call without await ineffective?

Accepted Answer

The function returns a promise; synchronous try/catch won't see async rejection. Await inside try/catch or attach .catch. This is a classic junior/mid footgun.

Question 3

Should you catch uncaughtException and keep running?

Accepted Answer

Generally no — state may be corrupt; log, alert, and exit for process supervisor restart. Domain is deprecated. Use proper rejection handling. Crash-only for unknown errors is safer.

Question 4

How do you model errors for APIs?

Accepted Answer

Typed/error codes, HttpError hierarchy, cause chaining, and consistent client payloads without leaks. Include correlation IDs. Map validation vs auth vs internal. Don't expose stacks to clients.

Question 5

Express async errors — patterns?

Accepted Answer

Wrap async route handlers or use Express 5 / utilities that forward rejections to error middleware. Unhandled rejections in middleware hang or crash. Centralize mapping to status codes.

Question 6

Lead: error budget and incident taxonomy for Node platforms.

Accepted Answer

Classify errors (user/client/server/dependency), burn rates, and playbooks for crash loops vs dependency outages. Standardize logging fields. Make on-call actionable. Prefer graceful degradation over silent catch.

Error Handling Node.js Interview Questions

Other Node.js interview topics