DTEX SRE APAC — Culture Screening Prep

My core positioning

I’m at my best when I can own a problem end to end: understand the operational pain, stabilise what is urgent, and then turn repeated work into automation or a better system. I like small-team environments because ownership is clearer and the impact is easier to see.

My “fun work” story

The definition of fun work has changed through my career.

In the first phase, fun meant going deep technically — Linux, virtualisation, bare metal and infrastructure fundamentals. That gave me depth. In the second phase, fun became working across complex systems — observability, CI/CD, incident management and platform engineering. That widened my understanding of how the whole delivery system works. In the last few years, fun has become more about impact: running internal engagement, uplifting other teams, and turning BAU pain into automation or good-enough systems that improve velocity.

So for me, fun does not only mean shiny new projects. Fun means useful work where I can own the problem and make the system better.

Tell me about yourself

I’m a Senior Platform engineer with 13 years of experience across platform engineering and incident management. My career pattern has been turning manual or complex operational environments into more reliable, automated platforms. Recently I’ve also been applying AI to daily workflows through agentic tooling, K8sGPT and AI-assisted support. I’m interested in DTEX because it sounds like a small team with real ownership, autonomy and meaningful work.

Why are you open to a move?

My role has been changed since I joined; I’m looking for more ownership and delivering impact. I like environments where I can operate independently, help shape the way things work, and improve systems rather than just maintain a narrow slice.

Why DTEX?

DTEX stands out to me because I’ve been following the security space for a while, and I’m especially interested in user behavior analytics done in a privacy-conscious way. I also think I can bring strong value through my end-to-end platform engineering background. Beyond the technical fit, the role feels culturally aligned with how I work and what motivates me.

What does your current day-to-day look like?

My day is usually split between collaboration and hands-on engineering. I spend around one to two hours for a mix of customer context, platform implementation and building relationships. The rest of the time is hands-on: checking GitHub issues, coding, reviewing PRs, troubleshooting, and improving automation or delivery flow.

Are you comfortable coming into the office?

Yes. Flexible timing would be helpful, but the office expectation itself is not a concern.

How do you handle shifting priorities and last-minute changes?

I’m used to that. In previous roles I’ve spent years balancing incidents, shifting priorities and requests from multiple teams while still protecting focus for longer-term reliability work. I try to avoid silent context switching. If priorities change, I make that visible so stakeholders understand what is being delayed and why. That keeps the team calm and avoids accidental surprises.

What are you doing with AI in your current role?

I’m using AI practically. One pattern I use is breaking work into deterministic and non-deterministic steps, then allowing a harness agent — currently Claude Code — to act within predefined rules and boundaries. At Viator, I also introduced K8sGPT with custom prompts for SRE troubleshooting and built an AI Slack bot for internal support. So this is an area I’ve already applied in real operational workflows.

Will BAU and firefighting bore you?

For me, BAU is only boring if nothing improves. I usually treat BAU as a signal. If the same task or incident keeps coming back, that is a chance to automate it, document it, add observability, or simplify the system.

How do you operate independently?

I usually start by making the problem smaller and clearer. I identify what we know, what we do not know, what the risk is, and what decision is needed next. If the direction is ambiguous, I do not wait passively. I’ll propose a small next step, make my assumptions visible, and keep progress moving. In a small SRE team, I think that matters. You need people who can move without needing every detail specified upfront, but who also communicate enough that the rest of the team is not surprised.

How do you communicate in a small team?

I’m comfortable owning work independently, but I do not like disappearing into a corner. I try to make my work visible enough that people trust where things are going. I prefer simple, explicit communication.

What kind of manager or team environment works well for you?

I work well in teams where expectations are clear, communication is direct, and people are trusted to own outcomes. I do value alignment — especially around priority, risk and customer impact.

What is your approach to incidents?

During an incident, I focus on staying calm, reducing uncertainty and restoring service. I want clear roles, clear communication and short feedback loops. Afterward, I care about the learning: what signal did we miss, what process was unclear, and what can we automate or improve so the same issue is easier or gone next time.

Good stories to keep ready

Do not lead with these unless asked. Use them as short examples.

Story A — AI for SRE

“At Viator, the SRE team spent a lot of time gathering evidence and answering repeated internal support questions. I introduced K8sGPT with custom prompts for troubleshooting and built an AI Slack bot connected to the internal knowledge base. The result was faster evidence gathering and a 50% reduction in first-response time for internal support.”

Story B — Platform ownership at Domain

“At Domain, we had a large platform migration from ECS to Kubernetes supporting more than 100 microservices. I designed and built the Kubernetes platform, reusable Terraform modules and GitOps workflows so product teams could deploy independently. That work improved reliability and also reduced friction for more than 20 teams.”

Story C — Observability and incident improvement at Envato

“At Envato, observability cost and alert quality were problems. I helped migrate from New Relic to Datadog, improved alerting and integrated PagerDuty workflows. That reduced observability cost and improved incident resolution time.”

Story D — Incident process at Avinet

“At Avinet, I helped establish incident management and disaster recovery processes from scratch. That reduced MTTR significantly and gave the team a clearer way to respond under pressure.”

Questions to ask Andre

Best questions “What does success look like for this person in the first three to six months?” “Because the Adelaide SRE team is still small, where do you most need ownership immediately?” “What are the biggest sources of operational noise or toil today?” “How are you thinking about AI-assisted SRE workflows? Are you already using agents internally, or is that something you want this role to help shape?” “How do you like the team to communicate when priorities change quickly or incidents happen?”

Final 30-second close

What interests me about this role is the combination of small-team ownership, reliability work, security context and AI. I’ve spent my career improving operational systems — from Linux and infrastructure foundations through to Kubernetes platforms, observability and incident management. I’m comfortable with ambiguity, BAU and urgent work, but I enjoyed more and excited about turning those things into better systems over time. That is why this DTEX role feels like a strong fit.