Adobe Interview Questions (2026): Most Asked, With Answers

Most engineering loops start with a recruiter screen, then one or two technical phone screens covering coding and sometimes a short design question, then a final round of four to five onsite (usually virtual) interviews. That final round typically mixes one or two coding interviews, one system design or architecture discussion, one interview focused on the specific team's domain (graphics, PDF internals, distributed services, whatever the team actually builds), and a behavioral or "Adobe for All" values conversation.

The exact mix shifts by level and by team. A senior or staff candidate sees less pure algorithm coding and more deep technical discussion about tradeoffs in systems they've actually built. An intern or new grad loop leans harder on fundamentals: arrays, strings, trees, basic complexity analysis.

For some new grad and early-career roles, yes, an online coding assessment on a platform like HackerRank or Codility is common before you get to a live phone screen. For most experienced-hire engineering roles, the loop moves straight to live phone screens instead of a take-home, since Adobe (like most large software companies at this point) has mostly moved away from unpaid take-home projects for senior candidates. Design and product roles are more likely to include a portfolio review or a live product critique instead of a coding assessment.

Not coding in the traditional sense, but expect a working session that's functionally similar. Product managers usually get a live product sense or metrics exercise, walking through how you'd prioritize a feature or diagnose a metric drop, worked out loud in real time rather than presented from slides. Designers get a portfolio walkthrough followed by live critique or a whiteboard exercise sketching a solution to a prompt they're given on the spot. The format changes, but the expectation that you think out loud in front of the interviewer instead of reciting a rehearsed answer is the same across all three tracks.

Floyd's cycle detection, two pointers moving at different speeds, is the standard answer. If a fast pointer moving two nodes at a time ever equals a slow pointer moving one node at a time, there's a cycle. If the fast pointer reaches the end of the list, there isn't one.

function hasCycle(head) {
 let slow = head, fast = head;
 while (fast && fast.next) {
  slow = slow.next;
  fast = fast.next.next;
  if (slow === fast) return true;
 }
 return false;
}

It comes up constantly because it's a clean way to check whether a candidate reasons about pointers and memory rather than just memorizing a library call, which matters more at a company with a large native C++ codebase than it would at a purely web-based shop.

The classic two-sum pattern, dressed up in an image-processing frame. A hash map keyed by value, checked as you iterate, gets it done in one pass instead of the naive quadratic approach.

function twoSum(intensities, target) {
 const seen = new Map();
 for (let i = 0; i < intensities.length; i++) {
  const complement = target - intensities[i];
  if (seen.has(complement)) return [seen.get(complement), i];
  seen.set(intensities[i], i);
 }
 return null;
}

The "why is this an image processing problem" framing is mostly flavor text, but a sharp candidate will notice the values are bounded (0 to 255 for 8-bit channels) and mention that a fixed-size counting array would work just as well as a hash map and use less memory, which is exactly the kind of detail that separates a rote answer from one that actually reasons about the data.

Both are O(n) in the number of pixels visited, the algorithmic complexity doesn't change. What changes is the call stack. A naive recursive flood fill makes one function call per pixel, and a large contiguous region on a 40-megapixel image can recurse millions of levels deep, which blows the stack long before it finishes. A queue-based (or explicit stack-based) breadth-first or depth-first version does the exact same traversal iteratively, with no per-pixel function call overhead and no risk of a stack overflow regardless of region size.

function floodFill(image, start, target, replacement) {
 const queue = [start];
 const width = image[0].length;
 const height = image.length;
 while (queue.length) {
  const [y, x] = queue.shift();
  if (y < 0 || y >= height || x < 0 || x >= width) continue;
  if (image[y][x] !== target) continue;
  image[y][x] = replacement;
  queue.push([y + 1, x], [y - 1, x], [y, x + 1], [y, x - 1]);
 }
}

A raster image is a fixed grid of pixels, each with its own color value, so zooming in past its native resolution reveals visible blocks rather than more detail. A vector image describes shapes mathematically, as points, curves, and fills, so it can scale to any size with no loss of quality, since the shape gets recalculated at render time rather than sampled from a fixed grid.

