Milestone map
Milestone map
3 milestones
Build ownership, borrowing, and lifetimes foundations
4 weeks
Work through Rust's ownership model until the borrow checker is no longer a surprise: ownership transfer, borrowing (shared &T and exclusive &mut T), lifetimes in function signatures, and the rules that prevent data races at compile time. Complete the first three chapters of The Rust Book plus the ownership and lifetimes Rustlings exercises. The proof is five small programs each demonstrating a different ownership rule — not just programs that happen to compile.
Proof required
Public GitHub repository containing five small Rust programs, each with a comment explaining which ownership rule it demonstrates and why the borrow checker would have rejected an alternative approach.
What gets checked
- All five programs compile and run correctly
- Each program's comment names the specific ownership rule and explains a rejected alternative approach
- Ownership transfer, shared borrow, exclusive borrow, lifetime in function signature, and at least one Rc/Arc pattern are each represented
Common mistakes
- Fighting the borrow checker by cloning everything — cloning is a workaround that bypasses the ownership model rather than demonstrating it
- Marking lifetimes as 'static when the correct lifetime is shorter — a common shortcut that compiles but misrepresents understanding
- Not writing the comments — the comments are the proof of understanding, not just the compiled code
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Open the repository and review each program's comment — confirm each names a specific rule and an alternative the borrow checker would reject
- Spot-check one program by asking the candidate to explain why cloning instead would have been wrong
Build a systems-level Rust project
6 weeks
Build a non-trivial systems project in Rust demonstrating real-world ownership model application: a CLI tool with file I/O and error handling, an HTTP server using async and tokio, or a multi-threaded data processing pipeline using channels and Arc<Mutex<>>. The project must not use unsafe, must have at least one test, and must be documented with a README explaining what it does, how to build it, and why the key ownership decisions were made — not just what they are.
Proof required
Public GitHub repository with the project code, a README covering purpose, build instructions, and ownership decision rationale for the two most non-obvious design choices, plus at least one test that runs with cargo test.
What gets checked
- Project compiles and runs with cargo build && cargo run (or documented instructions)
- README explains the two most non-obvious ownership or concurrency decisions and why they were made
- At least one test passes with cargo test
Common mistakes
- Building a single-threaded sequential program that never requires Rust's ownership model advantages — the project should create situations where the borrow checker provides real value
- Using unwrap() throughout for error handling — unwrap is not error handling; use the ? operator and proper error types
- Writing a project that is functionally correct but has no documentation — the README ownership rationale is the proof of understanding, not the compiled binary
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Clone the repository and run cargo build — confirm it compiles without errors
- Read the README ownership rationale section — confirm it explains why specific design choices were made, not just what they are
- Run cargo test and confirm at least one test passes
Code review and ownership Q&A with a Rust developer
1 week
Present the project from M2 to a developer who writes Rust professionally or has substantial Rust experience. The reviewer must challenge specific ownership and concurrency decisions in real time — asking 'why did you use Arc<Mutex<>> here and not RwLock?', 'why is this lifetime annotation necessary?', 'what would break if you removed this borrow here?'. Defend or revise your design based on the Q&A. This real-time challenge is the AI-fakeability countermeasure: LLMs can generate Rust code that compiles, but reasoning under live expert challenge requires genuine understanding.
Proof required
Q&A notes (300+ words) documenting the reviewer's name and Rust background, at least three specific ownership or concurrency challenges they raised, your reasoning in response, and any code changes made or planned based on the session.
What gets checked
- Reviewer has professional or substantial open-source Rust experience (not just general programming experience)
- At least three specific ownership or concurrency decisions were challenged with follow-up questions
- Notes document your live reasoning responses, not retrospective post-hoc justifications
Common mistakes
- Asking a general software engineer rather than someone with Rust experience — the challenge must be domain-specific to Rust's ownership model, not generic code review
- Preparing scripted answers in advance — the point of the Q&A is to probe understanding that cannot be looked up in the moment
- Not implementing any changes from the review — if the reviewer identified a real issue, the code should reflect the correction
Resources
Foundationstart here
What a verifier looks for
- Confirm the reviewer has genuine Rust experience — ask for their GitHub profile or a project they have contributed to in Rust
- Review Q&A notes — confirm specific ownership/concurrency challenges are documented (not generic feedback)
- Check whether any code changes were made post-review — changes signal genuine engagement with the feedback