Google Full Stack 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. This includes custom UI components like a rich text editor with custom formatting buttons, or a complex emoji picker. ARIA should be removed or avoided when a native HTML element (e.g., `<button>`, `<input type="text">`, `<ul>`, `<li>`) can inherently provide the same semantic meaning and accessibility features without ARIA. Overusing ARIA on native elements can create redundancy or conflicts, degrading the user experience for assistive technology users.

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 Drive file browser's component API by requiring explicit error states, retry mechanisms, and user feedback props. The QA process must expand to include dedicated test cases for network failures, backend errors, permission issues, and optimistic UI rollbacks, often leveraging fault injection. For the release checklist, new items are added to verify error logging, monitoring alerts for error rates, and A/B testing of different error message presentations to ensure user comprehension and recovery paths.

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, programmatically discoverable feedback using ARIA attributes like `aria-invalid`, `aria-describedby`, and `aria-live` regions for error messages. It would detail clear, concise error messages that explain the problem and suggest a fix, linking them visually and programmatically to the relevant input. For recovery, candidates should discuss inline correction, 'save' button state changes (e.g., disabled until valid), and clear instructions for complex validation, ensuring screen reader users get the same guidance as sighted users. Focus on a holistic approach where errors are not just displayed but also announced and actionable.

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 accessibility concerns: subtle icons may lack sufficient contrast or alternative text, and gestures are inaccessible to users without fine motor control or using assistive technologies. They would propose a collaborative negotiation with design, advocating for WCAG compliance (e.g., AA or AAA for Google products). Solutions would include providing visible text labels or tooltips for icons, ensuring sufficient color contrast, and offering keyboard-navigable and mouse-clickable alternatives for all gesture-based interactions. The negotiation would emphasize user impact, legal compliance, and Google's brand reputation, presenting accessible design as an enhancement rather than a compromise.

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 focus on proper WAI-ARIA roles and properties, specifically `role="dialog"` (or `alertdialog`), `aria-modal="true"`, and `aria-labelledby` / `aria-describedby`. It's crucial to manage keyboard focus: trap focus within the modal, ensure the 'Escape' key closes it, and return focus to the triggering element upon closure. Semantic HTML for interactive elements (buttons for close, links for actions) should be used. Finally, ensure visual focus indicators are clear and that the modal is announced correctly by screen readers when opened and closed.

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 candidate would first define touch target size and its importance for accessibility, referencing WCAG 2.1 success criterion 2.5.5 (Target Size). They would then identify key interactive elements on a Google Search results page, such as search result links, pagination buttons, 'People also ask' toggles, and filter/tool buttons. For manual checks, they would describe using browser developer tools to inspect CSS dimensions and padding, and physically testing with a finger/stylus on various devices to assess usability. Automation would involve using Lighthouse audits, axe-core, or custom Puppeteer/Playwright scripts to check computed styles against minimum size requirements (e.g., 44x44 CSS pixels) for clickable elements.

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 will describe an inline editor that activates on user interaction (e.g., click, Enter key) and becomes a live ARIA-enabled editing region. It will detail how focus moves into the editor, how labels (aria-label, aria-labelledby) provide context, and how ARIA live regions (aria-live="assertive" or "polite") announce changes like 'editing mode activated' or 'changes saved'. Keyboard interactions should cover navigation (Tab, Shift+Tab), editing (standard text input), and actions (Enter to save, Escape to cancel), ensuring all controls are reachable and operable without a mouse.

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 (e.g., NVDA, JAWS, VoiceOver) and browser combinations, and pinpointing the exact interaction or feature that fails. Reproduction requires setting up the identified environment and attempting to complete a common task (e.g., typing, formatting, saving) while using the screen reader. The fix would likely involve inspecting the DOM for missing ARIA attributes (roles, states, properties), incorrect semantic HTML, or keyboard trap issues, then implementing the necessary code changes and thoroughly testing with multiple screen readers.

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 typically occurs for complex custom UI components like a custom autocomplete dropdown, a draggable pin, or a multi-level hierarchical location selector. ARIA attributes like `role`, `aria-labelledby`, `aria-describedby`, `aria-haspopup`, `aria-expanded`, `aria-controls`, and `aria-live` would be crucial here. Conversely, ARIA should be removed or avoided when a native HTML element (e.g., `<input type="text">`, `<button>`, `<select>`, `<option>`) already provides the correct semantic meaning and default accessibility features. Overusing ARIA on native elements can create redundancy, confusion, or even break existing accessibility features, adhering to the first rule of ARIA: "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA `role`, `state` or `property` to make it accessible, then do so."

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 YouTube watch page's component API by requiring semantic HTML, ARIA attributes for custom controls, and keyboard navigability. The QA process must integrate automated accessibility checks (e.g., Lighthouse, axe-core) and manual testing with screen readers, keyboard-only navigation, and zoom. The release checklist will then include mandatory accessibility audits, sign-offs from accessibility specialists, and verification of accessible documentation and user feedback channels.

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 candidate would emphasize immediate, clear, and context-sensitive feedback for errors and validation. This includes using ARIA live regions for dynamic updates, associating error messages directly with their input fields using `aria-describedby`, and providing specific, actionable recovery paths. For high-stakes panels, ensure error messages are not only accessible but also non-disruptive, allowing users to correct issues without losing their place or context within complex collaborative workflows. Prioritize progressive enhancement and user testing with assistive technologies.

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 (e.g., visual impairment, motor impairment, cognitive load). They would then propose a collaborative negotiation strategy with design, emphasizing user research and accessibility standards (WCAG). Key solutions would include offering robust alternatives like clear text labels, keyboard navigation, ARIA attributes, and configurable settings, while also exploring progressive enhancement to retain the desired aesthetic for users who can utilize it. The discussion should focus on finding a balance that meets both design goals and accessibility requirements, potentially through iterative prototyping and user testing with diverse groups.

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 ARIA roles and attributes, keyboard trap management, and focus management. Specifically, it should cover setting `role="dialog"` or `role="alertdialog"`, `aria-modal="true"`, and `aria-labelledby` / `aria-describedby`. Keyboard navigation must be trapped within the modal when open, returning focus to the trigger element upon close. Focus should be programmatically moved to the first interactive element or the modal itself upon opening.

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 like tabbing through all interactive elements (files, folders, buttons, menus) to ensure a logical order and visible focus indicator. It would also cover keyboard navigation within complex components (e.g., arrow keys in a file list, Esc to close modals). For automation, the candidate should mention using browser DevTools (e.g., Lighthouse accessibility audit, `tabindex` checks) and potentially writing end-to-end tests with frameworks like Playwright or Cypress to simulate keyboard interactions and assert focus changes, especially for critical workflows like file uploads or sharing.

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 close. It will detail the use of ARIA attributes like `role="dialog"`, `aria-labelledby`, and `aria-describedby` for proper labeling and announcements. Keyboard interactions will include `Tab` for navigation within the dialog, `Shift+Tab` for reverse navigation, `Escape` to close the dialog, and `Enter`/`Space` to activate buttons/links. Visual focus indicators and clear, concise button labels are also crucial.

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

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

Other roles at Google

Full Stack Engineer interviews at other companies