Your project isn’t getting you interviews because you’re showing the wrong thing. You built an artifact — a repo, a notebook, a deployed demo — and reviewers don’t buy artifacts. They buy decisions. The fix takes 90 minutes: stop describing what you built and rewrite it as a short record of four decisions you made and would defend.
That’s the whole move. A case study isn’t a tour of your code. It’s a decision log — the problem you chose and why, the call you’d defend, the thing you verified, the trade-off you’d redo. Spend 90 minutes converting one project into those four parts and you’ll have something a senior engineer reads to the end instead of skims and forgets.
This is for you if you’ve got a finished project — a churn model, a scraper, a side app — sitting in a portfolio that isn’t converting to callbacks. If you’re still mid-build, or you’re looking for advice on how many projects to have, this isn’t that. One finished project and 90 minutes is the whole prerequisite. And you’re not behind for not knowing this — nobody teaches it; it’s one of those skipped-fundamentals gaps everyone hits and no one names.
Why your portfolio isn’t landing
Here’s the part nobody says out loud: most portfolios fail not because the project was weak, but because the project is presented as an artifact when the reviewer is shopping for decisions.
A README answers “what is this and how do I run it.” That’s documentation for a user. A reviewer isn’t a user — they’re trying to answer one question: can this person turn a vague problem into a defensible call? That’s the actual job now. When the tool writes the code, your value is the judgment around it — what to build, what to check, what to ship. The argument that your new job is compute allocator is the larger version of this; for your portfolio, the short version is that the code is the cheap part, and a repo that only shows the code is showing the cheap part.
So a notebook full of clean cells reads as “I can follow a tutorial.” A three-line account of why you dropped 40% of your features and how you knew it was safe reads as “I can think.” Same project. The second one gets the interview.
The short version
Set a 90-minute timer. Open the one project you’d most want to be asked about. Write four short sections — none longer than a paragraph:
- The problem you chose, and why20 min
- The decision you’d defend25 min
- The thing you verified25 min
- The trade-off you’d redo20 min
That’s it. No new code, no new charts, no redesigned README. You’re not improving the project — you’re surfacing the decisions already inside it. Each block below tells you what to write and how to know it’s working.
The 90-minute conversion, block by block
1. The problem you chose, and why — 20 minutes. Start with the problem, not the tech. Most portfolios open with “built a churn model with XGBoost.” That’s the tool, not the problem, and the reviewer can’t tell whether you picked something real or grabbed the first Kaggle dataset you found. Write two or three sentences: what was the actual problem, who’d care if it were solved, and why you chose this one over the alternatives. The “why” is load-bearing — it’s the first sign you make decisions instead of following a tutorial’s default. Picking a narrow, real problem also beats a sprawling generic one — the go-wide-then-deep logic applies to projects too.
How to know it worked A stranger reads it and can restate what you were solving and why, without opening the repo.
2. The decision you’d defend — 25 minutes. Pick the single most consequential choice you made and write it up as a choice — the options, the call, the reasoning. Not “used a random forest” but “I had X and Y; I went with X because Z, knowing the cost was W.” This is the heart of the case study. One real, defended decision outperforms a list of ten technologies, and it’s exactly what an interviewer will probe — so the version on the page should be the version you can defend out loud. Hand-waving here (“it seemed like the standard approach”) is the fastest way to read junior. Directing a model in plain English to write the code isn’t the skill being measured — the point that English is not the new programming language holds — the judgment behind the call is.
How to know it worked You’d be comfortable if the interviewer’s next question were “why not the other option?” — because you already answered it.
3. The thing you verified — 25 minutes. This is the section almost no junior portfolio has, and the one seniors look for hardest. Anyone can produce an output; the question is whether you checked it. How did you know the model was actually good, the pipeline actually correct, the number actually right? Write what you did to not fool yourself: the test you ran, the baseline you compared against, the edge case you caught, the metric you distrusted and re-checked. “Accuracy was 94%, but the classes were imbalanced, so I checked precision and recall and it fell apart on the minority class — here’s what I did” is worth more than any green checkmark. Confirming a result instead of trusting it is the same discipline behind knowing when an agent is actually done, and it transfers straight onto the page.
How to know it worked The section answers “how do you know it works?” with evidence, not a claim.
4. The trade-off you’d redo — 20 minutes. Close with one honest limitation and what you’d do differently. Not false modesty (“could always improve”) and not a confession of incompetence — a specific trade-off you made under real constraints, named clearly. This does two things at once: it shows you can see your own work critically, and it pre-empts the reviewer’s “but what about…” by getting there first. “I skipped hyperparameter tuning to ship on time; with another week I’d have run a proper sweep and probably gained a few points” is a senior sentence. It says you know what good looks like and chose deliberately.
How to know it worked You’ve named a weakness a sharp reviewer would have found — so they don’t get to find it for you.
A worked example
Customer Churn Prediction — Built an end-to-end churn prediction model using XGBoost on a telco dataset. Achieved 94% accuracy. Includes data cleaning, feature engineering, and a Streamlit dashboard. Tech: Python, pandas, scikit-learn, XGBoost, Streamlit.
Customer churn for a subscription telco — flagging at-risk accounts a month out.
- Problem
- Retention beats acquisition on cost, so I built a model to flag accounts likely to churn within 30 days, early enough to act on.
- Decision I’d defend
- I optimized for recall over accuracy. Missing a churner costs more than a wasted retention offer, so I accepted more false positives to catch more real churn.
- What I verified
- 94% accuracy looked great until I saw only 6% of accounts actually churned — the model was mostly predicting “stays.” I switched to precision and recall, found recall at 0.34, and rebuilt with class weighting to push it to 0.71.
- Trade-off I’d redo
- I held out the last 3 months but didn’t fully guard against leakage from features computed over the whole window — with more time I’d rebuild the pipeline to compute every feature as of the prediction date only.
Same project. The first reads like a tutorial finished. The second reads like an engineer who can be trusted with an ambiguous problem. Notice the “after” is shorter on tech-name noise and longer on judgment — which is exactly the trade the reviewer wants.
Would it survive a senior’s skim?
The first read is fast and unfair. In Ladders’ eye-tracking study, recruiters spent an average of 7.4 seconds on a resume’s initial pass — and a senior engineer skimming your case study isn’t much slower. So before you call it done, run four binary checks. Each is a yes or a no:
- Problem, not tool, in the first line?yes / no
- One decision written as a defensible choice, not a fact?yes / no
- Evidence you verified the result, not just produced it?yes / no
- One honest, specific trade-off named?yes / no
Four yeses and it survives the skim. Any no is a 5-minute fix, not a rewrite — that’s the whole reason you wrote the four blocks separately. If you want one line to judge the entire thing by: a reviewer should be able to argue with you after reading it. If there’s nothing to argue with, you wrote a README.
The common failure is writing all four sections but hedging every one (“I think,” “probably,” “it seemed”). Hedging reads as not having decided. Go back and cut every qualifier you can’t defend — a wrong-but-owned call reads stronger than a right-but-hedged one.
How it reads to an AI-era reviewer
One last reason decisions beat artifacts: the artifact half is now trivial to fake, and reviewers know it. A clean repo proves less than it used to when a model can generate one over lunch. What a model can’t generate is your account of why you chose this problem and how you caught your own mistake. That part is still scarce — so that’s the part worth points.
It’s the same shift happening inside interviews. The case for allowing AI in interviews is that once the tool is in the room, the only thing left to measure is judgment — and a decision log is judgment, on a page, before the interview even starts. Write it well and you’ve answered the interviewer’s hardest questions before they think to ask them.
So open the project you most want to be asked about. Set the timer, write the four blocks, run the four checks, and ship the version a reviewer can argue with. Do it today, on the project you’ve already finished — the work is done. You’re just finally showing the half that gets you hired.
Sources
- 1Ladders, Inc. — eye-tracking study (2018 update of its 2012 study) — recruiters spend an average of 7.4 seconds on the initial scan of a resume. Reported by HR Daily Advisor, November 15, 2018.