Learn the new mechanism.
Use examples, hints, explanations, and reference answers while a concept is being formed. Success means you can reproduce and vary the chapter behavior.
Open a course →01 / PURPOSE
Use the right learning instrument.
Assessment is useful only when its purpose is clear. These checks diagnose a boundary; they do not replace teaching or a complete project.
Locate the first missing boundary.
Attempt unfamiliar-but-bounded tasks without the solution open. Success means your artifact and explanation satisfy observable evidence.
Read the protocol →Integrate and transfer.
Combine multiple capabilities into a system another person can run, test, diagnose, and extend. Success means all acceptance checks pass.
Open Project Lab →02 / PROTOCOL
Make the attempt cold, bounded, and inspectable.
Follow the same procedure for every assessment so results can guide learning instead of reflecting unlimited searching or hidden setup.
- 01
Choose one assessment.
Take the starting-point diagnostic if you are uncertain. Otherwise choose the path you intend to enter, not the field that sounds most impressive.
- 02
Create a clean evidence folder.
Record date, operating system, runtime and tool versions, exact commands, and the assessment name. Do not reuse a finished tutorial project.
- 03
Attempt before opening lessons.
You may use language or platform reference documentation for exact syntax, but do not copy a complete solution. Record every source and every request for help.
- 04
Respect the timebox.
Stop at the stated time. An unfinished artifact with a precise explanation of the blocker is more diagnostic than a copied completion after four hours.
- 05
Preserve artifacts and failures.
Keep source, fixtures, commands, tests, output, diagnostics, and a short reasoning note. Remove secrets and private data before sharing.
- 06
Apply the rubric literally.
Score observable behavior, explanation, boundary handling, and reproducibility. Do not award credit for code that looks plausible but was not run.
- 07
Route the first gap.
Use the assessment’s next actions. Study the smallest missing prerequisite, repeat only the failed task, then attempt the complete check again from a clean state.
03 / EVIDENCE RUBRIC
Score what another learner can verify.
Use four dimensions for every task. “It worked once” is only one part of the evidence.
No inspectable evidence
The artifact is missing, does not run, or the result cannot be connected to the task.
Ordinary path only
The main example works, but boundaries, errors, explanation, or reproduction steps are missing.
Required evidence passes
The stated behavior, critical boundary cases, commands, and causal explanation are present and reproducible.
New variation remains correct
A second learner changes one condition, and the design, tests, and explanation still guide a correct result.
Path-ready rule
Score at least 2 on every task marked critical and at least 2 on four of five tasks overall. One polished task cannot average away a missing safety, data-integrity, or recovery boundary.
04 / CHOOSE
Select one current decision.
You do not need to take all nine assessments. Use the result that can change what you study next.
I am unsure where to startStarting-point diagnosticI want independent foundationsBuilder readinessI want Web interfacesFrontend readinessI want APIs and servicesBackend readinessI want data platformsData readinessI want AI and RAG systemsAI readinessI want systems and reliabilitySystems readinessI want secure softwareSecurity readinessI want installable applicationsApp readiness
Starting-point diagnostic
Use this when you do not know whether to begin with Foundations, a first language, or a specialist path. It measures your ability to operate a tiny program—not prior terminology.
Task 1 · Locate and run
Create a new folder, add a text file and a tiny program that reads it, then run the program from that folder. Record the working directory, file listing, runtime version, command, exit status, and output.
EvidenceAnother learner can recreate the folder and obtain the same output from your instructions.Task 2 · Explain one value path
Write a function that receives three numbers and returns the largest. Demonstrate all-equal, negative, and ordinary inputs. Explain which comparison decides each result.
EvidenceSource, three observed results, and a control-flow explanation that uses the actual values.Task 3 · Diagnose a seeded defect
Move a return statement inside a loop so a total uses only the first item. Reproduce the wrong result, reduce it to two items, trace the first iteration, repair it, and preserve a regression test.
EvidenceThe test fails before the repair, passes after it, and your note explains why indentation changed control flow.Task 4 · Inspect a Web request
Open a public page or local server and use browser tools to record one document request: method, URL, status, content type, and response size. Explain the difference between DNS, HTTP, and HTML.
EvidenceA sanitized request record and three plain-English distinctions.Task 5 · Preserve a version
Initialize version control, commit the working program, change one behavior, inspect the difference, and create a second focused commit. Restore or reproduce the first behavior without deleting the repository.
EvidenceStatus, diff, log, and exact recovery command with readable commit messages.
Interpretation
If Tasks 1 or 5 are below 2, begin with Computing & Programming Foundations. If tools are comfortable but Tasks 2 and 3 are below 2, continue Foundations through program structure and debugging, then take Python. If every task reaches 2, choose a specialist assessment below.
Independent builder readiness
Use this after Foundations and one introductory language. It verifies that you can begin, inspect, test, version, and hand off a small program without a tutorial supplying every command.
Task 1 · Define the boundary
Specify a command-line tool that reads a UTF-8 file and reports non-empty line count. State accepted input, output format, encoding policy, maximum size, exit statuses, and what the tool will never modify.
EvidenceA one-page contract precise enough for another learner to implement.Task 2 · Implement and classify failure
Build the tool. Distinguish missing argument, missing file, invalid byte sequence, oversized input, and successful empty input without exposing private content.
EvidenceCommands show the documented output and exit status for every class.Task 3 · Test the boundaries
Create empty, one-line, multiline, whitespace-only, Unicode, invalid-byte, and size-boundary fixtures. Tests must begin from an isolated directory and leave source fixtures unchanged.
EvidenceOne command runs the suite and reports every named case.Task 4 · Debug from evidence
Seed an off-by-one line-count defect. Use the seven-step debugging method to preserve the mismatch, reduce it, inspect state, test a hypothesis, and explain the repair.
EvidenceA completed evidence worksheet and regression test, not only the final diff.Task 5 · Handoff from a clean state
Clone or copy the repository into a clean directory and follow only the README. Verify runtime requirement, setup, ordinary run, tests, failure example, and cleanup.
EvidenceA second-person or clean-directory handoff record with exact commands and results.
Ready when
All critical tasks reach 2 and the clean handoff succeeds. If the contract is unclear, revisit Software Engineering. If implementation or tests fail, return to the corresponding chapters in your first language rather than changing languages.
Frontend Web readiness
Use this before React or a production Web framework. It verifies browser fundamentals, state reasoning, accessibility, network failure, and testing.
Task 1 · Semantic interaction
Build a form that adds named study items to a list. Use native labels, validation, buttons, headings, and status announcements. Complete the journey with keyboard alone and visible focus.
EvidenceHeading outline, accessible names, keyboard steps, validation behavior, and DOM source.Task 2 · Resilient layout
Present the form and list without horizontal document scrolling at 320 pixels, 200% zoom, a long unbroken label, and large text. Respect reduced-motion preference.
EvidenceRecorded viewport checks and identification of any intentional internal scroller.Task 3 · Explicit state transition
Model create, complete, rename, filter, and undo as pure state transitions before DOM rendering. Define outcomes for empty input, unknown identity, repeated completion, and undo with no history.
EvidenceTransition table and tests that run without a browser DOM.Task 4 · Network race and failure
Load fixed remote-style data through a fake transport. Demonstrate loading, empty, success, timeout, invalid data, and reversed response order without allowing an older result to replace a newer one.
EvidenceDeterministic tests and a timeline connecting request identity to committed state.Task 5 · Diagnose one browser layer
Seed either a CSS overflow or duplicate submission defect. Locate it through document, style, script, and network evidence and add regression protection.
EvidenceA reduced page, captured evidence, causal explanation, and passing focused test.
Ready when
Critical tasks reach 2 and no keyboard, state-ownership, or request-order defect remains. Repair document and layout gaps in HTML/CSS; repair runtime gaps in JavaScript; then continue to TypeScript and React & Next.js.
Backend and API readiness
Use this before distributed workflows or production delivery. It verifies domain invariants, HTTP contracts, data integrity, resource authorization, and operational evidence.
Task 1 · Protect a domain invariant
Model enrollment into a course with finite seats. Define identities, allowed states, commands, invariant, and distinct invalid, missing, conflict, and forbidden outcomes.
EvidenceState-transition table and pure tests for ordinary, boundary, repeated, and rejected commands.Task 2 · Write the HTTP contract
Specify request and response examples for create, read, cancel, conflict, validation failure, forbidden access, and idempotent repeat. Include status, headers, body shape, limits, and compatibility rule.
EvidenceContract examples precise enough for an independent client implementation.Task 3 · Enforce data integrity
Design relational tables and one transaction that cannot oversubscribe the last seat under concurrent requests. State constraints, isolation or locking choice, rollback behavior, and retry boundary.
EvidenceSchema, transaction pseudocode or SQL, and a concurrent test or rigorous schedule showing the invariant.Task 4 · Authorize the resource
Given two users and two enrollments, write the lookup and authorization sequence so changing a URL identifier cannot expose or mutate another user’s record.
EvidenceTests for owner, non-owner, absent resource, changed tenant, and privileged role where applicable.Task 5 · Make failure operable
Define request ID, structured logs, safe error response, health, readiness, latency measure, overload behavior, and rollback signal for the service.
EvidenceOne failing request traces from client result to sanitized service evidence and a named recovery action.
Ready when
All critical tasks reach 2; authorization and seat integrity cannot be averaged away. Study Backend & API Engineering for contract or workflow gaps and Database Engineering for isolation, constraints, indexing, or recovery gaps.
Data engineering readiness
Use this before streaming, lakehouse, or orchestration depth. It verifies contracts, row grain, deterministic transformation, reconciliation, replay, and lineage.
Task 1 · State contract and grain
Define an order-item input with field types, units, identifiers, event time, null policy, version rule, maximums, and one-row meaning. Define the intended daily product output grain separately.
EvidenceA versioned contract plus accepted and rejected fixture examples.Task 2 · Transform and reconcile
Decode, parse, validate, quarantine, deduplicate, and transform a fixed snapshot. Prove source count equals accepted plus rejected plus intentionally ignored records.
EvidenceDeterministic outputs, classified failures, counts, hashes, and one command that reproduces the run.Task 3 · Query at the correct grain
Write SQL for daily product quantity and revenue without repeating order-level facts. Add a window calculation and explain partition, ordering, ties, and null behavior.
EvidenceQuery, tiny hand-calculated fixture, result, and row-grain explanation before and after each join.Task 4 · Replay without duplication
Run the same snapshot twice, interrupt before publication, and restart. The last verified output must remain authoritative and logical records must not duplicate.
EvidenceRun identities, staging and publication rule, repeated hashes or explained nondeterminism, and restart results.Task 5 · Trace lineage and change
For one output row, record source snapshot, source record, contract version, transform version, run, quality decision, and publication. Propose one compatible and one incompatible schema change.
EvidenceTrace record and explicit consumer behavior for both changes.
Ready when
Contract, reconciliation, and replay tasks reach 2. Repair Python/SQL fluency first if implementation obscures meaning; study Database Engineering for source authority and Data Engineering for replay, quality, history, lineage, and operations.
AI, LLM, and RAG readiness
Use this before agent workflows or model promotion. It verifies leakage boundaries, baselines, retrieval evidence, sliced evaluation, authority, and safe abstention.
Task 1 · Protect the evaluation boundary
Given repeated users and time-ordered records, define train, validation, and test splits that prevent the same user or future information leaking into evaluation. State what the test set may influence.
EvidenceSplit code or pseudocode, overlap assertions, time assertions, and a plain-English leakage explanation.Task 2 · Establish a baseline
Choose a simple non-model or simple-model baseline and one metric connected to error cost. Calculate it on a tiny fixture and explain why accuracy alone may mislead.
EvidenceInputs, calculation, baseline result, error-cost statement, and one metric limitation.Task 3 · Separate retrieval from generation
For answerable, unanswerable, conflicting, and unauthorized questions, record retrieved document identities and whether relevant authorized evidence appears before judging prose quality.
EvidenceRetrieval results, recall-style judgment, authorization decision, and expected abstention cases.Task 4 · Evaluate slices and failures
Compare a candidate with the baseline across at least three meaningful slices. Preserve per-case outcomes, evaluator rationale, uncertainty or sample limits, latency, and cost.
EvidenceAggregate table linked to individual failures and a decision that cannot hide a critical slice.Task 5 · Enforce authority and rollback
Define how tenant access, document deletion, prompt injection, citation support, abstention, model version, prompt version, corpus version, and policy version are tested and rolled back.
EvidenceRelease gates with at least one security invariant and a rollback matrix for independently versioned parts.
Ready when
Evaluation, retrieval, and authority tasks reach 2. Study Python for AI & Machine Learning for pipeline or metric gaps, Data Engineering for corpus evidence, and LLM & RAG Systems before adding agents.
Systems and reliability readiness
Use this before cloud orchestration depth. It verifies process lifecycle, files and descriptors, request-path tracing, bounded concurrency, service objectives, and recovery.
Task 1 · Own the process lifecycle
Start a tiny local service from one known artifact. Record working directory, executable, arguments, identity, environment policy, PID, graceful stop, exit status, and cleanup.
EvidenceOne command or documented sequence starts, verifies, stops, and cleans the exact process without broad termination.Task 2 · Account for files and descriptors
Record configuration file identity, permissions, open files or sockets, soft limit, and descriptor count before and during bounded requests. Seed one missing-file or permission failure.
EvidenceThe failure is located at the file/process boundary and all resources return near baseline after cleanup.Task 3 · Trace one request
Map name or literal address, route, listener, client/server socket tuple, HTTP method and path, status, body limit, request ID, and application result on loopback.
EvidenceA layer-by-layer notebook distinguishing DNS, routing, TCP, HTTP, and application evidence.Task 4 · Bound concurrency and deadlines
Run a safe local load with a declared concurrency limit and total deadline. Classify success, timeout, connection, protocol, and application failures and prove cancellation releases work.
EvidenceConcurrency never exceeds the bound; every input reaches one terminal result; resources clean up.Task 5 · Define objective and recover
Choose one user-visible service indicator and objective. Seed an occupied port or bad artifact, detect impact, restore the known version, and verify ordinary service.
EvidenceIndicator definition, incident timeline, exact rollback target, post-recovery check, and retained evidence.
Ready when
Lifecycle, request tracing, and recovery reach 2. Study Linux, Networking & SRE for host or network gaps and DevOps Engineering before Cloud Native & Kubernetes.
Security engineering readiness
Use this after Web, backend, database, and host fundamentals. It verifies threat modeling, resource authorization, injection boundaries, secrets, dependencies, detection, and recovery.
Task 1 · Build a concrete threat model
For a small document service, identify assets, actors, identities, entry points, trust boundaries, authority, abuse cases, security invariants, and recovery assumptions.
EvidenceEvery proposed control maps to a named threat and every critical asset has an owner and lifecycle.Task 2 · Test resource authorization
Specify and test owner, non-owner, changed tenant, missing resource, revoked session, privileged support, and list filtering. Do not trust a client-supplied owner field.
EvidenceAuthorization is enforced at each resource lookup and mutation, with safe indistinguishable outcomes where policy requires.Task 3 · Contain hostile input
Choose one SQL, HTML, command, path, or document-processing boundary. Demonstrate that structure and data remain separated, input is bounded, output context is safe, and rejection leaves valid state.
EvidenceAdversarial fixtures fail safely without executing injected structure or leaking sensitive diagnostics.Task 4 · Protect secrets and supply chain
Map secret creation, storage, delivery, use, logging, rotation, revocation, and deletion. Record direct dependencies, lockfile, artifact identity, vulnerability response, and build provenance boundary.
EvidenceNo secret enters source, artifact, URL, or log; one dependency can be identified, updated, tested, and rolled back.Task 5 · Detect, contain, and recover
Seed a safe unauthorized attempt in a disposable environment. Define detection, evidence retention, session or credential containment, user impact check, restore, and post-incident verification.
EvidenceA timeline and response plan prove containment and recovery without relying on attacker-controlled content.
Ready when
Authorization, hostile input, and response reach 2; security invariants cannot be averaged away. Repair missing system models first, then use Cybersecurity & Application Security to connect controls, detection, supply chains, cloud boundaries, and rehearsed recovery.
Mobile and desktop application readiness
Use this before a full installable product. It verifies lifecycle-safe state, persistence migration, offline synchronization, accessibility, packaging, update, and rollback.
Task 1 · Preserve lifecycle state
Model an editable note through new, modified, saving, saved, conflict, and failed states. Recreate the view or process while work is in progress without duplicating effects or losing committed state.
EvidenceState/event table and deterministic tests for recreation, repeated event, cancellation, and failure.Task 2 · Migrate durable data
Define version 1 and version 2 stored documents, forward migration, invalid-data policy, backup or atomic replacement, and behavior when a newer unknown version appears.
EvidenceOld fixture migrates, current fixture remains stable, malformed input fails safely, and rollback policy is explicit.Task 3 · Resolve offline synchronization
Create two offline edits to the same record. Define identity, operation ordering, retry, idempotency, conflict detection, user choice, and which authority commits the resolved state.
EvidenceTimeline and tests for replay, duplicate operation, deletion, and a genuine conflict.Task 4 · Verify accessible interaction
Specify focus or accessibility traversal, names, errors, dynamic status, text scaling, contrast, reduced motion, and keyboard or switch access for the critical journey.
EvidencePlatform-appropriate inspection plus a complete non-pointer interaction record.Task 5 · Package, update, and recover
Define artifact identity, signing or trust boundary, configuration, install, update, schema compatibility, health signal, bad-update rollback, and user-data preservation.
EvidenceA release checklist identifies the exact rollback artifact and proves retained user state remains readable.
Ready when
Lifecycle, migration, and release recovery reach 2. Strengthen language async and testing first, then use Mobile Engineering or Desktop Application Engineering for product lifecycle depth.
05 / AFTER THE CHECK
A failed task is a routing result.
Do not repeat the whole curriculum or switch fields because one boundary is missing. Repair the earliest prerequisite that explains the evidence.
- Keep the first attempt.
It is the baseline against which learning can be measured.
- Name the earliest missing boundary.
Choose the course chapter that teaches that mechanism, not a broad topic label.
- Practice one variation.
Complete the chapter loop and one nearby exercise without copying.
- Repeat the failed task cleanly.
Do not edit the old artifact into a pass; prove you can reconstruct the result.
- Advance to Project Lab.
After path readiness, integrate the skill under a larger system boundary and acceptance checklist.