Your 12-Week DSA Study and Revision Plan

Most study plans fail for the same reason: they were written by someone who imagined a version of you with unlimited energy. On day 1 you follow the schedule perfectly. By day 12 you are tired, behind and tempted to start over.

This plan tries not to do that. It assumes you have a college timetable or a job, that some weeks will be bad, and that you need slack. It will not promise you a job, because no plan can. What it can do is organise the 28 articles of this course into twelve weeks of steady work, with built-in revision, practice under time pressure, and rehearsal of the interview itself.

• A weekly rhythm you can sustain, with a daily session template.
• A week-by-week plan with goals and checkpoints.
• How to revise on a schedule and keep an error log.
• When to start timed sessions and mock interviews.
• A lighter and a more intensive version, and what to cut when time runs out.

1. Learn, implement, practise, revise. Reading is not learning. For every topic, read it, type the code, solve problems, and come back to it later.
2. Consistency beats intensity. An hour every day outperforms a ten-hour Sunday, because you forget less and the work stays fresh.
3. Revise early. Much forgetting happens within days. A small, scheduled review is much cheaper than relearning.
4. Practise like the real thing. From the middle of the plan, solve problems with a timer, on paper or in a plain editor, and explain aloud.
5. Keep slack. One session a week is for catching up, not for new material.
6. Track, then adjust. Review your progress at the end of weeks 2, 6 and 10, and change the plan if it is not working.

This assumes about 9 to 10 hours a week. It is a template, and you can shift the days around.

Some days are bad. Keep a floor so the habit survives: 10 minutes of revision, 15 minutes on one exercise, 5 minutes of notes. A 30-minute day does not break the plan. A skipped week might.

Article numbers refer to the articles in this course. "Implement" means typing and running the code yourself. "Practise" refers to the exercises at the end of each article, plus any extra problems you choose. The problem counts are suggestions, and understanding matters more than quantity.

• Week 5 is lighter on purpose. It has one new article and a review of weeks 1 to 4. Do not skip the review.
• Week 8 has three articles but each is shorter, and the bit-manipulation article is mostly optional depth.
• Week 10 is the hardest. If you need two weeks for dynamic programming, take them, and use the slack that you protected.
• Tries, Fenwick and segment trees are lower priority. If you run short of time, learn DSU and skim the rest.
• The project (article 26) runs alongside weeks 9 to 12, one milestone at a time.

You are far more likely to forget something in the first few days than later. So review it soon, then at growing gaps. A simple schedule: after 1, 3, 7, 14 and 30 days. This is the same schedule the practice project uses.

When you finish a topic or solve a problem, note the date. Then, on each review date, re-solve it from memory (not re-read it). If you can do it cleanly, move to the next gap. If you cannot, go back to the first gap.

The program below turns a study date into its review dates, and also spreads a number of articles across a number of weeks. You can use it to build your own pacing.

// File: Main.javaimport java.time.DayOfWeek;import java.time.LocalDate;import java.util.ArrayList;import java.util.Arrays;import java.util.List;public class Main {    static final int[] REVIEW_GAPS = {1, 3, 7, 14, 30};    static List<LocalDate> reviewDates(LocalDate studied) {        List<LocalDate> dates = new ArrayList<>();        for (int gap : REVIEW_GAPS) {            dates.add(studied.plusDays(gap));        }        return dates;    }    // Spreads totalItems over the given number of weeks as evenly as possible.    // The first (totalItems % weeks) weeks get one extra item, so nothing is lost.    static int[] weeklyLoad(int totalItems, int weeks) {        if (weeks <= 0) {            throw new IllegalArgumentException("weeks must be positive");        }        int[] load = new int[weeks];        int base = totalItems / weeks;        int extra = totalItems % weeks;        for (int w = 0; w < weeks; w++) {            load[w] = base + (w < extra ? 1 : 0);        }        return load;    }    // The Monday of week number weekNumber (1, 2, 3, ...), counting from the first Monday on or after start.    static LocalDate mondayOfWeek(LocalDate start, int weekNumber) {        LocalDate monday = start;        while (monday.getDayOfWeek() != DayOfWeek.MONDAY) {            monday = monday.plusDays(1);        }        return monday.plusWeeks(weekNumber - 1);    }    public static void main(String[] args) {        LocalDate studied = LocalDate.of(2026, 10, 12);        System.out.println("studied " + studied + " (" + studied.getDayOfWeek() + ")");        System.out.println("review on " + reviewDates(studied));        for (int weeks : new int[] {8, 12, 16, 20}) {            int[] load = weeklyLoad(28, weeks);            int total = 0;            for (int n : load) {                total += n;            }            System.out.println(weeks + " weeks: " + Arrays.toString(load) + " total " + total);        }        LocalDate start = LocalDate.of(2026, 10, 7);        System.out.println("week 1 starts " + mondayOfWeek(start, 1) + ", week 12 starts " + mondayOfWeek(start, 12));        System.out.println(Arrays.toString(weeklyLoad(0, 3)));    }}

