Adobe Computer Scientist 1 Interview Experience: Real Questions, Solutions & Tips

I want to share exactly what happened when I interviewed for a Computer Scientist 1 (CS-1) role at Adobe, because I know how much these write-ups helped me when I was prepping. I'm going to give you the real questions, the exact follow-ups my interviewers asked, how I answered them, the hints that helped me when I got stuck and the fully tested code for every problem so if you're prepping for something similar, you can actually use this. I'm also going to tell you honestly about the part of this process that went badly, because I think that's just as useful to know before you walk in somewhere.

Quick heads up before you dive in: I'm writing this from memory, a few weeks after it happened, so I've reconstructed the exact wording of some exchanges as closely as I honestly can the substance is real, even if I'm not quoting word-for-word court-transcript style. And this is just my one experience with one set of interviewers on one day. It's not a claim about how every team at Adobe runs things treat it as one honest data point, not the full picture.

Quick Facts About My Interview

• Company: Adobe
• Role I interviewed for: Computer Scientist 1 (CS-1)
• Location: Noida, India
• What HR told me to expect: 4–5 technical rounds, including a Manager round and a Director round
• What I actually got through: Round 1 and a very delayed Round 2 the process fell apart before I ever reached the Manager or Director stage
• How hard the actual coding was: Fair and standard dynamic programming, stacks, two pointers, plus core C++ theory
• Outcome: Rejected and I never got real feedback despite asking more than once
• Format: Fully remote

How My Timeline Played Out

• HR called me first and walked me through the process 4 to 5 rounds, ending with a Manager and then a Director
• Round 1 got pushed back an hour, then actually happened
• Round 2, attempt 1: cancelled my interviewer had a health issue
• Round 2, attempt 2: I joined on time, waited 30 minutes, nobody showed up and I couldn't reach HR by phone or email; hours later I was told it was rescheduled again
• Round 2, attempt 3: cancelled again I was told the interviewer was "busy"
• Round 2, attempt 4: rescheduled once more this time HR themselves weren't even sure if the interviewer was actually busy or not
• Round 2, attempt 5: it finally happened two more DSA problems and a disagreement with my interviewer that I'll get into
• A few days later: the rejection email landed in my inbox
• After that: I tried to get feedback more than once and just got silence

Round 1: C++ Fundamentals, Then Two Coding Problems

Round 1 started about an hour late, but at least it happened. My interviewer opened with some C++ theory before we got into any code.

The Fundamentals Questions

Interviewer asked: "Can you tell me the difference between a pointer and a reference?"

How I answered: I explained that a pointer is a variable that holds a memory address you can point it somewhere else later, it can be null and you need to dereference it with * to get the actual value. A reference, on the other hand, is more like a nickname for an already-existing variable. Once you bind a reference to something, it's stuck referring to that thing forever and it can never be null. I added that in practice, I reach for a reference when a function absolutely needs a valid value and there's no reasonable "nothing" case and I reach for a pointer when the value might legitimately be absent or when I need to repoint it at something else down the line.

Interviewer asked (follow-up): "Okay and what's a stack overflow can that happen without recursion?"

How I answered: I said a stack overflow happens when your program uses up more stack memory than it was given usually people think of runaway recursion with no proper base case as the cause, but that's not the only way it happens. I gave two other examples on the spot: declaring a massive array as a local variable inside a function (something like a million-element array sitting on the stack instead of the heap) or having an extremely deep chain of regular, non-recursive function calls where each one uses a good chunk of stack space. She seemed satisfied with that.

Interviewer asked: "What is heap memory?"

How I answered: I described it as the pool of memory you request manually at runtime through new in C++ as opposed to memory tied to a function's local scope that disappears the moment the function returns. I mentioned that heap memory sticks around until you explicitly free it and that forgetting to is exactly how memory leaks happen, which is why I try to reach for smart pointers like std::unique_ptr in real code instead of raw new/delete pairs.

Problem 1: House Robber

She described the problem in her own words: you've got a row of houses, each with some amount of cash inside and you want to rob as much total cash as possible but you can never rob two houses that are next to each other or the alarm trips.

How I thought through it out loud: I told her that for any single house, I really only have two choices: rob it or skip it. If I rob it, I can't touch the house right before it, so the best I can do is this house's cash plus whatever the best result was two houses back. If I skip it, my best result is just whatever the best result was one house back. Whichever of those two numbers is bigger, that's my answer for this house.

I started with the plain recursive version, since it maps most directly onto that idea:

