Adobe Software Engineer 2 Interview Experience

Janhavi Rajput

Published : 09 September 2025
Updated : 09 August 2026

60 Views

#interview

#adobe

#dsa

#system-design

#sde-2

#interview-experience

I gave my interview for the Software Engineer 2 (SDE-2) role at Adobe a while back and I've been meaning to write this down properly ever since. So here it is everything I remember, in the order it happened, along with the actual code I wrote for each DSA question. No sugar-coating, no "and then I solved it perfectly" I'll tell you where I struggled too.

There were 4 rounds in total:

Technical Interview (Theory + DSA + Puzzle)
DSA & Technical Concepts
Technical Interview (Experience-focused)
Hiring Manager Round

Let's go through each one.

Round 1: Technical Interview (60 minutes, Remote)

This round was a nice mix some theory, one coding question and a puzzle at the end. It didn't feel like a typical "grind three DSA problems" round, which honestly I liked, since it gave me room to show more than just memorized patterns.

Testing Concepts

They started with Black Box vs White Box testing. I explained it the simple way black box is when you test the app without knowing how the code is written inside, you just check if the input gives the right output. White box is when you do know the internal code and you test the actual logic paths, branches and conditions inside it.

API Fundamentals

Then a few questions on APIs the basic types, what REST really means and general API design questions. Nothing too deep, just enough to check if I actually work with APIs day to day and not just in theory.

DSA Problem: Two Sum

Given an array of numbers and a target value, find two numbers in the array that add up to the target.

This is a classic, but I still walked through it properly instead of jumping straight to the answer, since that's what they actually want to see.

My approach:

I first mentioned the brute force way checking every pair using two loops, which is O(n²). Then I moved to the better way using a HashMap to store numbers I've already seen, so I only need one pass through the array.


public int[] twoSum(int[] nums, int target) {
    Map<Integer, Integer> seen = new HashMap<>();

    for (int i = 0; i < nums.length; i++) {
        int complement = target - nums[i];

        if (seen.containsKey(complement)) {
            return new int[] { seen.get(complement), i };
        }
        seen.put(nums[i], i);
    }
    return new int[] {}; // no pair found
}

The idea is simple: for every number, I check if its "partner" (target minus current number) has already shown up before. If yes, I've found my pair. If not, I just remember this number and keep moving. This way I only go through the array once, so it runs in O(n) time.

Puzzle: 25 Horse Problem

This one caught me off guard a little. The puzzle: You have 25 horses and a race track that can only fit 5 horses at a time. You don't have a stopwatch, so you can't time them individually you can only compare which horses finish first, second and so on in each race. What is the minimum number of races needed to find the top 3 fastest horses out of all 25?

I hadn't seen this exact puzzle before, so I thought out loud with the interviewer instead of freezing up. My approach was to first race the horses in groups of 5 (5 races), then think about which horses could actually still be in contention for the top 3 based on those results and race just those. I got to the right answer of 7 races, but I'll be honest it took me a couple of wrong turns to eliminate the horses that clearly couldn't be in the top 3.

Where I slipped up: In the middle of solving this, I almost said we'd need 8 races because I forgot that the winner of the group-of-5 race between the "second place" horses could actually still be eliminated using logic, without needing to physically race them again. The interviewer gave me a small hint ("think about which horses you can rule out just from what you already know") and that's what got me unstuck. Lesson here with puzzles, don't panic if you don't get it instantly. Thinking out loud and letting the interviewer nudge you is completely normal and expected.

Discussion on Current Work

We closed the round talking about what I actually work on day to day my current project, the kind of problems I solve and how I approach them.

Round 2: DSA & Technical Concepts (60 minutes, Remote)

This round had two coding problems and honestly, this was the round I prepped for the least going in, since I assumed system design or behavioral stuff would take priority. That was a mistake on my part Adobe clearly weighs core DSA heavily even for SDE-2.

Binary Search in a 2D Matrix

The problem: Given a 2D matrix where each row is sorted and the first number of each row is greater than the last number of the previous row, find whether a target number exists in the matrix.

My approach:

since the matrix is essentially a sorted 1D array split across rows, I treated it that way and did a binary search over the whole matrix by converting the single index into a row and column.

public boolean searchMatrix(int[][] matrix, int target) {
    int rows = matrix.length;
    int cols = matrix[0].length;

    int low = 0;
    int high = (rows * cols) - 1;

    while (low <= high) {
        int mid = low + (high - low) / 2;
        int midValue = matrix[mid / cols][mid % cols];

        if (midValue == target) {
            return true;
        } else if (midValue < target) {
            low = mid + 1;
        } else {
            high = mid - 1;
        }
    }

    return false;
}

The trick here is converting a single index mid into a row (mid / cols) and a column (mid % cols). Once you see the matrix as one long sorted line instead of a grid, it's just a plain binary search.

Mistake I made:

I initially wrote matrix[mid / rows][mid % rows] instead of using cols a silly slip that gave wrong results on the first test case. I caught it myself while dry-running with a small example, but it did cost me a minute or two of confusion. Small reminder: always dry-run with real numbers before assuming your formula is right.

Dutch National Flag Problem

The problem: Given an array with only 0s, 1s and 2s, sort it in a single pass without using extra space.

I explained the three-pointer approach one pointer for placing 0s at the start, one for placing 2s at the end and a middle pointer to walk through the array.

