Start Here: Your Roadmap from Zero to Job-Ready DSA

Most people start DSA by opening a coding site, picking a problem called something like "Longest Valid Parentheses", staring at it for forty minutes, and closing the tab feeling stupid. Then they try again the next week. After a month they conclude that they are "not a DSA person".

The problem was never the person. It was the order. Nobody told them that a hard problem is built from smaller ideas, and that those ideas can be learned one at a time.

This course is that order. It has 28 articles, it is free, it uses Java, and it assumes you are starting from the beginning. This first article explains what you are getting into, how to study, and the one habit that will carry you through the rest.

• What "data structures" and "algorithms" actually mean, in plain words.
• Why companies ask DSA questions, and what they are really checking.
• What this course covers and what you can honestly expect to be able to do afterwards.
• How to study each article so the knowledge sticks.
• A six-step loop that turns "I have no idea" into a plan.
• A progress checklist and a study routine you can follow with limited time.

A data structure is a way of organising data in memory so that certain operations are easy. An algorithm is a step-by-step procedure for solving a problem.

Everyday life is full of both. Think about how you keep your phone contacts. You could keep them in the order you added them, or alphabetically. Finding "Priya" in the first arrangement means scrolling through everyone. In the second, you can jump to the P section. The contacts are the same. The arrangement (the data structure) changed how quickly you can answer "where is Priya?".

Now think about the procedure you use to find her. "Start at the top and check every name" is an algorithm. "Open the middle, decide whether she comes before or after, and repeat on the correct half" is a different algorithm. Both are correct. One is much faster when you have 5,000 contacts.

So DSA comes down to two questions you will keep asking:

1. How should I store this data?
2. What steps should I follow to get the answer?

The skill is not memorising a hundred named techniques. It is learning to see which arrangement and which procedure fit a problem, and being able to explain why.

You may have heard that "nobody uses a red-black tree at work", and that is partly true. Most day-to-day programming is about reading requirements, calling libraries, and fixing bugs. So why do many interviews still include DSA?

Here is the honest answer, without the hype:

• It is a common, comparable test. Interviewers see many candidates. A problem with clear inputs and outputs lets them compare people fairly, especially freshers who have little work history.
• It shows how you think. Do you ask what the input looks like? Do you try a simple solution first? Can you notice that your solution is slow? Can you test your own code?
• It shows whether you can write careful code. Off-by-one mistakes, forgotten empty inputs and unhandled duplicates are the same mistakes that cause production bugs.
• It is a proxy for learning ability. Someone who can learn a new structure and apply it to a fresh problem will probably cope with a new framework too.

None of this means DSA is the only thing that matters. Projects, communication, fundamentals such as databases and operating systems, and attitude all count. But DSA is a skill you can improve with deliberate practice, and that is good news.

If you work through this course, here is a realistic picture of where you will be:

• You will understand the core data structures and when each one is a good choice.
• You will recognise common patterns such as two pointers, sliding window, recursion, BFS and basic dynamic programming.
• You will be able to read a problem, ask good questions, reason about its complexity and write clean Java for it.
• You will have a process for practising, revising and doing mock interviews.

And here is what this course cannot promise:

• It cannot promise a job. Hiring depends on openings, competition, your projects, your communication and a fair amount of timing.
• It cannot replace practice on problems beyond the exercises here. The exercises teach technique. Fluency comes from solving more problems on your own, and the study plan in Your 12-Week DSA Study and Revision Plan shows how.
• It does not cover every advanced topic. We mark clearly what is essential and what is optional.

The articles are in a deliberate order. Each one uses ideas from the ones before it.

You will notice recursion sits before trees. That is on purpose: tree code is naturally recursive, so it is easier if you have met recursion first.

• A computer where you can install the Java Development Kit (JDK). This course targets Java 17, a long-term support release, and the code also works on newer versions.
• A way to run Java. Any of these is fine: an IDE such as IntelliJ IDEA Community or VS Code with the Java extensions, or just a terminal with javac and java.
• Basic programming exposure. If you know what a variable and a loop are, you are ready. If not, Java Essentials for DSA covers what you need, and you can read it right after the next article.
• A notebook or a plain text file for dry runs. Tracing code by hand is the most useful habit in this course.

