Technical Support Engineer

Who you are

• Very strong Linux experience and daily work in the CLI
• Experience owning tickets against a response SLA in cloud, hosting, or infrastructure support
• Solid networking and storage fundamentals: SSH, NFS and mounts, DNS, firewalls and security groups
• Working familiarity with GPU workloads: nvidia-smi, drivers, CUDA, containers
• Clear and fast written communication under time pressure. Customers read what you write while they are blocked
• Good judgment about the limits of your own knowledge, and a bias toward escalating early with a complete picture rather than late with a guess
• Comfortable working across time zones and with an on-call rotation for critical issues
• Experience with ticketing and on-call tooling (Zendesk, Linear, PagerDuty, or similar)
• Scripting in bash or Python to automate repeat work
• Exposure to Slurm, Kubernetes, or Docker in a multi-tenant environment
• Background in GPU cloud, HPC, or a hardware-adjacent support org

What the job involves

• When a customer's GPU cluster has a problem, you are the first engineer they talk to, and most of the time you are the only one they need to. You own the ticket from the first response to the resolution, you own the clock against our SLA, and you keep ownership even when the problem needs deeper help
• This is not a ticket routing job. You will be in Linux every day, on real infrastructure, fixing real customer problems. The people who do this well here move into the Forward Deployed Engineer role, and we will build that path with you deliberately
• Ticket ownership, end to end. You own every ticket you pick up, including after it escalates. You do not hand off, you pull in the engineer you need and stay on it until the customer is working
• The SLA clock. First response, severity classification, and keeping us honest against our response commitments. You are the person who knows where every open issue stands
• First technical response and triage. Reproduce the problem, gather the logs and configuration that matter, and make the first call on whether the fault is ours or the provider's
• Customer environment access and configuration. SSH key and access issues, NFS mounts and storage, quotas, security groups, container and driver questions, billing and account questions
• Runbook execution and authoring. Run the documented play when there is one. When you solve something new, write the runbook so the next person does not escalate it
• Documentation. Keep our customer-facing docs and internal knowledge base current. Most repeat tickets are a documentation gap