Quick Answer: To show coding activity to recruiters, give them one link to a curated, verifiable record of your work: two or three pinned repositories whose commit history tells a story, visible recent activity, and, ideally, an audited activity profile that proves the work happened the way you say it did. Do not lead with your contribution graph. Recruiters have learned that green squares are easy to game, so raw activity reads as noise. Verifiable activity reads as signal. Below: what recruiters actually do with your activity, which artifacts prove anything, and the steps to make your work legible in under a minute.
What recruiters actually do with your coding activity
If you have ever polished your GitHub profile before an application and heard nothing back, the reason is simple. Most recruiters spend under a minute on a profile, and they are not reading your code. They scan for three things: recency (are you active now), consistency (is this a habit or a sprint before job hunting), and substance (do the repos look like real projects or tutorial clones).
Recruiters know activity can be manufactured. Fake-commit scripts are a genre. AI agents can generate a year of plausible-looking history in an afternoon. You will often see hiring guides now telling recruiters to treat the contribution graph as decoration, and some to spot gamed activity outright. This is why simply having activity no longer separates you. The question a recruiter is quietly asking has changed from "is this person active" to "can I trust what I am looking at."
That reframes the whole exercise. You are not trying to display activity. You are trying to make your activity believable at a glance.
What each artifact claims, and what it proves
Most developers hit this when choosing where to invest effort: profile README, portfolio site, more commits, a blog. Each artifact sits somewhere on a spectrum from claim to proof, and recruiters weight them accordingly.
| Artifact | What it claims | What it proves | How recruiters read it |
|---|---|---|---|
| Contribution graph | "I code often" | Almost nothing (gameable in minutes) | Skimmed, discounted |
| Pinned repos | "This is my best work" | Code exists; authorship unclear | The main event, 30 to 60 seconds |
| Portfolio site | "I can present myself" | Presentation skill, not process | Nice-to-have, rarely decisive |
| Resume bullets | "I did X at Y" | Nothing without references | Assumed inflated |
| Blog / build-in-public posts | "I understand what I built" | Thinking, over time | Strong but rarely read pre-interview |
| Audited activity profile | "Here is the work, verified" | Sessions, commits, and time tied to source | Rare enough to stand out |
The artifacts developers spend the most time on (graph, portfolio homepage) are the ones recruiters trust least, because they are the easiest to fake. This is what actually separates candidates in 2026: not volume of activity, but how close their evidence sits to the proof end of the spectrum.
How to show coding activity to recruiters: five moves
You do not need all of these. In practice, the first three take an afternoon and cover most of the distance. The point of each move is the same: reduce the recruiter's cost of believing you.
- Curate down to two or three repos whose history tells a story. Pin them. Archive or hide the tutorial clones and the 40 abandoned experiments. A repo with six months of readable commits ("fix webhook retry race", "swap auth provider after Stripe change") says more than ten repos with "initial commit" and "update". Your git history is already a portfolio if you let it be seen.
- Make recency impossible to miss. A recruiter deciding between two similar profiles almost always picks the one that shipped something this month. If your best work is old, add a current project, even a small one, and mention the active one in your README's first line.
- Surface process, not just output. Merged PRs, issues you closed, design notes in the repo. In the AI era this matters more, not less: anyone can present finished code, so the trail of decisions is where authorship lives. If most of your work is AI-assisted (for most of us it now is), the interesting evidence is what you directed and reviewed, not the diff size. Commit volume stopped mapping to effort a while ago; big diffs no longer mean big work.
- Put one link everywhere. Resume, LinkedIn, email signature: one URL to the profile you want scanned. Recruiters follow one link, rarely two. Deciding what that link should be matters more than perfecting three destinations.
- Add a verifiable layer if you want to stand out. Shareable coding stats have existed for years (WakaTime dashboards are the familiar example, though they only see editors with the plugin installed; here is how DevClocked compares to WakaTime). The stronger version is a record tied to source: real sessions, real commits, real time, presented so a stranger can check it.
Some will object that recruiters do not care about any of this and only look at your last employer. Sometimes true, especially at the senior end. But activity evidence is disproportionately powerful exactly where the resume is weakest: self-taught developers, career changers, juniors, and anyone whose best work happened outside a brand-name company.
The AI wrinkle: activity needs an audit trail now
AI tools make a profile look worse by default, better only if you can prove your role. When Claude, Cursor, or Codex writes a large share of the code, two claims soften at once: how long the work really took, and how much you drove. A green graph cannot answer either. Neither can the finished repo.
An audit trail can. A record showing your sessions, which parts were agent-generated, what you reviewed and reworked, and when, turns "AI did it" from a suspicion into a documented workflow. In practice, recruiters are not hostile to AI-assisted work; they are hostile to not being able to tell. Candidates who can show their leverage (what they shipped per unit of directed effort) are ahead of candidates hiding the tools they used.
Where DevClocked fits
Full disclosure: I build DevClocked. If you already have a strong open-source presence, merged PRs in recognisable projects, and public repos under your name, you do not need another tool; that is proof, and a clean GitHub profile plus a good README is the better call. The same goes if you are applying through referrals where your reputation precedes you.
DevClocked earns its place when your work is private, scattered across clients, or heavily AI-assisted, which is most working developers. It builds a profile from what you actually shipped: Work Blocks from real telemetry and git, AI-agent sessions tracked first-class (Claude Code, Cursor, Codex), and a Leverage Score that shows output rather than hours performed. The result is a single link where the activity is audited to source instead of self-reported, which is precisely the property a skeptical recruiter is scanning for. You can create a profile at devclocked.com and decide what stays private.
Common mistakes that quietly hurt you
A few patterns show up repeatedly and each one lowers trust rather than raising it. Gaming the graph with scripted commits: recruiters check commit content more than developers think, and one glance at a repo full of whitespace changes ends the conversation. Dumping every repo public: thirty unfinished projects bury your two good ones. Making everything private and describing it in prose: a claim without evidence in a market that has stopped pricing claims. Screenshotting your stats into a portfolio: a static image of a dashboard proves the dashboard existed once, nothing more.
