Microsoft Full Stack 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 specific accessibility guidelines (WCAG 2.1+) that subtle icons and gestures might violate, such as non-text contrast, sufficient target size, and keyboard/assistive technology operability. They would propose a collaborative approach with design, suggesting alternatives like high-contrast modes, explicit text labels, tooltips, and keyboard shortcuts. The negotiation would involve demonstrating the impact on users with disabilities using data or user stories, and offering phased implementation or A/B testing to balance accessibility with design aesthetics. The candidate should emphasize that accessibility is a core product quality, not an afterthought, aligning with Microsoft's inclusive design principles.

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 attributes, and keyboard interaction. 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. Crucially, it would involve using appropriate ARIA roles (e.g., `role="dialog"`, `aria-modal="true"`) and labels (`aria-labelledby`, `aria-describedby`) to convey the modal's purpose and state to screen readers. Keyboard navigation within the modal should follow standard tab order, and the modal should be programmatically hidden from the accessibility tree when not active.

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 begin by stating the WCAG 2.1 AA requirement for touch target size (44x44 CSS pixels) and explain its importance for accessibility, especially on touch devices. For manual checks, I would focus on interactive elements within the chat pane, such as message send buttons, emoji pickers, attachment icons, and user avatars, using a device with touch input and a ruler or screen measurement tool. Automation would involve using browser developer tools (e.g., Chrome Lighthouse, Edge DevTools Accessibility tab) or dedicated accessibility testing frameworks (e.g., Axe-core) to identify elements below the minimum size, particularly for static or less frequently interacted components. I would also consider dynamic elements that appear on hover or focus, ensuring they meet the criteria when active.

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 all interactive elements are reachable via keyboard. It will emphasize clear, descriptive ARIA labels and `aria-describedby` for complex elements, providing sufficient context for screen reader users. Crucially, it will explain how dynamic content changes and form submissions trigger `aria-live` region announcements, and outline comprehensive keyboard interactions including Tab, Shift+Tab, Enter, Space, and arrow keys for navigation within components like tables or tree views, adhering to WAI-ARIA authoring practices.

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), browser, and Excel web grid version, and pinpointing the exact interaction failing (e.g., navigating cells, entering data, using formulas). Reproduction requires setting up the same environment, using the identified screen reader, and attempting the failing interaction. Fixing would likely involve inspecting the DOM for missing ARIA attributes (e.g., `aria-rowindex`, `aria-colindex`, `aria-describedby`), incorrect `role` assignments (e.g., `role="grid"`, `role="row"`, `role="gridcell"`), or improper keyboard navigation handling (e.g., Tab/Shift+Tab for grid navigation, arrow keys for cell movement).

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: ARIA should be used in the Azure portal when native HTML elements cannot convey the necessary semantic meaning or interactive behavior for assistive technologies. This includes custom components like a complex drag-and-drop dashboard widget, or dynamic content updates that need live region announcements. Conversely, ARIA should be removed or avoided when a native HTML element (e.g., `<button>`, `<input type="checkbox">`, `<nav>`) already provides the correct semantic meaning and built-in accessibility features. Overusing ARIA on elements with inherent semantics can create redundancy, conflicts, and degrade accessibility rather than improve it, adhering to the 'first rule of ARIA' principle.

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 necessitates changes to component APIs by requiring explicit properties for accessibility attributes (e.g., `aria-label`, `role`, `tabIndex`), ensuring semantic HTML output, and providing keyboard interaction handlers. The QA process must integrate automated accessibility checks (linters, axe-core), manual keyboard navigation testing, screen reader testing across multiple browsers, and color contrast verification. The release checklist will then include mandatory sign-offs for accessibility test results, documentation of accessibility features, and verification that all critical WCAG success criteria (e.g., A/AA) are met for the template components.

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: For accessible errors, I would use ARIA live regions (e.g., `aria-live="assertive"`) to announce validation failures immediately without interrupting the user's flow, linking errors to their respective fields using `aria-describedby` or `aria-labelledby`. Validation hints should be provided proactively using `aria-describedby` to associate them with input fields, appearing on focus or hover, and clearly indicating expected formats or constraints. For recovery paths, I'd ensure clear, actionable error messages with direct links or buttons to resolve issues, such as 'Retry' or 'Edit Invalid Items,' making sure these controls are keyboard-navigable and have appropriate ARIA labels. A summary of all errors at the top of the form or toolbar, with anchor links to each problematic field, would also be crucial.

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 first emphasize understanding the specific accessibility issues posed by subtle icons/gestures (e.g., for low vision, motor impairment, screen reader users). They would then propose a collaborative negotiation strategy, focusing on offering concrete, accessible alternatives that meet design goals (e.g., high-contrast icons, keyboard navigable actions, ARIA labels, visible focus states). The discussion should center on educating design about accessibility standards (WCAG) and Microsoft's commitment, demonstrating how accessibility enhances usability for everyone, and finding a balanced solution that preserves aesthetic intent while ensuring inclusivity. Prioritization of critical functionalities and phased implementation could also be discussed.

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 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 using `aria-modal="true"`, `aria-labelledby`, and `aria-describedby` for semantic context. Keyboard navigation must allow users to close the modal (e.g., via Esc key) and interact with elements inside it using Tab and Shift+Tab, while preventing interaction with background content. Additionally, ensure the modal is announced correctly by screen readers when it opens and closes.

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 answer would begin by defining focus management's importance for keyboard and assistive technology users. For manual checks, candidates should detail tabbing order (logical flow, no traps), visual focus indicator presence and clarity, and focus restoration upon modal/panel closure. Automated checks would involve using tools like Axe-core or Lighthouse for basic tab order and focusability issues, and potentially custom Playwright/Selenium scripts to verify focus trapping within the panel and correct focus return. The answer should emphasize the iterative nature of testing and the combination of manual and automated approaches for comprehensive coverage.

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 candidate would design an upload flow that prioritizes keyboard navigation and screen reader compatibility. They would detail a logical focus order, ensuring interactive elements are tabbable and follow a visual left-to-right, top-to-bottom flow. Labels would be explicit and programmatically associated with their controls, using `aria-label` or `aria-labelledby` for custom components. Screen reader announcements would provide real-time feedback on upload progress, success, or failure, leveraging ARIA live regions. Keyboard interactions would include standard keys like Enter/Space for activation, Escape for closing modals, and arrow keys for navigation within lists or radio groups.

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: Triage would involve gathering user reports, identifying the specific screen reader (e.g., NVDA, JAWS, Narrator), browser, and exact steps where the user gets stuck. Reproduction requires setting up the identified environment and attempting to navigate the Planner board using only keyboard and the specified screen reader. Fixing would likely involve inspecting the DOM for missing ARIA attributes (e.g., `aria-labelledby`, `aria-describedby`, `aria-roledescription`), incorrect tab order, or inaccessible custom controls, then implementing the necessary semantic HTML5 elements or ARIA roles and properties to ensure proper communication with the assistive technology.

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 accessibility, such as custom UI components in the Word web commenting system (e.g., a custom emoji picker, a complex threaded reply widget, or a custom button with a dynamic state like 'resolve comment'). It's essential for roles, states, and properties that native HTML lacks. ARIA should be removed or avoided when a native HTML element already provides the equivalent semantic meaning and accessibility features, adhering to the 'first rule of ARIA' (use native HTML whenever possible). This applies to standard interactive elements like buttons, links, form inputs, and headings within the commenting UI, which inherently provide accessibility via the browser's accessibility tree.

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 component APIs by requiring explicit `prefers-reduced-motion` media query checks or a prop-driven approach to disable or simplify animations. The QA process must include dedicated test cases for both motion and reduced motion settings, verifying visual stability and functionality without distracting animations. The release checklist needs an item to confirm reduced motion compliance across all new features, ensuring accessibility standards are met before deployment to a large user base like Microsoft Teams.

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

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

Other roles at Microsoft

Full Stack Engineer interviews at other companies