[Hiring] Technical Support Engineer @Attain

Role Description

We build and run an occupancy sensing platform that gets deployed inside enterprise client environments. That means our software lives on someone else's network — inside their VLANs, behind their firewalls, talking to their wireless controllers and switches.

When something breaks, the problem could be anywhere: the network config, the 802.1X authentication, the containerised services, the database, or our own code. The job is to figure out which layer it's in, fix what you can, and involve engineering when it needs to go deeper.

The honest version: you don't need to be a deep expert coming in. The previous person in this role built their specialisation on the job. What you do need is a solid enough foundation in networking and Linux that you can get up to speed quickly and work through unfamiliar problems without getting stuck.

Team

• Occupancy & IoT Platform — Client Delivery

Location

• Remote

Start

• As soon as possible

Environment

• Enterprise networks
• Cisco infrastructure
• Linux / Docker / Kubernetes

What You'll Be Doing

• Troubleshooting connectivity issues between our sensors and backend systems — this means reading routing tables, checking ARP and CAM tables, and tracing packets across VLANs
• Working with client IT teams on 802.1X authentication setups — certificates, Cisco ISE policy, RADIUS flows, and why a device isn't getting onto the network it should be
• Investigating WLAN issues — access point associations, SSID configuration, wireless LAN controller settings, and RSSI or connectivity problems affecting sensor communication
• Pulling and interpreting SNMP data from managed switches and wireless controllers to diagnose device and network health
• Debugging infrastructure issues on the platform side — inspecting container logs, checking service health in Docker and Kubernetes, running database queries to understand what the data is telling you
• Remote access and diagnosis via SSH — a lot of the operational work happens this way
• Writing up what you find and building runbooks so the next issue like this takes less time to resolve

Networking — What We're Looking For

• IP addressing and subnetting — you can read a CIDR block, work out what's in and out of a subnet, and understand why a /24 and a /16 behave differently. Private ranges (10.x, 172.16.x, 192.168.x) should be second nature
• Routing — you can read a routing table, understand what 'via' and 'link' entries mean, and reason through why a packet is or isn't getting where it needs to go
• Switching — you understand how CAM tables work, what a VLAN is and why they exist, and how trunk ports carry tagged traffic between switches
• ARP — you know the relationship between IP and MAC addressing and can use the ARP table to diagnose link-local connectivity issues
• 802.1X — you've dealt with certificate-based network authentication in an enterprise context. You understand the EAP flow well enough to figure out where an authentication is failing
• Cisco ISE — familiarity with how ISE handles 802.1X policy is a plus, even if you haven't configured it yourself
• WLAN — access points, wireless LAN controllers, SSIDs, client association. You know the difference between an AP and a WLC and understand how a wireless client gets authenticated and onto the network
• SNMP — you know what OIDs and MIBs are, you've actually queried a managed device with SNMP, and you can interpret what you get back. SNMPv2 community strings and SNMPv3 certificate auth are both relevant here
• Cisco CMX / MSE — not required, but if you've worked with location services based on RSSI or TDOA data, that's directly useful

Systems & Infrastructure — What We're Looking For

• Linux command line — you're comfortable in a shell. File navigation, process inspection, network tools (ping, traceroute, netstat, curl, dig), log tailing — all of this should feel normal, not effortful
• SSH — remote access is the default mode for most operational work
• Docker and docker-compose — you understand what a container is, how services are defined and networked in a compose file, and how to inspect a running container or read its logs
• Kubernetes — you don't need to build clusters, but you should understand pods, services, and deployments at an operational level and know how to use kubectl to check what's happening
• Python scripts — you're not a developer, but you can run a script, read what it does, and debug a basic error without it being a whole thing
• SQL — intermediate level. You'll write queries to investigate what the platform data is showing, check whether records exist, and cross-reference things across tables
• Log inspection — you know how to find a signal in a wall of output and work backwards from an error to its cause

Useful, Not Required

• Hands-on Cisco WLC or Prime Infrastructure experience — configuring or managing wireless controllers in a multi-AP environment
• Cisco ISE administration — building or modifying 802.1X policies, not just understanding how they work
• Experience with network monitoring tools and interpreting SNMP traps or polls at scale
• Any exposure to occupancy sensing, indoor positioning, or IoT device management

Qualifications

• You've only worked on one layer — pure networking or pure Linux ops, not both
• Enterprise networking — VLANs, 802.1X, managed switches — is new to you
• You escalate before you've isolated the issue yourself
• You need a runbook to work through anything unfamiliar
• The command line is something you avoid when there's a GUI available

Additional Information

• You've debugged problems that started in the network and ended in the application, or vice versa
• You've worked inside or alongside a corporate IT environment and know how it's structured
• You narrow the problem down to a layer before asking for help
• You're comfortable starting with limited information and working towards the answer
• The terminal is where you live when you're debugging something

How to Apply

• Send us two things:
• Your CV — be specific. Tell us the types of environments you've worked in, what networking gear you've touched, and what your day-to-day debugging actually looked like
• One real example of a network or infrastructure issue you worked through. What were the symptoms, how did you narrow it down, and what did it turn out to be
• No example, no review. We need to know you can actually diagnose things — not just that you're familiar with the concepts.
• 5+ years of experience is mandatory.