How to use Algoz

Summary

Go chapter by chapter, read each note from basics to expert, run its code, and then prove it on the sheets.

The idea in real life

Why it exists

1. Solving random problems without an ordered curriculum creates hidden knowledge gaps and wastes time when you get stuck on topics you have not learned yet.
2. Many resources stop at basic definitions or provide code without explaining the trade-offs, internal mechanics, or edge cases that interviewers probe.
3. Reading solutions passively feels like learning, but without structured practice and deliberate review, the techniques vanish under interview pressure.
4. Algoz organizes the full syllabus into an ordered weekly plan, covers every topic from basics to expert depth, and pairs each note directly with verified practice.

How it works

The one-year plan

Fifty chapters arranged over fifty-two weeks build skills in order.

The curriculum spans one full year across 52 weeks and 50 chapters, numbered from 00 to 49, followed by an appendix. In What DSA is, the curriculum map showed how these chapters are organized into nine sequential parts, beginning with Java foundations and finishing with interview preparation.

Every chapter row in the curriculum has a suggested week range. The topics are arranged so that each idea rests directly on the ones before it. Arrays and strings teach index manipulation; stacks, queues, and linked lists introduce reference handling; and these linear structures lay the groundwork for trees, graphs, and dynamic programming.

On your first pass through the course, follow the chapters in order. Jumping ahead to advanced topics before finishing earlier structures leaves holes in your fundamentals that make later algorithms harder to follow. The appendix covers topics beyond DSA, such as concurrency and JVM internals, which you can read at any time when preparing for Java-focused engineering interviews.

The parts of a note

Every note follows the same structure so you know what comes next.

Every note on Algoz covers exactly one topic. A note never combines separate topics into one long article, and it never leaves a topic half-explained.

At the very top of each page, the note head provides immediate context. It displays the chapter and note number, the topic title, a short summary deck, and an estimated reading time. Beneath the title sits a facts strip:

• Builds on: links the prerequisite note you should read first.
• You'll gain: states the primary technique or insight the note teaches.
• Cost: lists the time and extra space complexity when the note introduces an algorithm or data structure.
• Practice: shows the count of verified coding problems tied to this note.

The body of each note follows a predictable structure from start to finish:

When you study a note for the first time, you can focus on the basics in "How it works", run the Java code, and solve the core problems. When you return for revision, you can dive straight into "Going deeper" and "Under the hood" to study the deeper mechanics.

Reading a note

Step through the figures and run the code as you read.

Visualizing how an algorithm changes data in memory is often clearer than reading paragraphs of text. Step-by-step figures on Algoz never play automatically, so you are never rushed. You move through it with the ◀ (previous) and ▶ (next) buttons. Clicking ↻ restarts the figure at step 1. Where a figure includes custom inputs, choosing a new input immediately restarts the demonstration from step 1 with the new data. A caption below the figure describes what happens at each individual step.

Code blocks on the site are practical and complete. Every Java program compiles and runs on JDK 17 or newer, and the output shown under it is the real output of that program. Each code block has a COPY button in the header.

While copying code is convenient, you should type the programs into your own editor by hand whenever possible. Typing forces you to notice variable types, boundary conditions, and loop increments. It also builds the muscle memory needed when writing code on a whiteboard or in a plain browser editor during interviews.

The two sheets

Real interview problems and theory questions turn reading into lasting skill.

Reading explanations and watching animations is only the beginning of preparation. To build real problem-solving skill, every note connects directly to two companion sheets:

• The Practice Sheet: coding problems grouped by chapter and pattern. Each problem links directly to its LeetCode or GeeksforGeeks page. Every problem is assigned a tier: core (essential problems that teach the base pattern), extended (additional problems that show variations), or expert (the hardest problems for that pattern).
• The Interview Sheet: theory questions with model answers you can say out loud in a round. These cover the architectural and JVM questions that interviewers ask aloud, such as how hash collisions are handled or how memory is allocated.

Both sheets list only questions that are known to be asked in real rounds. At the end of every note, a dedicated card opens both sheets filtered to the problems and theory questions belonging to that specific note. Each row includes a checkbox to track whether you have solved or reviewed it, and a star to flag problems you want to revisit later.

Going deeper

A study routine for one note

Work in three clear steps: understand the idea, build it, and practice.

To get the most out of each note, follow a consistent three-phase routine:

1. Understand the mechanism: read the summary, the analogy, and the "How it works" section. Focus on the core trade-off: what problem does this data structure or algorithm solve, and why is it faster than the naive approach?
2. Trace and build: step through the figure slowly to see how indices and pointers move. Then open your local editor, type the Java code by hand, and run it. Check that the output matches the note, and try modifying an input array to see how the output changes.
3. Practice on the sheet: click through to the Practice Sheet for the note. Solve the core problems first without consulting hints or discussion forums. Give each problem an honest attempt before checking solutions. Finally, read the Traps section to review mistakes before moving to the next note.

A week in the plan

Balance your week between reading new notes and solving sheet problems.

Most chapters in the 52-week plan take one or two weeks; a few short ones share a week. Rather than cramming an entire chapter into a single weekend, distribute your work evenly across the week.

