The 90-day GitHub profile audit for your job search

The worst time to clean up your GitHub profile is the week you start applying. At that point every fix shows its seams: half-finished READMEs, repositories updated in a rush the night before, a contribution graph that suddenly lights up after months of nothing. Reviewers can read dates. A profile that changed shape in the same week a job search started says something, and it is not the thing you want it to say.

There is also a slower mechanical reason to start early. Much of what a profile needs — a real contribution graph, steady commit history, projects that show repeated attention rather than one dump of work — only exists after weeks of ordinary activity. You cannot backfill sincerity.

This is a week-by-week audit for the roughly ninety days before a job search, built around what actually gets read: the software that filters applications first, the human who might open your profile at a technical stage, and the specific signals each of them checks. It assumes you have a normal GitHub account, private work or not, and a job search no more than three or four months away.

Key Takeaways

• Nearly every large employer filters applications with software first, and recruiters lean on those filters hard, so your resume and profile need to survive a keyword pass before any human sees you.
• A recruiter working through applications has little time to spare; sourcing screens are not deep reads, which means the first screen of your profile — photo, bio, pinned repos, profile README — carries most of the weight.
• Ninety days is about the minimum for contributions and commit history to look ordinary rather than staged, and that matters more than volume.
• The highest-value fixes are unglamorous: archive dead forks, write real READMEs for three to six pinned repositories, make each one runnable, and stop representing abandoned tutorials as current work.
• Anything you can derive from your own data — language breakdowns, star counts, contribution totals — is evidence a reviewer can check, so prefer that over unverifiable claims in your resume.

What gets read before any human reads you

Start with the least rational-sounding fact about job searching: your resume is usually not read by a person first. It is read by software. Applicant tracking systems parse your resume into structured fields, then let recruiters search that text. A link to GitHub in a parsed resume is, to that system, just a string. Whether anything ever follows that link starts with how your document parses and what it contains as plain text.

The scale of that filtering layer is stable to the point of boredom. Between 2018 and 2026, every edition of Jobscan’s annual census has found an ATS at roughly 98 out of every 100 Fortune 500 companies:

1009998979695Fortune 500 career pages where an ATS was detected (Jobscan)98.2%201898.8%201997.4%202398.4%202497.8%202597.4%2026SHARE OF FORTUNE 500 USING A DETECTABLE ATSAxis starts at 95% to make a flat trend readable. Source: Jobscan, 2026.

Inside those systems, the filtering is aggressive. In Jobscan’s 2025 survey of 384 recruiters, 99.7% reported using filters or keyword searches in their ATS to find candidates, and 41% said they also go back through their own stored candidate pools from previous openings. Two things follow for you. First, the skills and keywords on your resume must match how the job description words them, because a filter searches literally. Second, recruiters search databases for candidates already in the system, which means a clean, well-parsed application today is an asset for openings that exist years from now. The full mechanics are in the complete guide to getting past an ATS.

Why does a profile audit take 90 days?

Because the evidence a profile is supposed to show is mostly evidence about time. A reviewer clicking into your account can see when repositories were created, when commits landed, whether activity is continuous or a burst. There is no way to fake a slow accumulation of ordinary work, and also no need to: ninety days of real activity is a legitimate pattern by definition.

The time pressure lands on the other side of the table. Bullhorn’s 2025 GRID survey of more than 1,500 recruitment professionals put the average recruiter’s time spent searching for candidates at 14.6 hours per week — more than a third of a working week spent just looking for people before any interviews happen:

RECRUITER HOURS A WEEK AI COULD HAND BACK (BULLHORN, 2025)4.53.68.9Search and matchScreeningRest of the 17-hour totalCandidates spend their time on job boards instead: 66% of candidates useLinkedIn, Indeed or similar sites, against 35% who use recruitment firms.Source: Bullhorn GRID 2025 Industry Trends Report.

Read that as a scarcity statement, not a feature announcement. A person with fourteen-plus hours of searching already on their calendar is not going to reconstruct your career from your repository list. They pattern-match on whatever is visible in seconds: the photo, the bio, the pinned work, whether the graph suggests a working developer. What does and does not get looked at, and by whom, is covered honestly in do recruiters actually check your GitHub.

So the ninety days split into three jobs: make the first screen strong, make the second click survive scrutiny, and let the passage of time quietly fix what nothing else can.

Whose ATS your resume lands in parses GitHub links as text

It is worth knowing which systems you are writing for, because the same resume passes through different parsers with different quirks. Jobscan’s 2026 analysis of more than 13,000 job listings where an ATS was detected found Greenhouse the most common in the broad market at 19.0% of companies, then Workday at 17.5%, Lever at 15.6% and iCIMS at 14.4%, with dozens of smaller systems sharing the rest:

WHICH ATS COMPANIES USE (13,000+ ANALYSED, 2026)No singlewinnerGreenhouse — 19.0%Workday — 17.5%Lever — 15.6%iCIMS — 14.4%Everything else — 33.5%Source: Jobscan 2026 ATS Usage Report, broad-market analysis.Everything else is the remainder after the four named systems.

