Preparing Your GitHub and Portfolio for Engineering Interviews

Reviewers will look, so decide what they find

When you apply for engineering roles, a fair number of reviewers will open your GitHub profile and any portfolio link you provide. Some will skim for thirty seconds between meetings. A few, especially at smaller companies and for senior roles, will read code closely and form a strong opinion before you ever speak. Either way you do not get to narrate it in the moment, so the profile speaks for you while you are asleep, in another interview, or unaware the link was even clicked.

The aim is simple. Make sure what they find shows judgement and care, not a graveyard of half-finished tutorials. This is not about faking a glittering profile. It is about curating what already exists so your real strengths are easy to see and the weak signals are out of the way.

Be honest about how much weight this carries. A clean GitHub rarely wins you an offer on its own, but a messy one quietly loses you screens you never hear about. The asymmetry is the point: the downside of a neglected profile is large and invisible, the upside of a tidy one is modest but real, and the work to fix it is a single focused afternoon.

A reviewer is not grading your repositories like a professor. They are answering one question: would I want this person on my team next month? Everything below is in service of making that answer obvious.

How reviewers actually read a profile

Before changing anything, it helps to understand the order of attention. Most reviewers move through a predictable funnel, and each stage filters out candidates who fail it.

Most candidates obsess over the read stage and ignore the glance. That is backwards. Far more reviewers bounce at the glance than ever reach your source, so optimise from the top down: the pinned repositories and their READMEs earn you the read, and only then does code quality matter.

Curate the profile, do not hoard

A profile with forty repositories, most of them forked tutorials and abandoned experiments, sends a worse signal than a profile with four solid projects. Reviewers do not assume your best repo represents you. They often assume the median one does. So raise the median by removing the bottom half from view.

Practical steps, in priority order:

• Pin your three to six strongest repositories so they sit at the top of your profile.
• Archive the dead experiments, course-along clones, and throwaway scripts. Archiving keeps the history without inviting scrutiny, and it adds a clear banner saying the work is no longer maintained.
• Make genuinely embarrassing repos private rather than deleting them. You may want the code later, and private repos still count towards your own records.
• Remove or privatise forks you never meaningfully changed, since they clutter the view and dilute the signal.
• Make sure your pinned work actually runs and reflects how you write code now, not how you wrote it three years ago.

Pinned repositories are the single highest-leverage control you have, because most reviewers look there first and rarely scroll past. Treat them as your shop window. If you only do one thing from this guide, fix the pins.

On archive versus delete: archiving is almost always the right call. Deleting breaks inbound links and removes your own reference copy. An archived repo is invisible to a casual reviewer and recoverable to you, which is exactly the balance you want.

What good looks like next to what weak looks like

Abstract advice is easy to nod at and hard to act on, so here is the standard as a direct contrast.

You do not need every row in the strong column for every repo. You need your pinned ones to land mostly on the right, and you need none of them to be obviously in the left.

Make every showcased project readable in a minute

A reviewer should understand what a project does, why it exists, and how to run it within a minute of opening it. The README carries that weight. A good one includes:

• A one-line description of what the project is and who it is for.
• A short section on the problem it solves or why you built it.
• Clear setup and run instructions that actually work from a clean clone, with versions pinned where they matter.
• A note on the stack and one or two interesting technical decisions, including the ones you would do differently now.
• A screenshot or short demo link if it has a user interface.

The "why" matters more than people expect. A project that says "I built this to learn how rate limiting works, then load-tested three strategies and measured the tail latency of each" tells a reviewer about your curiosity and rigour. A bare repo with no README tells them nothing, so they move on.

Here is a compact README skeleton you can adapt for any showcased repo. It reads in under a minute and answers the four questions a reviewer is asking.

# Ratekeeper

A small HTTP rate limiter you can drop in front of a Node service.
Built to compare token-bucket, sliding-window, and fixed-window strategies
under realistic burst traffic.

## Why this exists
I kept reaching for rate limiting without really understanding the
trade-offs, so I implemented three strategies and load-tested each one.
Findings and graphs are in /benchmarks.

## Run it
    git clone https://github.com/you/ratekeeper
    cd ratekeeper && npm install
    npm start        # serves on :3000
    npm test         # unit tests for each strategy

## Stack and decisions
- Node + Fastify, no framework magic so the limiter logic stays visible.
- Storage is pluggable; in-memory by default, Redis adapter included.
- Sliding window won on fairness; token bucket won on throughput.
  Trade-off write-up in /benchmarks/README.md.

## What I would change
The Redis adapter does one round trip per request. Batching with a Lua
script would cut that. Noted, not done.

That states the problem, proves the work with a benchmarks folder, runs in three commands, and ends with an honest limitation. The "what I would change" section is disproportionately effective because it signals the self-awareness interviewers probe for in person.

Let your code show judgement

If a reviewer opens the source, they are reading for judgement more than cleverness. A few things make a strong impression:

• Sensible structure, with files and folders organised the way a teammate would expect to find them.
• Meaningful names and small, focused functions over dense one-liners that show off.
• Tests for the core logic, even if coverage is not complete. Some tests beat none, and a single well-named test that documents the tricky case is worth more than a hundred trivial ones.
• Error handling where it genuinely matters, not defensive noise on every line.
• A consistent style, ideally enforced with a linter and formatter config committed to the repo so the style is the project's, not just your editor's.

You do not need a perfect codebase. You need code that looks like it was written by someone who would be easy to work with. One well-built project beats five sprawling ones with copy-pasted code and no tests.

Consider what a single tidying pass does to a function. Before:

