Ramp·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

Apr 2026

Summary

Ramp coding screen for a software engineer role, basically a from-scratch OOP design question around a banking system. Pretty straightforward concept but the edge cases pile up fast and that's clearly where they're separating candidates.

Questions Asked (1)

Build a simple banking system from scratch that supports creating accounts, depositing funds, and transferring between accounts. Each operation takes a timestamp. What data structures do you use and how do you handle edge cases like missing accounts, insufficient balance, or a transfer to the same account?

Algorithms & Data StructuresSystem DesignTechnical Trade-offs

Author's notes

I went straight for a dict keyed by account ID and stored balance as the value, which was fine.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and assumptions, then propose a clean data model using hash maps for accounts and a transaction log for auditability. Walk through each operation, explicitly handling edge cases with appropriate error responses, and discuss trade-offs like concurrency and idempotency.

Pro tip: Mention that timestamps can be used to detect and reject out-of-order operations or to implement optimistic concurrency control, showing awareness of real-world banking constraints.

1. Clarify Requirements and Assumptions

Ask about expected scale, concurrency needs, persistence, and whether timestamps are client-provided or server-generated. State your assumptions clearly.

2. Design Data Structures

Propose a hash map (dictionary) for accounts, mapping account ID to an account object containing balance and metadata. Optionally, maintain a transaction log for auditing.

3. Implement Core Operations

For each operation (create, deposit, transfer), outline the steps: validate inputs, check account existence, verify sufficient balance, update balances atomically, and record the transaction with timestamp.

4. Handle Edge Cases

Explicitly address missing accounts (return error), insufficient balance (reject transfer), same-account transfer (no-op or error), and invalid timestamps (reject if older than last operation).

5. Discuss Trade-offs and Extensions

Talk about concurrency (locks vs. optimistic), idempotency (using timestamps or transaction IDs), and potential improvements like persistent storage or distributed systems.

Key Points to Mention

Use a hash map for O(1) account lookup and updates.
Maintain a transaction log for auditability and debugging.
Validate timestamps to ensure monotonicity and prevent replay attacks.
Handle same-account transfer as a no-op or error to avoid unnecessary processing.
Consider concurrency control (e.g., locks or optimistic concurrency) for thread safety.
Discuss idempotency of operations, especially with client-provided timestamps.

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