Technical Interview Preparation: Cracking the Interview

Flipkart's campus SDE-1 pipeline runs a DSA round before anything else. Forty-five minutes, one interviewer, a shared code editor. The prompt: "You have a Big Billion Days gift card worth ₹900. Here are the listed prices of items in your cart: 200, 700, 1100, 1500. Find two items whose prices add up to exactly the gift card balance, and return their positions in the list." A strong CBSE Computer Science student knows every data structure this problem could possibly need — arrays, hash maps, sorting. That knowledge is not what fails most candidates in the room. What fails them is silence: staring at the array, coding a nested loop from memory without saying a word, getting a bug, deleting everything, starting over with four minutes left. The interviewer did not ask for silence. They asked for a trace of how you think, and most of the marks are awarded before a single line of code is typed.

What the interviewer is actually measuring

A CBSE unit test rewards one thing: the final answer, checked against a key. A technical interview round is scored on a different axis entirely, because the interviewer is not a marking key — they are a person trying to predict, from forty-five minutes of evidence, whether you will be safe to put in front of a production codebase. Four things get evaluated in that window, roughly in this order of weight: whether you can turn a vague prompt into a precise one by asking the right clarifying questions; whether you can reason about the time and space cost of an approach before writing it, not after; whether the code you produce actually does what you claim, verified by tracing it rather than assuming it; and whether a second engineer could follow your reasoning without you being in the room. Correctness of the final function matters, but a candidate who reaches a working O(n) solution while narrating every decision scores higher than one who reaches the same O(n) solution in silence, because the first candidate has demonstrated the actual skill the job requires — the second has only demonstrated that they memorised the pattern.

This is worth internalising precisely because it inverts a habit built by years of exams: in an exam, showing your rough work costs you nothing extra and the answer is what counts. In an interview, the rough work spoken aloud is the primary signal, and a correct answer produced with no visible reasoning is treated with more suspicion than a nearly-correct answer produced with a clear, self-correcting process.

The problem-solving loop

Every DSA interview question, regardless of company or topic, rewards the same fixed sequence of moves. Skipping steps is the single most common way strong students lose marks, because skipping the "state the brute force" step in particular removes the interviewer's ability to see you reason about complexity at all — they only see the finished trick. The loop below is what a well-prepared candidate runs, consciously, on every problem: restate and clarify, work a small example by hand, state a brute-force solution and its cost, identify exactly what that brute force wastes, match that waste to a known pattern, code the match while talking, trace the code against the example and an edge case, and only then state the final complexity out loud.

The pivot point in this loop is the diamond: "what redundant work does the brute force do?" This single question is what CBSE students consistently skip, because it requires naming the waste before naming the fix. In the gift-card problem, the brute-force answer checks every pair of prices with two nested loops — for each item, it re-scans the entire list looking for a partner. The redundant work is exactly that re-scanning: by the time you reach item j, you have already seen every price before it, and you are throwing that memory away and re-deriving it. Naming the waste out loud — "I'm re-scanning prices I've already seen" — is what leads an interviewer to hear you arrive at "so I should remember what I've seen," which is precisely the hash-map pattern, arrived at by reasoning rather than recall.

Worked example: the gift-card pair, from O(n²) to O(n)

Take the exact problem from the opening: prices [200, 700, 1100, 1500], gift card balance ₹900. The brute-force approach checks every pair:

def two_sum_bruteforce(prices, target):
    n = len(prices)
    for i in range(n):
        for j in range(i + 1, n):
            if prices[i] + prices[j] == target:
                return [i, j]
    return []

Trace it: i=0, j=1 gives prices[0] + prices[1] = 200 + 700 = 900, which equals the target on the very first pair checked, so it returns [0, 1]. That is correct, but the correctness of this one lucky example hides the real cost: for a cart of n items, the outer loop runs n times and the inner loop runs up to n times for each outer iteration, giving O(n²) time. Space is O(1) beyond the input, since nothing extra is stored. On a cart of 20 items that is at most 190 comparisons — fine. On a catalogue-scale list of 50,000 SKUs, that is up to 1.25 billion comparisons, and this is exactly the number an interviewer expects you to say before they ask "can you do better?"

The redundant work, named per the loop above, is the re-scanning: for every item, the inner loop re-examines items you have already looked at while checking earlier outer-loop items. A hash map remembers, in O(1) expected time per lookup, every price seen so far, keyed by its index:

