Resume vs portfolio: what gets IDs hired.

Two instructional designers apply for the same mid-level role. Same years of experience, same tools listed, nearly identical resumes. One gets an offer in three weeks. The other gets a polite “we went with someone whose work was a closer fit.” The difference was never the resume. It was a single link at the bottom of it — and what happened when the hiring manager clicked it.

I have sat on the hiring side of enough ID interview pipelines to watch this play out the same way over and over. The resume and the portfolio feel like the same artifact — both are “here is my work” — so people pour their energy into the wrong one. They polish the resume into a glossy keyword sheet and treat the portfolio as an afterthought. That is exactly backwards.

/01What the resume is actually for.

The resume has exactly one job: survive the filter. It is read fast, often by a recruiter or an applicant-tracking system, scanning for the keywords that map to the job description — Articulate Storyline, xAPI, needs analysis, Kirkpatrick, SCORM. Its purpose is not to win you the role. Its purpose is to not get you eliminated, and to earn the fifteen minutes where a human finally looks at your work.

So make it scannable and specific. Lead each role with an outcome, not a duty: “Redesigned onboarding curriculum; cut new-hire ramp from six weeks to four” beats “Responsible for creating training content.” Mirror the language in the job posting so the ATS and the recruiter both find what they are looking for. Then stop. The resume is a filter, not a flex — every extra paragraph you add is a paragraph the reader skims past on the way to the link.

/02The one portfolio shape that converts.

Here is the part nobody tells you. The portfolios that get IDs hired are not the prettiest, the longest, or the ones with the slickest landing page. They all share one structure: a small number of runnable case studies, each told as a story with a measurable end. Not a gallery of screenshots. Not a fifteen-tile grid. Three to five pieces a hiring manager can actually open, click through, and finish.

Every strong piece answers four questions in this order:

• The problem. What was broken? A failing compliance pass rate, a six-week ramp, a course nobody finished. Concrete and specific.
• The decision. What did you choose, and why? Branching over linear because the audience needed to practice judgment. Scenario over lecture because retention was the goal. This is the part that signals seniority — anyone can build a slide; a senior ID defends a design choice.
• The artifact. The actual module, live and launchable in the browser. They click “Launch,” the SCORM runs, the branching works, the assessment scores. This is the proof that you did the work, not just described it.
• The outcome. What changed? Completion went up, errors went down, the client renewed. Even a modest, honest number ends the story with evidence instead of a shrug.

That problem → decision → artifact → outcome arc is the spine of every case study that converts. If you want a fill-in-the-blank version, we wrote one up in the STAR case-study template, and there is a gallery of the pattern done well in ID portfolio examples.

/03Portfolio formats, ranked.

Once you have the right shape, the format you ship it in decides whether the hiring manager ever experiences your work the way you built it. Ranked by how well they survive contact with a busy reviewer:

/04The gaps that quietly kill you.

Most rejected portfolios are not bad. They are incomplete in ways the candidate never sees, because they only ever review their own work while logged in. Three gaps come up again and again.

1. The link is dead from the outside.

You test the portfolio in the tab you built it in, where you are authenticated and the cache is warm. The hiring manager opens it cold, logged out, on a phone — and hits a login wall, a 404, or a module that never loads. Always open your own link in an incognito window before you send it. The view that matters is the one a stranger gets.

2. The modules describe work instead of being work.

A wall of text that says “I built a branching scenario” with a screenshot is a claim. A button that launches the branching scenario is proof. If a reviewer cannot interact with at least one or two real modules, your portfolio is doing the same job as your resume — asserting — and you have given them no reason to believe the assertion.

3. No outcomes, so every story trails off.

“I designed a compliance course” ends on a flat note. “Pass rates on the compliance assessment rose after I rebuilt the practice scenarios” ends on evidence. You do not need dramatic numbers — you need an ending that shows you measure your work. If you are early-career and short on outcomes, borrow the discipline from how seniors think about scope and impact; our piece on pricing your first freelance ID project is really about framing the value of the work, which is the same muscle.

/05TL;DR.

The resume is a filter. Make it scannable, keyword-true to the job posting, outcome-led, and short. Its only job is to earn the click and put your portfolio link in front of a human.

The portfolio is the decision. Three to five runnable case studies, each built on problem → decision → artifact → outcome. Modules that actually launch in the browser, not screenshots of modules.

Ship it live, not as a PDF. Host the SCORM somewhere that runs it, wrap a portfolio page around it, and use expiring share-links for confidential work. Then test the whole thing logged out, in incognito, before you ever paste the link into an application.

/06Frequently asked questions.