Features

Everything a practice site does, in your terminal

cstudy picks the next problem, scaffolds it in your language, runs your code, reveals hints and solutions, measures performance and tracks your progress. Here is what each part does.

01 Languages

6 languages, each a real project

A workspace holds one ordinary project per language. cstudy writes your stub into it and runs it with that language’s own toolchain, so your language server, formatter and debugger work without extra setup.

Languages, their workspace projects and problem counts
Language	In your workspace	Toolchain	Problems
Python	python/ with uv; pyright, ruff, debugpy and pytest as dev tools	uv and Python 3.13	239
TypeScript	typescript/ with pnpm; Node runs your .ts files with type stripping	Node 24 and pnpm	235
Java	jvm/java/, built with the Gradle wrapper	JDK 21, Gradle wrapper	240
Kotlin	jvm/kotlin/, built with the Gradle wrapper	JDK 21, Gradle wrapper	240
Go	go/, a Go module; go.work at the root for gopls	Go 1.24 or newer	237
Rust	rust/, a Cargo package; each problem is its own crate	Rust 1.80 or newer, via rustup	236

Pick a language per problem with --lang, or set default_lang in ~/.config/coding-study/config.toml. Reviews are scheduled per problem, not per language: solve a problem in Kotlin today and review it in Rust next week.

02 Tracks

Practice for the rounds beyond algorithms

Algorithms are one part of a senior or staff loop. The catalog also covers practical coding, low-level design, concurrency and debugging, with prompts for system design and code review.

Tracks in the catalog
Track	Items	Graded by	What you practise
Data structures and algorithms	196	Tests, in every language	Functions and data-structure designs across 23 patterns
Practical	28	Tests, level by level	One class whose API grows over levels, a project folder, or a business task with money and dates
Low-level design	8	Tests, then a design rubric	Object-oriented design
Concurrency	6	Stress tests against invariants	Thread-safe classes, with a concurrency model per language
Debugging	16	Tests	Buggy code to fix, including bugs that exist only in Go or Rust
System design	10	Yourself, with a rubric	A prompt, a notes template and a reference design
Code review	6	Yourself, with a rubric	A change to review, and the issues a strong reviewer finds

Problems in several shapes

Most problems ask for one function or one class. Progressive problems grow a class over levels; concurrent problems are checked by stress runs against invariants; debugging problems hand you buggy code to fix; project problems give you a whole folder to extend.

How each kind of problem works

Problems of your own

cstudy new scaffolds a problem in your workspace from a template, and cstudy verify checks its statement, tests and reference solutions. Your problems join the catalog for every command.

Writing your own problems

03 IDE and debugging

Your editor runs cstudy. Your debugger stops in your code.

cstudy init writes project files for VS Code and IntelliJ IDEA with a task or run configuration for every action, on the file in the editor or on the active attempt. Any other editor works through $VISUAL or $EDITOR.

cstudy test --debug runs the normal judged run under the language’s debug agent and waits for your IDE to attach. Breakpoints in your file stop the real runner, time limits are off, and the verdict arrives when the run ends.

Debug agents and default ports
Language	Debug agent	Port
Python	debugpy	5678
TypeScript	Node inspector	9229
Java, Kotlin	JDWP	5005
Go	Delve	2345
Rust	debugserver (macOS) or lldb-server (Linux)	12345

VS Code gets launch configurations for Python, TypeScript, Java, Go and Rust; IntelliJ IDEA debugs Java and Kotlin. Editors and debugging

the line your IDE waits for (standard error)

cstudy: waiting for debugger on 127.0.0.1:5678 (python)
cstudy: waiting for debugger on 127.0.0.1:9229 (typescript)
cstudy: waiting for debugger on 127.0.0.1:5005 (java)
cstudy: waiting for debugger on 127.0.0.1:2345 (go)
cstudy: waiting for debugger on 127.0.0.1:12345 (rust)
cstudy: connecting to debugger at 127.0.0.1:5005 (kotlin)

04 Complexity checks

Measured against a ladder of references

cstudy bench runs your code and every reference approach on the same generated inputs, in the same runtime, and places your solution on the problem’s complexity ladder with an explicit confidence.

terminal

$ cstudy bench
two-sum · python · sizes 1e2..1e5 · reps 7 · power AC · load 1.2

TARGET        DECLARED   n=1e2    n=1e3    n=1e4    n=1e5    SLOPE  BAND     MEMORY
brute-force   O(n^2)     0.21ms   19.8ms   2.04s    budget   2.00   ~n^2     constant
hash-map      O(n)       0.01ms   0.09ms   0.94ms   10.1ms   1.00   ~n|nlogn linear
you                      0.01ms   0.11ms   1.10ms   11.8ms   1.01   ~n|nlogn linear

