The Interview Problem-Solving Workflow

Two candidates are given the same problem. Both finish a correct solution. One of them gets a warm "that was a good conversation", and the other gets a cool "thank you for your time". Why?

The first one asked what the input could look like, tried a simple approach first, noticed it was slow, explained a better idea before writing it, tested the code on tricky cases, and said clearly how fast it was. The second typed silently for twenty minutes and handed over code that happened to work.

Both produced working code. The first showed the interviewer what it would be like to work with them. That is a large part of what a coding interview is for. This article gives you a repeatable routine for being the first candidate.

• What interviewers are usually trying to learn from a coding problem.
• A step-by-step workflow, with a suggested time split.
• How to find the optimisation after you state a brute force.
• A full sample dialogue, with code you can run.
• What to do when you are stuck, and how to take a hint.
• Testing and complexity-statement habits, plus checklists for practice.

Different companies score differently, but most coding interviews look at some mix of these:

Notice that "gets the optimal answer instantly" is not on the list. A candidate who reaches a good solution through clear reasoning, with one hint, often does better than one who recites a memorised solution without being able to explain it. Interviewers often ask a follow-up ("what if the input is a stream?") precisely to see whether you understand your own answer.

Here is the sequence. The time split is a rough guide for a 45-minute slot, which is a common length but certainly not universal. Adapt it to what you are told.

Let us go through each step.

Resist the urge to start solving after the first sentence. Read to the end. Then restate the problem in your own words: "So we have two sorted arrays, and we want to merge them into the first one, which has spare room at the end. Is that right?" This catches misunderstandings early and gives you a moment to think.

Questions you should almost always consider:

• Input. What type is it? Can it be empty? Can it contain duplicates, negatives, null? Is it sorted? How large can it get?
• Output. What exactly should I return? An index, a value, a list? What if there is no answer? What if there are several?
• Constraints. What are the limits on size and on values? This tells you which complexity is acceptable, and whether int could overflow.
• Rules. May I modify the input? Is extra memory allowed?

These are not stalling tactics. They are what a good engineer does before building anything. Write the answers down where you can see them.

Make a small normal example. Then add awkward ones: empty, a single element, all equal, a case where the answer is at the end. Work out the expected answer by hand. Later, these become your tests.

Say the simplest correct solution out loud, and its complexity, even if you can already see something better. For example: "The brute force is two nested loops over all pairs, which is O(n^2)." Three benefits: it shows you understand the problem, it gives you a fallback if you get stuck, and the way it wastes work points to the optimisation.

Look at what the brute force repeats or wastes. Then use the toolbox from this course. These questions help:

When you have an idea, explain it before you code it, in a sentence or two, with a quick example. Then check: "Does that approach sound reasonable to you?" Agreeing on a plan is the single best way to avoid spending twenty minutes coding the wrong thing.

• Write clean, readable code: meaningful names, small helper methods for distinct jobs, consistent formatting.
• Narrate why, not just what. "I move the pointer on the smaller side, because that is the only side that can improve the answer" is much better than "now I increment left".
• Do not try to be clever. A plain loop that is obviously correct beats a clever line that needs explaining.
• Handle the edge cases you identified. If you plan to handle one later, say so ("I will add the empty check after the main loop").
• If you realise you made a mistake, say so and fix it. Everyone does this.

Do not hand over code and say "done". Trace it yourself. Take your normal example and walk through the code line by line, tracking variable values, as you did in the dry runs of this course. Then try each edge case. Many bugs, such as off-by-one errors, are found in the first two minutes of tracing. Finding your own bug is a good signal to an interviewer. Having them find it for you is not.

State the time and space complexity clearly (see below), and compare with your brute force. Be ready for follow-ups: "What if the input does not fit in memory?", "What if it is a stream?", "Can you do it with less space?". If you do not know, say how you would think about it.

Here is a complete example, written as a conversation. The problem is a nice one for showing in-place thinking:

Problem. You are given two sorted integer arrays nums1 and nums2. nums1 has length m + n: its first m positions hold real values in sorted order, and the last n positions are empty padding (zeros). nums2 has n values. Merge nums2 into nums1 so that nums1 becomes one sorted array.

Interviewer: Take your time. Walk me through how you would approach this.

Candidate: Let me restate it first. nums1 has m real elements followed by room for n more, and nums2 has n elements. Both are sorted, and I need the merged, sorted result stored in nums1 itself. Can I assume ascending order?

Interviewer: Yes, ascending.

Candidate: And the padding at the end of nums1, can I overwrite it freely?

Interviewer: Yes. It is just there to give you room.

