Microsoft Frontend Engineer Interview Questions (2026)

1. 1Recruiter screen30 minEasy

   Role alignment, team options, and logistics with a recruiter.

2. 2Online assessment (Codility)60 minMedium

   Timed coding problems used mainly for early-career and campus screening in India.

3. 3Coding interview 145 minMedium

   DSA problem with production-quality code, testing, and edge cases in a shared editor.

4. 4Coding interview 245 minHard

   Harder algorithmic problem plus discussion of a past project's technical decisions.

5. 5System design round60 minHard

   Design a practical service (e.g. Teams presence, OneDrive sync) with API contracts and Azure-flavored components.

6. 6As Appropriate (AsApp) round45 minMedium

   Senior manager assesses growth mindset, long-term potential, and overall fit; effectively the closing behavioral gate.

1. Q1

   The design for the Planner board uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

   HardOnsite/Full Loop - AccessibilityAccessibilityMicrosoft-specific

   Context: Planner board

   How to answer: A strong candidate would first identify the core accessibility issues: subtle icons lack sufficient contrast or alternative text, and gesture-only interactions are inaccessible to many users. They would propose a collaborative negotiation strategy, suggesting alternatives like high-contrast icons with clear text labels, keyboard and mouse equivalents for gestures, and ARIA attributes for semantic meaning. The negotiation would focus on educating design about WCAG principles (e.g., 1.1.1 Non-text Content, 2.1.1 Keyboard, 2.5.1 Pointer Gestures) and demonstrating how accessible solutions can still be elegant and enhance usability for everyone. They would emphasize an iterative approach, involving user testing with diverse groups.

2. Q2

   How would you ensure a modal, popover, or drawer in the Word web commenting UI works for keyboard and assistive technology users?

   StaffOnsite/Full Loop - UX QualityAccessibilityMicrosoft-specific

   Context: Word web commenting UI

   How to answer: A strong answer would focus on proper focus management, ARIA roles and properties, and keyboard interaction. Key points include trapping focus within the modal, restoring focus to the trigger element upon close, and using `aria-modal="true"` with appropriate roles like `dialog` or `alertdialog`. Additionally, ensuring all interactive elements within the modal are keyboard navigable and that the Escape key closes the modal are critical. The solution should also consider announcing the modal's presence and purpose to screen reader users.

3. Q3

   Audit the Teams chat pane for touch target size. What checks would you run manually and which would you automate?

   MediumOnsite/Full Loop - ArchitectureAccessibilityMicrosoft-specific

   Context: Teams chat pane

   How to answer: A strong answer would first define touch target size and its importance for accessibility, especially on touch devices. It would then identify key interactive elements within the Teams chat pane (e.g., message input, send button, emoji picker, attachment button, message reactions, reply/forward buttons, user avatars, scrollbar). For manual checks, the candidate should describe using a finger or stylus to interact with these elements, noting any difficulty or accidental activations, and potentially using a physical ruler or screen overlay. Automated checks would involve using browser developer tools (e.g., Lighthouse, Accessibility Tree) or dedicated accessibility testing tools to identify elements smaller than the recommended 44x44 CSS pixels and flag them for review.

4. Q4

   Design an accessible admin console for the Outlook inbox. Explain focus order, labels, announcements, and keyboard interaction

   MediumOnsite/Full Loop - AccessibilityAccessibilityMicrosoft-specific

   Context: Outlook inbox

   How to answer: A strong answer will detail a logical focus order that follows visual layout, ensuring interactive elements are tabbable. It will emphasize clear, descriptive labels for all controls (e.g., `aria-label`, `label` elements) and explain how ARIA live regions or status announcements can inform users of dynamic content changes (e.g., 'Email deleted successfully'). Comprehensive keyboard interaction should be discussed, including standard tab/shift+tab for navigation, enter/space for activation, and arrow keys for navigating within groups like radio buttons or menu items, along with common hotkeys for frequent actions.