def two_sum(prices, target):
    seen = {}
    for i, price in enumerate(prices):
        complement = target - price
        if complement in seen:
            return [seen[complement], i]
        seen[price] = i
    return []

Trace it on the same input, prices=[200, 700, 1100, 1500], target=900:

• i=0: price=200, complement=700. seen is empty, so 700 is not found. Insert: seen={200: 0}.
• i=1: price=700, complement=200. 200 is in seen, mapped to index 0. Return [0, 1].

Same answer, [0, 1], but now in a single pass: O(n) time, and O(n) space for the dictionary in the worst case where no pair is found until the last element. This is the trade you must state explicitly in the interview — you have bought speed by spending memory, and saying that sentence out loud is worth marks by itself.

Now check the line order inside the loop, because it is the part every student gets wrong on the first attempt: the complement is checked before the current price is inserted into seen. Try prices [300, 300], target 600 — two items priced identically, a real and common case in any catalogue. At i=0, price=300, complement=300; seen is still empty at this point, so the check correctly fails, and only then is 300 inserted with index 0. At i=1, price=300, complement=300; now seen contains {300: 0}, so the check succeeds and returns [0, 1] — two genuinely different items. If the insertion happened first, on the very first iteration the item would insert itself into seen and then immediately "find" itself as its own complement, returning [0, 0] — the same cart item paired with itself, which is not a valid answer to "find two items." Checking before inserting is what prevents an item from partnering with itself.

If the prices are already sorted — realistic, since most catalogue views are — a two-pointer sweep beats even the hash map on space, trading the dictionary for two index variables:

def two_sum_sorted(prices, target):
    left, right = 0, len(prices) - 1
    while left < right:
        s = prices[left] + prices[right]
        if s == target:
            return [left, right]
        elif s < target:
            left += 1
        else:
            right -= 1
    return []

Trace it on sorted prices [100, 300, 400, 600, 800], target 1000: start left=0 (100), right=4 (800), sum 900 < 1000, so move left up (the sum is too small, and moving right down could only make it smaller). Now left=1 (300), right=4 (800), sum 1100 > 1000, so move right down. Now left=1 (300), right=3 (600), sum 900 < 1000, so move left up again. Now left=2 (400), right=3 (600), sum 1000 == 1000: return [2, 3]. This is O(n) time and only O(1) extra space, because two integers replace an entire dictionary — the correct answer to "can you reduce the space?" once the interviewer learns the input is sorted.

A misconception that costs candidates the offer

The most common belief a well-prepared CBSE student walks in with is that the interview is graded like an exam: the brute force is a wrong answer, so mentioning it wastes time and signals weakness, and the goal is to jump straight to the optimal solution in silence to look sharp. This is backwards. Interviewers explicitly want to hear the brute force stated first, with its complexity, because that sentence is the only direct evidence they get that you can measure cost before you have measured it by running code. A candidate who says "brute force is O(n²) because of the nested scan, but I can trade space for time with a hash map to get O(n)" has demonstrated the actual reasoning skill the round exists to test. A candidate who silently writes the optimal hash-map solution from memory, with no brute force mentioned and no complexity spoken, has demonstrated only that they solved this exact problem before — which tells the interviewer nothing about how they will behave on a problem they have not seen, which is the entire point of asking a live question instead of a memorised one.

Beyond the whiteboard: LLD, HLD, and behavioural rounds

Most Indian product-based companies run technical hiring as a sequence, not a single test. An online assessment on a platform like HackerRank filters the funnel first, typically two problems in sixty to ninety minutes, no interviewer present, so all four signals above have to come through in comments and variable names alone. Candidates who clear the OA face two or three live DSA rounds of the kind described here. For roles above entry level, a low-level design (LLD) round follows, where the prompt is not "find two numbers" but "design the classes for a parking lot" or "design a Splitwise-style expense splitter" — the pattern-matching loop still applies, but the pattern library shifts to object-oriented design: identifying entities, relationships, and the operations each class must expose, then defending trade-offs the same way you defended O(n) over O(n²). Senior and staff-track candidates additionally face a high-level design (HLD) round — "design IRCTC's seat-booking system for a Tatkal window" or "design Swiggy's live order-tracking" — where the redundant-work question becomes a question about which component absorbs a spike in read or write traffic. The pipeline closes with a hiring-manager or bar-raiser round focused on behavioural evidence, and an HR round on logistics and compensation.