Candidate: Can m or n be zero?

Interviewer: Yes, either could be.

Candidate: Thanks. Let me make an example. nums1 = [1, 2, 3, 0, 0, 0] with m = 3, and nums2 = [2, 5, 6] with n = 3. The merged result should be [1, 2, 2, 3, 5, 6]. A tricky one is nums1 = [0] with m = 0, nums2 = [1]: the result is [1], and nums1 has no real elements at all.

Candidate: For a brute force, I could copy nums2 into the padding of nums1 and then sort the whole array. That is O((m + n) log (m + n)) time and no extra array. It works, but it ignores that both inputs are already sorted.

Interviewer: Good. Can you do better?

Candidate: The usual merge of two sorted arrays is O(m + n), walking through both from the front and writing the smaller each time. But if I write into nums1 from the front, I will overwrite its real elements before I have read them. I could copy nums1 first, which costs O(m) extra space. Hmm. Is there a way to avoid that?

Candidate: What if I merge from the back? The padding is at the end of nums1, so the largest element of the merged result belongs at the last position, which is empty. I can compare the last real element of nums1 with the last element of nums2, put the larger at the end, and move the corresponding pointer left. Writing from the back never overwrites a value I still need, because the write position is always at or ahead of the read position in nums1.

Interviewer: Convince me of that last claim.

Candidate: Think of the free slots between the unread part of nums1 and the write position. At the start, that is exactly n slots, the padding. Every time I place an element from nums2, one free slot is used up and one element of nums2 is consumed. Every time I place an element from nums1, the read pointer and the write pointer both move left by one, so the number of free slots does not change. So the number of free slots always equals the number of unread elements of nums2. While nums2 still has elements, there is at least one free slot, so the position I write to is never an unread element of nums1.

Interviewer: Good. Go ahead and code it.

Candidate: I will use three pointers: i for the last real element of nums1, j for the last element of nums2, and write for the position to fill. I loop while j >= 0. Once nums2 is exhausted, the remaining elements of nums1 are already in place, so I can stop. But if nums1's real elements run out first, I need to copy the rest of nums2, and the loop condition on j handles that.

(The candidate writes the code below.)

// File: Main.javaimport java.util.Arrays;public class Main {    // Merges nums2 into nums1 in place. nums1 has m real values followed by n spare slots.    static void merge(int[] nums1, int m, int[] nums2, int n) {        int i = m - 1;                 // last real element of nums1        int j = n - 1;                 // last element of nums2        int write = m + n - 1;         // where the next largest value goes        while (j >= 0) {               // once nums2 is used up, nums1's remaining prefix is already in place            if (i >= 0 && nums1[i] > nums2[j]) {                nums1[write] = nums1[i];                i--;            } else {                nums1[write] = nums2[j];                j--;            }            write--;        }    }    public static void main(String[] args) {        int[] a = {1, 2, 3, 0, 0, 0};        merge(a, 3, new int[] {2, 5, 6}, 3);        System.out.println(Arrays.toString(a));        int[] b = {0};        merge(b, 0, new int[] {1}, 1);        System.out.println(Arrays.toString(b));        int[] c = {4, 5, 6, 0, 0, 0};        merge(c, 3, new int[] {1, 2, 3}, 3);        System.out.println(Arrays.toString(c));        int[] d = {1, 2, 3};        merge(d, 3, new int[] {}, 0);        System.out.println(Arrays.toString(d));        int[] e = {2, 0};        merge(e, 1, new int[] {1}, 1);        System.out.println(Arrays.toString(e));    }}

[1, 2, 2, 3, 5, 6][1][1, 2, 3, 4, 5, 6][1, 2, 3][1, 2]

Candidate: Let me test. For my first example, i = 2, j = 2, write = 5. Compare 3 and 6: 6 is larger, so nums1[5] = 6, j = 1. Next, 3 against 5: nums1[4] = 5, j = 0. Next, 3 against 2: 3 is larger, so nums1[3] = 3, i = 1. Next, 2 against 2: they are equal, and my condition is strict, so I take from nums2: nums1[2] = 2, j = -1. The loop ends. nums1 is [1, 2, 2, 3, 5, 6]. Correct. For the case m = 0, i = -1, so the i >= 0 check fails and every element comes from nums2. Good. If n = 0, the loop does not run, and nums1 is untouched, which is correct.

Candidate: Each loop iteration places one element and moves one pointer left, and the loop runs at most m + n times, so the time is O(m + n). The extra space is O(1), just three integers. The brute force was O((m + n) log (m + n)).

Interviewer: What if the arrays were not sorted?

