Lyft · Primly Community

Lyft frontend engineer interview: what they actually tested, vanilla JS vs. React, and what tripped me up

infra_ines · 3 replies

Did the Lyft frontend engineer loop a couple months ago, senior level (L5 equivalent). Sharing because the prep advice I found before my loop was pretty surface-level and I had to piece together the actual shape myself.

Background: 4 YOE, React-heavy, some TypeScript, a bit of Vue from a previous job. Applied through a referral from a friend at Lyft.

Phone screen: One coding problem, focused on DOM manipulation. Not a React question. Pure JavaScript. I hadn't done raw DOM work in a while and it showed a little. The question was something like "implement a simple virtual DOM diffing function" -- not the full React reconciler obviously, but you need to understand what the real one is doing. worth brushing up on JS fundamentals even if you work in frameworks all day.

Onsite (4 rounds):

Round 1: Frontend coding. I got a UI component implementation question. Build a filterable list component with live search. They gave me a blank HTML/JS file, no framework. Again: vanilla JS. Know event listeners, debouncing, basic DOM update patterns.

Round 2: Another coding round. This one was more algorithmic than UI-focused. Medium-difficulty problem, graph-adjacent (given a list of roads between pickup zones, find the shortest path -- basically Dijkstra's). The framing was transportation-domain specific but the algorithm underneath was standard. I think they do this on purpose because it's relevant to their actual product.

Round 3: System design -- frontend architecture. "Design the real-time driver tracking UI that riders see during a trip." This was genuinely interesting. Topics that came up: WebSockets vs. polling, how to handle dropped connections gracefully, caching driver position updates on the client, how you'd handle the component lifecycle if the user backgrounds the app. They wanted depth on state management and data flow, not just visual design.

Round 4: Behavioral. Standard STAR questions. A conflict story, a story about a technically complicated feature, a story about working with design. Nothing unusual.

What surprised me: way more vanilla JS than I expected for a React company. They clearly want to know that you understand the platform, not just the framework abstractions. If you've only ever worked in React and haven't thought about what happens under the hood, spend some time there.

The real-time tracking system design was the round I felt best about. Worth thinking through websocket patterns before your loop.

Offer: L5, Seattle, base around $185k. Didn't negotiate hard enough in retrospect.

3 replies

hardware_hugo

the vanilla JS thing is real. i've seen this at a few mobility companies. the logic from the interviewers' perspective is: if your framework disappears, do you still know what's happening. it's a reasonable bar even if it's annoying to prep for when you haven't touched raw DOM in 3 years.

staff_steph

the real-time tracking system design is a great one to think through because it hits websocket lifecycle, reconnection logic, and state management all at once. if you're prepping for this role specifically, i'd sketch out that architecture before your loop. not just "use websockets" -- how do you handle the reconnect, what's the client-side buffer strategy, what do you show the user during a connection gap.

mobile_mara

curious whether they had any mobile web or PWA questions given how heavily Lyft users are on mobile. or was the loop pretty desktop-centric?