No waitlist. The work decides.

Ship and Sustain a Reliable Service

4 milestones · 12 weeks

Set real SLOs for critical services, measure the actual reliability gap against them, then close it and defend the change to a panel of practitioners.

Lead Incidents From Alert to Resolution

4 milestones · 12 weeks

Audit a real incident response process against MTTD/MTTR and post-mortem completion, fix the specific failure modes, then show the improved metrics.

Operate as a Staff Engineer

5 milestones · 20 weeks

Staff Engineer is the most misunderstood title in the industry. Many companies hand out the title for tenure or as a retention tool, without the person ever doing Staff-level work. This outcome's proof standard is about the WORK, not the title — every milestone tests for influence without authority, the hardest skill at this level. The defining shift from Senior to Staff is scope: a Senior engineer is excellent within a defined problem. A Staff engineer identifies which problems matter before anyone assigns them, and influences outcomes across teams they do not manage.

Reduce Team Time-to-Merge by 50%

0 milestones · 12 weeks

Diagnose and fix the bottlenecks in your team's code review process to halve average PR time-to-merge — before and after metrics required.

Build Something Physical

3 milestones · 10 weeks

Design and build a physical object or device — a 3D printed model in Tinkercad, an LED circuit, a woodworking project, a cardboard automaton, or anything you made with your hands and tools. A photo or short video of the finished project is proof. What you build and the tools you use are entirely your choice.

Discover a Problem and Defend Your Thesis

3 milestones · 16 weeks

Investigate a real problem through primary and secondary research, evaluate solution approaches with ethical analysis, and defend your chosen solution direction before a faculty panel. Proof requires: a problem scoping document with primary research from real affected people, a solution comparison with ethical risk analysis, and a defended thesis with a documented panel challenge record and revision note.

Launch a Working MVP with Real Users

3 milestones · 20 weeks

Run user research with at least five affected people, write an evidence-based MVP specification, build a deployed V1.0 product, and document real usage by at least three people outside the family. Proof requires: user research notes, a feature-to-evidence specification, a change log tracing V1.0 decisions to user feedback, and a faculty attestation confirming the launch is real.

Deepen with Subject Methods and Build V2.0

3 milestones · 20 weeks

Apply rigorous academic methods from at least two school subjects to analyse V1.0 and drive V2.0 improvements. Proof requires: a faculty-reviewed integration plan naming specific curriculum methods, a methods log tracing each analysis result to a V2.0 decision, a deployed V2.0, and a before/after integration report with faculty attestation confirming the subject methods are genuine curriculum techniques.

Scale to 50+ Users and Defend at Oral Examination

3 milestones · 24 weeks

Deploy through a documented institutional partnership to at least 50 real community users, measure real-world outcomes, write a 4000-word Extended Essay grounded in your project's own primary evidence, and defend the full four-year project in an oral examination with an independent external examiner. Proof requires: partnership documentation, usage evidence for 50 core-task completions, an impact report, the final Extended Essay, and an examination record with challenge questions.

Software Requirements Specification

0 milestones · 6 weeks

Produce a Software Requirements Specification (SRS) for a real or realistic software system using IEEE 830 or an equivalent structured format. The SRS must cover: functional requirements (at least 15 numbered, testable requirements with input, output, and boundary conditions), non-functional requirements (performance, security, availability, maintainability — each with a measurable acceptance criterion), assumptions and constraints documented explicitly, and use-case or user-story mapping to each requirement. The system described must be real or realistic enough that the requirements can be verified against it. Proof artifacts: the SRS document (design artifact) and a review record in which a software engineer challenges at least 3 requirements for completeness or consistency — with your written responses (documentation artifact). Accessible: no special software required — the SRS is a document artifact. Verification: a software engineer or systems architect who challenges 'this requirement is ambiguous — how would you test it?' for at least 3 requirements before endorsing. Generic fictional systems are not accepted; the reviewer must be able to ask grounding questions about real constraints.

Software Architecture Design Document

0 milestones · 8 weeks

Produce a software architecture document for a real or realistic system covering: a component diagram showing at least 4 logical components with named interfaces, an interface specification for each inter-component communication (message format, protocol, error handling), documented architectural decisions with at least 3 alternatives considered per major decision and explicit trade-off rationale, and a quality attribute analysis (how the architecture addresses 2 chosen quality attributes such as scalability, fault tolerance, or security). Diagrams produced using draw.io (free), Lucidchart free tier, or PlantUML (free, text-based). Proof artifacts: the architecture document with diagrams (design artifact) and a documented trade-off rationale for the primary architectural decisions (documentation artifact). Accessible: draw.io and PlantUML are fully free; no hardware or software license required. Verification: a senior software engineer or architect challenges 'why did you choose this component boundary?' and 'what breaks first when load doubles?' — you must answer in terms of the specific system, not general principles.

