Senior Rust Interview Preparation Architecture

Status: draft for discussion.

This document turns the principles in study-framework.md into an operational preparation architecture. It defines what to study, in what dependency order, to what depth, and what evidence is required before a topic advances.

It is intentionally separate from:

• study-framework.md, which defines the learning philosophy and capability model;
• roadmap.md, which defines the long-term knowledge graph;
• questions/<topic>/questions.md, which defines the interview-card backlog for one topic.

1. Preparation Outcome

The target profile is deliberately uneven:

1. Reach L1 across the entire relevant interview map.
2. Reach interview-ready L2 across the Rust core and production-critical topics.
3. Reach L3 only for common Senior interview hotspots.
4. Use L4 only to close a demonstrated gap or prepare for a specialized role.

Expected end state:

Scope	Target
Full relevant map	L1
Core Rust, memory, concurrency, async, systems basics	L2
Ownership, lifetimes, traits, Send/Sync, synchronization, async, Tokio	L3
Compiler and language internals	Selective L4

The preparation is complete enough for an interview when the candidate can explain, apply, defend, and connect the important topics. Completing every planned card is not a prerequisite.

1.1 Core Rust Architecture

This is the primary dependency path for preparation:

0. Execution and Memory Basics
              |
              v
1. Ownership and Borrowing
        +-----+-----+
        |           |
        v           v
2. Lifetimes   3. Type System and Traits
        +-----+-----+
              |
              v
4. Memory, Smart Pointers, Interior Mutability
        +-----+----------------+
        |                      |
        v                      v
5. Unsafe Rust       6. Send, Sync, Threads
                               |
                               v
                       7. Synchronization
                               |
                               v
                           8. Atomics

Lifetimes + Traits + Memory + Send/Sync
                    |
                    v
              9. Async and Future
                    |
                    v
              10. Pin and Unpin
                    |
                    v
                 11. Tokio

Memory + Concurrency + Async + Tokio
                    |
                    v
       12. Performance, OS, Networking
                    |
                    v
       13. Senior System Architecture

The numbered layers are the spine of the preparation. Supporting language and engineering topics run alongside it:

• closures, iterators, pattern matching, and collections are attached to Ownership, Lifetimes, and Traits;
• error handling is attached to Type System, Traits, and API design;
• Cargo, modules, features, and conditional compilation are attached to production engineering;
• testing, property testing, fuzzing, and deterministic concurrency testing are attached to each relevant layer;
• declarative and procedural macros remain a lower-priority language track;
• FFI is attached to Memory Representation and Unsafe Rust.

The architecture is designed for high interview coverage, not exhaustive coverage of every Rust Reference rule, standard-library API, macro corner, platform detail, or third-party crate.

2. Architecture Dimensions

The system has four independent dimensions.

2.1 Depth Axis

Level	Capability	Required evidence
L0 Discovery	The topic is unmapped or untested	Initial diagnostic and compact topic map
L1 Explain	Explain the core model without notes	70-80% of conceptual questions answered clearly
L2 Apply	Predict, diagnose, and fix Rust code	80% or more of code drills solved and justified
L3 Defend	Survive chained Senior follow-ups	Several 4-5 question chains handled with trade-offs
L4 Internals	Reason at compiler/runtime/memory-model depth	Targeted internal explanation tied to a real need

2.2 Scope Axis

The interview map is divided into six tracks:

Track	Scope
A. Language Core	Ownership, lifetimes, types, traits, closures, iterators, errors, patterns, collections
B. Memory and Safety	Representation, smart pointers, interior mutability, unsafe Rust
C. Concurrency	Threads, Send/Sync, synchronization, atomics
D. Async Runtime	Future, async state machines, Pin, Tokio
E. Systems	Performance, OS fundamentals, networking
F. Engineering	Cargo, modules, testing, macros, architecture and system design

2.3 Time Axis

Preparation uses repeated passes rather than completing one topic to maximum depth before seeing the rest:

Pass 0: Diagnose
    -> Pass 1: Breadth to L1
        -> Pass 2: Core topics to L2
            -> Pass 3: Hotspots to L3
                -> Pass 4: Mock interviews and cold retesting

2.4 Evidence Axis

Every level change must be supported by observable performance:

