Cloud Engineer
30hRuns the infrastructure a product sits on: event-driven services, storage and access.
- Object storage
- Event triggers
- IAM
- Serverless
A track is one job title and 30 hands-on hours, a subject's worth of effort across a semester. It carries the roadmap for that role, the labs that build it, the project that proves it and the résumé that presents it. You buy it one role at a time.
Run a track the way a department runs a subject, 30hours of hands-on sessions on the calendar, marked as they happen. Every student leaves holding the artefact in their track's line below, which is what makes the résumé at the end checkable.
Runs the infrastructure a product sits on: event-driven services, storage and access.
Moves data from where it lands to where it is queried, without losing rows on the way.
Puts a model inside a product and keeps its latency and token cost inside a budget.
Designs systems where several agents carry a long task and hand off to each other cleanly.
Writes the contracts that hold value, and the indexers that make them readable.
Closes the loop between sensor input and motion, in simulation and then on real hardware.
Ships inside a customer's stack, against their SDK and under their constraints.
Owns a feature from the database to the button, and stays with it after it ships.
A department that needs a role not listed here gets it built, since the machinery is the same and only the roadmap, the sources and the rubric change. Tell us the job title you are placing into.
Four stages, in the order a cohort meets them. The split below is the shape we start from and we move it to fit your calendar, but the roadmap always comes first, and the résumé is always built from work that was already judged.
The role broken into the competencies a hiring team screens for, and a baseline showing where each student currently stands against them. It is the map the other twenty-eight hours follow, and it is why a track is a track rather than a pile of assignments.
Why it moves the number: The roadmap is built from what teams are hiring for now, so the syllabus a department runs stops drifting from the job description it is meant to feed.
The bulk of the track, and the part that recurs. Your manual and SDK docs index into a knowledge graph the mentor answers from; your rubric publishes as weighted checks students read before they start; every submitted repository returns a verdict per criterion, cited to a line of their own code.
Why it moves the number: The per-criterion workbook is the attainment record, produced week by week as the labs run rather than assembled in April from memory.
A single project shaped like the work the role does, run on a semester clock: milestones instead of a Friday deadline, a repository instead of a report, and every claim the team makes about its own project checked against the code it shipped.
Why it moves the number: A project judged on verified claims cannot be bought or copied, because overclaiming caps the score by rule rather than by an examiner's suspicion.
A private challenge against the same role's competency set, judged the way a hiring challenge is and returning a ranked shortlist with evidence attached to every name. The résumé is then built from that evidence and aimed at the role, each line traceable to the repository behind it.
Why it moves the number: The placement cell learns who clears the bar before the drive rather than after it, and a student arrives with a record a recruiter can open and check.
Sponsors fund the events, so every student on the platform has this whether their campus buys a track or not. It is not a stripped tier and there is nothing to unlock, just the outside benchmark that makes a track worth running.
The way in
Start with one track and one cohort
One role for one semester is the smallest thing worth running, and it is enough to see the evidence come back on your own rubric.