5. Q5

   A screen reader user cannot complete the Excel web grid. How would you triage, reproduce, and fix the issue?

   HardOnsite/Full Loop - UX QualityAccessibilityMicrosoft-specific

   Context: Excel web grid

   How to answer: Triage would involve gathering user reports, identifying the specific screen reader (e.g., JAWS, NVDA, Narrator) and browser combination, and pinpointing the exact interaction failing within the Excel grid (e.g., navigating cells, entering data, using formulas). Reproduction requires setting up the identified environment and attempting to perform the failing action with the screen reader active, noting spoken output and focus behavior. Fixing would likely involve inspecting the DOM for missing ARIA attributes (e.g., `aria-label`, `aria-describedby`, `aria-rowindex`, `aria-colindex`), incorrect `tabindex` values, or non-semantic HTML elements, then implementing the necessary ARIA roles, states, and properties to convey meaning and enable proper navigation and interaction.

6. Q6

   When would you use ARIA in the Azure portal dashboard, and when would you remove it in favor of native semantics?

   StaffOnsite/Full Loop - ArchitectureAccessibilityMicrosoft-specific

   Context: Azure portal dashboard

   How to answer: A strong candidate would explain that ARIA is used in the Azure portal when native HTML elements lack the semantic meaning or interactive behavior required for complex UI components, such as custom tree views, tab panels, or dynamic status updates. They would emphasize using ARIA to bridge the semantic gap for assistive technologies, ensuring custom widgets are understandable and operable. Conversely, ARIA should be removed or avoided when a native HTML element (e.g., `<button>`, `<input type="checkbox">`, `<nav>`) already provides the necessary semantics and accessibility features. The 'first rule of ARIA' – to use native HTML whenever possible – is paramount, as native elements come with built-in keyboard support, roles, states, and properties that ARIA would otherwise need to replicate manually.

7. Q7

   Explain how WCAG conformance changes your component API, QA process, and release checklist for the Office template gallery

   MediumOnsite/Full Loop - AccessibilityAccessibilityMicrosoft-specific

   Context: Office template gallery

   How to answer: WCAG conformance significantly impacts a component's API by requiring properties for accessibility attributes (e.g., `aria-label`, `role`, `tabIndex`) and ensuring keyboard navigability. The QA process shifts to include automated accessibility checks (e.g., Axe-core), manual keyboard testing, screen reader verification, and color contrast analysis. The release checklist must then incorporate mandatory accessibility audits, sign-offs from accessibility specialists, and documentation updates detailing accessibility features and limitations.

8. Q8

   How would you handle accessible errors, validation hints, and recovery paths in a high-stakes bulk action toolbar?

   MediumOnsite/Full Loop - UX QualityAccessibilityMicrosoft-specific

   Context: Edge settings page

   How to answer: A strong answer would emphasize immediate, context-sensitive feedback using ARIA live regions for errors and validation hints, ensuring screen reader users are notified without losing focus. For bulk actions, provide a summary of errors at the top of the action's results or a dedicated status area, linking to specific items where possible. Recovery paths should be clearly articulated, offering actionable steps like 'Retry Failed' or 'Undo Last Action,' and ensuring these controls are keyboard navigable and clearly labeled. Focus on a layered approach: inline validation for individual fields, a summary for bulk operations, and clear, accessible recovery options.

9. Q9

   The design for the SharePoint document library uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

   HardOnsite/Full Loop - ArchitectureAccessibilityMicrosoft-specific

   Context: SharePoint document library

   How to answer: A strong candidate would start by identifying 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, focusing on educating design about WCAG principles and Microsoft's own accessibility standards. Practical solutions would include advocating for visible focus indicators, keyboard equivalents for gestures, text labels or tooltips for icons, and user-configurable display options. The negotiation would emphasize finding design-friendly compromises that meet accessibility requirements without sacrificing core aesthetics, potentially through progressive enhancement or user personalization.

10. Q10

    How would you ensure a modal, popover, or drawer in the OneDrive file explorer works for keyboard and assistive technology users?

    StaffOnsite/Full Loop - AccessibilityAccessibilityMicrosoft-specific

    Context: OneDrive file explorer

    How to answer: A strong candidate would emphasize managing focus, keyboard interaction, and ARIA attributes. They would explain how to trap focus within the modal, ensuring users can only interact with its content until dismissed. Proper keyboard navigation (Tab, Shift+Tab, Escape) for closing and interacting with elements inside is crucial. Finally, they would detail the use of ARIA roles like `dialog` or `alertdialog`, `aria-modal`, `aria-labelledby`, and `aria-describedby` to convey the modal's presence and purpose to assistive technologies.