• an answer delivered without notes;
• a code prediction made before compiling;
• a compiler error explained precisely;
• a fix justified without unnecessary cloning;
• a trade-off discussed using a realistic engineering scenario;
• a cold retest passed after one, three, or seven days.

Time spent, pages read, and videos watched are not completion evidence.

3. Global Preparation Passes

Pass 0 - Baseline Diagnostic

Purpose: locate existing strengths and unknowns without studying first.

For every high-priority topic:

1. Answer three to five conceptual questions.
2. Solve two or three short code-reasoning exercises.
3. Give one practical trade-off.
4. Assign a provisional level from L0 to L3.
5. Record weak subtopics, not just a single topic score.

Output:

• initial level matrix;
• weak-subtopic list;
• role-specific priority adjustments;
• first cold-retest queue.

Time box: half a day to one day.

Pass 1 - Breadth to L1

Purpose: build a complete mental map and eliminate unknown core areas.

Rules:

• move through every relevant topic;
• spend most time on priorities 8-10;
• stop when the core model is coherent and approximately 70-80% of conceptual questions are correct;
• do not chase rare edge cases;
• record gaps for Pass 2 instead of expanding the current session indefinitely.

Output per topic:

• compact topic map;
• 30-90 second core explanation;
• common distinctions and misconceptions;
• dependency links to other topics;
• provisional L1 result.

Expected duration: 7-10 intensive days, depending on baseline and daily availability.

Pass 2 - Core Topics to Interview-Ready L2

Purpose: turn conceptual familiarity into applied reasoning.

Primary topics:

• Ownership and Borrowing;
• Lifetimes;
• Type System;
• Traits and Generics;
• Closures and Iterators;
• Smart Pointers;
• Interior Mutability;
• Memory Representation;
• Unsafe Rust fundamentals;
• Threads;
• Send and Sync;
• Synchronization;
• Atomics;
• Async and Future;
• Pin and Unpin;
• Tokio;
• Performance;
• OS and Networking fundamentals.

Required work per topic:

• 10-20 compile-or-fail snippets;
• output and ownership-state prediction;
• compiler-error diagnosis;
• fixes with explicit soundness reasoning;
• one API or system-design exercise;
• two or three follow-up questions;
• one realistic engineering trade-off.

Expected duration: 2-3 intensive weeks after broad L1.

Pass 3 - Hotspots to L3

Purpose: withstand Senior-level follow-up chains.

Default hotspots:

• Ownership and Borrowing;
• Lifetimes;
• Traits and Generics;
• Smart Pointers and Interior Mutability;
• Send and Sync;
• Synchronization and Concurrency;
• Async and Future;
• Tokio;
• Performance and resource ownership.

Each hotspot requires:

• at least three chained interview scenarios;
• four or five follow-ups per scenario;
• explicit invariants;
• comparison with a plausible alternative;
• runtime, compiler, memory, or OS implications where relevant;
• connection to at least two adjacent topics.

Expected duration: 5-10 focused days, adjusted by diagnostic results.

Pass 4 - Interview Simulation and Retention

Purpose: integrate topics and make performance stable under cold conditions.

Use:

• mixed-topic mock interviews;
• timed 30-90 second answers;
• unfamiliar code review;
• debugging and design scenarios;
• one-day, three-day, and seven-day retests;
• flashcards generated only from mistakes.

This pass begins during Pass 1 and becomes dominant near the interview date.

4. Topic Dependency Architecture

The primary dependency graph is:

Ownership and Borrowing
├── Lifetimes
│   ├── Closures
│   ├── Async borrowing
│   └── API design
├── Type System
│   └── Traits and Generics
│       ├── Iterators
│       ├── Trait objects
│       └── Async traits and futures
├── Smart Pointers
│   └── Interior Mutability
│       └── Send and Sync
│           ├── Threads
│           ├── Synchronization
│           └── Async Send futures
└── Drop and RAII
    ├── Cancellation
    ├── Resource ownership
    └── Graceful shutdown

Memory Representation
├── Unsafe Rust
├── Atomics and Memory Model
├── Pin and Unpin
└── Performance

OS Fundamentals
├── Threads and Synchronization
├── Async I/O and Tokio
├── Networking
└── Performance

Async and Future
├── Pin and Unpin
├── Tokio
├── Cancellation and backpressure
└── Async system design

