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

   The design for the brand kit manager uses subtle icons and gestures. How would you negotiate an accessible implementation with design?

   HardOnsite/Full Loop - AccessibilityAccessibilityAdobe-specific

   Context: brand kit manager

   How to answer: A strong candidate would first emphasize collaboration, not confrontation, with design. They would propose an iterative process involving accessibility audits and user testing with diverse groups, including those using assistive technologies. Key technical solutions would include robust ARIA attributes, keyboard navigation, and sufficient color contrast, even for subtle elements. They would also suggest alternative text for icons and explore user-configurable display options to enhance accessibility without compromising the core design aesthetic.

6. Q6

   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.

7. Q7

   Audit the Photoshop web canvas for touch target size. What checks would you run manually and which would you automate?

   MediumOnsite/Full Loop - ArchitectureAccessibilityAdobe-specific

   Context: Photoshop web canvas

   How to answer: A strong candidate would first define touch target size and its importance for accessibility (WCAG 2.5.5 Target Size). They would then outline manual checks for interactive elements like buttons, sliders, and menu items, focusing on visual inspection and using browser developer tools to measure actual dimensions. For automation, they would discuss using accessibility linters (e.g., Axe, Lighthouse) in CI/CD pipelines to flag common violations, especially for standard UI components. Finally, they would mention the need for a hybrid approach, as automation can't catch all context-specific issues, particularly within a complex canvas like Photoshop's.

8. Q8

   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).

9. Q9

   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.

10. Q10

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

    StaffOnsite/Full Loop - ArchitectureAccessibilityAdobe-specific

    Context: Firefly prompt gallery

    How to answer: ARIA should be used when native HTML elements lack the semantic meaning or interactive behavior required for accessibility, such as custom components in Firefly's prompt gallery (e.g., a custom carousel or complex filter UI). It's crucial for conveying roles, states, and properties that assistive technologies need. Conversely, ARIA should be removed or avoided when a native HTML element already provides the necessary semantics and functionality (e.g., using a `<button>` instead of a `<div>` with `role="button"`). Overusing ARIA on native elements can create redundancy, confusion, or even break accessibility, violating the first rule of ARIA.

11. Q11

    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.

12. Q12

    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.

13. Q13

    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.

14. Q14

    How would you ensure a modal, popover, or drawer in the Lightroom web gallery works for keyboard and assistive technology users?

    StaffOnsite/Full Loop - AccessibilityAccessibilityAdobe-specific

    Context: Lightroom web gallery

    How to answer: A strong answer would focus on proper WAI-ARIA roles and properties (e.g., `role="dialog"`, `aria-modal="true"`, `aria-labelledby`, `aria-describedby`) to semantically identify the modal. It should detail robust focus management, including trapping focus within the modal when open and returning focus to the triggering element upon close. Keyboard interaction is critical, specifically handling the `Escape` key to close the modal and ensuring `Tab` and `Shift+Tab` cycle only through elements inside the modal. Finally, the answer should mention managing background content, either by visually hiding it or using `aria-hidden="true"` on the main content to prevent assistive technologies from interacting with it while the modal is open.

15. Q15

    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.

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