I'm Enes Şahin. Here I collect the decisions I made while building my own portfolio (this site) and choosing which of the real projects I've worked on to include. I'm a final year software engineering student, I develop the backend of an e-commerce business, and at an agency I worked on a trilingual corporate website with more than 200 pages. I explain what I paid attention to when turning this experience into a portfolio.
Which projects should go in
Someone on the hiring side usually spends a few minutes on your portfolio. That's why my portfolio doesn't show everything I've built, just a few projects that say the most:
- A project with a real client or real users. As much as code quality, the impression that "this person solved a real problem" matters. My list includes an e-commerce platform and a school website; neither is a school assignment, both are real work.
- A project with an architectural decision. If I can answer a question like "why did you choose this database?" or "why did you set up this authentication method?", the project goes in. If I can't, meaning I just followed a random tutorial, the project does nothing but crowd the CV.
- A finished project. Nothing leaves a worse impression than a half-finished demo link that doesn't work. If a project isn't running live, I prefer to show it with screenshots and an architecture description; I don't put up a "see it live" link that doesn't work.
What I pay attention to with client projects
If you want to show work you did for a client, a few rules apply even without a non-disclosure agreement:
- I write the organization's name only with permission. Without permission I use a general description like "for an education institution with several branches". Showing a screenshot (logo included) is usually fine, but I don't name them in the text.
- I never show real data. When taking screenshots I work with a test account and sample data; real customer information or order data never appears on screen.
- I describe the architecture, not the whole code. A summary like "Next.js frontend, Express/Prisma/PostgreSQL backend, JWT authentication" is more valuable than a line-by-line copy of the code. The person hiring can look at your GitHub anyway.
The GitHub profile
After the portfolio link, GitHub is usually the next place people look. Things to watch:
- The README should say what the project does in its first sentence. A repo without a "This project does X" sentence forces people to read the code to understand what it is; someone on the hiring side won't do that.
- The commit history should show a real development process. A history where features were added one by one looks more credible than a single 3000-line "initial commit".
- Pinned repos should be chosen, not random. The repos shown at the top of a GitHub profile should be the ones that say the most, not the ones with the most stars.
How much technical detail
For each project I give three levels of information: a one-sentence summary (what it does), the technologies used (a short list), and any architectural decisions (why it's built that way). I don't include code snippets; a portfolio isn't a code review tool but a showcase that sparks interest and sends people to GitHub or the live site. Anyone who wants detail clicks the link and reads the code.
Splitting the work between CV and portfolio
It makes sense to give each project a single line on the CV and leave the detail to the portfolio. The CV's job is to get you invited to an interview; the portfolio's job is to give you something concrete to talk about in that interview. Writing the same amount of text for both makes both of them boring.
Conclusion
Every project in my portfolio answers at least one of these questions: did I solve a real problem, can I defend an architectural decision, am I showing something finished and working? A project that answers "no" to all three doesn't go into the portfolio, no matter how well it's coded.
Frequently asked questions
Which projects should a junior developer portfolio include?
What each project shows matters more than the number: finished, working projects that solve a real problem and involve an architectural decision you can defend. A few strong projects leave a better impression than many weak ones.
What should you watch when showing client projects in a portfolio?
Name the organization only with permission; otherwise use a general description. Screenshots should contain no real customer data; use a test account and sample data.
What should you pay attention to on a GitHub profile?
The first sentence of the README should say what the project does, the commit history should show a real development process, and pinned repos should be chosen from the ones that say the most, not at random.
Should I put a project that doesn't work in my portfolio?
Instead of a demo link that doesn't work, it's better to show it with screenshots and an architecture description. A broken link leaves a half-finished impression.