Level, red flags and mapping yourself to the rubric

Two candidates tell the same story and receive different scores, correctly. The variable is level, and it runs through every lesson from here on.

Competencies tell you what is scored. This lesson covers the three things that decide how a story scores once it is in the rubric: the level it demonstrates, the red flags that can sink it regardless of level, and the gaps in your own material. It ends with a one-hour exercise that turns all three into your preparation plan.

The triad

Every level judgement in this course reduces to three questions:

They are independent. A story can be wide in scope and low in autonomy (you executed a big migration someone else designed). It can be narrow in scope and high in autonomy (you identified and fixed something nobody had noticed, alone). Interviewers read all three.

The same event at three levels

An invented example: a service is timing out under load twice a week.

Mid. "I picked up the ticket for the timeouts. I reproduced it with a load test, found the connection pool was sized at 10 against 40 concurrent workers, raised it to 60, and added an alert on pool saturation. The pages stopped."

Scope: one service. Autonomy: given the ticket, chose the fix. Influence: none. Clean, competent, mid.

Senior. "The timeouts were a ticket, but the third time it happened I stopped fixing and asked why we kept discovering pool exhaustion in production. Nobody owned pool sizing — every service had copied the same default from a template written in 2022. I fixed ours, then wrote a short doc showing the sizing calculation and got it into the service template. Four teams picked it up over the next quarter."

Scope: several services. Autonomy: reframed the problem. Influence: four teams.

Staff. "We had eleven pool-exhaustion incidents in six months across seven services. I treated the class, not the instances: the shared HTTP client library had no way to express concurrency limits, so every team invented one. I proposed adding bounded concurrency to the library, wrote the written proposal, ran the review with the three loudest sceptics first, and had the platform team own it. Two quarters later that incident class was gone from the register."

Scope: an org-wide library. Autonomy: chose the problem class. Influence: platform team took ownership, sceptics converted.

Reading your own stories against the triad

Take any story and score it honestly:

If your best three stories all land in the mid column, you have found the real work: not better wording, but different stories. That may mean going back through your last two years for the moments where you chose the problem — they exist more often than people think, and they are usually the ones you did not consider "projects".

Red flags that end loops

Level decides how high a good story scores. Red flags are different: they can sink a loop on their own. Most rejections are the absence of good evidence. A smaller number are the presence of a specific negative, and those are close to unrecoverable in the same loop.

The five that end loops

1. Blaming others. The single most common one. It rarely sounds like blame from the inside — it sounds like accurate description.

"The project failed because product kept changing requirements and we never got the headcount we were promised."

That may be entirely true. The interviewer writes: no ownership of a failure; external attribution. The repair is not to lie about the causes. It is to spend most of the answer on what you controlled: "Requirements changed four times, which I could not control. What I could control was that I didn't force a scope conversation until week nine. If I ran it again I'd have put a written scope agreement in place in week two."

2. No ownership of failure. Asked for a mistake, the candidate produces a mistake that was not theirs, or a "mistake" that is a virtue in disguise. The failure question covers the selection problem in full.

3. "We" with no "I". Forty minutes of collaborative narration and no locatable contribution. The interviewer cannot score a team. The lesson "I" versus "we" is the fix.

4. Cannot name a weakness. "I'm too much of a perfectionist" is read as either a lack of self-awareness or an unwillingness to be honest with an interviewer. Both are disqualifying for senior roles, where the job includes being wrong in public.

5. Disrespect toward past colleagues. Naming someone as incompetent, mocking a former manager, or describing a previous employer as full of bad engineers. The interviewer's inference is not about your old colleagues.

The pattern behind all five

Every one of them says the same thing to a rubric: this person's account of events is shaped to protect them. Interviewers are not looking for humility as a personality trait. They are checking whether your description of reality survives contact with your own interests, because that is the property that makes someone useful in an incident review.

The near-miss versions

These are subtler and appear in write-ups constantly:

Mapping yourself to the rubric

Now apply all of this to yourself. This is a one-hour exercise that produces the gap list your preparation is built around. Do it before writing any stories.

Step 1 — Dump the raw material

List every project, incident, migration, launch, and difficult conversation from the last three years. One line each. Aim for twenty; do not filter for quality.

Sources that surface forgotten material: performance review self-assessments, old sprint boards, incident write-ups, your pull request history, and the Slack channel from any launch.

Step 2 — Score yourself per competency

Build this grid. Score each competency 0–3 on evidence you actually have:

Scoring guide: 3 — a story with real stakes, my decision, and a measured outcome. 2 — a real story, but thin on one of scope, autonomy, or outcome. 1 — something happened but it will not survive follow-ups. 0 — nothing.

Step 3 — Act on the zeros and ones

This is the point of the exercise. The grid above says: the candidate has a delivery and problem-solving story bank and no trust, customer, or strategic material.

Three responses, in order of preference:

Look again. Most zeros are recall failures, not experience gaps. "I have never had a conflict" almost always means "I have not thought of the code review argument in March as conflict". The story-building lessons for Earning Trust and Customer Focus both exist because these two zeros are so often false.

Reframe adjacent material. A platform engineer with no customer story has internal developers as customers (Building the story, including when you have no users). A senior engineer with no strategic story may have a technical direction they set for two teams.

Go and get one. If your loop is more than a month out, this is real. Volunteer for the mentoring, run the postmortem, take the conversation you have been avoiding. Six weeks produces a usable story.