1. Does asynchronous code always avoid blocking?
No. Marking a function async does not move its synchronous JavaScript onto another thread. CPU-heavy work before or after an await can still occupy the event loop. Node's official guide distinguishes event-loop callbacks from work handled by its worker pool; do not describe every operation as automatically parallel.
For an interview example, imagine an endpoint that awaits a database query and then sorts a huge array. The database wait may allow other work, but the sort can still delay unrelated requests. Explain the symptom you would expect, how you would profile it, and why adding async to another wrapper would not solve that CPU bottleneck.
2. How would you investigate rising API latency?
Start with one slow route, a time window, and a baseline. Separate time waiting for a dependency from time spent executing application work. Check request rate, response sizes, event-loop delay, CPU, memory pressure, and database pool saturation. A high average alone can conceal a small group of extremely slow requests.
Our practice scenario is a report endpoint that becomes slow only for large accounts. First compare input sizes and query counts. If it performs one query per row, address the access pattern. If query time is stable but processing time grows sharply, inspect the transformation. State what evidence would make you abandon your first hypothesis.
3. Why is unbounded Promise.all risky?
Creating thousands of concurrent requests can exhaust a connection pool or overwhelm a dependency. Promise.all combines results; it is not a concurrency limiter. Limit in-flight work using a bounded queue or worker count, and choose that bound from dependency capacity and measured behavior rather than a convenient round number.
Distinguish concurrency from rate. Ten in-flight operations can still generate a high request rate when each completes quickly. A service may need both a concurrency bound and a rate limit. Discuss what happens to queued work when a request is cancelled and how you prevent an ever-growing backlog from consuming memory.
4. How should an API handle errors and retries?
Separate invalid input, missing resources, dependency failures, and unexpected defects. Return a useful response without leaking credentials or internal traces, while retaining a correlation identifier for investigation. Avoid a catch block that silently returns success: it turns an observable failure into incorrect application behavior.
Retry only when the operation and failure make it safe. If a payment provider accepted a request but the response was lost, blindly retrying can duplicate work unless an idempotency mechanism exists. Use bounded attempts and deadlines, and explain which layer owns retries so multiple layers do not amplify the same outage.
5. What is backpressure, and why does it matter?
A producer can generate data faster than a consumer can process it. Backpressure lets the slower side constrain the flow instead of allowing memory to grow without bound. In an interview, use a concrete example such as exporting rows to a slow client, and describe where buffering happens and who stops producing.
Compare a fully buffered export with a streaming design. Streaming can reduce peak memory, but it introduces partial responses, cancellation, and error handling after headers have been sent. Explain how you would test a disconnected client and a slow destination. Do not claim that streaming removes the need to bound database reads or resource usage.
A twenty-minute practice round
Spend five minutes drawing the report request path, five listing measurements, five proposing the smallest fix, and five defining a regression test. Change one constraint halfway through: now two large reports run simultaneously. A good proposal still protects other users and explains the tradeoff between completion time and shared capacity.
Use Cluegent during permitted preparation to challenge your explanation, then repeat it unaided. Ask for a counterexample rather than accepting a fluent answer. Your final response should identify a bottleneck, a measurement, a bounded change, and a result you would verify—not merely say that Node.js is fast because it is asynchronous.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Does async make CPU-heavy JavaScript non-blocking?
No. Synchronous computation in an async function still occupies its executing thread. Profile the work and consider reducing, partitioning, or offloading it appropriately.
Should every failed request be retried?
No. Retry safety depends on the operation, failure, deadline, and idempotency. Unbounded retries can amplify an outage.