The practical reading: your GitHub URL is parsed as plain text, your skills section is searched literally, and none of these systems open links. Everything the ATS sees of your GitHub work is what you wrote about it on the resume in the system’s own vocabulary. How to phrase that text is covered in how to put GitHub on your resume.

Weeks 1 and 2: fix the first screen

The first screen is what a reviewer absorbs before clicking anything. Work through it once, slowly, and fix what is stale:

• Photo, name, bio, location. A blank profile reads as low signal. The bio is one line that says what you build; nothing clever is required.
• Username. If it is a gamertag from school, change it now — this is exactly the kind of change that should happen long before any applications, since links already circulating will break.
• Pinned repositories. GitHub shows up to six. Pin three to six that represent real, current work and unpin everything else. The default unpinned view often surfaces whatever was updated last, which might be a two-year-old tutorial.
• Profile README. The special repository named after your username renders a document at the top of your profile. A short one — a sentence or two on what you work on, links to a few real projects — gives a reviewer context before they start clicking. Setup and structure are in the profile README guide, and a fuller treatment of the first screen is in how to make your GitHub profile professional.
• Repository descriptions. Every pinned repository has a one-line description field empty by default. Fill it in for every public repo you want seen; a reviewer scanning your profile relies on that line to decide what is worth opening.

Week 1 is identity and pins. Week 2 is the profile README and descriptions. Both are low-effort, and both change what eleven seconds of pattern-matching has to work with.

Weeks 3 to 6: make the pinned projects hold up to a second click

The second click is where real judgment happens, and where most profiles quietly fail. When a reviewer opens a pinned repository, they are checking several things in under a minute:

1. Is there a real README? Not a title, but an explanation: what the project does, why it exists, how you run it. A repository a stranger cannot understand is not evidence of anything except that the builder never considered a stranger.
2. Does it run? Install and start instructions that were true at some point count for little. In the audit, run every pinned project’s setup yourself on a clean clone. Broken builds that sat for a year are visible; a rebuild last month is also visible, in the right way.
3. Is the commit history legible? Commits named “fix bug,” “update,” “changes” tell a reviewer nothing about how you think. Descriptive messages on future work fix this for free going forward; rewriting a distant history is not worth the risk of breaking old states.
4. Is the scope honest? A tutorial rebuild presented as a e-commerce platform is one of the fastest credibility losses available, and experienced reviewers have seen the same course projects many times.
5. Is there anything to quantify? Stars are not the point, but real, checkable numbers are: merged pull requests, contributors, tests passing, play counts, whatever the project actually produced. Finding useful numbers you did not think to track is its own skill, covered in how to quantify engineering achievements.

The audit’s question for each pinned repository is simple: if a thoughtful engineer spent ninety seconds here, would they learn something true about you? Repositories that fail the test get three options: improve them, remove them from the pin list, or archive them. Archiving is not hiding; it just marks a project as historical work rather than current evidence.

By the end of week 6, you should have removed the junk, improved the keepers, and be left with a short list of repositories that each tell one coherent story about the kind of engineer you are. Choosing between competing candidates for the resume and the pin list is its own decision, covered in how to choose which GitHub projects belong on your resume and in more detail on the wording side in how to describe GitHub projects on a resume.

Weeks 7 to 9: does your language breakdown match what your resume claims?

Somewhere in the first several scrolls, a reviewer cross-references the languages your resume lists against what your public repositories show. The cross-check is fast and unforgiving. Claiming to specialise in a language that never appears in your public work raises exactly the wrong question.

This is also a moment to notice how fast the ground moves. GitHub’s Octoverse 2025 report found that in August 2025 TypeScript overtook both JavaScript and Python to become the most-used language on the platform, adding more than one million contributors in a year, up 66%. The platform as a whole passed 180 million developers, with over 36 million joining in the previous twelve months:

LANGUAGE GROWTH ON GITHUB, YEAR OVER YEAR (2025)TypeScriptPythonJavaScript+66%+48.8%+24.8%0+20%+40%+60%TypeScript became the most-used language on GitHub in August 2025.Source: GitHub Octoverse 2025.

Two things follow for the audit. The first is arresting: if your public work is heavily JavaScript and your resume claims TypeScript or vice versa, the mismatch now has a documented company trend behind it. Migrations happen on a public profile in a legible way — a real port of a project to TypeScript over three or four weeks is a legitimate, visible piece of evidence, not a stunt. The second is the scale point: with 36 million developers joining in one year and 630 million projects on the platform, no one is going to hunt for an unusual mix of languages. The reviewer checks what is visible. Visible coherence, in this market, is worth more than ambitious old claims.

If you are pivoting languages or adding one for the first time, weeks 7 through 9 are the right window to make the change public and start generating real history in it.

Weeks 10 to 12: rebuild the activity record the honest way

The contribution graph is the element people worry about most and should worry about least, as long as it reflects reality. Its mechanics matter here: the graph counts public contributions on the default branch, and a list of things that do and do not show up is in how the GitHub contribution graph works. Private-repository contributions count only if you enable the setting, and most company repositories will not, so a period of quiet public work is not a lie. Reviewers who have written code for a living know this.

