Google Frontend Engineer Interview Questions (2026)

1. 1Recruiter screen30 minEasy

   Background, level calibration, and process walkthrough with a recruiter.

2. 2Technical phone screen45 minHard

   One or two DSA problems solved live in a shared editor with emphasis on optimal complexity and clean code.

3. 3Coding round (onsite)45 minHard

   Harder DSA with follow-up constraint changes; interviewer scores GCA and RRK on a rubric.

4. 4System design round45 minHard

   Design a planet-scale system (e.g. a piece of Search or YouTube) with explicit capacity estimates and tradeoffs.

5. 5Googleyness & Leadership45 minMedium

   Behavioral round on collaboration, ambiguity, and user-first judgment scored against Google's structured rubric.

6. 6Hiring Committee review30 minMedium

   No candidate interaction; the written feedback packet is reviewed and the hire/no-hire decision is made, followed by team matching.

1. Q1

   When would you use ARIA in the Meet chat panel, and when would you remove it in favor of native semantics?

   StaffOnsite/Full Loop - AccessibilityAccessibilityGoogle-specific

   Context: Meet chat panel

   How to answer: ARIA should be used when native HTML elements cannot convey the necessary semantic meaning or interactive behavior for assistive technologies in the Meet chat panel. Examples include custom UI components like a 'send message' button that looks like an icon but needs an accessible name, or a custom emoji picker that requires ARIA roles (e.g., `role="grid"`, `role="gridcell"`) and states (e.g., `aria-selected`) to be navigable and understandable. Conversely, ARIA should be removed or avoided when native HTML elements already provide the correct semantics, such as using a standard `<button>` for a clickable action instead of a `<div>` with `role="button"`, or a `<textarea>` for the message input. Overusing ARIA on elements that already have inherent meaning can create redundancy or conflicts for screen readers, leading to a worse user experience.

2. Q2

   Explain how error recovery changes your component API, QA process, and release checklist for the Drive file browser

   MediumOnsite/Full Loop - UX QualityAccessibilityGoogle-specific

   Context: Drive file browser

   How to answer: Error recovery significantly impacts the component API by requiring explicit error states, retry mechanisms, and clear prop definitions for displaying messages and actions. The QA process must expand to include dedicated test cases for various error scenarios (network, permission, data corruption), accessibility of error messages, and recovery paths. The release checklist needs to incorporate checks for comprehensive error logging, user-facing error message clarity, and robust rollback strategies in case of widespread error conditions.

3. Q3

   How would you handle accessible errors, validation hints, and recovery paths in a high-stakes profile settings form?

   MediumOnsite/Full Loop - ArchitectureAccessibilityGoogle-specific

   Context: Shopping comparison page

   How to answer: A strong answer would emphasize immediate, clear, and programmatically accessible feedback. For errors, use `aria-invalid` on the input and `aria-describedby` linking to a live region (e.g., `aria-live="assertive"`) containing the error message. Validation hints should be visible on focus/hover and linked via `aria-describedby`, ideally with `aria-live="polite"` if they update dynamically. Recovery paths involve clear instructions within the error message, direct links to relevant sections, or suggestions for correction, ensuring keyboard and screen reader users can easily understand and act on them.

4. Q4

   The design for the Translate result panel uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

   HardOnsite/Full Loop - AccessibilityAccessibilityGoogle-specific

   Context: Translate result panel

   How to answer: A strong candidate would first identify the core accessibility issues with "subtle icons and gestures," specifically for users with visual impairments, motor impairments, and cognitive disabilities. They would propose a collaborative approach with design, advocating for clear, redundant text labels for icons and keyboard/alternative input methods for gestures. The negotiation would involve presenting concrete examples of how current design violates WCAG principles (e.g., 1.1.1 Non-text Content, 2.1.1 Keyboard, 2.5.1 Pointer Gestures) and suggesting alternative, accessible design patterns. Finally, they would emphasize the business value of accessibility, including broader user reach and legal compliance, to align with design goals.

