Ramp Interview Process & Questions

Ramp interviews almost never use textbook algorithm puzzles. Nearly every round is a small, realistic build: a banking or file-storage system that grows level by level, a crawler that must survive 503 and 401 responses, a recurring-charge detector with no definition of "recurring." Speed, correctness and how you handle ambiguity without help are graded together. Interviewers are often close to silent, and several candidates who passed every test were still rejected. A dedicated AI-assisted coding round, plus questions about your AI workflow in most conversations, sets the loop apart.

This guide breaks down each stage of the Ramp interview, what interviewers evaluate in each round, and how to prepare, with questions candidates were actually asked.

Verified: Based on 21 candidate-reported interview experiences, cross-checked against recent public accounts.

Ramp interview process

The order of the stages is stable, but the content depends on the track. Backend and full-stack candidates get simulation-style online assessments and HTTP-heavy live coding. Frontend candidates get a React and DOM assessment. A typical funnel runs from an online assessment to a 45–60 minute technical screen, then a virtual onsite of three to five rounds totaling about four hours. Candidates usually describe a few weeks from application to decision, though some recruiter-led processes took about two months.

New grads are screened mainly on the progressive assessment and practical coding. Experienced candidates get a heavier architecture round that pairs a project deep dive with an unannounced design prompt, and since many postings span several levels, the loop itself often sets the level.

Here's what the interview process can look like:

• Online assessment: A timed exercise, usually CodeSignal. It is either a 45-minute single simulation problem or a 90-minute build in four levels. Frontend candidates get a React and DOM version instead.
• Recruiter screen (sometimes with an async video screen): A short call about background, why Ramp, and how you use AI. Some candidates also record a values video.
• Technical phone screen: 45–60 minutes of practical coding with an engineer, such as scraping with retries, flight-history lookups, or a cache extended in stages.
• Practical coding rounds (onsite): One or two live builds, such as a URL maze over HTTP, recurring-transaction detection, a flight tracker with pytest tests, or a spreadsheet with formulas.
• AI-assisted coding round (onsite): A data-reconciliation task done with AI tools allowed. It is graded on the rules you set and how you verify the generated code.
• Architecture round (onsite): A project deep dive followed by a surprise design question.
• Behavioral and hiring manager interview (onsite): Motivation, values, and your most impactful project, with follow-up questions that keep digging.

Tip: Assume every live round is a working-software exercise. Get a running baseline within the first third of the time, then add error handling. Candidates who started with a polished design ran out of time on the edge cases that actually decided the round.

Online assessment

Most software funnels open with a CodeSignal link, often within days of a cold application, with about three days to start. It comes in two shapes. The first is a single 45-minute problem, such as a per-IP sliding-window rate limiter over time-sorted input, or a simulation computing final balances and cashback across bank accounts. The logic is simple; the difficulty is a long statement full of conditional rules that are easy to misread.

The second shape is a four-level build, about 90 minutes long, where each level unlocks only after the previous one passes. Reported subjects are a recipe manager, an in-memory banking system (transfers, payments, account merges), cloud file storage with per-user capacity, and a task manager over a four-level nested file system. Later levels add the same features each time: case-insensitive uniqueness, search sorted by one key descending with an ascending tiebreaker, owner-only edits, quotas, compress and decompress operations that must do nothing when repeated, and immutable version history where a rollback adds a new version. The grade is correctness, not runtime, and a shell command runs each level's tests.

Frontend candidates get a 90-minute assessment instead: a custom query selector that walks a nested DOM object to find a hidden URL, a playable Wordle clone in React, and a final step that fetches an answer from that URL and submits it. Another version tested hooks bugs (stale closures, wrong dependency arrays, missing list keys), browser-versus-Node differences, and tests that failed on missing browser globals.

Interviewers evaluate:

• Data model foresight: A store keyed by ID with indexes, chosen in the first ten minutes, absorbs ownership, history and quotas without a rewrite.
• Spec fidelity: Cashback conditions, case-insensitive comparisons, capacity math on copy and compress, and a task completed exactly at its deadline (not overdue) are where hidden tests fail.
• Harness awareness: One file-replacement task shipped tests whose import syntax didn't match the module system the runner expected. Another frontend candidate built all three parts and still failed tests that weren't clearly documented.
• Duplicate handling in Wordle: Letter feedback when a guess repeats a letter is the classic logic trap.