function p(d){let r=[];for(let i=0;i<d.length;i++){if(d[i].s=='active'&&d[i].v>0){r.push(d[i].v*1.2)}}return r}

After:

const TAX_MULTIPLIER = 1.2;

function activeTaxedValues(records) {
  return records
    .filter((r) => r.status === "active" && r.value > 0)
    .map((r) => r.value * TAX_MULTIPLIER);
}

The logic is identical. The second version tells a reviewer you name things, you keep functions readable, and you do not leave magic numbers lying around. That is the difference between "this person writes code" and "this person writes code I would review without dread."

Tidy your commit history and hygiene

Reviewers sometimes glance at commit history, and it reveals habits in a way a polished README cannot. A history of "fix", "stuff", and "asdf" reads as careless. You do not need to rewrite years of history, but for showcased projects, aim for commit messages that describe the change in plain language. A useful test: could a teammate understand what changed from the subject line alone, without opening the diff.

Check the basics too:

• No secrets, API keys, or credentials committed anywhere, including in old history. Scan before you make a repo public.
• A sensible .gitignore so you are not committing build output, dependencies, or local config.
• A license file if you want the work treated as genuinely open. Without one, others legally cannot reuse it.
• A profile README on your GitHub landing page with a short, human introduction.

Committed secrets are both a security problem and a judgement signal, so this deserves a careful pass before any profile goes in front of an employer. A key buried in commit 200 of a public repo is still exposed even if the current files are clean, because the history is public too. A dedicated secret scanner, or a manual git log -p pass, catches most of it. If you find a live key, rotate it first and clean history second. The rotation matters more than the cleanup.

Build your green squares honestly, or ignore them

The contribution graph gets more attention than it deserves, mostly from candidates rather than reviewers. A consistent history of real work looks good, but experienced reviewers know the graph is trivial to game and that plenty of serious work happens in private or company repositories. Do not stuff your graph with daily trivial commits to fake activity. It is transparent and a little embarrassing if noticed, and it signals exactly the wrong thing about how you spend effort.

If your best work lives in private or work repositories, that is normal and expected for most working engineers. Mention it plainly in interviews and describe what you built, the constraints, and your specific contribution. A strong verbal account of private work carries more weight than a busy public graph of throwaway commits. Our guide to backend engineer interview questions covers how to talk about work you cannot show.

Treat the portfolio site as a curated front page

If you keep a personal portfolio site, treat it as the curated version of your GitHub, written for humans who may not read code. For each featured project, include the problem, your role, the stack, the outcome, and a link to the live demo or repo. Keep it fast, keep it simple, and make sure every link works, because a broken demo link undercuts everything around it.

You do not need an elaborate site. A clean single page with three strong projects and a clear way to contact you does the job. Reviewers are looking for signal and ease, not visual fireworks. If your site loads slowly, has a placeholder "lorem ipsum" section, or links to a demo that 404s, it actively hurts you, which is why no site at all is better than a half-built one.

Make it match the role you want, and the level you are at

Align what you showcase with the roles you are chasing. If you want backend work, pin projects that show data modelling, APIs, and reliability rather than a flashy frontend toy. If you are targeting AI-native roles, surface work that involves model APIs, evaluation, or data pipelines, with a README that explains how you measured quality. A reviewer should glance at your pinned repositories and immediately see someone who fits the role, not someone they have to squint at and guess about.

Seniority changes the emphasis too.

• Junior and early career. Quantity of evidence matters more, because you have less professional work to point to. A few complete, well-documented projects do real work for you here. Showing you can finish and document is the signal.
• Mid level. The bar shifts from "can you build" to "do you build well". Tests, structure, and sensible trade-offs in your READMEs carry the weight. One serious project beats three demos.
• Senior and beyond. Reviewers expect most of your strongest work to be private, so the graph and repo count matter little. Depth helps: a thoughtful technical write-up, a meaningful open-source contribution, or a README that reasons about trade-offs the way a senior engineer would in a design review.

The role also shifts what to surface. A product engineer benefits from a live, polished demo more than a backend specialist does. A platform or infra candidate gains from showing CI config, Dockerfiles, and observability over a pretty interface.

A short before-and-after

Before. Twenty-six public repositories. Pins are a forked "awesome-list", a half-finished React tutorial, and an empty repo from last week. No profile README. The one genuinely good project, an API with tests, sits on page two and is never seen.

After. Four pins: the API project with a clear README and a live docs link, a CLI tool with a usage clip, a small library with a test badge, and a write-up repo explaining a performance investigation. Everything else archived. A two-line profile README states focus and location. The change took one afternoon, and the median repo a reviewer now sees is strong. Nothing was faked. The good work was always there, just buried.

Frequently asked questions

How many repositories should I have public? There is no magic number. Three to six strong pins matter far more than the total. A reviewer rarely counts; they judge the median of what is visible.

Should I delete my old bad projects? Archive rather than delete. Archiving hides them from casual view, adds a "no longer maintained" banner, and keeps your own copy. Delete only if a repo contains something you genuinely never want associated with you.

Does a low contribution graph hurt me? Rarely, and less the more senior you are. Most serious work is private. Speak to that work in interviews instead of gaming the graph.

Is a portfolio site worth building? Only if you will keep it working. A clean single page helps non-technical reviewers; a broken or half-finished one hurts. If in doubt, a strong GitHub profile alone is enough.

How long should all this take? A focused afternoon for the high-leverage work: pins, READMEs on those pins, a secret scan, and archiving the noise. Deeper code cleanup can follow if you have time, but the funnel fixes come first.

Continue your prep

Pair a clean profile with role-specific interview practice:

• Backend engineer interview questions
• Backend engineer salary guide
• Backend engineer resume template