Your DSA syllabus had AVL trees, B-trees, red-black trees, Fibonacci heaps, and something about splay trees that you never fully understood. You passed the exam. Then the placement season started, you opened a list of "top 100 interview problems", and almost none of those showed up. Instead it was arrays, again and again, hash maps, a stack problem about brackets, a linked list to reverse, a tree to traverse.
It is a strange feeling: the hard things you studied are not being asked, and the simple things you skipped past are being asked in ways you cannot immediately solve.
The short answer
Coding rounds for freshers, whether in a campus drive, an off-campus assessment or a product company's first technical round, draw overwhelmingly on seven structures: arrays and strings, hash maps and sets, stacks and queues, linked lists, trees, heaps, and graphs. Topic-wise question lists such as GeeksforGeeks' top 100 show the same clusters. The winning strategy is not to cover everything you were taught. It is to go deep on these seven: know how each works, when to reach for it, the time complexity of its common operations, and at least one classic problem you have solved while explaining your reasoning aloud. Then learn to recognise which structure a new problem is asking for. Depth and recognition, not coverage.
Why coverage fails and depth works
The interviewer is not testing whether you have seen the problem before. She is testing whether you can look at a problem you have not seen, say which structure fits and why, and then implement it while explaining yourself. A candidate who has memorised solutions to four hundred problems gets stuck the moment the problem is slightly different. A candidate who deeply understands seven structures can reason toward a solution they have never seen.
For the theory behind each structure, Introduction to Algorithms by Cormen, Leiserson, Rivest and Stein is still the reference most courses use, and the Big-O cheat sheet is the one-page summary of complexities worth having open while you practise. Neither is the skill. Solving problems while talking is.
Arrays and strings
Arrays are the foundation, and in most interview languages strings behave like arrays of characters. Know that indexing is constant time, searching an unsorted array is linear, and inserting or deleting in the middle is linear because everything after the point has to shift. Know what a sorted array buys you: binary search in logarithmic time, and the two-pointer technique for problems about pairs and ranges.
The patterns that recur are two pointers, sliding window and prefix sums, and between them they cover a very large share of first-round online assessment problems. Practise removing duplicates from a sorted array, finding the maximum subarray sum, and the longest substring without repeating characters. Each time, say the complexity before you code, and say why the obvious nested loop is the first idea and what replaces it.
Hash maps and sets
The hash map is what turns quadratic solutions into linear ones, and interviewers expect you to reach for it instinctively. Understand that insertion, lookup and deletion are constant time on average, why they degrade under heavy collisions, and what happens when the map has to grow. Know when a set is the honest choice because you only care whether something has been seen.
Two Sum is the canonical problem. The nested loop compares every pair in quadratic time; a single pass with a map of values seen so far does it in linear time. Follow it with grouping anagrams and finding the first non-repeating character in a string. In an interview, the moment you say "I need fast lookup, so a hash map" is a moment the interviewer notes.
Stacks and queues
Both are simple and both hide a large family of problems. A stack is last in, first out; a queue is first in, first out; each has constant-time push and pop.
Stacks appear wherever there is nesting or a need to return to the most recent unresolved thing: matching brackets, evaluating expressions, undo history, and the call stack itself, which is why recursion and stacks are the same idea in different clothes. Valid Parentheses is the classic problem. The monotonic stack, used in next-greater-element and daily-temperatures problems, is the step up that product companies like.
Queues appear wherever arrival order matters: scheduling, buffering, and above all breadth-first search, which is a queue plus a visited set and nothing else. If you can explain why BFS needs a queue and DFS needs a stack, you understand both structures.
Linked lists
Less common than a decade ago but still asked, especially by service companies, because they test whether you can manipulate pointers without losing your place. Know that insertion and deletion at a known position are constant time, that indexing is linear, and that a singly linked list has no way back.
The classic problems are reversing a list, detecting a cycle with the fast and slow pointer technique, and merging two sorted lists. Draw the pointers on paper when you practise. Interviewers who ask these want to see you reason carefully about the next pointer, not recite a memorised solution.
Trees
Trees model hierarchy and are where recursion stops being optional. Start with the binary tree and its three depth-first traversals, in-order, pre-order and post-order, plus the breadth-first level-order traversal. Then the binary search tree: the ordering rule, why search and insert are logarithmic when the tree is balanced, and why they collapse to linear when it is not. You will almost never implement a self-balancing tree in a fresher interview, but you should be able to say in one sentence why they exist; that is what your AVL lectures were for.
Practise finding the maximum depth, checking whether a tree is a valid BST, and finding the lowest common ancestor. Each is a small recursive function, and the interview is really about whether you can state the recursive case and the base case cleanly, out loud.
Heaps
A heap is the structure for repeatedly getting the smallest or largest element: constant-time peek, logarithmic insert and remove. Its shape, a complete binary tree stored in an array, is worth understanding because the parent-child index arithmetic is a common follow-up.
The heap pattern is "top K" and "merge K": the Kth largest element, the K most frequent words, merging K sorted lists. Recognising that a problem is a top-K problem, and that a heap of size K beats sorting everything, is exactly the pattern recognition interviewers are probing.
Graphs
Graphs feel intimidating and are mostly two traversals applied to different questions. Know the two representations, adjacency list and adjacency matrix, and when each fits. Know BFS for shortest paths in unweighted graphs and for level-by-level exploration, DFS for connectivity, cycle detection and topological ordering, and that both are linear in vertices plus edges.
Practise counting islands in a grid, which is DFS or BFS over an implicit graph, course scheduling, which is topological sort, and cloning a graph, which is traversal plus a visited map. If you have time, understand Dijkstra's algorithm for weighted shortest paths; it is BFS with a heap in place of the queue and ties three of these structures together.
Recognising the pattern under pressure
Knowing the structures is necessary and not sufficient. The interview skill is looking at an unfamiliar problem and asking, quickly and aloud: which structure fits, why, and what does that make the complexity? Some signals to train yourself on. Fast lookup, counting, or "have I seen this before" points at a hash map or set. Nesting, matching, or "most recent first" points at a stack. Arrival order or level-by-level exploration points at a queue. Repeatedly taking the smallest or largest points at a heap. Hierarchy points at a tree. Relationships between many items, or a grid to explore, points at a graph. Sorted input, or a question about a contiguous range, points at two pointers or a sliding window over an array.
Say the signal out loud in the interview. "This is asking for the K largest, so I am thinking of a heap of size K rather than sorting everything." That one sentence tells the interviewer more than ten minutes of silent coding.
A practice routine that builds depth
Volume is the wrong goal, and this is the hardest thing to convince a fresher of during placement season, when everyone is comparing problem counts. A candidate who has solved four hundred problems silently is regularly outperformed by one who has solved sixty aloud and reviewed each.
For each of the seven structures, solve two or three representative problems, speaking your reasoning as you go, with a timer running. Before writing code, state the approach and its complexity in one sentence. After solving, ask what variant an interviewer might pose next and sketch the change. A week later, revisit the problem cold, without notes. If it is not fluent, it is not learned yet. Problem sources matter less than the method; LeetCode and curated lists like NeetCode both organise problems by structure, which suits this routine.
Then test it under interview conditions, because solving alone and solving while someone watches are different skills. A friend who asks "why that complexity?" and "what about an empty input?" is ideal. If you do not have one, the DSA practice track on 99Interview puts you in front of a problem with a clock and an interviewer who asks about your complexity claims and your edge cases, either an AI interviewer that scores the transcript or a live mock interview with a working engineer who writes up feedback including on your code; the details are on the pricing page. If you are on a short runway, the two-week plan schedules these seven structures across four days.
Frequently asked questions
Which data structures are most asked in interviews for freshers?
Arrays and strings first, then hash maps, stacks and queues, linked lists and trees. Heaps and graphs appear more at product companies. Advanced structures from the syllabus, like AVL or B-trees, are almost never implemented in a fresher interview.
How many DSA problems should I solve for placements?
Fewer than you think, solved properly. Two or three per structure, solved aloud and revisited a week later, is around sixty problems and is enough for most fresher rounds. Four hundred problems solved silently and never reviewed is not.
How do I identify which data structure to use in a problem?
Look for the signal in the question. Fast lookup means hash map; nesting or "most recent" means stack; order of arrival means queue; smallest or largest repeatedly means heap; hierarchy means tree; connections or a grid means graph. Say the signal aloud before you code.
Is DSA required for service company placements?
Usually at a basic level: arrays, strings, linked lists, simple sorting and searching, and the ability to explain time complexity. The deep tree, heap and graph problems are more typical of product companies. Check the pattern of previous years' questions for your target company.
How long does it take to prepare DSA for interviews?
If you know the basics from college, a focused four to six weeks of pattern practice and mock rounds is realistic. Starting from nothing, most people need two to three months of consistent daily practice.
Should I learn DSA in Python, Java or C++ for interviews?
Whichever you can write fluently without looking things up. Interviewers care about your reasoning, not the language. Most Indian companies accept any mainstream language; some service companies specify Java or C, so check the job posting.
Start with one structure tonight
Pick the structure you are least comfortable with from the seven. Solve one classic problem for it aloud, with a timer, and state the complexity before you write a line.
Seven structures, understood deeply, cover most of what a fresher's coding round will ask. Which one would you struggle to explain out loud right now?