The first pass is eight seconds, on a phone, by a non-engineer

Three different readers, three different clocks

"How long do they look at it" has three answers, because three different things look at your material and they are looking for different information. Building for the wrong one is why portfolios that are genuinely good still get no responses.

This guide is about the first two, because they are the filter. The third reader is covered in the portfolio that gets interviews guide, which goes deeper on case studies and what a technical reviewer checks. Read that one second. Nothing in it matters if the link never gets opened.

What an ATS actually parses, and what it does not

The most common misconception is that the applicant tracking system reads your portfolio. It does not. It parses your resume into structured fields and stores the result. Your portfolio enters the process as a URL sitting inside that parsed text, which makes the URL itself a piece of infrastructure worth taking seriously.

• The link must survive parsing as plain text. A URL that only exists as a hyperlink behind the word "Portfolio" can be flattened into the word "Portfolio" with the destination gone. Write the visible URL out.
• No shorteners, no tracking parameters. A shortened link looks like spam to a human and can be stripped or blocked by mail filters. A URL with a long query string looks broken and is impossible to type from a printed page.
• Short enough to retype by hand. Recruiters do this more than you would expect, particularly from a PDF opened on a phone. Compare a clean domain against a nested workspace URL with a random identifier in it: only one of those survives being read aloud.
• The same link everywhere. Resume, LinkedIn, email signature, GitHub profile. Different links in different places creates ambiguity about which is current, and the resolution is usually that nobody checks any of them.
• Top of page one. Header block with your email, not buried in a projects section on page two.

Everything else about surviving the parse is resume mechanics rather than portfolio design, and it is covered properly in the ATS resume guide. The one-line summary: the parser is a database importer, not an adversary, and the rules that matter are boring formatting rules.

What happens in the eight seconds

The recruiter taps the link on a phone. The page loads or it does not. They scroll once, maybe twice. Then they either close the tab or paste the link into a message to a hiring manager. Design the top of your page for that exact sequence.

The above-the-fold requirement

Without scrolling, on a phone, in about three seconds, a stranger should be able to state your name, what you build, and one concrete thing you have built. That means the first screen contains, in order:

1. Your name and one line of what you do. Not a mission statement. "Third-year CS student building data pipelines and small ML tools" is a line. "Passionate technologist bridging innovation and impact" is not.
2. Three projects, each with a one-sentence outcome. Not tiles with just names. The sentence is the whole point.
3. Working links. Repository, live demo or a fallback artifact, and a contact route.
4. Nothing else. No full-screen hero animation, no "scroll to discover", no typed-text effect that takes four seconds to spell your title.

The blunt test: hand your phone with the page open to someone who does not know what you do, take it back after eight seconds, and ask them three questions. What does he build? Name one project. Would you forward this? If they cannot answer all three, the top of the page is wrong, and no amount of quality further down fixes it.

Three projects, not ten

A portfolio is evaluated on its weakest visible item, not its average. Ten projects where four are tutorial clones reads as four tutorial clones with some noise around them. Three strong ones read as three strong ones. Removing work is the single highest-leverage edit available to most student portfolios, and it costs nothing but ego.

The selection criteria

• It is finished enough to use. Someone can run it, or see it running, without you present. This is the criterion that eliminates most candidates for inclusion.
• It is explainable in one sentence. If the sentence needs a subordinate clause explaining the assignment it came from, it is coursework rather than a project.
• It is distinct from the others. Three variations on the same web app demonstrate one skill three times. One systems or tooling project, one data or machine learning project, one product with real users covers far more ground.
• It survives twenty minutes of questioning. Every design decision on the page has to be one you can defend, including the bad ones, honestly, as tradeoffs you understood.
• You would still choose it if nobody was grading you. Interest shows in the writeup, and its absence shows just as clearly.

What to cut without hesitation

The tutorial-following clone with the tutorial's own structure intact. The to-do app. The portfolio site itself listed as a portfolio project. Anything with a README that is still the framework's generated default. Anything whose last commit is a broken build. None of these are shameful, they were all useful to build, and none of them belong on the first screen.

Quantified outcomes, honestly

"Built a web app with React and Node" describes tooling. "Cut a manual research process from six hours a week to two" describes an outcome. The second one is what a recruiter can forward and a hiring manager can ask about, and it is what makes the difference between a project list and a portfolio.

The honesty rule, and why it is self-interested

Every number on your portfolio is a promise that you can explain how it was produced. A figure you cannot reproduce under a follow-up question does more damage than having no number at all, because it converts "impressive" into "unreliable" in a single exchange, and the interviewer remembers the second one.

Two things make a number safe. Attach the method to it ("78% directional accuracy on a six-month backtest" is checkable; "78% accurate" is not), and be willing to retire it. I have removed figures from my own site after they failed a stricter re-test, including a trading result that did not survive a proper walk-forward evaluation and a research statistic that turned out to overstate what the published paper actually reported. Both removals were mildly painful and both were obviously correct, because the alternative is defending a number you already know is wrong in front of someone who might check.

Where a result is real but weaker than it looks, say so on the page. "Statistically significant pre-to-post gains across 60 participants" plus a note that a specific secondary comparison was not significant reads as someone who understands their own data. Omitting the caveat reads fine right up until an interviewer opens the paper.

The README is the landing page

