Schedule: Shift-based with coverage expectations, weekend rotation shared across the team. More scheduling flexibility than the L1/L2 role.

Compensation: USD $2,200–$3,000/month, depending on experience.

Reports to: FDC support tech lead.

The work

FDC Servers runs bare metal, VPS, and network infrastructure across more than thirty locations in North America, Europe, and Asia. Real hardware, real clients, and real consequences when it goes down.

This role is the end of the line on the technical side. When a ticket has been through two people and still isn't solved, it comes to you. When a client's packet loss doesn't show up in any obvious place, you're the one who finds it. When the same failure has happened four times, you're the one who works out why and makes it stop.

It's the depth track rather than the management track. You'll mentor and you'll set the technical standard, but nobody is asking you to run a rota or write performance reviews.

We're hiring across the L2 and L3 band. Level is set at offer based on what you demonstrate.

What you'll actually do

• Own the problems nobody else could close. Intermittent packet loss, hardware that fails only under load, boot failures with no obvious cause, performance problems that aren't where the client thinks they are.

• Diagnose at the network layer and interpret what you find. MTR analysis, packet capture, DHCP and PXE failure signatures, routing behavior, throughput testing across sites. Not just running the tool, but reading the output and knowing what it rules out.

• Turn one-off fixes into permanent ones. If you solved it by hand, the next step is a runbook, a KB article, or an AWX job template so the L1s solve it themselves next time. We measure this. Automation here exists to take tedious load off people, not to replace them.

• Build and extend the tooling. We run automation in AWX and Ansible: multi-site iperf3 throughput testing, NIC tuning, PXE boot diagnostics with packet-level tracing, firmware version tracking. These were built here, several of them from ideas the support team had first. You'll add to them.

• Set the technical standard by example. Your notes, your escalations, and your client writing are what the L1s copy. That's most of how a standard actually spreads.

• Be the second pair of eyes on remote hands scope. Catching an underspecified task before a technician drives to a data center is worth more than fixing it afterward.

• Escalate outward when it really is beyond us. Vendor escalation, network team, hardware RMA, with the evidence assembled rather than as an open question.

You don't need a hosting background, and you may not need the title either

We're looking for demonstrated depth. We're not looking for a specific job history, and we're not counting years.

Backgrounds that work well here:

• NOC or ISP engineering. If you've chased packet loss across a transit provider's network, you already do the hardest part of this job.

• A serious homelab or self-hosted setup. Multiple hypervisors, a segmented network, BGP at home because you wanted to understand it, services you actually maintain. People who do this for fun are often better diagnosticians than people who only ever did it for a paycheck.

• You were the whole IT department somewhere. Small company, no backup, everything from the switch config to the backups was yours. That breadth is exactly what this role uses.

• Open source or community work. You maintain something, you answer hard questions in a forum or Discord, you've debugged other people's infrastructure for free.

• Adjacent engineering. SRE, DevOps, systems, platform, or a sysadmin role in an industry with nothing to do with hosting. The hardware is learnable. The diagnostic instinct is the hard part.

• Self-taught, with no degree and no certs. That works. We test directly.

If you're strong but have never held a senior title because the org never had one to give you, please apply. That's a common shape and it isn't a mark against you.

Our interview goes deep on the work you describe, so depth you can talk through matters more than length on the page, and depth you can demonstrate doesn't need a credential behind it.

Technical baseline

This is what we test.

• Linux, deeply. Not just navigating. Diagnosing: what's consuming the resource, why the service won't start, what the kernel is complaining about, and how to prove it.

• Networking, properly. Routing, VLANs, MTU and fragmentation, reading an MTR and knowing what asymmetry means, packet capture and analysis, DHCP and PXE mechanics. Familiarity with BGP concepts is a strong plus.

• Hardware failure modes. SMART data and what predicts failure, RAID controller behavior, NVMe and SAS and SATA differences that matter in practice, memory and thermal faults, IPMI and BMC.

• Automation. Scripting at minimum. Ansible, or the ability to pick it up quickly and the interest to. You don't need to have used AWX.

• Written English strong enough to be the escalation standard. You'll write the notes other people learn from.

Nice to have

• Proxmox VE at scale

• Kubernetes, Docker, or Ceph

• Experience writing runbooks or KB material others actually used

• Data center or colocation operations exposure

• Any language beyond scripting

Things worth knowing before you apply

This isn't a step into meetings, and it isn't a role where you stop touching tickets. A large part of it is making yourself less necessary: writing down what you know and automating what you repeat, so the team can solve next time what you solved this time.

That suits some engineers much better than others, and it's worth knowing which you are before you apply.

How to apply

Send a CV. Then send us something that shows depth, because a CV usually doesn't:

• A war story with the diagnostic path. A hard problem you solved. What you thought it was, what the evidence actually said, where you were wrong on the way, and how you proved the real cause. The wrong turns are the interesting part.

• Something you built. A tool, a script, a playbook, a repo, a homelab you can describe in detail.

• Something you wrote. A runbook, a postmortem, a KB article, a long technical answer you gave somebody. We want to see how you explain things.

Any one of the three is enough. For candidates without a conventional senior background, these count for more than the CV.

How we hire

A written technical exercise, then a live interview that goes deep on real scenarios rather than trivia. We'll ask you to reason through problems out loud, and I don't know, here's how I'd find out is a good answer here.

We tell you yes or no either way, with the reason.

Support Engineer (L2/L3), Infrastructure Hosting