Adobe Full Stack Engineer Interview Questions (2026)

1. 1Online coding test60 minMedium

   Timed HackerRank-style DSA problems plus aptitude/CS MCQs for campus and early-career candidates.

2. 2Technical round 1 (DSA)45 minMedium

   Whiteboard-style DSA with dry runs and complexity analysis; occasional puzzle or probability question.

3. 3Technical round 2 (CS fundamentals + domain)45 minMedium

   OS, DBMS, OOP design, and language depth — C++ internals for product teams, Java/services for Experience Cloud.

4. 4Design round60 minHard

   Low-level design for juniors (e.g. design an undo stack) or system design for seniors (e.g. document sync service).

5. 5Director / hiring manager round45 minMedium

   Project walkthroughs, ownership stories, and team-fit judgment with an engineering leader.

6. 6HR round30 minEasy

   Standard HR discussion on background, relocation (Noida/Bangalore), notice period, and compensation.

1. Q1

   A screen reader user cannot complete the Adobe Stock search page. How would you triage, reproduce, and fix the issue?

   HardOnsite/Full Loop - ArchitectureAccessibilityAdobe-specific

   Context: Adobe Stock search page

   How to answer: The candidate should first describe a systematic triage process: gathering user reports, identifying the specific screen reader and browser, and asking for exact steps to reproduce. Reproduction involves using a screen reader (e.g., NVDA, JAWS, VoiceOver) to navigate the Adobe Stock search page and confirm the reported blockage. The fix would likely involve inspecting the DOM for missing ARIA attributes (e.g., `aria-label`, `aria-labelledby`, `aria-describedby`), incorrect `tabindex` values, or non-semantic HTML elements (e.g., `div` instead of `button` or `a`) that prevent proper navigation or interaction. Implementing semantic HTML5 elements and appropriate ARIA roles/properties would be key to resolving the issue.

2. Q2

   When would you use ARIA in the Lightroom web gallery, and when would you remove it in favor of native semantics?

   StaffOnsite/Full Loop - AccessibilityAccessibilityAdobe-specific

   Context: Lightroom web gallery

   How to answer: ARIA should be used in the Lightroom web gallery primarily when native HTML elements cannot convey the necessary semantic meaning or interactive behavior to assistive technologies. This includes custom UI components like a drag-and-drop reordering interface for photos, a custom slider for image adjustments, or a complex modal dialog. Conversely, ARIA should be removed or avoided when native HTML elements already provide the required semantics and accessibility features, such as standard buttons, links, form inputs, or well-structured headings and lists. Overusing ARIA on native elements can create redundancy, confusion, and even break accessibility features.

3. Q3

   Explain how error recovery changes your component API, QA process, and release checklist for the Premiere timeline panel

   MediumOnsite/Full Loop - UX QualityAccessibilityAdobe-specific

   Context: Premiere timeline panel

   How to answer: Error recovery significantly impacts the component API by requiring explicit error states, retry mechanisms, and hooks for user intervention, moving beyond simple success/fail returns. For QA, it necessitates extensive testing of edge cases, invalid inputs, network failures, and user-cancellation scenarios, often requiring specialized tooling for fault injection. The release checklist must then include verification of error messaging clarity, accessibility of recovery options, logging for diagnostics, and rollback strategies, ensuring a robust user experience even when things go wrong.

4. Q4

   How would you handle accessible errors, validation hints, and recovery paths in a high-stakes comment composer? Include a migration or testing angle specific to Adobe

   MediumOnsite/Full Loop - ArchitectureAccessibilityAdobe-specific

   Context: document signing flow

   How to answer: A strong answer would focus on immediate, context-sensitive feedback using ARIA live regions for errors and validation hints, ensuring screen reader users are informed without losing context. For recovery, provide clear, actionable instructions directly within the error message or near the invalid field, guiding users on how to fix the issue. Emphasize a robust testing strategy, including automated accessibility checks (e.g., Axe-core) integrated into CI/CD, manual screen reader testing (NVDA/JAWS on Windows, VoiceOver on Mac), and user acceptance testing with disabled users, potentially leveraging Adobe's internal accessibility testing frameworks or expert teams.

