Field Notes

What hiring managers actually look at on a senior backend engineer's GitHub in 2026 (and what they ignore)

Valerii Hurachek · May 15, 2026 · 15 min read

What hiring managers actually look at on a senior backend engineer's GitHub in 2026

The senior backend GitHub review in 2026 is short. The recruiter self-reports I've seen cluster around a minute or two, sometimes less. Whatever the candidate hopes the reviewer will read deeply, what actually happens is a scroll through the profile page and a binary call before any source file is opened.

What gets scrolled past — and what gets opened — is not random. It is a short list of signals hiring managers have learned to trust because AI-generated portfolios cannot fake them at scale, plus a short list of anti-signals that auto-trigger a close-tab. With AI-assisted applicant materials near half by DISHER Talent's 2026 estimate, polish and green squares are now the average, not the signal. The reviewer's attention shifts to what's harder to fake.

Most senior-engineer career advice still treats GitHub like a junior portfolio — get green squares, ship side projects. That advice was calibrated for a different signal-to-noise ratio. Hiring managers in 2026 look at five things and ignore four. The five are proof the resume claims are real. The four are evidence the resume was padded by tooling.

What follows is what's in each pile.

Before the signals: the data context

Roughly three-quarters of resumes never reach human eyes; when they do, GitHub becomes the verification layer (Harvard "Managing the Future of Work" project, cited 2026). Eighty-eight percent of employers acknowledge their automated filters reject qualified candidates — which means the resumes that survive the pipeline are pre-selected for parser fit, raising rather than lowering the verification bar at the human stage. The polished profile paradox compounds this: with AI-assisted applicant materials near half (DISHER Talent, 2026), the resumes increasingly look identical too.

The review window is short. Recruiter and hiring-manager self-reports cluster around a minute or two — sometimes less. The reviewer is not deep-diving; she is pattern-matching against a short list. Behind all of this, recent computer-science graduates were unemployed at 5.8% in 2025 against a 3.6% national baseline (BLS), which raises the verification bar at every stage above them.

These numbers are why senior backend GitHub matters more in May 2026 than it did three years ago, and why most advice about it is still calibrated for the wrong portfolio.

What hiring managers actually look at: the five signals

Each signal below appears in 60-second GitHub reviews because each one is hard to fake at scale. Together, they answer a single question: does this candidate have lived experience at the level they claim?

Signal 1: Repository half-life

A senior engineer maintains. A candidate spamming repositories does not. The hiring manager looks at the candidate's most-active repos and asks whether they show consistent commits over six months or more — or whether there are thirty to fifty fresh repos with single commits each. The latter is the "got Cursor'd" pattern, named in cohort discourse for engineers who generated dozens of starter projects in a week to look productive.

Long half-life signals deliberate practice and the ability to stay with hard problems. Short half-life signals decision paralysis or surface-level engagement, both of which read as red flags for the Mid-Level Squeeze cohort trying to pad output.

Signal 2: Issue and PR conversation quality

Long, opinionated PR descriptions. Pushback in code review where warranted. Engagement with maintainers of other repos, not just the candidate's own. Vague issues filed and abandoned ("doesn't work") cancel the signal.

What this proves is engineering judgment exercised in public — exactly what AI-generated portfolios cannot fabricate, because the conversations are timestamped and the counter-parties are real people who reply.

Signal 3: Test ratios and CI configuration

Proper test setups. CI passing on every PR. Deployment automation visible in the repository — Dockerfile, GitHub Actions workflows, infrastructure-as-code. Passing badges in the README. At least one test file per non-trivial source file.

AI-generated repos rarely include CI configuration because the model has no need to test what it produced; its job ends at authorship. The presence of CI is therefore one of the more reliable signals of human-authored depth, and one of the cheapest to verify in thirty seconds.

Signal 4: One non-trivial OSS contribution

One accepted, non-cosmetic PR to a known repository — bug fix in a framework, feature added to a library, documentation rewrite that argues a position. Typo fixes do not count. The contributions tab on the candidate's profile shows whether the PRs landed in repos owned by other people, which is the signal that matters.

