The engineering record
A resume is a claim. This is a record.
Every time a student runs code, fixes a failure, commits or asks the mentor a question inside Sudo Code, that becomes a measurable signal. Over three or four years those signals add up to a picture of how an engineer actually works — one nobody had to write by hand.
A transcript records what a student was examined on. A resume records what they say about themselves. Neither answers the question an employer is really asking: when this person hits a problem they have never seen, what do they do? The record answers that from four years of evidence.
The pipeline
From a terminal command to a verified record, in four steps.
- 1
The student works in Sudo Code
They open the lab, install what they need, write code, run it, read the failure, fix it, commit. Nothing about this step is extra. There is no form to fill in and no checklist to tick.
sudo code · vscodium
- 2
The IDE captures the signals
Terminal runs and their exit codes, file saves and churn, commits and their messages, mentor prompts and the code that followed them, and uninterrupted focus sessions. No keystrokes, no screen capture.
raw signals
- 3
The backend computes the metrics
Signals are batched and processed on a schedule — every hour — into the metrics below. A student's profile carries the timestamp of its last update, so nobody is reading a stale number.
every hour
- 4
The record and the level
The metrics roll into a composite ready-to-deploy index and a level of L1, L2 or L3. That, plus the underlying numbers and their history, is the record — visible to the student, their professors and their department.
rtd index · L1 / L2 / L3
What is measured
Twelve metrics, each traceable to a raw signal.
Nothing here is a survey answer or a self-assessment. Each number names the signal it was computed from, so a professor can always ask what a figure is made of and get an answer.
Error-to-success ratio
Successful runs per failing run. It rises as a student gets faster at turning a red terminal into a green one.
from: terminal exit codes
Mean time to resolve
How long a failing run stays failing before the student gets it passing. The clearest measure of real debugging skill.
from: time between failing and passing runs
Thrashing index
Repeated edit-run cycles on the same lines with no progress — the signature of guessing rather than diagnosing.
from: file churn against run outcomes
Deep-work momentum
Minutes of uninterrupted, active engineering per session. Distinguishes four hours of work from four hours with the IDE open.
from: focus sessions in the editor
Independent vs supervised ratio
How much of a student's output was produced alone versus during supervised lab time with help available.
from: session context and timing
AI-generated code share
The portion of committed code that came from a mentor exchange rather than being written by the student.
from: prompts paired with editor insertions
Prompt sophistication
How well a student frames a technical question — the error, the constraint, what was already tried — instead of asking for the answer.
from: semantic depth of mentor prompts
Refactoring index
How often a student returns to working code and improves it, rather than leaving the first version that passed.
from: edits to previously passing files
Commit semantic quality
Whether commit messages describe the change usefully and whether commits are scoped, not dumped at midnight.
from: git commit messages and diffs
Test-driven execution rate
How often tests are run alongside the program, and whether they are written before the implementation.
from: test runs in the terminal
Active engineering hours
Hours of genuine editing, running and debugging, counted from activity rather than from a clock.
from: editor and terminal activity
Ready-to-deploy index
The composite of everything above: one number for how close a student is to being useful on a real team on day one.
from: all of the metrics above
Levels
L1, L2, L3 — and the ready-to-deploy index.
The index is the composite of every metric on this page. The level is the band it falls into, and it is the shorthand a department head or a recruiter can act on without reading twelve numbers first.
L1
Foundations
Works in the environment without help. Runs, reads and fixes their own errors. Commits regularly. Debugging is still mostly trial and error, and the mentor carries a visible share of the load.
L2
Independent
Diagnoses failures instead of guessing at them: mean time to resolve is falling, thrashing is low, tests appear alongside the code. Deep-work sessions are real, and AI use has shifted from producing code to unblocking it.
L3
Deployable
Sustains long independent sessions on unfamiliar problems, refactors their own work, writes commit histories another engineer can read, and uses the mentor sparingly and precisely. This is the roster department heads hand to recruiters.
A level is not a grade and it is not permanent. It is recomputed as new work lands, so a student who starts pulling long independent sessions in their third year moves, and a student who stops working moves the other way. Both are supposed to happen.
For students
You own this, and it follows you.
The record is attached to you, not to a course or a semester. Every lab you run in Sudo Code, in any subject, across any year, lands in the same profile. By the time you are applying for jobs there is a multi-year history of how you work that you did not have to assemble, remember or exaggerate.
You can see everything that has been computed about you, at any time, in your own dashboard — the same numbers your professors see.
Five things worth knowing
- It is yours. The record follows the student, not the course — every lab, every semester, every year lands in the same profile.
- It accumulates. Three or four years of how you actually debug, build and ship is not something you can assemble the week before placements.
- It shows movement. A weak first year that becomes a strong third year is visible, and it is a better story than a number that was always flat.
- It is honest about AI. Using the mentor is not a penalty. How you use it, and whether you need it less over time, is what gets measured.
- You control sharing. Telemetry sharing and leaderboard visibility are toggles in your settings, not decisions made for you.
Sudo Code does not log keystrokes and does not capture your screen. Terminal output and mentor prompts are used to compute the metrics above — professors see those metrics and how they are trending, not a transcript of your session.
For recruiters
What a verified record shows that a resume cannot.
Every line on a resume is a claim made by the candidate. Every line in the record was computed from work the candidate did in an IDE, over years, without knowing which moment would matter.
On a resume
In the record
"Proficient in Python, Docker, REST APIs"
The share of active hours spent in each stack, the projects it was used on, and how failures in that stack were resolved.
"Strong problem solver"
Mean time to resolve a failing run, a thrashing index, and how both moved across four years.
"Familiar with AI tools"
AI-generated code share, prompt sophistication, and whether reliance decayed as the student progressed.
"Team project, final year"
The commit history, with message quality and the independent versus supervised split of the work.
CGPA
A ready-to-deploy index and a level computed from how the student engineers, not how they sit exams.
Institutions can hand recruiters a verified roster of students at L3 rather than a shortlist ordered by CGPA. The interview then starts from what the candidate has been observed doing, instead of from a claim that has to be tested from scratch.
Start the record with one cohort.
A pilot needs a department, a set of labs and the Sudo Code build. The first metrics appear within days of students starting work; the record is what four years of that becomes.