For most technical reviewers, the repository README is your portfolio, because it is where the forwarded link goes. Treat it as a product page with a fixed structure, and put the visual proof above the fold.

1. One sentence: what it does and who it is for. Before the badges, before the table of contents.
2. A screenshot or a short GIF, immediately. This is the highest-value element in the entire README because it works on a phone, in eight seconds, with nothing installed.
3. Quickstart that works from a clean clone. Three commands or fewer to something visible.
4. Why it exists. Two sentences on the problem. This is where genuine interest becomes visible.
5. How it works. Five lines on architecture and the one or two decisions that were actually interesting.
6. Honest limitations. What it does not do, what would break at scale, what you would change. This section makes technical readers trust the rest of the document.
7. License and contact. A repository with no license is legally ambiguous, which matters more than students expect.

The clean-clone test, run once per project before you link it anywhere: clone into a fresh directory on a machine with nothing configured, follow your own quickstart literally, and change nothing you did not write down. Almost every project fails this the first time, usually on an undocumented environment variable or a hardcoded path. It takes ten minutes and it is the difference between a reviewer succeeding and a reviewer closing the tab.

The live-demo rule

A live demo is the strongest single element you can offer, and a broken one is worse than none at all, because it converts a neutral impression into direct evidence that you do not check your own work. The rule that resolves this: every project needs a fallback artifact that works with zero setup and cannot go down.

The operational half of this is monitoring. Domains expire, free tiers change policy, and a link that worked in September can be a parked domain in November while you keep sending it out. Check every link on your resume and portfolio on the first of the month, in under two minutes, and log the date the way you would log anything else in an application tracker.

The GitHub profile is part of the portfolio

Recruiters open it, usually before the personal site, and a default profile page is a wasted first impression. Four cheap fixes:

• Pin the three projects you actually want read. Otherwise the page shows whatever was touched most recently, which is frequently a course repository or an unfinished experiment.
• Write a repository description and add topics. A repo with no description is a name in a list, and topics are how search inside the platform finds you at all.
• Add a short profile README. Three lines, the same one-liner from your site, and links. Not an animated statistics wall.
• Ignore the contribution graph as a goal. A dense green grid built from trivial commits is transparent and slightly embarrassing; a sparse one with three real projects is fine. Nobody has ever been hired for a streak.

The same consistency principle applies across surfaces: the one-liner on your site, your GitHub bio, and your LinkedIn headline should say recognizably the same thing, because a recruiter checking all three is checking for coherence as much as for content. That is the subject of the LinkedIn profile guide.

The killers

• A dead link. Expired domain, moved page, typo in the resume. Fatal, common, and entirely preventable by a two-minute monthly check.
• A demo that errors or takes thirty seconds to wake. Worse than no demo, for the reason above.
• A private repository linked publicly. The reviewer gets a 404 and assumes the project does not exist.
• Secrets committed to a public repo. An immediate credibility problem in a security-adjacent conversation, and a real risk on its own. Scan before you link.
• The framework's default README. It says the project was never finished, whatever the code says.
• A site that is unreadable on a phone. Roughly half of first opens are mobile. A five-megabyte hero image on a phone connection loses more candidates than any missing feature.
• No contact route. A portfolio with no email address has failed at its only job.
• A PDF-only portfolio. Cannot be skimmed on a phone, cannot be linked to a specific project, will not be opened.
• Last commit three years ago, with no note explaining it. A finished project is fine; say it is finished. Unexplained abandonment is not the same thing.
• Claims with no method attached. Covered above, and the most expensive one on this list, because it fails in the interview rather than before it.

If you do not have three real projects yet

The honest path is short and it is not "build a bigger project." Take the most complete thing you have, finish one narrow slice of it properly, write the README as described above, record a thirty-second demo, and ship it somewhere it stays up. One genuinely finished small project outperforms three ambitious unfinished ones, every time, because the question being answered is whether you finish things.

Then add the two kinds of work students systematically undervalue: research, which is the most differentiating thing on an undergraduate resume and is available by asking a professor properly, and teaching or tutoring, which demonstrates the communication skill every interview loop is silently measuring. Both are covered in the undergraduate research guide.

The audit, in ten minutes

1. Open your portfolio link on a phone, on cellular data, not office wifi. Time it.
2. Run the eight-second test on someone who does not know what you do. All three questions.
3. Click every link on the page, including the ones in the footer.
4. Clean-clone your top project and follow your own quickstart literally.
5. Read your top three project sentences aloud. Cut every one that names only tools and no outcome.
6. Check that every number on the page has a method you could explain for two minutes.
7. Confirm the same URL appears on your resume, LinkedIn, and GitHub profile.
8. Delete the weakest visible project. There is almost always one, and the portfolio gets stronger the moment it is gone.

Run that once before a recruiting season and once mid-season. It is the whole maintenance burden. Everything else, the deeper case studies and what a technical reviewer looks for on the second pass, belongs to the next guide and to the resume itself, which is still the document that carries the link.

Tools referenced in this guide

• Resume — the document the portfolio URL has to survive inside.
• Portfolio that gets interviews — the deeper technical-reviewer pass, once the link is opened.
• ATS resume guide — the parsing rules that are real and the folklore that is not.
• Apply OS — tracking applications, links, and the monthly link check.