Google Frontend Development Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Google hiring for Frontend Development roles
Google, part of Alphabet, builds products such as Search, YouTube, Android, Google Cloud, Maps and Pay. Its Indian offices contribute to engineering, cloud, payments and research work for local and global products. It hires in India for software engineers, test and reliability engineers, data scientists and analysts who work on large-scale data and experimentation.
For Frontend Development roles, this Google practice set focuses most on Frontend Testing (7), Build Tools and Tooling (7), Web Performance (5), CSS Architecture and Accessibility (4). It has 4 easy, 18 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Mountain View, California, USA
Main India offices
Bengaluru, Hyderabad, Gurugram, Mumbai, Pune
Google Frontend Development interview process
Recruiter screening
Online coding assessment or phone screen
Technical interviews (coding, 3-4 rounds)
Googleyness and leadership round
Hiring committee review
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for GoogleStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What is the testing pyramid, and how does the testing trophy differ?
The testing pyramid suggests many fast unit tests, fewer integration tests and very few slow end-to-end tests. The testing trophy, popular for frontend work, puts most effort into integration tests that render components with real behaviour, supported by static analysis like TypeScript and ESLint at the base. Both aim for confidence at reasonable cost; the trophy reflects that UI bugs often appear where units connect.
02
Write a GitHub Actions workflow that lints, tests and builds a frontend app.
A typical CI pipeline:
name: CI
on: [pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint
- run: npm test -- --run
- run: npm run build
npm ci installs exactly from the lockfile, and caching speeds up repeat runs. Branch protection can require this check before merging.
03
Write a card that changes layout based on its container width.
Use a container query so the card adapts wherever it is placed:
.card-wrapper {
container-type: inline-size;
}
.card {
display: grid;
gap: 1rem;
}
@container (min-width: 420px) {
.card {
grid-template-columns: 160px 1fr;
align-items: center;
}
}
In a narrow sidebar the image stacks above text; in a wide main column it sits beside the text, with no viewport media queries.
04
Break a long-running loop into smaller tasks to keep the page responsive.
Yield to the main thread between chunks:
function yieldToMain() {
if (globalThis.scheduler?.yield) return scheduler.yield();
return new Promise(resolve => setTimeout(resolve, 0));
}
async function processRows(rows) {
let last = performance.now();
for (const row of rows) {
processRow(row);
if (performance.now() - last > 40) {
await yieldToMain();
last = performance.now();
}
}
}
The browser can handle clicks between chunks, which improves INP. scheduler.yield keeps the task's priority after resuming.
I would first try a modular monorepo with clear package boundaries, code owners, affected-only CI with Nx or Turborepo, and trunk-based development with feature flags, which removes most blocking at low cost. If teams truly need independent deployments, I would introduce micro-frontends along business domains, such as search, product and checkout, with a shared design system and strict performance budgets to control duplication.
07
Write a Playwright end-to-end test for a login flow.
Use role-based locators and web-first assertions:
import { test, expect } from '@playwright/test';
test('user can log in and see dashboard', async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill('student@example.com');
await page.getByLabel('Password').fill('Secret@123');
await page.getByRole('button', { name: 'Log in' }).click();
await expect(page).toHaveURL(/dashboard/);
await expect(page.getByRole('heading', { name: 'My courses' })).toBeVisible();
});
Assertions auto-wait, so no manual sleeps are needed. Save login state with storageState to reuse in other tests.
08
Errors from failed promises are silently disappearing in production. How do you catch them?
Promises without a catch produce unhandled rejections that do not stop the app but hide failures. I would add a global window.addEventListener('unhandledrejection') handler and window.onerror that report errors to a monitoring tool like Sentry with source maps. In code, every async call should have try and catch or a .catch, and ESLint rules such as no-floating-promises in TypeScript projects catch missing handlers.
09
What is the guiding principle of Testing Library and why query by role?
Testing Library encourages testing the way users interact: find elements by what they see and hear, not by implementation details like class names or component internals. getByRole('button', { name: 'Submit' }) is preferred because it also verifies the element is accessible. Tests written this way survive refactors and catch real accessibility problems. Test ids are a last resort when no accessible query works.
10
How can web fonts slow a page down and how do you optimise them?
Fonts are often discovered late, after CSS is parsed, and text may stay invisible until they load. To optimise, self-host fonts in WOFF2 format, subset them to the characters you need, preload the main weight, and use font-display: swap so fallback text appears immediately. Limiting the number of weights and using variable fonts reduces downloads. Matching fallback metrics with size-adjust prevents layout shift.
11
Write a type-safe getProperty function using generics and keyof.
Constrain the key to the object's own keys:
function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
return obj[key];
}
const course = { title: 'Frontend', weeks: 14 };
const weeks = getProperty(course, 'weeks'); // number
// getProperty(course, 'price'); // compile error
T[K] is an indexed access type, so the return type matches the chosen property. Typos in key names are caught at compile time.
12
The main JavaScript bundle is 2 MB. How do you reduce it?
I would run a bundle analyser to see what is inside. Usual wins are route-based code splitting, lazy loading heavy widgets, replacing large libraries such as full date or utility packages with smaller alternatives or native APIs, and importing only needed functions so tree shaking works. I would also remove polyfills for browsers we no longer support, and make sure production mode and minification are enabled.
13
How do you balance technical debt against delivering new features?
Situation: our team constantly added features while an outdated build setup slowed everyone. Task: I needed time for cleanup without stalling the roadmap. Action: I quantified the cost, about 30 minutes lost per developer daily, and proposed reserving roughly 15 percent of each sprint for debt, starting with the biggest pain points. Result: the product manager agreed, build times halved, and feature delivery actually sped up.
14
Most of your users are on low-end Android phones with slow networks. How does that change your approach?
I would test with real budget devices and network throttling rather than a fast laptop. The priorities become sending less JavaScript, rendering important content on the server, compressing images aggressively, and keeping the initial page under a strict size budget. Caching with a service worker helps repeat visits. Features like large animations and heavy carousels should be reduced or loaded only when the device can handle them.
15
Lighthouse shows a score of 95, but Search Console reports failing Core Web Vitals. Why?
Lighthouse is a single lab run on a simulated device, while Search Console uses field data from real Chrome users at the 75th percentile over 28 days. Real users may have slower phones, interact with the page, which affects INP and CLS later in the session, or see different content like ads and personalised blocks. I would add real user monitoring with attribution to find which pages and elements fail.
16
Write a visually-hidden utility class for screen-reader-only text.
This hides content visually but keeps it readable by assistive technology:
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
Use it for labels on icon-only buttons, such as <button><svg aria-hidden='true'></svg><span class='sr-only'>Close</span></button>. display: none would hide the text from screen readers too.
Component-driven development builds UIs from the bottom up as small, reusable, isolated components, such as buttons and inputs, composed into larger patterns like forms and pages. Each component has a clear API through props or attributes and is developed and documented in isolation, often in Storybook. Composition over configuration keeps components flexible. This approach enables design systems, parallel work and easier testing.
18
Editing one item in a copied list also changes the original list. Why?
Copying an array with spread or slice creates a new array, but the objects inside are still the same references. Changing copy[0].qty changes the original object too. The fix is to create new objects for changed items, for example list.map(item => item.id === id ? { ...item, qty: item.qty + 1 } : item), or use structuredClone when a full deep copy is genuinely needed.
19
Management requires 100 percent code coverage, but bugs still appear. How do you respond?
Coverage shows which lines ran, not whether the behaviour was verified, so tests can execute code without meaningful assertions. I would explain this with an example and propose a balanced target, perhaps 80 percent on business logic, combined with quality measures like mutation testing, critical user flows covered by end-to-end tests and tracking escaped defects. Effort is better spent on risky areas than on trivial getters.
20
Your app must now support an Arabic right-to-left version. What changes are needed in CSS?
I would set dir='rtl' on the html element for that locale and replace physical properties like margin-left, padding-right and left with logical ones such as margin-inline-start and inset-inline-start. Flexbox and Grid follow direction automatically. Directional icons like arrows need flipping with a transform in RTL, while logos and media do not. I would test layouts with real Arabic text, which has different line heights.
21
Your page embeds a payment iframe from another domain and needs its result. How do you do it safely?
The iframe should send the result with parent.postMessage(data, 'https://yourshop.com'), and the page listens for message events, checking event.origin against the exact payment domain and validating the data shape before acting. The frontend message should only update UI; the final payment status must be confirmed from your server through the gateway's webhook or verification API, since messages can be spoofed.
22
npm audit reports a critical vulnerability in a dependency. What do you do?
I would check whether the vulnerable package is actually used in the production bundle or only in build tooling, and whether the vulnerable code path is reachable. Then I would update to a patched version, using npm update or overrides for transitive dependencies. If no fix exists, I would look for an alternative package or mitigate. Automated tools like Dependabot or Renovate keep dependencies current.
Tree shaking removes exports that are never imported from the final bundle. It relies on static ES module imports and exports. It fails with CommonJS modules, dynamic property access on imported objects, and code with side effects that the bundler must keep. Libraries mark themselves safe with sideEffects: false in package.json. Importing { debounce } from a modular package instead of the whole library lets tree shaking work.
24
How do you test code that depends on the current date or timers?
Real time makes tests slow and nondeterministic. I would use fake timers, such as vi.useFakeTimers() and vi.setSystemTime(new Date('2026-11-12T10:00:00+05:30')), then advance time with vi.advanceTimersByTime to test debounce, countdowns or expiry logic instantly. Restoring real timers after each test avoids leaking state. Designing functions to accept a clock or date parameter makes them even easier to test.
25
After a release, the app shows a blank page in some older browsers. What could be wrong?
The build probably targets newer syntax or uses an API that older browsers lack, causing a parse error that stops the whole bundle. I would check the console in that browser, compare the build target and browserslist with our support policy, and add missing polyfills for used APIs. Error monitoring with browser breakdowns catches this quickly, and testing on the oldest supported browser should be part of release checks.
26
The frontend test suite takes 20 minutes in CI. How do you make it faster?
I would measure which tests are slowest. Options include running tests in parallel and sharding across CI machines, moving logic checks from end-to-end tests into faster integration tests, reusing logged-in state instead of logging in every time, and running only tests affected by changed files on pull requests with the full suite nightly. Replacing real network calls with MSW and caching dependencies also helps.
27
Production builds take eight minutes on an old webpack setup. How would you speed them up?
I would profile the build to find slow loaders and plugins. Quick wins include replacing Babel and Terser with SWC or esbuild, enabling persistent filesystem caching, and removing unused plugins. For a bigger gain, I would evaluate migrating to Vite or Rspack, which keeps webpack-compatible config. In CI, caching dependencies and build outputs and running only affected packages in a monorepo cut time further.
28
End-to-end tests fail randomly in CI about one run in five. How do you stabilise them?
I would collect traces, videos and screenshots of failures to see what actually happened. Usual fixes are replacing fixed waits with auto-waiting assertions, waiting for specific network responses, seeding isolated test data per test, mocking unstable third-party services, and disabling animations. I would quarantine persistently flaky tests with a tracking ticket rather than letting the team ignore red builds, and retry only as a temporary measure.
29
Describe a disagreement with your team about choosing a tool or framework.
Situation: half the team wanted a heavy state management library for a new app, while I felt it was unnecessary. Task: we needed a decision quickly. Action: I suggested building the same feature both ways in a time-boxed spike and compared code size, learning curve and bundle impact. Result: the data favoured the simpler approach, the team agreed, and we documented criteria for when to add the library later.
30
Tailwind classes built dynamically like 'bg-' + colour work locally but are missing in production. Why?
Tailwind finds classes by scanning source files for complete strings, so a class assembled at runtime never appears in the code and its CSS is not generated. The fix is to map values to full class names, such as const colours = { success: 'bg-green-600', error: 'bg-red-600' }. If truly dynamic values are needed, use inline styles with CSS variables or explicitly safelist those classes.
Tips to crack the Google Frontend Development interview
Practise solving DSA problems in a plain document without autocomplete, since Google interviews often use a shared editor without running code.
For data science roles, revise statistics, A/B testing and product metrics for products like YouTube, Search or Google Pay.
Prepare examples showing collaboration, handling ambiguity and doing the right thing, which the Googleyness round tends to explore.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; Google interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Google Frontend Development interview?
Candidates usually go through 5 stages: Recruiter screening; Online coding assessment or phone screen; Technical interviews (coding, 3-4 rounds); Googleyness and leadership round; Hiring committee review. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the Google Frontend Development interview?
This practice set leans on Frontend Testing (7), Build Tools and Tooling (7), Web Performance (5), CSS Architecture and Accessibility (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Google interviewers ask you to walk through real work.
Are these the exact questions asked at Google?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Google's. They are not a leaked or verified list of past questions.
Where does Google hire Frontend Development professionals in India?
Google has large teams in Bengaluru, Hyderabad, Gurugram, Mumbai, Pune. Openings and locations change often, so check the Google careers page and filter by city and experience.
Frontend Development questions for similar companies