Adobe Frontend Development Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Adobe hiring for Frontend Development roles
Adobe makes creative, document and marketing software including Photoshop, Acrobat, Premiere Pro, Adobe Express and Adobe Experience Cloud. Its Noida and Bengaluru centres are among its largest engineering sites globally. It hires in India for software engineers, quality engineers, data scientists and analysts working on product analytics, marketing data and AI features such as Firefly.
For Frontend Development roles, this Adobe practice set focuses most on Frontend Architecture (7), Modern JavaScript (6), Build Tools and Tooling (4), CSS Architecture and Accessibility (3). It has 2 easy, 21 medium, 7 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
San Jose, California, USA
Main India offices
Noida, Bengaluru, Gurugram
Adobe Frontend Development interview process
Online assessment (aptitude + coding)
Technical round 1 (DSA)
Technical round 2 (DSA + CS fundamentals)
Hiring manager round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for AdobeStart 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
Compare CSS Modules, CSS-in-JS and utility-first CSS.
CSS Modules scope class names per file at build time, giving plain CSS with no runtime cost. CSS-in-JS libraries write styles in JavaScript with dynamic props, but runtime versions add bundle size and slow server rendering, so zero-runtime options are now preferred. Utility-first frameworks like Tailwind compose small classes in markup, producing small CSS and consistent spacing. The choice depends on team preference and rendering strategy.
02
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.
03
Configure cache headers for hashed assets and HTML in Nginx.
Long cache for fingerprinted files, revalidation for HTML:
location ~* \.(js|css|woff2|avif|webp|svg)$ {
add_header Cache-Control 'public, max-age=31536000, immutable';
}
location / {
try_files $uri /index.html;
add_header Cache-Control 'no-cache';
}
This works only when build tools add content hashes to filenames. Returning users then load assets from cache instantly, while every deploy still reaches them through fresh HTML.
04
Which rendering strategy would you choose for a large e-commerce site?
I would mix strategies by page type. Category and product pages need SEO and fast LCP, so I would use static generation with incremental revalidation or server rendering with CDN caching. Cart, checkout and account pages are personalised, so server rendering without shared caching or client rendering works. Prices and stock can be fetched fresh on the client. Frameworks like Next.js, Nuxt and Astro support this per-route choice.
05
Cancel an older search request when the user types again using AbortController.
Keep a controller per request and abort the previous one:
let controller;
async function search(term) {
controller?.abort();
controller = new AbortController();
try {
const res = await fetch('/api/search?q=' + encodeURIComponent(term), {
signal: controller.signal
});
renderResults(await res.json());
} catch (err) {
if (err.name !== 'AbortError') showError(err);
}
}
This prevents slow old responses from overwriting newer results.
Let callers specify the expected response type:
async function getJson<T>(url: string): Promise<T> {
const res = await fetch(url);
if (!res.ok) throw new Error(`Request failed: ${res.status}`);
return res.json() as Promise<T>;
}
interface Course { id: number; title: string; }
const courses = await getJson<Course[]>('/api/courses');
courses[0].title.toUpperCase();
The cast trusts the server, so for untrusted data validate with a schema library like Zod before returning.
07
Search results sometimes show data for an older query. What is happening?
This is a race condition: requests for 'ja' and 'java' are in flight together, and if the older one responds last, it overwrites the newer results. I would cancel the previous request with AbortController, or tag each request with an id and ignore responses that are not the latest. Debouncing the input reduces the number of requests, and caching repeated queries makes responses faster and more consistent.
08
Detect offline status and retry queued requests when the connection returns.
Listen for online and offline events and keep a small queue:
const queue = [];
async function send(req) {
if (!navigator.onLine) { queue.push(req); showBanner('You are offline'); return; }
await fetch(req.url, req.options);
}
window.addEventListener('online', async () => {
hideBanner();
while (queue.length) await send(queue.shift());
});
window.addEventListener('offline', () => showBanner('You are offline'));
navigator.onLine can report true on captive networks, so treat failed fetches as offline too. Persist the queue in IndexedDB for reliability.
09
Create a new Vite project with TypeScript and run it.
Use the official scaffolding tool:
npm create vite@latest my-app -- --template vanilla-ts
cd my-app
npm install
npm run dev # starts the dev server with HMR
npm run build # type-checks and builds to dist/
npm run preview # serves the production build locally
Templates also exist for react-ts, vue-ts and svelte-ts. The dist folder contains static files ready for any web server or CDN.
10
State is passed through many component layers and global state has become chaotic. How do you restructure it?
I would first classify state: server data moves to a data-fetching cache like TanStack Query, URL-worthy state such as filters moves to query parameters, and truly local state moves back into components. What remains global, like user session and theme, goes into a small, well-defined store or context split by concern. Composition patterns, passing components as children, also remove much prop drilling.
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.
12
Run linting and formatting automatically before each commit.
Use Husky with lint-staged:
npm i -D husky lint-staged
npx husky init
echo 'npx lint-staged' > .husky/pre-commit
// package.json
"lint-staged": {
"*.{ts,tsx,js}": ["eslint --fix", "prettier --write"],
"*.{css,md,json}": "prettier --write"
}
Only staged files are checked, so commits stay fast. CI should still run the full lint because hooks can be skipped locally.
13
Write a fetch wrapper that retries with exponential backoff.
Situation: my team had almost no automated tests and frequent regressions. Task: as tech lead, I wanted testing to become a habit, not a mandate. Action: I set up Vitest and Playwright with examples, ran two short workshops, required tests only for bug fixes at first, and celebrated bugs caught in CI. Result: within six months, most pull requests included tests and production regressions dropped significantly.
15
When should you mock in frontend tests, and what is Mock Service Worker?
Mock things that are slow, nondeterministic or outside your control, such as network calls, timers and browser APIs, but avoid mocking your own modules heavily, which makes tests pass while the real integration breaks. Mock Service Worker intercepts requests at the network level in both browser and Node, so your real fetch code runs against defined handlers. The same handlers can power tests, Storybook and local development.
16
Model API request state with a discriminated union.
A shared status field lets TypeScript narrow each case:
type ApiState<T> =
| { status: 'idle' }
| { status: 'loading' }
| { status: 'success'; data: T }
| { status: 'error'; message: string };
function render(state: ApiState<string[]>) {
switch (state.status) {
case 'success': return state.data.join(', ');
case 'error': return 'Error: ' + state.message;
default: return 'Loading...';
}
}
Impossible states, like having both data and an error, cannot be represented.
17
Split vendor libraries into separate chunks and visualise the bundle.
Use manualChunks and a visualiser plugin:
import { defineConfig } from 'vite';
import { visualizer } from 'rollup-plugin-visualizer';
export default defineConfig({
plugins: [visualizer({ filename: 'stats.html', gzipSize: true })],
build: {
rollupOptions: {
output: {
manualChunks: { charts: ['chart.js'], editor: ['@tiptap/core'] }
}
}
}
});
After building, open stats.html to see which modules take the most space and decide what to lazy load or replace.
18
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.
19
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.
20
How do you handle unclear requirements from a product manager?
Situation: a product manager asked for 'offline support' in our web app without details. Task: I needed clarity before estimating. Action: I listed specific questions, which screens, read-only or editing, how long offline, and shared a quick prototype showing two options with effort estimates. Result: we agreed on read-only offline access for the order history, which shipped in one sprint instead of an open-ended project.
21
Ten teams work on one large frontend and releases keep blocking each other. What would you propose?
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.
22
Build an API client that refreshes an expired access token once and retries.
Optional chaining ?. stops evaluation and returns undefined if the value before it is null or undefined, so user?.address?.pincode never throws. Nullish coalescing ?? returns the right side only when the left is null or undefined, unlike || which also replaces 0, false and empty strings. For example, const qty = input ?? 1 keeps a valid 0, while input || 1 would wrongly change 0 into 1.
A Proxy wraps an object and intercepts operations like get, set, has and deleteProperty through handler traps. Reflect provides matching methods that perform the default behaviour, so traps can add logic and then call Reflect.set. Reactive frameworks such as Vue 3 use Proxies to track which properties a component reads and re-render when they change. Proxies add overhead, so they suit framework internals more than hot loops.
Tokens go in CSS with the @theme directive:
@import 'tailwindcss';
@theme {
--color-brand-500: #2563eb;
--color-brand-700: #1d4ed8;
--font-display: 'Poppins', sans-serif;
--radius-card: 12px;
}
/* usage in markup */
/* <button class='bg-brand-500 hover:bg-brand-700 rounded-card font-display'> */
Tailwind generates utilities like bg-brand-500 from these variables and also exposes them as CSS custom properties for use in plain CSS.
26
An accordion animation stutters on low-end Android phones. What is wrong?
Most likely it animates height, max-height or margin, which forces layout recalculation every frame. I would check the Performance panel for long layout events. Fixes include animating transform and opacity, using the newer interpolate-size or calc-size features for height where supported, or animating grid-template-rows from 0fr to 1fr, which is cheaper. Testing with CPU throttling in DevTools reveals these issues before users do.
27
Create a type where all fields are optional except id.
Frameworks escape output by default, but risks remain: dangerouslySetInnerHTML or v-html with unsanitised data, javascript: URLs in links, and vulnerable npm packages. I would sanitise any HTML with DOMPurify, enforce a strict Content Security Policy with nonces, use Subresource Integrity for CDN scripts, keep tokens in HttpOnly cookies, run dependency audits in CI and never place secrets in frontend environment variables.
29
How do you estimate the time needed for a frontend feature?
I break the feature into small parts: components, states such as loading, empty and error, API integration, responsive behaviour, accessibility and tests. I estimate each part, add time for reviews and unknowns, and flag dependencies like pending designs or APIs. For example, a filter panel I estimated at five days was delivered in five because I had listed edge cases upfront instead of discovering them late.
30
How would you explain a difficult JavaScript concept to a junior teammate?
Situation: a junior developer kept writing bugs with async code. Task: I wanted them to understand promises rather than copy fixes. Action: I drew the event loop on a whiteboard, wrote three small console examples for them to predict, and then reviewed one of their real pull requests together. Result: within two weeks, their async bugs stopped and they started explaining the concept to the next new joiner.
Tips to crack the Adobe Frontend Development interview
Practise DSA and puzzles, which have commonly appeared in Adobe interviews alongside OOP and operating system questions.
Use Adobe Acrobat or Express and be ready to suggest a feature or test plan for one of its products.
For data roles, read about Adobe Analytics and Experience Platform, since many teams work on customer and marketing data.
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; Adobe interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Adobe Frontend Development interview?
Candidates usually go through 5 stages: Online assessment (aptitude + coding); Technical round 1 (DSA); Technical round 2 (DSA + CS fundamentals); Hiring manager round; HR round. 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 Adobe Frontend Development interview?
This practice set leans on Frontend Architecture (7), Modern JavaScript (6), Build Tools and Tooling (4), CSS Architecture and Accessibility (3). Revise those first, then practise explaining one or two of your own projects end to end, because most Adobe interviewers ask you to walk through real work.
Are these the exact questions asked at Adobe?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Adobe's. They are not a leaked or verified list of past questions.
Where does Adobe hire Frontend Development professionals in India?
Adobe has large teams in Noida, Bengaluru, Gurugram. Openings and locations change often, so check the Adobe careers page and filter by city and experience.
Frontend Development questions for similar companies