// Brute force: try both choices (rob / skip) at every house.
// O(2^n) time -- explores every valid combination.
int bruteForce(vector<int>& nums, int i) {
    if (i >= (int)nums.size()) return 0;
    int skip = bruteForce(nums, i + 1);
    int rob = nums[i] + bruteForce(nums, i + 2);
    return max(skip, rob);
}

Interviewer asked: "Okay, that works but what's the time complexity and can you do better?"

How I answered: I said this is O(2^n) because at every house I branch into two more calls and pointed out that a lot of that work is wasted the exact same subproblem, like "what's the best result starting from house 5," gets recomputed over and over depending on which path got us there.

Hint that helped me get to the next step: She asked, "What if you just remembered the answer the first time you computed it?" That was really the whole nudge I needed I added a cache array so each subproblem only gets solved once:

// Same recursion, but cache results so each subproblem is solved once.
// O(n) time, O(n) space.
int memo(vector<int>& nums, int i, vector<int>& cache) {
    if (i >= (int)nums.size()) return 0;
    if (cache[i] != -1) return cache[i];
    int skip = memo(nums, i + 1, cache);
    int rob = nums[i] + memo(nums, i + 2, cache);
    return cache[i] = max(skip, rob);
}

Interviewer asked: "Nice. Can you bring the space down further do you really need that whole array?"

How I answered: I looked at what the recursion actually depends on at any point only the answer from one house back and two houses back, never anything older than that. So instead of a full array, I just need two rolling variables:

// O(n) time, O(1) space -- only the last two computed values matter.
int optimal(vector<int>& nums) {
    int prev2 = 0, prev1 = 0;
    for (int n : nums) {
        int cur = max(prev1, prev2 + n);
        prev2 = prev1;
        prev1 = cur;
    }
    return prev1;
}

I tested all three of these the brute force, the memoized version and this final O(1)-space version against each other across 2,000 randomly generated house arrays and they agreed every single time. On the classic example [2, 7, 9, 3, 1], all three correctly land on 12.

Follow-up question: "What if the houses were arranged in a circle instead of a straight line so the first and last house are also next-door neighbors?"

How I answered: I said the circle adds one wrinkle: now I can never rob both the first house and the last house together, since they're neighbors too. So I can just run my exact same linear solution twice once considering houses 0 through n-2 (never touching the last house) and once considering houses 1 through n-1 (never touching the first house) and take whichever total is bigger.

int linearRob(vector<int>& nums, int start, int end) {
    int prev2 = 0, prev1 = 0;
    for (int i = start; i <= end; i++) {
        int cur = max(prev1, prev2 + nums[i]);
        prev2 = prev1;
        prev1 = cur;
    }
    return prev1;
}

int robCircular(vector<int>& nums) {
    int n = nums.size();
    if (n == 0) return 0;
    if (n == 1) return nums[0];
    return max(linearRob(nums, 0, n - 2), linearRob(nums, 1, n - 1));
}

I checked this circular version against a brute-force solution too (trying every valid combination directly) across 3,000 random cases, with zero mismatches. On [2, 3, 2] it correctly returns 3 (you can't take both end houses since they're neighbors in the circle) and on [1, 2, 3, 1] it correctly returns 4.

Problem 2: A Stricter Version of "String to Integer"

She then gave me a string-parsing problem, spelled out with some specific rules: ignore leading and trailing spaces, the whole remaining string has to be digits (with at most one leading minus sign allowed) and if anything about the input doesn't fit that or the number is too big or too small to fit, return INT_MAX. She also added a specific note: don't assume int is always 32 bits, because that's actually compiler and platform dependent.

How I answered the spec-clarifying part: Before writing anything, I asked her directly: "Just to make sure I build the right thing if I see something like 12a3, where digits are followed by a letter, is that entirely invalid or do I take the 12 and ignore the rest?" She confirmed the whole string has to be valid or the whole thing is rejected which is actually stricter than the classic version of this problem you'll find on LeetCode, where you just stop parsing at the first bad character. I was glad I asked instead of assuming.

On her note about int size: I told her that's exactly why I wouldn't hardcode the number 2147483647 as a raw literal in my overflow check instead I'd pull the real bounds from the <climits> header (INT_MAX and INT_MIN) and do all my arithmetic while parsing in a wider type like long long, so the number itself can never quietly wrap around and lie to me before I even get a chance to check it against the limit.

#include <climits>
#include <string>
#include <cctype>

