Airbnb · Primly Community

Airbnb frontend engineer interview: what they tested beyond "can you build a UI"

frontend_fran · 5 replies

wrapped up my airbnb frontend engineer interview loop about two weeks ago. currently processing the offer and wanted to post while it was fresh because i couldn't find anything recent when i was prepping.

quick context: ~4 YOE, mostly React, some Vue, strong on CSS. applied for what maps to L4/mid-level.

Round structure: Initial recruiter screen (30 min, no technical content) OA: one frontend coding problem (more on this below) Onsite: 4 sessions across two days

The OA: was a component-building exercise. build a functional autocomplete search input with debouncing. vanilla JS allowed, React allowed, your choice. they cared about: edge cases (empty query, rapid typing, handling a network error from the mock API they gave you), keyboard accessibility (arrow keys, enter to select), and clean readable code. no external libraries. i used React and hooks. the debounce part was where people probably slip up, make sure your implementation actually cancels the previous pending call.

Onsite rounds:

Frontend systems: build a simplified version of a component that could plausibly exist on airbnb.com. i got a date range picker. the interviewer kept pushing the scope: "now make it support multiple months", "now handle disabled dates". classic expand-the-requirements pattern. knowing CSS grid/flexbox cold, managing state cleanly, and talking out loud the whole time mattered.

Performance + browser fundamentals: this is the round people don't prep for and should. questions like: how would you diagnose a slow initial page load for a listing page with 50+ photos? what's the paint timeline look like? we talked about LCP, CLS, image lazy loading, font loading strategies, and bundle splitting. if you've never opened the Chrome Performance tab in anger, go do that now.

Behavioral: standard airbnb core values format.

Cross-functional collaboration: a scenario round about working with designers. they gave me a realistic situation where a designer's spec was technically expensive and the timeline was tight. how do you negotiate without just saying no.

overall: if you're purely an algorithmic grind person, the frontend loop might surprise you. they care more about product sense and web fundamentals than data structures.

5 replies

mobile_mara

the autocomplete OA is kind of a classic now. the thing people always forget is the cleanup function in useEffect to cancel the previous request or clear the debounce timer on unmount. classic memory leak / stale closure trap.

infra_ines

LCP and CLS questions in a frontend interview used to be surprising, now they're basically table stakes. if you care about web perf, Lighthouse scores and the Web Vitals docs are actually worth reading the night before.

brand_ben

the designer negotiation scenario is interesting to hear about. did they seem to want the candidate to push back on the design spec or find a middle ground? asking because I'm a designer and i've been on the other side of these conversations.

frontend_fran

they wanted middle ground with a concrete proposal. not 'this is too expensive' and not 'sure we'll build exactly that'. the answer they seemed happy with was: here's what we can ship in the sprint that gets 80% of the user value, here's what we defer, here's how i'd document the gap so it stays on the roadmap.

returner_ren

the date range picker exercise sounds like something that would expose gaps if you've been out of the frontend world for a bit. good to know that's what the onsite component-build looks like, gives me a clear target to practice.