Cracking a technical interview requires more than just knowing algorithms. This guide covers all 77 interview prep topics on TheCodeForge — coding patterns, system design, HR questions and aptitude.
Technical interviews test three things that have almost nothing to do with each other: whether you can find an algorithm under time pressure, whether you can reason about a system you have never built, and whether people want to work with you. Candidates who prepare fail most often because they spend all their time on the first and are surprised by the other two.
The good news is that all three are learnable, and the highest-return preparation is not more problems. It is learning to recognise which pattern a problem belongs to, learning a repeatable structure for design rounds, and having your own stories prepared well enough that you are not composing them live.
Nobody derives the sliding-window technique during a 45-minute interview. What strong candidates do is recognise, within a minute or two, that a problem is a sliding-window problem — and then spend the remaining time on correctness and edge cases rather than on the idea.
That recognition comes from a surprisingly short list. Most interview problems are one of about ten patterns, and the input's shape usually announces which:
| Signal in the problem | Pattern | Typical complexity |
|---|---|---|
| Sorted array, find a pair or a target | Two pointers / binary search | O(n) or O(log n) |
| Contiguous subarray or substring, best or longest | Sliding window | O(n) |
| Top k, or a running median | Heap | O(n log k) |
| Next greater or smaller element | Monotonic stack | O(n) |
| Shortest path in an unweighted graph or grid | BFS | O(V + E) |
| All paths, connected components, cycle detection | DFS / union-find | O(V + E) |
| Count the ways, or optimise over choices with overlap | Dynamic programming | O(n · states) |
| Prefix, autocomplete, word lookup | Trie | O(length) |
| Intervals, merging or overlap | Sort by start, then sweep | O(n log n) |
| Subsets, permutations, combinations | Backtracking | exponential — say so |
A hundred problems worked through slowly, with the pattern named out loud each time, beats four hundred solved and forgotten. If you cannot state why a problem belongs to its pattern, you have memorised a solution rather than learned one.
System design rounds are open-ended by design, and the most common failure is not a wrong answer but an unstructured one — jumping straight to a database choice before establishing what the system must do. Interviewers are assessing how you approach ambiguity, so the structure itself is part of the signal.
A sequence that fits 45 minutes: clarify functional requirements and explicitly agree what is out of scope (5 min); establish scale — users, requests per second, read-to-write ratio, data volume, and the latency and availability targets (5 min); sketch the high-level design end to end (10 min); go deep on the one or two components the interviewer steers you toward (15 min); then identify bottlenecks, failure modes and trade-offs you are accepting (10 min).
That last section is where senior candidates separate themselves. Saying 'this is eventually consistent, so a user may not see their own write immediately — here is how I would fix that for their own profile specifically' demonstrates more than any amount of component naming.
The behavioural round is frequently treated as a formality and is frequently where offers are lost. It is evaluated on evidence: a specific situation, what you did, and what resulted — which is what the STAR structure is for. Answers that stay in the abstract ('I always make sure to communicate clearly') provide no evidence at all.
Prepare six to eight real stories and know them well enough to retell in two minutes: a conflict with a colleague, a failure and what changed afterwards, a project you led, a time you disagreed with a decision, a time you had to deliver under a hard constraint, and something you taught someone. Most behavioural questions are one of those six in disguise.
Bring numbers where you honestly have them, and say so plainly when you do not. 'Cut p99 latency from 1.2s to 300ms' is stronger than 'improved performance'; inventing a number you cannot defend under follow-up is worse than either.
| Weeks | Focus | Concretely |
|---|---|---|
| 1–2 | Patterns, not volume | Arrays, strings, hash maps, two pointers. Name the pattern before writing code, every time |
| 3–4 | Trees, graphs, recursion | BFS and DFS until they are automatic; they underpin a large share of medium problems |
| 5–6 | Dynamic programming and system design basics | DP slowly — it is the pattern that most rewards depth. Start reading one design case per week |
| 7–8 | Mock interviews and behavioural stories | Out loud, timed, with someone else. Write your six stories down and rehearse them |
| Ongoing | Spaced repetition | Re-solve problems you got wrong after a week and again after a month. This is what makes recall survive interview nerves |
Two habits are worth more than extra hours: solve out loud, because thinking silently is a skill that does not transfer to an interview; and always state the complexity of your solution unprompted, because being asked for it repeatedly reads as though you had not considered it.
Every tutorial starts with a plain-English analogy — then real code, then interview questions.
Browse Interview Tutorials →