Photoshop is built around raster editing because it's fundamentally a photo and pixel-manipulation tool, photographs are inherently raster data captured by a camera sensor. Illustrator is built around vectors because it's aimed at logos, icons, and print work where the same artwork needs to scale cleanly from a business card to a billboard without redoing the artwork at each size.

Non-destructive editing means changes are stored as instructions layered on top of the original data rather than baked permanently into it, so you can always go back and adjust or remove an edit without losing anything. Adobe Camera Raw and Lightroom are built entirely around this idea: every adjustment, exposure, white balance, cropping, is metadata sitting alongside the original raw file, which never gets altered.

Photoshop's adjustment layers and smart objects work the same way: an adjustment layer changes how the layers beneath it render without modifying their actual pixel data, and a smart object preserves the original embedded content so a filter or transform applied to it can be re-edited or removed later. The opposite, destructive editing, permanently changes the pixel data on the spot, which is faster and uses less memory but forgives no mistakes.

Under the perpetual license model, which Adobe largely phased out starting in 2013, you paid once for a specific version of a product (Photoshop CS6, say) and owned that version outright, with major upgrades sold as separate paid purchases every year or two. Creative Cloud is subscription-based: a monthly or annual fee gets continuous access to the current version of every app in the plan, with updates delivered continuously instead of as discrete paid releases.

The business tradeoff is straightforward from Adobe's side: subscription revenue is recurring and more predictable than lump-sum upgrade sales, and it funds continuous feature delivery instead of saving improvements for a big annual release. The tradeoff for users is the opposite of ownership, access ends the moment the subscription lapses, which is the most common criticism of the model from long-time Adobe customers who preferred owning a version outright.

The honest first question is who the feature is actually for. Photoshop's core users are professionals who already tolerate a steep learning curve in exchange for depth and control, so a feature aimed at that audience belongs there even if it adds UI complexity. Adobe Express exists specifically for people who want a fast, templated result without learning Photoshop at all, so a feature aimed at speed and simplicity for a casual user belongs in Express instead, even if a version of it already exists buried three menus deep in Photoshop.

Adobe has visibly struggled with this exact tension for years, features sometimes get added to Photoshop that arguably should have been an Express-only capability, adding UI weight to a tool professionals already find complex. A candidate who names that real tension, rather than pretending the answer is always obvious, is showing genuine product judgment.

This is a low-stakes-sounding question that's actually checking whether you've used the product at all before showing up. A specific, honest opinion, generative fill's edge blending has visibly improved over the past couple of releases but still struggles on complex textures, say, lands far better than a vague compliment about how innovative the company is.

Interviewers aren't looking for you to agree with everything Adobe ships. A well-reasoned critique of a real feature, backed by a specific example of where it worked or didn't for you, shows more genuine engagement with the product than blanket praise ever does.

The answer that lands well is specific about what the feedback actually was and how you delivered it, not just "I was honest and it went fine." Name the actual problem you saw, describe how you framed it so it was about the work rather than the person, and be honest about how it was received, including if it didn't go perfectly at first.

A weak answer here is vague ("I always try to be constructive") with no real example attached. A strong one names a specific decision that changed as a direct result of your feedback, or is honest that the feedback wasn't taken and describes what you did next.

Interviewers here are checking two things at once: whether you actually own mistakes rather than deflecting them, and whether you have a real process for catching and fixing problems after they ship, not just a story about the bug itself. Walk through how you found out about the problem, what you did in the immediate aftermath, and what changed afterward, a new test, a new review step, a new alert, so the same class of problem is less likely to happen again.

Avoid a story where the resolution is entirely someone else's doing. Even if a teammate found the bug or a manager decided the fix, your part of the story should show what you personally did in response.

A weak answer here is generic enough to work for any large tech company: "I love creativity" or "Adobe is a leader in its space." A strong one names something specific: a product you've actually used and have an opinion on, a technical problem particular to Adobe's scale (millions of users depending on decades-old file format compatibility, say) that genuinely interests you, or the specific business you'd be joining and why that one over the others.

It's fine, and often better, to be honest that you're also excited about the breadth: Adobe spans desktop software, cloud services, enterprise SaaS, and generative AI under one roof, which is a genuinely unusual range for one company to operate at a serious level in all four.

