Running the coding interview

What the interviewer is scoring

Most companies score a coding round on a few things: problem solving (did you find a good approach and reason about it), coding (is the code correct, clean and readable), testing (did you find your own bugs), and communication (could the interviewer follow your thinking). A perfect solution typed in silence can score lower than a good one explained clearly, because the interviewer must write down evidence of how you think.

A step plan for 45 minutes

1. Listen and restate: say the problem back in your own words. "So I get a list of meeting times and must merge the ones that overlap?"
2. Clarify: ask about input size, empty input, duplicates, negatives, sorted or not, what to return when there is no answer, and whether you may change the input.
3. Work an example by hand, including one tricky case. Write it in the editor as a comment.
4. State the brute force and its cost: "Comparing every pair is O(n²)." This shows you can always produce something correct.
5. Optimise: look for repeated work, then match a pattern (sorting, hash map, two pointers, heap, DP). Say the new cost.
6. Agree: "I will sort by start time and merge in one pass, O(n log n). Shall I code that?" Wait for a yes.
7. Code cleanly: clear names (start, end, merged), small helper functions, no clever one-liners you cannot explain.
8. Test: walk through your example line by line, then run the edge cases from step 2.
9. Analyse: state time and space, and what dominates (here, the sort).
10. Discuss trade-offs: what if the input is huge, streaming, or already sorted? What would you change?

Thinking aloud

Thinking aloud means narrating your reasoning as you go: what you are trying, why, and what you just noticed. It feels strange at first, so practise it alone with a timer. Useful phrases: "My first idea is…", "This fails when…", "The repeated work here is…", "Let me check this with the example…". Silence for more than a minute leaves the interviewer guessing.

When you are stuck

• Try a smaller example (two or three items) and solve it by hand; notice what you did.
• Solve a simpler version: sorted input, no duplicates, only positive numbers. Then remove the simplification.
• Go through the pattern cheat-sheet: could a hash map, a sort, two pointers, a heap or a DP state help?
• Ask for a hint politely: "I am thinking about sorting first; am I on a useful track?" Taking a hint costs much less than staying stuck.
• If time is short, code the brute force cleanly and explain how you would improve it.

Online assessments versus live rounds

An online assessment (OA) is a timed test on a platform with hidden test cases and nobody watching. Only correctness and speed count: read the constraints, handle edge cases, and submit partial solutions if the platform gives partial marks. A live round is with an interviewer on a call or in person, often in a shared editor that may not run code. There, communication and testing by hand matter as much as the final code.

Choosing a language

Use the language you write most fluently. Python is short and has collections, heapq and bisect built in, which saves time. Java and C++ are common too, especially in competitive programming and some companies' preferences. Whatever you choose, know its standard tools for lists, maps, sets, heaps and sorting without searching, and know its pitfalls (integer overflow in Java and C++, mutable default arguments in Python).

Common mistakes

• Jumping into code after hearing the problem. Fix: spend the first 5 to 10 minutes on clarifying, examples and the approach.
• Not stating the brute force. Fix: always say it with its cost, even if you know the optimal idea.
• Going silent when stuck. Fix: say what you are trying; ask for a hint after a few minutes.
• Declaring "done" without testing. Fix: trace one example and the edge cases before you say you are finished.
• Arguing with a hint. Fix: thank the interviewer and try it; they are helping you.