How the interviewer opens it
“Design a programmable SMS platform for businesses. Tenants use an API to send texts and receive texts through telecommunications carriers. The platform also reports delivery status and charges each tenant for use.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Traffic
- Read and write mix
- Segments and carrier limits
- Latency
- Acceptance and consistency
- Delivery and retries
- Tenant charges
- Inbound messages and tenant webhooks
- Retention
- Scope boundaries
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Accept outbound SMS requests and report message status
- Receive inbound SMS and send events to tenant webhooks
- Apply carrier limits and retry rules across tenants
- Record billable use and produce monthly tenant invoices
Usually out of scope
- Number purchase and porting
- Carrier contracts and sender registration
- MMS and campaign tools
- Tax calculation and payment collection
What interviewers ask about
- Carrier capacity and tenant delays
- Carrier limits count SMS segments, not API calls. Shared routes must handle tenant bursts without excessive delay or expired sends.
- Uncertain send results
- A carrier can accept a segment before the connection fails. A resend can create a second text and another carrier charge.
- Message status and tenant events
- Receipts can arrive before send replies or after newer states. Inbound duplicates and failed tenant webhooks create separate delivery obligations.
- Usage and tenant charges
- Carrier acceptance can remain unknown beyond invoice finalization. Late evidence and repeated events must not create missed or duplicate tenant charges.
Common mistakes
- Counts API requests instead of SMS segments when checking carrier limits.
- Treats a carrier timeout as proof that no text left the platform.
- Treats carrier acceptance as proof of handset delivery.
- Bills every retry or receipt as new use.
- Lets one tenant delay every other tenant on a shared route.
- Charges unresolved attempts or changes finalized invoices after late evidence.
The bar by level
- Senior (L5/E5)
- Separates API retries from carrier retries. Enforces segment limits and tenant fairness. Handles uncertain outcomes without blind resend. Prevents duplicate charges and recovers failed tenant webhooks. Applies the stated unresolved-attempt and late-charge policies.
- Staff (L6+/E6+)
- Explains route ownership during failures and regional isolation. Quantifies costs from uncertain sends and duplicate carrier charges. Preserves evidence across content deletion and invoice finalization. Uses backlog age and route capacity to justify overload and recovery rules.