Practice a four-level simulation against a 90-minute timer, and plan the model for level four before you write level one.

Note: Passing does not guarantee you advance. An Applied AI Engineer candidate finished in about 25 minutes and was rejected the same day by automated pre-screening, and a software engineer who passed every test early was also rejected.

Sample questions for the online assessment

Here are some questions reported by recent candidates:

• Build a recipe manager with case-insensitive unique names, ingredient search, owner-only edits, and version history with rollback.

• Implement per-user cloud storage with copy, prefix-and-suffix search, and compression that changes the user's free space.

• Build a React Wordle clone with correct duplicate-letter feedback, then fetch and submit a flag from a URL hidden in a nested DOM object.

• Recipe Manager

• Cloud Storage System

• Rate Limiter by IP Address

• Frontend Hidden URL and React Wordle

Recruiter screen

The recruiter call is short and conversational: background, why Ramp, and increasingly how AI fits into your daily engineering. Some candidates also record a short async values video. Recruiters sometimes preview a later round precisely; one candidate was told the AI-assisted round would involve data reconciliation, and it did.

Interviewers evaluate:

• Builder signal: Concrete things you shipped, and how fast, matter more than titles or where you trained.
• AI fluency: What you hand off to coding assistants, and how you check what they produce.
• Motivation: A specific reason for Ramp's product area, such as cards, bill pay, travel or finance automation, rather than general excitement about fintech.

Ask the recruiter directly what each onsite round covers, and treat any hint as a study guide.

Sample questions for the recruiter screen

Here are some questions reported by recent candidates:

• Tell me about yourself, and why Ramp?

• How do you use AI in your daily work, and has it changed how you code?

• How do you keep up with new technologies?

• Async Video Behavioral Screen

Technical phone screen

The screen is 45–60 minutes with an engineer, practical rather than algorithmic. Recurring prompts: scrape endpoints with retry logic, checking status and body before parsing JSON; walk a graph of URLs whose response format is deliberately vague; find a user's airport at a timestamp from flight records (repeated across many months); and an LRU cache extended to generate keys for arbitrary arguments and recover from crashes with a write-ahead log.

Interviewers differ on details, so ask: one pushed for a high retry count with no backoff, while an onsite interviewer wanted a delayed retry on 503. Screeners are often nearly silent. One candidate solved a nearest-flight binary search, clarified the tie rule unprompted, tested boundaries, and was still rejected without feedback.

Interviewers evaluate:

• Exploration before assumption: On the URL-graph prompt, the interviewer wanted the response format probed, not a known solution recited.
• Boundary semantics: Is the user at the departure airport at the exact departure time? What does a query return mid-flight, before the first flight, or after the last one?
• Defensive I/O: Never parse a body as JSON before confirming the status code and content.
• Self-driven testing: Running your own examples and stating complexity unprompted, because the interviewer may never ask.

Practice two or three HTTP-driven problems end to end in Python, narrating every assumption out loud.

Tip: On the flight problem, state the timeline convention before coding: at the departure airport until departure, in transit until arrival, at the arrival airport afterward. Then build the lookup as a sorted search per user.

Sample questions for the technical phone screen

Here are some questions reported by recent candidates:

• Given flights with airports, times and user IDs, return where a user is at a given moment, including in-transit gaps and exact boundary times.

• Scrape a set of endpoints with retries, inspecting each response before parsing it as JSON.

• Traverse a graph of linked URLs with deliberately vague responses, handling redirects and auth status codes.

• User Flight Location Tracker

• Track Users From Flight History

• URL Maze Traversal

Practical coding rounds

Onsite coding rounds run about 60 minutes in your own environment. In the URL maze, each GET returns JSON with links to neighbors and sometimes an exit key; you find the shortest path with BFS, retry 503 responses after a delay, and build an Authorization header on 401. One interviewer told the candidate to favor speed over elegance: traversal first, error handling later.

The recurring-transactions prompt is deliberately open-ended: given date, merchant, amount and currency, decide which charges recur. The work is in gap and amount tolerances (daily, weekly, roughly monthly) and in excluding frequent small purchases like transit fares. Other builds are a spreadsheet with formulas and dependent cells, and a flight tracker (user with the most flights, location by binary search) with helpers imported from other folders and pytest tests written live.

