Lyft Software Engineer T3 Interview Experience
Lyft · Entry level · Software Engineer
The process wasn’t as long as I expected. My onsite was supposed to be four rounds, but they cut it to just two, and one of them was a time-based key value store with delete at a specific timestamp given in the full spec up front.
Interview process
I interviewed for Software Engineer T3, and the biggest thing that stood out was how short the process was. I had a recruiter screen, then a 1-hour technical round, and then an onsite that was originally supposed to be four rounds but got cut down to just two. The technical screens were pretty classic: one medium BFS/DFS-style grid problem similar to Rotting Oranges, then one OOP-flavored time-based key value store with a delete-at-timestamp twist. It felt more streamlined than I expected for a new grad process. I don't have an outcome to share, but process-wise it was a lot leaner than I thought it would be.
Interview rounds · 4
- 1
Recruiter screen
BehavioralProject DiscussionI started with a pretty standard recruiter screen. It was mostly logistics plus a quick pass through my background, and it felt straightforward.
Q1. Why do you want to join the company, and what are you looking for?
How they answeredI talked about my interest in the company and what I was hoping to get out of the role. They also used that part to explain what the company could offer me.
Q2. Can you walk me through your resume and talk about a couple of interesting projects you worked on?
How they answeredI walked through my resume at a high level and talked about a couple of projects I thought were most interesting. It was more of a quick background check than a deep technical discussion.
Q3. When could you start, and what are your salary expectations?
How they answeredI answered the basic logistics around my start date and compensation expectations. That part was very standard and felt like a normal recruiter screen.
- 2
Technical round
CodingData Structures & AlgorithmsTechnicalThe next round was a 1-hour coding interview that was basically one medium LeetCode problem. It was focused on data structures and algorithms, and the whole round stayed on that single question.
Q1. Solve a medium grid problem very similar to Rotting Oranges.
How they answeredThe problem was essentially a matrix-based BFS/DFS question, very close to Rotting Oranges. I remember it as a grid of objects where I had to reason about everything becoming 'rotted' over time, so the core skill being tested was multi-source BFS on a matrix.
- 3
Final / onsite round
CodingTechnicalData Structures & AlgorithmsMy onsite was supposed to be four rounds, but for my case they cut it down to just two. The first was a laptop round that felt like another LeetCode-style problem, except this one leaned more object-oriented.
Q1. Implement a time-based key value store with set and get, plus extra methods.
How they answeredThe question was a variation of the classic time-based key value store. I had to think in an object-oriented way and implement the full spec up front, not just basic set/get. The extra requirement I remember clearly was delete at a specific timestamp, which made it more nuanced than the standard version.
Follow-up questions- Implement delete for a specific timestamp.
- 4
Final / onsite round
BehavioralThe last round was a behavioral with the engineering manager. I don't remember the exact prompts, but it was the closing conversation after the laptop round.
Tips from the candidate
I'd prep the basics really well instead of expecting anything super exotic. For me, that meant being ready for a medium graph or grid problem like Rotting Oranges, and also being comfortable with OOP-style data structure questions where they add methods like delete at a specific timestamp. I'd also make sure you can talk cleanly through your resume, projects, and why this company.
Company culture
My impression was that they were trying to move fast. In my case they literally cut the onsite from four rounds to two, so the process felt more flexible and shorter than expected. Even with that, they still checked the main buckets: recruiter fit, standard DS&A, an OOP-leaning coding round, and an EM behavioral. So to me it felt like they were streamlining the loop without really changing what they wanted to evaluate.