5. Q5

   How would you ensure a modal, popover, or drawer in the Photos album grid works for keyboard and assistive technology users?

   StaffOnsite/Full Loop - UX QualityAccessibilityGoogle-specific

   Context: Photos album grid

   How to answer: A strong answer would cover managing focus, keyboard navigation, and ARIA roles/attributes. Specifically, when the modal opens, focus should be trapped within it and moved to the first interactive element. Keyboard users must be able to navigate all interactive elements inside the modal using Tab/Shift+Tab and close it with Escape. Appropriate ARIA roles (e.g., `role="dialog"`, `aria-modal="true"`) and attributes (`aria-labelledby`, `aria-describedby`) are crucial for assistive technologies to understand the modal's context and state. Upon closing, focus must be returned to the element that triggered the modal.

6. Q6

   Audit the Search results page for touch target size. What checks would you run manually and which would you automate?

   MediumOnsite/Full Loop - ArchitectureAccessibilityGoogle-specific

   Context: Search results page

   How to answer: A strong answer would first define touch target size and its importance for accessibility, particularly on a search results page with many interactive elements. It would then outline manual checks, focusing on visual inspection for spacing, using browser developer tools to measure actual element sizes, and testing with various finger sizes and input methods. For automation, the candidate should mention using Lighthouse audits, axe-core, or similar accessibility linters integrated into CI/CD, specifically looking for rules related to minimum touch target size (e.g., WCAG 2.1 SC 2.5.5 Target Size). Finally, they should discuss how to interpret results and prioritize fixes based on user impact.

7. Q7

   Design an accessible inline editor for the Gmail inbox. Explain focus order, labels, announcements, and keyboard interaction

   MediumOnsite/Full Loop - AccessibilityAccessibilityGoogle-specific

   Context: Gmail inbox

   How to answer: A strong answer would describe an inline editor that appears on 'Enter' or 'Space' when a message subject/body is focused, transforming the static text into an editable input field. Focus should automatically shift to the editor, and a screen reader announcement like 'Editing message subject' should occur. Keyboard navigation within the editor should be standard (arrows, Home/End, Ctrl+arrows), with 'Escape' to cancel and revert, and 'Enter' (or Ctrl+Enter for multiline) to save. Labels for the editor should be programmatically associated using `aria-label` or `aria-labelledby` referencing the original content, ensuring clear context for assistive technologies.

8. Q8

   A screen reader user cannot complete the Google Docs editor. How would you triage, reproduce, and fix the issue?

   HardOnsite/Full Loop - UX QualityAccessibilityGoogle-specific

   Context: Google Docs editor

   How to answer: Triage would involve gathering user reports, identifying specific screen reader/browser combinations, and pinpointing the exact interaction or feature that's failing. Reproduction requires using the reported screen reader (e.g., NVDA, JAWS, VoiceOver) with the specified browser to step through the user's workflow in Google Docs, observing the screen reader's output and focus management. The fix would likely involve inspecting the DOM for missing ARIA attributes (roles, states, properties), incorrect semantic HTML, or improper focus management (e.g., `tabindex`, programmatic focus shifts). Debugging tools like browser accessibility trees and screen reader loggers would be crucial.

9. Q9

   When would you use ARIA in the Maps place picker, and when would you remove it in favor of native semantics?

   StaffOnsite/Full Loop - ArchitectureAccessibilityGoogle-specific

   Context: Maps place picker

   How to answer: ARIA should be used in the Maps place picker when native HTML elements cannot convey the necessary semantic meaning or interactive behavior to assistive technologies. This includes custom UI components like a visually hidden live region for search results (aria-live), custom combobox implementations for place suggestions (role="combobox", aria-expanded, aria-autocomplete, aria-controls), or custom buttons with non-standard actions (aria-label). ARIA should be removed or avoided when a native HTML element already provides the equivalent semantic meaning and accessibility features, such as using a standard `<button>` for a clickable action instead of `<div>` with `role="button"`, or an `<input type="text">` for text entry instead of a `<div>` with `role="textbox"` and custom event handlers. Prioritize native semantics for robustness, browser optimization, and reduced maintenance.

10. Q10

    Explain how WCAG conformance changes your component API, QA process, and release checklist for the YouTube watch page

    MediumOnsite/Full Loop - AccessibilityAccessibilityGoogle-specific

    Context: YouTube watch page

    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 managing focus. The QA process must incorporate automated accessibility checks (Lighthouse, axe-core) and manual testing with assistive technologies (screen readers, keyboard navigation) across various browsers. The release checklist will then include mandatory accessibility audit sign-offs, documentation of accessibility features, and verification of bug fixes related to WCAG violations before deployment.

