Portfolios list strengths. Here's the other side, because hiding it would make this series dishonest.
Every project I've written up has a limits section. Here I'll pull them together in one place and add the broader, personal gaps. If you're a hiring manager, a teammate or another student, I'd rather you see where my edges are than guess.
Gaps my projects don't prove
Testing
CardBridge has no automated test suite. The case study says so, and I know it's a gap. For a project where money-rules matter, that's the most important thing to fix, and I'll write the plan on Day 20.
Contrast that with Job Scheduler, where I did write tests: 156 algorithm unit tests, plus a concurrency check where 300 jobs were claimed by 10 concurrent claimers with zero double-claims. So I know what good looks like. I just didn't carry it across every project.
Things I wrote but never measured
Whiteboard.ai has an AI review evaluation: 15 fixture boards with 16 planted flaws and a 12/15 pass bar. It's written and graded deterministically, but it has never been run against a real API key. So the review prompt's real catch rate is unmeasured. A feature that's untested against reality is a hypothesis.
Not deployed
Whiteboard.ai also isn't deployed. It runs locally against a dev Supabase project, so there's no live demo. Its load numbers come from one Mac with the database 76 ms away and haven't been re-measured on staging. Payment checkout has been tested with a scripted provider and mocked browser flow, not real test mode.
Single-node and free-tier realities
- Knot.ai keeps state single-node (in-memory per round, plus SQLite). It runs on Render's free plan, which sleeps after about 15 minutes idle, and a cold start mid-interview breaks the voice loop. The interview brain is verified against a mocked voice service; the live voice path is the thinner-tested surface.
- Hospitality.ai runs on entirely synthetic data: the policies, the 14 Bengaluru hospitals and their tariffs are invented. It doesn't read scanned PDFs, and its distances are straight-line, not drive time.
- CardBridge's escrow and KYC providers are stubs.
- GigShield's payouts are simulated.
None of that is hidden. Most of it is in the case studies, because the limits are part of the work, not an embarrassment to bury.
Broader gaps
Beyond individual projects, here's what a list of projects can't tell you:
- Scale. Everything I've built has handled student-sized traffic, not production traffic. A load test on one laptop is not the same as running a service.
- Long-term maintenance. Building is fun. Living with a codebase for years, through changing requirements and teammates leaving, is a skill I haven't had the chance to learn.
- Working in a mature codebase. My projects are mostly mine, which is the easy mode. Reading, extending and not breaking someone else's decade-old code is a different skill.
- Estimating. It's easy to be too optimistic. I'm working on writing estimates down and comparing them to reality.
- Production operations. Monitoring, on-call, incident response. I've read about them. I haven't done them.
Things I'm working on
- Writing tests before the next project gets big. Retrofitting is harder than starting with them.
- Reading other people's code, not just writing my own (Day 28).
- Measuring things I only believe. Running that eval is on the list.
- Shipping things instead of letting them sit at 95%. My template is a good example: built, not published, as I wrote on Day 4.
Why I'm publishing this
Because if someone reads my work, I'd rather they see a student who knows exactly where the edges are than one who pretends they don't exist.
There's also a selfish reason: naming a gap publicly makes it harder to ignore. A private list gets quietly shortened. A public one stays on the page.
An exercise you can copy
Write your own honest list, in three columns:
| Things my projects prove | Things they don't prove | What I'll do about it |
|---|---|---|
The middle column is the valuable one. It tells you what to build or learn next.
Turn each gap into a learning plan
A gap is only useful if it becomes an action. Here's the template, filled in for testing as an example:
GAP: My largest project has no automated tests.
WHY IT MATTERS: Rules protecting money can break silently.
FIRST STEP (this week): Write table-driven tests for the state machine.
SECOND STEP (next week): Add a concurrency test and policy tests.
EVIDENCE OF PROGRESS: A test command that runs in CI and fails when a rule breaks.
REVIEW DATE: in 30 days.
The "evidence of progress" line is the one that matters. Without it, a plan is just a wish.
Prioritising gaps
You can't fix everything. Rank gaps on two axes:
| Cheap to fix | Expensive to fix | |
|---|---|---|
| High impact | Do first | Plan and schedule |
| Low impact | Do when convenient | Ignore for now |
For me, "run the eval I wrote" is cheap and high impact, so it comes first. "Learn to operate a production system" is expensive and high impact, so it needs a longer plan (probably through an internship or job, not a side project).
How to talk about weaknesses in an interview
A question like "what's your biggest weakness?" is easier when you've done this exercise. A good answer has four parts:
- A real gap, not a disguised strength. ("I'm a perfectionist" is not an answer.)
- Evidence you've noticed it. ("My largest project has no automated tests.")
- What you're doing about it. ("I've written a plan to test the state machine first.")
- Progress so far, if any.
Interviewers rarely expect perfection. They look for self-awareness and a habit of improving.
Gaps versus excuses
A useful distinction:
- A gap is something you're aware of and working on.
- An excuse is a reason not to work on it.
"I haven't deployed Whiteboard.ai" is a statement of fact. "I haven't deployed it because the deployment step is boring" starts becoming an excuse. Honest lists help you notice when one turns into the other.
Strengths still count
Naming gaps doesn't mean ignoring strengths. A balanced self-assessment has both columns. If your list is entirely gaps, you're probably being unfair to yourself; if it's entirely strengths, you're probably missing something.
Revisit it
Put a reminder on your calendar to re-read your honest list in 30 days. Cross off what's done, add what's new. A gap list that never changes isn't being used.
What's on your honest list? I'll go first in the comments if nobody does.
Top comments (4)
The mature-codebase gap seems harder to turn into evidence than 'run the eval.' I'd make the first step a small fix in someone else's repository: trace an existing behavior, explain why it works that way, then get the change reviewed. That would test reading and negotiating constraints that your own projects let you choose freely. Would you count an accepted change as progress on that gap while keeping long-term maintenance explicitly open?
The list is the easy half, and you know it, which is why testing already has a Day 20 next to it.
I read a lot of these. The ones that close a gap have two things: a date and a person who will check. The others stay honest and stay open, because an honest list is a comfortable place to stand. From the inside it looks like work.
So: testing, Day 20. Who sees it on Day 21?
This is a really underrated move. Most people hide their gaps because they think the gaps are the thing that makes them look small, but hiding them is what keeps you nervous. Some part of you is always waiting to get found out. Putting them on the page takes that weight off. "A private list gets quietly shortened" is so true. Once it's public your brain stops treating the gaps as a secret and starts treating them as a to do list, and you can walk into an interview as yourself instead of defending a version of you that doesn't exist. Good luck with the rest of the series.
which gap are you closing first?