IT support engineer to FDE: tickets, scripts and client calls

Myth: "Support is not real technical work, so I am starting from zero"

Evidence says otherwise, if you look at what you actually produce each week. Look at your own work and list the artefacts:

• Incident tickets in ServiceNow, Jira Service Management or Freshservice, each with a category, a priority, timestamps and a resolution note.
• SLA reports that show response and resolution time against P1–P4 targets.
• Knowledge base articles and runbooks you or your team wrote ("Outlook profile corruption: rebuild steps").
• Asset inventory exports: laptop tags, OS builds, assigned users.
• Scripts in PowerShell or batch that map drives, clear caches or push a registry setting.

FDE work involves the same kinds of objects at a different layer. A client's AI workflow breaks, you reproduce it, you find whether the cause is data, permissions, configuration or code, you fix it, and you write down what happened. The difference is that the fix is usually code you wrote and must test, not a setting you toggled.

Myth: "I should start with a chatbot project to show I know AI"

A generic chatbot says nothing about you. A better first project is one only a support engineer would think of: find out which repeat incidents cost the most SLA time, and which assets keep coming back. That is the diagnosis a forward deployed engineer does before proposing any automation.

The script below uses synthetic tickets. It computes resolution hours, flags SLA breaches by priority, and finds assets that raised the same category of ticket more than once.

import csv
import io
from collections import Counter, defaultdict
from datetime import datetime

# Synthetic ticket export (hypothetical data, not from any real service desk)
raw = """ticket_id,opened,resolved,category,priority,asset
INC1001,2026-09-01 09:10,2026-09-01 10:05,vpn,P3,LT-221
INC1002,2026-09-01 09:40,2026-09-02 14:00,outlook,P3,LT-305
INC1003,2026-09-02 11:00,2026-09-02 13:30,vpn,P2,LT-221
INC1004,2026-09-03 08:15,2026-09-03 17:45,printer,P3,PR-014
INC1005,2026-09-03 10:00,2026-09-03 19:30,vpn,P2,LT-118
INC1006,2026-09-04 09:05,2026-09-05 12:00,outlook,P3,LT-305
INC1007,2026-09-05 15:20,2026-09-05 16:10,vpn,P3,LT-221
INC1008,2026-09-06 09:00,2026-09-06 14:30,access,P1,SRV-02
"""

SLA_HOURS = {"P1": 4, "P2": 8, "P3": 24}
fmt = "%Y-%m-%d %H:%M"

rows = list(csv.DictReader(io.StringIO(raw)))
breaches = []
hours_by_cat = defaultdict(float)
repeat = Counter()

for r in rows:
    hrs = (datetime.strptime(r["resolved"], fmt) - datetime.strptime(r["opened"], fmt)).total_seconds() / 3600
    hours_by_cat[r["category"]] += hrs
    repeat[(r["asset"], r["category"])] += 1
    if hrs > SLA_HOURS[r["priority"]]:
        breaches.append((r["ticket_id"], r["priority"], round(hrs, 1)))

print("SLA breaches:", breaches)
print("Hours by category:", {k: round(v, 1) for k, v in sorted(hours_by_cat.items(), key=lambda x: -x[1])})
print("Repeat asset+category:", [k for k, n in repeat.items() if n > 1])

assert [b[0] for b in breaches] == ["INC1002", "INC1005", "INC1006", "INC1008"]
assert repeat[("LT-221", "vpn")] == 3
assert repeat[("LT-305", "outlook")] == 2

Output: four breaches (two Outlook tickets over 24 hours, one P2 VPN ticket over 8, and the P1 access ticket over 4), Outlook as the largest consumer of hours, laptop LT-221 raising three VPN tickets in five days, and LT-305 raising both of the slow Outlook tickets. In a write-up you would then argue what to do: LT-221 needs a root-cause fix, not a fourth reset, and the Outlook pattern might be worth a guided self-service flow. Only after that would you propose an AI assistant, and you would say how you will measure whether it cuts repeat tickets.

Myth: "Talking to users is a soft skill that FDE hiring ignores"

It is the other way round. Forward deployed roles put engineers in front of client teams, so interviewers look for someone who can take a vague complaint ("the system is slow") and turn it into a reproducible case. You have done this hundreds of times on calls. What you need is to show it in writing: an incident summary with timeline, cause, fix and prevention, the same structure you would give a client.

The real gap for a support engineer

Be honest with yourself about three things:

Plan to spend most of your learning time on Python, SQL and API work. The FDE for Freshers programme at /courses/fde is designed for people without a software engineering background, and the FDE hub explains the role itself.

Implementation or solutions engineer before FDE

A sensible first target is a role that still values your support instincts while making you write code daily: implementation engineer, solutions engineer (junior), technical support engineer on a software product with a scripting component, or an associate FDE role where one exists. Moving from L2 support into an implementation or integration team at a software company is a smaller jump than a straight move into an AI team, and it builds exactly the delivery record FDE interviewers ask about.

Turning ticket history into your interview story

Interviewers will want to know why you are leaving a stable track and whether you understand what you are moving into. A sample answer:

"My last role was L2 support for roughly six hundred users. What I enjoyed most was the part after the fix: finding out why the same laptops kept failing VPN, and writing the runbook so it stopped reaching us. I started automating that with PowerShell, then realised I wanted to build the software, not only support it. Over the last months I rebuilt my ticket analysis in Python with tests, learned SQL properly, and wrapped it in a small API. I know I am junior as an engineer. What I bring is that I have already sat with frustrated users and turned a vague complaint into a fix, which is most of what a deployment looks like from the client's side."

Before you apply, paste your resume into the free skill check; if it cannot find a single script or repository in your evidence, fix that first.