Rippling had a really solid interview process. I applied with a referral, and the recruiter reached out the next day to schedule a time for us to speak.

On that call, the recruiter did a great job of pitching Rippling and made me excited about the financial potential of joining the company at this stage. It was authentic too. Although I did not receive an offer, I would be excited to consider Rippling in a future job search, as the company clearly has a fantastic product and a bright future, and the interview process only highlighted this.

The next interview was with a software engineer who had me build a simple data structure. With each subsequent step, the class we were building became more complex. Think "let's design a bank account class and allow users to withdraw and deposit," and then it gets progressively more complicated. I've encountered a few of these, and I think they are excellent when done well. This interviewer orchestrated it near perfectly. I felt like it really gave me the opportunity to show what I knew. I was later told that that question is being retired, as it has quite a high pass rate, but I really hope the future of coding interviews features more of these because they give far more meaningful signal than any Leetcode-type questions.

Next, I had an interview with the Director of Engineering, where he gave me a demo of the product and asked me a few behavioral-style questions. I got a sense of where the product was headed, and overall, it was an enjoyable interview.

At this point, I moved on to the final round, which was a "virtual onsite" that consisted of two coding interviews and one system design interview.

I started with the system design interview and, looking back, I made a few critical and probably silly mistakes that likely reflected poorly on me. I was able to come up with a comprehensive design, but a few of the key decisions I made were just wrong. Fortunately, realizing my mistakes there helped me pass my next onsite with a different company.

My next onsite interview was a coding question. I was able to solve it with a brute-force solution, which was actually a non-trivial amount of code. It seemed clear that the optimal solution was actually a dynamic programming approach, and the interviewer seemed to indicate that this was the correct path when I brought it up. I was only able to sketch out the memoization chart and got tripped up there, and the interviewer had to help me. I do find myself questioning why a company that makes HR software is asking DP questions, but I think I got the benefit of the doubt on this one, as the interviewer and I had a great discussion about this question, and I definitely demonstrated competency.

My final coding interview was similar to my initial coding interview, in that the goal seemed to be to gauge understanding of OOP concepts. I think I did okay on this one but definitely flailed a bit and did not end up with a 100% comprehensive solution.

Nevin C., the recruiter, was easily the best recruiter I have gotten to work with so far in my career. I had a difficult time with my most recent job search, and all of my interactions with Nevin were like a breath of fresh air compared to those with a lot of the other recruiters I was working with. He responded to all inquiries promptly, was completely honest about the process, helped me as much as he could, and generally just served as a fantastic ambassador for the company. Even after it was clear I wasn't getting an offer, he reached out to let me know I should keep Rippling in mind for the future and even offered to help my job search where he could. Stand-up guy -- glad I had the opportunity to work with him during this process.

Design a bank account class where we can withdraw and deposit.