I Studied How GitHub READMEs Are Actually Evaluated — Here Are the 5 Things That Matter

I spent weeks reading hiring threads, portfolio guides, recruiter-facing articles, Reddit discussions, and academic papers to answer one question: what do people actually look at when they evaluate a GitHub profile? I expected to find a clear standard. I didn't. What I found was more useful: most README "best practices" aren't rules — they're signals . And there's a formal framework for understanding why some signals matter and others don't. I wrote up the full deep-dive with all sources and references. Here's the short version of what I verified. 1. Your README Is a Screening Surface, Not Documentation People don't start with a deep code review. The first pass is shallow — they're scanning for signs of seriousness. Eye-tracking research shows recruiters spend about 7 seconds on an initial screen. Your README's first job isn't to explain everything. It's to justify continued attention . 2. Tests and CI Are Signals, Not Checkboxes Tests, CI, .env.example , meaningful commits — these det