DEV Community

Cover image for Case-Study Portfolios That Humans and ATS Both Parse
Muhammad Ali Mughal
Muhammad Ali Mughal

Posted on

Case-Study Portfolios That Humans and ATS Both Parse

#career #portfolio #resume #programming

A hiring manager once told me she shortlisted a candidate because of one case study: a two-page write-up of how he cut a nightly billing job from four hours to eleven minutes. The recruiter screening before her almost rejected the same candidate. His resume said "See portfolio" and linked to a Notion page. The ATS stored the link as plain text and found almost none of the keywords the role asked for. The best evidence he had was in a place the first filter could not read.

I wrote this with help from AI tools and checked every template, example and parser result myself. I am a Principal Software Engineer in Karachi with 9+ years across PHP/Laravel, Vue, Node and .NET microservices. I review portfolios when we hire, and I build Smart Resume Analyzer. This is Part 4 of the series Interview Proof Beyond the Resume. Part 1 covered take-home tests, Part 2 covered live coding and Part 3 covered system design from production scars. Those were about proving depth in the room. This part is about getting your proof to the room at all.

📚 Series Roadmap — Interview Proof Beyond the Resume

Related earlier posts: The One-Story Resume Test: Building a Flagship Project Section · GitHub & Open-Source Proof of Work on Your Resume · Tailoring Without Lying

How do you make a portfolio case study that both ATS and humans can read?

Direct answer: Put a short text version of each case study inside the resume itself, under a plain heading like "Selected Case Studies", with the problem, your actions, the stack and a measured result. Link each one to its own HTML page with the full story. The ATS reads the resume text; humans click the link. Never hide key evidence only behind a URL.

Blank sheets of white cardstock stacked on a pale desk in soft light, AI-generated

Two readers, two very different parsers

Your portfolio has two audiences and they read in opposite ways.

The ATS reads the file you upload. It extracts text, splits it into sections based on headings, and maps it to fields such as job titles, dates, skills and education. Most systems do not follow links, render JavaScript or log into anything. A URL is just a string. If the evidence is only on the other side of that string, the system never sees it.

The human spends seconds on the resume first. If something catches their eye, they click. On the linked page they want a quick answer to three questions: what was hard, what did you personally do, and did it work? They will not scroll through a 3,000-word essay or watch a ten-minute video to find out.

So you have one job with two outputs: a compact text version that survives parsing, and a skimmable page that rewards a click.

What goes wrong with typical portfolios

These are the failure patterns I see most often when reviewing engineering applications:

  • "Portfolio: link" and nothing else. No keywords, no results, no reason to click.
  • Case studies as images or slides. A PDF export of Figma frames or a slide deck is mostly images to a parser. Even with OCR, layout and order are unreliable.
  • Client-rendered portfolio sites. A single-page app that shows a spinner until JavaScript loads gives link previews, crawlers and some reviewers' tools an empty page.
  • One giant page for everything. You cannot link a recruiter to "the payments story" if all five projects live on one scroll.
  • Team results with no personal role. "We migrated to Kubernetes" says nothing about what you did.
  • Confidential details pasted in. Customer names, internal dashboards and revenue numbers make reviewers nervous about your judgement.

Step 1: write the resume version first

The text version is the one that has to work, so start there. Keep each case study to three or four lines. I use this structure:

SELECTED CASE STUDIES

Billing Pipeline Rewrite | PHP 8.2, Laravel, PostgreSQL, Redis, AWS SQS
- Nightly invoicing for 40k B2B accounts took 4 hours and blocked month-end close.
- Split the monolithic job into idempotent per-tenant jobs on SQS, added
  partitioned queries and a reconciliation report.
- Runtime fell to 11 minutes; month-end close moved from day 3 to day 1.
  Case study: https://yourname.dev/case-studies/billing-pipeline

Checkout Latency Fix | Vue 3, Nuxt 3, Node.js, Redis, OpenTelemetry
- p95 checkout latency hit 2.8 s during campaigns; cart abandonment rose.
- Traced the slow path to N+1 pricing calls, added request-scoped caching
  and a stale-while-revalidate layer for catalog data.
- p95 dropped to 640 ms under the same peak load; abandonment fell 9%.
  Case study: https://yourname.dev/case-studies/checkout-latency
Enter fullscreen mode Exit fullscreen mode

A few rules hold this together:

  • Plain heading. "Selected Case Studies" or "Projects" parses reliably. Clever headings such as "Things I'm Proud Of" may not be mapped to any known section.
  • Stack on the title line. It puts the skill keywords next to the evidence, which helps both keyword and semantic matching.
  • Problem, action, result. One line each. Numbers in the result line.
  • Full URL in text. Write the URL out so it survives copy-paste and plain-text conversion. Hyperlinked words like "here" lose the target in many parsers.
  • Single column. Put this section in the main column, not a sidebar.

To choose which case studies to include and which stack terms to lead with, I paste the job description into the job description keyword finder and pick the two or three stories that honestly cover the most of those terms. Then I run the finished file through the ATS parser to confirm the section is recognised and the text comes out in the right order.