The graph is not a prohibition on previewing later topics. It defines where deep reasoning depends on earlier mental models.

5. Study Waves

The waves define the preferred topic order inside every pass. Pass 1 moves through all waves quickly. Passes 2 and 3 revisit only the required topics at greater depth.

Wave 1 - Ownership Foundation

Topics:

1. Ownership and Borrowing.
2. Lifetimes.
3. Drop, RAII, moves, and borrowing across APIs.

Why first: nearly every later Rust-specific topic depends on accurate ownership and lifetime reasoning.

Exit from L1:

• explain ownership, moves, borrowing, and destruction;
• explain the purpose of lifetimes;
• distinguish reference lifetime from value lifetime;
• explain common &T and &mut T rules.

Exit from L2:

• reason through moves, partial moves, reborrowing, NLL, and destructuring;
• fix borrow-checker errors without blind cloning;
• design function signatures that take ownership or borrow deliberately;
• reason about structs and methods with references.

Exit from L3:

• defend aliasing and exclusivity invariants;
• connect &mut T, UnsafeCell, optimizer assumptions, and raw pointers;
• discuss variance, HRTBs, drop checking, and advanced lifetime trade-offs when relevant.

Wave 2 - Type and Abstraction Foundation

Topics:

1. Type System.
2. Traits and Generics.
3. Closures.
4. Iterators.
5. Error Handling.
6. Pattern Matching.
7. Collections.

Why second: these topics define how production Rust APIs express behavior, ownership, abstraction, and errors.

Exit from L1:

• explain generics, trait bounds, associated types, and dispatch;
• distinguish impl Trait, generic parameters, and dyn Trait;
• explain closure captures and Fn traits;
• explain iterator ownership modes;
• use Option, Result, ?, and pattern matching coherently.

Exit from L2:

• reason about monomorphization and dynamic dispatch;
• diagnose dyn-compatibility and coherence problems;
• choose appropriate conversion and borrowing traits;
• reason about closure captures and iterator consumption;
• design error boundaries and collection APIs.

Exit from L3:

• defend abstraction and dispatch trade-offs;
• explain vtables, blanket implementations, coherence, and orphan rules;
• connect traits to auto traits, async futures, and API evolution.

Wave 3 - Memory and Safety

Topics:

1. Memory Representation.
2. Smart Pointers.
3. Interior Mutability.
4. Unsafe Rust.

Why third: these topics connect ownership rules to actual layout, allocation, aliasing, shared ownership, and safe abstraction design.

Exit from L1:

• explain stack versus heap without tying ownership to either location;
• explain thin and fat pointers;
• distinguish Box, Rc, Arc, Weak, Cell, RefCell, Mutex, and RwLock;
• explain what an unsafe block permits and what it does not guarantee.

Exit from L2:

• choose the correct ownership and mutability primitive;
• reason about reference counts, cycles, and weak references;
• explain runtime borrow failures;
• reason about layout, alignment, enum niches, and FFI representation;
• audit a small safe abstraction over unsafe code.

Exit from L3:

• defend UnsafeCell as the primitive behind legal interior mutability;
• connect smart-pointer bounds to Send and Sync;
• discuss soundness invariants, pointer validity, initialization, and aliasing.

Wave 4 - Concurrency

Topics:

1. Threads.
2. Send and Sync.
3. Synchronization.
4. Atomics and Memory Model.

Why fourth: correct concurrent reasoning requires ownership, lifetimes, smart pointers, and interior mutability.

Exit from L1:

• explain thread ownership transfer and scoped threads;
• define Send and Sync operationally;
• compare locks, channels, and atomics;
• explain the purpose of atomic ordering at a high level.

Exit from L2:

• derive common Send and Sync results for composed types;
• identify deadlock and contention risks;
• design lock ordering and bounded communication;
• use acquire-release reasoning for standard publication patterns;
• compare shared state with message passing.

Exit from L3:

• defend unsafe Send or Sync requirements;
• reason through multi-step concurrency scenarios;
• connect aliasing, data races, atomics, visibility, and happens-before;
• discuss starvation, fairness, poisoning, parking, and backpressure.

Wave 5 - Async Runtime

Topics:

1. Async and Future.
2. Pin and Unpin.
3. Tokio.

