Ramp Interview Process & Rounds

Ramp interview timeline

Few reports give dates, so treat each row as a small sample. No report gives end-to-end dates. After the screen, candidates heard back within a few business days in every report that gives timing, and three candidates who were rejected say they never understood what was missing. In one report a candidate who passed the screen was moved to another team two days later because the original role had been filled.

The Ramp interview process, step by step

1. 1. Online assessment: general roles

   90 minutes in the two reports that give a length; a four-level progressive class problem, sent after applying online (2 reports), at once in one of them. One report calls it an Industry Coding Assessment.

   Four reports describe four levels, each adding methods to the same class, with the next level opening only after the current one passes its tests. Reported themes are a banking system (2 reports), a task manager and a recipe manager. One report's instructions say efficiency is not graded and any code that passes the unit tests is enough, and one candidate says their camera was not on. One candidate says it comes before any resume review, and another passed 500 points after two levels, finished with 800 and was rejected the next day with a note that the team had other candidates. None of the five general assessment reports mentions an interview invitation afterwards, and one candidate says acquaintances with closely related backgrounds skipped the assessment and went straight to later rounds.

   • →Practise four-level class problems on a 90-minute clock, building level one so later levels can extend it. One candidate got the same problem as an earlier report.
   • →Aim for passing tests over efficiency, then move on to the next level.

2. 2. Online assessment: frontend roles

   A small React project; 45 minutes in one report and 90 minutes in another. The one report that names the platform says CodeSignal.

   Frontend applicants report a React task instead of the class problem. Wordle is the most reported task (5 of 7 frontend reports), with no styling required in two of them. Some versions add a part where you find a URL hidden in the page's DOM with your own selector and load it, and one report also describes a typewriter-style display that must run once, tested with Mocha and TypeScript. Two candidates say the provided unit tests could not pass as the project was set up, and a reply says the test files are not shown; one candidate traced the failure to the project's module format. Results have been poor even for finished work: two candidates who finished were rejected, one of them with every test passing, one who could not submit was rejected, and one new grad heard nothing further.

   • →Get familiar with CodeSignal before you start; one candidate says 45 minutes leaves little slack.
   • →If the tests fail out of the box, say so rather than quietly editing files you were told not to touch. One candidate who changed the export syntax against the file's instructions suspects it cost them.

3. 3. Recruiter call

   About 20 minutes in the one report that gives a length; in two reports the recruiter reached out first.

   Two reports place the call before the technical screen. It covers your background, motivation and interests, and logistics such as sponsorship. One candidate also had a recorded video screen, at a point in the process the report does not state, with five or six short behavioral prompts, among them why Ramp and how you use AI in your work.

   • →Have a short, specific answer to why Ramp; it is one of the video screen prompts.
   • →Be ready to describe how you use AI in your daily work. It comes up in the video screen, and the onsite has an AI-assisted round.

4. 4. Technical screen: coding

   60 minutes of live coding in CoderPad (2 reports give the length and 2 the platform), with about 5 minutes for your questions at the end (2 reports).

   Most screens are the URL maze (8 of 11 screen reports), a graph search in which each step is an HTTP request. Three candidates say the difficulty is in the HTTP handling and parsing rather than the algorithm. Follow-ups add error responses and, in three reports, keys that must be collected and sent with later requests. Four candidates describe short or vague prompts and interviewers who give little guidance, so you print responses and work out the format yourself; one felt that knowing everything up front would look as if you had seen the problem. Other screens were a flight-records problem, recurring transaction detection, and in one report a system design round (a hotel reservation site) as the only round. Several candidates ran short of time: debugging intermittent server errors, missing a key in noisy debug output, or a last edge case still failing.

   • →Print the raw response before you parse it (3 reports).
   • →Retry failed requests rather than skipping them. Two reports say a request that failed could succeed on the next try, and one candidate who skipped them lost the exit. One interviewer wanted plain retries with no backoff.
   • →Get the main path working before error handling. One interviewer said code style counts for little in this round.
   • →Ask questions out loud even if the interviewer stays quiet, and keep your debug output readable.