Candidate: Then merging would not apply. I would need to sort first, which is the brute force I mentioned.

Take a moment to see what the candidate did. They asked before coding. They gave a brute force with its complexity. They found the optimisation by looking at a specific obstacle (overwriting). They gave a short justification for why the idea is safe. They traced the code on the example and on two edge cases. They stated the complexity at the end and compared it to the brute force. None of that required genius, only a routine.

Here is the trace of the first example, in a table:

After that, j = -1, the loop stops, and the leading 1, 2 of nums1 are already in the right place.

Everyone gets stuck sometimes. What matters is how you behave. Try these in roughly this order:

1. Say what you know. "I understand the brute force. The part I am stuck on is how to avoid re-checking pairs." Naming the obstacle often reveals it.
2. Shrink the problem. Try an input of size 2 or 3 by hand. Notice what you do. That pattern may be the algorithm.
3. Draw it. Boxes and arrows for lists and trees, a grid for DP, a graph for dependencies.
4. Ask the toolbox questions from step 5: would a hash map, sorting, a heap, a stack, or two pointers help here?
5. Relax a constraint. Solve an easier version (sorted input, small values, no duplicates), then work back.
6. Look at the constraints. n up to 20 suggests exponential. n up to 10^5 suggests near-linear.
7. Ask for a hint, politely. "I am considering X or Y but I am not sure which direction to take. Could you give me a nudge?" Interviewers expect this, and how you use the hint is part of what they see.

Give both time and space, with what the variables mean: "O(m + n) time, where m and n are the sizes of the two arrays, and O(1) extra space." Also:

• Include the recursion stack in space if you use recursion ("O(h) for the call stack, where h is the height").
• Mention the hidden costs of library calls: sorting is O(n log n), String += in a loop is quadratic, list.remove(0) is O(n).
• Say whether you mean worst case, average or amortised when they differ ("average O(1) for a hash map").
• Compare with the brute force: it shows you know why the improvement matters.
• Do not claim a complexity you cannot justify. "I think it is O(n) because each pointer moves at most n times" is stronger than a confident but unexplained answer.

When you trace, follow the code as written, not as you meant it. The bug is usually in the gap between the two.

Use these during mock interviews and when solving problems alone. Copy them into your notes.

Before I code:

• I restated the problem in my own words.
• I asked about input size, edge cases and whether I may modify the input.
• I worked at least one normal and one tricky example by hand.
• I said the brute force and its complexity out loud.
• I explained my plan and checked that it sounded reasonable.

While I code:

• My names are meaningful, and my code is split into small, clear pieces.
• I narrate why, not only what.
• I handle the edge cases I listed.

Before I say "done":

• I traced the code on my normal example.
• I tried the empty, single-element and extreme cases.
• I looked for int overflow, off-by-one errors and null dangers.
• I stated time and space complexity, and compared with the brute force.
• I am ready for a follow-up ("what if it were a stream?").

• Know your core library by heart: Arrays.sort, Arrays.fill, Arrays.copyOf, Collections.sort, Map.getOrDefault, Map.merge, Deque (push, pop, offer, poll), PriorityQueue with a comparator, and StringBuilder.
• Use Integer.compare(a, b) in comparators, never a subtraction.
• Use long when sums or products can be large.
• Do not modify the input unless the problem allows it. Copy first if you must.
• Prefer the simplest syntax. Fancy features that you cannot explain quickly are a risk.
• Ask whether you may use library utilities such as Arrays.sort or Collections.reverse, or whether you should implement them. Usually the answer is yes, as long as you state their complexity.

static void mergeBuggy(int[] nums1, int m, int[] nums2, int n) {    int i = m - 1;    int j = n - 1;    int write = m + n - 1;    while (i >= 0) {        if (nums1[i] > nums2[j]) {            nums1[write] = nums1[i];            i--;        } else {            nums1[write] = nums2[j];            j--;        }        write--;    }}

static List<Integer> uniqueValues(int[] numbers) {    List<Integer> result = new ArrayList<>();    for (int x : numbers) {        if (!result.contains(x)) {            result.add(x);        }    }    return result;}

// File: Main.javaimport java.util.Arrays;public class Main {    public static void main(String[] args) {        int[] nums1 = {4, 5, 6, 0, 0, 0};        int[] nums2 = {1, 2, 3};        int i = 2;        int j = 2;        int write = 5;        int steps = 0;        while (j >= 0) {            if (i >= 0 && nums1[i] > nums2[j]) {                nums1[write--] = nums1[i--];            } else {                nums1[write--] = nums2[j--];            }            steps++;            System.out.println("step " + steps + ": " + Arrays.toString(nums1));        }    }}

