Meta Full Stack Engineer Interview Questions (2026)

1. 1Recruiter screen30 minEasy

   Process overview, level calibration, and prep guidance — Meta recruiters actively coach on round formats.

2. 2Technical screen45 minHard

   Two DSA problems in 45 minutes on a plain shared editor with no autocomplete or execution.

3. 3Coding round ('Ninja')45 minHard

   Two more problems at loop difficulty; clean near-compilable code and verbalized complexity analysis expected.

4. 4System design ('Pirate')45 minHard

   Design a Meta-scale product system (feed, Stories, chat) with emphasis on read-heavy fan-out, caching, and data modeling.

5. 5Behavioral ('Jedi')45 minMedium

   Deep past-experience discussion on conflict, growth, and impact aligned to Meta values; graded as a real signal round.

1. Q1

   Design an accessible comment composer for the Marketplace listing grid. Explain focus order, labels, announcements, and keyboard interaction

   MediumOnsite/Full Loop - UX QualityAccessibilityMeta-specific

   Context: Marketplace listing grid

   How to answer: A strong answer will detail a comment composer with logical focus order, starting with the text area and moving through action buttons (e.g., 'Post', 'Cancel'). It will emphasize explicit ARIA labels for all interactive elements, linking labels to inputs using `for` and `id` attributes, and providing descriptive `aria-label` or `aria-labelledby` for buttons. Crucially, it will explain live region announcements for success/error messages and character counts, and describe full keyboard operability including Tab for navigation, Enter/Space for activation, and Escape for closing/canceling, ensuring no mouse-only interactions.

2. Q2

   A screen reader user cannot complete the Threads profile page. How would you triage, reproduce, and fix the issue?

   HardOnsite/Full Loop - ArchitectureAccessibilityMeta-specific

   Context: Threads profile page

   How to answer: First, I would triage by gathering more information: what specific screen reader (e.g., NVDA, VoiceOver), browser, and OS is being used, and at what exact step does the user get stuck? Next, I would attempt to reproduce the issue using the reported setup, navigating the Threads profile page with the specified screen reader. If I can't reproduce it, I'd try other common screen readers. To fix, I'd inspect the DOM for missing ARIA attributes (e.g., `aria-label`, `aria-describedby`, `role`), incorrect tab order (`tabindex`), or non-semantic HTML elements that are not properly exposed to the accessibility tree. I would then implement the necessary ARIA attributes, adjust tab order, or refactor the HTML to ensure all interactive elements are programmatically discoverable and actionable for screen reader users, testing thoroughly with multiple screen readers.

3. Q3

   When would you use ARIA in the Meta Quest store, and when would you remove it in favor of native semantics?

   StaffOnsite/Full Loop - AccessibilityAccessibilityMeta-specific

   Context: Meta Quest store

   How to answer: A strong candidate would explain that ARIA should be used when native HTML elements or attributes do not sufficiently convey the semantic meaning or interactive behavior of a custom UI component to assistive technologies. This often occurs with complex widgets like custom carousels, tab panels, or tree views built from generic `div`s. Conversely, ARIA should be removed or avoided when a native HTML element already provides the necessary semantic meaning and accessibility features, such as using a `<button>` instead of a `div` with `role="button"`. The principle is to use native semantics whenever possible, as they are more robust and widely supported, and only layer ARIA on top when native options are insufficient to bridge the accessibility gap for custom components.

4. Q4

   Explain how error recovery changes your component API, QA process, and release checklist for the Creator insights panel

   MediumOnsite/Full Loop - UX QualityAccessibilityMeta-specific

   Context: Creator insights panel

   How to answer: Error recovery fundamentally shifts a component's API to include explicit error states, retry mechanisms, and fallback UIs, requiring props or context for error messages and actions. The QA process expands to rigorous testing of all error paths, including network failures, invalid data, and backend service unavailability, ensuring graceful degradation and accessibility of error messages. The release checklist must then include verification of error handling across different environments, A/B testing for error state user experience, and monitoring for error rates and recovery success post-launch.