OSS contribution proves the candidate can integrate with an existing codebase under foreign constraints — exactly the skill mid-level execution work requires. It is also structurally fake-resistant: maintainers verify identities and engage in conversation, both of which leave timestamped public artefacts.

Signal 5: Public technical writing or talks

A README that argues a position. A DESIGN.md with constraints and trade-offs named explicitly. A linked conference talk. A blog post on a personal site that the GitHub bio points at. One anchor artefact that demonstrates judgment beyond code — something that took some risk to publish.

The thing being measured is taste. It is the signal AI-generated content cannot reliably reproduce, because language models average their training data and what averages well is the absence of specific opinions. A specific opinion, defended, is evidence of a specific person.

What hiring managers ignore: the four anti-signals

These patterns get scrolled past in the 90-second review — or worse, used as evidence to auto-reject.

Anti-signal 1: 30-50 freshly-created repos with single commits

The "got Cursor'd" pattern. Dozens of starter projects, all created in the same week, none with substantial commit history. Reads as: the candidate generated these with an AI assistant in a sprint to "look productive." There is no lived practice here.

Anti-signal 2: Tutorial-following projects

Todo apps, blog clones, e-commerce demos that mirror tutorial structures. These are appropriate for juniors learning fundamentals. They are negative signals for a 7-YOE engineer because they suggest the candidate is performing rather than building.

Anti-signal 3: Stale "highlighted" repos with last commit 2+ years old

GitHub's "pinned repositories" feature lets candidates highlight their best work. When the highlighted repos haven't been touched since 2022, the implicit message is: my best work is two years stale, and I haven't shipped anything I'm proud of since.

Anti-signal 4: AI-generated README boilerplate

Long descriptions with formatting flourishes, emoji, badges, and zero specific opinions or trade-off discussions. The pattern is recognizable in 2026: ChatGPT-style README generation produces structurally similar artifacts. Hiring managers have learned to read past the polish and look for opinion or specific decisions. Their absence reads as Cursor output.

The senior-vs-junior signal divide

The same artefact reads differently at different career stages. This is the most-missed point in candidate-side advice and the source of most calibration errors.

A todo app from a junior is acceptable. It demonstrates the candidate can complete a small project end-to-end.

A todo app from a 7-YOE engineer is a negative signal. It suggests the candidate either has nothing better to show or is presenting weak work as portfolio-grade.

The asymmetry: junior portfolios are evaluated for can they code at all; senior portfolios are evaluated for do they have judgment, taste, and lived experience. Most "build a portfolio" advice on the internet is calibrated for the first question. Mid-level backend engineers who follow it produce portfolios that look junior — exactly the opposite of what the Mid-Level Squeeze cohort needs to break the rung-above gating problem.

Backend-specific signals (what differentiates within the senior backend pile)

Generalist senior signals matter; backend-specific signals further calibrate. Hiring managers reviewing a backend engineer's GitHub look for:

  • Database migration scripts visible in repo history — proves the candidate has shipped to a system with real data
  • Performance tuning commits with measurable claims — "reduced p99 latency from 800ms to 120ms" in a commit message beats abstract optimization claims
  • Deployment configuration — Dockerfile, docker-compose, Kubernetes manifests, infrastructure-as-code (Terraform / Pulumi)
  • Observability setup — logs, metrics, tracing in the codebase
  • Error handling beyond happy path — retries, timeouts, circuit breakers, graceful degradation
  • API design documents — OpenAPI specs visible, design rationale captured in markdown
  • Test pyramid — unit + integration + end-to-end, in proportions appropriate to the system

A senior backend candidate's GitHub does not need all of these. It needs some, with specificity. One repo demonstrating real database migration, real performance tuning with numbers, and real deployment config beats five repos demonstrating none of these.

What this connects to (the cohort context)

The GitHub portfolio is one of the few signals that survives the polished-profile paradox. With roughly three-quarters of resumes pre-rejected and AI-assisted application materials near half, the human-stage reviewer is increasingly using GitHub as the verification layer — comparing what the resume claims to what the GitHub actually shows.

