I still keep a PDF resume around because applicant tracking systems exist and apparently we are all being punished for something.

But when I am sending my resume to an actual human, I would rather send a link.

A real URL. On a domain I control. Fast to open, easy to skim, current by default, and connected to the rest of the work: portfolio, blog, GitHub, project pages, the whole evidence trail.

That is the piece I did not fully dig into in the technical portfolio post. The portfolio is the broader job-search surface. The hosted resume link is one specific part of it, and it solves a problem that sounds small until you are juggling versions named things like resume-final-v7-actually-final.pdf like a damned archaeologist.

A PDF still has a place. A link is just better as the default.

1. The PDF attachment problem

PDF resumes are not evil. They are just brittle.

The usual problems:

  • the version you sent last week is already stale
  • recruiters forward attachments around with no context
  • mobile users get a download prompt instead of a clean page
  • some viewers render fonts, spacing, and margins differently
  • links inside the PDF are easy to ignore or miss
  • there is no obvious path from a bullet point to the supporting work

The versioning problem is the one that annoys me most.

If I improve a project page, update a certification, add a new writeup, or clean up a skills section, the old PDF does not magically update in someone else’s inbox. It just sits there, becoming less accurate with every passing week. Like documentation, but with margins.

A hosted resume page fixes that part immediately.

One URL. Current content. No attachment archaeology.

Recruiters move fast. Not because they are all careless, but because the workflow usually forces it. They are skimming names, roles, tools, dates, and signals in seconds.

A resume link helps because it removes friction:

Recruiter need Hosted resume advantage
Open quickly No attachment download, no viewer weirdness
Skim on mobile Responsive layout instead of pinch-zoom PDF misery
See current info One canonical page instead of stale copies
Share internally Forward the URL, not a file blob
Verify depth Inline links to portfolio, blog posts, GitHub, and project pages

That last point is the important one.

A resume bullet can say “built automation.” A hosted resume can link directly to the project page, blog writeup, or repo that proves there is something behind the sentence.

That is the whole show-don’t-tell argument again, just applied to the resume itself.

3. What belongs above the fold

The top of the page has one job: tell the recruiter who you are and why they should keep reading.

Above the fold, I want:

  • name
  • role or positioning line
  • location or remote/hybrid preference if relevant
  • email/contact link
  • PDF download button
  • portfolio link
  • GitHub link
  • short technical summary

Not a life story. Not a cinematic origin sequence. Nobody needs a hero banner with a stock photo of a laptop and a plant pretending to be strategy.

The summary should be direct:

Infrastructure and endpoint management professional focused on Microsoft 365,
Intune, automation, identity, security, and practical systems operations.

That kind of line gives the reader orientation. Then the rest of the page proves it.

4. Keep it recruiter-skimmable

A recruiter is not reading your resume like a novel. They are scanning for fit.

That means the page needs hierarchy:

  1. Summary
  2. Core skills
  3. Recent experience
  4. Projects and portfolio links
  5. Certifications or education if relevant
  6. Contact and PDF download

Keep the sections obvious. Use plain headings. Use short bullets. Put the strongest signal early.

If the page requires someone to solve a navigation puzzle, it has already failed. The resume page is not where I show off clever interaction design. It is where I make the right information painfully easy to find.

Painfully easy is underrated. Usually by people who design forms.

5. Link the resume to the body of work

This is where a hosted resume earns its keep.

A PDF can include links, sure. But a web page makes linking feel native instead of bolted on.

The resume page can point to:

  • portfolio.mrdtech.me project pages
  • blog.mrdtech.me technical writeups
  • GitHub repositories
  • selected scripts or documentation
  • downloadable PDF resume for ATS uploads

The pattern is simple:

Resume page
     |
     | summarized proof points
     v
Portfolio project pages
     |
     | deeper explanations
     v
Blog posts and GitHub repos

That gives the hiring manager options. If they only need the summary, fine. If they want depth, it is one click away.

