You're not signed in!
Sign in to save your progress and sync your settings across devices.
Authors: Nathan Wang, Benjamin Qi
How each module is structured.
The material in this guide will be grouped into modules such as the one you're reading right now. A module generally consists of three parts:
- Lesson: Introduces the concept.
- Implementations: Code!
- Practice Problems: Teaches you how to apply the concept to various problems.
Some relatively rare modules are prefixed with "optional." It's not essential to work through these if your goal is just to pass the corresponding division. They might be referenced in later divisions.
The lesson is a curated collection of external resources, problems, and supplementary text we've written ourselves.
- We'll link to online resources that already exist whenever possible.
- The goal is to introduce you to the concept.
- Everything is meant to be completed in order.
- It usually begins with at least one standard problem, marked "Intro" in the difficulty column.
- The standard problem is a direct application of the concept, and is useful in testing your implementation.
- We'll star external resources that we highly recommend you read. Feel free to read the others if you don't understand something. If multiple modules cover essentially the same material, at most one should be starred.
Usually the lesson is followed by an implementation of the solution to the standard problem.
- C++ code will always be provided.
- Java code will be provided (at least) for Bronze to Gold.
- Python code will be provided (at least) for Bronze and some of Silver.
Example input / output will be provided if not already contained within the statement of the standard problem. See Code Conventions for more information regarding what our code will look like.
After reading the module lesson, you'll be given a lot of problems (from various sources, not just USACO) to practice applying the concept you've learned.
- The problems are roughly sorted in order of how they are recommended to be completed.
- You don't have to solve every problem, just enough to feel comfortable with the module. We've starred the ones we found most interesting.
Please let us know if the problem is not a good example of the corresponding topic!
We'll try our best to write full editorials for problems which don't have them (or if existing editorials are poorly written). Starred problems will generally have better editorials.
Pre-release note: Currently, very few problems have full editorials. We've provided some temporary solution sketches (very short solution explanations) while we continue working on this guide. If you believe an editorial is needed for a problem, please let us know using the "Contact Us" button.
Difficulty represents how challenging a problem is expected to be to someone after they read through the module, not how difficult the problem is in general. Therefore, it is not comparable across modules (even of the same division).
Difficulty ranges from Very Easy to Insane.
- Very Easy problems are related to the module, but you should be able to do them relatively quickly before reading the resources.
- Easy problems can be solved relatively quickly by someone who is familiar with the module, and they should be approachable by someone who has just finished reading the starred resources.
- Normal problems require a bit more thinking.
- Hard problems may require a lot (?) of time to approach.
- Very Hard problems challenge even the strongest contestants in the corresponding division. Often require multiple levels of observation and more knowledge than provided by the module.
- Insane problems shouldn't appear on a (reasonable) contest of the corresponding division. Don't worry about solving these until you've reached a higher division.
Sometimes modules will contain interactive elements. Here are some of the more common ones.
Not all content in this guide is essential to competitive programming. Skipping over optional content is fine, but if you're interested, feel free to explore further as well.