Airbnb Frontend Engineer Interview Questions (2026)

1. 1Recruiter Screen30 minEasy

   Background, motivation for Airbnb's mission and process overview.

2. 2Technical Phone Screen60 minHard

   A practical CoderPad problem where the code must compile and pass real inputs, e.g. parsing, interval logic or a mini file-system.

3. 3Onsite Coding (Practical)60 minHard

   Product-flavored implementation task pushed to fully working code with follow-up extensions.

4. 4System Design / Architecture60 minHard

   Design a marketplace subsystem such as search ranking, calendar availability or payments with consistency and trust concerns.

5. 5Core Values Interview I45 minMedium

   Cross-team interviewer probes real stories against Airbnb's named core values; holds veto power independent of technical rounds.

6. 6Core Values Interview II45 minMedium

   Second independent values conversation with a different cross-functional interviewer for signal redundancy.

1. Q1

   When would you use ARIA in the amenity filter panel, and when would you remove it in favor of native semantics?

   StaffOnsite/Full Loop - AccessibilityAccessibilityAirbnb-specific

   Context: amenity filter panel

   How to answer: ARIA should be used when native HTML elements or attributes do not provide the necessary semantic meaning or interactive behavior for assistive technologies (ATs). For the amenity filter panel, this means using ARIA for custom components like a multi-select dropdown (e.g., `role="listbox"`, `aria-selected`), custom sliders (`role="slider"`, `aria-valuenow`), or dynamic regions (`aria-live`). Conversely, ARIA should be removed or avoided when native HTML provides equivalent or superior semantics, such as using `<button>` for clickable actions, `<input type="checkbox">` for toggles, or `<fieldset>` and `<legend>` for grouping related filters, as native elements are inherently more robust and accessible.

2. Q2

   Explain how error recovery changes your component API, QA process, and release checklist for the experience detail page

   MediumOnsite/Full Loop - UX QualityAccessibilityAirbnb-specific

   Context: experience detail page

   How to answer: Error recovery significantly impacts the component API by requiring props for error states (e.g., `isError`, `errorMessage`), retry mechanisms, and potentially a `fallbackRender` prop for boundary components. The QA process must expand to include dedicated test cases for various error scenarios (network, data, permissions, UI rendering), focusing on accessibility of error messages and retry flows. The release checklist needs to incorporate checks for robust error handling, graceful degradation, and user experience during recovery, ensuring all error states are visually and functionally tested across devices and assistive technologies.

3. Q3

   How would you handle accessible errors, validation hints, and recovery paths in a high-stakes admin console? Include a migration or testing angle specific to Airbnb

   MediumOnsite/Full Loop - ArchitectureAccessibilityAirbnb-specific

   Context: trip itinerary

   How to answer: For accessible errors, I'd use ARIA live regions (e.g., `aria-live="assertive"`) to announce validation messages immediately without shifting focus, ensuring screen reader users are aware of issues. Validation hints would leverage `aria-describedby` to link input fields to their descriptive error messages, providing context. Recovery paths involve clear, actionable error messages, suggestions for correction, and accessible 'retry' or 'fix' buttons. For Airbnb, I'd propose an A/B test comparing the current error handling with a new ARIA-enhanced version, specifically measuring task completion rates and time-on-task for users relying on assistive technologies within the admin console.

4. Q4

   The design for the host onboarding form uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

   HardOnsite/Full Loop - AccessibilityAccessibilityAirbnb-specific

   Context: host onboarding form

   How to answer: A strong candidate would first identify the accessibility issues with subtle icons and gestures (e.g., lack of text alternatives, motor skill requirements). They would then propose a collaborative approach with design, advocating for clear, redundant alternatives like visible text labels, tooltips, and keyboard navigation support. The discussion would involve explaining WCAG principles (Perceivable, Operable, Understandable) and Airbnb's commitment to inclusivity, suggesting user testing with diverse groups, and exploring progressive enhancement or customization options for accessibility.

5. Q5

   How would you ensure a modal, popover, or drawer in the price breakdown panel works for keyboard and assistive technology users?

   StaffOnsite/Full Loop - UX QualityAccessibilityAirbnb-specific

   Context: price breakdown panel

   How to answer: A strong answer would focus on proper WAI-ARIA roles and states, specifically `role="dialog"` or `role="alertdialog"` for modals, and `aria-modal="true"`. It should also cover keyboard trap management, ensuring focus remains within the open component and returns to the triggering element upon close. Crucially, candidates must mention managing focus, including setting initial focus inside the component and restoring it afterwards. Finally, they should discuss visible focus indicators and the ability to close the component via the Escape key.

