What Interviewers Actually Look For in a Coding Interview

Many candidates prepare for coding rounds by solving more problems, then find in the interview that working code is only part of what's evaluated. This post collects the coding interview tips I'd give from the other side of the table: the signals interviewers typically score, a minute-by-minute plan for a 45-minute round, a fully worked example, and a practice routine that builds the right habits.

As part of the hiring loop at BigLeap, I take technical interviews covering data structures and algorithms, system design and problem solving. What follows isn't any company's official rubric. It's the set of signals widely used across the industry, and the ones I listen for when I'm interviewing.

The signals interviewers typically score

A correct solution matters. But "solved it" is one data point, and interview feedback usually covers how you got there.

The common thread is visibility. An interviewer can only score what they see or hear, and a candidate thinking brilliantly in silence looks the same as one who is stuck.

Coding interview tips for a 45-minute round

Rounds vary, so treat this as a rough budget, not a script.

The blocks easiest to skip under pressure are the first five minutes and the testing window. Both are cheap, and both are scored.

A worked example: Longest Substring Without Repeating Characters

Let's run the framework on a classic, Longest Substring Without Repeating Characters: given a string s, return the length of the longest substring with no repeated characters.

Step 1: Clarify

• Substring or subsequence? Substring, so characters must be contiguous. For "pwwkew" the answer is 3 ("wke"), not 4, because "pwke" is a subsequence.
• Which characters? Letters, digits, symbols and spaces. This bounds how large a hash map can grow.
• Empty string? Return 0.

Examples to agree on: "abcabcbb" → 3, "bbbbb" → 1, "pwwkew" → 3, "" → 0.

Step 2: Start with brute force

Checking every substring for duplicates is O(n^3): O(n^2) substrings, O(n) to check each. You can drop a factor of n quickly by fixing a start index, extending right with a set, and stopping at the first repeat.

def length_of_longest_substring_brute(s: str) -> int:
    best = 0
    for i in range(len(s)):
        seen = set()
        for j in range(i, len(s)):
            if s[j] in seen:
                break
            seen.add(s[j])
            best = max(best, j - i + 1)
    return best

That's O(n^2) time in the worst case and O(min(n, k)) space, where k is the size of the character set. Saying this out loud takes a minute and gives you a correct fallback.

Step 3: Find the bottleneck

The waste is in restarting. On "abcabcbb", when the window "abc" meets a second a, the brute force rescans from b, even though we already know "bc" has no repeats. We only need to move the window's start past the previous a.

That's a sliding window: right grows the window one character at a time, and left only moves forward. A hash map from each character to its last-seen index tells us where to move left.

Step 4: Code the sliding window

Python:

def length_of_longest_substring(s: str) -> int:
    last_seen = {}  # character -> index where we last saw it
    left = 0        # start of the current window
    best = 0

    for right, ch in enumerate(s):
        # Only jump if the repeat is inside the current window.
        if ch in last_seen and last_seen[ch] >= left:
            left = last_seen[ch] + 1
        last_seen[ch] = right
        best = max(best, right - left + 1)

    return best

TypeScript:

function lengthOfLongestSubstring(s: string): number {
  const lastSeen = new Map<string, number>(); // character -> last index
  let left = 0; // start of the current window
  let best = 0;

  for (let right = 0; right < s.length; right++) {
    const ch = s.charAt(right);
    const prev = lastSeen.get(ch);
    // Only jump if the repeat is inside the current window.
    if (prev !== undefined && prev >= left) {
      left = prev + 1;
    }
    lastSeen.set(ch, right);
    best = Math.max(best, right - left + 1);
  }

  return best;
}

charAt works on UTF-16 code units, which is fine for this problem's character set; for emoji you'd iterate by code point instead.

Step 5: Dry run on "abba"

"abba" is the case I'd trace first, because it catches the most common bug in this solution.

right  ch  last_seen before   left after  window  best
0      a   {}                 0           "a"     1
1      b   {a:0}              0           "ab"    2
2      b   {a:0, b:1}         2           "b"     2
3      a   {a:0, b:2}         2           "ba"    2

