The degree or the GitHub repository?

Two folders sit on a desk.

In one, a degree.

In the other, a GitHub profile full of projects.

Which would you choose if you were hiring a developer?

The question looks simple.

It isn't.

A degree doesn't automatically mean someone can deliver software. And an impressive repository doesn't guarantee they understand every line inside it.

The interesting part may be less what a candidate shows than what they can explain.

What a degree can demonstrate

Structured education can provide valuable foundations: logic, algorithms, architecture, databases, networks and project management.

It also makes people study subjects they might not have chosen on their own.

A degree can signal sustained effort and assessment.

That's worth respecting.

I studied computing after previously pursuing law.

But I also know that not every reality of a software project is taught in a classroom.

What a portfolio reveals

A project allows you to look beyond a list of skills.

How did the person organise the code?

Why that architecture?

What tests did they write?

What would they change today?

How do they react when asked to fix a bug or extend a feature?

A portfolio doesn't need twenty projects.

One product explained clearly can tell you a great deal.

But be careful: some work was done in teams or with code-generation tools. That's not automatically a problem.

You need to understand the person's real contribution.

What if the work isn't public?

This is where “show me your GitHub” becomes unfair.

Not everybody can publish work built for clients or employers.

Some developers work on confidential internal systems. Others have strong experience but little time for public demos.

An inactive profile isn't proof of incompetence.

A candidate can discuss architecture without revealing private information, review permitted code or work through a small business scenario.

Good interviews aren't traps

I'm wary of interviews that become memorisation competitions.

Definitions matter sometimes.

But professional development involves reasoning.

Imagine two customers trying to book the final available place.

How do we avoid double booking?

You can discuss transactions, database constraints, states and tests.

The goal isn't to embarrass anyone.

It's to see how they approach a problem.

Does AI change the assessment?

A little.

Candidates can now generate interfaces, tests and explanations.

That doesn't mean every use of AI should be prohibited.

It's better to define what's allowed and ask people to justify their decisions.

What did they ask the tool?

What did they check?

Which mistake did they catch?

Could they maintain the result without the exact generated answer?

Those skills matter.

How I'd assess a junior developer

I'd combine several signals:

• Understanding of fundamentals.
• A few projects they can explain.
• Questions they ask about vague requirements.
• Their approach to debugging.
• Attention to security, users and maintenance.
• Willingness to admit what they don't know yet.

Context matters too.

Not everyone has had the same hardware, connectivity or opportunities.

A false choice

I don't think degrees and portfolios should be rival camps.

Education gives depth.

Projects show how knowledge gets used.

Work experience brings constraints that rarely appear in classroom exercises.

So the real question isn't “Which document or link is more impressive?”

It's “Can this person understand a problem, build a solution and keep learning?”

That's what I'd hope people consider when looking at my own path too.