Meta Frontend 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 describe a comment composer with a clearly defined focus order, typically from the 'Add a comment' button/link to the textarea, then to 'Post' and 'Cancel' buttons. It will emphasize explicit ARIA labels for the textarea and buttons, ensuring screen reader announcements are informative (e.g., 'Comment text area, type your comment', 'Post comment button'). Keyboard interactions should include Tab for navigation, Shift+Tab for reverse, Enter/Space for button activation, and potentially Esc to close/clear the composer without posting. Validation feedback should also be announced accessibly.

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: Triage would involve gathering user reports, identifying specific screen reader (e.g., VoiceOver, NVDA) and browser combinations, and checking for recent deployments. Reproduction requires using the identified screen reader and browser, navigating to the Threads profile page, and attempting common actions like editing bio, changing profile picture, or following/unfollowing. The fix would likely involve inspecting the DOM for missing ARIA attributes (e.g., `aria-label`, `aria-describedby`), incorrect semantic HTML (e.g., using `div` instead of `button` or `a`), improper focus management (e.g., tabbing order, focus traps), or dynamic content updates that aren't announced.

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: ARIA should be used in the Meta Quest store primarily when native HTML elements cannot convey the necessary semantic meaning or interactive behavior to assistive technologies, such as for custom UI components (e.g., a custom slider, tab panel, or tree view). It's crucial for making rich, non-standard VR UI accessible. Conversely, ARIA should be removed or avoided when a native HTML element already provides the desired semantic meaning and accessibility features (e.g., using a `<button>` instead of a `<div>` with `role="button"`). Overusing ARIA on native elements can create redundancy or even conflict with browser accessibility trees, leading to a worse user experience for assistive technology users. The principle is to use native semantics first, and ARIA only when native isn't sufficient.

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: Implementing robust error recovery for the Creator insights panel necessitates changes across its component API to include error states and retry mechanisms, impacting prop types and internal state management. The QA process must expand to rigorously test various failure scenarios, including network outages, API errors, and data inconsistencies, ensuring graceful degradation and user guidance. The release checklist will then incorporate specific items for error recovery validation, such as verifying accessibility of error messages, logging mechanisms, and the efficacy of retry/fallback UIs.

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. This includes using ARIA attributes like `aria-invalid` and `aria-describedby` to link error messages to their respective input fields, ensuring screen readers announce validation states. For recovery, provide specific, actionable advice within the error message itself, guiding the user on how to fix the issue. Visual cues like red borders and icons should complement the ARIA attributes, and focus management might be used to direct users to the first error on submission.

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," such as lack of discoverability, reliance on motor skills, and poor screen reader compatibility. They would then propose a collaborative negotiation strategy with design, focusing on providing alternative, redundant access methods (e.g., visible text labels, keyboard shortcuts, clear ARIA attributes) rather than removing the subtle design. The negotiation would emphasize user testing with diverse groups and data-driven arguments about user reach and compliance, aiming for a solution that enhances accessibility without entirely sacrificing the desired aesthetic.

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 trigger element upon close, and ensuring the modal is dismissible via the Escape key. Additionally, the modal should have an appropriate `role` (e.g., `dialog` or `alertdialog`), a clear accessible name (`aria-labelledby`), and indicate its state (`aria-modal`). The solution should also address background content management, such as inerting 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 begin by defining touch target size and its importance for accessibility, referencing WCAG 2.1 success criterion 2.5.5 (Target Size) and 2.5.8 (Target Size (Minimum)). Manually, I would check critical interactive elements like the like, comment, share, and save buttons, the profile avatar, and the 'more options' ellipsis, using a finger or stylus to gauge usability and developer tools to inspect computed dimensions. Automation would focus on identifying all interactive elements (buttons, links, inputs) and programmatically checking their `width` and `height` against the WCAG minimums (44x44 CSS pixels) and Meta's internal larger targets, flagging any that fall below these thresholds. I'd also consider dynamic elements and state changes where targets might shrink.

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 would propose a toggle using a `role="tablist"` with `role="tab"` for each view (Map, List). Focus order should follow visual order, with `tabindex="0"` on the active tab and `-1` on inactive tabs, managed via JavaScript. Each tab needs an `aria-label` (e.g., 'View as Map', 'View as List') or descriptive text for screen reader announcements. Keyboard interaction must allow left/right arrow keys to navigate between tabs, automatically activating the new tab and updating `tabindex` and `aria-selected` states.

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 more details: what screen reader, browser, OS, and specific steps lead to the failure. Reproducing requires setting up the exact environment and using the screen reader (e.g., NVDA, VoiceOver) to navigate the WhatsApp Web chat list. The fix likely involves inspecting the DOM for missing ARIA attributes (e.g., `role="list"`, `role="listitem"`, `aria-label` for chat names), incorrect tab order, or non-semantic HTML elements used for interactive components. Testing the fix with the screen reader is crucial to ensure full accessibility.

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: ARIA should be used in the Messenger thread when native HTML elements lack the semantic meaning or interactive behavior required for accessibility, such as custom UI components like a custom emoji picker or a complex message reaction system. It's crucial for conveying roles, states, and properties that assistive technologies need. Conversely, ARIA should be removed or avoided when native HTML elements already provide the necessary semantics, following the 'first rule of ARIA' (use native HTML whenever possible). Examples include standard buttons, links, headings, and form inputs, where adding ARIA would be redundant or even detrimental.

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`, `tabIndex`), ensuring semantic HTML output, and supporting keyboard navigation. The QA process must integrate automated accessibility checks (e.g., Axe-core), manual keyboard testing, screen reader testing (VoiceOver, NVDA), and color contrast verification. The release checklist should include a mandatory accessibility audit sign-off, documentation of accessibility features, and verification that all interactive elements are keyboard accessible and have proper ARIA attributes.

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 actionable feedback. This includes using ARIA live regions for dynamic error messages, associating error messages directly with their input fields using `aria-describedby` and `aria-invalid`, and providing explicit visual cues (e.g., borders, icons). For recovery, candidates should discuss clear instructions, 'fix it' links, and ensuring focus management guides users to the problematic field. Finally, consider global error summaries for complex forms and ensuring all feedback is available to assistive technologies.

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 specific accessibility concerns with 'subtle icons and gestures,' such as lack of text alternatives for icons, insufficient contrast, and discoverability issues for gestures. They would then propose concrete solutions like adding visible text labels, ARIA attributes (e.g., `aria-label`, `aria-describedby`), ensuring sufficient color contrast, and offering alternative interaction methods (e.g., keyboard navigation, visible buttons for gestures). The negotiation with design would involve presenting these accessibility requirements as essential for usability and legal compliance, demonstrating how they can be integrated without compromising the core aesthetic, perhaps through progressive disclosure or user-configurable options. Finally, they would emphasize the importance of user testing with assistive technologies to validate the proposed solutions.

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 emphasize proper focus management, including trapping focus within the modal and restoring it upon close. It should detail the use of ARIA attributes like `role="dialog"`, `aria-modal="true"`, `aria-labelledby`, and `aria-describedby` to convey semantic meaning. Keyboard interaction, specifically the `Escape` key for closing and `Tab`/`Shift+Tab` for navigation, is crucial. Finally, ensuring the underlying page is inaccessible to assistive technologies while the modal is open, typically via `aria-hidden="true"` on the main content, is a key consideration.

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

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

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

Other roles at Meta

Frontend Engineer interviews at other companies