5. Q5

   How would you ensure a modal, popover, or drawer in the collaborative review panel works for keyboard and assistive technology users?

   StaffOnsite/Full Loop - UX QualityAccessibilityAdobe-specific

   Context: collaborative review panel

   How to answer: A strong answer would focus on proper focus management, ARIA attributes, and keyboard navigation. This includes trapping focus within the modal, restoring focus to the trigger element upon closure, and using appropriate ARIA roles and states (e.g., `role="dialog"`, `aria-modal="true"`, `aria-labelledby`, `aria-describedby`). Keyboard interaction should support `Tab` for navigation within the modal, `Shift+Tab` for reverse navigation, `Escape` for closing, and potentially `Enter` or `Space` for activating buttons. The solution should also address the underlying page's accessibility by either visually hiding or programmatically disabling interaction with content outside the modal.

6. Q6

   Design an accessible document preview for the Creative Cloud asset library. Explain focus order, labels, announcements, and keyboard interaction

   MediumOnsite/Full Loop - AccessibilityAccessibilityAdobe-specific

   Context: Creative Cloud asset library

   How to answer: A strong answer will describe a document preview component that ensures keyboard navigability and logical focus order, typically from left-to-right, top-to-bottom, with clear visual focus indicators. It will detail the use of ARIA attributes for semantic labeling (e.g., `aria-label`, `aria-labelledby`) for document titles, actions (zoom, print), and navigation controls (next/previous page). The candidate should explain how `aria-live` regions or `sr-only` text can announce dynamic content changes or status updates, such as page number changes or loading states, without interrupting the user. Finally, it should cover standard keyboard interactions like `Tab` for navigation, `Enter`/`Space` for activation, and arrow keys for internal control within components (e.g., scrolling through pages, adjusting zoom sliders).

7. Q7

   A screen reader user cannot complete the Acrobat PDF viewer. How would you triage, reproduce, and fix the issue?

   HardOnsite/Full Loop - UX QualityAccessibilityAdobe-specific

   Context: Acrobat PDF viewer

   How to answer: Triage would involve gathering specific details from the user (screen reader type, browser, PDF content, exact failure point) and checking existing bug reports or accessibility audits. Reproduction requires setting up the exact environment, using a screen reader (e.g., NVDA, JAWS, VoiceOver) to navigate the Acrobat PDF viewer, and attempting the user's reported workflow. Fixing would likely involve inspecting the DOM for missing ARIA attributes, incorrect semantic HTML, or keyboard trap issues, then implementing the necessary code changes (e.g., adding `aria-label`, `role`, `tabindex` management) and thoroughly re-testing with screen readers.

8. Q8

   Explain how WCAG conformance changes your component API, QA process, and release checklist for the Illustrator vector inspector

   MediumOnsite/Full Loop - AccessibilityAccessibilityAdobe-specific

   Context: Illustrator vector inspector

   How to answer: WCAG conformance significantly impacts the Illustrator vector inspector's component API by requiring properties for accessible names, descriptions, and state (e.g., `aria-label`, `aria-describedby`, `aria-checked`). The QA process must integrate automated accessibility checks (e.g., Axe-core) and manual testing with assistive technologies (screen readers, keyboard navigation) across various browsers. The release checklist needs explicit sign-offs for WCAG compliance, including VPAT generation, accessibility regression testing, and documentation updates for accessible usage.

9. Q9

   How would you handle accessible errors, validation hints, and recovery paths in a high-stakes message thread?

   MediumOnsite/Full Loop - UX QualityAccessibilityAdobe-specific

   Context: Express template editor

   How to answer: A strong answer would emphasize immediate, non-disruptive feedback using ARIA live regions for errors and validation hints, ensuring screen reader users are informed without losing context. It would detail clear, actionable recovery paths, such as explicit 'fix it' links or buttons that move focus to the problematic field. The answer should also cover visual indicators (color, icons) combined with text for sighted users, and the importance of testing with assistive technologies to validate the user experience. Finally, it should touch on graceful degradation and progressive enhancement for error handling.

10. Q10

    The design for the Adobe Stock search page uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

    HardOnsite/Full Loop - ArchitectureAccessibilityAdobe-specific

    Context: Adobe Stock search page

    How to answer: A strong candidate would emphasize proactive collaboration with design from the outset, advocating for accessibility as a core requirement rather than an afterthought. They would propose specific strategies like providing text alternatives for all icons (e.g., `alt` text for images, `aria-label` for SVG/font icons), ensuring sufficient contrast ratios for subtle elements, and making sure all interactive elements are keyboard navigable and have clear focus indicators. The negotiation would involve presenting data on user impact and legal compliance, offering alternative accessible design patterns, and demonstrating how accessibility enhances usability for all users, not just those with disabilities. The goal is to find a balance where the aesthetic vision is preserved while meeting WCAG standards.