6. Q6

   Audit the listing search page for touch target size. What checks would you run manually and which would you automate?

   MediumOnsite/Full Loop - ArchitectureAccessibilityAirbnb-specific

   Context: listing search page

   How to answer: A strong candidate would first define touch target size and its importance for accessibility, especially on mobile. They would then propose manual checks for interactive elements like buttons, links, and input fields, focusing on their visual size and spacing relative to other elements. For automation, they would suggest using browser developer tools (e.g., Lighthouse, Chrome DevTools audit) and potentially a custom script to check CSS properties (width/height, padding) against WCAG 2.1 AA guidelines (44x44 CSS pixels). They would also mention considering dynamic elements and different screen sizes.

7. Q7

   Design an accessible comment composer for the map search results. Explain focus order, labels, announcements, and keyboard interaction

   MediumOnsite/Full Loop - AccessibilityAccessibilityAirbnb-specific

   Context: map search results

   How to answer: A strong answer will detail a logical focus order, starting with the composer's trigger, then the input field, and finally action buttons (e.g., 'Post', 'Cancel'). It will emphasize clear, programmatically associated labels for the textarea (e.g., `aria-label` or `label` with `for`/`id`) and buttons. Crucially, it will explain ARIA live region announcements for success/error messages and character counts, along with standard keyboard interactions like `Tab` for navigation, `Enter` for submission, and `Escape` to close or clear. The candidate should also mention `aria-describedby` for instructions or constraints.

8. Q8

   A screen reader user cannot complete the booking checkout flow. How would you triage, reproduce, and fix the issue?

   HardOnsite/Full Loop - UX QualityAccessibilityAirbnb-specific

   Context: booking checkout flow

   How to answer: Start by gathering more information: what specific screen reader, browser, OS, and what exact step in the checkout flow is failing. Next, attempt to reproduce the issue using the identified screen reader (e.g., VoiceOver, NVDA, JAWS) and browser, navigating the checkout flow solely with a keyboard. Use browser developer tools to inspect the accessibility tree and ARIA attributes for the problematic elements. Identify missing or incorrect ARIA roles, states, properties, or improper focus management. Implement fixes by adding appropriate ARIA attributes (e.g., `aria-label`, `aria-describedby`, `aria-live`), ensuring logical tab order, and managing focus programmatically where necessary, then re-test with the screen reader.

9. Q9

   When would you use ARIA in the host availability calendar, and when would you remove it in favor of native semantics?

   StaffOnsite/Full Loop - ArchitectureAccessibilityAirbnb-specific

   Context: host availability calendar

   How to answer: A strong candidate would explain that ARIA is primarily used when native HTML elements cannot convey the necessary semantic meaning or interactive behavior for accessibility, such as for custom widgets like a complex date picker or calendar. They would detail using ARIA roles (e.g., `role="grid"`, `role="gridcell"`), states (`aria-selected`, `aria-disabled`), and properties (`aria-label`, `aria-labelledby`) to make the calendar navigable and understandable for screen reader users. Conversely, they would emphasize removing ARIA when native HTML elements inherently provide the required semantics (e.g., using a `<button>` for an interactive day instead of a `<div>` with `role="button"`), as native elements offer built-in keyboard interaction and browser optimizations. The decision hinges on whether the custom component's functionality can be fully expressed and made accessible through standard HTML.

10. Q10

    Explain how WCAG conformance changes your component API, QA process, and release checklist for the wishlist board

    MediumOnsite/Full Loop - AccessibilityAccessibilityAirbnb-specific

    Context: wishlist board

    How to answer: WCAG conformance significantly impacts the component API by requiring props for accessibility attributes (e.g., `aria-label`, `role`, `tabIndex`), making them first-class citizens. The QA process must integrate automated accessibility checks (e.g., Axe, Lighthouse) and manual testing with assistive technologies (screen readers, keyboard navigation) across various browsers. The release checklist needs to include explicit sign-offs for accessibility, ensuring all critical user flows on the wishlist board are navigable and understandable for users with disabilities, and that accessibility bug fixes are prioritized.