studied 2026-10-12 (MONDAY)review on [2026-10-13, 2026-10-15, 2026-10-19, 2026-10-26, 2026-11-11]8 weeks: [4, 4, 4, 4, 3, 3, 3, 3] total 2812 weeks: [3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2] total 2816 weeks: [2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1] total 2820 weeks: [2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] total 28week 1 starts 2026-10-12, week 12 starts 2026-12-28[0, 0, 0]

The even spread is only a starting draft. Real plans are uneven: our 12-week plan puts four articles in week 1 (they are short), and one in week 5 (a review week). Take the draft, and then move articles around according to difficulty.

Keep one file or notebook with an entry for every mistake or confusion. It is the most valuable page you will own. A useful format:

Re-read it every Friday. Over weeks it becomes a personalised guide to the mistakes you actually make.

For each pattern (two pointers, sliding window, BFS, DP state), keep a card with: when it applies (signals in the problem), the template, a worked example, the edge cases, and a counterexample or trap. Write it in your own words. Writing it is the revision.

From week 6, add one timed problem a week:

• Set a timer for 45 minutes (shorter for easy problems).
• Use a plain editor or paper, with no autocomplete and no looking at solutions.
• Work through the workflow from article 25: clarify, example, brute force, optimise, code, test.
• At the end, score yourself with the self-review checklist. Did you test? Did you state the complexity?
• Whether or not you finish, spend 15 minutes comparing your approach with the solution, and write the lesson in your error log.

Timed practice builds a skill that untimed practice cannot: thinking clearly while the clock is running.

Start in week 8, and do one a week in weeks 10 to 12.

• Find a partner: a classmate, a colleague, or someone from an online community of learners. Take turns being the interviewer. Being the interviewer teaches you a lot.
• Or mock alone: read a problem, set a timer, and talk out loud as if someone were listening. Record yourself if you can bear it. You will notice filler words and long silences.
• Use a simple feedback form: Did I clarify first? Did I state a brute force? Was my code readable? Did I test? Was my complexity statement right? What one thing will I change next time?
• Treat each mock as information, not a verdict.

Good for a heavy college semester or a demanding job. Use the same weekly rhythm but with fewer sessions (for example, Tuesday, Thursday, Saturday, and a short Sunday review).

Only if you have the time, for example in a semester break. Compress the plan, and protect the revision and mocks more than the new material.

Do not go faster than your retention allows. Reading eight articles in a week and remembering none of them is worse than reading four.

If you cannot cover everything, protect the core in this order:

If you only have four weeks, do tier 1, practise out loud, and add a little of tier 2.

At the end of each module, answer these without looking:

• After week 4: Can I write an O(n) solution for a simple array problem, trace a linked list reversal, and say when to use a stack or a map?
• After week 8: Can I recognise two pointers, sliding window, prefix sums and greedy from a problem statement?
• After week 10: Can I model a graph problem, and write the six DP steps?
• After week 12: Can I run the full interview workflow on a new problem, in about 40 minutes, out loud?

A simple tracker is a table with the topic, date learned, number of problems, confidence from 1 to 5, and next review. Update it each Sunday.

The helper functions are tiny. reviewDates is O(1) (five dates), weeklyLoad is O(weeks), and mondayOfWeek is O(7) at most for the initial search. The more important lesson is in weeklyLoad: using totalItems / weeks alone would lose the remainder, and the exercise below asks you to find that bug. Whenever you divide, ask what happens to the remainder.

