Interview guide
Solving the problem is only part of it. Interviewers watch how you clarify, reason, write code and check your work. Here's how to learn so it sticks, and exactly what to do and say in the room.
Before the interview
1.Learn patterns, not answers
Each problem is practice for a pattern (two pointers, sliding window, BFS…). After solving, name the pattern and the clue in the problem that pointed to it.
2.Time-box the attempt
Give it 20–30 minutes. If you're stuck, read only the idea, not the code, then close it and write the code yourself.
3.Write a 3-line note
Pattern, key insight, the bug you hit. Reading these notes before an interview beats re-reading whole solutions.
4.Re-solve from memory
Solve it again after 1 day, 1 week and 1 month. If you can't, it wasn't learned yet. That's what Reviews is for.
Open reviews →5.Practise like the real thing
Sometimes use a plain editor with no autocomplete, a 45-minute timer, and explain out loud as if someone is listening.
In the room
A typical coding round, step by step, with what to do and an example of what to say. The example is Two Sum.
Restate the problem in your own words. Ask about input size, value ranges, duplicates, negatives, empty input and what to return.
“So I get an unsorted array of integers and a target, and I return the indices of two numbers that add up to it. Can there be more than one answer? Can I use the same element twice?”
Work one normal example by hand, then list edge cases. Agree on them before coding.
“Let me try [2, 7, 11, 15] with target 9: that's 0 and 1. Edge cases I'll keep in mind: two elements, negative numbers, duplicates like [3, 3].”
State the simplest correct idea and its complexity. Don't code it unless asked, but it proves you understand the problem.
“The brute force checks every pair: O(n²) time, O(1) space. That works but is slow for large n. Can I do better?”
Find the repeated work and remove it, usually with a better data structure. Get the interviewer's OK before you write code.
“The slow part is searching for the partner each time. If I store each number's index in a hash map, I can look up target − x in O(1). That's O(n) time and O(n) space. Does that sound good?”
Write clean code with clear names. Explain each block briefly as you write it, not after.
“I'll loop with the index. For each number I compute what I need. If it's already in the map, I return both indices; otherwise I store this one.”
Dry-run your code line by line on the example, then on an edge case. Fix bugs calmly and say what you changed.
“Running [3, 3], target 6: first 3 isn't in the map, I store it. Second 3 needs 3, which is there, so I return 0 and 1. Good.”
Restate final complexity and mention a trade-off or extension. Then ask your own questions.
“Final: O(n) time, O(n) space. If memory were tight and the array sorted, two pointers would give O(1) space.”
In the room
In the room
Use the same four parts every time. It keeps you organized under pressure and makes you easy to follow.
1
Idea
One or two sentences: the pattern and the key insight.
2
Why it works
The reason it's correct: what stays true at every step (the invariant).
3
Complexity
Time and space, with a reason for each, not just the letters.
4
Trade-offs
What you gave up (usually memory) and when another approach would be better.
Example: Longest Substring Without Repeating Characters
In the room
Avoid
Behind the scenes
Most companies use a version of these four areas. A correct answer with poor communication can score lower than a near-miss that was clearly reasoned and tested.
Problem solving
Did you understand the problem, find a good approach and justify it?
Coding
Is the code correct, readable and reasonably structured?
Communication
Could they follow your thinking? Did you listen to and use their input?
Verification
Did you test your own code and find your own bugs?
Pick the company you're interviewing with, or follow the roadmap level by level.