A common mistake in interview preparation is to grind hundreds of coding problems, then walk into a design or behavioural round with nothing ready. Four focused weeks will not make you an expert, but they are enough to get fluent in the formats most interview loops use, provided the hours are split sensibly. This plan gives you a daily time budget, a week-by-week schedule, what to practise for each kind of round, and how to use the last 48 hours.
Set a daily time budget you can keep
Plan for about two hours on a working day and four on one weekend day. That is sustainable alongside a job, and five steady days do more than one heroic Sunday. A typical weekday:
- 60 to 75 minutes: timed coding problems from the week’s patterns.
- 30 minutes: low-level design, system design or a topic specific to your role.
- 15 minutes: update your mistake log and rehearse one behavioural story aloud.
Use the weekend block for a mock interview or a timed design exercise, followed by an honest review. With fewer than three years of experience, give the system design slots to extra problem-solving and low-level design, since loops at that level often skip a full system design round.
The four weeks at a glance
| Week | Coding patterns | Design and other rounds | Done by Sunday |
|---|---|---|---|
| 1 | Arrays, strings, hashing, two pointers | Object-oriented basics; model two small systems on paper; list your behavioural stories | Mistake log started; your language’s standard library feels automatic |
| 2 | Sliding window, stacks and queues, binary search, linked lists | Two timed machine-coding exercises; with 3+ years, design fundamentals: caching, databases, queues | First mock interview done and reviewed |
| 3 | Trees, graphs (BFS, DFS, topological sort), heaps | Role-specific topics; with 3+ years, three classic system design problems end to end | Second mock; behavioural stories written in STAR form |
| 4 | Dynamic programming basics, then mixed timed sets | Revision from the mistake log; full mock loops | Two more mocks; your last-48-hours checklist ready |
Coding rounds: practise patterns, not problem counts
Interviewers rarely care whether you have seen a problem before. They watch whether you recognise its shape, choose an approach, explain it and write correct code. That is pattern recognition, and it can be trained. Learn the trigger for each pattern:
- Arrays: prefix sums for repeated range questions, in-place updates, and sorting first when the original order does not matter.
- Hashing: “have I seen this before?”, counting, or looking for a complement. You trade memory for a single pass.
- Two pointers: sorted input, pairs that meet a condition, or rearranging in place.
- Sliding window: the longest or shortest contiguous subarray or substring that satisfies a constraint.
- Trees and graphs: breadth-first search for level order and shortest paths in unweighted graphs; depth-first search for connectivity, cycles and paths; topological sort when tasks depend on other tasks.
- Dynamic programming basics: “how many ways”, “minimum cost” or “is it possible” questions in which the same subproblem keeps recurring. Start with one-dimensional problems before grids and knapsack-style choices.
Give each problem a 25 to 30 minute block. If you are stuck at the end, read the approach (not the code), close it, and write the solution yourself. Log the problem with one line on what you missed, then solve it again from scratch three or four days later; re-solving is where a pattern sticks. Talk while you work, even alone: state the brute force and its complexity first, then improve it. Ten minutes of silence followed by perfect code often scores worse than a clearly reasoned path to slightly imperfect code.
Low-level design and machine coding
Many product companies in India run a machine-coding round, usually somewhere between one and two hours, in which you build a working, modular program for something like a parking lot, an expense-splitting app, a rate limiter or an in-memory key-value store with expiry. Others hold a discussion-style low-level design round on the same kind of problem. Both look for:
- clear entities and responsibilities, with interfaces where variation is likely;
- code that runs and handles the obvious edge cases before the clever ones;
- a few patterns used where they fit, such as strategy for interchangeable rules, rather than a catalogue;
- thread safety, when the problem implies concurrent access.
Practise with a 90-minute timer and a blank file in your interview language. Spend the first ten minutes on requirements and entities, get a minimal version running, then extend it. Finishing with something that runs and is easy to extend beats finishing with an elegant design that does not compile.
System design basics, if you have three or more years
At this level a design round checks whether you can turn a vague prompt into a reasonable architecture and defend your choices. Practise the same sequence every time:
- Clarify the functional requirements and pick the two or three that matter most.
- Estimate scale roughly: requests per second, data per day, the ratio of reads to writes.
- Define the API and the data model.
- Draw the main components and walk one request through them.
- Find the bottleneck and address it with caching, partitioning, queues or replication.
- Discuss failure: what happens when a dependency is slow or down, and how you would notice.
Good practice problems include a URL shortener, a notification service, a rate limiter, a news feed and a chat system. Interviewers listen for trade-offs said out loud, such as “a relational database here, because an order and its payment must change together in one transaction”, far more than for a list of technologies. Your current system is free practice material: draw it, find its weakest point and decide what you would change.
Role-specific rounds: ask the recruiter
Recruiters will usually tell you how many rounds there are, what each covers, which languages are allowed and whether you can run your code. Ask, then weight your preparation:
- Frontend: JavaScript closures and the event loop, rendering performance, accessibility basics, and building a small component against the clock.
- Backend: API design, indexes and query plans, transactions and isolation levels, and debugging a slow endpoint.
- Data: SQL with window functions, data modelling, and handling pipeline failures and late-arriving data.
- Mobile: app lifecycle, state management, offline behaviour and performance on low-end devices.
- DevOps and cloud: Linux and networking troubleshooting, CI/CD pipeline design, and walking through an incident you handled.
The job description fills in the rest: skills named early and repeated later are usually the ones the panel will probe. The guide to reading a job description explains how to tell them apart from the wish list.
Behavioural rounds: six to eight stories in STAR form
A hiring manager uses behavioural questions to judge how you act when things go wrong, and an unprepared answer rambles. Prepare six to eight stories covering a conflict, a failure or production incident, a tight deadline, ownership beyond your role, a decision with trade-offs, and helping someone else improve. Structure each with STAR: Situation, Task, Action, Result.
An illustrative answer to “Tell me about a time you disagreed with a technical decision”:
Situation: Our team planned to add a separate search database to a service that already had consistency bugs.
Task: I owned the search feature and was asked to start the migration.
Action: I compared the new database with PostgreSQL’s built-in full-text search, ran both against a week of real queries, and shared a one-page summary with my lead before the planning meeting.
Result: Full-text search met our latency target, we dropped the second database, and the feature shipped two weeks earlier than planned. I learnt to bring data to a disagreement instead of opinions.
Keep the situation to two sentences, spend most of your time on the action, and say “I” rather than “we”. End with the result and what you learnt. Rehearse aloud, because a story that reads well on paper often runs to four minutes when spoken.
Mock interviews: rehearse the conditions, not just the content
Mocks expose what solo practice hides: talking while coding, recovering from a wrong start and managing the clock. Do at least four across the four weeks. Trade sessions with a friend at your level and take the interviewer’s seat as well; watching someone else go quiet for five minutes shows you exactly how it looks from the other side. Use a plain shared editor without autocomplete at least once, record a session if you can, and ask your mock interviewer for one thing to keep and one thing to change.
The last 48 hours
- Learn nothing new. Re-solve five or six problems from your mistake log instead.
- Rehearse a 60 to 90 second introduction: your current role, one achievement and why this role.
- Re-read the job description and your own resume, since every line of the resume is fair game.
- For remote rounds, test the camera, microphone, editor and screen sharing, and keep a phone hotspot ready as a backup connection.
- For in-person rounds, confirm the address, the timings and the ID you need to carry.
- Prepare two or three questions for each interviewer about the team’s work.
- Sleep. Tired brains make the off-by-one errors that cost rounds.
Afterwards, write down every question you were asked while it is fresh and add the gaps to your mistake log. If a loop does not go your way, the guide to handling rejection shows how to work out which stage to fix.