• Starting too hard. A plan you can follow at 70% is better than one you abandon in week 3.
• Collecting resources instead of working. One course (this one), one language, one set of notes.
• Skipping revision because new topics feel more productive.
• Never practising under time pressure, then freezing in the real thing.
• Doubling up to catch up. It creates overload. Drop optional items instead.
• Comparing your week 3 with someone else's week 12. Compare yourself with last month's you.
• Ignoring the error log. The mistakes you repeat are the ones to fix first.
• Practising only the topics you enjoy. Make a rule that every week includes one thing you find uncomfortable.
• Treating the plan as a promise. It is a scaffold. Adjust it after each review.
• Neglecting health. Sleep, food and movement are part of preparation. A tired brain solves problems badly.

static int[] weeklyLoadBuggy(int totalItems, int weeks) {    int[] load = new int[weeks];    for (int w = 0; w < weeks; w++) {        load[w] = totalItems / weeks;    }    return load;}

// File: Main.javaimport java.time.LocalDate;public class Main {    public static void main(String[] args) {        LocalDate studied = LocalDate.of(2026, 10, 12);        int[] gaps = {1, 3, 7, 14, 30};        for (int gap : gaps) {            LocalDate date = studied.plusDays(gap);            System.out.println("+" + gap + ": " + date + " " + date.getDayOfWeek());        }    }}

+1: 2026-10-13 TUESDAY+3: 2026-10-15 THURSDAY+7: 2026-10-19 MONDAY+14: 2026-10-26 MONDAY+30: 2026-11-11 WEDNESDAY

// File: Main.javaimport java.util.Arrays;public class Main {    static int[] weeklyLoad(int totalItems, int weeks) {        if (weeks <= 0) {            throw new IllegalArgumentException("weeks must be positive");        }        int[] load = new int[weeks];        int base = totalItems / weeks;        int extra = totalItems % weeks;        for (int w = 0; w < weeks; w++) {            load[w] = base + (w < extra ? 1 : 0);        }        return load;    }    static int sum(int[] values) {        int total = 0;        for (int v : values) {            total += v;        }        return total;    }    public static void main(String[] args) {        int[] twelve = weeklyLoad(28, 12);        int[] sixteen = weeklyLoad(28, 16);        System.out.println(Arrays.toString(twelve) + " " + sum(twelve));        System.out.println(Arrays.toString(sixteen) + " " + sum(sixteen));        System.out.println(Arrays.toString(weeklyLoad(5, 8)) + " " + sum(weeklyLoad(5, 8)));    }}

[3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2] 28[2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1] 28[1, 1, 1, 1, 1, 0, 0, 0] 5

// File: Main.javaimport java.util.Arrays;public class Main {    static int[] weeklyLoadBuggy(int totalItems, int weeks) {        int[] load = new int[weeks];        for (int w = 0; w < weeks; w++) {            load[w] = totalItems / weeks;        }        return load;    }    static int[] weeklyLoadFixed(int totalItems, int weeks) {        int[] load = new int[weeks];        int extra = totalItems % weeks;        for (int w = 0; w < weeks; w++) {            load[w] = totalItems / weeks + (w < extra ? 1 : 0);        }        return load;    }    public static void main(String[] args) {        int buggyTotal = Arrays.stream(weeklyLoadBuggy(28, 12)).sum();        int fixedTotal = Arrays.stream(weeklyLoadFixed(28, 12)).sum();        System.out.println("buggy covers " + buggyTotal + " articles, fixed covers " + fixedTotal);    }}

buggy covers 24 articles, fixed covers 28

• Next: Indian Fresher Placement and Coding Interview Preparation covers aptitude and online assessments, technical interviews and project discussions.
• Related: How to Learn Data Structures and Algorithms Without Burning Out is a shorter overview of studying DSA, and Spaced Repetition: Remember What You Study Without Re-reading It goes deeper into the revision idea. Software Interview Preparation: A 6-Week Plan That Actually Works covers other interview topics next to DSA.
• Practice habit: at the end of every Sunday, write three lines: what went well, what slipped, and the one change for next week.