When you apply for your first developer job, your résumé says you can build things. Your portfolio and GitHub show it. A reviewer is unlikely to read every line of code. They will skim a few repositories, try a link and decide in about a minute whether you are worth a call. Your job is to make that minute count.
Pick fewer, better projects
Three solid projects beat fifteen half-finished ones. A solid project is one that:
- Solves a real problem, even a small one: tracking expenses for your hostel, a timetable tool for your department, a scraper for local job listings
- Works when someone opens it. A live link that loads and does what it says
- Shows range: one project with a backend and database, one focused on the user interface, perhaps one that uses an API or some data
- Is finished enough to demonstrate, with the rough edges listed honestly
Avoid piling up tutorial clones. A to-do list and a weather app built by following a video show you can follow instructions. Take that idea and add something of your own: your own data, a feature that was not in the tutorial, or a real user.
The README is your sales page
Many recruiters never open the code. They read the README. Give each main project a README with these parts:
- What it is: one or two sentences in plain language
- A screenshot or short GIF at the top
- Live demo link and how to run it locally, in a few steps that really work
- Tech used: languages, frameworks, database, hosting
- What you built and decided: two or three bullets on interesting choices, such as why you picked a database or how you handled a tricky bug
- What is next: things you would improve, which signals self-awareness
If a stranger cannot get your project running by following the README, fix the README.
Make the repository tidy
- Meaningful commit messages. "Add login validation" says more than "update" or "fix".
- No secrets. Never commit API keys, passwords or environment files. If you did by mistake, rotate the keys, because history keeps them.
- A sensible folder structure and a short note on how it is organised
- A licence if you want others to reuse it
- Pin your best six repositories on your GitHub profile
Contributions in the green squares do not matter as much as people think. A streak of empty daily commits is noticed and not respected. A handful of real projects with thoughtful history is better.
The portfolio site
A portfolio site is optional, but handy. Keep it fast and simple:
- Your name, what you do and what role you want, above the fold
- Three project cards with a screenshot, one line of description and two links: demo and code
- A short About section with the story of how you got into building
- A visible way to contact you, and a link to your résumé as a PDF
It should work on a phone, since many recruiters check links there. Do not hide your best work behind animations that take ten seconds to load. A plain, clear page beats a flashy one every time.
Write about what you build
A short write-up on a project, a bug that took you a day or a lesson you learned shows how you think, which code alone does not. Two or three posts on a personal blog or a developer community are enough. Explain the problem, what you tried, what failed and what worked.
Show you work with others
Teams matter. If you have contributed to open source, even fixing a typo in documentation or a small bug, link to the pull request. If you worked in a group project, say what part you built and how you collaborated using branches and reviews.
Habits that quietly hurt
- Broken links. Click everything before you apply.
- Too many languages and tools listed with nothing built using them
- Copied code with your name on it. If you used a tutorial, say so and say what you added.
- Unfinished repositories with no README, left public at the top of your profile
- Placeholder text, such as "Lorem ipsum" or "Your name here", on your live site
- Huge files and committed build folders
Before you send it
- Open your portfolio and each demo on your phone.
- Ask a friend who does not code to explain what each project does after reading the README. If they cannot, simplify it.
- Check that your résumé links to the exact repositories you want seen.
- Search your own name and see what shows up.
Keep it alive
Treat your portfolio as a living thing. When you learn something new, add a small project or improve an old one. In an interview, being able to say "I rebuilt this last month after learning X" shows exactly the kind of growth employers hire for.
