Not just what I have done — but how and why I do it. Real answers to real interview questions.
How do you handle situations where different teams see the same problem differently?
I bring people into the process early. Different teams often see
different parts of the same problem, so I spend time
understanding each perspective before proposing a solution.
Most disagreements aren't really disagreements. They're usually the result of
people working with different information or different priorities.
Once everyone can see the bigger picture, it's much easier to agree on a way forward.
I've found that showing people why something will or won't work
is far more effective than simply telling them. When people understand the reasoning,
they're more likely to support the solution and help improve it.
Walk me through how you approach a problem you have never seen before.
I start by understanding the problem before thinking about solutions. First I ask what is actually happening? Then I compare that to what people expect to be happening. That gap usually tells me where to start looking.
From there I break the problem into smaller pieces and gather as much information as I can. Sometimes the issue is technical, sometimes it's a process problem, and sometimes it's simply missing information. The goal is to find the root cause rather than treating the symptoms.
If I've solved something similar before, I'll use that experience as a starting point. If not, I'll research, test a few ideas, and build up from a small proof of concept. Once I know the approach works, I can develop it further and document it so others can understand and maintain it.
Tell me about a time you identified a problem nobody else had noticed.
At EDGE Education, there was very little visibility into production costs and timelines. Teams were making resourcing and pricing decisions using the information they had available, but the data needed to measure costs accurately simply wasn't being collected.
I identified the gap, redesigned parts of the Jira workflow to capture the missing information, and built the reporting needed to turn that data into something useful. Finance and the PMO were then able to see reliable cost and timing information at title level for the first time.
The impact of that work eventually led to the creation of my current Operational Systems, Data & Automation Lead role.
How do you get buy-in from people who are resistant to change?
I try to understand their concerns before I try to change their mind. Most people aren't resistant to change for the sake of it - they're worried about how it will affect their work, their team, or the things they're responsible for. So I ask questions, listen carefully, and make sure those concerns are considered in the solution.
I've found that people are far more open to change when they understand why it's needed and how it will help them. When that's not enough, I focus on the facts and show the impact of the current process, so the discussion becomes about solving a problem rather than defending a position.
Describe your approach to leading a team through a high-pressure delivery.
Under pressure, I focus on keeping things clear and organised. The first step is understanding what absolutely needs to be delivered, what can wait, and where the biggest risks are. I make sure priorities are clear so the team can focus on the work instead of trying to guess what matters most.
I communicate regularly, check for blockers, and help remove anything that is slowing progress down. Keeping people informed is just as important as solving technical problems during a high-pressure delivery.
Once the work is complete, I review what went well and what didn't. Tight deadlines often expose weaknesses in a process, and those lessons are worth capturing before the next project starts.
How do you decide what to automate and what to leave manual?
My rule of thumb: if I do it twice, I think about scripting it. If I do it ten times, I script it. But before automating anything, I make sure I understand the process properly. There's no point automating a process that isn't working the way it should.
I also consider how much time the automation will save compared to the effort required to build and maintain it. Sometimes a manual process is perfectly acceptable. The goal is to reduce repetitive work so people can spend more time solving problems and making decisions.
How do you ensure data accuracy in the systems you build?
I think about data accuracy from the moment a system is designed. I make sure important information is captured consistently and that the path from source data to final report is easy to follow. If a number looks wrong, I want to be able to trace where it came from and understand why.
I also build validation into the process wherever possible. That can include comparing counts between systems, checking totals against expected values, and testing results using known examples. The earlier an issue is identified, the easier it is to fix.
Where appropriate, I version queries, reports and schemas so changes can be tracked over time and unexpected results can be investigated quickly.
How do you use AI in your day-to-day work?
I use AI as a tool to help me work faster and explore ideas more efficiently. It's particularly useful for research, troubleshooting, code generation and reviewing different approaches to a problem. I also use it to help draft documentation, validate logic and learn unfamiliar technologies more quickly.
That said, I still verify everything before using it. I don't share sensitive information, and I don't rely on AI-generated output without understanding how it works. AI helps me move faster, but the responsibility for the final result still sits with me.
Are you worried AI will replace your role?
Not really. A large part of my role is understanding how people, processes and systems fit together. The technical work is important, but so is understanding the problem, asking the right questions and making practical decisions. Those are areas where human experience and context still matter.
AI has definitely changed how I work. Tasks that once took hours can often be completed much faster, which means I can spend more time on analysis, problem-solving and improving the overall solution. Rather than replacing my role, I see it as another tool that helps me do it more effectively.