Engineer Readiness Rubric

Use this rubric to evaluate evidence, not confidence.

Can repeat terms but cannot use them.

Signals:

• Reads docs but produces no artifacts.
• Cannot start an unfamiliar project.
• Cannot explain where code runs.
• Does not know where data lives.
• Accepts agent answers without checking.

Not ready for engineering work.

Can follow instructions in a known setup.

Signals:

• Can use terminal basics.
• Can run a provided command.
• Can make simple changes in obvious files.
• Can commit code with guidance.
• Can call an API if given the exact command.

Ready for tightly guided tasks.

Can complete small scoped changes with review.

Signals:

• Maps basic repo structure.
• Finds entry points.
• Explains frontend, backend, database, and API roles.
• Adds validation.
• Writes simple tests.
• Uses logs to inspect failures.
• Can ask an agent a bounded task.

Ready for small product work with senior review.

Can own a feature slice.

Signals:

• Converts requirements into acceptance criteria.
• Designs data and API changes.
• Implements UI-to-database behavior.
• Handles common failure states.
• Writes tests that catch real behavior.
• Debugs by reproduction and evidence.
• Updates docs and runbooks.
• Uses agents for acceleration and verifies output.

Ready to own scoped features.

Can ship and operate safely.

Signals:

• Thinks about deployment before merging.
• Handles config, secrets, health checks, logs, and rollback.
• Identifies migration risks.
• Designs for auth, authorization, audit, and privacy.
• Reads CI/CD failures.
• Writes incident notes and postmortems.
• Communicates risk clearly.

Ready for production systems with normal team process.

Can turn messy user problems into working systems.

Signals:

• Interviews users and maps workflows.
• Finds the real constraint behind vague requests.
• Designs a pragmatic first version.
• Builds, tests, deploys, observes, and iterates.
• Uses agents across SDLC and ADLC without losing control.
• Coordinates technical and non-technical stakeholders.
• Leaves behind systems, docs, tests, and context that make future work easier.

Ready for field-facing ownership.

The learner should have proof for each:

• Repo map.
• System diagram.
• Data model.
• API contract.
• Working feature.
• Test results.
• Debugging log.
• Deployment/runbook.
• Rollback proof.
• Agentic log.
• Capstone demo.
• Retrospective.

• Talks only in buzzwords.
• Cannot explain their own code.
• Cannot reproduce a bug.
• Cannot run tests.
• Cannot identify trusted versus untrusted code.
• Cannot explain where data is stored.
• Says “the agent did it” as proof.
• Claims production readiness without deployment evidence.

Ask the learner to walk through one feature:

user action -> frontend -> API -> business rule -> database -> response -> logs

Then ask:

• What can fail?
• What test proves it?
• What log proves it?
• What would you roll back?
• What did an agent help with?
• What did you verify yourself?