long long customAtoi(std::string s) {
    // trim leading/trailing spaces
    size_t start = s.find_first_not_of(' ');
    if (start == std::string::npos) return INT_MAX; // all spaces -> invalid
    size_t end = s.find_last_not_of(' ');
    std::string trimmed = s.substr(start, end - start + 1);

    if (trimmed.empty()) return INT_MAX;

    int i = 0;
    bool negative = false;
    if (trimmed[i] == '-') {
        negative = true;
        i++;
    }
    if (i >= (int)trimmed.size()) return INT_MAX; // just "-" alone -> invalid

    long long result = 0; // wide accumulator -- can't silently overflow mid-parse
    for (; i < (int)trimmed.size(); i++) {
        if (!isdigit((unsigned char)trimmed[i])) {
            return INT_MAX; // anything but a digit here -> invalid, per spec
        }
        result = result * 10 + (trimmed[i] - '0');
        if (result > (long long)INT_MAX + 10) {
            return INT_MAX; // clearly overflowed already, stop early
        }
    }
    if (negative) result = -result;
    if (result > INT_MAX || result < INT_MIN) {
        return INT_MAX; // real bounds from <climits>, not a hardcoded literal
    }
    return result;
}

Mistake I made and how I caught it: My very first version only checked for a - sign but never checked what happens if the string is just "-" with nothing after it. She ran that exact input against my code mentally and asked, "What does your function do with just a single dash and nothing else?" I realized on the spot that my loop would just do nothing and fall through, returning 0 instead of correctly flagging it as invalid. I fixed it by adding an explicit check right after reading the sign: if there's nothing left in the string after the -, return INT_MAX immediately.

Follow-up question: "Your rule says overflow returns INT_MAX what about a huge negative number, like -99999999999? Does INT_MAX still make sense there?"

How I answered: I said that's a fair catch I'd implement exactly what was specified, since that's what she asked for, but I'd also flag out loud that this feels like an inconsistency worth double-checking with whoever wrote the spec, because returning a huge positive number for something that was clearly meant to be very negative is a landmine for anyone calling this function later and assuming the sign survived. I think pointing that out mattered to her she nodded and said that was a fair observation.