Sensei is Adobe's older AI and machine learning platform, in production for close to a decade, that powers recognition and automation features across the product line: subject selection, auto-tagging, content-aware fill's earlier non-generative version, auto reframe in Premiere. Firefly is newer, launched in 2023, and specifically focused on generative capabilities, creating new images, text effects, and vector graphics from a text prompt rather than recognizing or transforming content that already exists.

The two aren't competing technologies, they solve different problems, and in practice a lot of Adobe's newer feature announcements combine both: a Sensei model might identify what's in an image so a Firefly model knows what context to generate new content into. Interviewers who ask this are mostly checking whether you understand that "Adobe AI" isn't one single thing internally.

Four to five rounds is typical for an engineering role: one or two rounds on data structures and algorithms, one system design round, one round with the hiring manager or a senior engineer on the team that goes deep on your actual past work and the team's specific domain, and one behavioral round, sometimes folded into the hiring manager conversation rather than run separately.

Product manager loops usually swap one coding round for a product sense or metrics case round, and add an execution round where you walk through a launch you owned end to end. Design roles almost always include a portfolio presentation as its own dedicated block, often 45 minutes to an hour, longer than any single engineering round.

The bar for seniority is roughly consistent, but what gets tested differs a lot. A Creative Cloud desktop app team (Photoshop, Illustrator, Premiere) leans on C++, memory and performance reasoning, and graphics or rendering fundamentals. Document Cloud teams care more about file format correctness, backward compatibility (a PDF made in 2003 still has to open correctly today), and accessibility standards. Experience Cloud, being the enterprise SaaS side of the business, runs interviews that look close to what you'd see at a typical large B2B software company: distributed systems, data pipelines, multi-tenant architecture.

If you're applying broadly, it's worth asking the recruiter directly which business unit and product you'd land on before you over-prepare for the wrong kind of technical depth.

A hash map for O(1) lookup paired with a doubly linked list for O(1) reordering and eviction. Every access moves that entry to the front of the list; when the cache is full, the entry at the back gets evicted.

from collections import OrderedDict

class LRUCache:
  def __init__(self, capacity):
    self.capacity = capacity
    self.cache = OrderedDict()

  def get(self, key):
    if key not in self.cache:
      return -1
    self.cache.move_to_end(key)
    return self.cache[key]

  def put(self, key, value):
    if key in self.cache:
      self.cache.move_to_end(key)
    self.cache[key] = value
    if len(self.cache) > self.capacity:
      self.cache.popitem(last=False)

The real-world tie-in matters here: a PDF viewer rendering a 2,000-page document can't hold every rendered page in memory at once, so it caches a window of recently viewed pages and evicts the ones furthest from where you're currently scrolled. That's an LRU cache with a twist, eviction priority based on scroll distance rather than pure recency, and mentioning that twist unprompted is a strong signal.

Sort the rectangles by their starting x-coordinate, then walk through them once, merging any rectangle that overlaps with the current merged region and starting a new region whenever one doesn't.

function mergeIntervals(rects) {
 rects.sort((a, b) => a.start - b.start);
 const merged = [rects[0]];
 for (let i = 1; i < rects.length; i++) {
  const last = merged[merged.length - 1];
  const current = rects[i];
  if (current.start <= last.end) {
   last.end = Math.max(last.end, current.end);
  } else {
   merged.push(current);
  }
 }
 return merged;
}

This is a one-dimensional simplification of the actual problem, real selections are 2D regions, sometimes non-rectangular, but interviewers use the 1D version to check whether you can reason about sorting plus a single pass before jumping to something more complicated than the question needs.

The command pattern is the standard structure: every action, a brush stroke, a filter application, a layer move, gets represented as an object with a do and an undo method, and both get pushed onto an undo stack. Undo pops from that stack, calls the undo method, and pushes the action onto a redo stack. Redo does the reverse. Doing any new action after an undo clears the redo stack, since the history branches at that point.