Why fifth: async Rust combines ownership, traits, state machines, scheduling, I/O, and concurrency.

Exit from L1:

• explain what an async function returns;
• explain lazy futures and Future::poll;
• distinguish futures, tasks, executors, and reactors;
• explain why Pin exists;
• explain Tokio tasks, runtimes, and async I/O at a high level.

Exit from L2:

• trace state across .await points;
• reason about Send + 'static requirements for spawned futures;
• detect blocking work inside async tasks;
• reason about cancellation and cancellation safety;
• choose Tokio synchronization and channel primitives;
• use spawn, spawn_blocking, join!, and select! deliberately.

Exit from L3:

• explain the generated future state machine and wake-up path;
• defend Future::poll(self: Pin<&mut Self>, ...);
• reason about cooperative scheduling, starvation, backpressure, and task ownership;
• design graceful shutdown and task supervision;
• connect Tokio behavior to OS readiness APIs.

Wave 6 - Systems and Performance

Topics:

1. Performance.
2. OS and Systems Fundamentals.
3. Networking.
4. Architecture and Senior Engineering.

Why sixth: Senior interviews often test whether Rust choices connect to hardware, OS behavior, latency, and production architecture.

Exit from L1:

• explain allocation, locality, syscalls, threads, scheduling, and non-blocking I/O;
• explain TCP, UDP, backpressure, and buffering;
• identify major production concerns such as shutdown, retries, and observability.

Exit from L2:

• diagnose likely allocation, contention, cache, and I/O costs;
• compare readiness and completion models;
• reason about latency, batching, bounded queues, and load shedding;
• design a concurrent Rust service with explicit resource ownership.

Exit from L3:

• defend system-design trade-offs under failure and load;
• connect Rust abstractions to allocator, cache, scheduler, kernel, and network behavior;
• discuss measurement methodology instead of guessing about performance.

Wave 7 - Engineering Support

Topics:

1. Cargo and Modules.
2. Testing.
3. Macros.

Why last: these are important for production fluency but usually offer lower interview return than the earlier waves.

Default target:

• Cargo and Modules: L1/L2;
• Testing: L1/L2;
• Macros: L1.

These topics can be inserted between demanding sessions in earlier waves.

6. Topic Inventory and Target Depth

This matrix is the authoritative proposed scope for discussion.

ID	Topic	Priority	Default target	Deepening trigger
1	Ownership and Borrowing	10	L3	Always
2	Lifetimes	10	L2/L3	Backend library or systems-heavy interview
3	Type System	8	L2	Heavy API or library design focus
4	Traits and Generics	10	L2/L3	Always deepen dispatch and coherence
5	Closures	8	L2	Async, iterator, or callback-heavy role
6	Iterators	7	L2	Performance and API-design focus
7	Error Handling	7	L2	Production backend focus
8	Pattern Matching	6	L1/L2	Weak ownership reasoning in patterns
9	Collections	7	L2	Data-intensive or performance role
10	Memory Representation	8	L2	Systems, FFI, or unsafe-heavy role
11	Smart Pointers	9	L2/L3	Always deepen Arc, Weak, and Pin links
12	Interior Mutability	9	L2/L3	Always deepen UnsafeCell relation
13	Unsafe Rust	9	L2	Specialized low-level role
14	Threads	9	L2	Thread-heavy systems role
15	Send and Sync	10	L3	Always
16	Synchronization	10	L3	Always
17	Atomics and Memory Model	9-10	L2	L3 for low-latency or lock-free role
18	Async and Future	10	L3	Always for backend roles
19	Pin and Unpin	8	L2/L3	Deep async or library role
20	Tokio	10	L3	Always for Tokio backend roles
21	Performance	9	L2/L3	Low-latency, trading, or systems role
22	OS and Systems Fundamentals	8-10	L2	Systems or infrastructure role
23	Networking	10	L2/L3	Backend, trading, or networking role
24	Cargo and Modules	5	L1/L2	Workspace or library-maintenance focus
25	Testing	5	L1/L2	Reliability or infrastructure focus
26	Macros	4	L1	Macro-heavy codebase
27	Architecture and Senior Engineering	10	L3	Always, integrated with technical topics

7. Detailed Topic Maps

These maps define the preparation boundary for each topic. They are maps, not quotas.

