The whole site, turned into answers
The hiring manager has told you exactly what he cares about. This page organizes the likely questions by domain, the STAR stories that back them, and the questions you should ask back — because the strongest signal a candidate sends is what they ask.
Three things he told you — use them
"On-prem, not cloud"
He drew the line between cloud-managed BGP/K8s and real on-prem ownership. Volunteer the difference before he asks. Your Penske datacenter + AWS mix is the perfect proof: you've run both, you know which one this job is.
"Team of two, one owns it"
They're hiring redundancy. Position every answer around de-siloing: runbooks, cross-training, mentoring 15+ admins, shared on-call. You are the person who makes sure no one is a single point of failure.
"BGP is the main skill"
Lead with it. When he asks the openers, steer to routing. The BGP page is your highest-value study time — spend double there.
Likely questions, with the angle to take
BGP & network
Walk me through your BGP experience — what did you actually own?
Penske: configured peers, route advertisements, and routing policies; troubleshooted on-prem routing and reachability across infra services. Structure it: (1) the environment — DC + AWS, internal ASN design, (2) what you configured — sessions, filters, policies, (3) an incident you solved, (4) the hardening you applied. Keep it 90 seconds, concrete verbs.
How would you design BGP for a new datacenter?
Leaf-spine, eBGP between leaves and spines (or iBGP + route reflectors at scale), private ASNs, loopback peering for stability, ECMP everywhere, BFD for convergence, prefix filters + max-prefix by default, then MetalLB/FRR peering from the cluster into the leaves for service VIPs. Draw it while you talk — on the whiteboard, not just in the air.
Your core router is blackholing a prefix. How do you find it?
Confirm the symptom (which destinations, from where) → trace the route hop by hop → check whether the prefix is in each router's RIB and FIB → look for a recent route-map/filter change → compare table snapshots → roll back the suspect change and diff. Emphasize change discipline: routing incidents are usually policy changes.
OpenShift & Linux
What does your day-2 look like on an OpenShift cluster?
Upgrades through CVO with EUS channels and canary pools, etcd backups + tested restores, cert expiry monitoring, operator lifecycle through OLM, node drains/reboots via MCO, capacity and scheduling triage, and security posture via SCCs + Compliance Operator. Then tie it to their reality: bare metal, MetalLB VIPs, Windows VMs landing in OpenShift Virtualization.
How do you migrate a Windows VM to OpenShift?
MTV: provider → maps → plan → warm precopy → cutover → verify → retain source as rollback. Lead with the dependency map (AD, DNS, time, agents), then the Windows traps: virtio drivers, firmware, firewall profiles, activation. This answer is rehearsed on the Migration page — own it cold.
How is OpenShift different from upstream Kubernetes?
Kubernetes plus opinion: CVO/MCO/OLM operators make the platform self-managing; integrated Router + registry; SCCs on top of RBAC; RHCOS immutable hosts managed by MachineConfigs; and Red Hat support for the whole stack. On-prem, that support contract is the answer to "who do we call."
L4/L7 & load balancing
Explain L4 vs L7 and where you'd use each.
L4 = IP:port tuples, fast, blind to content; L7 = protocol-aware, slower but can route on host/path/cookie and do TLS/WAF. Use L4 for pure distribution and MetalLB VIP delivery; L7 at the Router/F5 edge for routing, TLS, and security. Full map on the L4/L7 page.
You have F5 experience — how would F5 fit here?
As the north-south front door: LTM virtual servers, GTM for multi-site, APM for auth at the edge, WAF where needed — in front of both the legacy Windows estate and the OpenShift routes during migration. iRules for the tricky L7 logic. This is a differentiator question: answer it like you've already imagined their topology.
Hardening & security
How do you approach hardening across servers and network?
BGP session security first (GTSM, TCP-AO, prefix limits, RPKI), then hosts (SELinux enforcing, firewalld, SSH, CIS via OpenSCAP/Compliance Operator), then segmentation (VLANs + NetworkPolicies), then TLS hygiene, then the loop: scan → patch → verify → report. Back it with the Nessus + Ansible 90% story — it's your strongest proof.
Tell me about a time a security finding needed a fix fast.
STAR it: Situation (critical Nessus finding on production Linux fleet, PCI DSS exposure) → Task (patch 1000+ servers without breaking apps) → Action (prioritize by exposure, Ansible playbooks in change windows, phased rollout, verify with rescans) → Result (closed on deadline, automated the whole monthly cycle, cut effort 90%, reported posture to management weekly).
NinjaOne & endpoints
Have you used NinjaOne or similar RMM?
Honest pivot: "Not NinjaOne specifically — but I've run the same job with SCCM/WSUS for Windows and Ansible + CrowdStrike at 1,000+ server scale. The RMM model — policy, patching windows, script automation, alerting — is the operating loop I already run." Then ask a sharp question back about their agent coverage to show fluency. No fake experience — the NinjaOne page covers the concepts to speak to.
Behavioral (the team-of-two angle)
We're a small team. How do you make sure you're not a single point of failure yourself?
This is THE question. Answer: runbooks for every repeatable task, cross-training by design (mentored 15+ admins at Penske), documentation in the repo next to the configs, paired on-call, DR testing that proves the backup person can actually do the job. "The environment should survive me taking vacation — and I build toward that every week."
Tell me about a migration that nearly went wrong.
STAR it: the 50+ TB NetApp → PowerScale NFS migration — the scale is the story: phased data moves, verification passes, rollback posture, minimal disruption. Or a V2V dependency gotcha: app breaks post-move because of a hidden dependency (licensing, DNS, time sync) — what you found and how you systematized dependency mapping afterward. Scars are credibility.
Questions to ask the hiring manager
Pick four. Each one signals ownership mindset:
- "Where is the migration today — inventory done, pilots running, or mid-flight? What's the current wave's biggest bottleneck?"
- "How is BGP structured today — which devices peer, and does the cluster announce service VIPs via MetalLB already?"
- "What's the OpenShift version and upgrade cadence — are you on EUS channels, and who owns etcd backup/restore testing?"
- "Which Windows workloads are the hard cases — AD-coupled apps, licensing, or vendor-locked software?"
- "What would 'redundancy achieved' look like in six months — what should I be able to do solo by then?"
- "How does on-call work for a team this size, and what's the loudest alert today?"
- "How does NinjaOne fit — is it endpoints only, or do the Linux servers report into it too?"
Interview tactics
Draw, don't just talk
Any architecture question gets a whiteboard sketch: boxes for ASNs, arrows for sessions, the traffic path client → switch → VIP → pod. Drawing while explaining is the single strongest "I actually run this" signal.
Answer the question asked
If he asks about a flapping session, start with the session. Show the algorithm second. Depth on the problem in front of you beats breadth.
Be the redundancy hire
Every story closes with the de-siloing lesson: "and now there's a runbook, and two other people know how to do it." That's the narrative they're literally hiring.