Skip to main content

Cross-Cutting Engineering Tracks

These five tracks run across multiple semesters. They are not separate phases -- they should become habits integrated into your daily engineering practice.

Track A: Testing & Verification​

note

Starts in Semester 0. The roadmap should not produce someone who can design systems but cannot prove changes are safe.

Progression by Semester​

SemesterSkillsExpected Practice
0-2Unit tests, assertions, basic test organization, regression mindsetEvery exercise has tests
3Testable design, seam creation for refactoring, characterization testsRefactors are protected by tests
4-5Integration tests, concurrency/system tests, database testsMajor systems have integration checks
6-7Contract tests, API tests, architecture fitness checksDesign docs include verification strategy
8-9Cloud environment tests, infrastructure validation, E2E production verificationDeployed systems have test suites
10Full test strategy on capstone projectCapstone has comprehensive test coverage

Outputs by Degree End​

  • Every meaningful project has tests
  • Refactors are always protected by tests
  • Major systems have integration and E2E checks
  • Design docs include verification strategy

Track B: Git, CI/CD & Release Engineering​

note

Starts in Semester 0. A project-heavy roadmap without disciplined collaboration and delivery practice is incomplete.

Progression by Semester​

SemesterSkillsExpected Practice
0-1Commits, branches, merge/rebase basics, PR hygieneGit-based workflow from week 1
2-3Code review habits, commit discipline, automated lint/test pipelinesPRs with review notes
4-5Build automation, release workflows, artifact/version managementProjects have CI
6-8Trunk-based or branch-based strategy tradeoffs, deployment safety, rollbackRelease notes exist
9Infrastructure-as-code versioning, deployment pipelinesFull CI/CD pipeline
10Full release engineering on capstoneProduction deployment with rollback

Core Resources​

  • Pro Git
  • Software Engineering at Google
  • GitHub Actions documentation

Outputs by Degree End​

  • Each project uses version control professionally
  • Each substantial project has CI
  • Release notes and rollback plans exist for production-style systems

Track E: Engineering Fundamentals​

note

Starts in Semester 0. Strong engineers need command-line fluency, debugging discipline, and the ability to read technical documentation without being handheld.

Progression by Semester​

SemesterSkillsExpected Practice
0-1Terminal basics, filesystem fluency, editor workflow, reading technical docs, simple debuggingEvery repo task can be done from terminal and notes include command evidence
2-3Runtime inspection, tracing logic errors, profiling basics, technical writing for implementationsAlgorithm and design work includes debugging notes and short design explanations
4-5Linux workflow, compiler/build output, memory debugging, network inspection, shell-first debuggingSystems projects are traced, inspected, and explained with command-line evidence
6-8Performance investigation, design-doc writing, ADR literacy, operational debuggingMajor projects include written decisions and debugging/performance notes
9-10Production debugging, logs/metrics-driven investigation, runbooks, docs-first operationsCapstone includes runbooks, troubleshooting notes, and production-style diagnosis

Outputs by Degree End​

  • The learner is comfortable working from terminal, editor, and docs rather than only GUI flows
  • Major projects include debugging notes, performance notes, or troubleshooting records
  • Design decisions are written clearly enough for another engineer to follow
  • Official documentation is used directly in tooling-heavy phases

Track C: Security Engineering​

warning

Starts in Semester 4. Security should not appear only at the end of the roadmap.

Progression by Semester​

SemesterSkillsExpected Practice
4Memory safety awareness, undefined behavior, input validation, secure coding basicsSecure coding checklist for C code
5Network security fundamentals, auth basics, transport security, attack surface awarenessSecurity review on networked projects
6-7Data security, secrets handling, access control, threat modeling, API securityThreat model for major projects
8Security reviews, architecture risks, reliability/security tradeoffs, incident readinessSecurity checklist in architecture reviews
9-10Cloud security posture, IAM design, supply chain security, infrastructure hardeningCapstone security review

Outputs by Degree End​

  • Threat model for major projects
  • Secure defaults in APIs and services
  • Security checklist attached to architecture reviews

Track D: Observability, Reliability & SRE​

note

Starts in Semester 5. Systems engineering includes knowing whether a system is healthy, not just how to build it.

Progression by Semester​

SemesterSkillsExpected Practice
5Logs, metrics, traces, basic monitoringService projects expose telemetry
6Reliability thinking, failure modes, backpressure, recovery behaviorFailure-mode analysis in projects
7-8SLIs, SLOs, error budgets, alert design, incident response, postmortemsAt least one project has an SLO
9Cloud-native observability, managed monitoring, infrastructure healthObservability dashboard
10Full observability stack on capstone, production dashboards, operational readinessCapstone has monitoring and alerting

Reference Concepts​

  • Service Level Indicators (SLIs)
  • Service Level Objectives (SLOs)
  • Error budgets
  • Incident response
  • Postmortem culture

Outputs by Degree End​

  • Every service project exposes health and telemetry
  • At least one major project has an SLO and alerting model
  • Postmortem templates are used for failures found during projects