Interviewers evaluate:

• Problem scoping: For recurring transactions, agreeing on definitions and thresholds with the interviewer before coding. One candidate's small-amount heuristic was immediately challenged with the case of a $5.99 subscription.
• Operational discipline: One rejected candidate had correct BFS but flooded the terminal with debug output and missed the exit key in a response until the interviewer pointed it out.
• Real-world date handling: Varying month lengths, weekends and multiple currencies are part of the problem, not extras.
• Python fluency beyond algorithms: Imports across folders, pytest, and datetime handling are graded material.

Rehearse each of these builds under a 60-minute timer, logging responses selectively instead of printing everything.

Sample questions for the practical coding rounds

Here are some questions reported by recent candidates:

• Find the shortest path to the exit of a maze explored only through HTTP, retrying on 503 and building an auth header on 401.

• Detect recurring charges from raw transactions, separating subscriptions from frequent small purchases.

• Implement a flight tracker (most flights per user, location at a time) with pytest tests across a multi-folder project.

• Build a spreadsheet whose cells hold formulas referring to other cells.

• Detect Recurring Transactions

• Find an Exit in a URL Maze

• Design a Spreadsheet with Formula Evaluation

• Spreadsheet String Concatenation with Dependent Cells

AI-assisted coding round

In the newest onsite format, one round lets you use AI tools openly while the interviewer watches. The reported task is data reconciliation: several sources describe the same entities with slightly different fields, and you decide what counts as a match, set thresholds, and handle conflicts and missing values. The signal is the rules you choose and the AI mistakes you catch, not typing speed.

Interviewers evaluate:

• Spec ownership: You define the matching keys and fuzziness thresholds. The assistant does not.
• Verification: Targeted tests and spot checks on generated code, especially for near-duplicates and conflicting fields.
• Decomposition: Breaking the task into normalize, block, match and merge steps that the tool can implement one at a time.

Practice a reconciliation task with your usual assistant, writing the tests yourself before accepting any generated code.

Note: This round grades the opposite of what many candidates practice. Pasting the prompt into the assistant and accepting the result shows no judgment. Writing the rules and the tests yourself, and correcting the tool, is the passing pattern.

Sample questions for the AI-assisted coding round

Here are some questions reported by recent candidates:

• Reconcile records from multiple sources that describe the same entity with slightly different fields, defining match logic, thresholds and edge cases.

• Clean inconsistent listing data where structured fields disagree with free-text descriptions.

• Reconcile Multiple Data Sources

• Correct Bedroom Counts from Descriptions

Architecture round

