Portfolio, Projects & GitHub Guide

By Pranoy Tez · Sr. Software Engineer at Microsoft (9+ years) | Top 0.1% Topmate Mentor (500+ sessions)

Your portfolio is the difference between "I know React" and "I built and deployed a production app that handles 500 users." Interviewers at every level look for evidence that you can ship — not just write code, but take something from idea to working product.

This guide covers what to build, how to present it, how to clean up your GitHub, and how to talk about your projects in interviews.

1. Why projects matter more than tutorials

Tutorials teach you syntax. Projects teach you problem-solving. Here is what interviewers actually evaluate:

| Tutorial completion | Project building | |-------------------|--------------------| | Followed someone else's instructions | Made your own decisions | | Used pre-built examples | Handled real edge cases | | Never deployed | Deployed and running | | No users | Potentially has real users | | Shows you can follow | Shows you can lead |

The bar is not perfection. A deployed, working project with clean code and a good README beats a half-finished "perfect architecture" every time.

2. Three project types that impress

Type 1: Full-stack application

A complete app with frontend, backend, database, and authentication. This is the strongest signal for mid-level and senior roles.

What interviewers look for:

Can you build a complete system, not just one layer?
Do you understand data modeling, API design, and state management?
Is it deployed and working?

Examples:

Task management app with real-time updates
E-commerce store with payment integration
AI-powered tool (chatbot, content generator, search engine)

Tech stack suggestion: Next.js + TypeScript + PostgreSQL + Prisma + Vercel. This stack is modern, in demand, and shows you understand the full picture.

Type 2: Open source contribution

Contributing to an established open source project shows collaboration, code review awareness, and communication skills.

What interviewers look for:

Can you read and understand someone else's codebase?
Can you follow contribution guidelines and communicate in pull requests?
Did you solve a real issue, not just fix a typo?

How to start:

Look for "good first issue" labels on GitHub projects you use
Fix a real bug or add a small feature — not documentation-only changes
Write a clear PR description explaining what you changed and why

Where to find beginner-friendly issues:

goodfirstissue.dev — Curated list across popular projects
up-for-grabs.net — Projects with tagged beginner issues
GitHub Explore — Browse trending repos in your language
Your own dependencies — Check issue trackers of libraries you use daily

PR etiquette:

Reference the issue in your PR description
Explain what you changed and why — don't make reviewers guess
Keep PRs small — one change per PR
Respond to feedback promptly — maintainers appreciate fast iterations

Type 3: Side project with real users

Nothing impresses more than a project that actual people use. Even 10 users is meaningful.

What interviewers look for:

You solved a real problem, not a hypothetical one
You handled feedback, bugs, and iteration
You understand the full product lifecycle

How to get users:

Build something you personally need
Share it on Reddit, Hacker News, or relevant communities
Ask friends or colleagues to try it and give feedback

3. GitHub profile setup

Hiring managers and recruiters check your GitHub. A clean, well-organized profile signals professionalism.

Profile README (your GitHub landing page)

Create a repository with your GitHub username (e.g., github.com/yourname/yourname) and add a README.md. This appears at the top of your profile page.

What to include:

# Hi, I'm [Your Name]

**Software Engineer** | [Your Specialty] | [Location or Remote]

