Dropbox·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

May 2026

Summary

Dropbox software engineering interview with a coding question centered on payment status tracking. The problem was more nuanced than it first appeared, mostly around getting the state machine right.

Questions Asked (1)

Implement a payment system where each pay() call returns a unique payment ID, and a getPaymentStatus(paymentId) function returns the current status of that payment. Define the full status enum (e.g. in-progress, cashback received, invalid ID) and make sure status transitions work correctly as time passes and pending cashbacks eventually settle.

System DesignAPI & IntegrationsTechnical Trade-offs

Author's notes

The enum definition part tripped me up more than the code itself.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and defining the payment status enum with all possible states and transitions. Then design the API and data model, ensuring unique payment IDs and correct status updates over time, including handling pending cashbacks and invalid IDs. Finally, discuss trade-offs and potential optimizations.

Pro tip: Explicitly call out idempotency and how you'd handle duplicate pay() calls to avoid double-charging, as this is a common real-world payment system concern. Also, mention that you'd use a time-based simulation or scheduled job to transition statuses, showing awareness of asynchronous processing.

1. Clarify Requirements and Define Status Enum

Ask clarifying questions about expected payment lifecycle, cashback timing, and error cases. Define a complete status enum (e.g., IN_PROGRESS, CASHBACK_PENDING, CASHBACK_RECEIVED, INVALID_ID, FAILED) and specify valid transitions.

2. Design API and Data Model

Define pay() to return a unique payment ID (e.g., UUID) and getPaymentStatus(paymentId) to return the current status. Choose a storage model (in-memory map, database) that supports efficient lookups and updates.

3. Implement Status Transitions and Time Handling

Describe how statuses change over time: e.g., after pay(), status is IN_PROGRESS; after a delay, it becomes CASHBACK_PENDING; after cashback settles, CASHBACK_RECEIVED. Use timestamps or scheduled tasks to trigger transitions.

4. Handle Edge Cases and Invalid IDs

Ensure getPaymentStatus returns INVALID_ID for unknown IDs. Handle duplicate pay() calls idempotently, and consider concurrency issues if multiple requests update the same payment.

5. Discuss Trade-offs and Scalability

Talk about trade-offs: in-memory vs. persistent storage, synchronous vs. asynchronous status updates, and how the design scales with many payments. Mention potential use of message queues or cron jobs for cashback settlement.

Key Points to Mention

Unique payment ID generation (UUID, database auto-increment, etc.)
Complete status enum with clear transitions and time-based changes
Idempotency of pay() to prevent duplicate payments
Handling invalid payment IDs gracefully
Asynchronous processing for cashback settlement (e.g., scheduled jobs, message queues)
Data consistency and concurrency control (e.g., locking, atomic updates)

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