Skip to content
Log in Sign up My account

How to build a home lab portfolio employers notice

A home lab is only a portfolio if someone else can look at it and see what you can do. This article covers how to pick projects that map to real job skills, how to document them so a hiring manager can skim them in five minutes, how to lay out a GitHub repository, which automation projects carry the most weight, how to show troubleshooting, how to present all of it on a resume and in an interview, and what to avoid.

Start from the job, not the gear

Open ten job postings for the role you want and write down the recurring skills. For a network engineer role the list usually looks something like this: routing (OSPF, BGP), switching (VLANs, STP, EtherChannel), WAN or VPN, firewalls and ACLs, wireless, monitoring, automation (Python, Ansible), and some cloud networking. That list is your project backlog.

Pick projects that each prove one or two of those skills at a depth a lab can reach. A small project finished and written up beats a large topology that only exists in your head.

Job skill Project that proves it What the reviewer sees
Routing design Multi-site OSPF with a BGP edge, route filtering, summarisation Design reasoning, not just working adjacencies
Switching Campus with VLANs, RSTP, EtherChannel, first-hop security You know the failure modes
WAN / VPN Site-to-site IPsec with a routed overlay (for example DMVPN or a tunnel with a routing protocol over it) You can build and verify encryption and routing together
Security Zone-based or ACL-based segmentation with a written policy matrix You translate requirements to rules
Monitoring SNMP or streaming telemetry into a dashboard, with alert rules You operate networks, not only build them
Automation Config generation, validation and backup pipelines You reduce manual work
Cloud A VPC or VNet with a site-to-site connection back to the lab You can bridge on-prem and cloud

Tip

Two or three polished projects are enough. Depth and clear writing matter more than count. If you are studying for a certification, the labs on the CCNP lab setup page are a good source of topologies to extend into portfolio projects, and the study plan can help you decide which topics to build next.

Choose a lab platform you can share

Employers cannot touch your rack, so the portfolio has to be reproducible from files. That favours software-based labs:

  • Cisco Modeling Labs, EVE-NG, GNS3 or Containerlab for the topology. Check each one's current licence and image requirements, because they differ and change.
  • Plain text for everything else: device configs, topology definitions, scripts and notes.

Physical gear is fine and often impressive, but photograph it, diagram it, and still export configs into the repository. A rack photo with no configs proves little.

Warning

Do not publish vendor images, IOS files or licensed software in your repository. Publish your topology definition and configs, and tell the reader which images they need to supply themselves.

Document each project the same way

Use one template for every project so a reviewer learns the format once. A good write-up has these parts:

  1. Goal. One or two sentences. "Connect three sites with OSPF inside each site and eBGP between sites, with traffic engineering by local preference."
  2. Requirements. Numbered, testable statements. They become your verification checklist.
  3. Topology diagram. A picture of devices, links and addressing.
  4. Design decisions. Why you chose each protocol, timer or policy, and what you rejected.
  5. Implementation. Key configuration with a short explanation, not a dump of every line.
  6. Verification. The commands you ran and the output that proves each requirement.
  7. Troubleshooting log. What broke and how you found it (more on this below).
  8. Lessons and next steps. What you would change in production.

Diagrams

Diagrams are the first thing a reader looks at. Keep them legible: label interfaces and subnets, group devices by site or role, and show the logical layer you are discussing. You can keep diagrams as text so they live in version control and render on GitHub. Mermaid renders natively in GitHub Markdown files.

graph LR
    subgraph "Site A"
        A1["R1 AS 65001"]
    end
    subgraph "Site B"
        B1["R2 AS 65002"]
    end
    subgraph "Site C"
        C1["R3 AS 65003"]
    end
    A1 ---|"10.0.12.0/30"| B1
    B1 ---|"10.0.23.0/30"| C1
    A1 ---|"10.0.13.0/30"| C1

Keep a separate diagram per layer if one gets crowded: physical links, Layer 3 addressing, and routing or overlay relationships. Export a PNG or SVG too, so the page still reads in tools that do not render Mermaid.

Lay out the GitHub repository

A recruiter or interviewer may open your repo for under a minute. Make the structure obvious and put a README at every level.

network-lab-portfolio/
  README.md                  index of projects, one line each, with links
  01-ospf-bgp-multisite/
    README.md                write-up using the template above
    topology/
      topology.yml           lab definition (no vendor images)
      diagram.mmd
      diagram.png
    configs/
      r1.cfg
      r2.cfg
      r3.cfg
    verification/
      show-outputs.txt
    troubleshooting.md
  02-ipsec-overlay/
    ...
  03-config-pipeline/
    README.md
    inventory.yml
    templates/
    playbooks/
    tests/
  .gitignore
  LICENSE

Practical points:

  • The top-level README is a table of contents with a one-line outcome per project, not a biography.
  • Use numbered or descriptive folder names consistently.
  • Commit often with meaningful messages. The history shows how you work, including the mistakes you fixed.
  • Add a .gitignore for editor files, virtual environments and anything lab-specific that is large or licensed.
  • Pick a licence for your own code and text (MIT is common for scripts). If you do not choose one, others have no clear rights to reuse it.

Warning

Scrub every config before you push. Remove real public IP addresses, SNMP communities, pre-shared keys, enable secrets, usernames and anything from an employer's network. Use documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 from RFC 5737) or RFC 1918 space. Git history keeps deleted secrets, so check before the first commit, not after. GitHub's secret scanning can help, but do not rely on it alone.

Automation projects that carry weight

