Demonstrate the work
Use the capstone brief and the artifacts from earlier labs. This review checks what you can build, diagnose, and explain. Reading completion alone does not establish readiness, and the rubric is a self-assessment rather than a hiring guarantee.
Review session
- Give a five-minute explanation of the user problem, baseline, and chosen architecture.
- Run a successful case from a clean setup using the documented instructions.
- Demonstrate one failure without editing the result after the fact. Trace its cause and recover safely.
- Defend one tradeoff using your recorded evaluation or pilot evidence.
- Ask the reviewer to change a constraint and explain what you would reconsider.
Evidence rubric
| Dimension | Evidence to inspect |
|---|---|
| Discovery and scope | Observed workflow, baseline, assumptions, and acceptance criteria |
| Technical delivery | Data provenance, reliable integrations, and identity boundaries |
| Customer operations | UAT, rollout, recovery, training, and ownership |
| Communication and judgment | Tradeoffs, scope decisions, evidence, and transparent outcomes |
Score each dimension from 0 to 3: 0 means no artifact; 1 means you can follow a guided happy path; 2 means you can reproduce, test, and explain the work independently; 3 means you can adapt it to a changed constraint and diagnose a new failure. Aim for at least 2 in every dimension. Any unauthorized action, data leak, or irreproducible core workflow is a blocker to resolve before calling the project ready.
Have a peer review the evidence if possible. If you work alone, record the demo and return later with an unfamiliar test case. Keep the reviewer’s questions and unresolved gaps. Do not replace evidence with a polished slide deck.
Questions to answer without a script
- You can discover a workflow, identify its actual bottleneck, and challenge an unnecessary AI requirement.
- Your integration handles denied access, duplicated events, stale data, and uncertain writes.
- Another person can run acceptance tests, diagnose a failure, and execute your rollback instructions.
- Your case study distinguishes assumptions, simulated business impact, and measured results.
Finish with a development plan
List the weakest dimension, the next experiment or implementation change, and the evidence that would show improvement. Add the repository, architecture record, evaluation results, and recovery instructions to your portfolio. Describe synthetic engagements and simulated outcomes explicitly. A credible portfolio explains limitations as well as successful results.