Step 2: build one page per case study

Each case study gets its own URL and its own server-rendered HTML page. A static site generator, a simple blog, or a Nuxt or Next site with server rendering all work. The important part is that the content is in the HTML response, not injected later.

<article>
  <h1>Billing Pipeline Rewrite: 4 Hours to 11 Minutes</h1>
  <p class="summary">
    I rewrote nightly invoicing for 40k B2B accounts so month-end close
    moved from day 3 to day 1. Role: lead backend engineer, team of 3.
  </p>

  <h2>Context and constraints</h2>
  <p>Laravel monolith, PostgreSQL 14, no downtime allowed during business hours...</p>

  <h2>What I did</h2>
  <ul>
    <li>Split the job into idempotent per-tenant jobs on SQS</li>
    <li>Partitioned invoice queries by billing period</li>
    <li>Added a reconciliation report finance could check every morning</li>
  </ul>

  <h2>Result</h2>
  <p>Runtime 4 h to 11 min. Zero duplicate invoices across 6 months.</p>

  <h2>What I would do differently</h2>
  <p>Add the reconciliation report first, not last.</p>
</article>
Enter fullscreen mode Exit fullscreen mode

Keep the order fixed across every case study: summary, context, what I did, result, what I would change. Reviewers learn the layout on the first page and skim the rest faster. Add one diagram or screenshot if it genuinely helps, with sensitive data blurred, and give it alt text.

Test the page the way a tool would see it:

# Is the real content in the HTML response, or only after JavaScript runs?
curl -s https://yourname.dev/case-studies/billing-pipeline | grep -c "11 minutes"

# Does the page return 200 without redirects to a login wall?
curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" -L \
  https://yourname.dev/case-studies/billing-pipeline
Enter fullscreen mode Exit fullscreen mode

If the first command prints 0, the content is rendered client-side and many previews and tools will see an empty shell.

Formats compared

Format ATS reads the evidence? Human skim time Link-friendly? Recommendation
Text case studies inside resume ✅ Yes Fast n/a Always include
Server-rendered HTML page per study ❌ Not followed, but crawlable Fast if structured ✅ One URL each Best companion
Notion or Google Docs public page ❌ Medium ⚠️ Permissions break OK as a stopgap
PDF slide deck or Figma export ❌ Mostly images Slow ⚠️ Large downloads Avoid for engineers
GitHub repo README ❌ Not followed Medium ✅ Good for code-heavy work
Video walkthrough ❌ Slow ✅ Optional extra only
Client-rendered SPA portfolio ❌ Fast once loaded ⚠️ Empty previews Add server rendering

Handling confidential work

Most of the best engineering stories happen inside companies that will not let you publish anything. You can still write a case study:

  • Replace the company with a description: "a regional insurtech platform" or "a B2B SaaS with 40k accounts".
  • Use relative or rounded numbers: "around 2k requests per second", "cut runtime by 95%".
  • Rebuild diagrams from scratch with generic labels. Never screenshot internal tools.
  • Keep code samples to patterns you could write again from memory, not copied source.
  • Add a short note: "Details generalised to respect client confidentiality." Reviewers respect it.

Diagnostic checklist

  • [ ] The resume contains a "Selected Case Studies" or "Projects" section in the main column.
  • [ ] Each case study has a title line with the stack, plus problem, action and result lines.
  • [ ] Every result line has at least one real number.
  • [ ] Each case study links to its own URL, written out in full.
  • [ ] Linked pages return 200 without login, cookie walls or expiring share links.
  • [ ] Page content appears in the raw HTML response.
  • [ ] Your personal role and team size are stated on each page.
  • [ ] Confidential names, data and screenshots are removed or generalised.
  • [ ] The resume file parses with the case-study section intact and in order.
  • [ ] Stack terms match real keywords from the job description, and every one is true.

FAQ

How many case studies should I include on a resume?

Two or three. Pick the ones that best match the role. More than that pushes your experience section down and dilutes the strongest story.

Should case studies replace my experience bullets?

No. Experience bullets show breadth across roles; case studies show depth on one problem. Keep both, and avoid repeating the same sentence in each.

Do ATS systems follow portfolio links?

Generally no. Most store the URL as text and only parse the uploaded file. That is why the resume version must carry the keywords and results.

Is a GitHub profile enough as a portfolio?

For open-source or code-heavy roles it helps a lot, but recruiters rarely read code. Add a README case study that explains the problem and result in plain language.

Can I host case studies on DEV or Medium?

Yes, and they are crawlable and fast. Just keep one post per case study so you can link each one directly, and make sure the title states the result.

What about design-heavy portfolios with lots of visuals?

Keep the visuals, but put the written summary and results in real HTML text above them. A parser or a busy reviewer should get the point without loading a single image.

Next in this series, Part 5 covers async video and written interview answers that still sound like you rather than a script.

Follow & Connect

Top comments (0)