Free tech learning for everyone, from basics to pro

ProjectsLabsBeginner

Project: building a GitHub portfolio that gets interviews

In short: For networking and security roles, a GitHub profile is a portfolio of evidence. This project shows how to choose what to publish, structure each repository, write READMEs that reviewers actually read, keep secrets out and link it all to your CV.

Goal and requirements

The goal is a profile that lets a hiring manager confirm your skills in five minutes. You do not need to be a software developer: lab write-ups, configurations, scripts and diagrams are all valid content for network and security engineers.

  • A GitHub account with MFA turned on, ideally with a passkey or security key.
  • Git installed locally and the GitHub CLI (gh) if you like working from the terminal.
  • Three to six finished pieces of work, for example a lab series, an automation tool and a project write-up.
What reviewers look atYour GitHubprofile and pinsProfile READMEwho you arePinned reposbest 4 to 6READMEsproblem, how to runCommit historysteady, clearNo secretsscanned, cleanWrite-upslabs, diagrams
Figure 1. A recruiter or engineer spends a few minutes on your profile, so the pinned projects and their READMEs carry most of the weight.

Design

Plan the profile like a shop window. Create a repository with the same name as your username; its README becomes your profile page. Keep it short: a one-line summary of who you are, your focus areas, certifications, and links to your best repositories. Pin four to six repositories that match the jobs you want. A good repository README follows a simple pattern:

  1. Title and one-sentence purpose.
  2. Diagram of the topology or architecture.
  3. What it does and which skills it shows.
  4. How to run or reproduce it, step by step.
  5. What you learned, limitations and next steps.
Weak versus strong repositoryWeakName like test123No READMEOne giant commitPasswords in configStrongClear, descriptive nameREADME with diagram and usageSmall, meaningful commitsSecrets scanned and excluded
Figure 2. The same code looks completely different to a reviewer depending on how it is presented.

Build plan

  1. Create a .gitignore that excludes keys, state files, virtual environments and local configs before your first commit.
  2. Scan for secrets in every repository, including its history, and remove anything found. A secret that was ever pushed must be treated as leaked: revoke and replace it, then clean the history.
  3. Commit in small steps with messages that say what changed and why.
  4. Add a licence if you want others to reuse your code, and a short README to every repository.
  5. Turn on GitHub's secret scanning and push protection where available.
  6. Write the profile README and pin your best work.
git init
git add .gitignore README.md
git commit -m "Add README and gitignore"
gitleaks dir . -v
gitleaks git -v
git add .
git commit -m "Add OSPF multi-area lab configs and verification notes"
gh auth login
gh repo create ospf-multi-area-lab --public --source . --push
gh repo create <your-username> --public --add-readme

Warning: never upload configurations, logs, screenshots or diagrams from your employer, school or customers, even edited, unless you have explicit permission. Use lab data only.

Deliverables and how to present it

  • A profile README with a clear summary and links.
  • Four to six pinned repositories, each with a README, diagram and reproducible steps.
  • Evidence of steady work: regular commits over months, not one big upload.

Put your GitHub link in your CV header and on LinkedIn. In the CV's projects section, link straight to the specific repository next to each project, with one line describing the outcome. Before interviews, re-read your own READMEs: interviewers often pick one project and ask you to explain it, and the best answers describe a problem you hit and how you solved it.

Practice

How do you create a GitHub profile README?
Create a public repository with exactly the same name as your username; its README is shown on your profile page.
A password was committed and pushed last month. Is deleting the file enough?
No. It remains in history and may have been copied; revoke and replace the secret, then clean the history.
What should a project README contain?
Purpose, a diagram, what it does and shows, how to reproduce it, and lessons learned or limitations.

Key takeaways

  • Pin four to six projects that match the jobs you want.
  • Every repository needs a README with a diagram and reproduction steps.
  • Use .gitignore and secret scanning before the first push.
  • Never publish employer or customer data, even edited.
  • Link specific repositories from your CV and be ready to explain them.
Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author

Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.

Stay up to date by email

New notes, tools and security news from FM TecHub, explained simply. Free.

We only use your email to send these updates. See our privacy policy.