STAR Stories & Resume
Your resume is currently aimed at the wrong job
Your current resume leads with "Innovative Full Stack Developer and Linux Infrastructure Enthusiast". That headline gets you filtered out of an IT support pipeline before anyone reads a bullet point.
Recruiters filter on keywords from the JD. Your resume currently contains none of: Active Directory, Group Policy, Windows Server, DNS, DHCP, VLAN, nmap, Wireshark, PowerShell.
Do not replace your developer resume — it is valid for developer roles. Build a separate one-pager aimed squarely at this JD, and send that one here.
Headline change
- Innovative Full Stack Developer and Linux Infrastructure Enthusiast…
+ IT Support Engineer / Systems Administrator —
+ Windows, Linux, Networking and Active Directory
Translate what you have already done
Your projects are not irrelevant — they are described in the wrong language.
| Current bullet | Rewrite as |
|---|---|
| "Self-hosting, self-deployment" | "Administers Linux infrastructure across multiple hosts — provisioning, systemd services, updates, log monitoring and uptime" |
| "Built lightweight telemetry widgets for CPU, memory, storage, temperature and network traffic" | "Built real-time monitoring and telemetry across CPU, memory, storage, temperature and network utilisation" |
| "Deployed a service on Oracle VM using Docker behind Nginx" | "Deployed and maintained a production service on virtualised infrastructure with containerised services behind a reverse proxy" |
| "Advanced Node.js child process integration to control a game server" | "Administered server lifecycle and remote access control — start, stop, status and access allowlisting" |
| "Built a dashboard for server lifecycle controls, real-time status monitoring" | "Delivered server administration and monitoring tooling: lifecycle control, live status and access control" |
You have administered servers, monitored systems, scripted service management and deployed to virtualised infrastructure. That is genuinely relevant. It was simply described as web development instead of operations.
Skills block — match the JD's language
**Operating Systems:** Windows 10/11, Windows Server 2019/2022, Linux (Debian, Ubuntu, Arch)
**Networking:** TCP/IP, subnetting, DNS, DHCP, VLANs, 802.1Q, routing, VPN, firewalls
**Directory Services:** Active Directory, Group Policy, OU design, delegation, Kerberos
**Server Administration:** Windows/Linux server roles, DNS, DHCP, IIS, patch management,
system hardening, backup and restore
**Virtualisation:** VMware Workstation/ESXi, Hyper-V, VirtualBox, Oracle VM
**Security:** Windows Defender/EDR, Windows Firewall, BitLocker, least privilege
**Diagnostics:** ipconfig, netstat, nslookup, Test-NetConnection, nmap, Wireshark, PerfMon
**Scripting:** PowerShell, Bash, Linux service management (systemd)
**Languages:** JavaScript, Go, SQL
Never list Active Directory or Group Policy if you have never administered them. This guide is why you should do Lab 3 first — then the claim is true, and you can talk about it for ten minutes.
Add a Home Lab section
This is the single most effective addition available to you, because it converts every gap into experience.
### Home Lab — Windows & Network Infrastructure
Built a multi-VM lab to practise enterprise support administration:
- **Windows Server 2022 domain controller** — AD DS, DNS and DHCP roles,
three-tier OU structure, delegated helpdesk account
- **Windows Server 2022 member server** — file shares with NTFS and share
permissions, print server, IIS
- **Ubuntu LTS joined to the domain** via SSSD/realm — mixed-ecosystem management
- **pfSense** — firewall rules, VLAN routing, WireGuard VPN
- **Client VM** — reproduces the ticket scenarios studied in this curriculum
- **Monitoring** — Wazuh/Prometheus collecting host metrics and alerts
- **Documentation** — runbooks written in GitHub, referenced from this resume
Your three STAR stories
Build these from what you already own. Do not invent anything.
Roughly 20% situation, 60% action, 20% result. Interviewers are grading the action.
Story 1 — A service that would not stay running
S: A self-hosted media server kept exiting after a few hours, which broke
automations that depended on it.
T: I owned the host, so keeping it stable was mine.
A: I checked journalctl for the exit reason rather than restarting it
blindly, found a memory limit in the unit file, checked actual usage with
systemctl show and free, raised the limit and added Restart=always with
a backoff. I also added a health check to a cron job that alerts me instead of
waiting for a user report.
R: Uptime went from hours to months, and the failure mode became visible
before it became an outage.
Story 2 — A metric that lied
S: My monitoring showed a service as healthy while it was returning errors to users. T: I owned both the service and the monitoring, so the gap was mine. A: I compared what the health check actually tested against what users depended on. The check was only confirming the process was alive, not that it served requests. I changed it to exercise a real endpoint, set the threshold on response time rather than uptime, and added a separate check on logs for error rates. R: The monitoring started catching real failures before users reported them.
Story 3 — A network fault in my own environment
S: A containerised service on my homelab stopped resolving names, which
looked like a DNS problem.
T: My own infrastructure, my responsibility.
A: Rather than restarting Docker, I checked ipconfig-equivalent state
inside the container, found the DNS server address had not been inherited
after a configuration change, verified with dig against a public resolver,
and fixed the compose configuration to set an explicit nameserver.
R: Resolution recovered, and I added the check to my post-change routine
because the failure mode recurred after network-affecting changes.
How to talk about the lab honestly
"I haven't administered this in a production enterprise, so I built a lab to
learn it properly. I have a Server 2022 domain controller with AD DS, DNS and
DHCP, a three-tier OU structure, delegated permissions for a helpdesk role,
and GPOs I've broken deliberately and diagnosed with gpresult /r."
That answer is stronger than claiming production experience and being probed, because it shows initiative, self-teaching, and you know exactly what you have and have not done.