This round usually starts with a project you are proud of, then switches to a design question; one candidate who prepared only the deep dive was caught off guard. Prompts include counting website visits over the last minute, batching mixed GPU requests, a hotel-booking aggregator over slow third-party APIs, and an evolving banking system (ranking accounts by outgoing value, scheduled payments with cashback and status, merging two accounts' balances and histories).

On the hotel aggregator, discussion moved from caching to its consistency costs (TTL versus write-through versus event invalidation), then to the p99 latency of the slowest hotel API, then to pre-booking room blocks for instant confirmation. The rejected candidate concluded the key framing came too late: an aggregator that owns no inventory faces different constraints from a hotel's own booking system.

Interviewers evaluate:

• Framing first: Naming who owns the data and where latency comes from before drawing components.
• Trade-off depth: Accuracy versus cost in time-window counters, and freshness versus speed in caches.
• Evolvability: How each new banking feature changes the schema, including idempotent scheduled payments and conflicts during an account merge.
• Project ownership: In the deep dive, clear decisions you made yourself, with results.

Prepare one project story in depth plus two or three applied designs built around time windows and external dependencies.

Sample questions for the architecture round

Here are some questions reported by recent candidates:

• Count visits to a website over the past minute.

• Design an Expedia-style hotel aggregator that stays fast although every search fans out to dozens of slow hotel APIs.

• Extend a banking system with cashback-earning scheduled payments, status lookups, and account merging.

• Count Visits in One Minute

• Design Hotel Booking System

• Banking System with Payments and Account Merging

• Design Access Management System

Behavioral and hiring manager interview

The values conversation, often with the hiring manager, is friendly but persistent; follow-ups continue until they reach a real decision. Topics include why Ramp, a technology you learned recently and how you would teach it to an intern, how AI changed your coding, your proudest project, and teamwork, conflict and ambiguity. One screen was purely behavioral, with no code.

Interviewers evaluate:

• Velocity: Evidence that you ship quickly and iterate, consistent with a culture built around speed.
• Ownership: Problems you took on beyond your assigned scope, and outcomes you can measure.
• Clarity of explanation: The teach-an-intern prompt checks whether you can make a hard topic simple.
• Self-awareness: Honest accounts of failure and conflict, not a polished success story.

Prepare five or six recent stories (a fast ship, a failure, a conflict, a hard technical call, and your AI workflow) with the reasoning behind each one.

Sample questions for the behavioral and hiring manager interview

Here are some questions reported by recent candidates:

• Describe a technology you learned recently, and how you would explain it to an intern.

• Which project are you proudest of, and why?

• Tell me about a conflict with a teammate and how it was resolved.

• What Project Are You Proudest Of?

• From Take-Home Script to Production: Python Trade-offs and Hardening a Data Job

How Ramp makes hiring decisions

The team decides after the full loop, and in-round feedback is minimal. Several rejections followed rounds that felt solid, so polish, communication and fit count alongside correctness. Some applicants are filtered automatically before any human review. Postings often consider candidates for multiple levels, with pay set by the level hired, so the loop places you. No reapplication cooldown is published; ask your recruiter.

How to prepare for the Ramp interview

1. Drill the four-level simulation: Build banking, storage, recipe and task managers against a 90-minute timer, with ownership, quotas and history planned from level one.
2. Build an HTTP crawler harness: BFS over live endpoints with retries on 503, auth headers on 401, and status checks before parsing JSON.
3. Scope out loud first: For open prompts like recurring charges, propose definitions, tolerances and false-positive filters before coding.
4. Sharpen practical Python: Imports across folders, writing pytest tests live, and datetime boundary handling.
5. Rehearse AI-assisted work honestly: Set the matching rules yourself, write tests first, and correct the tool where it is wrong.
6. Prepare a deep dive plus a surprise design: One proud project and two applied designs around time windows and slow external APIs.
7. Frontend candidates: Rebuild Wordle in React with correct duplicate-letter handling, and review stale closures, dependency arrays and browser-only globals.

About working at Ramp

Ramp builds corporate cards, bill pay, expense management, travel and other finance-automation products from a New York headquarters, working hybrid. Teams are organized around business outcomes, with product, design and engineering in one technical organization, and the company openly prioritizes velocity and what you have built over where you trained. Engineers typically work across the stack in Python (Flask) and PostgreSQL on the backend and TypeScript and React on the frontend, with Kotlin used for Android.

Ramp hires engineers across its product and platform groups. Teams include:

• Credit: Systems behind the corporate card's credit and risk decisions.
• Banking: Banking and money-movement products.
• Ramp Travel: Business travel booking.
• Agent Developer Platform: APIs for developers and agents building on Ramp.
• Data Platform and Reporting: Data infrastructure and financial reporting.
• Production Engineering: Infrastructure reliability and scale, owned jointly with product teams.

Experience and education requirements

University-grad postings ask for a computer science or related degree and shipped projects rather than years of professional experience. Experienced roles start at about one year of software experience, and senior and staff roles expect a record of shipping at scale. Strong Python, Go or Java is common on backend postings, and JavaScript or TypeScript with React on frontend postings.

FAQs about the Ramp interview

How long does the Ramp interview process take?

Typically a few weeks from application to decision. Assessment invitations arrive within days, with a short window to start. Some recruiter-led processes stretched to about two months.

What is the hardest round of the Ramp interview?

The open-ended practical rounds, recurring-transaction detection and the URL maze, produce the most reported rejections, followed by the surprise design question in the architecture round.

Which language should I use?

Use the language you are fastest in. Python is the most commonly reported, and the flight-tracker round expected pytest. Frontend assessments require React and plain DOM APIs without third-party libraries.

How much does a Ramp software engineer make?

Posted base salaries give a guide. A New York backend new-grad role listed $142K–$175K base, product-team roles listed ranges of about $160K–$275K, and a staff backend role listed about $234K–$275K. Every range is base pay only, with target equity on top.

Is the Ramp interview remote?

Yes. The onsite is reported as a virtual loop, and the assessments are completed remotely.