Start the week by reading the assigned concept and pattern notes for the chapter. Focus on understanding the core data structures and running the code examples. Mid-week, shift your focus to writing code on the Practice Sheet. Tackle the core problems first. If you solve them comfortably, pick one or two extended problems to see how the pattern adapts to different problem statements.

Towards the end of the week, open the Interview Sheet for that chapter. Practice answering the questions aloud without looking at the model answers. Finally, spend time revising problems marked with a revisit star from earlier chapters to keep older patterns fresh in your memory.

When you get stuck

Step backwards through the note rather than looking up the answer immediately.

Getting stuck on a problem is an essential part of learning. When code fails a test case or an approach does not come to mind, avoid searching for the editorial right away.

Instead, step backwards through the learning materials in order:

1. Re-read the basics: return to "How it works" in the note. Most sticking points come from a misunderstanding of the fundamental rule or pointer movement.
2. Revisit the figure: walk through the interactive diagram again, paying special attention to edge cases like empty arrays, single elements, or boundary indices.
3. Check the Traps: review the Traps section at the bottom of the note. The problem you are facing is often one of the common mistakes listed there, such as off-by-one bounds or integer overflow.
4. Check prerequisite notes: check the "Builds on" link in the facts strip at the top of the note. If the current topic relies on recursion or two pointers, a quick review of that prerequisite note will often clear up the confusion.

If you are still stuck after working through these steps on paper with a small example, read only the first hint of the solution. Write the code yourself rather than copying the final answer.

Under the hood

Reading options

Choose the theme and language that keep your reading comfortable.

Algoz includes built-in display and language settings to keep long study sessions comfortable on any device:

• Themes: you can choose between Paper (a warm light tone, active by default), Chalk (a brighter, whiter light theme), Dark (for low-light environments), or System (which matches your operating system preference).
• Languages: notes are written in English and Hinglish. Hinglish uses conversational Hindi written in Roman script, blended with standard English technical terms. Headings, labels, code blocks, and technical vocabulary remain in English so that your interview terminology stays accurate.

On desktop computers, the theme and language button is located at the bottom left of the screen. On mobile phones, it sits in the top-right corner of the header. Your selections are remembered across visits on the same device.

Your progress lives in your browser

Local storage keeps your ticks private without needing an account.

Your study progress is saved directly in your browser using localStorage. Every time you check off a problem on the Practice Sheet, mark an interview answer as known, or star a question for revision, the change is stored locally on your device.

Because the data lives in your browser, you do not need an account, an email address or a password, and your progress is not sent anywhere.

However, browser storage is tied to the specific browser and device you use. If you clear your browser cookies and site data, your progress will be wiped. To prevent accidental data loss, use the Export button on the sheets to download your progress as a small JSON file. You can keep this file as a backup or use the Import button to restore your progress on a different laptop or phone.

Preparing for the real round

Simulate interview conditions early to build confidence under pressure.

Knowing how to solve problems in a quiet room is different from solving them in front of an interviewer. Chapter 49, "Cracking the round", brings all the patterns together and teaches the communication and problem-solving framework needed for live interviews.

To prepare for real interview rounds throughout the year:

• Tackle expert problems: as you grow comfortable with a chapter's core patterns, attempt problems from the expert tier. They are the hardest versions of each pattern.
• Speak out loud: practice explaining your reasoning as you write code. State your assumptions, explain why you chose a specific data structure, and calculate the time and space complexity before the interviewer asks.
• Code without an IDE: practice solving problems in a plain text editor without autocomplete, syntax highlighting, or immediate compiler feedback. This prepares you for the shared coding environments used in technical interviews.
• Run mock interviews: conduct timed mock sessions with peers or mentors to practice thinking calmly when an unexpected question or edge case arises.

Traps

1. Reading code without typing and running it yourself

   Reading a program gives an illusion of understanding, but syntax details, loop bounds, and type conversions only become second nature when you write them yourself. Always type the code into your editor, run it, and experiment with custom inputs.

2. Ticking a problem you only understood after reading the solution

   Looking at an editorial and thinking "that makes sense" is not the same as solving the problem. If you had to read the solution, close it, wait a few days, and attempt the problem again from a blank editor before marking it solved.

3. Skipping the Java fundamentals chapters

   Jumping straight to data structures while ignoring language mechanics leads to subtle bugs with object comparison, reference mutability, and integer overflow. Strong knowledge of the Java Collections Framework and memory model is essential for writing clean interview code.

4. Jumping between chapters out of order

   Data structures and algorithmic patterns build directly on previous topics. Attempting trees, graphs, or dynamic programming before becoming comfortable with recursion, stacks, and linear structures creates confusion and slows down your overall progress.

5. Sticking exclusively to easy problems

   Solving many easy problems feels good, but rounds usually ask for more than the basic pattern. Once you understand the core idea of a note, push into the extended tier to stretch your reasoning.

6. Never revisiting previously solved problems

   Algorithmic patterns fade quickly if you never review them. Use the revisit star on the Practice Sheet and return to older problems after a week or two to verify that you can still derive the optimal approach from scratch.

7. Practicing silently without speaking your thoughts out loud

   Interviews are collaborative problem-solving discussions, not silent coding tests. If you never speak your thought process aloud while practicing, you will struggle to articulate trade-offs, clarify constraints, and communicate calmly under pressure.