A technical hiring manager evaluating a candidate without a CS degree has one question: can this person actually build things? Your GitHub profile is the only evidence you can submit before anyone agrees to talk to you. Most self-taught developer profiles waste that evidence.
Here is exactly what to build and how to structure it.
Analysis Briefing
- Topic: GitHub profile strategy for self-taught developers without degrees
- Analyst: Mike D (@MrComputerScience)
- Context: Born from an exchange with Claude Sonnet 4.6 that refused to stay shallow
- Source: Pithy Cyborg | Pithy Security
- Key Question: What does a GitHub profile need to get you hired when credentials aren’t on your side?
What Technical Hiring Managers Actually Look For
I have talked to engineers at companies ranging from early-stage startups to large tech firms about how they evaluate GitHub profiles. The consistent answers:
Evidence that you shipped something real. A completed project with a live URL beats a 50-repository graveyard of half-finished tutorials. One working thing is worth more than ten abandoned things.
Code quality in the language they use. They are not grading your entire body of work. They are looking at the code in the language relevant to the role and asking: is this person writing code I would want to maintain?
Commits over time. A green contribution graph with commits spread across months tells them you code consistently, not just during interview prep sprints. The pattern matters more than the total count.
READMEs that explain the thinking. A project with no README is a project that requires effort to evaluate. Hiring managers who spend ten minutes on a profile move to the next one if they cannot figure out what a project does and why it exists.
The Three Projects That Signal Competence
You do not need twenty repositories. You need three good ones. Everything else is noise that dilutes the signal.
Project 1: The Real Tool You Actually Use
Build a tool that solves a problem you actually have. It does not need to be novel. It needs to be complete, deployed, and genuinely used.
A CLI tool that automates something tedious in your workflow. A personal finance tracker because you wanted one that worked exactly the way you think. A script that processes a specific kind of file you work with constantly.
The “real tool you use” signals two things that generic portfolio projects do not: you can identify a problem worth solving, and you care enough about the result to actually run the thing. Those are both signals that a hiring manager is actively looking for.
Keep the scope small enough that you can complete it. A working 500-line tool beats a planned 5000-line tool at commit 200.
Project 2: The Technical Deep Dive
One project that shows you can go deep on a technical problem. This is where you demonstrate the skill relevant to the roles you want.
For backend roles: a service that handles a real concurrency or performance challenge. Connection pooling, rate limiting, async task queuing, a feature that required understanding something non-trivial.
For ML/AI roles: an implementation that goes below the API level. Not “I called the OpenAI API and built a chatbot.” A RAG pipeline with a non-trivial retrieval strategy, a fine-tuning run with documented experiments, an evaluation framework with real results.
For systems roles: something that touches the layer below application code. A simple database from scratch, a network protocol implementation, a memory allocator, a scheduler.
The technical deep dive should have a README that explains the problem, why naive approaches fail, and what your approach does differently. This README is often what gets you the initial interview.
Project 3: The Open Source Contribution
At least one project that is not entirely yours. A merged pull request to an active repository with real users demonstrates that you can read unfamiliar code, understand a codebase’s conventions, and produce work that meets another engineer’s standards.
This is the one project type that no tutorial can fake. Either you have a merged PR in a repository with actual users or you do not.
The contributions do not need to be large. A well-crafted bug fix with a good commit message and a test that catches the regression is exactly what maintainers want and hiring managers respect.
The README Structure That Gets Read
Most project READMEs answer “what does this do?” but not “why should I care?” Hiring managers evaluating your profile are reading your READMEs as writing samples and thinking process samples, not just documentation.
The structure that works:
# Project Name
One sentence: what it does and who it is for.
## The Problem
Two to three sentences on what problem this solves and why existing solutions
did not work for this use case. This is where you demonstrate that you can
identify a real problem worth solving.
## How It Works
The interesting technical decisions. Not a feature list. The parts that were
non-trivial to figure out. One paragraph is enough if the project is small.
## Quick Start
The minimum commands to get this running. If it takes more than three steps,
include a one-command setup script.
## What I Learned / What I Would Do Differently
Optional but differentiating. Most candidates do not include retrospective
thinking. It signals engineering maturity.
The “What I Learned” section is the highest-signal section in the entire README for a hiring manager evaluating a junior developer. A candidate who can articulate what they would do differently on a project demonstrates the kind of reflective thinking that predicts growth.
The Commit Message Discipline
Your commit history is a writing sample. Hiring managers who are thorough enough to look at commit history are the ones you most want to impress.
The commit message format that signals competence:
Short description (50 chars max, imperative mood)
Optional longer description that explains WHY this change was made,
not WHAT changed (the diff shows what changed). When would someone
reading this commit six months from now need to understand your
reasoning rather than just your actions?
Fixes #42
The imperative mood matters: “Add retry logic for failed requests” not “Added retry logic” or “Adding retry logic.” It reads like a command that changes the codebase when applied. This is the Git convention and knowing it signals that you learned from real engineering culture rather than tutorial culture.
The Pinned Repositories
GitHub lets you pin six repositories to the top of your profile. Use all six. Leave nothing to chance about which projects get seen.
Pin in this order:
- Your strongest complete project (the one with the live URL)
- Your technical deep dive
- Your open source contribution or the repository you contributed to
- A project in the primary language for the roles you are targeting
- A project that shows range (different domain or language from the others)
- Something in progress that shows you are currently building
The “something in progress” pin signals current activity. An entirely static profile looks like someone who stopped building when job searching started.
The Profile README
A GitHub profile README is a pinned repository named the same as your username. It renders on your profile page. Keep it short:
## Mike D | Building AI Tools and Teaching CS Without the Gatekeeping
Currently working on: [current project with link]
I write about building AI tools without a CS degree at [blog link].
Languages I use in production: Python, Rust, Java
Things I have shipped: [2-3 links to live projects]
Open to: [what you are looking for]
Four to six lines. A hiring manager who reads this knows who you are, what you build, and whether you are looking for the thing they are hiring for. That is all it needs to do.
The One Thing That Beats All of This
Ship a side project that people actually use. Not a project you built for portfolio purposes. A project that solves a real problem for real users who would notice if it went down.
Any of the advice above accelerates the process of getting hired based on a portfolio. A project with real users replaces the portfolio. The engineer who built a tool that 400 developers use does not need to optimize their commit message formatting. They have already demonstrated everything a hiring manager needs to see.
The portfolio is what you build on the way to the thing with real users. Build the portfolio. Keep building until something gets traction.
Mike D builds in public at @MrComputerScience. No degree required, no networking budget needed.
Enjoyed this deep dive? Join my inner circle:
- Pithy Cyborg → AI news made simple without hype.
- Pithy Security → Stay ahead of cybersecurity threats.