- Currently working on [what you're building or learning]
- [X] years of experience in [key technologies]
- Exploring [what you're learning next]
- Reach me at [email] or [LinkedIn URL]

## Tech Stack

**Languages:** Python, TypeScript, Go
**Backend:** Node.js, Django, FastAPI
**Cloud:** AWS (EC2, Lambda, S3, DynamoDB), Docker, Kubernetes
**Databases:** PostgreSQL, MongoDB, Redis

## Featured Projects

| Project | Description | Tech |
|---------|------------|------|
| [Project 1](link) | One-line description | React, Node.js |
| [Project 2](link) | One-line description | Python, AWS |
| [Project 3](link) | One-line description | Go, PostgreSQL |

What NOT to include:

Animated GIFs or flashy badges that distract from content
GitHub stats widgets (views, stars) — they look vanity-driven
Overly long bios — keep it scannable in 10 seconds
"I'm a passionate developer who loves..." — show, don't tell

Profile settings (5-minute wins)

[ ] Profile photo — Professional headshot (same as LinkedIn)
[ ] Bio — "Software Engineer | [Specialty] | [Location]"
[ ] Location — City, State or "Remote"
[ ] Website — Link to portfolio or LinkedIn
[ ] Company — Current employer (or "Open to opportunities")
[ ] Social links — LinkedIn, Twitter/X if active

4. Pinned repositories: your top 6

GitHub lets you pin up to 6 repositories. These are the first things people see. Choose strategically.

| Slot | What to Pin | Why | |------|-----------|-----| | 1-2 | Your best portfolio projects | Shows you can ship end-to-end | | 3 | A project using your target company's stack | Signals relevance | | 4 | An open source contribution (your fork with meaningful changes) | Shows collaboration | | 5 | A data structures/algorithms repo (only if well-organized) | Shows interview prep discipline | | 6 | Something unique — a tool, CLI, library, or creative project | Shows initiative |

Pinned repo checklist:

[ ] Clear, descriptive name — ecommerce-api not project-1
[ ] One-line description filled in (the text below the repo name)
[ ] Topics/tags added (e.g., react, typescript, rest-api)
[ ] Language indicator is correct (GitHub auto-detects)
[ ] Not a fork (unless it's a meaningful open source contribution)

5. Repository quality standards

Every pinned or public repo should meet this bar.

README standards

A good project README answers these questions in order:

What is this? — One paragraph explaining the project
Demo — Screenshot, GIF, or live link (deploy on Vercel, Railway, or Render)
Tech stack — List of technologies used
How to run it — Clone, install, run commands (copy-paste ready)
Key features — 3-5 bullet points of what it does
Architecture (optional for complex projects) — How it is structured

Code quality signals

Interviewers will glance at 2-3 files. Make sure:

[ ] No secrets or API keys in the code (use .env files, add .env to .gitignore)
[ ] Consistent code style — Use Prettier/ESLint or equivalent
[ ] Meaningful commit messages — Not "fix", "update", "asdf". Use conventional commits.
[ ] No commented-out code — Delete it. Git has history for a reason.
[ ] Some tests exist — Even a few tests show you care about quality
[ ] Clean folder structure — Standard conventions for your framework
[ ] Type safety — If using TypeScript, actually use types (no any everywhere)

Deployment (instant pass/fail)

If your project is deployed and running, you are ahead of 80% of candidates. If the demo link is broken, you are behind.

Use Vercel, Netlify, or Railway for free deployment
Make sure it loads in under 3 seconds
Test it on mobile

Git history (bonus points)

Clean, descriptive commit messages show professionalism:

Good: feat: add user authentication with Clerk
Bad: update stuff or fix or asdf

Use conventional commits: feat:, fix:, docs:, refactor:

6. Contribution graph strategy

The green squares on your profile show activity over the past year. A consistent graph signals active engineering work.

What counts as a contribution:

Commits to default branch (main/master)
Opening pull requests
Opening issues
Reviewing pull requests (on repos you don't own)
Creating repositories

Do:

Work on side projects regularly — even 30 minutes of coding 3-4 days a week creates a solid graph
Contribute to open source — find issues labeled good first issue
Keep a learning repo — log your daily practice (LeetCode solutions, notes, experiments)
Commit to default branch — contributions only show if committed to the default branch or merged via PR

Don't: Make empty commits or "contribution padding" repos. Experienced engineers can spot this instantly.

What interviewers actually look at:

Consistency > intensity — Regular activity beats sporadic bursts
Recent activity — The last 3-6 months matter most
Quality of repos — A few well-maintained repos beat 50 empty ones

7. Cleanup checklist

Go through all your public repositories and clean up.

Archive these (make private or archive)

[ ] Tutorial follow-along repos (todo-app-tutorial, react-course-project)
[ ] Incomplete projects with no README and no recent commits
[ ] Forked repos you never modified
[ ] Class assignments (unless exceptional quality)
[ ] Repos with names like test, experiment, temp, project1

Keep public (if they meet quality bar)

[ ] Portfolio projects with READMEs and deployed demos
[ ] Open source contributions (your forks with meaningful changes)
[ ] Well-organized learning repos (e.g., leetcode-solutions with clean structure)
[ ] Tools or libraries others might use

The 10-repo rule: Aim for 10 or fewer public repos. Better to have 6-8 excellent repos than 40 mediocre ones. Archive everything else.

8. From idea to shipped project

Use this framework to go from "I should build something" to "here is the live link."

Week 1: Choose and scope

Pick a problem you personally care about
Write down 3-5 core features for v1
Cross out the two least important ones — ship with 2-3 features maximum
Choose your tech stack (stick with what you know for speed, or what you want to learn)

Week 2: Build the core

Set up the project (repo, CI, deployment pipeline)
Build the main feature first — the thing that makes this project worth existing
Deploy early — even if it is ugly. A live URL motivates you to keep going.
Do not add auth, payments, or analytics yet

Week 3: Polish and deploy

Add authentication if your project needs it
Write the README
Fix the mobile layout
Add error handling for the common paths
Make sure the deployment works reliably

Week 4: Share and iterate

Post your project on relevant communities
Ask 3-5 people to try it and give honest feedback
Fix the top 2-3 issues they raise
Write a short blog post about what you built and why (great LinkedIn content)

9. How to talk about your projects in interviews

Interviewers will ask "tell me about a project you have built." Here is the structure:

The 60-second pitch

What it is (1 sentence) — "I built a real-time task management app for small teams."
Why you built it (1 sentence) — "My team at work used Notion but it was too heavy for our daily standups."
What you used (1 sentence) — "Next.js, PostgreSQL, WebSockets for real-time sync, deployed on Vercel."
What makes it interesting (1-2 sentences) — "The real-time sync was the hardest part — I implemented optimistic updates with conflict resolution using CRDTs."
Impact or outcome (1 sentence) — "My team of 8 used it for 3 months before we switched to Linear."

Follow-up questions to prepare for

"What was the hardest technical challenge?" — Pick one specific problem. Explain the problem, what you tried, what worked, and what you learned.
"What would you do differently?" — Show self-awareness. Maybe you would use a different database, or start with better error handling, or write tests earlier.
"How did you decide on the tech stack?" — Show you evaluated options. "I chose PostgreSQL over MongoDB because my data was relational and I needed strong consistency for the real-time features."
"How does the system scale?" — Even if your project has 5 users, show you thought about what would break at 5,000 users.

10. Portfolio site vs GitHub profile

You do not need both, but here is when each makes sense:

GitHub profile is enough when:

You are applying for backend or full-stack roles
Your READMEs are strong
Your pinned repos show your best work

A portfolio site helps when:

You are applying for frontend roles (the site IS the portfolio)
You want to show projects that are not code-only (design, writing, consulting)
You want more control over the narrative

If you build a portfolio site:

Keep it simple — your work should be the focus, not animations
Include 3-5 projects maximum — quality over quantity
Link to live demos and source code
Include a brief "about me" with what you are looking for

11. Common mistakes

Too many half-finished projects — Better to have 2 complete projects than 10 abandoned repos
Tutorial projects presented as original work — "Todo app" and "weather app" from tutorials do not count
No deployment — If I cannot click a link and see it working, it barely counts
Ignoring the README — Your README is your project's resume. Treat it accordingly
Over-engineering — A simple, working app is better than a complex, broken one
Not removing sensitive data — Check for API keys, passwords, or personal data in your repo

DSA Problem TrackerTry free

Track your LeetCode progress across 16 patterns while building your learning repo.

The complete cleanup workflow

Do this in one focused session:

Update profile settings (photo, bio, links) — 5 min
Create or update profile README — 15 min
Audit all public repos — Archive/private anything below quality bar — 15 min
Pick 6 repos to pin — Verify each has a solid README — 10 min
Add missing READMEs to pinned repos — 30-60 min
Add topics/tags to all public repos — 5 min
Deploy any undeployed projects (Vercel/Railway) — 30 min per project
Review your contribution graph — Start a plan for consistent activity

Total: 2-3 hours for a profile that works for you in every job application.

Want a professional review of your GitHub profile and portfolio? Book a 1:1 session — I will audit your repos, help you choose what to pin, and create an action plan for a profile that gets noticed. Or check our prep packages.