What to Expect in the Adobe System Design Interview

Adobe's system design evaluation spans more altitudes than most companies': senior candidates get architecture discussions grounded in Adobe's product scale (creative cloud services, document platforms, and increasingly the AI infrastructure behind features like Firefly), mid-level candidates frequently get low-level design (object-oriented modeling of realistic systems), and database judgment questions (SQL versus NoSQL tradeoffs, schema design, query reasoning) appear across levels. Preparing for only one altitude is the common mistake; knowing which rounds your loop includes, and rehearsing each register, is the fix.

The house flavor across all of them: Adobe's products are craft tools with heavy documents, rich media, and creative workflows, which generates design problems most candidates have never practiced: document models with layers and history, asset pipelines for large binary files, collaboration on complex documents, and now generative-AI features with GPU economics inside consumer products.

The Question Territory

Architecture altitude

• Design a cloud document service. Documents with complex internal structure (layers, pages, embedded assets), versioning and history, sync across devices, and collaborative editing. The document model is the heart: candidates who reason about representing structured documents (operation logs, component trees, asset references) outperform those who jump to generic file storage.
• Design an asset storage and delivery pipeline. Large binary files (PSDs run to gigabytes), thumbnails and previews generated per format, CDN strategy for global creative teams, and deduplication economics.
• Design a generative AI feature at product scale. A Firefly-style flow: prompt intake, GPU inference queuing, latency expectations inside an interactive tool, content moderation, and cost control when millions of users generate images. This theme is growing fast in Adobe loops.
• Design licensing and entitlement systems. Subscription checks across apps and platforms, offline grace periods, and the reliability bar of a system that can lock paying customers out of their tools.

Low-level design altitude

• Design a document editor's core objects: layers, groups, transformations, undo/redo (the command pattern question in its natural habitat).
• Design a plugin architecture: extension points, sandboxing, versioned APIs.
• Design a brush engine, a shape hierarchy, or a file-format parser: classic OOD with craft-tool texture.

Database judgment

• Schema design for projects, assets, versions, and permissions; when SQL's transactions earn their cost versus when document stores fit; and query-shape reasoning.

What Interviewers Are Probing

1. Document-model thinking. Adobe's hardest problems live in the data model: how you represent a layered document so that undo, versioning, sync, and collaboration all remain tractable. Candidates who start with the model and derive the architecture read as native; candidates who start with load balancers read as generic.
2. Large-binary pragmatics. Multi-gigabyte assets break default web assumptions: chunked and resumable uploads, delta sync (a one-pixel edit must not re-upload four gigabytes), preview generation pipelines, and storage tiering. Naming these unprompted signals real understanding.
3. Interactive-latency AI. For the generative prompts: batching versus the user watching a spinner inside their creative flow, queue fairness between free and paid tiers, GPU cost per generation against subscription economics, and moderation in the loop. The cost-latency-quality triangle, inside a consumer product.
4. Undo as a design constraint. Across altitudes, Adobe interviewers love the undo/redo probe: it stress-tests your data model (command logs, immutable snapshots, memory bounds) and it is core to every product they ship.
5. OOD cleanliness under evolution. The LLD rounds grade modeling: interfaces that absorb the follow-up requirement ("now layers can be nested; now plugins can add tool types") without collapse.

Walkthrough Sketch: Cloud Document Service with Sync

Requirements first: layered documents averaging hundreds of megabytes, editing on desktop and tablet, offline work with later sync, version history, and eventual collaborative editing. The design lives or dies on the document model, so start there: represent a document as a tree of components (layers, groups) whose content references content-addressed asset chunks, and record edits as an operation log against that tree rather than as file overwrites. That single decision pays everywhere downstream: undo is log traversal, history is log retention, sync is log exchange, and a one-layer edit ships kilobytes instead of gigabytes.

Sync: clients maintain a local store, apply edits optimistically, and exchange operation logs with the service; conflicts on the same component resolve last-writer-wins per property with both versions retained in history (creative work is precious; silent loss is the cardinal sin, so surface conflicts rather than hiding them). Large assets ride a separate path: chunked, content-addressed uploads with resumability, deduplication across versions (the unchanged background layer is stored once), and preview renditions generated asynchronously per device class. Storage tiers by heat: active documents hot, old versions compacted into snapshots plus retained logs, archives cold. Close with the collaboration extension: the operation-log foundation means multiplayer is an ordering service away (a sequencer per document session), which is exactly why the model-first approach wins: the architecture grew without rewriting its bones.

How to Prepare

• Foundations and depth: Grokking the System Design Interview for the method, Grokking System Design Fundamentals for the blocks, and Advanced System Design Interview, Volume II for replication, consistency, and the sync-conflict territory.
• Drill the two house problems: the layered-document service (model-first) and the asset pipeline (large-binary pragmatics), each end to end. Their patterns transfer to most Adobe prompts.
• OOD reps for the LLD rounds: design a document editor's object model with undo/redo, twice, with a requirement twist mid-session. The command pattern should be reflexive.
• AI-feature fluency: Grokking Modern AI Fundamentals covers the inference, batching, and cost vocabulary the Firefly-style prompts assume.

For the full loop, see What is the Adobe interview process like?, and prepare the values round with Top Adobe behavioral interview questions.