public void sortColors(int[] nums) {
    int low = 0, mid = 0, high = nums.length - 1;

    while (mid <= high) {
        if (nums[mid] == 0) {
            swap(nums, low, mid);
            low++;
            mid++;
        } else if (nums[mid] == 1) {
            mid++;
        } else {
            swap(nums, mid, high);
            high--;
            // note: mid does NOT increment here
        }
    }
}

private void swap(int[] nums, int i, int j) {
    int temp = nums[i];
    nums[i] = nums[j];
    nums[j] = temp;
}

The interviewer asked why mid doesn't move forward after swapping with high. Good question because the element we just swapped in from the end hasn't been checked yet, so we need to look at it again before moving on.

Java-Specific Questions

We also spent some time on plain Java questions things like how HashMap handles collisions, difference between == and .equals() and a couple of questions on object mutability.

Round 3: Technical Interview (60 minutes, On-site)

This round felt more personal less about testing raw DSA skill and more about understanding how I actually work and think.

My Work and Team Challenges

We spent a good amount of time here. I talked about a specific project and they asked follow-up questions like what went wrong during it, how I handled disagreements with teammates and what I'd do differently now. I appreciated that they pushed for specifics instead of accepting generic answers.

Where I could've done better: My first answer about a team challenge was a bit too polished and vague I basically gave a "textbook" answer about communication and alignment. The interviewer asked, "but what did YOU specifically do, step by step?" and that's when I actually gave a real, honest account. I realized later I should've led with the specific story from the start, instead of starting broad and only getting concrete when pushed.

DSA Problem: Valid Parentheses (Brackets Validation)

The problem: Given a string containing just the characters (, ), {, }, [, ], determine if the input string is valid meaning every opening bracket has a matching closing bracket in the right order.

This is a classic stack problem and I explained why a stack fits perfectly here every time you see an opening bracket, you push it. Every time you see a closing bracket, you check if it matches the bracket on top of the stack.

public boolean isValid(String s) {
    Stack<Character> stack = new Stack<>();
    Map<Character, Character> pairs = Map.of(
        ')', '(',
        '}', '{',
        ']', '['
    );

    for (char c : s.toCharArray()) {
        if (pairs.containsKey(c)) {
            // closing bracket   check the top of the stack
            if (stack.isEmpty() || stack.pop() != pairs.get(c)) {
                return false;
            }
        } else {
            // opening bracket   just push it
            stack.push(c);
        }
    }

    return stack.isEmpty();
}

One thing I made sure to mention out loud: at the end, if the stack still has unmatched opening brackets left, the string is invalid too it's not enough for the pops to succeed, the stack has to be completely empty at the end.

Round 4: Hiring Manager Round (60 minutes, Remote)

This was the final round and it was a genuine mix of technical fundamentals and behavioral questions.

Java Fundamentals & SQL

We covered basic Java concepts again this time slightly deeper, plus some SQL questions. Things like writing a query to find duplicate records and the difference between INNER JOIN and LEFT JOIN. Nothing too advanced, but you do need to be quick and confident with the basics.

Behavioral Questions

Standard stuff teamwork, conflicts I've faced and what motivates me. I'd recommend having 2-3 real stories ready here rather than trying to improvise on the spot, because these questions tend to repeat across every round in some form.

DSA Problem: Valid Anagram

The problem: Given two strings, check if one is an anagram of the other (meaning both use the exact same letters, same number of times, just possibly in a different order).

My approach: count the frequency of each character in the first string, then subtract the frequency using the second string. If everything cancels out to zero, they're anagrams.


public boolean isAnagram(String s, String t) {
    if (s.length() != t.length()) {
        return false;
    }
    int[] charCount = new int[26];
    for (int i = 0; i < s.length(); i++) {
        charCount[s.charAt(i) - 'a']++;
        charCount[t.charAt(i) - 'a']--;
    }
    for (int count : charCount) {
        if (count != 0) {
            return false;
        }
    }
    return true;
}

I mentioned this only works cleanly for lowercase English letters. If the interviewer wanted a more general solution (Unicode, mixed case), I'd have used a HashMap<Character, Integer> instead of a fixed-size array and I said this out loud too, since showing awareness of the limits of your own solution matters just as much as the solution itself.

Overall Experience

Looking back, the whole process felt well-balanced. It wasn't just about solving DSA problems testing concepts, Java internals, SQL and my actual work experience all played a real part. What stood out to me the most was that in almost every round, they cared more about how I got to an answer than the answer itself. Nobody just wanted the final code they wanted to see the thinking behind it.

What I'd Tell Someone Preparing for This

Don't skip testing and API basics just because you're focused on DSA. Round 1 caught me a little off guard here.
Dry-run your code with real numbers before trusting your formula, especially with index math like in the matrix problem. That's exactly where I slipped.
For behavioral questions, lead with the specific story first, not a general principle. I learned this the hard way in Round 3.
Puzzles are meant to be solved out loud. Don't expect to get it instantly thinking through it with the interviewer is part of the test.
Know the edge cases and limits of your own solution. Saying "this works for lowercase letters, but here's what I'd change for a more general case" shows more maturity than just submitting working code.

That's my full Adobe SDE-2 interview experience. If you're preparing for something similar, I hope this gives you a real, honest picture mistakes included of what to expect.