How to Prepare for a Tech Interview: A Four-Week Plan You Can Actually Stick To

A technical interview checks a handful of things. Can you solve a problem you haven’t seen before? Can you explain your thinking while you do it? Can you design something sensible and talk about the trade-offs? And can you talk about your own work as if you really did it? The plan below is built around those four questions, not around a problem count.

It assumes about 90 minutes on weekdays and a bit more on weekends, which is what most people with a full-time job or final-year classes can manage. If you have more time, stretch each week out rather than cramming more into it.

Before you start: find out what the interview looks like

This sounds obvious, and almost nobody does it. Ask your recruiter or placement coordinator:

• How many rounds are there, and what is each one? Online assessment, live coding, system design, hiring manager, HR?
• Where does the coding happen: a shared editor, an online judge, a whiteboard or a take-home assignment?
• Which programming languages are allowed?
• Is there a system design round at your level?

Recruiters usually answer these happily, because they want you to pass. Interview experiences that other candidates post online for the same company help too, but treat them as hints, not a syllabus. Questions change, and people remember the hard parts far better than the easy ones.

Week 1: one language, and patterns instead of problem counts

Pick one language and stay with it. Interviewers notice when you’re fighting your own language, so know its standard library well: hash maps and sets, sorting with a custom comparator, heaps or priority queues, a double-ended queue, and how strings and integer overflow behave.

Then work through the common patterns rather than random problems. Most interview questions are a twist on one of these:

• Two pointers and sliding window
• Hashing and frequency counts
• Binary search, including binary search on the answer
• BFS and DFS on grids, trees and graphs
• Intervals: merging, overlaps, meeting rooms
• Heaps for “top k” and scheduling problems
• Prefix sums
• Backtracking
• Basic dynamic programming, in one and two dimensions

Do three to five problems per pattern, starting easy and moving to medium. The rule that makes this work: if you’re stuck for 25 to 30 minutes, read the solution, understand it, then close it. The next day, solve the same problem again from an empty editor. That second attempt is where the learning happens. Reading a solution feels like progress; rebuilding it from memory actually is.

Week 2: practice talking, not just typing

Plenty of people who can solve a problem alone at night go quiet in an interview. Thinking out loud is its own skill, and like any skill it improves with repetition. For every problem this week, follow the same sequence out loud, even if you’re alone in your room:

1. Restate the problem in your own words and ask clarifying questions. How big is the input? Can there be duplicates, negative numbers, an empty array?
2. Give the brute force first and say its complexity. It shows you can always produce something that works.
3. Improve it. Say what’s slow about the brute force and what would fix it.
4. Write the code, narrating the parts that aren’t obvious.
5. Test it out loud with a small example, then with one edge case.

Record yourself solving one problem. It’s painful to watch and very useful. Most people discover long silences they didn’t know about, or a habit like starting every sentence with “so basically”. Aim for 35 to 40 minutes per medium problem, explanation included, since that’s roughly what a real round gives you.

Week 3: system design, fundamentals and your own projects

What you study this week depends on how much experience you have.

If you’re a fresher or sitting for campus placements

Full-scale system design rarely comes up. What does come up, a lot, is CS fundamentals: DBMS (normalization, indexes, joins, transactions), operating systems (processes and threads, deadlocks, scheduling), computer networks (what happens when you type a URL, TCP versus UDP) and object-oriented design. Try a couple of low-level design problems too, like a parking lot or a library system, focusing on the classes and how they talk to each other.

If you have a few years of experience

Expect at least one design round. Use the same structure every time so you never freeze:

1. Clarify requirements: what it must do, and at what scale (users, requests per second, data size).
2. Sketch the API.
3. Choose a data model and say why.
4. Draw the high-level components.
5. Pick one or two bottlenecks and go deep: caching, queues, sharding, consistency.
6. Finish with the trade-offs, and what you’d change at ten times the scale.

Work through four or five classics with this structure: a URL shortener, a rate limiter, a chat app, a news feed and a notification system. You’re not memorizing designs. You’re getting fluent in the structure, so a new question doesn’t feel new.

Everyone: your resume projects

The “walk me through this project” round is where a lot of well-prepared candidates still slip. For every project on your resume, be ready to answer:

• What problem did it solve, and for whom?
• What exactly did you do, as opposed to the team?
• One technical decision you made, and why you chose it over the alternative.
• Something that went wrong, and how you fixed it.
• A number: latency, users, money saved, time cut.

If your resume says Kafka, expect “why Kafka and not a simple queue?”. If it says you improved performance by 40%, expect “40% of what, measured how?”. Anything on the page is fair game.

Week 4: HR stories and full mock interviews

Behavioral and HR rounds feel soft, so people skip preparing for them, then spend the round inventing examples on the spot. Build a small story bank instead: six to eight real stories you can bend to fit most questions. Cover a conflict, a failure, a tight deadline, a disagreement with a manager or senior, leading without authority, learning something fast and a mistake you owned.

Use the STAR structure (situation, task, action, result), but keep the setup short. A good split is about 20% context, 60% what you did and 20% the result and what you learned. Most weak answers are the reverse: three minutes of background and one sentence about the actual action.

Prepare “tell me about yourself” too. Keep it to 60 to 90 seconds: what you do now, the one or two earlier things that matter for this role, and why you want this job. Write it down, say it a few times, then stop memorizing it word for word so it doesn’t sound recited.

Then do full mock interviews, at least two or three, under real conditions: timed, on a video call, out loud. A friend who has interviewed people before is ideal. If that’s hard to arrange, an AI mock interviewer is a reasonable stand-in. Keeter’s mock interview mode, for example, asks questions based on your resume and the job description, gives feedback after each spoken answer along with a stronger sample version, and ends with a report on your weak areas. Whatever you use, the point is to hear yourself answer before the real day.

Finally, prepare two or three questions to ask at the end. Real ones, about the team, the work or how success is measured in the role. Saying “no questions” wastes a chance to leave a good last impression.

The day before and the day of

• Test your setup on the exact platform the interview uses: camera, microphone, internet, and screen sharing if you’ll need it.
• Charge your laptop, and keep the charger plugged in anyway.
• Find a quiet room and tell the people at home when you’ll be on the call.
• Keep water and a pen and paper nearby. Writing down the constraints as you hear them helps more than it seems.
• Reread the job description and your own resume the evening before.
• Sleep. A tired brain makes off-by-one errors and forgets edge cases. One more problem at midnight helps less than rest.
• Join five minutes early.

If you blank on a question, say so calmly and talk through what you do know. “Let me think about this for a second” is completely normal. Interviewers are mostly judging how you approach a problem, not whether you remember the answer instantly.

After every interview, write it down

Within an hour of each interview, note every question you were asked and how you think you did. Rejections rarely come with useful feedback, so your notes are the feedback. After three or four interviews, patterns show up. Maybe you’re fine on coding but keep stumbling on design follow-ups, or your project explanations run too long. That’s what to work on next week.

Four weeks is enough to walk in prepared. Not perfect, because nobody walks in perfect, but prepared. If you’re weighing up tools to practice with, we’ve written a checklist for choosing an AI interview assistant.