5. 5. Onsite: coding

   One round, in CoderPad in the one report that names the platform; one candidate could choose an in-person or remote onsite.

   All three onsite reports describe four rounds, one of them coding. Reported problems are flight records (the user with the most flights, then where a user is at a given time), recurring transaction detection, and a finance transaction problem. One candidate says the round weighed object-oriented design, clean code and corner cases, and another advises keeping the method flexible enough to tune. A third had to work out how to import a data file from a different folder and write tests with pytest, and thinks the time that took, and code that was not bug-free, probably cost them the loop.

   • →Set up a scratch project where you load data from another folder and run pytest, so the environment does not eat into the hour.
   • →Make thresholds and rules easy to change; one candidate says the data drifts in price and interval.

6. 6. Onsite: AI-assisted coding

   A repository you work in with the AI tools of your choice (4 reports describe the repository); one report mentions a $50 stipend for tools and says any language is allowed.

   You build a feature in an existing repository with an AI assistant. The request arrives as product work: in one report it was a Slack message from a PM, with the interviewer playing the PM and declining technical questions, so the job is to agree the smallest useful spec and then prompt the agent. Reported features are about financial matching (3 reports): reconciling several data sources with matching rules you agree with the interviewer, building a matching system with bonus tasks if time allows, and improving a receipt upload flow that matches receipts to transactions. In one loop the repository's instructions file told the assistant to record every prompt in a history file, which the interviewer used to judge how the candidate worked with AI; that candidate used about five prompts, failed this round, and was told the interviewers wanted to see more understanding of the AI's output rather than using it directly. Two candidates say the expectations for this round were unclear.

   • →Agree the spec, or the matching rules, with the interviewer before you prompt (2 reports).
   • →Read and explain what the assistant writes. The one detailed rejection from this round was for using output without showing understanding.
   • →Install and test your AI tools before the day. One candidate says waiting on each prompt and then reading the output left too little time, so plan the work and read while the agent runs.
   • →Read the recruiter's guidance closely; one candidate says it strongly hinted at the topic.

7. 7. Onsite: architecture (project presentation)

   A presentation of a project you built, followed in two reports by a short system design question.

   All three onsite reports describe this round as a presentation of a project you worked on. One recruiter said it is not a typical system design round, and another said it is mainly used to judge seniority. Two candidates then got a design question: about 20 minutes on counting recent visits to a website in one report, which the recruiter had not mentioned, and the second half of the round in another, on showing a payments count on an admin dashboard, scaled up step by step. One candidate who prepared slides and diagrams ran out of time before finishing and was told the presentation was hard to follow; another filled the presentation half and was asked little.

   • →Time the presentation so it leaves room for questions and a design question afterwards.
   • →Prepare a simple counting or aggregation design that you can scale up as requirements grow, even though the round is billed as a presentation.

8. 8. Onsite: behavioral

   One round in each of the three onsite reports.

   All three onsite reports call it a typical behavioral round, with tell me about a time questions in one report and which project you are proudest of, and why, in another. One candidate felt the interviewer valued shipping quickly and independently.

   • →Prepare stories about shipping something quickly with little direction, and about the project you are proudest of.

How the Ramp loop differs by role

After the final round

Only one onsite report gives timing: a rejection by email three days later, with feedback on the presentation and the AI round. Another onsite candidate was rejected and believes the coding round probably decided it. No report describes an offer or reference checks, and one commenter notes that none of the reports they had read ended in an offer.

What does Ramp ask in each round?

Ramp interviews span 6distinct round types, shown below. Counts reflect distinct questions per round across the loops we’ve indexed.

How to prepare for the Ramp interview

1. 1. Practise HTTP-heavy coding

   Write a small client that follows links across JSON responses, retries failed requests, handles 4xx and 5xx codes and adds auth headers, and get used to printing and reading responses before parsing them.

2. 2. Work practical data problems with tests

   Flight records, recurring transactions and other finance data, in a project where you import data files and run pytest, finishing a working version before adding cases.

3. 3. Rehearse the AI round end to end

   Set up your tools, take a loosely worded product request, agree a minimal spec, plan, prompt in pieces, and explain every change the assistant makes. Keep your prompts deliberate, since one loop recorded them for the interviewer.

4. 4. Build a short project presentation

   Pick one project you designed, make a few slides with diagrams, time it with room for questions, and practise a small design question you can scale up afterwards.

5. 5. Prepare for the assessment if you apply online

   General roles: four-level class problems in 90 minutes. Frontend roles: Wordle and DOM work in React in 45 to 90 minutes (CodeSignal in the one report that names the platform).

FAQ