Software Test Plan and Coverage Analysis

0 milestones · 6 weeks

Produce a software test plan and coverage analysis for a real software system (your own or an open-source system). The test plan must include: a testing scope statement identifying what is in and out of scope with rationale, a test strategy for at least 3 test levels (unit, integration, system), documented test cases for at least 20 representative scenarios with expected results, risk-based test prioritisation explaining why higher-risk areas receive more coverage, and a coverage analysis showing which code paths, branches, or requirements are covered by the documented tests. Tools: pytest-cov, coverage.py, JaCoCo, or equivalent (all free). Proof artifacts: the test plan document (design artifact) and the coverage report with gap analysis (analysis artifact). Accessible: all coverage measurement tools are free and open-source. Verification: a software engineer reviews the coverage gap analysis — 'these untested paths represent what risk?' — and the test case rationale for at least 5 cases.

Deployment Plan and Operations Runbook

0 milestones · 5 weeks

Produce a deployment plan and operations runbook for a real software system covering: a step-by-step deployment procedure with pre-conditions, execution steps, and post-deployment verification for at least one environment (staging or production), a rollback procedure with decision criteria for when to roll back, an incident response procedure for the 3 most likely failure modes with documented detection, diagnosis, and recovery steps, and an on-call guide documenting the operational state of the system (what healthy looks like, what alerts fire under what conditions). Preferred proof: the runbook for a live system you operate. Accessible alternative: a runbook for a real open-source system you have deployed locally (Railway free tier, Render free tier, or similar) — documented evidence of actual deployment required, not a hypothetical. Proof artifacts: deployment procedure document (design artifact) and runbook with rollback procedure (documentation artifact). Verification: someone who has operated production systems reviews 'would I be able to bring this system back up from a cold start using this runbook alone?' and 'what happens if the rollback itself fails?'

Engineering Design Review

0 milestones · 4 weeks

Conduct a formal engineering design review of a real software design — either as author defending your own design, or as a reviewer leading the review of a peer's design. The review must follow a structured format: design document distributed at least 48 hours before the review, a written review checklist with specific questions prepared in advance, the review session with documented findings (issues, action items, and their severity), and a revision record showing what changed as a result of the review. Preferred proof: a design review in a professional or team context. Accessible alternative: a peer design review conducted with at least 2 qualified reviewers from an open-source project community, a university engineering programme, or a professional network — the design reviewed must be non-trivial (an architectural decision, a data model, or a protocol specification, not a single function). Proof artifacts: the review checklist and findings (analysis artifact) and the revision record documenting what changed and why (documentation artifact). Verification: one of the reviewers confirms the review was substantive — not rubber-stamping — and at least one finding resulted in a real change to the design.

Mechanical CAD Model and Engineering Drawing

0 milestones · 6 weeks

Produce a fully constrained 3D CAD model of a real mechanical component and a 2D engineering drawing to engineering drawing standards. The component must be non-trivial (at least 5 geometric features, not a simple block or cylinder). The engineering drawing must include: all views necessary to fully define the geometry, dimensions with correct GD&T callouts for at least 3 critical features, surface finish specification, material callout with grade/standard (e.g. Al 6061-T6, S275 structural steel), and a title block with part number, revision, scale, and projection standard. Preferred proof: a component designed for a real project (personal, academic, or professional) with physical fabrication evidence (photo of machined or 3D-printed part). Accessible alternative: a CAD model and drawing produced in FreeCAD (free, open-source) or Onshape (free education tier) for a realistic component scenario — no physical fabrication required, but the drawing must be to standard. Proof artifacts: the CAD file and engineering drawing (design artifact) and the material + tolerance specification (documentation artifact). Verification: a mechanical engineer reviews the drawing for standards compliance — 'these tolerances cannot be manufactured — what process were you specifying for?' and 'what does this GD&T callout mean in inspection terms?'

Mechanical Structural Analysis

0 milestones · 8 weeks