11. Q11

    Audit the Copilot side panel for focus management. What checks would you run manually and which would you automate?

    MediumOnsite/Full Loop - UX QualityAccessibilityMicrosoft-specific

    Context: Copilot side panel

    How to answer: A strong candidate would outline manual checks including tabbing through all interactive elements to ensure logical order, checking for visual focus indicators, and verifying focus returns to the trigger element upon closing the panel. For automation, they would suggest using tools like Axe-core or Lighthouse to detect missing ARIA attributes (e.g., `aria-modal`), invalid tab indices, and elements that are not programmatically focusable. They would also mention writing end-to-end tests to confirm focus trapping within the modal and proper focus restoration.

12. Q12

    Design an accessible upload flow for the Power BI report view. Explain focus order, labels, announcements, and keyboard interaction

    MediumOnsite/Full Loop - ArchitectureAccessibilityMicrosoft-specific

    Context: Power BI report view

    How to answer: A strong answer will describe an upload flow starting with a clearly labeled 'Upload Report' button. Upon activation, a modal dialog should appear, containing a 'Browse' button (or drag-and-drop zone) and a text input for file path, all with proper ARIA labels. Focus order should be logical: 'Browse' button, file input, 'Upload' button, 'Cancel' button. Progress updates (e.g., 'Uploading file. 50% complete.') must be announced via ARIA live regions, and success/failure messages should be clearly communicated. Keyboard interactions must include Tab for navigation, Space/Enter for activation, and Escape to close the modal.

13. Q13

    A screen reader user cannot complete the Planner board. How would you triage, reproduce, and fix the issue?

    HardOnsite/Full Loop - AccessibilityAccessibilityMicrosoft-specific

    Context: Planner board

    How to answer: The candidate should outline a systematic approach starting with understanding the user's specific pain point, likely by interviewing them or reviewing bug reports. Reproduction involves using a screen reader (e.g., NVDA, JAWS, Narrator) to navigate the Planner board, focusing on keyboard-only interaction and common accessibility pitfalls like missing labels, incorrect ARIA roles, or inaccessible drag-and-drop. The fix would involve inspecting the DOM for semantic HTML, ARIA attributes (roles, states, properties), keyboard focus management (tabindex), and providing accessible alternatives for complex interactions. Finally, testing with multiple screen readers and assistive technologies is crucial.

14. Q14

    When would you use ARIA in the Word web commenting UI, and when would you remove it in favor of native semantics?

    StaffOnsite/Full Loop - UX QualityAccessibilityMicrosoft-specific

    Context: Word web commenting UI

    How to answer: ARIA should be used when native HTML elements cannot convey the necessary semantic meaning or interactive behavior for assistive technologies, such as custom UI components in the Word web commenting system (e.g., a custom 'reply' button that behaves like a menu, or a complex threaded comment view). It's crucial for widgets like custom dialogs, tab panels, or tree views. Conversely, ARIA should be removed or avoided when a native HTML element already provides the required semantics and functionality. For instance, a standard `<button>` for 'Post Comment' or a `<textarea>` for the comment input field should not have redundant ARIA roles or properties, as native elements are inherently accessible and often better supported. The 'first rule of ARIA' states that if a native HTML element with the desired semantic and accessible characteristics exists, use it instead.

15. Q15

    Explain how reduced motion changes your component API, QA process, and release checklist for the Teams chat pane

    MediumOnsite/Full Loop - ArchitectureAccessibilityMicrosoft-specific

    Context: Teams chat pane

    How to answer: Reduced motion significantly impacts the component API by requiring props or context to conditionally render animations or static alternatives. The QA process must include dedicated test cases for both motion-enabled and reduced-motion states, verifying visual stability and functionality without animations. The release checklist needs explicit sign-offs from accessibility and UX teams, ensuring all motion-related features have appropriate reduced-motion fallbacks implemented and tested across supported browsers and OS settings.

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

Practice coding with clear communication; show a growth mindset; know your past projects deeply

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

Other roles at Microsoft

Frontend Engineer interviews at other companies