← Back to Directory

Ramp interview notes, page 2 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

Apr 2026
Ramp SWE interview with a stock trading problem that looks like the classic buy-low-sell-high puzzle but has a few wrinkles around unsorted dates and multiple symbols. Pretty clean problem overall, though the edge cases around same-date trades and symbols with only one record are the kind of thing that'll trip you up if you're not careful.
  • Given an unsorted log of stock trades, each with a date, ticker symbol, and price, find the maximum profit from a single buy-then-sell transaction where the sell date must be strictly later than the buy date and both trades share the same symbol. Return 0 if no profitable transaction exists.

“My first instinct was to just sort everything by date and run the standard min-so-far sweep, but then I realized you have to track each symbol separately since you can't buy AAPL and sell GOOG.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Apr 2026
Ramp SWE interview with a data-heavy coding problem. The question was more interesting than I expected but the edge cases took a while to think through cleanly.
  • You have a dataset of flight records (user ID, flight ID, departure time, arrival time, origin, destination). Given a query timestamp, return where each user is at that moment. A user is in-flight if the timestamp falls within a flight's window; otherwise they're at the airport from their most recently completed flight.

“Spent the first few minutes just making sure I understood the 'otherwise' case correctly.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Apr 2026
Ramp SWE interview that went deep on system design for a task scheduler. The problem started simple and kept growing, which I was not fully prepared for.
  • Design a task scheduler with add, update, get, search, and sorted listing operations. Then extend it to support user quotas and time-based task assignments.
  • How would you handle the case where the same task is assigned to the same user multiple times, or where the assignment window is zero-length or already expired?
  • Implement get_user_tasks(timestamp, user_id) that returns all task IDs actively assigned to a user at the given timestamp.

“The base scheduler part felt fine, I rattled off the API shape pretty quickly.”

View Post

Ramp·Software Engineer·Onsite - System Design / Architecture

Apr 2026
Did a system design-style coding round at Ramp for a software engineer role where they asked me to build a small calendar app from scratch. More nuanced than it sounds, lots of clarifying questions to work through before writing a single line.
  • Design and implement a small calendar application that supports creating, editing, and deleting events, with clean state management and unit tests.
  • How would you redesign the event model to support recurring events?
  • How would you add availability search across a calendar?
  • How would you extend this to support multiple users sharing a calendar?
  • If you added persistence later, how would that change how you write and structure your tests?

“I jumped straight into coding and only realized halfway through that I hadn't asked whether overlapping events were allowed.”

View Post

Ramp·Frontend Engineer·Technical Phone Screen

May 2026
Frontend engineering round at Ramp, one coding problem focused on React animation behavior. Pretty niche stuff, not your typical leetcode grind, which I appreciated but also wasn't fully ready for.
  • Build a React component that reveals a string character by character using a typewriter animation with setTimeout or setInterval inside useEffect. The animation must run exactly once for the component's lifetime, even under React strict mode's double-invocation behavior.

“This is where I tripped up first.”

View Post

Ramp·Software Engineer·Onsite - System Design / Architecture

May 2026
Ramp software engineer interview built around a multi-level OOP banking simulation. Each level unlocked new operations and you had to extend your design without breaking what came before. Pretty grueling if you're not used to that incremental style.
  • Design an object-oriented banking system where accounts can be created, balances queried, money transferred between accounts, payments recorded, and two accounts merged together.
  • How would you modify the design to support scheduled or future-dated payments?
  • If the system needed to support cashback or rewards on payments, how would that affect your ledger design?
  • After merging two accounts, how would you support the old account id still being usable as an alias?
  • How would your design change if operations needed to be thread-safe and support concurrent access?

“The merge part is what got me.”

View Post

Ramp·Software Engineer·Technical Phone Screen

May 2026
Ramp SWE interview that went deep on a custom task scheduler design, specifically around adding completion tracking and overdue detection to an already-complex system. The design space was bigger than it looked at first glance.
  • You're given a task scheduler with add, update, get, search, and list operations, plus user quotas and time-based task assignment. How would you add a complete_task operation that marks an active assignment as done, frees up the user's quota slot immediately, and returns false if the assignment doesn't exist or isn't currently active?
  • How would you implement get_overdue_assignments(timestamp, user_id) to return all task IDs for a user where the finish time has passed and the task was never completed before that deadline? How do you make this efficient?
  • How does the assignment state model work across the full lifecycle? Walk through how you'd represent pending, completed, and overdue states, and how get_user_tasks should behave given that overdue assignments are neither active nor completed.

“The quota-freeing part is what tripped me up.”

View Post

Ramp·Software Engineer·Take-home Assignment

May 2026
Ramp gave me a take-home coding challenge to build a mini Wordle clone in React, no styling needed, just functional. Pretty reasonable scope for a frontend-leaning eng role, though the duplicate letter handling requirement is where things get interesting.
  • Build a simplified Wordle-style game as a small React app. The secret word is 5 letters, the player gets 6 attempts, and each guess must show per-letter feedback (correct position, wrong position, or absent). Duplicate letters must be handled correctly.

“The duplicate letter logic is what actually trips people up here.”

View Post

Ramp·Software Engineer·Technical Phone Screen

May 2026
Ramp technical phone screen for a software engineer role. One meaty design-and-implement question that took up the whole session, basically a mini system design disguised as a coding problem.
  • Design and implement an in-memory storage engine for a multi-level warehouse where items have weights and expiration times. Support a store operation that places items on the topmost available level, and a retrieve operation that finds the heaviest item from the topmost level that is at least half full after expiring stale entries.

“This looked like a coding question but it was really a system design problem crammed into a class implementation.”

View Post

Ramp·Software Engineer·Onsite - Coding / Algorithms

May 2026
AI-assisted coding round at Ramp for a software engineer role. The whole thing was a single deep-dive problem on reconciling person records across messy data sources, and they expected you to think out loud about every stage of the pipeline, not just write code.
  • Design and implement a system to reconcile person records from multiple data sources with missing values, inconsistent formatting, and conflicting information. Your solution should decide if two records refer to the same person, group matching records, produce a merged canonical record, and leave unmatched records separate.
  • How would you normalize fields like email, phone, address, and name before doing any matching?
  • Comparing every pair of records is O(n^2). How would you avoid that at scale?
  • Once you have pairwise match decisions, how do you group records that all refer to the same person?
  • When grouped records disagree on a field value, how do you decide what goes in the canonical merged record?
  • How would you validate the quality of your matching? What metrics matter and why?
  • Since this is an AI-assisted round, walk us through how you used the AI tool, what you verified yourself, and where you chose not to trust it.
  • How would you convert this from a batch job into an incremental system where new records stream in and must be matched against millions of existing records without reprocessing everything?
  • How would you detect and stop runaway over-merging, where weak transitive edges collapse many distinct people into one giant group?

“This is a deceptively large problem and I underestimated how much they wanted you to break it into stages before writing a single line.”

View Post