Projects and Portfolio
Before you start
You need: to be past month three of your route, with something running.
Time: about 40 minutes to read. The work itself runs alongside your whole programme.
Learning objective
Build one project that proves you can do the job, and present it so a hiring manager can see that in two minutes.
Topics
- One deep project beats five shallow ones
- What to build, month by month
- What makes a project credible
- The README that decides whether anyone looks further
- Your GitHub as evidence
- Deploying it, and why it matters
- What not to put in a portfolio
One deep project beats five shallow ones
The instinct is to build many things. Resist it.
| Five tutorial projects | One project you own |
|---|---|
| Each stops where the tutorial stopped | Hits the problems tutorials skip |
| No edge cases, no auth, no deployment | Absent students, duplicate roll numbers, tokens |
| "I followed a course" | "I built this and here is a decision I made" |
| Interview lasts one question | Interview lasts twenty minutes |
A reviewer looks at one project. They will not open five. So the question is not how many you have — it is whether the one they open survives a follow-up question.
Depth means the awkward parts. Anyone can list students. Handling a student with two fee accounts, a class where everyone was absent, and a user from another school trying to read your data — that is the part that took you real time, and it is the part worth talking about.
What to build, month by month
The School Management System runs through every track on this site, so you are building it anyway. Build it deliberately.
| Month | Add | Proves |
|---|---|---|
| 1 | Console application with tests | You can write and verify logic |
| 2 | The database — schema, constraints, procedures | You can design data |
| 3 | Repository layer over real data | You can connect the two safely |
| 4 | REST API with JWT and validation | You can build a real backend |
| 5 | Frontend, connected to your API | You can build a full stack |
| 6 | AI feature, deployment, documentation | You can ship |
Each month's work stays in the same repository. Six months of commits on one growing project tells a story that six separate repositories do not.
Do not restart it. Around month four the month-one code will embarrass you. Leave it, or refactor it in a commit that says why — a visible improvement is better evidence than a clean slate.
What makes a project credible
A reviewer forms a judgement in about ninety seconds. These are what they check.
It runs. Clone, follow the README, and it works. This is the single most common failure — a project that cannot be started by anyone but its author is not evidence of anything. Test it: fresh folder, fresh clone, follow your own instructions exactly.
It has the hard cases. Not just the happy path:
| Case | Why it counts |
|---|---|
| An absent student | Shows Absent, is excluded from the average |
| A student with two fee accounts | Picks the right one, not an arbitrary one |
| A duplicate roll number | Rejected at the API and by a database constraint |
| A user from another school | Cannot see your data — demonstrable from Postman |
| A class where everyone was absent | No crash, average shows zero |
It has tests, and they mean something. Nine focused tests beat sixty that assert the happy path. Comment out a fix and confirm the test fails — a test that passes either way tests nothing.
Secrets are not in it. git log -p | grep -i "password\|connectionstring\|apikey" returns nothing. A connection string in the history is a finding a reviewer will mention.
Commits look like work. Small, frequent, with messages that explain why. A single commit called "final project" tells a reviewer you did not use version control; you archived a folder.
The README that decides whether anyone looks further
Most of the time this is all that gets read. Write it last, and write it properly.
# NexCoding School Portal
A multi-tenant school management system — students, fees, exam results
and attendance — built as a full-stack application.
**Stack:** ASP.NET Core 9 · Dapper · SQL Server · React 18 · JWT
## What it does
- Staff sign in and see only their own school's students
- Search by name or roll number, filtered and paged
- Record fee payments; receipts print with the running balance
- Enter exam marks, including absences, and generate a class report
- Draft a report-card comment with an LLM, which the teacher edits
## Running it
1. `sqlcmd -S . -i database/01-schema.sql` then `02-seed.sql`
2. Set the connection string in User Secrets (see RUNNING.md)
3. Open the solution, press F5
4. `cd web && npm ci && npm run dev`
5. Sign in as admin@nca.test / Password123!
Full setup: [RUNNING.md](RUNNING.md)
## Decisions worth explaining
- **Dapper over EF Core** — reporting-heavy; I wanted to see and tune the SQL
- **Absent marks stored as NULL, not 0** — storing zero drags every class
average down by about 12% with no error anywhere
- **SchoolId read from the JWT claim, never from the request** — a caller who
can send it can send someone else's
- **The AI comment is a draft a teacher edits** — the model does not know the
student, and a person stays accountable
## Testing
40 tests. Grading logic, fee calculation, multi-tenant isolation.
`dotnet test`
## What I would add next
Pagination on the fee report, an audit trail on fee changes,
and a second-approval step on discounts.
The "decisions" section is what makes it a portfolio piece. Anyone can list features. Explaining why is the thing a reviewer cannot get from the code quickly, and it is exactly what the interview will be about.
"What I would add next" shows judgement. Knowing what is missing reads as more senior than claiming nothing is.
Screenshots matter more than you think. A reviewer who cannot run it will still look at an image.
Your GitHub as evidence
| What they see | What it tells them |
|---|---|
| Commit history over months | You worked steadily, not in one weekend |
| Small commits with real messages | You understand version control |
| Branches and pull requests | You have worked the way a team works |
| A README that explains the project | You can communicate |
| Tests in the repository | You verify your work |
| A pinned, tidy profile | You thought about the reader |
Raise pull requests even working alone. Branch, open a PR, review your own diff, merge. It costs a minute per feature and it is visible evidence of how you work. Track 16 Article 05 covers writing them.
Pin the project on your profile. Archive or unpin the tutorial repositories — a reviewer scanning twelve half-finished repositories forms a worse impression than one seeing three deliberate ones.
Deploying it
A deployed link is worth more than a repository link, because a reviewer can click it in five seconds.
Free options are sufficient: a small cloud VM, a container host, or a static frontend host with a hosted API. It does not need to be robust — it needs to exist and be reachable.
What deploying teaches you, and what interviewers ask about:
- Configuration differs between local and deployed — connection strings, CORS origins, the environment name
- The developer exception page must be off
- HTTPS certificates are real
- Something always breaks that worked locally, and finding out what is the lesson
Put the link at the top of the README and on your resume. Include the demo credentials.
What not to put in a portfolio
| Do not | Why |
|---|---|
| A tutorial project, unchanged | The reviewer has seen it fifty times |
| A repository with no README | It will not be opened |
| Real personal data of any kind | Use Ravi Kumar and NCA-2024-0012 |
| Anything with a secret in the history | It is a finding, not a project |
| Something you cannot explain | The follow-up question ends it |
| Twelve unfinished experiments | Unpin them |
| A project that does not run | The most common failure of all |
The last row deserves repeating. Before you send the link to anyone: fresh folder, fresh clone, follow your own README exactly, and see whether it runs. Better still, have someone else try it — every question they ask is a missing line in your instructions.
Common mistakes
- Building five shallow projects instead of one deep one
- Restarting the project when early code looks bad
- Leaving the README to the end and then rushing it
- No screenshots
- A project that only runs on your machine
- One commit called "final project"
- Committing a connection string
- Real student data instead of the standard examples
- Never deploying, so there is nothing to click
- Not being able to explain a decision in your own code
Practice
- List every feature your project has. Mark which handle a hard case from the table above.
- Add the hard cases that are missing. These are the interview material.
- Write the README with all six sections, including four real decisions.
- Take three screenshots and put them in the README.
- Clone your own repository into a fresh folder and follow your instructions exactly. Fix every gap.
- Give it to someone else and watch them try. Every question is a missing line.
- Run
git log -p | grep -i "password\|connectionstring\|apikey". It must return nothing. - Deploy it. Put the link and demo credentials at the top of the README.
- Pin it on your GitHub profile. Unpin the tutorial repositories.
- Write the "what I would add next" section honestly.
Exercises 5 and 6 catch the failure that costs the most and is noticed the least.
You can now
- Say why one deep project beats five shallow ones
- Build the hard cases that make a project credible
- Write a README that survives ninety seconds of scanning
- Explain four real decisions in your own project
- Present a GitHub profile that reads as evidence
- Deploy it and give someone a link
- Verify it runs from a fresh clone
Review questions
- Why does a reviewer opening one project make depth matter more than count?
- What does the "decisions" section give a reviewer that the code does not?
- What is the most common reason a portfolio project fails, and how do you test for it?
- Why raise pull requests on a repository where you are the only contributor?
Next: Interview preparation