class HistoryManager {
 constructor() {
  this.undoStack = [];
  this.redoStack = [];
 }
 do(action) {
  action.execute();
  this.undoStack.push(action);
  this.redoStack = [];
 }
 undo() {
  const action = this.undoStack.pop();
  if (!action) return;
  action.undo();
  this.redoStack.push(action);
 }
 redo() {
  const action = this.redoStack.pop();
  if (!action) return;
  action.execute();
  this.undoStack.push(action);
 }
}

At real scale, storing a full image snapshot per undo step is too expensive for a large canvas, so most editors store diffs, only the pixels a brush stroke actually touched, rather than the whole layer, and cap the history length so memory doesn't grow unbounded across a long editing session.

The core principle is that cloud connectivity should enhance the desktop experience, not gate it. Autosave, library sync, and cloud document storage should all queue their operations locally and flush them once connectivity comes back, rather than blocking the user's ability to keep editing and saving locally in the meantime.

The design detail that actually matters is conflict resolution once connectivity returns: if a user kept editing offline while a cloud version of the same file also changed (say, a collaborator edited it from another device), the reconnection logic needs a clear, visible way to surface that conflict rather than silently picking one version and discarding the other. Silently overwriting a user's offline work to reconcile with the cloud version is the single worst outcome a design like this can produce, and a good candidate calls that out directly.

Different devices and software render color differently because they can each interpret the same numeric pixel values against a different assumed color space. Color management is the system that keeps color numerically consistent across that chain by attaching an explicit color profile to an image and having every application in the pipeline honor it rather than guessing.

The mismatch you're describing usually comes down to whether the software is color-managed at all. Photoshop reads the embedded ICC profile and converts it correctly for your monitor's color space. Many web browsers, and most operating system image viewers, historically either ignored embedded profiles or handled them inconsistently, so an image tagged with a wide-gamut profile like Adobe RGB can look noticeably duller or more saturated in a browser that treats it as plain sRGB without converting.

An ICC profile is a standardized file describing exactly how a specific device or color space maps numeric color values to actual visible color, following a specification maintained by the International Color Consortium. It's what lets a color management system translate color accurately between a camera, a monitor, and a printer, three devices that each render the same RGB values differently without a shared reference to translate through.

Adobe ships several because different workflows need different reference spaces: sRGB for anything destined for the web, Adobe RGB for a wider gamut suited to print and photography work, and ProPhoto RGB for an even wider gamut used in high-end photo editing where you want maximum room to make adjustments before clipping any color detail. Picking the wrong one for your output destination is one of the most common real-world color mistakes professional users make.

PostScript is a full programming language for describing a page, originally designed to drive printers, and rendering a PostScript file requires actually executing its instructions in order. PDF, which Adobe introduced in 1993, is a simplified, non-programmable page description format built for the opposite goal: reliably viewing and printing a document identically across different machines, operating systems, and printers, without needing a full interpreter to run arbitrary code just to see the page.

Adobe built PDF specifically to solve the "it looked right on my machine" problem that plagued document sharing before it existed, a document authored on one system, with one set of fonts installed, often looked completely different or broke outright when opened somewhere else. PDF fixed that by embedding fonts and describing layout in a fixed, portable way, which is the entire reason "Portable" is in the name.

Firefly is Adobe's family of generative AI models, integrated directly into Creative Cloud apps (generative fill in Photoshop, text-to-template in Express, text effects in Illustrator) rather than shipped as a standalone tool you'd use separately. Adobe markets it as trained on Adobe Stock content, openly licensed content, and public domain content, positioning it specifically as commercially safe to use, meaning Adobe offers IP indemnification for content generated with it in enterprise plans.

That positioning is a direct response to the commercial and legal uncertainty around training data that surrounds a lot of other generative image tools. Whether that framing fully holds up under scrutiny is a genuinely debated question, but it's the specific angle Adobe leads with, and it's worth understanding going into any interview that touches Firefly.

Sensei is Adobe's older, broader AI and machine learning platform, predating Firefly by several years, that powers discriminative features across the product line rather than generative ones. Select Subject in Photoshop uses a Sensei-trained model to segment the main subject of a photo automatically. Lightroom's auto-tagging and search-by-content use it to recognize what's in a photo without a human manually keywording every image. Premiere Pro's auto reframe, which repositions a video's framing for different aspect ratios, is another Sensei-powered feature.

