The README, and the review you run yourself

The README

Most student READMEs are installation instructions. Installation instructions are the least interesting thing about your project to someone deciding whether to interview you.

Structure it in this order — reviewers read the first screen and scroll only if it earns it.

One sentence: what this is and for whom.

A lost-and-found board for our campus, so found items stop living in six WhatsApp groups.

A screenshot or a short clip. One image, near the top. This is often the only visual a reviewer who did not open the live link will see.

The live link. Above everything technical.

Built with. A short list, no version numbers, no badges. Badges impress nobody and push the content down.

How it works. Three to six sentences on the actual mechanism — where data lives, what happens when a user does the main thing. This is where a reviewer decides whether you understand your own system.

What I would do next. Two or three specific items, one of which is an honest limitation.

Search is a substring match, so a misspelt item is not found; the next step is fuzzy matching. There is no moderation — anyone can delete any post, which I would fix before real use.

That section is the most valuable paragraph in the document. It shows you evaluated your own work, and it steers the interview onto ground you have already thought about.

Running it locally. Last. Genuinely last.

The self-review

Run all fifteen before you send a link anywhere. Most students fail three or four, and every one of them is visible to a reviewer.

Works at all

1. The live link loads with no console errors.
2. It works logged out, or has a visible demo account.
3. It has data in it already — no empty first screen.
4. The main action works end to end on the deployed version, not just locally.

Works everywhere 5. No sideways scrolling at 375px wide. 6. Every tap target is reachable and large enough on a phone. 7. It loads on mobile data without a multi-second blank screen. 8. Text is legible — no grey-on-grey, no 11px body copy.

Handles reality 9. A loading state exists for anything that fetches. 10. An empty state says something useful, not "undefined". 11. A network failure shows an error rather than hanging or silently doing nothing. 12. A form tells you what is wrong, next to the field that is wrong.

Reads well 13. The README's first screen answers what, why and how. 14. No placeholder text or lorem ipsum anywhere in the UI. 15. The repository has no committed secrets — check .env, config files and the commit history.

Point 15 is not cosmetic: a committed API key is a security failure, and a reviewer who spots one has learned something about how you would handle production access.

What to do with a weak project

If a project fails a lot of these, fixing it is almost always a better use of a week than starting something new. A polished small project outperforms an ambitious broken one, and the fixes above are hours of work rather than weeks.

Next: the free practice set — eight questions on the JavaScript fundamentals from lesson 2, marked instantly, no account needed.