11. Q11

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

    MediumOnsite/Full Loop - UX QualityAccessibilityGoogle-specific

    Context: Google Cloud console

    How to answer: A strong answer would emphasize immediate, clear, and programmatically accessible feedback. This includes using ARIA live regions for dynamic error messages, associating error messages directly with their input fields using `aria-describedby` or `aria-errormessage`, and providing specific, actionable recovery paths. Visual cues (color, icons) should always be paired with text alternatives. For complex panels, a summary of errors at the top of the form, with links to the relevant fields, is also crucial.

12. Q12

    The design for the Calendar scheduling view uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

    HardOnsite/Full Loop - ArchitectureAccessibilityGoogle-specific

    Context: Calendar scheduling view

    How to answer: A strong candidate would first identify the core accessibility issues with 'subtle icons and gestures,' specifically for users with visual impairments, motor impairments, or cognitive disabilities. They would then propose a collaborative negotiation strategy, suggesting alternatives like visible text labels for icons, keyboard navigation support, and clear focus indicators for gestures. The discussion would involve advocating for WCAG compliance (e.g., perceivable, operable, understandable) while seeking design compromises that maintain aesthetic goals but enhance usability for all users. The candidate should emphasize user testing with diverse groups to validate proposed solutions.

13. Q13

    How would you ensure a modal, popover, or drawer in the Meet chat panel works for keyboard and assistive technology users?

    StaffOnsite/Full Loop - AccessibilityAccessibilityGoogle-specific

    Context: Meet chat panel

    How to answer: A strong answer would focus on proper focus management, ARIA attributes, and keyboard interaction patterns. Key points include trapping focus within the modal, restoring focus to the triggering element upon close, and ensuring the modal is dismissible via the Esc key. Additionally, the modal should be correctly identified using ARIA roles like `dialog` or `alertdialog`, labeled with `aria-labelledby` and optionally described with `aria-describedby`, and its open/closed state managed with `aria-hidden` on the main content. Semantic HTML for the modal structure and proper z-index management are also crucial.

14. Q14

    Audit the Drive file browser for focus management. What checks would you run manually and which would you automate?

    MediumOnsite/Full Loop - UX QualityAccessibilityGoogle-specific

    Context: Drive file browser

    How to answer: A strong answer would outline manual checks including tabbing through all interactive elements (files, folders, buttons, search, user menu) to ensure logical order and visibility of focus indicator, verifying focus returns to the correct element after modal/dialog closure, and testing keyboard navigation within complex components like context menus or grid views. For automation, the candidate should mention using browser dev tools (e.g., Lighthouse accessibility audits) to detect missing `tabindex` or non-focusable elements that should be, and employing end-to-end testing frameworks (like Playwright or Cypress) to programmatically tab through the application and assert focus on expected elements, especially after user interactions or state changes. They should also mention checking for proper ARIA attributes related to focus management, such as `aria-activedescendant` for grid navigation.

15. Q15

    Design an accessible sharing dialog for the Shopping comparison page. Explain focus order, labels, announcements, and keyboard interaction

    MediumOnsite/Full Loop - ArchitectureAccessibilityGoogle-specific

    Context: Shopping comparison page

    How to answer: A strong answer will describe a modal dialog pattern, ensuring it traps focus within the dialog when open and returns focus to the trigger element upon closing. It should detail a logical focus order, typically starting with a close button, then sharing options (e.g., copy link, social media icons), and finally a cancel button. The answer must specify ARIA attributes for labels (aria-labelledby, aria-label) and descriptions (aria-describedby) to provide context for screen reader users, along with live region announcements for critical actions like 'Link copied to clipboard'. Keyboard interactions should cover Tab/Shift+Tab for navigation, Enter/Space for activation, and Esc for closing the dialog.

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

Master DSA and communicate your thinking out loud; use Google's structured Explain-Clarify-Improve approach; prepare for Googleyness/behavioral

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

Other roles at Google

Frontend Engineer interviews at other companies