Updated: 16 October 2026. Preparing for an off-campus coding assessment or a fresher software engineering interview? This 30-day DSA roadmap for freshers helps you practise consistently without chasing hundreds of random problems. It covers arrays, strings, hash maps, searching, sorting, recursion, stacks, linked lists, trees, graphs and introductory dynamic programming. The plan is a learning schedule, not a guarantee that a company’s assessment will follow these topics.
Before starting the 30-day DSA roadmap
- Pick one primary language: Java, C++ or Python. Use the language allowed by your target assessments.
- Study time: aim for approximately 60–90 minutes on most days and adjust based on your available time.
- Daily pattern: 15 minutes learning a pattern, 35–50 minutes coding, 10–20 minutes reviewing failures.
- Keep evidence: record the problem name, approach, complexity, missed edge case and review date.
- Be truthful: count solved problems only if you can explain your own implementation.
Which topics should beginners prioritize?
| Priority | Topics | Reason |
|---|---|---|
| High | Arrays, strings, hashing, two pointers, binary search | Builds common logic and coding foundations |
| High | Basic sorting, sliding windows, stacks | Introduces reusable patterns |
| Medium | Linked lists and trees | Improves pointer/reference and recursive thinking |
| Medium | BFS, DFS and beginner dynamic programming | Useful for broader assessments and interview discussion |
| Context-dependent | Advanced graphs, tries, segment trees | Study later if your target role or assessment calls for them |
Complete 30-day DSA study plan
Week 1: arrays, strings and complexity
| Day | Concept and task | What to verify |
|---|---|---|
| 1 | Big-O notation; count basic operations | Two linear scans; explain O(n) time and O(1) extra space |
| 2 | Arrays: min, max and second-largest distinct | Three edge cases: empty, all equal, negatives |
| 3 | Reverse array; rotate by k | Compare additional-array and in-place approaches |
| 4 | Two pointers: sorted pair sum | Explain why sorting or already-sorted input matters |
| 5 | Strings: palindrome and frequency counting | Ignore punctuation only when the specification permits |
| 6 | Hash maps: first non-repeating character | Test duplicates and mixed-case rules |
| 7 | Review and mock test | Solve three problems without notes, then explain each |
Week 2: searching, sorting and recursion
| Day | Concept and task | What to verify |
|---|---|---|
| 8 | Linear search vs binary search | State binary search’s sorted-input requirement |
| 9 | Lower bound and insertion position | Test absent target and repeated values |
| 10 | Selection, insertion and merge sort concepts | Compare O(n²) and O(n log n) behavior |
| 11 | Two-pointer deduplication in sorted array | Distinguish in-place prefix from backing array length |
| 12 | Sliding window: fixed-length maximum sum | Handle window larger than array |
| 13 | Recursion: factorial and sum | Write base case and account for call stack |
| 14 | Timed review | Summarize solutions in a GitHub progress log |
Week 3: stacks, linked lists and trees
| Day | Concept and task | What to verify |
|---|---|---|
| 15 | Stack: balanced parentheses | Test empty, nested and invalid order |
| 16 | Queue: basic operations | Explain FIFO and implementation trade-offs |
| 17 | Singly linked list: insert and traversal | Explain null head and pointer updates |
| 18 | Reverse a linked list | Trace prev/current/next by hand |
| 19 | Tree traversals | Explain preorder, inorder and postorder |
| 20 | Binary search tree search | Compare balanced vs skewed behavior |
| 21 | Review test | Mix stack, list and tree problems |
Week 4: graphs, patterns and interviews
| Day | Concept and task | What to verify |
|---|---|---|
| 22 | Hash map: two-sum indices | Discuss duplicate and no-solution cases |
| 23 | Intervals: merge overlapping ranges | Explain need to sort by start |
| 24 | Grid BFS basics | Avoid revisiting nodes; define neighbors |
| 25 | DFS basics | Discuss recursion depth vs explicit stack |
| 26 | Dynamic programming: climbing stairs | Derive recurrence before writing code |
| 27 | DP: coin-change count or min coins | Explain state and impossible cases |
| 28 | Mock coding interview 1 | Think aloud and measure complexity |
| 29 | Mock coding interview 2 | Solve under time limit; document errors |
| 30 | Final review and applications | Present 3 strongest solutions and portfolio |
How to solve a coding question in interviews
- Clarify: ask about input size, sorting assumptions, duplicates, empty input and expected output.
- Start with a baseline: describe a simple correct method before optimizing.
- Identify the pattern: consider two pointers, hashing, a window, a stack or traversal only when its assumptions fit.
- Write readable code: name variables meaningfully and avoid cleverness that hides correctness.
- Test manually: try normal, empty, one-element, duplicate and boundary cases.
- Analyze: state time and extra-space complexity, including recursion stack when relevant.
Worked example: Two Sum using a hash map
Problem: Given an integer array and a target sum, return the indices of two different elements whose sum equals the target, or indicate that no such pair exists. Example input: numbers = [2, 7, 11, 15], target 9; output [0, 1]. This familiar exercise introduces complement lookup.
import java.util.HashMap;
import java.util.Map;
public class TwoSumExample {
static int[] twoSum(int[] numbers, int target) {
Map<Integer, Integer> seen = new HashMap<>();
for (int i = 0; i < numbers.length; i++) {
int needed = target - numbers[i];
if (seen.containsKey(needed)) {
return new int[]{seen.get(needed), i};
}
seen.put(numbers[i], i);
}
return new int[]{-1, -1};
}
}Explanation: keep a map of previously seen values and their indices. For each new element, check whether its complement has already appeared. Looking up before inserting the current element prevents using the same index twice. Under typical hash-map assumptions, average time is O(n) and additional space is O(n). Collision-heavy worst cases and integer overflow in target - numbers[i] are implementation considerations; interviewers may ask about them.
Three practice variations and edge cases
| Variation | Check |
|---|---|
| No matching pair | Return the agreed sentinel or follow the problem’s contract |
| Duplicate values | Input [3,3], target 6 should use indices 0 and 1 |
| Negative numbers | Input [-4,2,7], target 3 pairs -4 and 7 |
How to track real progress
Use a small log in a notebook, spreadsheet or GitHub README. A good progress record includes date, concept, problem, initial approach, improved approach, time complexity, space complexity and one thing to revise. Example: “Day 12 — fixed-length sliding window — forgot to subtract the outgoing element — retry on Day 15.” Avoid uploading copied question statements or other people’s solutions where licensing prohibits it.
Plan for different starting levels
- Complete beginner: extend the schedule to 45–60 days if basic loops, functions and arrays are still challenging.
- Comfortable programmer: use the 30 days as a pattern-review plan; spend additional time on timed mixed questions.
- Interview approaching soon: prioritize arrays, strings, hashing, binary search and explanation quality, then study company-specific requirements from official sources.
Where to practise coding questions
Choose a reputable platform that lets you code and run tests, such as LeetCode, HackerRank algorithms or GeeksforGeeks DSA tutorial. Platform questions, coverage and access conditions can change. This roadmap does not imply endorsement or official affiliation.
Frequently asked questions
Is 30 days enough to master DSA?
No. Thirty days can establish a consistent foundation or refresh basics; deeper mastery requires repeated practice, error analysis and more complex problems over time.
Which programming language is best for DSA?
Use one language you can explain confidently and that your target company’s coding platform supports. Java, C++ and Python are common options; changing languages every week may slow progress.
How many problems should I solve daily?
A practical starting point is one or two carefully reviewed problems. Understanding and explaining one solution well can be more valuable than completing several through hints alone.
What if I miss a day?
Resume from the next unfinished lesson and keep the review days. Compressing four difficult topics into one evening can reduce retention.
Related Hiring365 resources
Continue with our Java Spring Boot portfolio project, SQL practice questions, GitHub portfolio guide, and job-description checklist.
Editorial note: Hiring365 created this original practice schedule for educational use. It is not an official test syllabus of TCS, Cognizant, Accenture or any other employer. Assessment patterns and supported languages should be confirmed through the employer’s current instructions.
