Meta·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

Jun 2026

Summary

Meta SWE interview with a multi-level coding problem that built up into a full money transfer system. The last level was the most interesting, requiring pending transfers with expiration and refund logic.

Questions Asked (1)

Design a money transfer system between users where the sender initiates a transfer (deducting the amount immediately and creating a pending transfer with an expiration), the recipient must accept before it expires to receive the funds, and any unaccepted transfers are automatically refunded. Only completed (accepted) transfers should count toward transaction totals.

System DesignData ModelingTechnical Trade-offs

Author's notes

This is where the problem got genuinely tricky.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a state machine for transfers with clear transitions (pending, completed, expired, refunded). Focus on data consistency and atomicity for balance updates and transfer state changes, using transactions or distributed locking. Discuss how to handle expiration and refunds reliably, and how to compute transaction totals only for completed transfers.

Pro tip: Emphasize idempotency and exactly-once processing for transfer initiation and expiration handling to avoid double-spending or double-refunding, which is critical in financial systems.

1. Clarify Requirements and Scale

Ask about expected throughput, latency requirements, consistency needs, and whether the system is centralized or distributed. Confirm that only completed transfers count toward totals and that refunds are automatic.

2. Design Data Model and State Machine

Define entities: User (balance), Transfer (id, sender, recipient, amount, status, expiration, timestamps). Specify states: PENDING, COMPLETED, EXPIRED, REFUNDED, and allowed transitions.

3. Ensure Atomicity and Consistency

Use database transactions or distributed transactions to atomically deduct sender balance and create pending transfer. For acceptance, atomically update transfer status and credit recipient. For expiration, atomically refund sender and mark transfer expired.

4. Handle Expiration and Refunds

Implement a reliable mechanism (e.g., scheduled job, delayed queue, or TTL) to detect expired transfers and trigger refunds. Ensure idempotency to avoid duplicate refunds.

5. Compute Transaction Totals

Maintain aggregates (e.g., total completed transfers per user) by updating them only when a transfer transitions to COMPLETED. Use event sourcing or materialized views for scalability.

Key Points to Mention

Idempotency keys for transfer initiation and expiration handling to prevent duplicate operations.
Use of database transactions with row-level locking or optimistic concurrency control to maintain balance consistency.
State machine design with clear transitions and validation to prevent invalid state changes.
Reliable expiration mechanism: scheduled jobs, message queues with delay, or database TTL with a sweeper process.
Scalability considerations: sharding by user ID, using distributed locks or consensus for cross-shard transfers.
Monitoring and auditing: logging all state changes and providing reconciliation for failed or stuck transfers.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.