7.1 Ownership and Borrowing

• ownership rules and resource ownership;
• moves, copies, and clones;
• bindings, values, and resources;
• shared and mutable borrowing;
• aliasing and exclusivity;
• reborrowing and NLL;
• partial moves and destructuring;
• borrowing independent fields;
• temporaries and lifetime extension;
• Drop, drop order, drop glue, and RAII;
• std::mem::take, replace, swap, forget, and drop;
• API ownership choices.

7.2 Lifetimes

• why lifetimes exist;
• annotations and elision;
• input and output lifetime relationships;
• multiple lifetimes;
• structs and methods with references;
• 'static references versus 'static bounds;
• T: 'a versus &'a T;
• subtyping and variance;
• &mut invariance considerations;
• HRTBs and for<'a>;
• reborrowing and NLL;
• drop checking and PhantomData basics.

7.3 Type System

• primitives, structs, enums, tuples, arrays, and slices;
• str versus String;
• newtypes and aliases;
• never type and zero-sized types;
• Sized, ?Sized, and dynamically sized types;
• coercions, deref coercion, and unsizing;
• type inference and turbofish;
• associated types and GATs;
• impl Trait.

7.4 Traits and Generics

• trait definitions, bounds, and where clauses;
• blanket implementations, coherence, and orphan rules;
• associated types, constants, and default methods;
• supertraits, marker traits, and auto traits;
• static versus dynamic dispatch;
• monomorphization and vtables;
• dyn compatibility;
• extension traits;
• conversion traits;
• AsRef, Borrow, Deref, and DerefMut;
• iterator-related traits;
• generic API trade-offs.

7.5 Closures

• immutable, mutable, and by-value capture;
• move closures;
• Fn, FnMut, and FnOnce;
• closure trait hierarchy;
• closure versus function pointer;
• returning and storing closures;
• closure capture precision;
• async closure concepts.

7.6 Iterators

• Iterator and IntoIterator;
• iter, iter_mut, and into_iter;
• lazy adapters and consumers;
• map, filter, fold, and collect;
• FromIterator;
• custom iterators;
• ownership and borrowing implications;
• zero-cost abstraction claims and limits.

7.7 Error Handling

• Option, Result, and ?;
• error propagation and conversion;
• custom error types;
• std::error::Error and source chains;
• typed errors versus Box<dyn Error> or anyhow;
• thiserror;
• panic, unwind, and abort;
• catch_unwind, panic safety, and poisoning.

7.8 Pattern Matching

• exhaustive match;
• if let, while let, and let else;
• destructuring;
• guards, @, _, and ranges;
• matches!;
• moves and borrows inside patterns;
• match ergonomics.

7.9 Collections

• Vec, VecDeque, HashMap, HashSet, BTreeMap, and BinaryHeap;
• slices and strings;
• capacity and allocation behavior;
• Entry API;
• complexity and cache behavior;
• hash-map versus tree-map trade-offs.

7.10 Memory Representation

• stack, heap, and allocation ownership;
• layout, alignment, and padding;
• references and raw pointers;
• thin and fat pointers;
• slices, str, and trait-object representation;
• enum discriminants and niche optimization;
• Option<&T> and Option<NonNull<T>>;
• zero-sized types;
• repr(Rust), repr(C), and repr(transparent);
• ABI and endianness basics.

7.11 Smart Pointers

• Box, Rc, Arc, and Weak;
• reference-count layout and operations;
• cycles and weak ownership;
• Cow;
• Pin;
• NonNull;
• ManuallyDrop;
• MaybeUninit;
• smart-pointer Send and Sync bounds.

7.12 Interior Mutability

• interior mutability mental model;
• Cell and RefCell;
• runtime borrow checking and panic cases;
• UnsafeCell;
• Mutex, RwLock, and atomics as thread-safe forms;
• Rc<RefCell<T>>;
• choosing a primitive by ownership, thread, and blocking requirements.

7.13 Unsafe Rust

• unsafe operations and obligations;
• raw pointers;
• unsafe functions and unsafe traits;
• mutable statics and unions;
• soundness versus undefined behavior;
• aliasing, validity, initialization, and alignment;
• UnsafeCell, MaybeUninit, and NonNull;
• safe abstractions over unsafe code;
• FFI fundamentals.