To check your setup, save the program below as Main.java, then run javac Main.java followed by java Main.

// File: Main.javapublic class Main {    // Returns the largest value in numbers. Assumes numbers has at least one element.    static int largest(int[] numbers) {        int best = numbers[0];        for (int i = 1; i < numbers.length; i++) {            if (numbers[i] > best) {                best = numbers[i];            }        }        return best;    }    public static void main(String[] args) {        System.out.println(largest(new int[] {7, 2, 9, 4}));        System.out.println(largest(new int[] {-5, -2, -8}));        System.out.println(largest(new int[] {42}));    }}

You should see this:

9-242

If you do, your setup works. Notice that the code ran in order from the first line of main, and that we used the first element as the starting "best so far". That small decision, starting from the first element instead of from 0, is why the second call correctly returns -2. If we had started best at 0, an array of negative numbers would wrongly return 0. Small decisions like this are what DSA is made of.

Here is the habit that matters most. Whenever you meet a problem, do these six things in order. Do not skip ahead to code.

1. Clarify. What is the input? What must the output be? What are the limits on size? What should happen for empty or odd inputs?
2. Example. Write one normal example and one tricky example, and work out the answers by hand.
3. Brute force. Describe the simplest correct approach, even if it is slow. This is your safety net.
4. Optimize. Ask where the brute force wastes work. Which data structure or pattern removes that waste?
5. Code. Translate the plan into Java, with clear names and small steps.
6. Test. Run your examples, then the edge cases. Trace the code by hand if something is off.

We will deepen each step over the next few articles. For now, watch the loop in action on a small problem.

1. Clarify. Input: an array of integers. Output: true if any value appears at least twice, otherwise false. An empty array or an array with one element has no duplicate, so the answer is false.
2. Example. [3, 1, 4, 1] has two 1s, so true. [3, 1, 4] is false.
3. Brute force. Compare every element with every element after it. If any pair is equal, return true.
4. Optimize. The brute force compares many pairs. What if we remembered each value we had already seen, and asked "have I seen this before?" for each new value? A structure that answers "have I seen this?" quickly is a HashSet. We study it properly in Hashing. For now, think of it as a bag that remembers values and can answer yes or no almost instantly.
5. Code. Both versions are below.
6. Test. Run both versions on the examples and on the empty array.

// File: Main.javaimport java.util.HashSet;import java.util.Set;public class Main {    // Brute force: compare every pair. Checks about n * (n - 1) / 2 pairs.    static boolean hasDuplicateBrute(int[] numbers) {        for (int i = 0; i < numbers.length; i++) {            for (int j = i + 1; j < numbers.length; j++) {                if (numbers[i] == numbers[j]) {                    return true;                }            }        }        return false;    }    // Optimized: remember what we have seen. One pass over the array.    static boolean hasDuplicateSet(int[] numbers) {        Set<Integer> seen = new HashSet<>();        for (int value : numbers) {            if (seen.contains(value)) {                return true;            }            seen.add(value);        }        return false;    }    public static void main(String[] args) {        int[][] tests = {{3, 1, 4, 1}, {3, 1, 4}, {}, {5}};        for (int[] test : tests) {            System.out.println(hasDuplicateBrute(test) + " " + hasDuplicateSet(test));        }    }}

true truefalse falsefalse falsefalse false

Both versions agree on every test, which is a good sign. If they ever disagreed, we would know one of them has a bug.

A dry run means following the code by hand and writing down the state after each step. For [3, 1, 4, 1]:

The loop stops at step 4, without looking at the rest of the array.

For an array of n values with no duplicate, the brute force does n * (n - 1) / 2 comparisons. The set version does about n look-ups. For n = 1000 that is 499,500 comparisons versus about 1,000 look-ups. For n = 100,000 the brute force needs almost five billion comparisons and will feel stuck, while the set version still finishes quickly. Time and Space Complexity Without the Confusion gives you the language to talk about this precisely. Note that the set version uses extra memory, so it trades space for time. Such trade-offs appear in almost every article.

Reading about code is not the same as learning to write it. Use this routine for each article:

