Support Technician (L1/L2), Infrastructure Hosting

Schedule: 24/7 shift rotation. Shift assigned on coverage need, weekend rotation included.
Compensation: USD $1,200–$2,400/month, depending on experience.
Reports to: Support shift lead, with technical escalation to the FDC tech lead.
The work
FDC Servers runs bare metal, VPS, and network infrastructure for clients across North America, Europe, and Asia. Real hardware in real data centers, in more than thirty locations. When something breaks, a client is down, and the ticket stays with you until it's actually resolved.
That ownership is the core of the job. You pick up a problem, work out what's actually wrong, fix what you can reach, and hand off the rest with enough detail that nobody has to start over.
We're hiring across the L1 and L2 band. Where you land is set at offer, based on what you show us rather than on your last title. There's a real path between the two, and we move people on demonstrated capability rather than time in seat.
You don't need a hosting background
If you don't see your background in the list below, we'd still like to hear from you.
We care about what you can do more than where you learned it. People come into this work from a lot of directions, and the ones who do well tend to share a habit rather than a history: they take something apart to find out why it broke.
Backgrounds that work well here:
• You run a homelab. Proxmox VE or ESXi on secondhand hardware, a NAS you built, services you self-host, a network you've segmented into VLANs because you wanted to.
• You've administered game servers, a community Minecraft or CS network, anything where real users noticed when it went down.
• You've worked NOC or field ops at an ISP or telco, and you know what packet loss looks like before a customer calls about it.
• You were the person at a small company who ended up owning the servers because nobody else would.
• You're self-taught, with no degree, and you've spent years reading documentation and breaking things in a VM.
• You came from a different field entirely and taught yourself this because it held your attention.
These are paths our strongest people have actually come in on. One of our best recent hires was a junior with a modern toolset and an instinct for automating things, chosen over candidates with a decade more on paper.
Our interview goes into detail on the work you describe, so what helps you most is depth you can talk through. If there's an edge to what you know, say so. We think well of people who are clear about it.
What you'll actually do
• Diagnose and resolve problems across hardware, operating systems, and networking: disks and RAID, SMART data, NICs, BIOS and UEFI, IPMI and BMC access, PXE boot failures, throughput and packet loss, stability
• Handle Linux and Windows Server administration as part of resolving tickets, not as a separate specialty
• Run our automation rather than doing everything by hand. We've built self-service jobs in AWX for multi-site iperf3 throughput testing, NIC tuning, and boot diagnostics. You get execute access early, and we'd like you to use it and attach the output to the ticket.
• Scope and coordinate remote hands work with data center technicians. That means writing a task somebody on the floor can carry out without calling you, and verifying it was done before you close anything.
• Write internal notes that let the next shift continue without re-investigating. This is one of the standards we hold most consistently.
• Escalate with evidence: what you checked, what you found, what you already tried, and what you need.
At the L2 end of the band, add owning the harder tickets on your shift, being the person L1s bring a stuck problem to, holding remote hands coordination for the whole shift rather than just your own tickets, and taking first pass on tickets nobody else has been able to close.
What we're looking for
You read the whole thread before you reply. You verify a server is reachable before telling a client it's reachable, and you know a ping reply isn't that verification. When you spot something wrong next to the thing you were asked to fix, you flag it rather than leaving it for whoever finds it next.
You can tell the difference between "I don't know" and "this isn't mine." The first comes with a description of what you've already ruled out. The second goes to the right team with enough context that they don't repeat your work.
You handle a frustrated client like a professional, and you write the reply the situation calls for rather than reaching for the nearest template.
And you're curious. That matters more to us than any certification. The people who do well here want to know why the thing broke, not just how to make the ticket go away. The rest we can teach.
Technical baseline
This is what we'll test. Where you picked it up doesn't matter to us.
• Linux command line. Comfortable diagnosing and working without looking up every command. This is the floor.
• Hardware. Disk types and interfaces, SMART attributes and what they mean, RAID levels and controller behavior, NIC types and form factors, server components and how they fail.
• Networking fundamentals. IP addressing and subnetting, VLANs, the difference between ping, SSH, and application reachability, basic routing, reading latency and packet loss.
• Written English clear enough for direct client communication. You'll be writing to clients daily. We're reading for clarity, not for accent or polish.
Nice to have
• Proxmox VE or VMware
• WHMCS or a comparable ticketing platform
• Packet capture with tcpdump or Wireshark
• Docker or Kubernetes basics
• Any scripting, in anything
Certifications aren't required. We test the baseline directly, so not having one won't count against you.
Things worth knowing before you apply
Templates will only take you so far here, because most tickets need a real diagnosis behind the reply. The role expects you to look at problems next to the one you were handed rather than staying strictly in your lane. And passing a ticket to another team counts as a handoff, with the evidence attached, rather than as a resolution.
We'd rather you know all of that up front, so you can judge whether it sounds like the kind of work you want.
How to apply
Send a CV if you have one. If your CV doesn't show what you can actually do, send us something that does instead:
• A short writeup of your homelab or home network. What's in it, why you built it that way, what broke and how you found out.
• Something you automated, however small. A script, a playbook, a repo.
• A war story. The worst outage or hardware failure you've dealt with, what you thought it was at first, and what it turned out to be.
Two or three paragraphs is plenty. We read these, and for people without a conventional background they carry more weight than the CV does.
How we hire
A written screening exercise first, then a live technical interview. The written stage is deliberate: explaining a problem in writing is most of this job, and we'd rather see that before we take your time on a call.
We tell you yes or no either way, with the reason.

Work arrangement
Yes