7.14 Threads

• std::thread::spawn and JoinHandle;
• ownership transfer into threads;
• scoped threads;
• shared state;
• thread lifecycle, panics, and joining;
• OS-thread costs.

7.15 Send and Sync

• operational definitions;
• relationship between T: Sync and &T: Send;
• auto-trait derivation;
• why Rc is not Send or Sync;
• why RefCell is not Sync;
• Arc<T> bounds;
• raw pointers and auto traits;
• unsafe implementations and proof obligations.

7.16 Synchronization

• Mutex, RwLock, and Condvar;
• channels and message passing;
• lock guards and RAII;
• deadlocks and lock ordering;
• contention and critical-section size;
• poisoning;
• starvation, fairness, and parking;
• bounded versus unbounded communication.

7.17 Atomics and Memory Model

• atomic loads, stores, and read-modify-write operations;
• compare_exchange;
• atomicity, visibility, and reordering;
• Relaxed, Acquire, Release, AcqRel, and SeqCst;
• synchronization and happens-before;
• lock-free versus wait-free progress;
• ABA basics;
• false sharing and cache coherence.

7.18 Async and Future

• async functions and blocks;
• lazy futures;
• Future::poll, Poll, Context, and Waker;
• future, task, executor, and reactor distinctions;
• state-machine transformation;
• suspension points and .await;
• cancellation and cancellation safety;
• streams;
• Send futures;
• borrowing across .await.

7.19 Pin and Unpin

• address-sensitive values;
• self-referential structures;
• Pin<P> guarantees and limitations;
• Unpin;
• why most types are Unpin;
• pin projection;
• unsafe contract;
• relationship to Future::poll.

7.20 Tokio

• current-thread and multi-thread runtimes;
• task scheduling, worker threads, and work stealing;
• async I/O and readiness;
• reactor and OS polling concepts;
• spawn, JoinHandle, and spawn_blocking;
• task cancellation and Send + 'static;
• standard versus Tokio synchronization primitives;
• mpsc, oneshot, broadcast, and watch;
• Semaphore and Notify;
• cooperative scheduling, yielding, and starvation;
• graceful shutdown and task supervision.

7.21 Performance

• allocation and copying;
• cache locality, cache lines, and false sharing;
• branch prediction;
• virtual dispatch and monomorphization;
• inlining and SIMD basics;
• bounds-check elimination and iterator optimization;
• zero-copy design;
• arenas and pools;
• profiling and benchmarking;
• flamegraphs, LTO, and PGO;
• measurement errors and benchmark design.

7.22 OS and Systems Fundamentals

• virtual memory, pages, and page faults;
• stack, heap, malloc, mmap, and fragmentation;
• processes, threads, scheduling, and context switches;
• system calls;
• blocking versus non-blocking I/O;
• readiness versus completion;
• epoll, kqueue, and io_uring;
• sockets and file descriptors.

7.23 Networking

• TCP and UDP;
• handshakes, loss, and retransmission;
• flow and congestion control;
• Nagle's algorithm and TCP_NODELAY;
• keepalive;
• sockets and buffers;
• backpressure;
• HTTP, WebSockets, and TLS basics;
• serialization and latency trade-offs.

7.24 Cargo and Modules

• packages, crates, modules, and visibility;
• use, pub, and pub(crate);
• workspaces;
• features and feature unification;
• conditional compilation;
• build scripts;
• dependency types;
• profiles, release builds, and LTO.

7.25 Testing

• unit, integration, and documentation tests;
• property testing;
• fuzzing;
• benchmarking with Criterion;
• Loom conceptually;
• deterministic testing of concurrent and async code.

7.26 Macros

• macro_rules! matching and repetition;
• macro hygiene;
• procedural, derive, attribute, and function-like macros;
• TokenStream;
• when a macro is preferable to a function or trait.

7.27 Architecture and Senior Engineering

• shared state versus message passing;
• bounded queues and backpressure;
• graceful shutdown and cancellation;
• retries and idempotency;
• batching;
• rate limiting and load shedding;
• resource ownership;
• observability and fault isolation;
• API and library design;
• abstraction boundaries;
• failure-mode and capacity reasoning.

8. Topic Work Unit

Every topic uses the same work unit so progress remains comparable.

L0 Work Unit