1. Read once for the idea. Do not type anything yet. Aim to explain the idea to an imaginary friend.
2. Trace by hand. Follow the dry run on paper. Then change the input and trace again.
3. Type the code yourself. Do not copy and paste. Typing makes you notice details.
4. Break it on purpose. Give it an empty array, a negative number, a duplicate. See what happens.
5. Do the exercises before reading the solutions. Struggling for 15 to 20 minutes is where learning happens. If you are still stuck, read only the first line of the solution, then try again.
6. Revise. Come back after a day, a week and a month. The study plan article shows a simple schedule.

Each article ends with three to five exercises, in this rough order of difficulty:

• Trace exercises ask you to predict what code does. They build the habit of reading code carefully.
• Implementation exercises ask you to write a method.
• Debug exercises give you broken code and ask you to find the bug.
• Interview-style exercises are open problems where you apply the six-step loop.

Every exercise has a full solution in a collapsed section underneath, with the reasoning and the complexity, not just the answer. Open a solution only after a real attempt.

You do not need marathon sessions. Consistency beats intensity. A good default is 60 to 90 minutes a day, split like this:

If you only have 30 minutes on some days, do the Learn and Revise blocks and leave coding for the weekend. If you have a busy college semester or a full-time job, the plan in article 27 includes a lighter and an intensive version.

Copy this into your notes and tick items as you finish them. "Finished" means you read the article, traced the dry run, typed the code and attempted every exercise.

• 1. Start Here: Your Roadmap from Zero to Job-Ready DSA
• 2. Problem Solving Fundamentals
• 3. Java Essentials for DSA
• 4. Time and Space Complexity
• 5. Arrays
• 6. Strings
• 7. Linked Lists
• 8. Stacks and Queues
• 9. Hashing
• 10. Recursion and Backtracking
• 11. Trees and Binary Search Trees
• 12. Heaps and Priority Queues
• 13. Searching and Sorting
• 14. Two Pointers
• 15. Sliding Window
• 16. Prefix Sums and Difference Arrays
• 17. Greedy Algorithms and Intervals
• 18. Bit Manipulation and Mathematical Patterns
• 19. Graphs
• 20. Shortest Paths and Topological Sorting
• 21. Dynamic Programming Foundations
• 22. Dynamic Programming Practice
• 23. Tries
• 24. Range Queries and Disjoint Set Union
• 25. The Interview Problem-Solving Workflow
• 26. Build a DSA Practice Project
• 27. Your 12-Week Study and Revision Plan
• 28. Indian Fresher Placement and Coding Interview Preparation

Not every topic carries equal weight in interviews, and not every company asks the same things. As a rough guide for fresher roles:

• Core for almost everyone: arrays, strings, hashing, sorting and searching, linked lists, stacks and queues, recursion, basic trees, two pointers, sliding window.
• Common at product-focused companies: graphs, heaps, dynamic programming basics, binary search variations, greedy and interval problems.
• Useful but less common: tries, union-find, bit manipulation, segment trees and Fenwick trees.

We label optional material as optional when we get there. If you are short of time, protect the core list first.

• Jumping to code too early. Most wrong solutions come from solving a problem you did not fully understand.
• Looking at solutions too quickly. If you read the answer after five minutes, you practised reading, not solving.
• Collecting problems instead of understanding patterns. Fifty problems you understood are worth more than three hundred you skimmed.
• Skipping the dry run. If you cannot trace your code by hand, you cannot debug it under interview pressure.
• Comparing yourself to others. Someone else's "I solved it in ten minutes" skips the weeks of practice behind it.
• Never revisiting old problems. Without revision, you forget most of what you learn within weeks.

// File: Main.javapublic class Main {    static int countEven(int[] numbers) {        int count = 0;        for (int value : numbers) {            if (value % 2 == 0) {                count++;            }        }        return count;    }    public static void main(String[] args) {        System.out.println(countEven(new int[] {2, 7, 4, 9}));        System.out.println(countEven(new int[] {-4, 0, 3}));        System.out.println(countEven(new int[] {}));    }}

220

• Next: Problem Solving Fundamentals: From a Question to an Algorithm turns the six-step loop into a skill.
• If Java is new to you: continue to Java Essentials for DSA straight after.
• A shorter overview of learning DSA is in How to Learn Data Structures and Algorithms Without Burning Out.
• For the interview side, Software Interview Preparation: A 6-Week Plan That Actually Works covers more than DSA, and we come back to the interview process in articles 25 and 28.