On this page
The interviewer can't tell, unless you tell them
Who this is for
You've done the labs and built the projects, but when someone asks about them in an interview you shrink and call them "just practice." Stop doing that.
Here's the thing almost nobody internalises: an interviewer cannot tell the difference between a serious project and a paid task from how it sounds, they can only tell from how *you* talk about it. Say "it was just a tutorial" and it becomes a tutorial. Walk them through the decisions, the trade-offs, and the thing that broke, and it becomes engineering.
"Just a project" is two words that delete a year of your work. Never say them.
Engineers don't describe what they built, they describe decisions
A beginner lists what they used. An engineer explains *why they chose it over the alternative.* That single shift, from what to why, is the clearest signal of seniority, and it's completely available to you on a self-built project.
Listing tools
I built an app on AWS. I used EC2, an ALB, RDS, and Terraform. It worked well.
Explaining decisions
I put the app behind an Application Load Balancer so I could run it across two availability zones, I didn't want a single instance to be a single point of failure. I went with RDS over self-managed Postgres specifically so I didn't have to own backups and patching on a solo project. And I did it all in Terraform so I could tear the whole thing down and rebuild it identically, which mattered, because I was on the free tier and destroying it nightly saved me money.
- Every choice has a *because*. "Behind an ALB because I didn't want a single point of failure" shows you understand the trade-off, not just the tool.
- The RDS reasoning shows you think about operational cost, not just features. That's senior signal.
- The free-tier detail is gold, it proves the project was real enough that cost mattered to you.
The thing that broke is your best story
Counterintuitively, the most impressive thing you can describe is a failure you debugged. Anyone can follow a happy path. Engineers are paid for what happens when it breaks. A real "it didn't work and here's how I figured out why" story beats any list of technologies.
What most people write
Everything went smoothly, I didn't really run into any problems.
Rewrite that lands
My containers kept getting killed and I couldn't see why. I checked the logs, nothing obvious, then looked at memory and saw they were hitting the limit and getting OOM-killed. I'd set the limit too low for the JVM. I fixed the limit, but more importantly I added a memory alert so I'd catch it before a crash next time. That's when I really understood why observability isn't optional.
- "No problems" is a red flag, it means you either didn't build anything real or aren't reflective about it.
- The story shows a *method*: symptom → logs → metrics → root cause → fix → prevention. That's exactly how on-call works.
- Ending on the lesson ("why observability isn't optional") proves you extract principles from experience, the thing that makes a junior promotable.
Package it: the 90-second project story
- 1
What and why
One sentence: what you built and the goal. "A multi-tier app on AWS to learn production-grade infra hands-on."
- 2
A real decision
One trade-off you made and the reasoning. Shows judgement, not just execution.
- 3
Something that broke
A failure and how you debugged it. This is the part they remember.
- 4
What you'd do next
One thing you'd improve. Shows you see the gap between yours and production, which means you understand production.
You already have the raw material
The labs and capstones on this platform are built to generate exactly these stories, real decisions, real failures, real fixes. If you want a portfolio piece that interviews well, the [capstone projects](/capstones) are designed for it.
Key takeaways
- Never say "just a project", your words decide if it counts.
- Describe decisions and trade-offs, not a list of tools.
- Lead with a failure you debugged, it's your strongest story.
- End on what you'd improve, to show you understand production.
Reading is step one. Now do it for real.
Rehearse this with the platform's live tools, the first time you say it out loud shouldn't be the time that counts.
Keep reading
This is general, educational career guidance, not legal, financial, immigration, or professional advice. Examples are illustrative and simplified. Norms vary widely by country, company, role, and over time, so always verify what applies to your own situation. Nothing here guarantees an interview, an offer, or any particular outcome.