Airbnb Full Stack 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 adequately convey the semantic meaning or interactive behavior of a component to assistive technologies. For the amenity filter panel, this would include custom interactive elements like a multi-select dropdown with checkboxes (aria-labelledby, aria-controls, aria-expanded, role="listbox", role="option", aria-checked) or a custom range slider (role="slider", aria-valuenow, aria-valuemin, aria-valuemax). Conversely, ARIA should be removed or avoided when native HTML provides the same or better semantics, such as using a `<button>` for a submit action (instead of `role="button"` on a `<div>`) or `<input type="checkbox">` for a single amenity selection (instead of `role="checkbox"` with `aria-checked` on a `<div>`). Prioritize native semantics first, as they are inherently more robust and require less maintenance.

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 explicit error states and retry mechanisms, often through props like `isError`, `errorMessage`, and `onRetry`. For the QA process, it necessitates dedicated test cases for various failure modes (e.g., network, server, client-side data), focusing on user experience during errors and accessibility of error messages. The release checklist must include verification of error boundary implementation, graceful degradation, and A/B testing for error state user flows to ensure minimal impact on conversion and user satisfaction.

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 in a high-stakes admin console, I would implement ARIA live regions for immediate, non-disruptive announcements of validation failures, clearly associating error messages with their respective input fields using `aria-describedby`. Validation hints should be provided proactively, perhaps on focus, using `aria-describedby` to link to helper text, and recovery paths must be explicit, offering clear instructions or actionable buttons, not just 'try again'. For Airbnb, a migration strategy would involve an A/B test with a small internal admin team, comparing task completion rates and error resolution times between the old and new accessible error handling, alongside automated accessibility scans (e.g., Axe-core) integrated into CI/CD for new features.

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., for screen reader users, motor impaired users, cognitive load). They would then propose specific, actionable solutions like providing text alternatives, keyboard navigation, sufficient contrast, and clear focus indicators. The negotiation strategy would involve educating design on WCAG principles, demonstrating impact with user stories/data, and collaborating on alternative, equally elegant solutions that meet both aesthetic and accessibility requirements. Finally, they would emphasize an iterative approach, potentially using A/B testing or user research with diverse participants.

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 ARIA attributes, keyboard focus management, and semantic HTML. Key points include using `role="dialog"` or `role="alertdialog"`, `aria-modal="true"`, and `aria-labelledby` / `aria-describedby` for context. Crucially, implement focus trapping to keep keyboard focus within the modal and restore focus to the triggering element upon closure. Ensure the modal is dismissible via the Escape key and has a clearly labeled close button. Finally, manage `aria-hidden` on the main page content when the modal is open to prevent assistive technologies from interacting with background elements.

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, referencing WCAG 2.1 success criterion 2.5.5 (Target Size). They would then identify key interactive elements on an Airbnb listing search page, such as filters, listing cards, pagination controls, and the search bar, explaining how to manually check their size using browser developer tools (e.g., measuring dimensions and padding). For automation, they would suggest using tools like Lighthouse, axe-core, or custom Playwright/Cypress scripts to programmatically check element dimensions against minimum size requirements (e.g., 44x44 CSS pixels) and integrate these checks into CI/CD pipelines. Finally, they would discuss the importance of considering both explicit element size and effective touch area, including padding and margins.

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 comment composer with clear visual and programmatic focus order, ensuring logical tab navigation through the textarea, character counter, and submit/cancel buttons. It will emphasize explicit ARIA labels for all interactive elements (e.g., `aria-label="Write your comment"` for the textarea, `aria-live="polite"` for character count updates). Keyboard interactions should include `Enter` for submission (with Shift+Enter for new lines in textarea), `Escape` to close/cancel, and standard arrow key navigation within suggestions if present. Announcements via screen readers should confirm actions like 'Comment submitted' or 'Comment composer closed'.

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: Triage would begin by gathering details from the user report (browser, screen reader, OS, exact steps, error messages) and checking logs for client-side errors or accessibility audit failures. Reproduction involves setting up the reported environment, using a screen reader (e.g., VoiceOver, NVDA) to follow the checkout flow, and observing where the interaction breaks (e.g., unlabelled elements, incorrect ARIA roles, keyboard traps). The fix would involve identifying the specific inaccessible elements or interactions, applying appropriate ARIA attributes (labels, roles, states), ensuring correct tab order and keyboard navigability, and validating with multiple screen readers and automated accessibility tools.

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: ARIA should be used when native HTML elements cannot convey the necessary semantic meaning or interactive behavior for the host availability calendar, such as for custom date pickers, date ranges, or complex interactive states. Examples include `aria-label` for custom date cells, `role="grid"` and `role="gridcell"` for the calendar structure, and `aria-selected` for date selection. ARIA should be removed or avoided when a native HTML element already provides the equivalent semantic meaning and accessibility features, like using a standard `<button>` for a 'Save' action instead of a `<div>` with `role="button"`. Prioritize native semantics first, only augmenting with ARIA when absolutely necessary to enhance accessibility for assistive technologies.

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 Wishlist board's component API by requiring props for accessibility attributes (e.g., `aria-label`, `role`, `tabIndex`) and ensuring semantic HTML. The QA process must integrate automated accessibility checks (linters, axe-core) and manual testing with screen readers, keyboard navigation, and color contrast analyzers. The release checklist will expand to include explicit sign-offs for WCAG compliance, accessibility regression testing, and documentation of any known accessibility issues with mitigation plans.

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: For accessible errors in a map/list toggle, I would use ARIA live regions (e.g., `aria-live="assertive"`) to announce validation messages immediately to screen reader users without shifting focus. Validation hints should be linked to their respective input fields using `aria-describedby` and provide clear, concise instructions. For recovery paths, I'd ensure error messages are actionable, perhaps including a 'Go to error' link for complex forms, and that focus is programmatically moved to the first erroneous field upon submission. Visual cues like red borders and error icons must also be present and clearly associated.

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 core accessibility issues with subtle icons and gestures (e.g., lack of text alternatives, keyboard inaccessibility, motor skill challenges). They would then propose a collaborative negotiation strategy with design, focusing on solutions like providing clear text labels/alternatives (aria-label, alt text), ensuring keyboard navigability and focus management, and offering alternative input methods or larger touch targets. The discussion should emphasize user impact, legal compliance (WCAG), and Airbnb's brand values, aiming for an inclusive design that doesn't compromise core functionality or user experience.

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 interaction. Key points include trapping focus within the modal/popover, ensuring the escape key closes it, and that focus returns to the triggering element upon closure. Additionally, using appropriate ARIA roles (e.g., `role="dialog"`, `aria-modal="true"`) and labels (`aria-labelledby`, `aria-describedby`) is crucial for screen reader users. The solution should also manage the underlying page's scrollability and provide a visible focus indicator.

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 answer would begin by defining focus management and its importance for keyboard and assistive technology users. For manual checks, candidates should describe tabbing through all interactive elements in a logical order, checking for focus visibility, and ensuring modal dialogs trap focus. Automated checks would involve using tools like axe-core or Lighthouse to detect common issues like missing `tabindex` on custom controls or inaccessible elements, and writing end-to-end tests to verify focus behavior on specific interactive components like carousels or date pickers. The answer should emphasize the iterative nature of both manual and automated testing.

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 will describe an analytics widget that visually represents trip data (e.g., spending, activities) and is fully navigable and understandable via keyboard and screen readers. It should detail a logical focus order that moves through interactive elements sequentially, ensuring all data points and controls are reachable. Labels must be descriptive for all interactive elements and data visualizations (e.g., ARIA-labels for charts, `alt` text for images), and screen reader announcements should provide context and value changes (e.g., "Spending chart, showing 3 categories: Accommodation $500, Food $300, Activities $200"). Keyboard interactions must include standard navigation (Tab, Shift+Tab) and specific controls for interacting with the data (e.g., arrow keys to navigate chart segments, Enter/Space to activate filters or view details).

Practice these with instant AI feedback in a live mock interview → Start a Airbnb Full Stack 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.

Other roles at Airbnb

Full Stack Engineer interviews at other companies