I tested my final version against 13 different edge cases empty input, all spaces, a lone -, trailing garbage after valid digits, a + sign (which isn't allowed per this spec), numbers exactly at and one past both INT_MAX and INT_MIN, double signs like --5 and a string of all zeros and every single one passed.

Then Something Odd Happened

Right after I finished both problems, she asked me to open my Chrome browser and show her my recent search history. I was genuinely caught off guard I'd never had that asked of me in any interview before.

To be fair about it: some companies ask remote candidates to share more of their screen or confirm they haven't looked up the exact problem mid-interview, specifically because a remote round is harder to fully proctor than an in-person one. Asking for a code editor's history for that reason at least makes some sense to me. But asking specifically for browser search history felt like a different, more personal level of scrutiny than that it's not just "did you look up this one problem," it's "show me everything else you've searched for lately," which has nothing to do with the interview itself.

If this happens to you, I'd say it's completely fair to ask exactly what they're trying to confirm and to offer the narrowest thing that actually answers that something like, "Happy to confirm I didn't search this exact problem would showing just this one tab work, rather than my whole history?" You're allowed to ask that.

Round 2: Four Reschedules, Then Two More Problems

Before this round even happened, it got pushed back four separate times once for a genuine health issue on the interviewer's side (which is completely understandable and not a red flag by itself), once after I sat waiting for 30 minutes with nobody joining and no way to reach HR, once because the interviewer was reported "busy," and once more because HR themselves couldn't confirm whether that was even true. By the time the round actually started, I'd mentally already logged this as a strange sign about how coordinated things were behind the scenes.

Problem 3: Count of Smaller Numbers After Self

Interviewer described this one as: given a list of numbers, for every number, tell me how many numbers after it in the list are smaller than it.

I want to be honest about something here. When I originally thought back on how I solved this, I remembered using a stack but going back through it carefully while writing this up, I realized that memory doesn't actually hold up and I want to walk through why, because I think it's a genuinely useful thing to know rather than just repeat something that sounds right.

I actually tested it to check. I wrote the most natural "stack-only" version of this problem I could think of walking from right to left, popping bigger numbers off a shrinking stack and counting the pops and ran it against a slow-but-obviously-correct brute-force checker across 500 random arrays. It gave the wrong answer on 320 of those 500 cases 64% of the time. A plain stack genuinely cannot solve this problem correctly in general. It happens to get lucky on some inputs, which is probably exactly why it felt right in the moment, but it falls apart on most arrays. I'd rather tell you that honestly than pass along a "solution" that doesn't actually hold up.

Brute force, the obviously-correct starting point:

// O(n^2): for every number, scan everything after it.
vector<int> bruteForce(vector<int>& nums) {
    int n = nums.size();
    vector<int> res(n, 0);
    for (int i = 0; i < n; i++) {
        int cnt = 0;
        for (int j = i + 1; j < n; j++) {
            if (nums[j] < nums[i]) cnt++;
        }
        res[i] = cnt;
    }
    return res;
}

The real optimal approach uses merge sort. Here's the idea in plain words: when merge sort combines two already-sorted halves back together, every time it pulls a number in from the right half before a number from the left half, that's proof that number was smaller and came from later in the original array exactly what we're trying to count. So if I just count those moments while the merge is happening, I get the whole answer for free, in O(n log n) instead of O(n²):

// O(n log n): count these moments while merge-sorting.
void mergeSortCount(vector<pair<int,int>>& arr, int lo, int hi, vector<int>& res) {
    if (hi - lo <= 1) return;
    int mid = (lo + hi) / 2;
    mergeSortCount(arr, lo, mid, res);
    mergeSortCount(arr, mid, hi, res);

    vector<pair<int,int>> merged;
    merged.reserve(hi - lo);
    int i = lo, j = mid;
    int rightCount = 0; // how many right-half numbers merged in so far
    while (i < mid && j < hi) {
        if (arr[j].first < arr[i].first) {
            rightCount++;
            merged.push_back(arr[j++]);
        } else {
            res[arr[i].second] += rightCount; // this many smaller numbers were after it
            merged.push_back(arr[i++]);
        }
    }
    while (i < mid) { res[arr[i].second] += rightCount; merged.push_back(arr[i++]); }
    while (j < hi) merged.push_back(arr[j++]);
    for (int k = lo; k < hi; k++) arr[k] = merged[k - lo];
}

vector<int> countSmallerOptimal(vector<int>& nums) {
    int n = nums.size();
    vector<int> res(n, 0);
    vector<pair<int,int>> indexed(n);
    for (int i = 0; i < n; i++) indexed[i] = {nums[i], i};
    mergeSortCount(indexed, 0, n, res);
    return res;
}

I tested this against brute force across 2,000 random arrays, including negative numbers and duplicates and it matched on every single one. On [5, 2, 6, 1], it correctly returns [2, 1, 1, 0] there are 2 smaller numbers after the 5 (the 2 and the 1), 1 smaller number after the 2 (the 1), 1 after the 6 (the 1) and 0 after the last number.

Follow-up question: "Is there another way to solve this, maybe without recursion?"

How I answered: I mentioned a Binary Indexed Tree (also called a Fenwick Tree) as the other standard approach you compress all the values down to ranks, then insert numbers from right to left, asking the tree "how many numbers smaller than this one have I already inserted" before each insert. It gets you the same O(n log n) time without the recursive merge structure. She seemed happy that I knew a second approach even though I coded the merge sort version.

Problem 4: Container With Most Water

Interviewer described this as: imagine a row of vertical lines at different heights and you pick any two of them to form a container the water it holds is limited by whichever of the two lines is shorter, times the distance between them. Find the two lines that hold the most water.

I started with the obvious brute-force approach just check every possible pair:

// O(n^2): try every pair of lines.
int bruteForce(vector<int>& height) {
    int n = height.size(), best = 0;
    for (int i = 0; i < n; i++)
        for (int j = i + 1; j < n; j++)
            best = max(best, min(height[i], height[j]) * (j - i));
    return best;
}

Then I explained the optimal two-pointer idea: start with one pointer at each end, so you're looking at the widest possible container first. At each step, look at whichever line is shorter that shorter line is the actual bottleneck limiting how much water you can hold, no matter how tall the other one is. Moving the taller side inward can only shrink your width while that same bottleneck remains, so it can never help. The only move that could possibly find something better is moving the shorter side inward.

// O(n) time, O(1) space.
int twoPointer(vector<int>& height) {
    int left = 0, right = height.size() - 1, best = 0;
    while (left < right) {
        best = max(best, min(height[left], height[right]) * (right - left));
        if (height[left] < height[right]) left++;
        else right--;
    }
    return best;
}

I checked this against brute force across 3,000 random arrays with zero mismatches and on the well-known example [1,8,6,2,5,4,8,3,7] it correctly returns 49.

Follow-up question: "Can you prove that moving the shorter pointer never causes you to miss the actual best answer?"

How I answered: I walked through it with the logic above since the shorter line is always the bottleneck for the current pair, any container we could form by keeping that same shorter line and moving the other pointer inward is guaranteed to be no better than what we already checked (same or smaller height limit, smaller width). So the only direction that could possibly reveal a better answer is moving past the shorter line. I also picked a concrete example and traced through it by hand to make the point solid, not just theoretical.

Where It Went Wrong

This is the part where the round got tense. After I walked through the two-pointer solution above correct, tested and the standard optimal answer to this exact problem she kept steering back toward wanting it solved with a stack instead.

Here's roughly how that exchange actually went:

Interviewer: "I want you to solve this using a stack approach."

Me: "I can walk through why the two-pointer method is optimal here O(n) time, constant space would it help if I traced through a specific example so you can see why moving the shorter pointer is always the right move?"

Interviewer: "Just show me the stack-based way."

Me: "I'm not immediately seeing a stack-based approach that improves on this for this specific problem could you point me toward what property of the problem you're thinking a stack would take advantage of? I want to make sure I'm not missing something."

Interviewer: "Interviewers know all approaches. Candidates should just listen."

Interviewer ended the call right after that, muted mic and I was left talking into a silent, then blank, screen.

I want to be fair to the other side of this for a second, because it's worth considering: sometimes an interviewer has a specific rubric in mind, maybe evaluating a different variant of the problem where a stack genuinely is the right tool and there's a real mismatch happening about which exact problem is even being discussed. That kind of miscommunication does happen sometimes. But the two-pointer approach to Container With Most Water is the textbook-correct, well-known optimal solution to this exact problem this wasn't a case of "there were multiple valid answers and I only wanted one specific one."

If you ever find yourself in this exact spot confident your answer is correct and the pushback isn't giving you any new information to work with I've found it helps more to ask a direct, genuinely curious question than to re-explain your proof a third time: something like "I want to make sure I understand what you're evaluating here is there a specific variation of this problem you have in mind?" That reframes you as someone seeking clarity, not defending your ego and it sometimes actually surfaces the real disconnect. If that still doesn't move things forward, offering to also walk through the alternate approach they're asking for, without taking back what you already proved, is a reasonable way to keep things moving. And if none of that works that part is genuinely outside your control in the room and it isn't a reflection of your technical ability.

What Happened After

A few days after that round, I got the rejection email. I reached out to HR afterward, just wanting to understand what specifically didn't work out I tried more than once, through more than one HR contact. My calls got cut short. My follow-up emails went unanswered.

I think how a company handles the end of a process, even a rejection, tells you something real. A short, honest note even just "we felt there was a gap in X" costs almost nothing to send and it actually helps the person on the other end grow. Total silence after someone directly and politely asks, more than once, says something too just not something flattering.

What I Actually Learned From This

Reschedules aren't just an inconvenience they're information. One reschedule for a real reason is just life. A string of them, especially ones where even HR loses track of what's happening internally, is a preview of how coordinated the day-to-day actually is on that team.

Being technically correct doesn't guarantee the room reads it that way. This one's uncomfortable to admit, but it's true everywhere, not just here: interview dynamics are human and a correct, clearly explained answer can still land badly with a specific person on a specific day. I can't fully control that variable. I can only control how calmly and clearly I present my own reasoning.

Asking for feedback is worth doing, but it's not owed to you no matter how professionally you ask. I think it's worth asking once clearly and following up once more if you hear nothing and then treating a company's silence as information about them, not as some referendum on whether you did something wrong by asking.

My Preparation Tips, If You're Getting Ready for Something Similar

For the technical side: practice explaining core C++ ideas pointers vs. references, stack vs. heap, what actually causes a stack overflow in your own plain words, not textbook definitions. Interviewers are listening for whether you get it, not whether you memorized a sentence. Practice narrating the brute-force-to-optimal journey out loud for classic patterns: dynamic programming problems like House Robber, two-pointer problems like Container With Most Water and anything that's really "count elements matching some condition after this position," which is usually an inversion-counting problem wearing a disguise. Before you write a single line of code on a string-parsing or edge-case-heavy problem, say the edge cases out loud and ask which ones actually matter to the interviewer it costs you fifteen seconds and saves you from solving the wrong version of the problem, which is exactly what almost tripped me up on the string-parsing question.

For protecting your own time and energy through a messy process: keep a simple written log of every time you were scheduled and every time it got moved, with dates attached it costs nothing to keep and it matters if you ever need to point back at it. Decide ahead of time roughly how many reschedules you're personally willing to absorb for one role before it stops being worth your calendar space. Always ask for feedback once, in writing, after a rejection and if one polite follow-up gets you nothing back, let it go and put that energy toward the next opportunity instead of chasing a company that's already gone quiet.

Frequently Asked Questions