← Back to Directory

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

Jun 2026
Ramp SWE interview had a web crawling problem that started reasonable and then kept getting messier with each follow-up. The base question was fine but the auth key chaining bit caught me off guard.
  • Given a starting URL for a web-based maze where each URL is a room, write a function that performs BFS or DFS over HTTP requests to find whether any reachable room is an exit. Return the exit URL or None if no exit exists. You must handle cycles.
  • Extend your maze-solving function to handle 503 responses with limited retries, and 401 responses by capturing authorization keys from successful room responses and forwarding them in subsequent requests.

“The cycle-handling part I got immediately, just a visited set on URLs.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Ramp SWE interview focused on extending a task scheduler system with search and sorted listing operations. The design discussion got into data structure tradeoffs pretty quickly, which I wasn't fully prepared for.
  • You're given a task scheduler with add, update, and get operations. Each task has a name, a non-negative integer priority, and a sequential ID. Implement a search_tasks function that takes a name substring filter and a max_results limit, returning matching task IDs sorted by priority descending and then by creation order ascending.
  • Implement a list_tasks_sorted function that returns up to a given limit of task IDs sorted by priority descending, then creation order ascending. What data structure would you use to make this efficient, and what are the asymptotic costs of each operation?

“The sorting part is where I tripped up initially.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Ramp had me do an AI-assisted coding round centered on a gnarly data reconciliation problem. The scope was broad enough that you had to define your own matching rules before writing a single line, which honestly felt more like a design session that happened to end with code.
  • You're given records about the same real-world entities coming from multiple upstream systems with inconsistent identifiers, schemas, and field formats. Design and implement a matching and reconciliation system that merges these into unified entity records.
  • How do you think about precision versus recall tradeoffs in your matching logic, and when would you tune one over the other?
  • How do you ensure your reconciliation pipeline is idempotent so re-running it on the same input doesn't produce duplicate or inconsistent results?
  • How would you scale this matching logic to handle very large datasets efficiently?

“This one took me a few minutes just to scope.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Ramp SWE interview had a progressive OOP design problem built around a recipe manager, four levels deep, each one adding more complexity on top of the last. It's the kind of problem that feels manageable at first and then quietly snowballs.
  • Implement the basic CRUD operations for a RecipeManager class: adding a recipe with a unique name, retrieving it by ID, updating its fields, and deleting it.
  • Implement a search function that returns all recipe IDs containing a given ingredient, sorted by ingredient count ascending and then by recipe ID as a tiebreaker. Also implement a general list function that sorts all recipes by either name or ingredient count.
  • Add a user system where any registered user can edit any recipe, with the same name-uniqueness rules enforced and appropriate failure cases for nonexistent users or recipes.
  • Add version history to recipes: every successful edit or update appends a new version entry. Implement a function to retrieve all versions and a rollback function that restores a prior version as a new version entry, with name conflict checks on rollback.

“Level 1 felt fine.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Video screen for a software engineering role at Ramp, covering a mix of personal background, technical learning, and some AI-in-the-workflow stuff. Six prompts total, felt more like a recorded async thing than a live call.
  • Tell us about yourself and why you want to work at Ramp specifically.
  • Describe a time you had to learn a new technology. What was that process like?
  • How would you explain that same technology to a new intern who has no context?
  • How has AI changed the way you write code day to day?
  • Walk us through a recent project you worked on.
  • How do you keep up with new technologies and trends in software engineering?

“The 'why us' part is where I always fumble a little.”

View Post

Ramp·Software Engineer·Onsite - System Design / Architecture

Jun 2026
Interviewed at Ramp for a software engineering role and got a system design question that was less about architecture diagrams and more about writing real client logic against a live API. Interesting format, not what I expected.
  • You're given an API that returns the next location to visit in a maze. Starting from some initial position, design the client logic to repeatedly call the API until you reach the destination, including termination conditions, error handling, and tests.
  • How would you make the maze traversal resumable if the process crashes midway?
  • How would you handle the case where multiple paths through the maze are possible and you want to explore them concurrently?
  • How would you observe and measure the latency and failure rate of the API calls during traversal?

“This one took me a minute to parse.”

View Post

Ramp·Software Engineer·Onsite - Behavioral / Leadership

Jun 2026
Behavioral round at Ramp for a software engineer role. Just one question but it had a lot of surface area to cover.
  • Walk me through a project you're most proud of. Cover the problem and context, your specific role and contributions, trade-offs you made, the outcome, and what you'd do differently in hindsight.

“This question sounds open-ended but it's actually a lot to pack in.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Ramp SWE technical screen that involved live API work, error handling, and some painful debugging. Ended a few minutes early with an unresolved bug, which probably didn't help the impression.
  • Given a URL that may return various HTTP error codes, write code to handle responses like 503 and 401 gracefully and retry or surface errors appropriately.
  • After switching to a different endpoint, some responses contain a key embedded in the output. Extract that key, construct the appropriate headers, and use them to make a subsequent authenticated request.

“That part went fine, no real issues.”

View Post

Ramp·Software Engineer·Technical Phone Screen

Jun 2026
Frontend coding round at Ramp for a Software Engineer role. They had me build a Tic-Tac-Toe game from scratch in a single screen, which sounds trivial until you're mid-implementation and the interviewer starts tacking on new requirements. State management and testability were clearly the focus, not the visuals.
  • Build a single-screen Tic-Tac-Toe game that handles player turns, detects wins and draws, prevents invalid moves, and is structured to be easy to test.
  • How would you generalize this implementation to support an NxN board instead of a fixed 3x3?
  • How would you add an AI opponent to this game?
  • How would you persist match history across sessions?
  • How would you prevent unnecessary UI re-renders as the game state updates?

“I jumped straight into the UI and spent the first few minutes laying out the grid before I'd even thought about how to represent game state.”

View Post

Ramp·Software Engineer·Onsite - System Design / Architecture

Jun 2026
System design round at Ramp for a software engineer role. The main problem was building a spreadsheet cell system with formula dependencies, which sounds manageable until you actually start thinking through the update propagation and cycle detection pieces.
  • Design a spreadsheet system where cells can hold literal values or formulas referencing other cells. How do you represent dependencies, handle updates when a cell changes, and detect or reject cycles?
  • How would you extend the design to support cell ranges like A1 through A10 in formulas?
  • How would you make recalculation incremental rather than recomputing everything on each change?
  • How would you safely cache computed cell values, and when would you invalidate the cache?
  • How does your design change if multiple users can edit cells concurrently?

“My first instinct was to just store a map of cell name to value and call it a day.”

View Post