Perform structural analysis of a real mechanical component or assembly under defined loading conditions, documenting all assumptions, methodology, and results. The analysis must specify: the loading conditions (forces, moments, pressures) with justification for the values chosen, material properties with source reference, a documented mesh or calculation methodology showing how the problem was discretised or simplified, safety factor calculation with reference to the applicable standard (e.g. ASME, BS, or EN standard for the application), and a sensitivity analysis testing at least one assumption (what happens if the assumed load increases by 20%). Preferred proof: FEA on a component from a real project using professional software. Accessible alternative: FEA using SimScale free tier (browser-based, no install) or ANSYS Student Edition (free download) for a realistic component scenario, OR a fully documented hand calculation for a statically determinate structure using first principles and free textbook references. Proof artifacts: the analysis inputs and results (analysis artifact) and the documented methodology with assumptions (documentation artifact). Verification: a mechanical or structural engineer reviews the methodology — 'your mesh is coarser near this stress concentration; what effect does that have on your result?' — and the safety factor rationale.

Mechanism Design and Kinematic Analysis

0 milestones · 6 weeks

Design a mechanism for a specific function and perform a complete kinematic analysis covering: a kinematic diagram showing all links, joints, and degrees of freedom with Gruebler's criterion applied, position analysis (at least 3 positions in the motion cycle), velocity and acceleration analysis for the critical position, force analysis under the specified load, and identification of any design constraints or singularities (positions where the mechanism locks or becomes indeterminate). The mechanism must be non-trivial — at least a 4-bar linkage or equivalent complexity. Preferred proof: a mechanism designed for a real application with physical prototype evidence. Accessible alternative: kinematic analysis of a documented mechanism scenario using FreeCAD's kinematic analysis module or hand calculation with velocity polygon diagrams — equivalent rigor required. Proof artifacts: the kinematic diagram and analysis (design artifact) and the force analysis results with documented methodology (analysis artifact). Verification: a mechanical engineer reviews the kinematic analysis — 'what is the mechanical advantage at this position, and how does it change across the motion cycle?' — requiring you to reason from your own analysis.

Engineering Materials Selection

0 milestones · 5 weeks

