Role focus: Google Interaction Designer, UX Designer, Product Designer, Senior Interaction Designer, Staff Interaction Designer, UX Designer for Google Cloud, Search, Ads, YouTube, Workspace, Gemini, AI Foundations, XR, Payments, Kids & Families, L3–L6+ IC track
This guide follows the same role-specific interview-guide format as your demo: TL;DR, interview process, recruiter screen, portfolio review, design challenge, whiteboarding, app critique, behavioral, level expectations, prep plan, compensation, requirements, resources, and FAQs.
Google Interaction Designer interviews are not just portfolio walkthroughs. They test whether you can turn complex, ambiguous product problems into intuitive, accessible, scalable, user-centered experiences that work across Google’s ecosystem. Google’s own Interaction Designer job descriptions say the role is about transforming complex tasks into intuitive, easy-to-use experiences for billions of people, using user flows, wireframes, mockups, and prototypes while collaborating with UX, Engineering, and Product Management. (Google)
The best mental model is:
Google Interaction Designer = user-centered product thinker + systems-level UX designer + interaction craftsperson + cross-functional storyteller.
TL;DR
| Core Signal | What It Means | How It Shows Up | Why It Matters |
|---|---|---|---|
| Portfolio storytelling | You can explain the problem, your role, process, tradeoffs, decisions, and impact. | Portfolio review, onsite presentation, project deep dives. | Google requires a portfolio or work link in Interaction Designer applications, and candidate reports consistently describe portfolio review as central to the loop. (Google) |
| Interaction design craft | You can design flows, states, systems, prototypes, and polished experiences. | Whiteboard challenge, technical design round, app critique, craft questions. | Google job posts emphasize user flows, wireframes, UI mockups, prototypes, conceptual models, and user-centered design from concept to execution. (Google) |
| Product and systems thinking | You can connect design decisions to product goals, technical constraints, and ecosystem impact. | Product design challenge, critique, senior-level strategy questions. | Staff roles explicitly expect designers to translate ambiguous problems into roadmaps and partner with Product and Engineering leadership. (Google) |
| User advocacy and accessibility | You can design for diverse users, contexts, abilities, platforms, and constraints. | Portfolio follow-ups, accessibility critique, design challenge. | Google Design’s accessibility guidance emphasizes inclusive-by-default design, contrast, multiple visual cues, and robust access across environments. (Google Design) |
| Collaboration and influence | You can work with PMs, engineers, researchers, writers, and leadership without losing design quality. | Behavioral, stakeholder scenarios, portfolio Q&A, leadership rounds. | Google postings repeatedly emphasize collaboration with Researchers, PMs, Engineers, other designers, and cross-functional stakeholders. (Google) |
Note The core Google Interaction Designer interview pattern is user-centered clarity under ambiguity. A strong candidate does not just show beautiful screens. A strong candidate explains the user problem, constraints, alternatives, tradeoffs, research input, interaction model, accessibility decisions, cross-functional alignment, and why the final solution was better for users and the business.
Interview Process
Google does not publish one universal Interaction Designer loop for every team. The process can vary by level, product area, region, recruiter, and whether the role is for Cloud, Ads, YouTube, Workspace, Gemini, AI Foundations, Search, XR, Payments, or a design program. Public candidate reports and interview-prep sources commonly describe a process involving recruiter screen, portfolio review or technical design screen, design challenge or whiteboarding, onsite interviews, behavioral / Googleyness, and final team or hiring review. (Exponent)
| Stage | Likely Format | Main Signal | How to Prepare |
|---|---|---|---|
| Application / Portfolio Review | Resume + portfolio link screening | Design scope, craft, storytelling, relevance | Make 2–3 case studies easy to scan and explicit about your role, process, constraints, and impact. |
| Recruiter Screen | 30–45 minute call | Motivation, level, role fit, logistics | Prepare a concise narrative around product design, interaction craft, and why Google. |
| Design / Hiring Manager Screen | Portfolio overview or project deep dive with a designer or design lead | Design thinking, communication, role fit | Practice a 10-minute and 30-minute version of your strongest case study. |
| Portfolio Presentation | 45–60 minute presentation, often to multiple interviewers | Storytelling, ownership, impact, collaboration | Present one or two projects deeply, leaving time for Q&A. |
| Whiteboard / Design Challenge | Open-ended design prompt, live or take-home depending on process | Problem framing, ideation, interaction model, tradeoffs | Practice clarifying, sketching, prioritizing, and narrating decisions live. |
| App Critique / Product Critique | Critique an existing product experience | Taste, UX heuristics, product judgment, accessibility | Practice structured critiques of Google and non-Google products. |
| Technical Design / Craft Round | Design systems, prototypes, platform patterns, accessibility, AI design, implementation feasibility | Interaction craft and engineering collaboration | Prepare examples of constraints, states, flows, motion, responsive behavior, and handoff. |
| Behavioral / Googleyness | STAR stories and scenario questions | Collaboration, ambiguity, feedback, leadership | Prepare stories around conflict, influence, user advocacy, and iteration. |
| Hiring Committee / Team Match / Offer | Feedback review, level calibration, compensation | Hire/no-hire, level, team fit | Ensure every round creates evidence for the level you want. |
Exponent’s Google Interaction Designer guide describes screening calls, possible design challenges, an onsite with roughly 45-minute rounds, portfolio presentation, behavioral, technical design questions, and whiteboarding; Glassdoor candidate reports also mention portfolio review, whiteboarding, behavioral questions, and solving a design problem. Treat these as public candidate-report patterns, not guaranteed process details. (Exponent)
Note Ask your recruiter these questions:
Question Why It Matters Is there a take-home design challenge? It changes your prep timeline and presentation strategy. Is there a live whiteboard round? Live problem solving requires a different muscle than polished portfolio storytelling. Will there be an app critique? Critique requires structured product judgment, not only design craft. How long is the portfolio presentation? You need to know whether to prepare 20, 30, or 45 minutes of content. Who will attend the portfolio review? PMs, engineers, researchers, and designers evaluate different signals. What level am I being considered for? Senior and Staff design answers require more strategy and influence. Is this role product-specific or team-matched later? Domain context changes your examples and questions. Is AI-assisted prototyping expected or allowed? Some current Google design postings mention AI-assisted design tools and “vibe coding” prototypes. (Google)
Recruiter Screen
The recruiter screen is usually conversational, but it sets the frame for your loop. The recruiter is trying to understand whether you are a strong interaction designer, whether your portfolio maps to the role, whether your level is plausible, and whether you can explain your work clearly.
What the Recruiter Is Calibrating
| Category | What They Want to Hear |
|---|---|
| Role fit | You understand Interaction Design at Google as product UX, not just UI styling. |
| Portfolio strength | You have case studies showing process, craft, user insight, collaboration, and shipped impact. |
| Domain relevance | Your experience maps to the team: consumer, enterprise, AI, ads, cloud, video, kids, XR, or platform. |
| Craft and systems depth | You can discuss interaction models, states, flows, accessibility, design systems, and prototyping. |
| Collaboration | You have worked with PMs, engineers, researchers, writers, data, legal, or leadership. |
| Level fit | Your ownership scope matches the target level: feature, product area, roadmap, system, or cross-team strategy. |
Google’s UX Designer and Interaction Designer postings repeatedly require a portfolio link and experience in product or UX design, and they emphasize collaboration with UX, Engineering, and Product Management throughout the design process. (Google)
Recruiter Screen Question Map
| Motivation | Experience | Logistics |
|---|---|---|
| Why Google? | Walk me through your strongest design project. | What locations work for you? |
| Why Interaction Design? | What product surfaces have you designed for? | What is your timeline? |
| Why this product area? | How do you approach ambiguous design problems? | Do you need sponsorship? |
| What kind of team do you want? | Have you worked with PM, Engineering, Research, UX Writing? | Do you have competing offers? |
| What makes your portfolio strong? | Have you shipped work at scale? | What are your compensation expectations? |
Weak vs Strong Positioning
| Weak Positioning | Strong Positioning |
|---|---|
| “I’m a UX designer who makes clean interfaces in Figma.” | “I design end-to-end product flows from problem framing through prototype, research, launch, and iteration, with particular strength in complex enterprise workflows.” |
| “I redesigned a dashboard.” | “I redesigned the onboarding and monitoring flow for a developer dashboard, reduced setup errors by 28%, and aligned PM, Engineering, and Support around a new information architecture.” |
| “I care about users.” | “I used research and support-ticket analysis to identify where expert users and first-time users had conflicting needs, then designed progressive disclosure so both groups could succeed.” |
| “I worked with engineers.” | “I partnered with engineering to reduce implementation risk by defining interaction states, empty/error/loading behavior, accessibility requirements, and reusable components before build.” |
Note The biggest recruiter-screen mistake is describing yourself as a “visual designer with UX experience” when the role is looking for a product interaction designer. Lead with problem solving, systems thinking, user advocacy, shipped outcomes, and cross-functional impact.
Portfolio Review / Portfolio Presentation
The portfolio review is often the most important round. Exponent says the general prompt is usually a deep dive into a portfolio project, and candidate reports suggest Google often gives the candidate ownership of the presentation while reserving time for Q&A. (Exponent)
What Your Portfolio Needs to Prove
| Signal | What Strong Looks Like |
|---|---|
| Problem framing | You define the user, context, business goal, constraints, and why the problem mattered. |
| Your role | You separate what you personally did from what the team did. |
| User-centered process | You show research, data, feedback, usability testing, or credible proxies. |
| Interaction craft | You show flows, edge cases, states, prototypes, hierarchy, accessibility, and tradeoffs. |
| Cross-functional collaboration | You explain how PM, Eng, Research, UX Writing, Legal, Data, or leadership shaped the work. |
| Decision quality | You compare alternatives and explain why the final direction won. |
| Impact | You show user outcomes, product metrics, launch results, adoption, qualitative evidence, or learning. |
| Reflection | You explain what you would improve now. |
Recommended Portfolio Case Study Structure
| Section | What to Include | Interviewer Signal |
|---|---|---|
| 1. Context | Product, users, team, timeline, platform, business goal. | Can you set up the problem clearly? |
| 2. Problem | User pain, product gap, evidence, constraints. | Are you solving a real problem? |
| 3. Your role | Responsibilities, decisions, collaborators. | What should Google credit you for? |
| 4. Discovery | Research, data, audits, stakeholder input. | Did insight shape the design? |
| 5. Design exploration | Sketches, flows, concepts, rejected paths. | Can you explore, not just polish? |
| 6. Interaction model | IA, flow, states, transitions, controls, error handling. | Do you understand UX mechanics? |
| 7. Prototype and validation | Usability test, dogfood, stakeholder review, experiment. | Did you learn before launch? |
| 8. Final design | Key screens, design system usage, accessibility decisions. | Is the craft high enough? |
| 9. Impact | Metrics, launch result, adoption, qualitative improvement. | Did the work matter? |
| 10. Reflection | Tradeoffs, what changed, what you learned. | Are you self-aware and growth-oriented? |
Strong Portfolio Story Example
“This project started as a request to add more controls to an enterprise dashboard, but research showed that users were not asking for more controls—they were trying to recover from failed jobs faster. I reframed the problem from ‘add filters’ to ‘reduce time to diagnosis.’
I mapped the current troubleshooting journey, found three decision points where users lost context, and designed a new incident detail flow with progressive disclosure: summary first, then logs, dependencies, and recommended actions. I partnered with Engineering to define loading, empty, permission-denied, and partial-data states, and worked with UX Writing to make recovery actions understandable.
After launch, support escalations for this workflow dropped, and the design pattern was reused by two adjacent teams.”
Common Portfolio Mistakes
| Mistake | Why It Fails | Better Move |
|---|---|---|
| Showing only final screens | Interviewers cannot evaluate your thinking. | Show decision points, constraints, and alternatives. |
| Saying “we” for everything | Your ownership becomes unclear. | Explicitly state your role and decisions. |
| Overloading the deck | You lose the narrative. | Choose one or two deep case studies, not five shallow ones. |
| Hiding tradeoffs | Real design always involves constraints. | Explain what you gave up and why. |
| No measurable outcome | Hard to assess impact. | Use metrics, qualitative evidence, adoption, or learning. |
| No accessibility or edge cases | Google expects inclusive, robust design. | Show states, platforms, input methods, contrast, text, and assistive considerations. |
Note A Google portfolio review is not a gallery review. It is a design decision review. Every slide should help answer: What problem did you solve, why did you solve it that way, how did you know it worked, and what did you personally contribute?
Whiteboard / Product Design Challenge
The whiteboard or design challenge tests live thinking. Public sources describe Google Interaction Designer loops as often including a whiteboarding challenge or design challenge, sometimes with candidates choosing from several prompts; exact format varies by team and process. (Exponent)
Common Design Challenge Prompts
| Prompt Category | Example Prompt |
|---|---|
| Everyday product redesign | Redesign the checkout flow for a grocery app. |
| Google-scale consumer UX | Design a better onboarding flow for a maps or video product. |
| Enterprise workflow | Design a dashboard for cloud admins monitoring incidents. |
| AI interaction | Design how a user reviews and edits AI-generated recommendations. |
| Multi-device UX | Design a handoff experience between phone, TV, and laptop. |
| Accessibility-first design | Design a navigation experience usable in bright sunlight and with limited dexterity. |
| Creator tools | Design a lightweight video creation workflow for non-experts. |
| Trust and safety | Design a parental-control or consent flow for a family product. |
| Developer tools | Design a setup flow for a complex API or infrastructure feature. |
Strong Whiteboard Framework
| Step | What to Do | Why It Matters |
|---|---|---|
| 1. Clarify the prompt | Ask user, goal, platform, constraints, timeline, success metric. | Prevents solving the wrong problem. |
| 2. Define users and context | Primary user, secondary user, environment, expertise level. | Google products serve diverse users. |
| 3. Identify user needs | Jobs-to-be-done, pain points, motivations, risks. | Keeps solution user-centered. |
| 4. Define success and guardrails | User success, business success, accessibility, trust, privacy. | Shows product maturity. |
| 5. Map the current journey | Entry point, actions, decisions, failure points. | Makes the problem concrete. |
| 6. Generate options | Explore 2–3 possible directions quickly. | Shows divergent thinking. |
| 7. Choose and justify | Pick based on user value, feasibility, and risk. | Shows decision quality. |
| 8. Sketch core flow | Key screens, states, hierarchy, interactions. | Shows interaction craft. |
| 9. Handle edge cases | Empty, error, loading, permission, offline, AI uncertainty. | Shows production readiness. |
| 10. Validate and iterate | Research plan, usability test, metrics, rollout. | Shows how you learn. |
Strong Whiteboard Answer Example
“Before sketching, I want to clarify the user and success metric. If we’re designing an AI-assisted video creation flow, is the target user a novice who wants a quick work update, or a power user who wants precise editing control?
I’ll focus on the novice user first. Their core need is not ‘more editing tools’; it is getting from idea to usable draft with confidence. I’d structure the flow around prompt → outline → generated draft → editable scenes → export/share. The key design challenge is trust: users need to understand what the AI created, what they can change, and when the output is good enough.
I’d add progressive controls: simple edit chips for beginners, deeper timeline controls for advanced users, and clear states for generation in progress, failed generation, and low-confidence output. I’d validate with a task-based usability test: can users create a shareable video in under ten minutes, and do they understand how to edit or reject AI output?”
What They Are Really Testing
| Hidden Signal | What Interviewers Look For |
|---|---|
| Problem navigation | Can you reduce ambiguity without freezing? |
| User-centered thinking | Do you start with users instead of screens? |
| Interaction model | Can you turn vague needs into flows, states, and controls? |
| Product judgment | Can you make tradeoffs instead of adding every feature? |
| Craft under time pressure | Can you sketch enough detail to make the idea understandable? |
| Validation mindset | Do you know how you would test the solution? |
Note In whiteboarding, the goal is not the prettiest sketch. The goal is to make your thinking visible: assumptions, user needs, alternatives, tradeoffs, core flow, edge cases, and validation.
App Critique / Product Critique
Some Google design loops include app critique or product critique, especially for UX and interaction design roles. Prepfully describes app critique as a possible onsite component, and public candidate reports often discuss product critique or whiteboard-style critique in design loops.
Product Critique Framework
| Lens | Questions to Ask |
|---|---|
| User and context | Who is this for? What are they trying to accomplish? |
| Entry point | How does the user arrive here? What do they expect? |
| Information architecture | Is the hierarchy clear? Are labels meaningful? |
| Interaction model | Are controls predictable? Are states visible? |
| Accessibility | Is it usable with contrast needs, screen readers, keyboard, touch constraints, and varied environments? |
| Trust and privacy | Does the product explain permissions, data use, AI uncertainty, or sensitive actions? |
| System consistency | Does it align with platform patterns and design system conventions? |
| Business goal | What product outcome does this design support? |
| Improvement | What would you change, and how would you validate it? |
Strong Critique Example
“I’ll critique this onboarding flow from the perspective of a first-time user trying to set up a family account. The flow is visually clear, but it asks for consent before explaining value, which may create distrust. I would move the benefit explanation earlier, use plain language for permissions, and separate required from optional steps.
Accessibility-wise, I would check text size, contrast, touch target size, and whether the same information is conveyed beyond color. For validation, I’d compare completion rate, drop-off at permission steps, comprehension of parental controls, and support contacts after setup.”
Common Critique Mistakes
| Mistake | Better Move |
|---|---|
| Only commenting on visual taste | Discuss user goal, hierarchy, interaction, states, accessibility, and product tradeoffs. |
| Redesigning everything | Prioritize the highest-impact issue. |
| Ignoring platform context | Mention Android, web, TV, enterprise, or ecosystem conventions when relevant. |
| Being overly negative | Critique respectfully: what works, what fails, why, and how to validate improvement. |
| No success metric | Define how you would know the redesign worked. |
Note A strong critique sounds like a designer who could join the product team tomorrow: respectful, structured, user-centered, and specific enough to guide action.
Technical Design / Interaction Craft Round
For Interaction Designer roles, “technical” rarely means coding algorithms. It usually means whether you understand how design becomes product: states, components, patterns, accessibility, platform constraints, data, AI behavior, implementation feasibility, and collaboration with engineering.
Google job descriptions explicitly mention storyboards, wireframes, high-fidelity mockups, interactive prototypes, conceptual models, cross-platform design, design systems, and collaborating with PMs and engineers. Current posts also mention AI-assisted design tools, technical prototyping, scripting, and “vibe coding” functional prototypes for some senior/staff AI-facing design roles. (Google)
Interaction Craft Topic Map
| Core UX Craft | Design Systems / Platform | AI and Advanced Interaction |
|---|---|---|
| User flows | Component variants | AI uncertainty states |
| Information architecture | Tokens and patterns | Prompt-to-output workflows |
| Wireframes | Responsive layouts | Human-in-the-loop review |
| Prototypes | Android / web / TV conventions | Model confidence and correction |
| Empty / error / loading states | Accessibility standards | Generated content editing |
| Progressive disclosure | Handoff specs | Non-deterministic behavior |
| Navigation models | Design system extension | AI safety and trust cues |
| Microcopy collaboration | Motion and transition intent | Rapid functional prototypes |
Material Design 3 is Google’s open-source design system for creating user-friendly interfaces, and its accessibility guidance says accessible design enables users with diverse abilities to navigate, understand, and enjoy a UI. ([Material Design][6]) Google’s People + AI Guidebook provides UX and ML guidance, principles, patterns, and workshops for creating helpful AI-enabled products. ([Pair][7])
[6]: https://m3.material.io/foundations/overview/principles " [7]: https://pair.withgoogle.com/guidebook/?utm_source=chatgpt.com "People + AI Guidebook - Home"