Two Audiences, Two GitHubs: What Recruiters vs Engineers Actually Look For

## Who clicks your GitHub and what they want Direct answer: Recruiters want visual trust signals (photo, pins, green graph); engineers want readable architecture, clean READMEs and demos. You must design for both or pick which you serve. ## The Non-Technical Recruiter (10-second scan) Recruiters do not read code. They look for signals of completeness and seriousness during a quick screen. Useful trust signals: a professional profile photo, exactly six pinned repositories to fill GitHub’s grid, a succinct profile README, visible stars or forks as social proof, and a healthy contribution graph (even if engineers know it can be gamed). These things make a recruiter more likely to click into a project and forward your CV to a technical lead. Treat them like the cover of a book — not the content. ## The Lead Engineer (30-second smell test) Engineers skim for substance. They want: - A clear, well-structured README explaining architecture, decisions and how to run the app - Sensible folder structure with obvious entry points (src/, docs/, tests/) - Professional commit messages and a tidy commit history - A hosted demo or reproducible local run instructions (no “works on my machine” excuses) They will not run npm install and poke for hours; they’ll do a smell test. Make that test pass. ## Bridging the gap You can serve both audiences with small trade-offs: keep your profile tidy and visually complete for recruiters, but ensure each pinned repo has a README with architecture notes and a demo link for engineers. If you must choose, favour the engineer signals for mid/senior technical roles — bad engineering signals outweigh good visual signals. *For more on writing technical project entries, explore our [Writing & Content](/writing-and-content) insights.*