step 1: [4, 5, 6, 0, 0, 6]step 2: [4, 5, 6, 0, 5, 6]step 3: [4, 5, 6, 4, 5, 6]step 4: [4, 5, 3, 4, 5, 6]step 5: [4, 2, 3, 4, 5, 6]step 6: [1, 2, 3, 4, 5, 6]

// File: Main.javapublic class Main {    static int minAddToMakeValid(String s) {        int open = 0;        // unmatched '(' so far        int added = 0;       // '(' we must insert for unmatched ')'        for (char c : s.toCharArray()) {            if (c == '(') {                open++;            } else if (open > 0) {                open--;      // this ')' matches an earlier '('            } else {                added++;     // nothing to match: we need an extra '('            }        }        return added + open;    }    public static void main(String[] args) {        String[] tests = {"())", "(((", "()", ")(", "", "()))((", "(()"};        for (String test : tests) {            System.out.println("[" + test + "] -> " + minAddToMakeValid(test));        }    }}

[())] -> 1[(((] -> 3[()] -> 0[)(] -> 2[] -> 0[()))((] -> 4[(()] -> 1

// File: Main.javaimport java.util.Arrays;public class Main {    static void mergeBuggy(int[] nums1, int m, int[] nums2, int n) {        int i = m - 1;        int j = n - 1;        int write = m + n - 1;        while (i >= 0) {            if (nums1[i] > nums2[j]) {                nums1[write] = nums1[i];                i--;            } else {                nums1[write] = nums2[j];                j--;            }            write--;        }    }    static void mergeFixed(int[] nums1, int m, int[] nums2, int n) {        int i = m - 1;        int j = n - 1;        int write = m + n - 1;        while (j >= 0) {            if (i >= 0 && nums1[i] > nums2[j]) {                nums1[write--] = nums1[i--];            } else {                nums1[write--] = nums2[j--];            }        }    }    public static void main(String[] args) {        int[] a = {4, 5, 6, 0, 0, 0};        mergeBuggy(a, 3, new int[] {1, 2, 3}, 3);        System.out.println("buggy:  " + Arrays.toString(a));        int[] b = {4, 5, 6, 0, 0, 0};        mergeFixed(b, 3, new int[] {1, 2, 3}, 3);        System.out.println("fixed:  " + Arrays.toString(b));        int[] c = {1, 2, 3, 0, 0, 0};        try {            mergeBuggy(c, 3, new int[] {2, 5, 6}, 3);            System.out.println("buggy on the first example: " + Arrays.toString(c));        } catch (ArrayIndexOutOfBoundsException e) {            System.out.println("buggy on the first example: crashes with an index error");        }    }}

buggy:  [4, 5, 6, 4, 5, 6]fixed:  [1, 2, 3, 4, 5, 6]buggy on the first example: crashes with an index error

// File: Main.javaimport java.util.ArrayList;import java.util.HashSet;import java.util.List;import java.util.Set;public class Main {    static List<Integer> uniqueValuesSlow(int[] numbers) {        List<Integer> result = new ArrayList<>();        for (int x : numbers) {            if (!result.contains(x)) {          // contains scans the list: O(size)                result.add(x);            }        }        return result;    }    static List<Integer> uniqueValuesFast(int[] numbers) {        Set<Integer> seen = new HashSet<>();        List<Integer> result = new ArrayList<>();        for (int x : numbers) {            if (seen.add(x)) {                  // add returns true only for a new value                result.add(x);            }        }        return result;    }    public static void main(String[] args) {        int[] numbers = {4, 8, 4, 15, 8, 16, 23, 42, 15};        System.out.println(uniqueValuesSlow(numbers) + " " + uniqueValuesFast(numbers));        System.out.println(uniqueValuesSlow(new int[] {}) + " " + uniqueValuesFast(new int[] {}));    }}

[4, 8, 15, 16, 23, 42] [4, 8, 15, 16, 23, 42][] []

• Next: Build a DSA Practice Project lets you use several data structures together in one small program, which is also good material for project discussions.
• Related: Your 12-Week DSA Study and Revision Plan schedules mock interviews, and Indian Fresher Placement and Coding Interview Preparation covers the rest of the interview process. For a broader plan that includes non-DSA preparation, read Software Interview Preparation: A 6-Week Plan That Actually Works, and for the behavioural side, Common HR Interview Questions and How to Answer Them (With Examples).
• Practice habit: do at least one practice problem a week out loud, with a timer, even if you are alone. Explaining to an empty room feels odd and works surprisingly well.