T. Rowe Price Software Engineer Interview Guide

The process started with a phone screen with the recruiter, which was straightforward and felt like a typical initial qualification check. After that, I moved into the technical rounds, where things got more interesting. I had a discussion with the tech lead and a junior developer where they walked through my resume and asked fairly foundational questions about how I approach coding—things like how I structure code, what I look for in a code review, and how I apply learning to my day-to-day work. The questions themselves were pretty generic, and honestly, based on some of the follow-ups I tried to dig deeper on, both interviewers seemed somewhat inexperienced. That was a bit surprising for a senior-level role, but they were genuinely nice people and the conversation stayed friendly throughout.

The technical content focused a lot on problem-solving approaches. In one round, they presented a scenario: if you had a slow application, how would you debug and fix it? This was less about coding on the spot and more about articulating your thought process—how you'd identify bottlenecks, what tools you'd use, and how you'd systematize the fix. Another variant of this came up around latency issues in data-centric systems and root cause analysis. The expectation seemed to be that you could walk them through a structured debugging methodology rather than jump straight to solutions. There wasn't a traditional coding challenge with live pairing.

The whole process moved at a reasonable pace over a few weeks, and everyone I interacted with was professional and transparent about the process itself, which I appreciated. The biggest takeaway for me was that they're looking for how you think and tackle problems methodically, not necessarily how fast you can code. That said, the interview quality was a bit uneven—some rounds felt more polished than others, and the technical bar didn't always feel clearly calibrated.