The distinction worth knowing: Sensei features generally recognize, classify, or transform existing content, and Firefly features generate new content from a prompt. Adobe has increasingly folded Sensei's capabilities and Firefly together under a broader "Adobe AI" umbrella in its marketing, but the underlying technical distinction between recognition and generation is still a meaningful one to understand.

The framing matters before jumping to a fix. Low per-app usage across a large bundled suite isn't automatically a problem, that's how bundled software has always worked, most Microsoft Office users don't touch Access or Publisher either, and the bundle can still be the right pricing structure even if individual app usage is uneven.

The more useful question is whether low usage of an app correlates with subscription cancellation, since that's the number that actually matters commercially. If a subscriber who only ever opens Photoshop is just as likely to renew as one who also uses Illustrator and Premiere, the unused apps aren't hurting retention and don't need fixing. If low breadth of usage does predict churn, the fix is usually better in-app discovery of adjacent tools at the moment a user's task would benefit from them, not forcing usage through marketing alone.

Start with what each segment is actually worth to the business today versus where the growth is. Professional users are typically higher revenue per seat and more vocal, and losing them to a competitor carries real reputational risk in an industry where professionals talk to each other constantly. The prosumer and casual segment is growing faster in absolute numbers and is where products like Express and Lightroom mobile compete directly against Canva and similar tools.

My honest take is that this is rarely a clean either-or once you dig into a specific request. A lot of prosumer-driven feature requests, better templates, simpler defaults, faster export, don't actually conflict with what professionals want; they just need to ship without disrupting the professional workflow, often as an opt-in default rather than a forced change. The real prioritization skill is figuring out which requests are genuinely zero-sum between the two segments and which just look that way at first glance.

The strongest version of this answer shows you raised the disagreement directly and respectfully, with a specific reason, rather than either staying silent or complaining about it after the fact to other people. Then it's honest about the outcome. If your manager changed their mind, say what argument actually moved them. If they didn't, describe how you committed to the decision anyway once it was made, since "disagree and commit" is a real, common expectation at this level, not just a corporate phrase.

A red flag answer here is one where you were right and everyone eventually admitted it, with no acknowledgment of any nuance in the original disagreement. Real disagreements are rarely that clean, and interviewers notice when a story is too tidy.

Adobe's products sit at the intersection of creative work, engineering, and (increasingly, with generative AI) legal and policy concerns, so cross-discipline collaboration questions come up often. A good answer names a specific point of friction between the two disciplines' priorities, engineering wanting to ship a simpler version, design wanting more polish, legal flagging a licensing risk in a generative feature, and how you actually resolved it, not just that everyone eventually got along.

The detail that separates a strong answer from a generic one: what you personally did to bridge the gap, translating one side's concern into terms the other side could act on, rather than just being present in the room while other people worked it out.

Name the actual gap in information you were missing and why you couldn't just wait for more data, a deadline, a cost to delaying, a decision that had to be made before the missing information would even become available. Then walk through what you used instead: a smaller pilot, a proxy metric, direct user interviews, expert judgment from someone with more context, and be honest about the risk you accepted by moving forward anyway.

The follow-up question worth being ready for is what happened after: did the decision hold up once more data came in, and if not, what would you do differently. A candidate who's only ever told the version of this story where they turned out to be right hasn't been tested on it yet.

Adobe's product surface is unusually wide, color science, video codecs, PDF internals, distributed systems, machine learning, so almost every role eventually requires learning a domain you didn't already know cold. A good answer names the specific domain, how you actually ramped up (reading the spec, shadowing someone who already knew it, building a small throwaway project to force yourself to apply it), and a concrete example of using that new knowledge to make a real decision, not just that you "read up on it."

The weakest version of this answer stops at "I'm a fast learner" with no specific domain named. The strongest one picks a domain genuinely far from your background, so the interviewer can tell the learning curve was real.