That is much better than hoping someone manually copies a GitHub URL from a PDF and cares enough to paste it into a browser.

6. The PDF is still necessary

A hosted resume link does not mean deleting the PDF.

Some ATS platforms require file uploads. Some recruiters still ask for attachments. Some portals act like URLs are suspicious witchcraft.

Fine. Give them the PDF.

But make it secondary:

  • primary action: view the resume page
  • secondary action: download PDF
  • both generated from the same source if possible
  • both updated together

The goal is not link versus PDF. The goal is one canonical resume experience with a PDF export for systems that still demand tribute.

Because they will. Of course they will.

7. Build it as a static page

This does not need a resume-builder SaaS subscription.

A static page is enough:

  • HTML or Markdown/Jekyll
  • hosted on GitHub Pages
  • custom domain or subpath
  • versioned in git
  • fast load
  • no required JavaScript
  • print stylesheet or PDF export path

Versioning the resume in git is useful because changes become trackable. You can see when you updated a role summary, changed a project link, or cleaned up a skills section.

That is better than editing a mystery document in a resume platform and hoping the export did not mangle your spacing like it was paid by the broken line break.

For my setup, the clean model is the same ecosystem I am already using:

  • portfolio site on my domain
  • blog on my domain
  • resume page on the same public professional surface
  • GitHub behind it for source and version history

Simple stack. Low ceremony. Easy to maintain.

8. Keep the page boring on purpose

The resume page should load instantly.

What I do not want:

  • heavy JavaScript
  • animation that delays reading
  • third-party widgets everywhere
  • tracking junk
  • layout shifts
  • clever navigation
  • auto-playing anything, because I am not a monster

The page should be readable on a phone, printable when needed, and boring in the best possible way.

If I am building it, I care more about these details than visual fireworks:

Requirement Why it matters
Fast load Recruiters will not wait for a resume page to perform theater
Mobile layout A lot of first-pass review happens on phones
Print support Someone will still want paper or PDF
Accessible links The supporting work should be obvious and usable
No secret data Public page means public page. Sanitize accordingly

A resume page is infrastructure for opportunity. Treat it like infrastructure: small, reliable, observable enough, and not dependent on a pile of nonsense.

9. What I would put on mine

For an infrastructure-focused resume page, I would keep the content practical:

  • short summary focused on infrastructure, endpoint management, automation, and security
  • core technical skills grouped by domain
  • recent roles without naming anything that should not be public
  • selected project links from the portfolio
  • selected blog links for deeper technical context
  • GitHub link for public scripts and repositories
  • PDF download
  • contact link

The selected links matter.

Do not link every random thing you have ever touched. Link the work that supports the role you want. If I am aiming at infrastructure, endpoint, cloud, or security operations roles, I want the page to make that direction obvious.

A resume page should not be an attic. It should be a front desk.

10. Practical checklist

If I were building this from scratch, I would do it in this order:

  1. Create a clean static resume page.
  2. Put the strongest summary and contact actions above the fold.
  3. Add a PDF download button for ATS workflows.
  4. Link to the portfolio home page.
  5. Link specific bullets to project pages where it helps.
  6. Link deeper technical posts only where they support the resume story.
  7. Test it on mobile.
  8. Test print/PDF output.
  9. Keep the page in git so changes are tracked.
  10. Update the PDF whenever the hosted version changes.

That last step is where discipline matters. If the page and PDF drift apart, you have rebuilt the version-control problem with better branding. Very innovative. Still bad.

11. Closing

A hosted resume link is not a replacement for doing the work.

It is a cleaner way to present the work.

For technical roles, that matters because the strongest signal is not a perfectly polished sentence. It is a clean path from summary to evidence: resume, portfolio, blog, GitHub, all tied together under a domain you control.

Send the link when you are talking to humans. Keep the PDF for the robots and the systems that still demand uploads.

Both can exist. They should point to the same story.

Current. Fast. Shareable. Verifiable.

That beats another stale attachment floating around someone’s inbox like a cursed artifact.