You have solved 180 problems. Your streak is green for two months. Then the interviewer shares a document, reads out a question you have probably seen before, and says, "Talk me through how you'd approach it." Your mind goes quiet. You know the answer is somewhere in there, but every time you start a sentence it comes out half-formed, so you stop talking and start typing. Four minutes of silence later, the interviewer asks, "What are you thinking?" and you realise you have no idea how to say it.
That is not a knowledge problem. It is a training problem, and it is the most common way freshers lose coding rounds they were technically ready for.
The short answer
A coding interview tests two things at once: whether you can solve the problem, and whether you can explain your reasoning while you solve it. Practice sites train only the first, silently. Good coding interview preparation for freshers means picking one language, working through the core topics in priority order (arrays and strings first, dynamic programming last), and from the very first week saying your approach out loud before you write a line. Spend six weeks mixing solving with speaking, learn a fixed routine for working any problem in the room, and test your code yourself before the interviewer does.
The two halves of a coding round
Think of a live coding round as two separate skills sharing one clock.
The first half is solving: recognising the pattern, choosing a data structure, getting to a correct and reasonably efficient answer. This is what LeetCode-style practice trains, and it matters.
The second half is explaining while solving: stating your assumptions, describing a brute force before you optimise, naming the complexity, and narrating what you are doing as you code. Interviewers score this directly, because it is the only window they have into how you think. A correct answer reached in silence tells them almost nothing about whether you would be useful on a team. A partly correct answer reached with clear reasoning often scores better. We have written more about why in why knowing the answer isn't enough.
Here is the trap: grinding problems alone, silently, feels like full preparation. Your solved count goes up, you feel faster, and nothing tells you that the second skill has not moved at all. You only find out in the room.
Choose one language and stop switching
Pick one language and use it for every problem until the interview season is over. For most freshers that will be Java, C++ or Python, whichever you have written the most code in.
- Python is the fastest to write and the easiest to read aloud, which helps when you are narrating. Watch for hidden costs, such as slicing a list creating a copy.
- Java is verbose but explicit, and many Indian service and product companies are comfortable with it. Know your
HashMap,ArrayList,ArrayDequeandPriorityQueuecold. - C++ is quick in online assessments and the STL gives you everything you need. Be ready to explain what
unordered_mapandsetcost.
The reason to commit is simple: in the room you want zero thought going into syntax. If you have to stop and remember how to sort with a custom comparator, that is attention stolen from the problem and from your explanation. Learn your chosen language's standard library for the structures below so well that it disappears.
The core topics, in priority order
Freshers are asked a fairly predictable range of problems. Study these in order, because each one builds on the last and the early ones appear far more often. For a deeper look at the structures themselves, read the data structures you must know; here the focus is on what each topic is used for in an interview.
- Arrays and strings. The base of almost every fresher round: reversing, rotating, counting characters, finding duplicates, prefix sums. If you are weak here, nothing else will hold.
- Hashing. Hash maps and sets turn "search the whole array again" into a constant-time lookup. Used for frequency counts, finding pairs, detecting duplicates and grouping anagrams.
- Two pointers and sliding window. For sorted arrays, pair sums, removing duplicates in place, and "longest or shortest substring or subarray that satisfies a condition". Many brute-force O(n²) answers become O(n) with one of these.
- Recursion. Not a topic so much as a way of thinking you need for trees, backtracking and DP. Practise defining the base case and trusting the recursive call.
- Sorting and searching. Know how merge sort and quick sort work and what they cost, and know binary search well enough to apply it to "search on the answer" problems, not just sorted arrays.
- Linked lists. Reversal, finding the middle, detecting a cycle, merging two sorted lists. These test pointer handling and whether you check for null.
- Stacks and queues. Balanced brackets, next greater element, and anything that needs "the most recent unmatched thing". Queues lead straight into breadth-first search.
- Trees. Traversals (inorder, preorder, postorder, level order), height, checking whether a tree is a valid binary search tree, lowest common ancestor. Mostly recursion in disguise.
- Basic graphs. Representing a graph as an adjacency list, BFS and DFS, counting connected components, grids treated as graphs. Most fresher rounds stop here; product companies occasionally add topological sort or shortest paths.
- Introductory dynamic programming. Climbing stairs, coin change, longest common subsequence, 0/1 knapsack. Learn to spot overlapping subproblems and write the recursive version first, then memoise it.
If you are short on time, the first five topics cover a large share of online-assessment and first-round problems.
A six-week plan that mixes solving and speaking
This plan assumes about two to three hours a day alongside college or work. The rule that runs through all six weeks: for at least one problem every day, say your full approach out loud before you write code, as if someone were listening. Record yourself on your phone if you can. Listening back is uncomfortable and very effective.
Week 1: Arrays, strings and hashing
Solve three to four easy problems a day. Before each, say out loud what the input and output are, one example, and the brute force. After each, say the time and space complexity. This week is about building the habit more than the volume.
Week 2: Two pointers, sliding window, sorting and searching
Move to a mix of easy and medium problems. For every problem, explain the brute force first, then explain why the pattern makes it faster. Write binary search from memory at least five times until the boundary conditions stop scaring you.
Week 3: Recursion, linked lists, stacks and queues
Draw things. For linked lists and recursion, sketch the pointers or the call tree on paper while explaining. Practise narrating while you code: one short sentence per block, such as "now I move the slow pointer one step and the fast pointer two".
Week 4: Trees and basic graphs
Do all four traversals until they are automatic. Then solve grid and graph problems with BFS and DFS. End the week with your first full rehearsal: one medium problem, 30 minutes, timer running, talking the whole way through, with a friend or on your own recording.
Week 5: Introductory DP and mixed review
Two DP problems a day, always starting from the recursive solution. Spend the rest of the time on mixed problems from earlier weeks, chosen at random so you practise recognising the pattern rather than being told it.
Week 6: Rehearsals and weak spots
At least three timed rehearsals with a real listener, plus one or two online-assessment-style sets under exam conditions. Go back over the topics where you went silent or got stuck, and redo those problems out loud. Read up on what happens in a technical interview so the format holds no surprises.
How to work a problem in the room
Use the same routine every time, so that nerves have something to hold on to.
- Restate the problem in your own words, and ask about anything unclear: input size, whether values can be negative, whether the array is sorted, what to return if there is no answer.
- Work an example by hand, including one small edge case.
- Give the brute force and its complexity, even if you already see something better. It proves you understand the problem and gives you a fallback.
- Optimise, explaining what is wasteful about the brute force and which structure removes the waste.
- Code it, narrating each block briefly.
- Test it yourself by walking through your example and your edge cases line by line, before the interviewer asks.
Here is what that sounds like on a classic: "Given an array of integers and a target, return the indices of two numbers that add up to the target."
You restate it: "So I need two different positions whose values sum to the target. Can there be more than one valid pair, and can I use the same element twice?" The interviewer says return any one pair, and no, not the same element twice. You take [2, 7, 11, 15] with target 9 and note that the answer is indices 0 and 1.
Brute force: "I could check every pair with two loops. That's O(n²) time and O(1) space." Then the optimisation: "The waste is that for each number I'm searching the rest of the array for its partner. If I store each number I've seen in a hash map from value to index, then for each new number I just check whether target - num is already in the map. That's one pass, O(n) time, at the cost of O(n) space."
You code it, saying "I check the map before inserting the current number, so I never pair an element with itself." Then you test: the given example, an array where the pair includes a duplicate like [3, 3] with target 6, negative numbers, and an array with no valid pair, where you confirm what your code returns. That last step is the one most freshers skip, and it is the one interviewers notice.
If you get a problem you genuinely cannot crack, the routine still helps: restate, give a brute force, and say where you are stuck. Our guide on how to handle a question you don't know covers that situation in detail.
Online assessments are a different game
Many fresher hiring processes start with an online assessment (OA) on a testing platform before any human round. It rewards different things.
- Nobody hears your reasoning. Only passing test cases count, so speed and correctness are everything.
- Hidden test cases are harsh. Large inputs will expose an O(n²) solution, and edge cases like empty arrays or very large numbers will fail careless code. Check constraints before choosing an approach.
- Time pressure is fixed. Two or three problems in 60 to 90 minutes is common. Read all the problems first and start with the one you are surest of.
- Partial credit sometimes exists. If you cannot find the optimal answer, a correct brute force that passes some cases beats an empty submission.
Silent solving practice does prepare you well for OAs. The mistake is assuming that clearing the OA means you are ready for the live round. The live round is where the second half of the skill is tested, and it is where well-prepared candidates most often lose an offer they were technically ready for.
Mistakes that cost freshers the round
- Memorising solutions. You recognise the problem, type the answer from memory, and then cannot explain why it works when the interviewer changes one condition. Interviewers often tweak known problems for exactly this reason. Learn the pattern and the reasoning, not the code.
- Skipping complexity. If you do not state time and space complexity, the interviewer will ask, and hesitation here suggests you got the answer by luck. Say it for every solution, including the brute force.
- Thinking silently. Long silences leave the interviewer with nothing to score and no way to help you. Even "I'm considering whether sorting helps here" is better than nothing.
- Not testing your code. Saying "I think that works" and stopping is a missed chance. Walking through an edge case and catching your own bug often scores better than code that happened to be right first time.
- Jumping straight to code. Starting to type before you have agreed on an approach usually means rewriting halfway through, under pressure, with the clock running.
Putting it together
Coding interview preparation is not a race to a solved count. It is six weeks of building two skills side by side: solving problems, and explaining them clearly while you solve them. Most freshers only train the first. If you train both, you walk into the room with an advantage that does not show up on any practice-site profile.
The quickest way to find out whether your explaining has kept pace with your solving is to practise it out loud in a scored round. On 99interview you can take a round on the DSA track with Sia, an AI interviewer who asks one question at a time and follows up on what you actually said, then scores you with a written breakdown when you finish. Sia does not ask you to type code; it asks for your approach, data structure, complexity, edge cases and a dry run, which is exactly the explaining half of the skill. When you want a human read, a live 40-minute Zoom interview with a working engineer is scored the same way, on technical depth, problem solving, communication, behavioural and code quality. For the rest of your preparation beyond coding, start with the interview preparation guide for freshers.