Candidate Interview Labs

Broken on purpose so candidates can show how they think.

These labs are meant to reveal troubleshooting judgment, communication, and calm under ambiguity. They are not trivia quizzes, certification drills, or production-adjacent sandboxes.

The site explains the interview design clearly while keeping the real topology, reset controls, and administrative internals private. Candidates work from a controlled Windows VM loaded with the same kinds of tools they would normally use in a real troubleshooting session.

View lab types Candidate login flow See isolation model Back to homepage

Interview-first design No production crossover Resettable scenarios Public-safe overview only

Lab goals

Candidate evaluation model

Networking Pathing, DNS, VLAN, firewall, and troubleshooting flow through a hidden GNS3 backend

Candidate seat Windows toolbox VM with normal admin and network troubleshooting utilities

Evaluation Reasoning, communication, prioritization, and follow-through

Control Per-session isolation, timed access, and repeatable reset paths

Open interview flow Open candidate portal mockup Open monitoring page

Broken Networking Lab

Designed to expose troubleshooting process, not memorized commands.

The networking lab should simulate the kind of partial outage or confusing path problem that strong engineers and administrators see in the real world: symptoms in one place, root cause in another, and enough ambiguity to make communication matter. The actual fault should live inside a hidden GNS3 topology that the candidate never sees directly.

Typical failures OSPF drift, route leaks, STP surprises, VLAN mismatches, ACL blocks, HSRP confusion, or asymmetric pathing.

What they see A Windows jump VM with common tools such as ping, tracert, nslookup, Wireshark, PuTTY, and browser access to test endpoints.

Interview signal How someone narrates their thinking, handles uncertainty, and chooses the next most useful check without seeing the backend topology.

Desired outcome A candidate may or may not fully solve it, but they should show structure, composure, and clear logic from the evidence available at the edge.

View the candidate-facing login and Windows toolbox flow

Broken Linux Lab

Focused on systems reasoning, service recovery, and safe change habits.

The Linux lab should feel like a believable operations problem: a service that no longer starts, a storage condition that looks like an application issue, or a permissions break that creates noisy but misleading symptoms.

Typical failures Systemd service failures, package drift, bad file permissions, mount issues, cron/job problems, or broken configs.

What it tests Log reading, methodical triage, rollback awareness, and ability to change one variable at a time.

Interview signal Whether the candidate gathers evidence before acting and explains risk while working through the fix.

Desired outcome The goal is to evaluate recovery approach and operational judgment, not speed-running shell syntax.

Isolation Model

The labs should be real enough to matter and isolated enough to be safe.

Candidate access must stay separated from the live public site, ERP systems, and admin surfaces. Every interview environment should be disposable, time-boxed, and easy to reset without manual cleanup.

Access

Controlled entry points only

Temporary credentials or one-time session access.
Candidates log into a Windows VM, not the hidden GNS3 controller or backend devices.
No shared administrator secrets exposed to candidates.
No direct path to production services, dashboards, or host controls.

Networking

Private segmentation and policy boundaries

Labs segmented from public and internal management networks.
Hidden GNS3 backend separate from the candidate Windows jump host.
Deliberate fault injection without affecting the rest of the stack.
Clear reset points for each interview scenario.

Operations

Reset, review, and repeatability

Scenario snapshots or rebuild automation per lab.
Monitoring that shows when a lab is available or needs reset.
Consistent scoring criteria tied to how candidates approach the problem.

Interview Flow

A simple structure that keeps the exercise fair and useful.

Suggested session format

1. Candidate receives a session code
2. Candidate logs into the portal
3. Candidate launches the Windows toolbox VM
4. Candidate investigates live symptoms from that VM
5. Candidate proposes likely root cause
6. Candidate explains fix and risk
7. Debrief on tradeoffs and communication

What to watch for

Can they narrate what they know versus what they assume?
Do they check the highest-value evidence first?
Do they communicate risk before making changes?
Do they stay calm when the issue is not immediately obvious?
Do they avoid inventing topology details they cannot actually prove from the workstation?

Build direction

Phase 1: Public explanation page
Phase 2: Candidate login and Windows VM front end
Phase 3: Hidden GNS3 backend and reset automation
Phase 4: Resettable Linux lab
Phase 5: Scoring notes and monitoring

Design rule

The public page should explain the interview philosophy clearly.
The candidate should only see the Windows workstation and allowed test targets.
The real GNS3 project should stay private to the interviewer side.
The live lab controls should stay private and operationally simple.
The environment should measure reasoning, not memorization.