Interview Question
When should an API call stay synchronous, and when should work become asynchronous?
What the interviewer is testing
- Requirement clarification
- Latency and UX reasoning
- Failure and retry thinking
Real-World Sample Answer
I would approach “When should an API call stay synchronous, and when should work become asynchronous?” by clarifying the requirements first, then using these considerations: in a real interview, i would start by clarifying the problem and assumptions. for “when should an api call stay synchronous, and when should work become asynchronous?”, i would start with user-facing latency and completion requirements, then consider retries, partial failure, and back-pressure, and explain how the caller learns completion status. i would close by explaining the trade-offs, operational implications, and what i would verify after launch.. I would state my assumptions and defend the trade-offs rather than presenting the choice as universally correct.
What a Strong Answer Should Cover
In a real interview, I would start by clarifying the problem and assumptions. For “When should an API call stay synchronous, and when should work become asynchronous?”, I would start with user-facing latency and completion requirements, then consider retries, partial failure, and back-pressure, and explain how the caller learns completion status. I would close by explaining the trade-offs, operational implications, and what I would verify after launch.
Common Mistakes
- Calling everything asynchronous because it scales
- Ignoring user experience
- Choosing a queue without explaining delivery and retry behavior
Interviewer Follow-ups
- What assumptions would you clarify before committing to the design?
- What changes if the scale, reliability target, security requirement, or budget changes?
- What is the biggest failure mode in your proposed approach?