How do you read a developer's profile and resume?

How do you read a developer's profile and resume?

You read them as a pair: the resume makes claims, and the public profile lets you check some of them. A GitHub profile is self-curated. The developer decided what to publish, what to feature, and what to leave private, so the first question on any profile is what this person chose to show and why. That framing comes from the way developers work in public: code on GitHub is written to be seen, and the display choices are part of the message.

This module is where the path turns to the two documents that arrive with every candidate. The earlier stations built the vocabulary for it: what the technology names mean, what developers care about, and who holds which title. This station spends that vocabulary. Seven lessons cover the ground: a fixed scan order for the profile, calibration for stars and green squares, what an empty profile means, a ninety-second check on open source claims, the fifteen-technology skills wall, the verbs that carry a resume, and the shape of the career timeline itself. The sections below walk the same ground in miniature. Each lesson goes deep on its piece.

The two artifacts differ in one property that shapes everything below: verifiability. A resume line is a claim written by the candidate with no attached evidence, the same as in every field you have hired for. A profile entry is different in kind. Every item on GitHub carries an author and a timestamp, every accepted change to a shared project passed review by someone else, and none of it can be backdated. So the working method for this whole module is a loop: take a claim from the resume, find its trace in the public record, and weigh the claim by what the trace shows. Where no trace exists, and often none does, the claim gets weighed the way you have always weighed claims, by history and by conversation.

Where do your eyes go first on a profile?

To the pinned repositories. A pinned repository is one of up to six projects a developer selects to sit at the top of their profile. Pinning is a deliberate act, which makes the pinned row the developer's own answer to the question you came to answer: out of everything here, this is what I want you to see.

Three checks follow, in order. First, origin: is each pinned project original work or a fork, a copy of someone else's repository? A fork with no changes on top of it displays another person's work under this person's name. Second, the README of the strongest one. A README written for a stranger, explaining what the project does and how to run it, shows the same communication habit that makes a developer good on a team. Third, recency: the recent activity feed shows what they build now, which can differ sharply from what they pinned three years ago. The 90-second read turns these checks into a full routine, including the topics, the labels a developer attaches to a repository, that tell you what territory each project sits in.

The order matters because it replaces scrolling. A profile with forty repositories rewards a fixed path and punishes browsing, and the pinned row is the one place the developer already did the sorting for you.

What are stars and green squares worth?

A star is a bookmark another GitHub user placed on a repository, so a star count measures audience. It tracks visibility, promotion, timing, and luck, the same forces that drive follower counts anywhere. The gift economy lesson covered why developers publish work for free; stars are the applause side of that economy, and applause concentrates. A few projects collect thousands while the median repository written by an excellent engineer sits near zero. High stars are real evidence of reach. Their absence is evidence of nothing.

The green squares are the contribution graph: a calendar grid on every profile where each day a developer saved changes gets a colored square, and busier days get darker ones. The graph counts commits and similar events without weighing them, so a one-line configuration tweak and a week of hard design work can produce the same square. A developer whose job runs through GitHub fills the wall as a side effect of employment. A developer whose employer hosts code elsewhere can do superb work above an empty graph.

What does an empty profile take out of the read?

Less than it appears to. Employers own the code written for them, and most professional work lives in private repositories or on internal systems that never touch GitHub. A developer who spent eight years in defense, banking, or health care can be forbidden to publish a single line. What an empty profile removes is one channel of evidence. The work history, the resume, and the conversation still carry the read, the way they do for every other profession you have hired for.

Two more ordinary explanations fill out the base rates. Plenty of strong developers treat GitHub as a work tool rather than a portfolio, the way many strong salespeople keep a bare LinkedIn. And some keep their experiments in private repositories out of perfectionism: the same instinct that makes them good at the job makes them reluctant to publish anything unfinished. An empty profile is common enough at every seniority level that it cannot sort candidates on its own.

What a full profile adds, when it exists, is the side project: something built with no manager, no deadline, and no paycheck attached. That is the clearest available evidence of genuine interest in the craft, which is why what developers care about treats voluntary work as a distinct signal. The empty GitHub works through the honest middle ground: public work is strong positive evidence, and its absence is a reduction in evidence rather than a mark against the person.

How do you check an open source claim?

By finding the merged pull request. "Contributor to a major open source project" is a true sentence across an enormous range: it covers a one-word typo fix and it covers years as a core maintainer, the person who reviews other people's changes and decides what gets in. The claim itself does not tell you where on that range the candidate sits. The public record does.

Every accepted contribution exists as a merged pull request with an author, a date, a size, and a review thread where a maintainer of that project examined the work before accepting it. That last part is the reason the check is worth ninety seconds: a merged pull request is a piece of work that a qualified stranger, with no stake in this candidate's job search, already judged good enough to ship. It is the closest thing hiring has to a pre-verified reference. Verifying open source claims shows the exact steps, including how to pull up everything one person contributed to a given project in a single search.

How do you read a skills list?

As a set of shelves rather than a list of fifteen equals. The shelves sorted technology names into kinds: languages, frameworks, databases, and the tools around them. A skills wall becomes readable the moment you sort it that way, because a working developer holds one or two real choices per shelf. Fifteen names usually resolve into one coherent stack plus a cloud of things touched once.

Coherence is the signal. A list whose names sit together in practice describes a person who built things with them, since technologies cluster into stacks that teams adopt as a unit. A list that sprays one name from every shelf with no pattern describes a keyword strategy aimed at screening software. Neither reading is a verdict on the person; the second one tells you the list will not carry the evaluation and the profile and history will. The skills wall walks the sorting in detail, and what transfers covers the follow-on fact that makes walls less alarming: skills within a shelf move between names quickly, so depth in one framework prices in a short ramp to its neighbors.

Which resume verbs carry weight?

The verbs that describe accountability. Shipped means the work reached real users, the full journey covered in from laptop to customer. "Owned" means the person was the one answerable for the system, in success and in failure. "Migrated" means they moved a live system from one foundation to another without breaking it, which is among the hardest work in software because software is never done and the system had to keep serving users mid-move. On-call means they were the person paged when it broke. Each of these verbs commits the writer to a claim that a reference or a conversation can confirm or collapse.

The verbs of exposure sit at the other end. Used, worked with, familiar with, and exposed to are all true of someone who watched a teammate operate the thing. They cost the writer nothing, which is exactly why they carry so little. Shipped, owned, migrated grades the full vocabulary, including the numbers that decorate resumes without a denominator to give them meaning.

One artifact remains after the words: the timeline itself. Tenure lengths, the gap between title changes, and the hours side projects get written in are all evidence, and why they leave and why they hop already established that developer tenure runs shorter than in most fields you have hired for. Career shapes closes the module by reading the timeline the way the other lessons read the profile: as a record of choices, each one made for a reason you can usually recover.