5. Q5

   How would you handle accessible errors, validation hints, and recovery paths in a high-stakes comment composer?

   MediumOnsite/Full Loop - ArchitectureAccessibilityMeta-specific

   Context: Facebook Events page

   How to answer: A strong answer would emphasize immediate, clear, and programmatically discoverable feedback. For errors, this means using `aria-invalid` on the input, associating error messages with `aria-describedby` or `aria-errormessage`, and visually highlighting the problematic field. Validation hints should appear proactively, perhaps on focus or as the user types, using `aria-describedby` to link them. Recovery paths require clear instructions within the error message itself, suggesting specific actions, and ensuring focus management guides users back to the problematic field or a relevant action button after an error.

6. Q6

   The design for the Instagram comments drawer uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

   HardOnsite/Full Loop - AccessibilityAccessibilityMeta-specific

   Context: Instagram comments drawer

   How to answer: A strong candidate would first identify the core accessibility issues with subtle icons and gestures (lack of discoverability, reliance on fine motor skills, visual impairment challenges). They would then propose a collaborative negotiation strategy with design, focusing on alternative implementations like visible text labels, standard button components, and keyboard/screen reader discoverable actions. The negotiation would emphasize user testing data, accessibility guidelines (WCAG), and the business value of inclusivity, aiming for solutions that enhance usability for all without sacrificing core design intent. Finally, they would discuss a phased approach or A/B testing to validate changes.

7. Q7

   How would you ensure a modal, popover, or drawer in the Business Suite inbox works for keyboard and assistive technology users?

   StaffOnsite/Full Loop - UX QualityAccessibilityMeta-specific

   Context: Business Suite inbox

   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 triggering element upon closure, and ensuring the modal is dismissible via the Escape key. Additionally, using appropriate ARIA roles (e.g., `role="dialog"`, `aria-modal="true"`) and labels (`aria-labelledby`, `aria-describedby`) is crucial for screen reader context. The solution should also handle background content appropriately, such as inerting it or hiding it from assistive technologies.

8. Q8

   Audit the Instagram Reels feed for touch target size. What checks would you run manually and which would you automate?

   MediumOnsite/Full Loop - ArchitectureAccessibilityMeta-specific

   Context: Instagram Reels feed

   How to answer: A strong answer would first define touch target size and its importance for accessibility, referencing WCAG 2.1 success criterion 2.5.5 (Target Size). For Instagram Reels, manual checks would involve using a finger or stylus to interact with key elements like the like, comment, share buttons, profile picture, and 'next reel' swipe area, observing for accidental activations or difficulty. Automated checks would focus on programmatic measurement of interactive element dimensions using tools like Accessibility Scanner (Android) or Xcode's Accessibility Inspector (iOS), comparing them against the recommended minimums (e.g., 44x44 CSS pixels). The candidate should also consider dynamic elements like overlaid text or interactive stickers, and how their touch targets might be affected.

9. Q9

   Design an accessible map/list toggle for the Facebook Groups composer. Explain focus order, labels, announcements, and keyboard interaction

   MediumOnsite/Full Loop - AccessibilityAccessibilityMeta-specific

   Context: Facebook Groups composer

   How to answer: A strong answer will propose a toggle component that uses a native HTML button or a `role="tablist"` with `role="tab"` elements. Focus order should be logical, moving from the toggle to the active view's content. Labels must be descriptive, like 'Show map view' or 'Show list view', and use `aria-live` regions for announcements when the view changes. Keyboard interaction should support Space/Enter for activation and potentially Left/Right arrow keys for tab-like navigation between view options if using a tablist pattern.

10. Q10

    A screen reader user cannot complete the WhatsApp Web chat list. How would you triage, reproduce, and fix the issue?

    HardOnsite/Full Loop - UX QualityAccessibilityMeta-specific

    Context: WhatsApp Web chat list

    How to answer: Triage would involve gathering user reports, identifying the specific screen reader (e.g., NVDA, JAWS, VoiceOver) and browser, and determining the exact point of failure (e.g., cannot navigate to list, cannot select chat, cannot activate chat). Reproduction requires setting up the identified environment and using the screen reader to attempt the task. The fix likely involves inspecting the DOM for missing ARIA attributes (e.g., `role="list"`, `role="listitem"`, `aria-label`, `aria-selected`), incorrect tab order, or non-semantic HTML elements, then implementing appropriate semantic HTML and ARIA roles/properties to expose the interactive elements and their states to assistive technologies.

