Employers do look at GitHub. Not all of them, and not as a ritual. When they do, they do not study the contribution graph. They open a handful of links and decide whether you can work in someone else’s code.

This page is that click path: merged pull requests, review comments, issue threads. It is not how to format a resume PDF. That is open source on your resume. It is not how to pin repos or write a profile README. That is how to build a developer portfolio through open source. A count-as-plan is five merged PRs. This URL will not write those.

If nobody on the panel opens GitHub, none of this matters for that loop. If someone does, the green squares are the least useful thing on the page.

They start at your profile, then they leave

The profile is a directory, not the evidence. A hiring manager who cares will scan the name, maybe the bio, then jump to activity that landed. They are looking for:

A merged pull request from the last year or two
A conversation under that PR: review comments you answered, CI you fixed, a scope you did not explode
The issue that asked for the change
Whether you still show up after merge (a second issue, a follow-up comment) or you vanished

They are not looking for:

How many days you committed to private gists
A perfect calendar
Star counts on a tutorial clone
Fifty open PRs with no merges
A wall of fix typo across unrelated READMEs

“Looks active” is not a hiring signal. “This person shipped a specified change and survived review” is.

The merged PR is the artifact

Open the Files tab. A manager who can read the stack will look at:

Size relative to the issue. A three-file fix for a named bug is readable. A 40-file “cleanup” attached to a one-line ticket is a red flag.
Tests if the project has them. Adding or updating a test for the path you touched is stronger than a comment that says “tested locally.”
Whether the diff matches the title. If the PR says “fix date parsing in CSV export” and half the files are unrelated formatter noise, they will assume you cannot keep a branch small.

Then they open the Conversation tab. That is the interview they can run without you on the call.

Useful signals:

You asked a clarifying question on the issue before dumping code
A reviewer asked for a change and you made it, or you explained why not
CI failed and you pushed a fix instead of arguing with the bot
You did not ping maintainers daily

Bad signals:

The PR is a dump with “please merge” and no context
Review asked for a test and you closed the thread
You force-pushed over the discussion so the history is unreadable
You argued about style while ignoring the actual bug

You do not need a famous repo. You need a thread a stranger can follow in five minutes.

Issue threads beat commit lists

Commits without an issue are hard to judge. The issue is the spec.

A hiring manager who opens the linked issue wants to see:

The problem was real (repro, missing docs, a labeled task)
You did not invent a feature the project never asked for
Maintainers were still talking (or at least merging) around that time

A closed issue with a merged PR is a complete story. An issue you opened that got “we don’t want this” and a PR you still pushed is a story too — usually not the one you want.

If you only have commits on a personal repo with no review, that is a project, not an open-source loop. Personal work can be strong. It is not the same as surviving someone else’s review. Do not pretend it is.

What they skip (and why you should stop optimizing it)

The green calendar. Private work, bot commits, and timezone tricks all paint squares. None of that is a review thread.

Follower counts and stars. Easy to inflate. Irrelevant to “can this person land a change.”

Language bars. Generated from bytes in the default branch of repos GitHub happens to index. A forked tutorial in C++ will dominate a year of Python PRs on other people’s repos.

Organization badges. Being in an org is not the same as a merge you can walk through.

Open PR counts. An open PR that has sat for six months is unfinished work, not ambition.

If you have been farming contribution-graph screenshots, stop. Put the time into one specified issue that can merge.

How they use it on a call

If GitHub comes up in an interview, they will paste a PR URL or ask you to open one. They want narration:

What the issue asked for
What you changed and what you left alone
What review asked
What you would do differently

If you cannot do that without reading the diff live, do not list the work. Memory of the thread is the signal. “I contributed to many projects” is not a walkthrough.

They may also open a PR you are not proud of. That is why spray-and-pray nits are expensive: the worst merge is still public. One or two repos with a few honest PRs is easier to defend than twenty typos.

What “looks at GitHub” does not mean

It does not mean every recruiter clones your history. Many never leave the ATS. Some only check that the username on the application loads.

It does not mean they run your code. They read diffs and comments.

It does not mean they need a company-shaped org. Individual merges on a maintained library, a CLI, a docs site, or an app they use are all readable.

It does not mean they will ignore a thin GitHub if the rest of the loop is strong. It means that if they do look, the calendar is not the page that helps you.

Make the click path boring and complete

Before you worry about polish:

Your recent work is merged, not draft-forever.
The PR description names the issue and the change. See how to write a pull request description.
Review comments have replies that are actual commits, not “will do.”
You can open the same URLs they will open.

If you have no merge yet, this page is not a profile-tuning guide. Get one specified issue through review. Start from open source issues, or stay in one language: Python, TypeScript, JavaScript. How to contribute is the workflow. How to pick an issue that will get merged is the filter.

FAQ

Do FAANG / every startup look? Some people on some panels do. Optimize for a readable merge, not for a myth that “they always check GitHub.”

Should I make everything public? Only work you are allowed to publish. Do not leak employer code. A few public PRs beat a dump of private history you cannot discuss.

What if most of my work is private? Then GitHub is a thin extra. One public merge you can walk through is still useful. Do not fake a green year.

Typo PRs? They merge. They do not survive a Files-tab look. Skip them if the goal is a hiring click.

Does inactivity kill me? A gap is normal. A two-year-old merge you can still explain is better than a week of empty commits.

The job of this page: when someone opens GitHub, they land on a merged PR and a review thread — not a calendar.