Perform a structured materials selection exercise for a specific engineering application, documenting the full selection process from requirements to final recommendation. The exercise must include: translation of functional requirements into material property targets (at least 4 performance indices with calculated values), screening using an Ashby property chart or equivalent to eliminate unsuitable material classes, ranking of at least 5 candidate materials using a weighted decision matrix (criteria weights justified, not arbitrary), a documentation of supporting information searched for each shortlisted material (manufacturer datasheets, standards, published test data), and a final recommendation with an explicit cost-vs-performance trade-off discussion. The application must be real or physically grounded — not abstract. Accessible alternative: free Ashby chart resources from open mechanical engineering textbooks (Ashby's Materials Selection in Mechanical Design is in many university open-access repositories); CES EduPack student version is free. Proof artifacts: the decision matrix and screening analysis (analysis artifact) and the materials selection report with recommendation (documentation artifact). Verification: a mechanical engineer or materials specialist challenges the decision matrix weighting — 'if fatigue life was 3× more important than density, would your recommendation change?' — requiring you to defend your criteria priorities.

Mechanical Engineering Design Report

0 milestones · 8 weeks

Produce a complete mechanical engineering design report for a real engineering design problem, integrating requirements, design alternatives, analysis, and final design into a single coherent document. The report must include: a problem statement with quantified design requirements and constraints, at least 3 design alternatives with documented screening criteria, the selected design with justification referencing analysis results (structural, kinematic, or materials — from earlier outcomes or conducted for this report), a risk assessment identifying the top 3 technical risks with proposed mitigations, and an implementation recommendation. Preferred proof: a real design project report (academic, personal, or professional). Accessible alternative: a design report for a well-specified open engineering challenge (bridge design challenge, FIRST Robotics design brief, or equivalent publicly available problem specification). Proof artifacts: the design alternatives comparison (design artifact), the analysis summary referenced within the report (analysis artifact), and the complete report document (documentation artifact). Verification: a mechanical engineer reviews the design justification — 'your analysis shows margin of X; would you accept this in a real production context?' and 'what is the first thing that will fail in service?' — requiring specific answers from your own design.

Circuit Analysis and Design

0 milestones · 6 weeks

Design a real electronic circuit for a specific purpose and document the design with analysis. The circuit must be non-trivial — at minimum an active circuit with at least one transistor or op-amp stage, or a passive filter with defined frequency response specifications. Required documentation: a complete schematic with all component values and part references, DC operating point analysis showing all node voltages and branch currents, AC analysis or transient simulation demonstrating the circuit meets its specification, component selection rationale for at least 3 key components (with alternatives considered), and a tolerance analysis identifying which component tolerances most affect performance. Preferred proof: a physically built circuit with oscilloscope or multimeter measurements demonstrating the circuit meets specification. Accessible alternative: LTspice simulation (free, Windows and Mac) or Falstad Circuit Simulator (browser-based, no install required) with documented simulation results and methodology. Proof artifacts: the schematic and component selection (design artifact) and the simulation or measurement results (analysis artifact). Verification: an electrical engineer reviews the design — 'what happens to your output voltage if this supply varies by ±10%?' — requiring you to reason from your own circuit analysis.

Digital Logic Design

0 milestones · 6 weeks

Design a digital logic system to implement a defined Boolean function or finite state machine. The system must be non-trivial — at minimum a 4-bit binary counter with enable and reset, an 8-to-1 multiplexer with documented truth table, or an equivalent sequential or combinational circuit. Required documentation: a complete logic diagram or HDL description, a truth table or state transition table, timing analysis identifying critical path and maximum clock frequency (for sequential circuits), and a documented test plan with at least 10 test vectors with expected and actual results. Preferred proof: an FPGA implementation or physical breadboard build with documented test results. Accessible alternative: Logisim-Evolution (free, open-source, runs locally) or EDA Playground (browser-based, supports VHDL and Verilog) with simulation waveform output. Proof artifacts: the logic diagram or HDL description (design artifact) and the truth table and test results (analysis artifact). Verification: a digital electronics engineer reviews the timing analysis — 'what is your setup time margin at this clock frequency, and what happens if it is violated?' — requiring specific reasoning from your own design.

Power Systems Analysis

0 milestones · 8 weeks

Perform a power systems analysis for a defined electrical network — either a real distribution network (using public utility data) or a documented study network. The analysis must cover: a single-line diagram of the network with all bus voltages, line impedances, and load specifications, a load flow analysis calculating real and reactive power flows on all branches and bus voltages under normal operating conditions, a fault analysis calculating fault current for at least one three-phase bolted fault at a specified bus, and a protection coordination analysis identifying whether the existing protection devices (or proposed devices) will correctly isolate the fault. Preferred proof: analysis of a real utility or industrial distribution network using professional software. Accessible alternative: pandapower (Python library, free and open-source) or OpenDSS (free, from EPRI) applied to a published IEEE test network (IEEE 9-bus, 14-bus, or 30-bus systems — all publicly available). Hand calculation for a simplified 3-bus network is also accepted with documented methodology. Proof artifacts: the single-line diagram and network specification (design artifact) and the load flow and fault analysis results (analysis artifact). Verification: a power systems engineer reviews the fault analysis — 'at this fault level, does the upstream breaker clear within its rated interrupting time?' — requiring you to reason through your own protection coordination.

Signal Processing Application

0 milestones · 6 weeks

Design and implement a signal processing application for a defined signal and task: filter design (low-pass, high-pass, band-pass, or band-stop), spectral analysis, noise reduction, or feature extraction. The application must be non-trivial — a real signal with real noise characteristics, not a textbook ideal case. Required documentation: signal specification (frequency content, noise type, SNR, sample rate), filter or algorithm specification (design method, order, cutoff frequencies, ripple), frequency response plot of the designed filter or algorithm, performance validation comparing before and after processing with quantitative metrics (SNR improvement, stopband attenuation achieved), and a documented sensitivity analysis testing at least one design parameter. Preferred proof: a real signal from physical measurement hardware. Accessible alternative: Python with scipy.signal and numpy (free), MATLAB Online free tier, or GNU Octave (free) applied to publicly available signal datasets (PhysioNet ECG data, NOAA seismic data, urban noise datasets). Proof artifacts: the filter or algorithm specification (design artifact) and the frequency response and performance validation plots (analysis artifact). Verification: an electrical or signal processing engineer reviews the performance analysis — 'this filter removes the noise but what useful signal components are also attenuated?' — requiring you to quantify the trade-off.

Electronics Engineering Design Report

0 milestones · 8 weeks

Produce a complete electronics engineering design report for a real electronics design problem, integrating specifications, design decisions, analysis, and test results into a single coherent document. The report must include: a system specification with quantified performance requirements, a block diagram showing the overall system architecture with signal flow, detailed sub-circuit design documentation with schematic and analysis for each stage, a test plan with documented results demonstrating the system meets its specification (or a clear analysis of where it falls short and why), and a bill of materials with sourcing notes. Preferred proof: a real electronics project report with physical test results. Accessible alternative: a design report with simulation-based validation using LTspice or Falstad — simulation results must demonstrate the design meets its specification under the relevant operating conditions. Proof artifacts: the system schematic and block diagram (design artifact), the per-stage analysis and test results (analysis artifact), and the complete report (documentation artifact). Verification: an electrical engineer reviews the test results — 'your simulation shows this margin; how confident are you this would hold with real component tolerances?' — requiring specific reasoning from your own design and component choices.