How do I prepare for a technical coding interview?

Spend it on patterns and out-loud practice, not on solving as many problems as possible. Most people grind volume and still freeze, because the interview tests communicated problem-solving under observation — a different skill from solving quietly at your desk. **A month's plan:** *Week 1 — foundations and patterns.* Arrays and strings, hash maps, two pointers, sliding window. Learn the *pattern*, not the problem. There are roughly 15 recurring patterns behind the vast majority of interview questions; recognising which one applies is the actual skill. Aim for 3-4 problems a day, and redo the ones you couldn't solve. *Week 2 — core structures.* Stacks, queues, linked lists, binary trees, BFS and DFS, recursion. Trees and graph traversal come up constantly. *Week 3 — harder patterns and depth.* Binary search variants, heaps, intervals, basic dynamic programming. Don't over-invest in advanced DP — it appears less often than its reputation suggests and consumes disproportionate time. *Week 4 — simulation.* Full mock interviews, out loud, timed, ideally with another person. This is the highest-value week and the one people skip. **The practice method that actually transfers:** 1. Attempt for 20-25 minutes before looking at anything. The struggle is the training. 2. When stuck, look up the *approach*, then implement it yourself without the solution visible. 3. **Redo the problem 3-5 days later, cold.** Solving once is recognition; solving again is retention. This one habit outperforms doing twice as many problems. 4. Keep a log: problem, pattern, what tripped you. **How to behave in the actual interview**, which is worth as much as the algorithms: - **Clarify first.** Ask about input size, edge cases, duplicates, empty input. Interviewers deliberately leave ambiguity to see whether you ask. - **Say your approach before coding**, including the brute force and why you're improving on it. Silent coding is the most common way strong candidates fail. - **Think out loud continuously.** They're evaluating your reasoning; if it's internal, they can't score it. Even 'I'm considering a hash map here because lookups need to be constant' is valuable. - **Start with a working brute force** if you're stuck. A working slow solution beats an unfinished clever one. - **Test your code out loud** with a small example and an edge case before saying you're done. And take hints gracefully — they're offered to help, and how you incorporate them is part of the assessment.