← Back to C# interview home

The Interview Script

The same seven phases, every time, in the same order. A script frees your attention for the actual problem, and it keeps you moving when the problem is hard.

Two candidates can write the same final code and get opposite verdicts. The difference is almost always the first ten minutes and the last five. This page is what to do in those minutes, with the C# details that come up along the way.

The time budget

For a 45-minute slot with one problem. Shrink the middle if there are two.

• 1. Clarify, 3 minutes. You can restate the problem in one sentence.
• 2. Example by hand, 2 minutes. One worked case on the board, plus one edge case.
• 3. Brute force, 2 minutes. Named and costed. Not coded.
• 4. Optimise, 6 minutes. A pattern named, an approach agreed.
• 5. Code, 18 minutes. Working code, narrated as you go.
• 6. Test, 6 minutes. A dry run and the edge cases.
• 7. Complexity and follow-ups, 3 minutes. Time, space, and one improvement you would make.

1. Clarify

Ask until you could write the method signature with no guesswork. Seven questions cover most problems in C#.

• “How large can the input get?” It picks the target complexity. See Guide 2.
• “Can the values be negative? Zero?” Kills or enables the sliding window outright.
• “Can the input be empty, or null?” Decides your guard clauses. In C#, null and empty are two different cases.
• “Are duplicates possible?” Changes the dedup logic in 3Sum, backtracking, and rotated binary search.
• “Am I allowed to modify the input?” Decides whether Array.Sort(nums) is fine, and chooses between cyclic sort and Floyd.
• “If several answers are valid, does it matter which?” Decides whether you need a tie-break, as in topological sort.
• “Can the result pass the int range?” Decides between int and long for the return type and the running totals.

2. Work an example by hand

Take the given example and compute the answer yourself, on the board, slowly. It forces you to understand the rule. It also often shows you the pattern before you go looking for it.

• Use their example first, so you and they are looking at the same thing.
• Then invent one awkward case: empty, single element, all duplicates, or all negative. Ask what the expected output is.
• Write both down and leave them on the board. You will reuse them in phase 6.

3. State the brute force

Say it. Cost it. Do not write it.

This costs thirty seconds and does three things. It proves you understand the problem. It gives you a correctness baseline for later. And it makes the optimisation a deliberate step rather than a lucky guess. Some interviewers will let you keep it as a fallback if time runs out, which is far better than nothing.

4. Optimise, out loud

This is the phase graded hardest. Make your reasoning audible. Five moves, in order:

1. Name the waste. “The brute force recomputes the same range sums over and over.”
2. Name the pattern. “Contiguous plus an exact target plus negatives, so a window will not work. This is prefix sums with a dictionary.”
3. Justify it. “A range sum is a difference of two prefixes, so I can look up the partner instead of scanning for it.”
4. Cost it before coding. “That is one pass, O(n) time and O(n) space. That fits the constraint.”
5. Get agreement. “Shall I code that?”

5. Code

Write it the way you would want to read it in a review.

Do

• Start with the signature and types. public static int CountSubarrays(int[] nums, int k) confirms the contract one last time.
• Guard clauses first. Null or empty input, a single element. It gets the edges out of the way.
• Name variables for what they mean. windowSum, not s. firstIndex, not d.
• Write the invariant as a comment. One line. It is how you and the reviewer both stay convinced.
• Narrate the non-obvious lines only. “I look up before recording, so a prefix cannot pair with itself.”
• Use a local function when a block gets long. Small named pieces read better under time pressure, not worse.

Do not

• Narrate every line. “Now I set i to zero” is noise. Explain decisions, not syntax.
• Go silent for three minutes. The interviewer cannot score thinking they cannot hear.
• Golf it into one LINQ chain. A dense chain is harder to debug, harder to grade, and hides its cost.
• Fight the compiler on nullable warnings. In an interview, say “I would handle null here” and move on.
• Silently change approach midway. Say “I have realised this misses X, so I am switching to Y”.

6. Test

Do not say “I think that works”. Prove it, out loud, on the example still on the board. The method is in Guide 4. The short version:

