How do you read a GitHub profile?

How do you read a GitHub profile?

Reading a GitHub profile means scanning it in a fixed order: pinned repositories first, then a check on whether each pin is original work, then the README of the strongest one, then recent activity. The whole pass takes about ninety seconds.

The order works because of one fact about the page. A GitHub profile mixes two kinds of information. Some of it the developer curated: the pinned projects, the written introduction, the tags on each repository. The rest is generated automatically from their activity, in date order, with no editing. The curated parts tell you what the developer thinks matters. The automatic parts let you check that story against evidence. Reading curated first, then automatic, turns a wall of unfamiliar links into two short questions: what do they say about themselves, and does the record agree.

This lesson gives you the pass itself. The pieces after it in this module go deeper on judging what the pass surfaces.

Why does the order matter?

Without an order, a profile invites scrolling, and scrolling on GitHub rewards the wrong things. The default repository list is sorted by recent activity, so the top of it is whatever the developer touched last week: a config file, a homework fork, a half-started experiment. Judged from that list, an excellent developer can look scattered, because the list was never meant to represent them.

The fixed order fixes this by starting where the developer exercised judgment. A hundred cooks and a public square covered what the pieces of GitHub literally are. This pass adds the reading direction: self-presentation first, evidence second. It also caps the time. Ninety seconds is enough to decide whether a profile deserves ten more minutes, and most of the profiles in a long sourcing list will resolve in the first thirty.

What do the pinned repositories tell you?

Pinned repositories are up to six projects a developer selects to display at the top of their profile. Everything else on the page is ordered by date. The pins are the only place the developer answers, in their own choice of projects, the question of which work represents them.

That makes the selection itself a signal, before you open a single pin. A developer who pins one substantial project and five small ones is telling you where their weight is. A developer who pins six projects on one theme is telling you what they consider their specialty. A developer with no pins has let the date-ordered default stand, which is common and carries little meaning either way. The empty GitHub covers how to proceed when there is nothing curated at all.

The one mechanical check to run on each pin is whether it is original or a fork. A fork is a copy of someone else's repository, and it arrives carrying the original project's description, stars, and README. Developers fork for good reasons, usually to contribute back, but a forked pin represents someone else's work unless the developer changed it. The word "forked from" appears right under the repository name, so the check takes two seconds per pin.

What is a profile README?

A profile README is a written introduction that appears at the very top of some profiles, above the pins. GitHub renders it when a developer creates a repository named after their own username and puts a README file in it, which is why the feature carries the README name even though it reads like a bio.

When one exists, it is the highest-value ninety seconds on the page, because it is the developer describing themselves in prose: what they build, what they maintain, what they are interested in now, sometimes how they prefer to be contacted. It is the closest thing GitHub has to a summary section, written for exactly the reader you are.

Most developers have no profile README, and the absence means only that they skipped an optional feature. When it is missing, the pins carry the self-presentation on their own and the pass continues unchanged.

What does the README of a project show?

After the pins, open the strongest one and read its README. Every serious repository has one, and it is the author explaining the project to a stranger: what problem it solves, who it is for, how to use it.

For this pass you are reading it for orientation and for care. Orientation, because the README tells you in plain language what the project actually is, which the repository name rarely does. Care, because a README written for strangers, with a clear problem statement and working instructions, shows a developer who finishes things and communicates about them. Written communication is a large share of senior engineering work, and the README is a public sample of it that the developer produced with no interviewer watching.

A polished README sits on top of substance or on top of very little, and telling those apart is its own skill. Real work or wallpaper is the next lesson and covers exactly that judgment.

What does recent activity add?

Recent activity answers the question the pins cannot: what is this person doing now. The contribution graph and the activity feed below it are generated automatically, so they are the un-curated half of the page, and they update whether or not the developer ever touches their pins.

The useful move is to compare the two halves. Pins from four years ago plus a graph full of current commits describe a developer who is building steadily and has stopped updating their shop window, which is most working developers. Pins from four years ago plus years of quiet public activity describe a profile that has gone dormant as a public artifact, and the last section of this lesson covers why that is a fact about the artifact rather than the person.

What is a topic on a repository?

A topic is a tag the author adds to a repository to describe what it is about. Topics appear as small labels under the repository description, and a project might carry tags for its language, its framework, and its problem area.

Topics matter to this pass for one reason: they are the author's own categorization, in the author's own vocabulary. When a developer tags a project with the same technology names sitting on the resume in front of you, the profile and the resume are corroborating each other in the developer's own words. Topics are also searchable across all of GitHub, which makes them useful beyond any single profile, and the author chose each one deliberately, since none are applied automatically.

What is not on this page at all?

Almost all of the developer's professional work. Code written for an employer lives in private repositories, and nothing private appears anywhere in this pass: no pins, no READMEs, no feed entries, and, under the default settings, no marks on the contribution graph. A staff engineer carrying a critical system at a large company can present a nearly blank public profile while doing the best work of their career.

The gift economy explained why the public work that does exist is there: reputation, portfolio, leverage, craft. Every one of those motives takes spare time and a reason, so a full public profile tells you the developer had both, and a sparse one tells you only that they spent their hours elsewhere. Treat the ninety-second read as a way to harvest evidence when evidence is present. When the pass comes up thin, the profile has answered a question about the artifact, the resume and the conversation still hold everything they held before, and the lesson on the empty GitHub picks up from exactly this point.