Automation is the area where a portfolio most clearly separates candidates, because it is checkable. Good projects are small, finish end to end, and are tested. Ideas in rough order of difficulty:

  1. Config backup. Pull running configs from lab devices with Netmiko or NAPALM on a schedule, store them in Git, and show diffs between runs.
  2. Inventory-driven config generation. Keep device data in YAML, render configs with Jinja2 templates, and push them. Show that the same template builds a different site by changing only the data.
  3. Pre- and post-change validation. Capture state before a change (neighbours, routes, interface status), apply the change, capture again, and report differences. Parsers such as TextFSM with ntc-templates or Genie can structure the output.
  4. Ansible playbooks. Use the cisco.ios collection to configure VLANs, interfaces or ACLs idempotently. Demonstrate that a second run reports no changes.
  5. CI pipeline. Run linting and template rendering tests on every push using GitHub Actions or a similar service, so a bad template fails before it reaches a device.
  6. Source of truth plus automation. Pull intended state from a tool such as NetBox and compare or generate configs from it. Run it locally in a container if you do not want to host anything.

A short snippet in the write-up shows intent without forcing the reader into the code. For example, a Netmiko backup core:

from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "192.0.2.11",
    "username": "lab",
    "password": "REPLACE_ME",
}

with ConnectHandler(**device) as conn:
    config = conn.send_command("show running-config")

with open("r1.cfg", "w") as f:
    f.write(config)

Never hard-code real credentials in a published script. Read them from environment variables or a secrets file excluded by .gitignore, and document that in the README.

Tip

Reviewers value a README that says "run these three commands and see this output." Include a requirements.txt or pyproject.toml, a sample inventory, and expected output. If it only works on your laptop, it is not a portfolio piece.

For a structured route from CLI work to automation, see the CLI to automation roadmap.

Show your troubleshooting

Troubleshooting is the skill that is hardest to fake and most valued on the job. Most labs only show the final working state. Add a short record of what went wrong.

Break your lab on purpose, or record real faults you hit, and write each up like this:

  • Symptom. What was reported or observed.
  • Scope. What worked, what did not, and how you narrowed it.
  • Evidence. The commands and output that pointed to the cause.
  • Root cause. One sentence.
  • Fix and prevention. What you changed and what would catch it earlier next time, such as a monitoring check or a pre-change test.

Good fault ideas: an MTU mismatch that breaks OSPF adjacency or a large transfer, an asymmetric route dropped by a stateful firewall, a mismatched BGP authentication key, a native VLAN mismatch, a missing route redistribution tag causing a loop. Show packet captures or debug output where they were decisive, and trim them to the relevant lines.

A page titled troubleshooting.md with three well-explained faults tells an interviewer more about you than another working topology.

Present it on a resume

Keep the resume entry short and outcome-focused, and link to the repository.

  • Put a "Projects" or "Lab experience" section under your experience, or above it if you have little professional history.
  • Write each entry as what you built, with which technologies, and the result you verified. Avoid listing every protocol you touched.
  • Include the link as a clean URL. Check that it works while logged out.
  • Be honest about scope. Say "lab" or "home lab" where it applies.

Example entries:

Multi-site routed network (lab): Designed and built a three-site topology with
OSPF internally and eBGP between sites, route filtering and summarisation,
verified against 12 written requirements. Documented design, verification
and fault write-ups on GitHub.

Config automation (lab): Built a Netmiko and Jinja2 pipeline that generates
and pushes interface and routing configs from YAML data, with pre/post
validation and GitHub Actions template tests.

Only quote numbers you can back up from your own project, as in the requirement count above.

Talk about it in interviews

Interviewers use a project as a starting point to probe how you think. Prepare for it.

  • Have a 60-second summary per project. Goal, design, one thing that went wrong, one thing you would change.
  • Know every line you published. If a script came from a tutorial or a generated snippet, understand it fully and say what you adapted. Expect to be asked to explain or modify it.
  • Lead with decisions. "I chose eBGP between sites rather than extending the IGP because I wanted failure domains separated" is a stronger answer than "I configured BGP."
  • Be ready for what-ifs. What happens if this link fails? How would you scale this to fifty sites? What would you monitor? What would be different with real traffic and real carriers?
  • Bring up a failure. Describing a fault you diagnosed shows method. Walk through scope, evidence and root cause, in that order.
  • Admit limits. A lab has no real carrier behaviour, scale, change control or users. Saying so, and saying how production differs, reads as maturity.

More question practice is in the interview prep article.

What not to do

  • Do not pad with duplicates. Ten near-identical OSPF labs read as one skill repeated.
  • Do not publish raw command dumps with no explanation. A folder of configs with no README tells the reader nothing.
  • Do not claim production experience you do not have. Label lab work as lab work.
  • Do not leak secrets or employer data. This can end a hiring process and cause real harm.
  • Do not copy someone else's repository. Following a guide is fine and a good way to learn, but credit it, then extend it with your own requirements and faults.
  • Do not leave broken links, empty folders or half-finished projects public. Archive or hide what is not ready.
  • Do not chase tools for their own sake. A project that uses five trendy tools but no clear goal is weaker than a simple project with a clear design.
  • Do not let the repo go stale. Even small updates, such as a new verification step or a fixed typo, show you are still working.
  • Do not neglect writing quality. Spell-check, use consistent terms, and keep sentences short.

A simple plan

  1. Collect ten postings and list the repeated skills.
  2. Choose three projects: one routing or switching design, one security or WAN project, one automation project.
  3. Build each in a shareable lab platform, with configs in text files.
  4. Write each up with the template, a diagram, verification output and at least one troubleshooting entry.
  5. Scrub secrets, publish, and add a top-level README.
  6. Add two resume lines and rehearse a 60-second summary for each.
  7. Revisit every few months and add one new project or improve an old one.

References