The Content Authenticity Initiative (CAI) is a cross-industry effort Adobe launched in 2019 to build standards and tools for attaching verifiable provenance information, who created a piece of content, what tools or edits touched it, whether AI was involved, directly to the content itself as tamper-evident metadata (Content Authenticity Initiative). Adobe started it partly out of self-interest, its own tools are the ones editing and generating huge volumes of the world's images, and partly as a genuine response to the growing difficulty of telling real content from manipulated or fully generated content online.

It's worth knowing that CAI isn't Adobe going it alone. It's a coalition that includes major camera manufacturers, news organizations, and other software companies, which matters for any question about whether this kind of provenance standard can actually work: a single company attaching metadata to its own exports doesn't solve anything if no one else honors or displays that metadata.

Adobe's public position is that Firefly is trained on Adobe Stock content, openly licensed content, and public domain content whose licensing terms permit that kind of use, explicitly distinguishing it from models trained by scraping the open web without regard to individual images' licensing status. Because of that framing, Adobe offers IP indemnification for Firefly-generated content on its enterprise plans, effectively saying it will stand behind the legal safety of what the model produces.

Commercially, that's a direct pitch to enterprise customers, publishers, agencies, large brands, who need generated content they can actually use without inheriting an unresolved copyright question. Whether every detail of that training claim holds up to full external scrutiny is a genuinely contested question outside Adobe, but the commercial logic behind leading with it is straightforward and worth understanding either way.

Embedding a feature like generative fill directly into Photoshop meets users where their existing workflow already lives, no new app to learn, no context switch, and it benefits immediately from Photoshop's existing distribution and installed base. The cost is that it adds real complexity to a tool professionals already consider dense, and it ties the feature's release cadence to Photoshop's own update cycle rather than letting it ship and iterate independently.

A separate product, the way Firefly also exists as its own standalone web app, can iterate faster and reach an audience that never opens Photoshop at all, but it starts from zero distribution and has to earn its own habit formation from scratch. Adobe has actually done both at once with Firefly, embedded inside existing apps and available standalone, which is a reasonable hedge when you're not sure yet which distribution model will win for a given feature.

Firefly and the broader generative AI org sit closer to a research-adjacent ML engineering loop: expect questions on model evaluation, latency and cost tradeoffs for serving generative requests at scale, and how you'd think about data provenance and licensing, a topic that matters more at Adobe than at most AI labs given how publicly the company has marketed Firefly as trained on licensed and public domain content. Classic desktop teams stay closer to systems and graphics fundamentals: rendering pipelines, memory management, file format internals.

Because the generative AI org has grown quickly and pulls engineers from very different backgrounds, ML research, classic backend, even people from the Photoshop C++ team moving over, the interview bar there is genuinely less standardized than on a team that's been running the same loop for a decade. Candidates report more variance interview to interview on that team than anywhere else in the company.

A PDF's internal structure already helps here. Each page's content stream is a separate object, and the file's cross-reference table (or cross-reference stream in newer PDFs) tells you the byte offset of every object without needing to parse the file sequentially. That means you can seek directly to a given page's content stream, decompress just that stream, and search it, instead of loading the entire multi-gigabyte file into memory up front.

For a real search-across-thousands-of-pages feature, the practical answer is to build an index once (extract text per page, tokenize it, store it in something like an inverted index) rather than re-parsing the raw PDF on every search. Acrobat's own full-text search, and Adobe's underlying PDF specification, which is now an open ISO standard (ISO 32000), work exactly this way: index at ingest time, query the index at search time, and only touch the original file bytes when you need to jump to and render the actual matching page.

A PDF page is fundamentally a set of drawing instructions, text positioned at coordinates, lines, images, with no inherent notion of reading order or semantic structure. Tagged PDF adds a parallel structure tree on top of that visual layer: tags marking which content is a heading, a paragraph, a table cell, a list item, and in what logical reading order, separate from the visual positioning.

Screen readers and other assistive technology read the tag structure, not the raw visual layout, which is exactly why an untagged PDF, a scanned document with no underlying structure, is effectively invisible to a screen reader even though a sighted user can read it fine. Interactive forms work the same way: an AcroForm field is a distinct object type layered into the page with its own name, type, and validation rules, addressable independently of the surrounding static content around it.