11. Q11

    Audit the Premiere timeline panel for focus management. What checks would you run manually and which would you automate?

    MediumOnsite/Full Loop - UX QualityAccessibilityAdobe-specific

    Context: Premiere timeline panel

    How to answer: A strong candidate would outline manual checks for logical tab order, visual focus indicator presence and contrast, and keyboard operability of all interactive elements within the Premiere timeline. They would then propose automated checks for ARIA attributes related to focus (e.g., `aria-activedescendant`), keyboard trap detection, and basic element visibility/interactivity. The answer should differentiate between dynamic, context-dependent focus behaviors requiring manual testing and static, structural aspects suitable for automation, emphasizing the complexity of a rich application like Premiere Pro.

12. Q12

    When would you use ARIA in the collaborative review panel, and when would you remove it in favor of native semantics?

    StaffOnsite/Full Loop - UX QualityAccessibilityAdobe-specific

    Context: collaborative review panel

    How to answer: ARIA should be used in the collaborative review panel when native HTML elements cannot convey the necessary semantic meaning or interactive behavior to assistive technologies. This includes custom UI components like a drag-and-drop reordering list for comments, a custom multi-select dropdown for assigning reviewers, or a dynamic status indicator for review progress. ARIA is crucial for providing roles, states, and properties that make these non-native elements understandable and operable. Conversely, ARIA should be removed or avoided when a native HTML element already provides the exact semantic meaning and functionality, such as using a `<button>` for a clickable action instead of a `<div>` with `role="button"`, or `<input type="checkbox">` instead of a custom checkbox. Overusing ARIA on native elements can create redundancy or even accessibility conflicts.

13. Q13

    A responsive editable detail panel in the document signing flow fails at tablet widths. How would you debug CSS cascade, layout containment, and overflow?

    MediumPhone/Virtual Technical ScreenCSSAdobe-specific

    Context: document signing flow

    How to answer: A strong candidate would start by using browser developer tools (e.g., Chrome DevTools, Firefox Developer Tools) to inspect the element at the failing tablet width. They would focus on the 'Styles' pane to understand the CSS cascade, identifying overridden or unexpected styles, and the 'Computed' pane to see final applied values. For layout and containment, they would use the 'Layout' or 'Elements' pane to visualize the box model, flexbox/grid containers, and check for unexpected widths, heights, or margins causing overflow. Finally, they would specifically look for `overflow: hidden`, `scroll`, or `auto` properties on parent containers that might be clipping content, and use the 'Event Listeners' or 'Sources' pane to check for JavaScript dynamically altering styles or layout at specific breakpoints.

14. Q14

    The Photoshop web canvas has a visual regression after a design-system update. How would you isolate whether responsive typography is the root cause?

    EasyPhone/Virtual Technical ScreenCSSAdobe-specific

    Context: Photoshop web canvas

    How to answer: To isolate responsive typography, I'd first use browser developer tools to inspect the affected elements' computed styles, specifically looking at `font-size`, `line-height`, and `media` queries. I'd then systematically disable CSS rules related to responsive typography (e.g., `font-size` within `@media` blocks, `clamp()`, `vw` units) to see if the regression resolves. A more targeted approach would involve creating a minimal reproducible example (MRE) with only the affected component and typography styles, or using a CSS preprocessor's inspection tools if available. Finally, I'd compare the current computed styles against a known good version (e.g., via version control or a previous build's dev tools) to pinpoint specific changes.

15. Q15

    How would you support dark mode, high contrast, localization, and reduced motion in the Creative Cloud asset library's CSS architecture?

    MediumOnsite/Full Loop - CodingCSSAdobe-specific

    Context: Creative Cloud asset library

    How to answer: A strong answer would focus on using CSS media queries for dark mode (`prefers-color-scheme`), high contrast (`prefers-contrast`), and reduced motion (`prefers-reduced-motion`). For localization, the candidate should discuss using CSS variables (custom properties) to manage directionality (`dir` attribute and `[lang]` selector) and potentially font stacks, rather than relying solely on JavaScript for style changes. Emphasize a component-based approach where these media queries and variables are applied at the component level or via a global theme, ensuring maintainability and scalability within a large application like Creative Cloud.

Practice these with instant AI feedback in a live mock interview → Start a Adobe Full Stack Engineer mock

Practise DSA and core CS fundamentals; revise OOP and DBMS; prepare project deep-dives

Other roles at Adobe

Full Stack Engineer interviews at other companies