menu_bookGyanByte
Lesson 013 min read

How Coding Interviews Really Work

November 05, 2026

// TL;DR

A coding interview tests how you SOLVE problems, not whether you've seen the exact one before. There are thousands of questions but only ~18 underlying PATTERNS; the skill is recognising which pattern fits. Use a method for every question: (1) CLARIFY — ask about inputs, edge cases, constraints before coding; (2) EXAMPLES — work a small case by hand to see the structure; (3) PLAN — say your approach out loud and name the pattern before writing code; (4) CODE — clean and correct, thinking aloud; (5) TEST — dry-run edge cases and fix bugs yourself. The constraints are a huge hint about the intended complexity (and pattern). Communicate throughout — interviewers hire a problem-solver they can work with, so show the thinking, not just the final code.

Before any algorithms, let us get the right model of what a coding interview is — because getting this wrong is why smart people underperform in interviews they could easily pass.

What is actually being tested

A coding interview is not a memory test. The interviewer is not checking whether you’ve seen this exact problem; they are watching how you think — how you break down an unfamiliar problem, communicate, handle edge cases, and write clean, correct code. That is the thing they are trying to hire: a problem-solver they can work with.

This is good news, because it means you do not need to memorise a thousand problems. You need to learn the patterns and the method.

Patterns beat problems

Here is the single most useful fact about coding interviews: there are thousands of questions but only about eighteen underlying patterns. Two Sum, 3Sum, container-with-most-water and valid-palindrome are all the same pattern (two pointers). Longest-substring, max-sum-subarray and min-window are all one pattern (sliding window). Once you recognise the pattern, you already know the template — you are just filling in the details.

So the goal of this course is not “solve 500 problems”; it is “learn 18 patterns deeply, and the judgement to recognise which one fits.” That is a far better use of your time, and it transfers to problems you have never seen.

The method: clarify → examples → plan → code → test

How to approach any coding problem, five steps. One, clarify: ask about inputs, edge cases and constraints. Two, examples: work a small example by hand to spot the pattern. Three, plan: say the approach out loud before coding and name the pattern. Four, code: clean and correct, talking through it as you go. Five, test: dry-run edge cases and fix bugs yourself. Say the pattern name before you code — that is the whole skill this course builds. Why patterns beat memorising problems: there are thousands of questions but only about eighteen underlying patterns; a strong candidate recognises this is a sliding-window problem and reaches for the template. In the room the method matters as much as the answer: clarify the question, work a small example, state your plan and name the pattern, write clean code while thinking aloud, then test it yourself on edge cases.

Have a routine you run for every question, so you never freeze:

  1. Clarify. Never start coding on assumptions. Ask: what are the input types and ranges? Can the array be empty, have duplicates, be unsorted? What should I return on no answer? These questions also buy you thinking time and show maturity.
  2. Examples. Work a small example by hand. Writing out [2,7,11,15], target 9 and finding 9 = 2+7 often reveals the structure (and the pattern) faster than staring at the abstract problem.
  3. Plan. State your approach out loud before coding, and name the pattern: “I’ll use two pointers because the array is sorted.” This is the most important habit in the whole interview — it lets the interviewer course-correct you before you waste time, and it is exactly the signal they are looking for.
  4. Code. Write clean, correct code, narrating as you go (“now I’ll loop and keep a running max…”). Silence is bad; a running commentary is good.
  5. Test. Dry-run your code on your example and on edge cases (empty, one element, duplicates, the boundary). Find your own bugs before the interviewer does — that is a huge positive signal.

Read the constraints — they are a hint

One pro move: the constraints in the problem statement tell you the intended complexity, and often the pattern. n ≤ 20 hints at exponential/backtracking. n = 10⁵ means you need O(n log n) or better, so brute force is out. n = 10⁹ means O(log n) or O(1). Always read the constraints first — they are not decoration, they are a clue (Lesson 2).

Communicate, always

The hardest thing for many strong coders: talk. Think out loud. Explain your plan. Ask questions. Admit when you’re stuck and reason through it. The interviewer cannot read your mind, and a brilliant silent solution scores worse than a good, clearly-communicated one. You are auditioning as a teammate, not just a coder.

Pitfalls

  • Coding before clarifying. You solve the wrong problem, or miss an edge case the interviewer specifically wanted. Always clarify first.
  • Going silent. The interviewer is evaluating your thinking; if you don’t share it, there’s nothing to evaluate. Narrate.
  • Memorising problems instead of patterns. You freeze on anything slightly different. Learn the pattern and the template.

Recap

A coding interview tests how you solve problems, not whether you’ve memorised them — and there are only ~18 underlying patterns to learn. Run a method on every question: clarify, work an example, state the plan (name the pattern), code cleanly, test yourself. Read the constraints for the intended complexity, and communicate throughout. That mindset, plus the patterns in this course, is what cracks the coding round.

Next: Lesson 2 — Big-O Made Intuitive, so you can state and choose complexity with confidence.

coding-interviewinterview-prepproblem-solvingpatterns
Next arrow_forwardBig-O Made Intuitive