Ramp Frontend Engineer Interview Questions
& Process

Typical process. Started with a recruiter call, then went through several coding challenges, followed by a systems design round, and finished with a behavioral interview. Like many places now, they seem to think failing a quick coding test means you're not good enough, even if you have relevant skills for the actual job. The coding test I got didn't seem related to the team's work at all. I didn't pass the coding test, but honestly, based on reviews, I probably wouldn't have wanted to work there anyway. Still, I figured it'd be good practice. Sharing the questions to help others get past that silly gate and actually discuss what they know and can do. Being able to code a Google Calendar isn't really what they need.

So the whole interview process was really great. First, I had a take-home exercise, which was actually fun and felt useful. Then, there was a 1-hour pair programming coding exercise where being communicative and letting the interviewer guide you was important, and speed mattered too. After that, it was onsite for four interviews. Two of them were 1-hour pair programming coding exercises with a 30-minute break. They were similar to the first coding interview, and again, communication was key. There was also a standard cultural interview. Lastly, a 30-minute presentation of my past work followed by 30 minutes of questions about my experience for the architecture and system design part. A recruiter helped me out a lot after the first coding interview, answering questions and setting up the onsite. They made the whole thing really pleasant, from the first recruiter call right through to the offer.

So, the first thing was a takehome React challenge after I chatted with the recruiter. It wasn't too hard, took me less than an hour. Then, there was a live coding session with an engineer. Honestly, I didn't think it was a great way to judge someone's skills. They wanted us to build a bunch of simple features in about 50 minutes, which felt like it forced you to cut corners. Even so, I couldn't get a working version in that time. They didn't seem to care much about edge cases, React best practices, or good UX, just wanted to see code that worked fast. It was pretty simple stuff, but a lot for a 1-hour interview. I don't think it's a good way to tell if someone can write clean, modular code for the role. The requirements were pretty clear, and there wasn't much room for back-and-forth with the interviewer. It was pretty quiet during the interview.