Can you tell me a bit about yourself and your experience for this kind of role?
I have experience working on an IT service desk, supporting office staff with incidents and
access issues. I am used to working from a ticket system, using tools like ServiceNow, email
and Microsoft Teams, and keeping clear records of what I do. I enjoy methodical problem
solving, asking simple questions, and explaining technical issues in plain language. This
helps users feel calmer and means they can get back to work faster. I also like working with
clear processes and checklists, because it reduces mistakes and makes my work more
consistent.
For example, when a finance user could not access a key application before a deadline, I
quickly acknowledged them on Teams, asked focused questions, and updated the ticket as we
went. I used remote access, checked basic things first, then followed our knowledge base
steps to refresh their permissions, and kept them on the call while we tested. They were
back working within about 15 minutes and thanked me for keeping them calm and explaining
what was happening. In another role, I prepared laptops and phones for new starters,
following a build checklist, updating the asset inventory, and testing logins and Wi Fi.
Because of this careful approach, new starters could begin work on day one and my manager
always had accurate records of devices and who they were assigned to.
(Built from a mix of your stories.)
What would you say are your main strengths for this role?
My main strengths are calm problem solving, clear communication, and being organised with
documentation. I stay patient with users, ask simple, focused questions, and avoid guessing
before I have checked the basics. I like to write things down in tickets and knowledge notes
so that other people can understand what happened and reuse the solution. This reduces
repeated questions and makes it easier for the team to work together. I also follow
processes and checklists carefully, which helps avoid mistakes and keeps systems and records
accurate.
For example, when a finance user lost access to a key application, I kept them informed on
Teams, used remote tools to check the issue, and followed a known fix from our knowledge
base. I documented the cause and solution clearly in the ticket and spotted a pattern in
similar tickets later that day, which helped my manager raise it for a permanent fix. In
another situation, when a whole team lost access to a shared folder, I created a ServiceNow
ticket, summarised my checks for the infrastructure team, and sent regular, plain language
updates to the user. My clear notes meant the infrastructure team could act quickly without
repeating work, and colleagues later used my how to note to solve similar problems faster.
(Built from a mix of your stories.)
What is a development area or something you find difficult, and how are you working on it?
One development area for me has been avoiding assumptions when I see a familiar symptom. In
the past, when I was busy, I sometimes jumped to the quickest fix instead of doing a full
set of basic checks. This can lead to repeat tickets and frustration for the user, so I have
worked on slowing down slightly and following a simple checklist, even under pressure.
Taking a few extra minutes at the start now saves time later and reduces follow up
complaints.
For example, a user once logged a ticket about a slow laptop, and I assumed it was the same
minor issue I had seen earlier that day. I applied the usual quick fix and closed the
ticket, but an hour later they emailed to say the laptop was still slow and applications
were freezing. I apologised, reopened the ticket, and arranged a short Teams call so I could
see the problem properly. I used remote access to check disk space, running processes and
recent updates, and found a failed update that was looping. I followed our documented steps
to clear and reinstall the update, stayed on the call while we tested, and then added
detailed notes and a reminder to myself to always do basic checks before closing similar
tickets.
(Built mainly from your “something went wrong” story.)
Why are you interested in this role and working with our organisation?
I enjoy IT support roles where I can solve problems for users and make their day easier, and
this role fits that well. I like working with ticket systems, remote tools and clear
processes, and I know from experience that good support has a big impact on how smoothly
people can do their jobs. I am also motivated by environments where communication and
documentation are valued, because that matches how I like to work. This kind of role lets me
use my strengths in calm troubleshooting, clear writing, and careful record keeping, which
leads to fewer repeated issues and better service.
For example, in a previous role I helped a finance user who had lost access to a key
application just before a deadline. By responding quickly, asking focused questions, and
using our knowledge base, I got them working again within about 15 minutes and documented
the fix so others could reuse it. In another task, I prepared laptops and phones for new
starters, following a detailed checklist and keeping the asset inventory up to date. This
meant new staff could start work without delays and my manager always had accurate
information about devices, which is the kind of reliable support I would like to bring to
your organisation.
(Built from a mix of your stories.)
Can you tell me about a time when something went wrong and how you handled it?
There was a time on the service desk when I handled a slow laptop ticket too quickly and it
went wrong. I was dealing with a busy morning and assumed the issue was the same minor
problem I had seen earlier. I applied the usual quick fix and closed the ticket without
asking extra questions or checking properly. An hour later, the user emailed again to say
the laptop was still slow and now some applications were freezing, so it was clear I had not
solved the real problem.
I apologised to the user for closing it too quickly and reopened the ticket, then set up a
short Teams call so I could see the issue in more detail. Using our remote access tools, I
checked disk space, running processes, and recent updates, and found that a large background
update had failed and was repeatedly trying to install. I followed our documented steps to
clear the failed update and reinstall it, then stayed on the call while the laptop restarted
and we tested the main applications together. The user appreciated that I owned the mistake
and stayed with them until it was fixed, and my manager agreed I had handled the second
attempt well. After that, I added a note for myself and made it a habit to ask a few extra
questions and do basic checks before closing similar tickets, which reduced repeat
incidents.
(Built mainly from your “something went wrong” story.)
How do you handle stress, for example when a deadline changes or the workload increases?
When I am under stress, I focus on staying calm, breaking work into small steps, and
communicating clearly with users and colleagues. I try not to rush blindly, because that can
lead to mistakes and repeat work. Instead, I prioritise based on impact and deadlines, and I
use simple checklists so I do not forget key steps. I also keep users updated, even if the
update is just to say I am still working on it, which often reduces pressure on both
sides.
For example, when a finance user lost access to a key application with only an hour before
their deadline, they were very stressed. I replied on Teams straight away to acknowledge
them, asked simple questions, and opened their ticket so everything was recorded. I used
remote access to check basic things first, then our knowledge base to find a known
permissions issue and followed the steps to refresh their access. I kept them on the call
while we tested and explained in plain language what I was doing, which helped them stay
calm. As a result, they were back in the application within about 15 minutes and able to
meet their deadline, and I had clear notes in the ticket for the team.
(Built mainly from: Finding and fixing IT problems for
users.)
Can you tell me about a time you had to manage several tasks or deadlines at once?
I often had to manage several tasks at once on the service desk, watching ServiceNow, email
and Microsoft Teams. When this happened, I would first make sure every request had a ticket
so nothing was lost, then I would sort them by urgency and impact. I tried to deal with
quick wins fast, while also keeping an eye on more complex issues that needed coordination
with other teams. This approach helped me stay organised and reduced the chance of missing
an important deadline.
For example, one morning a user emailed to say their whole team had lost access to a shared
folder needed for a client presentation later that day. I created a ServiceNow ticket from
the email, replied to confirm I was on it, and asked for the exact folder path, while still
monitoring other tickets. After doing my own checks, I contacted the infrastructure team in
another time zone on Teams, shared the ticket number, and summarised what I had already
tried. While they investigated, I added their updates into ServiceNow and sent short, plain
language emails to the user so they knew what was happening and roughly when to expect a
fix. This meant the team regained access in time to prepare for the presentation, and other
tickets were still tracked properly in the system.
(Built mainly from: Talking clearly, writing things down, and
working with others.)
Can you tell me about a time you worked closely with someone else to get something done?
I work well with other teams when an issue needs skills or access that I do not have. My
approach is to do sensible first checks myself, then give the other team a clear summary of
the problem, what I have tried, and any error messages. I also keep the user updated so they
know we are working together on it. This makes collaboration smoother and avoids duplicated
work or repeated questions.
For example, when a whole team lost access to a shared folder before a client presentation,
I first confirmed it was not a simple permission issue I could fix. I then contacted the
infrastructure team on Microsoft Teams, shared the ServiceNow ticket number, and clearly
summarised the problem and my checks. While they investigated, I added their questions and
updates into the ticket and sent short, plain language updates to the user about progress.
The infrastructure team said my notes made it easier for them to pick up the issue without
repeating questions. The user’s team regained access in time, and later two colleagues used
the how to note I wrote from this case to handle similar issues more quickly.
(Built mainly from: Talking clearly, writing things down, and
working with others.)
Can you give an example of how you learnt a new system or process and became confident using
it?
When I learn a new system or process, I like to break it into small steps, follow any
existing guides, and then write my own simple notes. I usually start with the most common
tasks, repeat them a few times, and check my understanding with a colleague or manager.
Writing things down in clear language helps me remember and also helps others later. Over
time, this means I can work more independently and make fewer mistakes.
For example, when I was responsible for preparing laptops and mobiles for new starters, I
had to learn our build process and asset tracking systems. I used the build checklist step
by step, installing the standard image, applying updates, encrypting the drive, and
enrolling the phone in our mobile management tools. I tested logins, email and Wi Fi, and
wrote key configuration details into the ServiceNow ticket, as well as a simple handover
sheet with device names and instructions. By repeating this process and keeping the
inventory accurate with correct serial numbers, I became confident and consistent. New
starters could log in and start work without delays, and later device moves were
straightforward because the records were already complete.
(Built mainly from: Looking after devices and keeping track of
them.)
Can you tell me about a time you disagreed with a colleague or stakeholder, and how you
resolved it?
I try to handle disagreements by focusing on facts, impact on the user, and clear
communication, rather than on who is right. If I see something that could be improved, I
raise it calmly with evidence from tickets or patterns I have noticed. This helps turn a
disagreement into a joint problem to solve. It usually leads to better processes and fewer
issues for users.
For example, after helping a finance user who lost access to a key application, I noticed
two more similar tickets later that day. Instead of just fixing each one separately, I
emailed my manager with the ticket numbers and a short summary of the pattern. This could
have been seen as questioning the application owners, but I kept the focus on the repeated
permissions issue and the impact on users with deadlines. My manager used this information
to raise the pattern with the application owners, which led to a more permanent fix. As a
result, we reduced repeat incidents for that application and made things smoother for both
users and the support team.
(Built mainly from: Finding and fixing IT problems for
users.)