Choose a problem small enough to finish
A reservation service, an accessible form or a data-cleaning pipeline can expose meaningful engineering decisions without requiring a large product. Define the user, the essential behavior and what is out of scope.
The GitHub README guidance explains the role of repository documentation. Use the README to orient a reviewer, then link to deeper design and test notes only where needed.
Make the evidence inspectable
| Artifact | Question it answers |
|---|---|
| Requirements note | What behavior did you intend? |
| Run instructions | Can someone reproduce the result? |
| Tests | Which important failures have been checked? |
| Decision note | Why did you choose this approach? |
| Limitations | What should the reviewer not infer? |
This is our editorial review framework, not a hiring guarantee. A project does not become production experience because it has a polished screenshot.
Use synthetic data unless you have a legitimate reason and permission to use real records. Keep credentials out of the repository. If an external service is needed, document a local substitute or a safe setup path so the reviewer does not need your account.
Show one meaningful tradeoff
Explain a decision such as a simple database schema, a synchronous operation or a deliberately limited feature set. State what the choice makes easier and what it cannot support. This shows judgment more clearly than a diagram containing many technologies without a reason for each.
For web interfaces, the MDN curriculum provides a foundation that includes more than appearance. Test keyboard use, error messages and small screens in addition to the happy path.
Invite a reproducibility review
Ask someone unfamiliar with the project to follow the setup instructions. Record where they became stuck and improve the documentation or code. Do not claim “user-tested” from an imagined scenario; describe the actual review and its limits if you publish it.
Link the project from a relevant resume entry. Be ready to explain what you wrote, what came from dependencies and what assistance you used. The software engineering overview ties these artifacts to the broader work of building and maintaining software.