DSA Interview Red Flags

A compact reference for interviewers and candidates. Reasoning ability matters more than memorizing algorithm names — the bottom tier is deliberately forgiving.

Major problems

Any of these should make you reconsider a hire — or, as a candidate, be the first thing you fix.

Major
  • Cannot explain why their own solution is correct, or why each step is needed.
  • Cannot determine the time or space complexity of code they just wrote.
  • Ignores the constraints and proposes an O(n²) algorithm for n ≤ 10⁵ without noticing.
  • Debugs by random edits instead of tracing a concrete input through the code.
  • Cannot reason about edge cases such as empty input, a single element, duplicates, or negative numbers.
  • Claims the code works without running a single example by hand.
  • Contradicts the problem statement (solves subsequence when subarray was asked) and does not notice when the example fails.
  • Cannot recognize any of the standard patterns (hashing, two pointers, BFS, DP) even after a strong hint.

Serious concerns

Strong signals of memorization over understanding.

Serious
  • Recites a memorized pattern name but cannot say why it applies or what invariant it maintains.
  • Starts typing code before stating an approach or asking a single clarifying question.
  • Never compares alternatives, so cannot say why a heap beats sorting here or why BFS beats DFS.
  • Reaches for an unnecessarily complex algorithm (segment tree, Dijkstra) when a prefix sum or BFS suffices.
  • Produces a working brute force but cannot identify the bottleneck or improve it with a hint.
  • Cannot name the data structure that supports the operations their algorithm needs in the required time.
  • Silently changes the approach mid-implementation and leaves the code inconsistent with the explanation.
  • Fails the same class of bug (off-by-one, missed visited set) twice in the same session after it was pointed out.

Minor / contextual

These are not red flags. Do not weight them.

  • Forgets exact library syntax, such as the argument order of heapq.heappush or how to sort by a key.
  • Blanks on the name of a rarely used algorithm (Kosaraju, Manacher) while still describing the idea correctly.
  • Solves in a different language than the team uses, as long as the reasoning is clear.
  • Needs one small nudge ("what if the array were sorted?") and then proceeds independently.
  • Has not seen an obscure technique like meet-in-the-middle or a sparse table.
  • Makes a typo or minor syntax slip that they catch during their own trace.
  • Runs a few minutes over on a hard problem while still reasoning productively.

What good looks like

Green flags
  • Clarifies the requirements first: input format, output format, duplicates, empty input, value ranges.
  • Reads the constraints and states the target complexity before proposing anything.
  • Starts with a correct brute force and states its complexity honestly.
  • Identifies the specific bottleneck in the brute force and derives the optimization from it.
  • States the time and space complexity of the final solution with a one-line justification.
  • Discusses tradeoffs — memory versus time, simplicity versus speed, sort versus heap.
  • Tests edge cases deliberately: empty, one element, all equal, maximum size, negative values.
  • Explains why the solution is correct in terms of an invariant, not just "it passes the example".
  • Considers at least one alternative approach and explains why it was rejected.
  • Communicates continuously, so the interviewer never has to ask "what are you thinking?"

Every interview question in this guide applies these flags to a specific answer — start with the question library.