verdict   optimal: matches hash-map, 1.17x at n=1e5 · confidence high (spread 3%, R^2 0.999)
space     linear, same as hash-map · confidence high
history   best previous 13.0ms at n=1e5 (2026-09-12) · now 9% faster · 1st of 3 runs

What the verdict means

optimal: the same growth band as the optimal reference, at most 1.5 times its time at the largest size, and a ratio that does not grow.
near-optimal: the same band, but the ratio grows with n, which usually means an extra log factor.
suboptimal: a worse growth band, or over the time budget where the optimal reference finished.
unknown: too few usable sizes, or no optimal reference in this language, to compare.

What it cannot tell

Slopes separate n from n² reliably, but not n from n log n, which cstudy judges by the ratio to the optimal reference and its trend. Constant, logarithmic and square-root growth share one band. Memory is reliable in Python and approximate on the JVM and Node.

Time limits for cstudy test reuse the same reference timings: --time-limit gives each case 5 times the reference’s time by default, so a brute force fails the large cases.

05 Spaced repetition and mock interviews

Reviews when they are due, mocks when you are ready

Every finished attempt gets a grade, and the grade decides when the problem comes back. cstudy next serves what is due first, then new problems from your weakest pattern.

From rating to next review

You rate an attempt easy, ok or hard. A hint caps the grade at ok; finishing over your time box, or a confident suboptimal bench verdict, caps it at hard; giving up or revealing the solution before passing grades it again.

6 reviews of one problem, from the scheduling spec
Grade	Next review in	Ease after
`ok`	3 days	2.50
`ok`	7 days	2.50
`ok`	18 days	2.50
`hard`	22 days	2.35
`again`	1 day	2.15
`ok`	3 days	2.15

Mock interviews

cstudy mock starts new medium and hard problems from different groups with one shared timer, 45 minutes by default, and locks hints and solutions until the timer ends or every problem is done.

terminal

$ cstudy mock
mock interview · 2 problems · 45 min shared timer · python
1  group-anagrams  (medium · arrays-hashing)  weakest pattern: arrays-hashing (0.75)
   stub       python/practice/group_anagrams.py
   statement  .statements/group-anagrams.md
2  lru-cache  (medium · linked-list)  weakest pattern: linked-list (0.75)
   stub       python/practice/lru_cache.py
   statement  .statements/lru-cache.md
locked     cstudy hint and cstudy solution, until the timer ends or every problem is done
next       cstudy test group-anagrams --watch

Progress at a glance

cstudy stats shows your progress per pattern, track, language or difficulty: pass rate, median solve time, weakness, your streak and the reviews due.

terminal

$ cstudy stats
GROUP           PROBLEMS  ATTEMPTED  PASSED  MASTERED  PASS RATE  SOLVE TIME  WEAKNESS
arrays-hashing        17          5       4         1        80%     14m 10s      0.42
two-pointers          10          0       0         0          -           -      0.75
system-design         10          1       1         0       100%     45m 00s      0.30

attempts  6 finished · 5 in the last 7 days · streak 3 days
reviews   1 due today · 1 overdue
bench     4 benched · 2 optimal · 1 near-optimal · 1 suboptimal · 0 unknown

06 Offline use

On your machine, and offline

After the one-time toolchain setup, every command works without a network connection.

a.
Everything ships with cstudy
The problems, tracks and runners are part of the install. The libraries the Go and Rust runners need are vendored, so Go never downloads a module and Cargo builds with --offline.
b.
One online step for the JVM
cstudy doctor --fix runs a Gradle warm-up once, which caches the libraries that Java and Kotlin need, so later builds run offline.
c.
Your progress is a file
Attempts, reviews and bench runs live in progress.db, a SQLite file in your workspace. cstudy export writes them as JSON you can commit, and cstudy import restores them on another machine.
d.
Your code runs as you
Solutions run with your user’s permissions, under a hang guard that stops a run that never ends. cstudy is a practice tool, not a sandbox: it runs the code you write.

Ready to try it?

Install cstudy with Homebrew, then let cstudy doctor tell you which toolchains are missing.

Install cstudy Getting started

Everything a practice site does, in your terminal

Problems in several shapes

Problems of your own

What the verdict means

What it cannot tell

From rating to next review

Mock interviews

Progress at a glance

Everything ships with cstudy

One online step for the JVM

Your progress is a file

Your code runs as you

Ready to try it?