• model data with the type system instead of runtime checks
• design error types that callers can actually handle
• explain ownership and lifetimes without looking them up

Build a CLI tool with clap that ingests JSON/CSV with serde and reports typed, recoverable errors — small, finished, and pinned on your GitHub.

• ▢I can model a JSON API's types with serde derive and custom (de)serializers
• ▢I design error types with thiserror in libraries and anyhow in binaries
• ▢I can explain ownership and lifetimes without looking them up
• ▢I've published or maintained a crate/binary with a clean cargo project layout

• understand tasks, cancellation, and why blocking the runtime is a bug
• understand channels and backpressure as design tools
• operate concurrent code you can reason about under load

Write a concurrent scraper or queue worker: bounded concurrency, per-task timeouts, graceful shutdown on Ctrl-C.

• ▢I've built a program that runs concurrent tasks with tokio::spawn and joins them safely
• ▢I use timeouts and cancellation (select!, CancellationToken) deliberately
• ▢I can move data between tasks with mpsc/broadcast channels and explain backpressure
• ▢I can explain what .await yields to and why blocking the runtime is a bug

• ship an HTTP API with auth, validation, and error mapping
• understand middleware as composable services
• consume external APIs defensively (retries, timeouts, idempotency)

Ship a real REST API: auth, pagination, input validation, OpenAPI docs — deployed somewhere public with its URL in the README.

• ▢I've shipped an HTTP API with extractors, typed responses, and error mapping
• ▢I've written or composed middleware (auth, rate limiting, request IDs)
• ▢I've consumed external APIs with reqwest, handling retries and timeouts
• ▢I can explain what tower's Service trait abstracts and why it matters

• understand transactions, isolation, and connection pooling
• keep schema changes deployable (migrations as code)
• choose between SQL, embedded, and cache storage deliberately

Add PostgreSQL to your API: migrations, a transactional endpoint, and an integration test that runs against a real database (testcontainers).

• ▢I've built a service with migrations checked into the repo
• ▢I understand connection pooling and have tuned pool size under load
• ▢I can write and reason about a transaction with correct error rollback
• ▢I've used Redis (or similar) for caching or queues from Rust

• instrument services so a stranger can debug them from telemetry
• understand spans, context propagation, and structured events
• find a slow request in production without adding println

Instrument your API end-to-end: request spans, error events, latency metrics — screenshot the trace waterfall in your README.

• ▢I instrument services with tracing spans, not println!
• ▢I've configured tracing-subscriber with per-module filters and JSON output
• ▢I've exported metrics or traces to something (Prometheus, OTLP, honeycomb…)
• ▢I can find a slow request in production from telemetry alone

• trust your test suite enough to deploy on green
• containerize and ship a service with CI you wrote
• understand config, health checks, and graceful shutdown

Give your API a production spine: Dockerfile, GitHub Actions CI running integration tests, health checks, and zero-warning clippy.

• ▢My projects run integration tests against real dependencies in CI
• ▢I've containerized a Rust service with a small multi-stage Dockerfile
• ▢I use snapshot or property tests where they beat example tests
• ▢My services read config from the environment and shut down gracefully