For laid-off mid-level backend engineers in the Mid-Level Squeeze, this matters specifically because:

  1. The rung-above gate (senior IC roles) demands demonstrable scope. A senior-readable GitHub is one of the few ways to prove scope without referencing a current employer.
  2. The pipeline saturation (Stages 1-4 of AI resume screening) means the candidates who reach a human review have already been pre-filtered. The verification bar at Stage 5 is now higher.
  3. The cohort's natural response to layoff — building Cursor-generated demos to "prove I'm still a builder" — produces the exact anti-signals hiring managers ignore. The polished-profile paradox extends to portfolio building.

The recovery protocol below is calibrated for this cohort specifically: not "build more" but "build deeper."

How to bring a backend GitHub to senior-readable in 90 days

The five-step protocol (also captured in HowTo schema for AI search engines):

  1. Pick one repo to deepen, not five to start. Pick an existing repo with at least one real user (even if that's just yourself), 6+ months of commit history, and a problem worth solving. Do not start fresh. The most common failure mode is the candidate starting a new project to "show I can code in 2026," which produces another tutorial-shaped artefact.

  2. Add written context. A README that argues a position (not a description). A DESIGN.md short design doc with constraints and trade-offs explicitly named. A post-mortem if anything broke during the build. The written content is the taste signal.

  3. Add CI and tests if missing. GitHub Actions for lint and test on every PR. A test pyramid with unit and integration coverage. Passing badges in the README. CI presence is the strongest signal of lived production experience.

  4. Engage with one OSS repo non-cosmetically over 90 days. Pick a known backend OSS project (a Postgres extension, a framework like Spring or Django, an infrastructure tool like Pulumi). Submit a non-trivial PR — not typo fixes. Engage in technical discussion in the issue tracker. Aim for one accepted PR by Day 90. This is the single highest-value 90-day investment for the cohort.

  5. Make the activity heatmap reflect deliberate practice, not commit-spam. Thirty to fifty thoughtful commits over ninety days beats five hundred single-line commits to private forks. Hiring managers look at the green-square pattern as much as the count. They want to see consistent rhythm, not an unsustainable burst followed by silence.

What the short review leaves the candidate with

The candidate rejected at this stage does not learn it. GitHub review is not visible to the applicant the way a resume rejection is — there is no email, no auto-confirmation, no signal at all. The tab closes and the reviewer moves on.

The structural inversion that matters in 2026 is this: the resume can be polished above the floor and clear Stages 1–4, and then the polish stops mattering because GitHub becomes the verification layer. The five signals above are not aesthetic preferences. They are what a person under time pressure uses to decide whether the resume claims are likely to be real. None of them can be generated by Cursor at 2 a.m. None of them can be added to a profile after the reviewer opens the tab.

What is left is the slower, harder work — one deepened repository, one accepted OSS contribution, one written piece that argues a position, one set of green squares that looks like a person who actually shows up. That work does not produce callbacks in week one. By month three it produces a profile a reviewer opens and does not immediately close.

FAQ

Q1. Should I delete my old GitHub projects?

No. Deletion looks suspicious — gaps in account history are visible. Instead, unpin stale highlighted repos so they don't appear at the top of your profile. Leave them in your history but don't feature them. Pin only repos that show current, deliberate practice.

Q2. How many repos should a senior backend engineer have on GitHub?

Quality beats quantity. One deeply-built repo with 6+ months of history, CI, tests, design docs, and an OSS contribution beats 30 shallow repos. Hiring managers in 2026 explicitly look for the depth pattern as a counter-signal to AI-generated repository proliferation.

Q3. Do hiring managers actually look at GitHub for senior backend roles?

Yes — at the human-review stage (Stage 5 of the AI resume screening pipeline). Review time is short — recruiter self-reports cluster around a minute or two. The candidate who has cleared Stages 1-4 typically gets their GitHub reviewed; the candidate auto-rejected at Stage 1-4 does not. With roughly three-quarters of resumes pre-rejected in 2026, GitHub matters more for the candidates who do reach a human, not less.

Q4. What about private repos? Do they count?

Limited signal value. A candidate can mention private work in their resume, but the hiring manager cannot verify it. Some compensating signals exist (employer testimonials, talk recordings, internal documents made public after departure with permission), but private-only contributions reduce the verifiable surface that GitHub provides.

Q5. Should I publicly contribute to OSS while currently employed?

Yes if your employer permits — most modern engineering employers do, with reasonable boundaries. Specific guidance: review your employment agreement; pick OSS projects that don't compete with employer products; document time spent if employer has IP ambiguity. The career insurance value of consistent OSS work compounds across employers and survives job transitions.

Q6. What if my GitHub has been mostly inactive — is recovery possible in 90 days?

Yes — within limits. The 90-day protocol above produces a senior-readable GitHub if executed consistently. What it does not produce: 5+ years of accumulated reputation. Engineers with stale GitHub profiles applying to senior backend roles should expect 90 days of focused work to clear the polish floor (anti-signal removal + signal addition). Compounding reputation effects come from years of public practice, not 90 days.

Q7. How does this differ from junior-level GitHub advice?

Junior portfolios are evaluated for "can this person code at all" — completion of small projects end-to-end is acceptable. Senior portfolios are evaluated for "does this person have judgment, taste, and lived experience" — small-project completion is a negative signal, not a positive one. Most online advice about "building a portfolio" is calibrated for the first question. Mid-level backend engineers who follow that advice produce portfolios that read junior. The signal-vs-anti-signal split above is calibrated specifically for the senior-backend-after-layoff cohort.

Q8. Is the GitHub signal trend going up or down in 2026?

Up. With AI-assisted applicant materials near half by DISHER Talent's 2026 estimate, the resume signal-to-noise ratio has collapsed. Hiring managers compensate by relying more on signals that AI cannot fake at scale — public, verifiable, time-stamped artefacts. GitHub is the largest of those for backend engineers. Expect the trend to intensify through 2027.

Methodology

This piece is observational synthesis, not a study. The signal-list and anti-signal-list collect what recurs across Hacker News threads where senior backend hiring managers and engineering leaders describe what they look at on candidate GitHubs — load-bearing items include 47478029 (March 2026, broken hiring), 47420767 (vibe-coding interview discourse), and 46935171 (the original Mid-Level Squeeze thread). Adjacent to those threads sits the cohort vocabulary that grew up around the patterns — "got Cursor'd," the Cursor-README tell, the green-square-spam pattern. I did not count and did not score. I would not call it a study.

The review-time number ("about a minute or two") is the band recruiter self-reports cluster in. I have not seen verified telemetry on it and would not trust a precise figure if I had one. The ninety-day recovery protocol was built inversely from the signal list: what depth of practice would produce each artefact within ninety days of focused work?

Out of scope: junior portfolios (a different review heuristic, treated in passing only); FAANG hiring (different volume and process); non-English-language tech markets (coverage is too thin to claim a pattern).

Evidence

The pieces of evidence the argument actually rests on:

  • Hacker News reading, Q4 2025 – Q2 2026. Anchor items 47478029, 47420767, 46935171. The piece collects the signal/anti-signal patterns named across those discussions and their replies.
  • Harvard Business School "Managing the Future of Work" (cited via The Interview Guys, 2026) — roughly three-quarters of resumes eliminated before a human sees them; 88% of employers acknowledge their filters reject qualified candidates.
  • DISHER Talent (2026) — applicant AI-assistance rate near half; reported as a wide band in their own write-up.
  • BLS (2025) — 5.8% unemployment among recent CS graduates against a 3.6% national baseline.
  • Recruiter self-reports for the "about a minute or two" review-time figure. Not telemetry; named inline as estimate.

Sources

Valerii Hurachek writes about hiring systems and the cohort caught inside them. He builds Aria, an interview-prep tool focused on memory and continuity across sessions.

Get the senior-readable GitHub 90-day recovery checklist

Per-week checkpoint plan to bring a senior backend engineer's GitHub from \"looks like Cursor output\" to senior-readable in 90 days.

One email. No spam. Unsubscribe with one click in any email.