
Software Engineer T3 Interview Experience
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.
- Recruiter screen
- Technical interview
- Final round
Interview rounds
5 questions across 4 roundsRecruiter screen
3 questionsOverview
I started with a pretty standard recruiter screen. It was mostly logistics plus a quick pass through my background, and it felt straightforward.
Question types asked
Specific questions asked
I 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.
Can you walk me through your resume and talk about a couple of interesting projects you worked on?
I 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.
When could you start, and what are your salary expectations?
I answered the basic logistics around my start date and compensation expectations. That part was very standard and felt like a normal recruiter screen.
Technical interview
1 questionOverview
The 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.
Question types asked
Specific questions asked
Solve a medium grid problem very similar to Rotting Oranges.
The 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.
Final round (1)
1 questionOverview
My 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.
Question types asked
Specific questions asked
Implement delete for a specific timestamp.
The 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.
Final round (2)
Overview
The 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.
Question types asked
Interview tips
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.
Get full access with a membership, or share your experience to try it free.
More Lyft interview experiences

“Started with background discussion. Interviewer asked about a specific project i mentioned on the resume and dug into details. As for the coding challenge, I was given an existing package which contained an API for reading 4 bytes of data at a type from a file. To read 10 bytes, we had to call this underlying API 3 times to get 12 bytes, respond back with the requested 10 bytes, and keep the extra 2 bytes of data in memory for future calls. I solved this with a queue-based implementation, handling edge cases around reaching the end of the file. Got follow-up questions related to handling API call failures, retries, and streaming the output.”

“Pretty standard interview process - the recruiter was very nice and collected information, and guided me through the expectations for the interview. The sense and execution interviews were also pretty standard - interviewers help you along if you get stuck. I had to answer some questions related to Lyft as well as a spotify question.”