Choose evidence for your target role
You do not need a personal website with elaborate animation to show engineering ability. Start with a project that resembles the kind of problems you want to solve.
For frontend roles, accessibility, state handling and thoughtful empty or error states can be useful evidence. For backend roles, consider data modelling, validation, failure handling and tests. Pick a manageable scope that you can finish and explain.
Write the README for a stranger
GitHub supports repository READMEs and a profile README. Use them to give reviewers context before they inspect the code. The official documentation explains the mechanics; your job is to make the content useful.
- What problem does the project solve, and for whom?
- What works today, and what is deliberately out of scope?
- How can someone run it without private credentials?
- Which decisions or trade-offs are worth noticing?
- How are tests run, and what are the known limitations?
Show how you reason
A short decision note is often more revealing than a long stack list. Explain why you chose a data structure, how you handled a failure mode, or what you would change at a larger scale.
If you used a tutorial, library or AI assistance, distinguish that help from your contribution. Be ready to explain, test and maintain the result. Never imply that generated or copied work demonstrates understanding you do not yet have.
Make the project safe and reviewable
Remove secrets, personal data and anything owned by an employer. Check that example configuration uses harmless sample values. Do not publish proprietary code just to prove experience.
A live demo is helpful only when it works and does not create unsafe costs or collect unnecessary information. Include screenshots or a short walkthrough if hosting is not appropriate. Keep setup instructions accurate.
Curate rather than inflate
Feature a small selection of relevant projects and archive or clearly label experiments. Give each selected project a brief explanation of your role, especially if it was collaborative.
Private production experience is valid even when your public GitHub is quiet. Use a case study that describes the problem and decisions without revealing confidential material. A contribution graph is not a complete measure of engineering capability.
Your next steps
- Choose one role-relevant project.
- Write reproducible setup instructions.
- Add tests and a short trade-off explanation.
- Check for secrets and attribution.
References and further reading
Put your preferences into practice.
Create a developer profile with your skills, preferred work model and availability.
Join Fliqdev