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 detail