At right = 3, a was last seen at index 0, which is outside the current window. That entry is stale. Without the >= left check, left would jump back to 1, the window would become "bba", and the function would wrongly return 3. The check (or left = max(left, last_seen[ch] + 1)) keeps left moving forward only.

"" never enters the loop and returns 0. "bbbbb" moves left to right on every repeat, so the window never exceeds 1. "pwwkew" shrinks to "w", grows to "wke", then slides to "kew", returning 3.

Step 6: State the complexity

• Time: O(n). right visits each index once with constant average-time map work, and left never moves backwards.
• Space: O(min(n, k)). The map holds at most one entry per distinct character.

If asked "what if the input is only lowercase letters?", a fixed array of 26 indices can replace the map: a constant-factor gain, not a change in complexity class.

Red flags interviewers notice

These are habits, not a lack of ability, and habits respond to practice.

• Silent coding. Long stretches of typing leave the interviewer guessing. Narrate decisions, not keystrokes.
• Jumping straight to code. Skipping clarification risks solving the wrong problem.
• Ignoring hints. "What if the input were sorted?" is rarely idle curiosity. Stop and engage with it.
• Not testing. Finding and fixing your own bug is a positive signal; leaving it for the interviewer to spot is not.
• Arguing. Disagreeing with reasons is fine. Defending an approach after a clear counterexample isn't. Treat the interviewer as a collaborator.

What to do when you're stuck

Getting stuck is normal, and how you handle it is part of what's evaluated.

1. Say it. "I'm stuck on how to avoid rescanning the window" tells the interviewer where to aim a hint.
2. Work a small example by hand. Solve a five-element input on paper and watch what you do. That's often the algorithm.
3. Fall back to brute force. A correct slow solution beats an unfinished fast one, and improving something concrete is easier than inventing from nothing.
4. Ask what a data structure would buy you. Repeated lookups suggest a hash map; repeatedly needing the smallest item suggests a heap; sorted input suggests binary search or two pointers.
5. Simplify. Solve a smaller version first (no duplicates, a single row), then generalize.
6. Use hints visibly. Restate the hint in your own words and show how it changes your approach.

How to practice effectively

Solving problems at random mostly builds recall of specific answers. Interviews reward recognizing which tool fits a problem you haven't seen, so practice for that.

Learn patterns, not answers

A large share of coding-round problems are variations on a handful of patterns:

Binary search on the answer is easy to miss. "Find the minimum ship capacity to deliver all packages within d days" doesn't look like a search problem. But if you can check one capacity in O(n), and every capacity above a feasible one is also feasible, you can binary search over the possible answers. The same narrowing of a sorted range is what makes B-tree indexes fast, which I cover in my PostgreSQL indexing guide.

After each problem, note which pattern it was and what in the statement should have pointed you there.

Do timed mock interviews

Solve problems against a 45-minute timer with a peer playing interviewer. Time pressure and an audience change how you think, and only repetition gets you used to them.

Explain out loud

Even alone, talk through your approach as if someone were listening. It's the fastest way to discover that an idea you "understood" has a gap.

Review your mistakes

Log the problem, the pattern, where you got stuck and any bug you wrote. Re-solve failed problems from scratch a week later. Mistakes that repeat in the log tell you what to drill next.

Many loops also include a system design round. If you're preparing for one, my walkthrough on designing a real-time collaborative task board shows how I approach that kind of problem end to end.

Key takeaways

• Interviewers score the process, not only the answer: clarifying, communicating, improving from brute force, complexity, clean code, testing and taking hints.
• Spend the first five minutes clarifying and agreeing on examples.
• State a brute-force solution and its complexity before optimizing.
• Trace examples and edge cases, like "abba", before saying you're done.
• When stuck, say so, work a small example and use hints visibly.
• Practice patterns over memorized answers, do timed mocks, explain out loud and review every mistake.