From study outcomes to engineering evidence
On this page
- General software engineering
- Systems and infrastructure engineering
- GPU and performance engineering
- ML engineering and research-oriented AI work
- Embedded and robotics software
- Scientific and simulation software
- A portfolio report that a reviewer can challenge
- Choosing the next depth rather than studying everything at once
This book is a learning system, not an employment credential or a guarantee of mastery. A reviewer can evaluate a reproducible project, a correct proof, a clear design tradeoff, or a well-diagnosed failure. They cannot infer those abilities from a book’s completion checkbox or a large repository’s line count. Experience you already have, such as shipping a game, running a production service, or building hardware, supplies useful contexts, while the diagnostics prevent that experience from being mistaken for uniform competence in every underlying subject.
Each role example below comes from an official posting or careers page inspected on 5 September 2026 and listed in the source register. Postings change and close, so read the current version before relying on any detail. For frontier AI, vehicle, and aerospace work, F00 and EL00 map current postings in more detail.
General software engineering#
The foundation is C01–C08 and C11–C17, supported by discrete reasoning and the mathematics relevant to the application. J01 demonstrates contracts, parsing, tests, and command-line design; J02 demonstrates algorithm choice and correctness; J03 demonstrates state and failure handling. Further depth includes maintaining a larger codebase over time, reviewing others’ changes, working with ambiguous requirements, deployment practices, and collaborating through incidents and revisions.
Readiness evidence is an unfamiliar bounded task completed independently with tests and a clear explanation of edge cases. A polished implementation that cannot be modified without AI assistance is weaker evidence than a smaller system whose behavior and limitations the learner can defend. Interviews are one assessment format; routine engineering also requires reading existing code, writing documentation, and making safe changes under constraints.
Systems and infrastructure engineering#
Prioritize C03, C06–C14, T01, and J03/J05. The central abilities are ownership, resource accounting, concurrency, storage semantics, failure recovery, and performance measurement. Further depth includes operating systems, networking internals, durable storage, distributed protocols, production observability, incident response, and substantial C++ or another systems language.
An official OpenAI Compute–Storage posting emphasizes storage services, data movement, replication/recovery, performance, and operational reliability; Rust and Kubernetes are details of that particular stack. Those specifics are not universal requirements for all AI-laboratory roles. The durable preparation is the ability to build and reason about reliable infrastructure, not merely recognizing those tool names. [ROLEOAI]
GPU and performance engineering#
Prioritize A01–A02, A05, C03, C09–C10, T01–T02, and the J05 measurement discipline. Useful evidence includes a verified kernel or CPU/GPU comparison with transfer costs, numerical error, workload, and environment clearly reported. Further depth includes actual GPU tooling, hardware architecture, parallel algorithms, profiling, memory-system behavior, and well-tested performance-sensitive code.
NVIDIA’s official indexed posting for Senior System Software Engineer, Performance–CUDA Driver describes analyzing application bottlenecks across software and hardware and working near drivers and operating systems. The indexed official text was available, while the dynamic detail page did not render its complete text when checked. This is a representative role example, not confirmation of live vacancy status or a universal entry-level requirement. [ROLENV]
ML engineering and research-oriented AI work#
ML engineering builds on A01–A06, T03, C11–C14, and reliable software practice. Evidence should include data separation, reproducible training, gradient checks, error analysis, and an honest account of dataset limitations. Additional work includes real data pipelines, model monitoring, deployment constraints, experiment management, and careful evaluation under distribution change.
Research-oriented work adds deeper probability, statistics, optimization, linear algebra, scientific reading, and the ability to formulate and test a novel hypothesis. Reproducing a small operation from a paper is an entry skill; reproducing an experimental claim, identifying its assumptions, and designing a useful extension are more demanding. A small educational classifier does not demonstrate the ability to train a frontier model.
Anthropic’s inspected Research Engineer, Model Evaluations posting emphasizes defensible evaluations, reliable distributed evaluation infrastructure, debugging anomalous results, and communicating findings. It illustrates that AI work can depend as much on measurement and infrastructure as on inventing a network architecture. Its listed experience and role expectations are specific to that posting, not to every position at the organization. [ROLEAN]
Embedded and robotics software#
Prioritize A01, A03, A06, C03, C09–C10, C14, C17, and T04. Useful evidence includes a simulated controller with explicit units, timing, sensor faults, saturation, and validation cases. Further preparation includes electronics, hardware interfaces, real-time scheduling, control theory, instrumentation, and supervised testing on physical systems.
SpaceX’s inspected C++ Dragon role emphasizes software configuration, verification, investigation of test results, and interdisciplinary hardware/software troubleshooting. Tesla’s official indexed Body Controls role describes real-time C work, firmware architecture, hardware bring-up, tests, and electrical-engineering fundamentals. Tesla’s dynamic page did not expose the full text during direct retrieval, so the record distinguishes indexed official text from a fully rendered current posting. Neither description makes an educational simulator equivalent to flight or vehicle software. [ROLESPX][ROLETESLA]
Scientific and simulation software#
Prioritize the full calculus pathway, A01–A06, C14, J04, and T05. Evidence should include model assumptions, dimensional analysis, analytic validation, convergence studies, conserved quantities, and reproducible reports. Further depth depends strongly on domain: mechanics, electromagnetism, fluids, numerical PDEs, uncertainty quantification, or other specialized science.
NASA’s engineering careers overview was inspected, but no specific current NASA software vacancy was used to define this curriculum. It describes a broad engineering setting rather than one uniform job profile. Scientific computing, mission operations, embedded flight software, and research roles can require different domain knowledge and validation processes. Consult the actual role description and applicable institutional requirements when choosing the next specialization. [ROLENASA]
A portfolio report that a reviewer can challenge#
For each project, write a short problem statement, constraints and nonrequirements, architecture, correctness argument, test plan and results, measurement methodology, limitations, and reproduction commands. Include the exact revision and environment. Explain what you implemented unaided, what assistance you used, and what you verified yourself. A statement such as “AI helped generate the first test outline; I implemented the transaction, found and fixed the duplicate-effect bug, and can reproduce the failure” is more informative than hiding assistance or claiming all output was independently authored.
A design-review rehearsal can use J05: explain why floor is required for negative cells, why candidate filtering still needs an exact containment test, how the immutable snapshot stays alive, and why the measured speedup is workload-specific. A debugging rehearsal can use J03: place a crash before and after commit and predict the next retry. A proof rehearsal can use J02: explain the heuristic’s lower-bound condition and construct a case where a changed movement model invalidates it. These are suggested rehearsals of already assigned work, not additional unsolved exercises.
Choosing the next depth rather than studying everything at once#
If you are taking a course, keep its current topic as the mathematics priority. Use diagnostic evidence to choose one computing gap. After the common core, start with the track closest to the work you want to do, and change tracks when sustained independent work shows greater interest and fit. A focused month of building, measuring, and revising one subsystem is more interpretable evidence than a claim to specialize in all five areas of T01–T05 at once.
Advanced specialization requires repeated success on unfamiliar tasks, not merely one project. Research-level work requires a defensible contribution relative to existing knowledge and appropriate external scrutiny. None of the role examples or readiness rubrics guarantees hiring, a grade, or qualification for safety-critical work. They identify the kinds of evidence to develop and the further depth still needed.