The honest starting point is that these competitors aren't all threatening the same layer of Adobe's business equally. Canva competes hardest for the casual, template-driven use case that Adobe Express is specifically built to defend, not core Photoshop or Illustrator. GIMP has existed as a free Photoshop alternative for over two decades without meaningfully dislodging Photoshop among working professionals, because professional workflows depend on ecosystem integration, plugin support, and file compatibility with other professionals' tools, not just raw feature parity. Figma is a sharper threat specifically in UI and collaborative design work, a space Adobe entered later with Adobe XD and has since folded into other efforts after XD's own traction stalled.

Defending value against that pressure isn't really about matching price, professionals already pay for Creative Cloud because switching costs (muscle memory, file compatibility, plugin ecosystems, industry-standard workflows) are real and expensive to walk away from. The more useful defense is making sure Adobe doesn't cede the segments below professional, prosumer and casual creators, to Canva-style tools by mistake, since that's genuinely where the newer competitive pressure sits, not in the professional tier itself.

This question has gotten more common specifically because of generative AI, questions about training data provenance, content authenticity, and copyright sit closer to the center of Adobe's business now than they did five years ago. A strong answer names the actual risk you saw, not a vague sense of discomfort, walks through how you raised it and to whom, and is honest about whether you had the authority to actually stop the thing or only to flag it upward.

Interviewers are specifically listening for whether you escalated appropriately rather than either staying quiet or unilaterally blocking something outside your authority to block. Both extremes are red flags in a different direction; the middle, raising it clearly to the person who could actually decide, is the answer that reads as mature judgment.

C2PA (the Coalition for Content Provenance and Authenticity) is the open technical standard behind the Content Authenticity Initiative's tooling, co-founded by Adobe along with other companies including Microsoft, and it defines exactly how provenance data, "Content Credentials," gets cryptographically signed and attached to a piece of media so it survives (or visibly breaks, if tampered with) as the file moves across platforms (Coalition for Content Provenance and Authenticity).

For a non-technical stakeholder, the useful analogy is a nutrition label attached to a photo instead of a food product: it doesn't stop anyone from creating misleading content, but it gives a viewer, or a platform, a verifiable way to check who made something and what tools touched it along the way, the same way a nutrition label doesn't stop a company from making unhealthy food but does let a shopper check the ingredients instead of trusting the packaging alone.

A layer panel is a tree: groups contain layers or other groups, arbitrarily nested. Flattening it is a straightforward depth-first traversal, but a good answer also handles the ordering constraint, layers inside a group need to stay in their original relative order once flattened, and a group's own visibility or lock state should propagate down to its children rather than being silently dropped.

function flattenLayers(node, result = []) {
 if (node.type === "layer") {
  result.push(node);
 } else if (node.type === "group") {
  for (const child of node.children) {
   flattenLayers(child, result);
  }
 }
 return result;
}

A candidate who asks "does a hidden group mean its children are effectively hidden too, even if a child layer is individually marked visible?" before writing code is showing exactly the kind of product-aware thinking this question is fishing for.

The core problem is merging concurrent edits from multiple users without losing anyone's changes or forcing a hard lock on the document. Two well-known approaches: operational transformation, which transforms each incoming operation against every operation that happened concurrently so they all still apply correctly, or CRDTs (conflict-free replicated data types), which structure the data so operations commute and merge deterministically without needing a central transform step.