1. Dry-run the main example, tracking every variable in a small table.
2. Run the edge case you invented in phase 2.
3. Check the boundaries: first pass, last pass, and the exit condition.
4. If you find a bug, say what it is before you fix it. Diagnosing out loud scores. Silently editing does not.

7. Complexity and follow-ups

State time and space using the four-part form in Guide 2. Then offer one thing you would do next. Good closers:

• “I could drop the space to O(1) with two pointers instead of the two arrays.”
• “If this ran repeatedly over the same data, I would build the prefix array once.”
• “The sort dominates. If the values were bounded I could bucket them and get linear time.”
• “In production I would count with CollectionsMarshal.GetValueRefOrAddDefault, which hashes once instead of twice.”
• “The recursion is as deep as the input. For large inputs I would switch to an explicit Stack<T>.”

One is plenty. Offering an improvement you had no time to build still shows you saw it.

When you are stuck

Being stuck is normal and is not a failure. Being stuck and silent is. Work down this list, out loud.

• Shrink it. Solve n = 1, then n = 2, then n = 3 by hand. The recurrence often appears.
• Re-read the constraints. “n is at most 20” is an instruction. See the hint list.
• Walk the pattern triggers. Sorted? Contiguous? All paths? Fewest steps? Run down the 23 triggers.
• Change the data structure. What if this were sorted? In a Dictionary? In a PriorityQueue? In a SortedSet? On a Stack?
• Invert the question. “Fewest to remove” is “most to keep”. “Rooms needed” is “peak overlap”.
• Solve a relaxed version. Drop a constraint, solve that, then add the constraint back.
• Say where you are. “I have the O(n²) version. I am looking for a way to avoid rescanning the left side. Can I think for a minute?”

When the interviewer hints

A hint is not a penalty. Interviewers hint because they want you to finish. How you take it is what gets scored.

• “What if the array were sorted?”
  • They mean: sort it.
  • Take it at once. “Good idea, then two pointers work because…”
• “Do you need to recompute that?”
  • They mean: you have a redundant scan.
  • Find the repeated work. It is usually a cache or a running total.
• “Walk me through your example again.”
  • They mean: there is a bug and they want you to find it.
  • Dry-run slowly. Do not defend the code.
• “Is that the best you can do?”
  • They mean: no.
  • Say your current complexity, then name the next target.
• “What happens if the input is empty?”
  • They mean: your code crashes, perhaps on nums[0] or Max().
  • Trace it honestly, then add the guard.
• “What if the numbers are very large?”
  • They mean: your int overflows.
  • Switch the running total to long, and say where the overflow would happen.
• Silence after you finish.
  • They mean: they are waiting for the complexity.
  • Give time, space and one follow-up.

A worked transcript

Problem: count the subarrays summing to exactly k. Compressed, but this is the shape.

public static class SubarraySum
{
    /// <summary>Counts contiguous subarrays whose sum is exactly k. O(n) time and space.</summary>
    /// <param name="nums">The values. Negatives and zeros are allowed.</param>
    /// <param name="k">The target sum.</param>
    /// <returns>The number of subarrays that sum to k.</returns>
    /// <example>SubarraySum.Count([1, 2, 3], 3) returns 2.</example>
    public static int Count(int[] nums, int k)
    {
        // prefix sum -> how many times it has appeared so far.
        // Seed: the empty prefix has sum 0 and appears 1 time, so ranges from index 0 count.
        var seen = new Dictionary<long, int> { [0] = 1 };
        long running = 0;   // 0 is the sum of the empty prefix. long, so it cannot overflow.
        int count = 0;      // 0 matches found so far

        // Each pass ends a range at this value.
        // Invariant: seen holds every prefix that ends BEFORE this value.
        foreach (int x in nums)
        {
            running += x;
            // Look up first, so the current prefix cannot pair with itself.
            count += seen.GetValueOrDefault(running - k);   // a miss reads as 0 matches
            seen[running] = seen.GetValueOrDefault(running) + 1;   // + 1 records this prefix
        }
        return count;
    }
}