← Back to Directory

Ramp interview notes, page 4 of 7

Small

Most of these Ramp write-ups come from Software Engineers (52), then Frontend Engineers (10). The most reported rounds are the technical phone screen (44), the system design round (8), the online assessment (5) and the behavioral / leadership round (2).

62 interview notes · updated Oct 2026

Ramp·Software Engineer·Technical Phone Screen

May 2026
Ramp software engineering interview with a flight records problem that looks manageable at first but has enough edge cases to keep you honest. Two functions, one input, and a lot of time thinking about how to handle timestamps correctly.
  • You have an unsorted list of flight records, each with departure airport, departure time, arrival airport, arrival time, and user ID. Implement a function that returns the user with the most flight records. If there's a tie, returning any one of them is fine.
  • Using the same flight records, implement a function that takes a timestamp and returns the location or travel status of every user at that point in time. A user is 'unknown' before their first departure, 'in transit' between departure and arrival, and at their last known airport otherwise.

“Pretty straightforward once you stop overthinking it.”

View Post

Ramp·Frontend Engineer·Technical Phone Screen

May 2026
Frontend coding round at Ramp, one question about building a typewriter animation in React. Pretty focused and self-contained, no system design or behavioral stuff from what I could tell.
  • Build a React component that animates a string fetched from an API, revealing it one character at a time at a consistent interval until the full string is displayed.

“The core logic isn't that complicated once you see it.”

View Post

Ramp·Software Engineer·Technical Phone Screen

May 2026
Ramp SWE interview with a graph traversal problem that had a lot of moving parts. The problem itself was interesting but I kept second-guessing the design decisions mid-explanation.
  • You're given a root URL that returns a JSON node in a directed graph. Each node can have outgoing URLs, optional passkeys, and optionally a terminal message. Traverse the graph to find the terminal node while handling 503/504 retries with exponential backoff, skipping 404s as dead ends, collecting passkeys and attaching them as headers on future requests, and avoiding cycles. Return the full path and the terminal payload.

“This one had layers and I didn't pace myself well unpacking them.”

View Post

Ramp·Software Engineer·Technical Phone Screen

May 2026
Ramp software engineer interview with a practical systems/networking problem that's less about clever algorithms and more about whether you can actually wire things together without breaking everything. The problem sounds deceptively simple until you start thinking about retries, cycles, and concurrency.
  • Given a starting URL, recursively follow URLs returned in each HTTP response until you find a response containing the string 'congrats'. Return that URL. How do you implement this, handle errors like 503s, avoid cycles, and test it without a live server?

“The core traversal isn't the hard part.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Ramp coding round for a software engineer role. The whole session was basically one extended design-and-implement question about a banking system, with a twist on ranking accounts by outgoing activity. More algorithmic than I expected for a fintech company.
  • You're building a banking system with CREATE_ACCOUNT, DEPOSIT, and TRANSFER operations. Now add a TOP_ACTIVITY(timestamp, n) query that returns the top n accounts ranked by total outgoing transaction amount, with ties broken alphabetically by account ID. How do you design the data structure to make this efficient, and what's the cost per operation?

“I knew immediately they wanted a heap or sorted set, but I fumbled explaining the key design.”

View Post

Ramp·Frontend Engineer·Technical Phone Screen

Jun 2026
Ramp frontend interview with a pretty unusual DOM traversal problem. Not your typical leetcode grind, felt more like a browser internals quiz wrapped in a coding challenge.
  • A URL is split into individual characters and embedded inside specially nested DOM elements. Write a custom query selector that walks the DOM tree, finds the matching elements using a selector syntax that supports '*' as a wildcard for zero or more characters in element names, and reassembles the characters in order to reconstruct the original URL.

“I did not see this coming.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Ramp technical phone screen for a software engineer role, centered almost entirely on building a web crawler. The problem sounded straightforward but the discussion kept going deeper than I expected, especially around retry logic and content-type handling.
  • Implement a basic web crawler that makes HTTP GET requests to a list of URLs, handles failures with a retry policy, inspects response content types before attempting JSON parsing, and returns parsed results or per-URL errors to the caller.
  • How would you decide on the right retry count, and when is exponential backoff appropriate versus retrying immediately?
  • How do you distinguish between retryable and non-retryable HTTP failures, and how would you test the retry logic?

“I started writing the happy path first and the interviewer let me get through maybe half of it before asking about retries.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Ramp software engineering interview with a graph traversal coding problem that had a few real-world constraints layered on top. The problem looked like a standard BFS/DFS at first glance but the HTTP retry and timeout requirements made it more involved than I expected.
  • Implement a web crawler starting from a root path that uses BFS or DFS to send HTTP GET requests and follow links returned in JSON responses until reaching an exit page. Your solution needs to handle cycles, retry on server errors, and respect timeouts while still guaranteeing completion if a valid path exists.

“The cycle detection part was easy enough, just keep a visited set.”

View Post

Ramp·Software Engineer·Onsite - System Design / Architecture

Jun 2026
System design round at Ramp for a software engineer role, focused on building a hotel availability service like what Expedia runs under the hood. Heavy on caching strategy, supplier integration tradeoffs, and concurrency edge cases. Felt pretty solid on the high-level design but the follow-ups on TTL decisions and last-room contention were trickier than I expected.
  • Design a hotel room availability service for a travel marketplace like Expedia, optimizing for low-latency search reads while keeping booking accuracy high despite external supplier APIs that are slow and unreliable.
  • How would you handle a supplier API going down mid-checkout when the user is about to confirm their booking?
  • How would you decide on TTL values for cached availability data?
  • Two users are looking at the last available room at the same time. How do you prevent both from successfully booking it?
  • How would you monitor for stale availability data being shown to users, and track failed booking confirmations?
  • How would your design change specifically for last-minute bookings in high-demand cities during peak periods?

“This was the core question and it took a while to scope properly.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Ramp SWE interview that went deep into a banking system design problem. The core challenge kept expanding with each follow-up, which I did not fully anticipate going in.
  • Design a banking system with account creation, deposits, transfers, a top-activity ranking by outgoing transaction volume, and a pay operation that schedules a 2% cashback 24 hours after the transaction.
  • Extend the banking system to support merging two accounts: the merged account inherits the combined balance, combined outgoing totals for ranking, and any pending cashbacks originally tied to the absorbed account. Payment status lookups using the old account's payment IDs should still work after the merge.
  • How would you keep the top-activity ranking correct after an account merge, given that the ranking is based on total outgoing transaction amounts?
  • Implement GET_BALANCE so it returns the current balance after applying any cashbacks that are now due, or null if the account does not exist.

“The cashback scheduling part is what tripped me up first.”

View Post