What the audit asks in this window is simply to generate ordinary, visible, relevant activity:

• Work on your pinned projects rather than starting new ones. Depth on three repositories outperforms breadth across fifteen.
• Open issues or pull requests against projects you actually use. A small, merged, well-described contribution to someone else’s project is among the strongest signals available, because it was accepted by a maintainer with no reason to be polite.
• Write good commit messages from now on. This fixes nothing retroactively and everything prospectively.
• Respond to issues on your own repositories. A repo with unanswered issues looks abandoned; a repo with thoughtful replies looks maintained, at whatever scale.

There is one thing to refuse in this window, and it is the temptation to manufacture the graph itself — empty automated-commit feeding, green-squares stuffing, bulk-import tricks. Reviewers do not read the graph as a résumé of effort; they read it as a fingerprint of habit, and manufactured patterns are odd-shaped fingerprints. The profile should be tidied, not performed. For the evidence side in aggregate, a comparison of what a profile can honestly prove against unverifiable resume claims is in why people lie on resumes and how GitHub fixes it.

Week 13: package the proof

By week 13, the account is clean, the pinned work is strong, the history has had a quarter to accumulate honestly. The last step is packaging, because a profile is evidence for the one-percenters who click; the resume is evidence for the filter that reads everything.

• Turn the audit’s findings into resume bullets: the projects that survived, described with their real numbers. A projects section that reads as evidence rather than a list is where this material belongs.
• Generate a working resume directly from the profile. resumefromgit.com takes a GitHub username and produces a dashboard — language breakdown, repository analytics, contribution history — plus a free, ATS-friendly PDF resume built from that data, with no login and no AI in the pipeline. Because it is derived from the account itself, it cannot drift from what a reviewer later verifies.
• Before each application, check the resume against that specific job description’s wording. The filter pass described earlier happens per application, not per quarter.
• Put a working link where the ATS and humans can both see it: resume header, profile README, LinkedIn.

What a 90-day audit will not fix

Say the limits plainly. Ninety days will not manufacture a decade of open-source standing, turn a career of private-work-only engineering into a public record, or substitute for skills. Where your strongest work lives in company repositories that will never be public, the audit’s job is different and simpler: make the small public surface that does exist coherent, and let the resume and the interviews carry the rest. Nothing in this plan asks you to perform openness you do not have.

Anything you cannot verify stays off the resume. GitHub’s contribution to hiring is that it makes some claims checkable; the moment evidence becomes invented, the tool stops working for you. Also worth understanding: AI-assisted development now shows up in profiles in its own ways, and the visibility mechanics are covered in whether Copilot usage shows on your GitHub profile.

Frequently asked questions

How much time does the audit actually take each week?

Two to four hours in weeks 1 and 2, one to two hours a week through weeks 3 to 6, and from week 7 onward most of the work happens inside the coding you would do anyway. The point is unglamorous consistency, not a heroic weekend.

I have a job already. Can I skip to the weeks I need?

Yes, with a caveat. If you are applying within days, do the week 1 screen fix and skip the deep work; a strong pin list is better than a half-finished overhaul you did not have time to complete. The parts that need weeks — commit history, graph continuity, merges landing in other people’s projects — only help if the timing allows them to happen naturally. That is exactly why the audit starts ninety days out.

Does an empty contribution graph disqualify me?

No, and pretending it does would be dishonest, since plenty of hired engineers have quiet graphs because their work is private. What a graph fails to do is help. If your public record is thin, your resume has to carry more of the load, and the profile that does exist should be as coherent as possible. What reviewers actually conclude from an empty profile is covered in do recruiters actually check your GitHub.

Is it worth making personal forks of big open-source projects?

Almost never on its own. A fork full of unmerged changes is a folder with a fork label. Contributing upstream is what produces a checkable signal: merged pull requests, accepted patches, issue discussions. If a fork exists as scratch space, unpin it.

Should I pin repositories that are demo or tutorial projects?

Only if they are annotated so no one mistakes them for original work, and preferably not at all in the pinned list. If one is genuinely useful — a template you built, a rebuilt project that taught you something — say exactly that in the README. The failure is not the fork itself, it is presenting it as more than it was.

When should I generate the PDF resume?

After the audit, not before. The generator is only as current as your account; producing it two to three weeks before applications start means the numbers, languages and contribution summary it lists all match what a reviewer will see when they check.

The quiet point at the end of ninety days

The strongest reading of this whole audit is that it does not exist to impress anyone. Its actual goal is sturdier: to remove every reason a careful reviewer could reasonably disbelieve you. A profile with coherent pinned work, honest language claims, ordinary-looking history and real numbers does not argue for you. It simply stops arguing against you, which in a market this filtered is most of what you control anyway.

Three months of low-effort ordinary work gets you there. If you want the evidence side ready-made, resumefromgit.com turns any public GitHub username into a visual CV and an ATS-friendly PDF resume in seconds before your first application goes out.