• build a 10-20 item subtopic map;
• list dependencies;
• answer a short diagnostic;
• assign provisional weak areas.

L1 Work Unit

• study only the core model;
• answer 10-15 conceptual questions without notes;
• explain why the feature exists;
• distinguish it from adjacent concepts;
• record failed questions.

L2 Work Unit

• solve 10-20 code drills;
• predict before compiling;
• explain exact compiler behavior;
• fix without unnecessary allocation or cloning;
• solve one API or engineering scenario;
• handle two or three follow-ups.

L3 Work Unit

• complete three or more chained interview scenarios;
• state safety or design invariants;
• compare alternatives;
• connect compiler, runtime, memory, or OS behavior;
• handle four or five follow-ups per chain.

Retention Work Unit

• retest failures after one day;
• retest again after three days;
• retest again after seven days;
• create a reasoning card only when the error repeats or is high value.

9. Progress Model

Track a topic using evidence rather than a single subjective label.

## Ownership and Borrowing

- L1: PASS, 13/15
- L2: PARTIAL, 12/17
- L3: PARTIAL, 2/4 chains
- Last cold review: 2026-08-11
- Next review: 2026-08-12

Weak subtopics:
- reborrowing;
- aliasing and UnsafeCell;
- temporary lifetime extension.

Repeated mistakes:
- assumed a borrow lasts until the end of scope;
- used clone where a narrower borrow was sufficient.

Recommended status vocabulary:

• NOT STARTED;
• DIAGNOSTIC COMPLETE;
• PARTIAL;
• PASS;
• COLD PASS;
• RETEST REQUIRED.

10. Session Architecture

A normal focused session should be 60-120 minutes:

1. Cold recall of an older topic: 10-15 minutes.
2. Current topic map or gap review: 5-10 minutes.
3. Active questions or code drills: 30-60 minutes.
4. Gap-focused reading: 15-30 minutes.
5. Re-explanation and close-out: 10-15 minutes.

For a new topic, perform L1 before a large code drill. For an existing topic, start with testing and study only the failures.

11. Proposed Preparation Sequence

This is the default sequence before it is converted into a calendar.

Stage A - Broad L1

1. Ownership and Borrowing.
2. Lifetimes.
3. Type System.
4. Traits and Generics.
5. Closures and Iterators.
6. Error Handling, Patterns, and Collections.
7. Memory Representation.
8. Smart Pointers and Interior Mutability.
9. Unsafe Rust.
10. Threads, Send/Sync, and Synchronization.
11. Atomics.
12. Async, Future, and Pin.
13. Tokio.
14. Performance, OS, and Networking.
15. Cargo, Testing, Macros, and Architecture.

Stage B - Core L2

1. Ownership and Lifetimes.
2. Traits, Generics, Closures, and Iterators.
3. Smart Pointers, Interior Mutability, and Memory Representation.
4. Send/Sync, Threads, Synchronization, and Atomics.
5. Async, Future, Pin, and Tokio.
6. Unsafe fundamentals and Performance.
7. OS, Networking, and production architecture.

Stage C - Hotspot L3

1. Ownership, borrowing, aliasing, and API design.
2. Lifetimes and advanced follow-ups.
3. Traits, dispatch, coherence, and abstraction trade-offs.
4. Smart pointers, interior mutability, Send, and Sync.
5. Locks, channels, atomics, deadlocks, and backpressure.
6. Future state machines, scheduling, cancellation, and pinning.
7. Tokio runtime, I/O, graceful shutdown, and task supervision.
8. Performance and system-design scenarios.

12. Open Decisions for Discussion

The following choices must be agreed before turning this draft into a concrete schedule:

1. Primary role profile: general Senior Rust, backend/Tokio, systems, trading/low latency, or Web3 infrastructure.
2. Available preparation time per day and target interview date.
3. Current baseline for each high-priority topic.
4. Whether broad L1 should be completed before any L2 work, or whether foundational topics should reach L2 earlier.
5. How much OS, networking, and architecture depth the target interviews require.
6. Where progress state and review dates should live in the repository.
7. Whether interview cards should be generated only after failed tests or also for the planned high-priority map.
8. How often full mock interviews should occur during the first two passes.

These decisions affect the calendar and emphasis, but not the dependency architecture or the L0-L4 capability model.