The behavioural round rewards the same discipline as the DSA round: structure before content. The STAR method gives that structure — Situation (the specific context, one or two sentences), Task (what you were specifically responsible for), Action (what you personally did, step by step), Result (the measurable outcome, including what you would change). A candidate answering "tell me about a time you disagreed with a teammate" without this structure tends to ramble through the situation and never reach a result; STAR forces the result to be spoken, which is the part interviewers actually score, since it demonstrates whether you learned anything from the disagreement rather than just survived it.

Active recall

Attempt each of the following before reading the worked answers below.

1. Trace two_sum on prices=[300, 200, 400, 300], target=600. Which indices are returned, and why does index 3 (also priced 300) never get examined?
2. State the time and space complexity of two_sum_bruteforce and two_sum side by side. Which one would you choose for a catalogue of 50,000 items with plentiful RAM, and which for an embedded device with 4 KB of memory?
3. Trace two_sum_sorted on prices=[100, 300, 400, 600, 800], target=1400. Which indices are returned, and how many pointer moves does it take?
4. An interviewer changes the question to: "find the length of the longest run of the cart where no item price repeats." Which box in the diagram does this match, and why does it not match the hash-map box even though it also uses a dictionary internally?
5. Using STAR, list the four labels you would fill in — not the full answer — for "tell me about a time you missed a deadline."
6. In the original two_sum example, the interviewer changes the gift card balance from ₹900 to ₹10,000 on the same prices=[200, 700, 1100, 1500]. Trace the function to its end. What does it return, and what must you now ask the interviewer before writing this function in the first place?

Worked answers

1. i=0: price=300, complement=300, seen empty, no match; insert seen={300: 0}. i=1: price=200, complement=400, not in seen; insert seen={300: 0, 200: 1}. i=2: price=400, complement=200; 200 is in seen at index 1. Return [1, 2]. The loop returns as soon as the first valid pair is found, and 200 + 400 = 600 is found at i=2, so the function exits before i=3 is ever reached — index 3 is never examined not because it is wrong, but because a match was already found earlier.

2. two_sum_bruteforce: O(n²) time, O(1) extra space. two_sum: O(n) time, O(n) extra space. For 50,000 items with plentiful RAM, the hash map is the clear choice — O(n²) at that scale is over a billion operations, while the dictionary costs at most 50,000 entries, cheap in absolute terms. For a 4 KB embedded device, neither may fit as written, but if the array can be sorted in place first, two_sum_sorted is the right choice: O(1) extra space regardless of n, at the cost of an upfront O(n log n) sort.

3. left=0 (100), right=4 (800): sum 900 < 1400, move left. left=1 (300), right=4 (800): sum 1100 < 1400, move left. left=2 (400), right=4 (800): sum 1200 < 1400, move left. left=3 (600), right=4 (800): sum 1400 == 1400. Return [3, 4]. That took three pointer moves before the match on the fourth check.

4. This matches the Sliding Window box, not Hash Map, because the question is about a contiguous run within the cart, not an arbitrary pair anywhere in it. A sliding window keeps a growing-then-shrinking contiguous range and uses a dictionary only to test membership within the current window — the dictionary is an implementation detail of the window, not the defining pattern. Hash Map as a top-level pattern applies when the two elements you need can be anywhere in the array, with no requirement that they be next to each other.

5. Situation: the specific project and deadline. Task: what you were responsible for delivering. Action: the concrete steps you took once it became clear the deadline was at risk. Result: what actually happened, stated with a number or outcome, plus what you changed afterward to avoid repeating it.

6. i=0: price=200, complement=9800, not found; insert. i=1: price=700, complement=9300, not found; insert. i=2: price=1100, complement=8900, not found; insert. i=3: price=1500, complement=8500, not found; insert. Loop ends with no match; the function returns []. This is the ripple a small parameter change forces you to confront: unlike the ₹900 case, there is no guaranteed pair here, so before writing the function at all you must ask the interviewer whether a valid pair is guaranteed to exist, and if not, what the function should return or raise when none is found — an empty list, None, or an explicit exception. Assuming a guaranteed answer, common on practice platforms, is unsafe in a real interview unless the interviewer confirms it.

Think About It

Think about this: How would you explain technical interview preparation: cracking the interview to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind technical interview preparation: cracking the interview, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.