Technical Support Engineer GPON NOC

SasaKonnect is an Internet Service Provider (ISP) that operates 24/7, focusing on delivering reliable internet services and maintaining its network infrastructure.

Konnect operates 24×7. This role sits inside a rotating shift roster. You own the network during your shift and hand it over clean to the next engineer. Quiet shifts are not idle shifts — when nothing is on fire, you are checking dashboards, learning the network, closing loose tickets, and writing down what you have learned for the team.

1. Diagnose and resolve customer-reported faults across the access network — ONT/CPE, PON power/attenuation, VLAN, PPPoE/DHCP sessions, Wi-Fi/LAN on customer premises.
2. Use OLT/ONT tools to read optical power, alarms, and provisioning state — and interpret what the numbers mean, not just whether they're "in range."
3. Read our redundant multi-PoP topology well enough to identify failover paths when a primary uplink drops, and know who to involve to action it.
4. Actively monitor dashboards as part of normal workflow — raise regional or cluster-level issues before they generate a wave of customer calls.
5. Correlate symptoms across customers, not just within a single ticket: multiple tickets from one cluster or OLT port pointing to one upstream cause is one investigation, not many.
6. Triage multiple open tickets by impact and urgency, not FIFO — and correlate across systems (CPE, shared PON, core, or a billing/provisioning API not reflecting actual service state).
7. Work the network as one team, not as a NOC silo. Coordinate directly with Home Tech (CPE / customer-premises) and Infrastructure (outside-plant) when hands on the ground are needed. Escalate to Network Engineering with full diagnostic context — never "over to you."
8. Use AI tools (ChatGPT, Claude, internal tooling) for research, log interpretation, and quick scripts — while verifying every output against what you know about our network. Blind copy-paste is the failure mode.
9. Follow tickets through to actual resolution and close the loop with the customer. Hand over open work clearly to the next shift; do not leave loose ends.
10. Network topology reasoning. Read our redundant multi-PoP design well enough to identify alternate paths when an uplink drops — not just report "link down."
11. Pattern recognition across tickets. Four reboots in one cluster is not four tickets; it's one upstream investigation (DHCP pool, switch, OLT, routing). Treating them as four is the single most expensive mistake in this role.
12. Genuine multitasking under volume. Triage and context-switch across several open issues at different stages — not one-ticket-at-a-time while the queue stacks.
13. Proactive monitoring, not reactive. Dashboards reach you before the tenth customer call. You act on what they show.
14. Automation instinct. Fifth time doing the same diagnostic manually, your reflex is "I could script this" — and you either do, or flag it.
15. Personal knowledge base. If Network Engineering helps you solve a PoP-level issue once, you write it down well enough to handle the next one without re-escalating. We are specifically trying to reduce repeat escalations.
16. AI tool judgement. Use AI as a working tool and verify every output against our specific environment. Blind acceptance is not acceptable, and we test the difference directly.
17. Ownership, not shift-clocking. Every minute of downtime costs revenue and customer trust. You follow serious issues to actual resolution, not to end-of-shift handoff.

1. TCP/IP fundamentals — IP/subnetting, DNS, DHCP, NAT, reading a traceroute or packet capture to find a problem, not just define the term.
2. Genuine Linux terminal comfort — navigate, manage processes (pm2/systemd), tail logs, use ping/traceroute/mtr/dig/curl/ss without being walked through each command. We test this directly.
3. A web/application layer mental model — distinguish "network path broken" from "network fine but service returned an error" (read HTTP codes correctly). A customer-visible error may originate from a service two hops from the network layer; don't treat the backend as a black box.
4. Practical GPON understanding — OLT/ONT relationship, optical power budgets, splitter ratios. Strong self-study from a different access tech (wireless/microwave, DSL) is acceptable.
5. 1–3 years in ISP technical support, NOC, or telecom field/operations. Equivalent self-taught depth with strong assessment performance beats title-only experience.
6. Willingness to work rotating shifts including nights, weekends, and public holidays. Non-negotiable.