After curating more than 4,400 interview questions across 72 technologies for this site, a clear pattern emerged: most candidates don't fail interviews because they lack knowledge. They fail because their preparation was unstructured — a week of random LeetCode problems, a skim through a framework's docs the night before, and hope.

This roadmap fixes that. It assumes you have about six weeks and roughly 60–90 minutes a day. If you have less time, compress the weeks but keep the order — the sequence matters more than the duration.

Week 1: Map the actual job, not the imaginary one

Before you open a single practice problem, spend the first week on reconnaissance:

  • Re-read the job description line by line. Every technology named in it is fair game for a question. If the posting says "REST APIs, PostgreSQL, Docker," expect questions on HTTP semantics, indexing and joins, and container basics — not just your primary language.
  • Search the company's engineering blog and recent releases. Interviewers overwhelmingly ask about problems they work on daily. A company migrating to microservices will probe distributed-systems thinking even for junior roles.
  • Write down your honest gap list. Go through a question bank for each listed technology and mark every question you couldn't answer aloud in two minutes. That list — not a generic study plan — is your syllabus.

Weeks 2–3: Fundamentals before frameworks

Interviewers use simple questions to probe depth. "What happens when you type a URL into a browser?" or "What's the difference between == and ===?" look easy, but the follow-ups are where interviews are decided: Why does JavaScript coerce types that way? What does the DNS resolver cache? When would you actually want type coercion?

Spend these two weeks on the layer beneath your day-to-day work:

  • For backend roles: how your language manages memory, how your database chooses an index, what happens between "request received" and "response sent" in your framework.
  • For frontend roles: the event loop, browser rendering pipeline, closures and scope, and why your framework re-renders when it does.
  • For every role: HTTP (methods, status codes, headers, caching), one round of Big-O analysis on code you have actually written, and basic SQL without an ORM.

A practical technique: answer questions out loud, without notes, as if a person were sitting across from you. Reading an answer and nodding feels like knowing; producing the answer from nothing is what the interview requires. They are different skills, and only one of them is tested.

Week 4: Deliberate problem practice

Now the coding practice — but deliberately, not by volume:

  • Solve 3–4 problems per pattern, not 40 random ones. The classic patterns (two pointers, sliding window, BFS/DFS, hash-map lookups, binary search on the answer) cover the overwhelming majority of screening questions. Once you can recognize a pattern from the problem statement, additional repetitions add little.
  • Time-box every problem to 30 minutes. If you're stuck at 30, read the solution, close it, and re-implement from memory an hour later. Staring for two hours teaches stubbornness, not algorithms.
  • Narrate while you code. In the real interview you must think aloud. Practicing silently then performing aloud is like rehearsing a speech by reading it silently.

Week 5: The system design and "experience" rounds

Two rounds catch candidates off guard because they can't be crammed:

System design (mid-level and up): practice the standard loop — clarify requirements, estimate scale, sketch the data model, pick components, then discuss trade-offs. Interviewers care far more about trade-off reasoning ("I'd start with a single Postgres instance because at this scale, operational simplicity beats theoretical throughput") than about drawing the trendiest architecture.

Behavioral/experience questions: prepare five concrete stories from your real work — a hard bug, a disagreement, a deadline, a failure, a thing you're proud of. Structure each as situation → action → result, with one specific number or detail that makes it real. Vague stories ("we improved performance a lot") are forgettable; specific ones ("p95 latency dropped from 900ms to 210ms after we moved the image processing into a queue") get written down by the interviewer.

Week 6: Simulate, rest, and logistics

  • Do at least two full mock interviews — with a friend, a colleague, or even by recording yourself answering a random set of questions for 45 minutes. The first mock is always rough; better to burn that roughness on a simulation.
  • Re-review your bookmark list. The questions you flagged in week 1 that still feel shaky are your highest-value hours this week.
  • Handle logistics the day before: test your camera and microphone for remote interviews, know the office location for on-site ones, and read your own CV again — a shocking number of candidates stumble when asked about a bullet point they wrote themselves.

What not to do

  • Don't learn a new framework the week before. Depth in what you know beats surface knowledge of what's trendy. "I haven't used it, but based on X I'd expect it works like Y" is a perfectly strong answer.
  • Don't memorize answers word-for-word. Interviewers ask follow-ups precisely to detect this. Understand the reasoning; the words will come.
  • Don't skip sleep for one more practice session. Interviews are working-memory-intensive. A tired candidate with more preparation reliably performs worse than a rested one with less.

A final note on failure

Even with perfect preparation, some interviews go badly — an off day, a hostile interviewer, a question from left field. Treat each interview as a data point, not a verdict. After every one, write down the questions you were asked while they're fresh. Three interviews in, you'll have a personalized question bank more valuable than anything online — because it's calibrated to the exact roles you're applying for.