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

   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.

3. Q3

   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.

4. Q4

   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.

5. Q5

   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.

6. Q6

   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.

7. Q7

   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.

8. Q8

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

   MediumOnsite/Full Loop - AccessibilityAccessibilityMicrosoft-specific

   Context: Outlook inbox

   How to answer: A strong answer would emphasize immediate, context-sensitive feedback using ARIA live regions for screen reader users, ensuring error messages are programmatically linked to their respective input fields (aria-describedby, aria-invalid). For validation hints, provide clear, concise instructions before submission, and for recovery, offer actionable steps within or near the error message, potentially with direct links to relevant documentation or support. Visual cues (color, icons) should always be paired with text alternatives, and the focus management should guide users to the first error on form submission.

9. Q9

   Design an accessible inline editor for the Edge settings page. Explain focus order, labels, announcements, and keyboard interaction

   MediumOnsite/Full Loop - UX QualityAccessibilityMicrosoft-specific

   Context: Edge settings page

   How to answer: A strong candidate will describe an inline editor that, when activated, transforms static text into an editable input field. They will explain how focus shifts directly to the input, which is clearly labeled using `aria-label` or `aria-labelledby` and has an appropriate role. Upon activation, screen readers should announce the editor's presence and instructions. Keyboard interactions must include `Enter` to save, `Escape` to cancel (reverting to original text), and `Tab` to navigate out, ensuring focus returns to the original trigger or a logical next element. Validation feedback must also be accessible.

10. Q10

    How would you support dark mode, high contrast, localization, and reduced motion in the Outlook inbox's CSS architecture?

    MediumOnsite/Full Loop - CodingCSSMicrosoft-specific

    Context: Outlook inbox

    How to answer: A strong candidate would discuss leveraging CSS media queries like `prefers-color-scheme` for dark mode, `prefers-contrast` for high contrast, and `prefers-reduced-motion` for animations. For localization, they would explain using CSS variables (custom properties) to manage directionality (`dir` attribute and `[dir='rtl']` selector) and potentially font-family adjustments. They would emphasize a token-based approach with CSS variables for colors and spacing, allowing easy theme switching and maintainability across all these concerns. Finally, they would mention a robust component library that inherently supports these adaptations.

11. Q11

    How would you implement skeleton loading and transitions in the Azure portal dashboard while avoiding layout shift and motion discomfort?

    HardPhone/Virtual Technical ScreenCSSMicrosoft-specific

    Context: Azure portal dashboard

    How to answer: A strong answer would detail using CSS `min-height` and `min-width` or fixed dimensions for skeleton elements to reserve space, preventing layout shifts. It would then describe using CSS `background-gradient` animations (e.g., `linear-gradient` with `animation`) for the shimmering effect, ensuring hardware acceleration. For transitions, it would suggest `opacity` or `transform` (scale, translate) for smooth fades or movements, rather than `width`/`height`, combined with `prefers-reduced-motion` media query to respect user preferences and avoid motion discomfort. Finally, it would touch upon using a dedicated skeleton component library or custom CSS classes for reusability and consistency across the Azure portal.

12. Q12

    A responsive notifications center in the Edge settings page fails at tablet widths. How would you debug CSS cascade, layout containment, and overflow?

    MediumOnsite/Full Loop - Frontend FundamentalsCSSMicrosoft-specific

    Context: Edge settings page

    How to answer: Start by inspecting the element at tablet width using browser developer tools, focusing on the computed styles to understand the cascade. Identify conflicting rules, especially those from media queries or specificity issues. Then, examine the box model and layout properties (flexbox, grid, block) for the notification container and its parents to diagnose containment problems. Finally, check `overflow` properties on relevant elements to see if content is being clipped or spilling out, and adjust dimensions or display properties accordingly.

13. Q13

    Design a CSS strategy for an embedded widget in the Planner board that must coexist with third-party page styles

    MediumOnsite/Full Loop - CodingCSSMicrosoft-specific

    Context: Planner board

    How to answer: A strong candidate would propose using a Shadow DOM for complete style encapsulation, explaining its benefits for isolation. Alternatively, they might suggest a CSS-in-JS solution with scoped styles or a BEM-like naming convention combined with a highly specific CSS selector strategy (e.g., `[data-planner-widget] .my-class`). They should also discuss using `all: unset` or `all: initial` on the widget's root element to reset inherited styles, and potentially leveraging `iframe` for extreme isolation if Shadow DOM isn't feasible or sufficient, acknowledging its drawbacks.

14. Q14

    Build the layout strategy for the Teams chat pane using cascade layers. What rules would you choose and where could the approach break?

    EasyPhone/Virtual Technical ScreenCSSMicrosoft-specific

    Context: Teams chat pane

    How to answer: A strong candidate would propose using `@layer` to manage the layout strategy for the Teams chat pane, defining layers such as `base`, `components`, `layout`, and `utilities`. The `layout` layer would contain rules for the main chat container, message list, input area, and header, ensuring these structural elements have higher specificity than individual components. They would explain that cascade layers provide explicit control over specificity, preventing unexpected overrides. The approach could break if layers are not defined logically, if developers forget to assign rules to layers, or if `!important` is overused, bypassing the layer order.

15. Q15

    How would you create a themeable component for the Excel web grid using custom properties and design tokens without creating global style regressions?

    MediumOnsite/Full Loop - Frontend FundamentalsCSSMicrosoft-specific

    Context: Excel web grid

    How to answer: A strong answer would propose using CSS Custom Properties (variables) to define themeable aspects like colors, fonts, and spacing. These custom properties would be set at a component-specific scope (e.g., a root element for the grid component) to prevent global regressions. Design tokens, managed centrally, would feed into these custom properties, ensuring consistency across the Excel web application. The theming mechanism would involve updating the values of these custom properties dynamically, either via JavaScript or by swapping CSS files/classes that define these variables, without directly modifying existing styles.

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