Software Interview Preparation: A 6-Week Plan That Actually Works

Divya had solved 300 problems on a coding platform and still froze in her first interview. The question was a mix of two things she'd practised separately, and she'd never said her thoughts out loud before.

Interview preparation fails in predictable ways: random problem hunting, no revision, no speaking practice. This plan fixes those. It assumes about 1.5 to 2 hours on weekdays and 3 to 4 hours on weekends, so roughly 15 hours a week.

Different companies vary, but most software interviews contain some of these rounds:

1. Online assessment: coding problems under a timer.
2. Coding rounds: data structures and algorithms in a shared editor or on a whiteboard.
3. Fundamentals: operating systems, databases, networking, language details, depending on role.
4. System or low-level design: more common from around 2+ years of experience, and at some companies for freshers too (basic design).
5. Behavioural / hiring manager round: your projects, decisions and how you work with people.

Find out the format for the companies you target. Ask the recruiter. It changes how you split your time.

• Pick one language and stay with it. Python, Java and C++ are all fine. Know its standard library for lists, maps, sets, heaps and sorting.
• Choose one practice platform and one list of problems. Don't keep switching.
• Keep a log. For every problem, record the pattern, the key idea and what you got wrong. You'll revise this log.
• Set a fixed daily slot, even if short.

• Revise time and space complexity (Big-O).
• Arrays, strings, hash maps and sets.
• Patterns: two pointers, sliding window, prefix sums, frequency counting.
• Solve 15 to 20 problems, mostly easy and some medium.

Goal: solve a standard easy problem in under 15 minutes and explain its complexity.

• Linked lists, stacks, queues.
• Binary search, including "search on the answer".
• Sorting and its use in problems.
• Solve 20 problems.

• Binary trees: traversal, depth, lowest common ancestor.
• Binary search trees.
• Graph basics: BFS, DFS, connected components, simple shortest paths.
• Recursion and backtracking (subsets, permutations).
• Solve 20 to 25 problems.

• Heaps and priority queues (top K elements).
• Introductory dynamic programming: climbing stairs, knapsack, longest common subsequence, coin change.
• A way to learn DP: write the brute-force recursion first, then add memoisation, then convert to a table.
• Solve 15 to 20 problems. Medium difficulty only after you're comfortable.

Split your time between two things:

• Fundamentals: processes and threads, memory, SQL joins and indexes, REST, HTTP, caching, basic OOP and SOLID. Be ready to explain things from your own projects. If you want a refresher on APIs, read what is an API.
• Design: for freshers, practise designing a small system (URL shortener, parking lot, to-do app) with classes and a simple database schema. For experienced candidates, learn the basics of system design: load balancers, caches, databases, queues, trade-offs.

Keep solving two or three coding problems a day, so your speed doesn't fade.

• Do at least four mock interviews, with a friend, a mentor or an online mock platform.
• Write and rehearse behavioural stories (see below).
• Re-do problems from your log that you got wrong.
• Review your resume line by line, because interviewers ask about every claim. Read how to build a resume that gets shortlisted if it needs work.

Use the same routine every time. It becomes a habit you carry into the interview.

1. Read it twice. Restate it in your own words.
2. Ask questions. Input size, edge cases, duplicates, negative numbers, empty input.
3. Work an example by hand.
4. Say the brute-force approach and its complexity.
5. Improve it. Which pattern fits? What is repeated?
6. Write the code cleanly, with sensible names.
7. Test it with an example and an edge case, out loud.
8. State the complexity.

If you're stuck for more than 30 to 40 minutes, read the solution, then close it and write the code from memory the next day. Struggling for hours without learning is not preparation.

For debugging your own code during practice, the process in how to debug any bug helps.

Interviewers can't read your mind. A silent candidate who writes the right answer may score lower than one who explains a slightly flawed approach clearly.

Practise saying:

• "I'll start with a brute-force approach to check my understanding."
• "The bottleneck is this nested loop. A hash map could make lookups constant time."
• "Let me test this on an empty array."

If you get stuck, say what you're considering. Interviewers often give hints to people who show their reasoning.

Prepare 5 to 6 real stories you can adapt. Use the STAR shape: Situation, Task, Action, Result. Cover:

• A time you solved a hard technical problem
• A disagreement with a teammate and how you resolved it
• A mistake you made and what you learnt
• A project you're proud of and your exact role
• A time you took initiative or learned something fast
• A time you missed a deadline or had to cut scope

Use "I" for your own actions, and give specifics and numbers where you honestly can. Never invent stories. Interviewers probe, and a made-up story falls apart on the second question.

Prepare two or three good ones:

• "What does success look like in the first six months?"
• "How does the team handle code review and releases?"
• "What's the hardest technical problem the team is working on?"

• Counting problems solved instead of patterns learned.
• Never practising with a timer or without the editor's autocomplete.
• Skipping fundamentals because they feel "non-interview". Many rounds are about them.
• Not reviewing past mistakes.
• Applying to everything at once. Apply to two or three practice companies first, and treat the early interviews as part of preparation.
• Burning out. Rest one day a week. Consistent beats intense.

Write down the questions you were asked while you remember them. Note what went well and what didn't. This log becomes valuable for the next round. If you get an offer, see salary negotiation in India and CTC vs in-hand salary.

There's no magic number. Many people do well after 150 to 250 well-understood problems covering the main patterns. Understanding matters more than count.

The one you know best. Python is short to write and good for interviews. Java and C++ are fine. Don't pick a language just because it's fashionable.

Almost everyone does, repeatedly. Write down what went wrong, fix it and move on. A rejection is information, not a verdict.

Most fresher rounds focus on data structures, fundamentals and projects, with occasional small design questions. Check the company's format.

Three to four months before the main interview season is comfortable. If you have less, compress the plan and focus on the highest-frequency patterns.

Interview formats differ between companies. Use this plan as a base and adjust to each company's process.