LinkedIn, GitHub and a personal site

Your resume is not the only thing a recruiter or hiring manager sees. They search LinkedIn, they click the GitHub link in your contact block, and some of them open your personal site. Each of these either supports the resume or quietly undermines it.

This lesson covers the three places people find you. The rule that connects them is simple: the facts must match everywhere, and anything you link must be worth the click, because the reader will go and look.

LinkedIn alignment

Your LinkedIn profile is not a copy of your resume, and it is not an unrelated document either. It is the same facts written for a different reading mode.

The three differences

That last row is the important one. A resume is targeted; a profile is a net. This is why breadth belongs here and not on your resume (see Keywords, honestly).

What must match exactly

Recruiters compare the two, and discrepancies are a genuine red flag:

• Job titles
• Company names
• Start and end dates, at least to the month
• Education

A title that reads "Senior Engineer" on your resume and "Engineer" on LinkedIn will be noticed and will be interpreted as inflation. If your official title differs from the functional one, use the same treatment in both places: Senior Engineer (officially "Engineer III").

What should differ

The headline. Not your job title — a searchable positioning line:

Software Engineer at Kestrel Systems

Backend engineer · Go, distributed systems, event-driven architecture · Bengaluru

The About section. Three or four short paragraphs, first person. What you work on, what you are good at, what you are looking for. This is where the personality your resume cannot afford belongs.

Breadth in skills. List the long tail here. Nobody is screened out for a broad LinkedIn skills list, and each entry is a search you might match.

Longer role descriptions. You have space for the context a resume bullet has to cut.

GitHub as evidence

LinkedIn is where people find you. GitHub is where they check you. If you link your GitHub, a reader will open it. Sixty seconds later they will have formed an opinion. Know what they are looking at.

What a reader checks in sixty seconds

1. Pinned repositories. The first thing on the page. If they are unpinned, the reader sees whatever you touched most recently — possibly a fork you made once.
2. The top repository's README. Do they understand what it does within ten seconds?
3. The commit history. Are there real commits over time, or one giant "initial commit" containing everything?
4. The code itself, briefly. Is it structured? Are there tests?

The cleanup, in priority order

1. Pin four to six repositories. This is the highest-value five minutes available. Pin your best work; everything else recedes.

2. Write a real README for each pinned repository. Most important item on the list. Structure:

# PantrySuggests recipes from ingredients you already have. ~2,400 monthly users.## Why it existsExisting recipe apps search by dish. This searches by what is in your kitchen.## How it worksPostgres trigram similarity for ingredient matching (full-text searchhandled misspellings poorly). React frontend, Node API, deployed on Fly.io.## Running it locally...

Four sections. What it is, why it exists, how it works, how to run it. A reader who understands your project in ten seconds thinks better of you than one who has to read your source to find out.

3. Make the commit history legible. You cannot rewrite the past, but future work should show incremental commits with meaningful messages.

4. Archive or make private the abandoned experiments. A profile of twelve half-finished repositories reads worse than one with four finished ones.

When not to link it

If your GitHub is empty, or contains only forks and course exercises, do not link it. An empty profile is a worse signal than no link at all, because the reader went and looked.

Portfolio and personal site

The third link is the one most engineers agonise over. A personal site is worth building for some roles, and a waste of time for others. Know which you are.

Who benefits

For most backend and infrastructure engineers, the honest answer is that a personal site will not change any hiring outcome. Spend the time on your resume bullets instead.

The minimum viable version

If you do build one, it needs four things and nothing else:

1. Who you are and what you do, in one or two sentences, above the fold.
2. Three or four projects, each with the same structure as a resume project entry: the problem, the decision you made, the result, and a link.
3. Contact details.
4. A resume link.

One page. No animated splash screen, no scroll-jacking, no "loading experience".

If you write

A small number of genuinely good technical posts is one of the most differentiating things available — particularly at senior level, where communication is part of the job.

Two or three real posts about problems you solved beat twenty short ones. Write the debugging story: what broke, what you thought it was, what it actually was, how you found out.