11. Q11

    When would you use ARIA in the Messenger thread, and when would you remove it in favor of native semantics?

    StaffOnsite/Full Loop - ArchitectureAccessibilityMeta-specific

    Context: Messenger thread

    How to answer: A strong candidate would explain that ARIA is used when native HTML elements lack the semantic meaning or interactive behavior required for accessibility, such as custom UI components like a rich text editor for message input or a custom emoji picker. They would emphasize that ARIA should be removed or avoided when a native HTML element (e.g., `<button>`, `<input type="text">`, `<a>`) can convey the same semantic meaning and provide the expected accessibility features by default. The 'first rule of ARIA' – to use native HTML whenever possible – is key, as native elements offer built-in browser support for focus management, keyboard interaction, and assistive technology interpretation without extra effort. A practical example for Messenger would be using native `<ul>`/`<li>` for the message list itself, but ARIA roles like `role="region"` or `aria-live` for dynamic updates within the thread.

12. Q12

    Explain how WCAG conformance changes your component API, QA process, and release checklist for the Ads Manager dashboard

    MediumOnsite/Full Loop - AccessibilityAccessibilityMeta-specific

    Context: Ads Manager dashboard

    How to answer: WCAG conformance significantly impacts the component API by requiring props for accessibility attributes (e.g., `aria-label`, `role`), ensuring keyboard navigability, and managing focus. The QA process must integrate automated accessibility checks (linters, axe-core) and manual testing with screen readers, keyboard-only navigation, and color contrast analyzers across various user flows. The release checklist will then include mandatory sign-offs from accessibility specialists, verification of all critical user flows with assistive technologies, and documentation of any known accessibility issues with a remediation plan.

13. Q13

    How would you handle accessible errors, validation hints, and recovery paths in a high-stakes admin console?

    MediumOnsite/Full Loop - UX QualityAccessibilityMeta-specific

    Context: Marketplace listing grid

    How to answer: A strong answer would emphasize immediate, clear, and programmatically identifiable feedback. This includes using ARIA attributes like `aria-invalid`, `aria-describedby`, and `aria-live` regions for dynamic error messages. Validation hints should be provided proactively where possible (e.g., input masks, character limits) and linked to their respective inputs. Recovery paths must be explicit, guiding users on how to fix errors, offering actionable suggestions, and ensuring form state is preserved where appropriate. Focus on a layered approach combining visual, programmatic, and instructional feedback.

14. Q14

    The design for the Threads profile page uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

    HardOnsite/Full Loop - ArchitectureAccessibilityMeta-specific

    Context: Threads profile page

    How to answer: A strong candidate would first identify the specific accessibility challenges posed by 'subtle icons and gestures,' such as low contrast, small hit targets, lack of text alternatives, and difficulty for motor-impaired users. They would then propose a collaborative negotiation strategy with design, focusing on WCAG principles (Perceivable, Operable, Understandable, Robust). This involves suggesting concrete, accessible alternatives like visible labels, larger interactive areas, ARIA attributes, keyboard navigation support, and user-configurable options, while emphasizing that accessibility enhances usability for all users, not just those with disabilities. The negotiation should aim for a solution that balances design aesthetics with essential accessibility requirements, potentially through A/B testing or user research with diverse groups.

15. Q15

    How would you ensure a modal, popover, or drawer in the Meta Quest store works for keyboard and assistive technology users?

    StaffOnsite/Full Loop - AccessibilityAccessibilityMeta-specific

    Context: Meta Quest store

    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 triggering element upon close, and ensuring the modal is dismissible via the Escape key. Additionally, the modal should have appropriate ARIA roles (e.g., `role="dialog"`, `aria-modal="true"`) and labels (`aria-labelledby`, `aria-describedby`) to convey its purpose and state to screen readers. The underlying content must be made inert to assistive technologies while the modal is open.

Practice these with instant AI feedback in a live mock interview → Start a Meta Full Stack Engineer mock

Be fast and correct on coding; for design, drive the conversation; prepare impact-focused behavioral stories

Other roles at Meta

Full Stack Engineer interviews at other companies