Technical interviews can feel random—until you realize most companies are testing the same handful of skills: problem decomposition, tradeoff thinking, and clear communication. Instead of grinding more problems, try upgrading your process. Here’s a repeatable framework you can use in live coding, whiteboards, and online assessments.

A 6-Step Process That Works Under Pressure

1) Restate the problem + confirm inputs/outputs

Before touching code, say (or write):

• What are the inputs? Types, sizes, constraints
• What is the output format? Single value, list, indices vs values
• Edge cases: empty input, duplicates, negative numbers, huge sizes

This prevents “solving the wrong problem” and shows maturity.

2) Clarify constraints → pick the right tool

Ask quickly:

• “What are typical max sizes (n)?”
• “Is this time-sensitive or memory-sensitive?”

Then map constraints to likely approaches:

• If n ≤ 10^5, you’ll usually need O(n log n) or better.
• If you see subarray / prefix / range, think: prefix sums, sliding window.
• If you see “closest / top K / stream”, think: heaps.
• If you see graph-like relationships, think: BFS/DFS, union-find.

3) Propose a baseline solution first

Offer a straightforward approach (even if not optimal):

• Builds interviewer trust
• Helps you validate correctness
• Creates a stepping stone to optimization

Say: “Here’s the simplest correct approach; then we can optimize.”

4) Optimize with a clear tradeoff story

When improving complexity, narrate the reasoning:

• “The bottleneck is nested loops → we need a data structure to lookup faster.”
• “Sorting costs O(n log n), but simplifies matching and deduping.”
• “Hash map gives O(1) average lookup, at the cost of extra memory.”

5) Implement in small, testable chunks

In live coding, reduce mistakes by building in layers:

• Write function signature + examples
• Implement core loop
• Add data structures
• Add edge-case handling

Use quick checks:

• “Let’s dry-run on a small example.”
• “What happens with empty input?”

6) Finish strong: complexity + 2-3 test cases

Always end with:

• Time complexity and space complexity
• A couple tests (normal + edge)

Mini Self-Checklist (Use This Every Time)

• Did I ask for constraints?
• Did I explain why this approach?
• Did I handle edge cases?
• Did I communicate while coding?
• Did I verify with examples?

Tip: If you freeze, narrate what you’re considering: “I’m choosing between a heap and sorting; heap helps if K is small compared to n.” Interviewers reward transparent thinking.

What’s the step you struggle with most—clarifying constraints, choosing the right data structure, or communicating while coding?