11. Q11

    How would you handle accessible errors, validation hints, and recovery paths in a high-stakes map/list toggle?

    MediumOnsite/Full Loop - UX QualityAccessibilityAirbnb-specific

    Context: review submission flow

    How to answer: A strong candidate would discuss using ARIA live regions for dynamic error messages and validation hints, ensuring immediate announcement to screen reader users without shifting focus. They would explain associating error messages directly with their respective input fields using `aria-describedby` or `aria-errormessage`. For recovery paths, they would suggest clear, actionable links or buttons (e.g., 'Try again', 'Correct address') that are programmatically linked to the error, potentially focusing the user on the problematic element. They would also mention visual cues like red borders and icons, ensuring a multi-modal approach to error communication.

12. Q12

    The design for the guest messaging thread uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

    HardOnsite/Full Loop - ArchitectureAccessibilityAirbnb-specific

    Context: guest messaging thread

    How to answer: A strong candidate would first identify the specific accessibility issues posed by 'subtle icons and gestures,' likely related to visual impairment (icons lack text alternatives, low contrast) and motor impairment (gestures are hard to perform). They would propose a collaborative negotiation strategy, emphasizing WCAG guidelines (e.g., 1.1.1 Non-text Content, 2.1.1 Keyboard, 2.5.1 Pointer Gestures) and user empathy. The negotiation would involve suggesting concrete alternatives like visible text labels, standard button components, keyboard navigation, and ARIA attributes, while demonstrating how these can be integrated without sacrificing core design aesthetics or user experience. They would also discuss the importance of user testing with diverse groups.

13. Q13

    How would you ensure a modal, popover, or drawer in the amenity filter panel works for keyboard and assistive technology users?

    StaffOnsite/Full Loop - AccessibilityAccessibilityAirbnb-specific

    Context: amenity filter panel

    How to answer: A strong answer would focus on proper focus management, ARIA attributes, and keyboard navigation. This includes trapping focus within the modal, restoring focus to the trigger element upon closure, and using appropriate ARIA roles like `dialog` or `alertdialog` with `aria-labelledby` and `aria-describedby`. Keyboard navigation must allow users to close the modal (e.g., with Esc) and navigate interactively within its content using Tab and Shift+Tab, while preventing interaction with the underlying page. Finally, ensuring the modal is semantically linked to its trigger and visually distinct from the background is crucial.

14. Q14

    Audit the experience detail page for focus management. What checks would you run manually and which would you automate?

    MediumOnsite/Full Loop - UX QualityAccessibilityAirbnb-specific

    Context: experience detail page

    How to answer: A strong candidate would outline manual checks including tabbing through all interactive elements to ensure logical order, checking for visible focus indicators, and verifying that modals and other overlays correctly trap and restore focus. For automation, they would suggest using browser developer tools' accessibility tree to identify missing `tabindex` or incorrect ARIA roles, and leveraging automated accessibility checkers like Axe-core or Lighthouse to detect common issues such as non-focusable elements that should be, or elements with `tabindex="-1"` that are not programmatically managed. They would also mention testing keyboard navigation for complex components like carousels, date pickers, and dropdowns to ensure all functionality is accessible without a mouse. Finally, they would emphasize the importance of testing across different browsers and assistive technologies.

15. Q15

    Design an accessible analytics widget for the trip itinerary. Explain focus order, labels, announcements, and keyboard interaction

    MediumOnsite/Full Loop - ArchitectureAccessibilityAirbnb-specific

    Context: trip itinerary

    How to answer: A strong answer would describe a widget with clear, semantic HTML (e.g., `<section>`, `<h2>`, `<ul>`, `<li>`, `<button>`). Focus order should be logical, following visual flow, with interactive elements (buttons, links) being tabbable. Labels for non-text elements (icons, graphs) must be provided using `aria-label` or `aria-labelledby`. Announcements for dynamic content changes (e.g., data updates, filter changes) should use `aria-live` regions. Keyboard interaction must support full functionality without a mouse, including navigation within complex elements (like a graph with data points) using arrow keys, and activation with Enter/Space.

Practice these with instant AI feedback in a live mock interview → Start a Airbnb Frontend Engineer mock

Focus your prep on the topics above, rehearse structured answers out loud, and do at least one full mock loop before the real thing.

Indicative Frontend Engineer pay in India: ~₹8–38 LPA (role-level range, not a Airbnb-specific figure).

Other roles at Airbnb

Frontend Engineer interviews at other companies