A practical answer also covers presence (showing who's viewing or editing which part of the document right now, usually over a WebSocket connection) and the reconciliation story for a client that goes offline mid-edit and reconnects later with a batch of local changes to replay against whatever changed on the server in the meantime.

An asynchronous, queue-based rendering pipeline: when a file is uploaded, a job goes onto a queue, a fleet of rendering workers picks jobs off it, renders the first page or a flattened preview, and writes the result to object storage keyed by file hash plus a size variant (thumbnail, medium, full preview). A CDN sits in front of that object storage for actual serving, so a popular shared file's thumbnail gets served from an edge cache instead of hitting the rendering pipeline or origin storage on every view.

The detail worth raising unprompted: cache invalidation on file update. If a user edits a PSD, the old thumbnail is now wrong, so the system needs to either version the cache key by content hash (so an edited file naturally gets a new key and the old thumbnail just becomes unreferenced rather than needing explicit invalidation) or push an active invalidation event through the CDN, which is more complex and more failure-prone than letting content-addressing handle it implicitly.

Store the first version in full, then store every subsequent version as a diff (a binary delta) against the previous version rather than a complete copy. Rolling back to an old version means replaying diffs forward from the nearest stored full snapshot, or backward by applying inverse diffs, whichever direction is cheaper for that particular version.

A practical system periodically stores a full snapshot again, every 20 or 50 versions, say, rather than diffing purely against the original forever, since a long chain of diffs makes reconstructing an old version progressively slower the further back you go. That snapshot cadence is a direct storage-cost-versus-restore-speed tradeoff, and naming that tradeoff explicitly is what turns an okay answer into a strong one.

Adoption and repeat usage come first, the percentage of active Photoshop users who try generative fill at all, and of those, how many come back to use it again within a week versus trying it once out of curiosity and never touching it again. A feature with high one-time trial and low repeat usage is a novelty, not a success.

Beyond usage, quality and trust metrics matter specifically for a generative feature: how often a user accepts the first generated result versus regenerating multiple times before settling on one, since a high regeneration rate signals the model isn't hitting what users actually want on the first try. And a business metric layered on top, whether access to the feature correlates with upgrading from a lower to a higher subscription tier, since that's ultimately what justifies the compute cost of running it at scale.

Creative Cloud Libraries hold shared assets, color swatches, character styles, graphics, that need to stay consistent across every app and device a user touches. The design centers on a sync protocol built around versioned metadata and content-addressed asset storage: each asset gets a hash-based identifier, and clients sync by comparing metadata version numbers rather than re-downloading full asset content every time, only pulling the actual bytes when a hash they don't already have shows up.

Conflict handling matters more here than in a single-user file system, because two clients can edit the same library asset offline and reconnect at different times. A reasonable default is last-write-wins at the individual asset level with a visible conflict resolution UI for the rare case where the same asset changed on two clients before either saw the other's update, rather than trying to auto-merge something like a color palette, which usually isn't meaningfully mergeable anyway.

Two mechanisms working together: a token bucket rate limiter per user to enforce a hard cap on requests per minute, and a priority queue in front of the actual GPU inference workers so paid-tier requests jump ahead of free-tier ones without free-tier requests starving entirely.

A single global FIFO queue would let a burst of free-tier traffic push paid customers' wait times up unpredictably, which is a real business problem, not just a technical inconvenience, since paying customers are the ones with an SLA expectation. A common real-world pattern is a small number of separate queues, one per tier, each drained by workers at a different rate, plus a fairness mechanism inside the free tier itself, weighted round robin or similar, so no single free user can starve every other free user during a burst. Autoscaling the worker fleet based on queue depth, with a floor reserved specifically for paid-tier capacity that never gets reassigned even under load, rounds out a complete answer.

Hash the content of every uploaded asset (SHA-256 is a reasonable default) and use that hash as the storage key. When a new upload's hash already exists in storage, don't write a second copy, just add a new reference (owner, permissions, upload timestamp) pointing at the existing content. The asset only actually gets deleted from storage once its reference count drops to zero.

The tricky part isn't the hashing, it's permissions. Two users can end up pointing at the exact same underlying bytes (the same stock photo, the same common brush preset) while having completely different access rights to it, so the permission model has to live entirely at the reference layer, not the content layer. A design that conflates "who can see this content" with "does this content exist" breaks the moment two unrelated users happen to upload the same file.

A layered permission check: first evaluate the broadest applicable rule (an organization-wide policy, if one exists), then a team or shared-library-level rule, then any individual share the file's owner explicitly granted, with the most specific rule that actually applies winning over broader defaults. Effective permission for a given user on a given file is the resolved outcome of walking that chain, not a single flat lookup.

The part worth raising unprompted is caching. Checking a multi-level permission chain on every single file access is expensive at scale, so a real system caches the resolved effective permission per user per file, and the hard problem becomes invalidating that cache correctly the moment any layer changes, an admin revoking team access, an owner changing an individual share, so a user doesn't keep working with a permission level that's already been revoked upstream.