Task level guide

Task level guide

Classify a completed task, then show the same task done at each level. The point is not to award a badge. It is to make the gap visible, because a person cannot practise a level they cannot see.

The two axes

From Honeycomb's engineering ladder and the PSHE framework it borrows from. Honeycomb's own conclusion matters here: scope is the enemy. A ladder that rewards bigger projects rewards the wrong thing. They prefer engineers who shrink scope by decomposing a problem.

So classify on both axes, and treat ownership as the one that matters more.

Scope — how much surface the work touches.

task  ->  feature  ->  project  ->  product  ->  company

Ownership — which question you owned.

Ownership	The question you owned	Also called
Execution	"Build this thing."	Implementer
Process	"Make delivering this repeatable."	Implementer
Solution discovery	"What should we build to fix this?"	Solver
Problem discovery	"What is actually wrong here?"	Finder

Problem discovery is the skill of being dropped into an unknown system and finding what is broken. It sits at the top of the ownership axis. It is not the same as working on something big.

A person can operate at high ownership inside a tiny scope. That is often the most valuable engineer in the room, and a scope-only ladder makes them invisible.

How to classify

After the task, answer four questions. Be strict.

1. Who decided the problem was worth solving? If someone handed it to you, ownership is at most solution discovery.
2. Who decided the approach? If the approach was given, ownership is execution.
3. What is the smallest thing that would have worked? If you did more than that, note it. Decomposition is a skill, not a shortcut.
4. What would break if you were wrong, and how would anyone find out? No answer means the work is unverified regardless of level.

Then write the level as a pair, not a title:

LEVEL   scope: feature   ownership: problem discovery
WHY     nobody asked for this; the bug was found by measuring, not by a ticket

The per-level blocks

For every completed task, write four short blocks. Each one describes how an engineer at that level would have approached this same task, and what they would have missed.

Keep each to three or four lines. This is a teaching artifact, not a performance review.

JUNIOR would have
  <the direct approach, and the thing it misses>

MID would have
  <adds repeatability, tests, or a second case>

SENIOR would have
  <questions the approach; finds the simplest version; verifies it>

STAFF would have
  <questions whether this is the right problem; checks the measurement itself>

The gap between the SENIOR and STAFF block is usually the same shape: senior solves the stated problem well, staff asks whether the stated problem is the real one, and whether the instrument that reported it can be trusted.

The two failure modes to name explicitly

Say these plainly when they apply, because they are the most common ways good work gets mis-levelled.

Big scope, low ownership. A large migration where every decision came from someone else is execution work at project scope. It looks senior on a resume. It is not.

Small scope, high ownership. A one-line fix found by noticing a number was impossible is problem discovery at task scope. It looks trivial on a resume. It is the harder skill.

For practice problems

LeetCode, HackerRank, a take-home, or a mock interview. The same four blocks apply, and the ownership axis is what interviewers actually score.

Level	What it looks like in a practice problem
Junior	Reaches a correct solution.
Mid	Reaches it, states the complexity, handles edge cases.
Senior	Clarifies the problem before coding. Names the constraint that decides the approach. Tests the failure case.
Staff	Asks what happens at real scale, what the input actually looks like, and whether the stated problem is the one worth solving.

Most candidates fail by solving before clarifying. That is the whole gap between mid and senior in an interview, and it is drillable.

The drill for problem discovery

This is the skill that is hardest to practise alone: dropped into an unknown codebase, find the problem, with AI assistance.

Run it like this:

1. Pick a repository you have never read. An open-source one with issues is fine.
2. Do not read the issue list yet.
3. Give yourself 30 minutes to answer: what does this system claim to do, and where is the weakest claim?
4. Now read the issues. Compare against what you found.
5. Score yourself on one thing only: did you find something nobody had filed?

Score 1 is problem discovery. Score 0 means you did solution discovery on someone else's problem.

With AI assistance the drill does not get easier, it gets faster. The agent reads more code than you can. It cannot tell you which claim matters, and that judgement is the level.

Where the evidence comes from

This skill reads what already exists. It does not ask the user to write a report.

• before-after-proof evidence shows whether the work was verified.
• easier-to-read-submissions changelog entries show what surfaces were touched.
• The git diff shows the scope.
• The conversation shows who decided the problem and the approach.

If a task has no evidence of verification, say so in the classification. Unverified work has no level.

Reference

• references/LEVELS.md — the full ladder, worked examples, and the honest mapping to job titles