Interview Battlecards

Interview Battlecards — DevOps / Platform Engineering Contracts

Kevin Ryan — February 2026

MINDSET

Detach from the outcome. Attach to the performance.

You don’t need any single role. There are hundreds of DevOps contracts. That’s your advantage — use it. Desperation is visible on camera. Calm confidence isn’t something you fake. It comes from knowing you have options. You do.

But detachment isn’t passivity. Every interview, show up like you want this one. Not like you need it — like you’ve chosen it. There’s a difference between “I don’t need this” and “I want this.” The second one wins rooms.

The first 90 seconds decide everything. Before you click join — stand up, move around, get your energy up. Smile before the camera turns on. The interviewer decides in the first minute whether they like you. Everything after that is confirmation bias in one direction or the other. Your job is to make sure it’s the right direction.

Discomfort is the strategy. You could make three calls and land something through your network by Friday. You’re deliberately choosing the cold path — new people, new conversations, expanding the network rather than activating it. That’s a muscle most senior people never build. Build it now.

Every interview is a rehearsal for the next. The first one will be the roughest. By the fifth you’ll own the room. After every conversation, debrief: what did they ask, what landed, what didn’t. Add it to this document. The battlecards get sharper with every rep. There is no failure — only data.

Close every interview. Don’t let it drift to “well, thanks for your time.” End with: “I’m keen on this. Is there anything about my experience that gives you concern? I’d rather address it now.” That one question changes everything. You’re not waiting for a verdict. You’re handling objections live, like a professional. Most candidates don’t do this. You will.

No ego. No stress. All signal.

PART 1: THE NARRATIVE

”Why are you going for a DevOps Engineer contract rather than a Head of / Principal role?”

This question is coming. Every time. Have one answer, rehearsed, natural, under 30 seconds.

The answer (pick the version that fits you best):

Version A — The craftsman:

I spent the last decade building practices, winning accounts, running programmes. I'm good at it. But I'm at my best when I'm hands-on — pipelines, infrastructure, architecture. That's what I love doing, and that's where I add the most value on day one. I don't need a ramp-up period. I can be productive by Tuesday.

Version B — The honest one:

I've done the 16-hour days running enterprise programmes. I've got two young kids and I'd rather do excellent technical work in sensible hours than run another portfolio. The scope is clearer, the hours are saner, and I'm a better engineer for it. Plus it gives me headspace to write — I've got two books in progress.

Version C — The strategic one:

I've been on both sides — running programmes and doing the engineering. What I've noticed is that the best DevOps engineers are the ones who understand the delivery context. I bring that. But I'm not looking to run your programme — I'm looking to make your pipelines work. That's a different job and it's the one I want.

What NOT to say:

• Anything that sounds like you couldn’t get a senior role
• Anything about money pressure or urgency
• Anything about being tired or burned out (even if true)
• “I’m overqualified but…” — never say overqualified

If they push (“but your CV shows Head of DevOps EMEA…”):

That's right. I built two practices from scratch at Cprime and ran enterprise programmes at Nestlé, Dematic, CERN. I know what good delivery looks like from the top. But I've chosen to go back to the tools. The industry's shifting to AI-native engineering and I want to be building, not managing builders. That's a deliberate choice, not a step down.

PART 2: QUESTIONS YOU ASK THEM

These signal expertise. Ask them early — don’t wait for “do you have any questions for us?” at the end. Weave them into the conversation.

Development Environment & Workflow

What's the version control setup — GitHub, GitLab, Azure Repos?

Why you ask: shows you know these are different ecosystems with different CI/CD patterns.

Is the dev environment containerised? Codespaces, Gitpod, devcontainers?

Why you ask: signals you work at a level where reproducible dev environments matter. Most contractors never ask this.

What's the branching strategy? Trunk-based, GitFlow, something custom?

Why you ask: branching strategy tells you everything about their maturity. Trunk-based = modern. GitFlow = legacy. Custom = pain.

AI & Governance

What's the enterprise policy on generative AI tooling? Copilot, Cursor, ChatGPT — approved, restricted, or banned?

Why you ask: this is a killer question. It signals you’re already using AI in your workflow and you understand governance. If they say “we haven’t figured that out yet” — that’s an opportunity for you.

Is there an approved AI tooling list, or is it team-by-team?

Follow-up if they say it’s allowed.

Tech Stack & Architecture

What's the target architecture — microservices, monolith, something in between?

What's the infrastructure provisioning story? Terraform, Bicep, ARM templates, Pulumi?

Where are you on the containerisation journey — everything in Kubernetes, some legacy VMs, hybrid?

What CI/CD platform are you on and what does a typical pipeline look like? Build, test, security scanning, deployment stages?

What's the observability stack — Azure Monitor, Grafana, Datadog, something else?

How are secrets managed — Azure Key Vault, HashiCorp Vault, something else?

Delivery & Team

How big is the engineering team I'd be working with?

What does a typical sprint or delivery cycle look like?

Is there a platform team, or is DevOps embedded in feature teams?

What's the biggest pain point right now — pipeline reliability, deployment frequency, environment provisioning, something else?

This is the best question you can ask. Their answer tells you exactly what they need and lets you map your experience to their problem in real time.

Contract Specifics

What does success look like at the end of three months?

Forces them to articulate the outcome. Also protects you from scope creep.

Is there appetite to extend beyond three months if the work's going well?

Who do I report to day-to-day — a tech lead, engineering manager, CTO?

PART 3: TECHNICAL BATTLECARDS

For each topic, your answer structure is: state the principle → give a specific example from your experience → keep it under 60 seconds.

Azure

“Talk me through your Azure experience.”

My primary cloud. At Nestlé, ran a global DevOps platform on AKS — thousands of developers, three continents. At Dematic, built the CI/CD platform on Azure — GitLab integrated with Azure services. Most recent engagement was a full cloud migration — legacy .NET/C# on-prem to Azure, containerised, MSSQL to Azure SQL SaaS. Comfortable with AKS, App Services, Azure DevOps, Blob Storage, Key Vault, Bicep templates, and Azure Monitor.

“AKS or plain Docker? When would you choose which?”

AKS for anything that needs scaling, self-healing, or multi-service orchestration. App Services or Azure Container Instances for simpler workloads — single containers, internal tools, batch jobs. Don't put everything in Kubernetes. The overhead isn't worth it for a simple API.

“How do you handle Terraform state in Azure?”

Remote state in Azure Blob Storage with state locking via Azure Storage lease. Separate state files per environment — dev, staging, prod. State never in version control. Access controlled via Azure RBAC and managed identity where possible, service principal where not.

CI/CD Pipelines

“Describe a CI/CD pipeline you’ve built.”

Dematic — GitLab CI. Build stage compiles and tests. SAST scanning via GitLab security templates. Docker image built, tagged with commit SHA and semantic version. Pushed to container registry. Helm chart updated. Deployed to dev automatically, staging on merge to main, prod on manual approval. Reduced their simulation turnaround from 11 hours to 24 minutes — 98% reduction.

“How do you handle pipeline failures?”

First: make failures visible. Notifications to Slack or Teams on failure, not success — don't train people to ignore notifications. Second: make failures fast. Fail on lint and unit tests before you get to integration. Third: make failures reproducible. If I can't run the failing step locally, the pipeline is broken by design.

“How do you manage pipeline templates across multiple teams?”

At Dematic, I built reusable CI/CD templates — shared GitLab CI includes that teams consumed. Versioned. Teams pull a specific version, not latest. Breaking changes go through a deprecation cycle. Same principle works with GitHub Actions reusable workflows or Azure DevOps task groups.

Kubernetes

“How would you debug a pod that’s stuck in CrashLoopBackOff?”

kubectl describe pod — check events. Then kubectl logs — check previous container logs with --previous flag. Common causes: app crash on startup (missing config or secret), OOM kill (check resource limits), failed health check (liveness probe too aggressive). Nine times out of ten it's a missing environment variable or a secret that wasn't mounted.

“How do you manage Kubernetes configuration across environments?”

Helm with values files per environment. Base chart stays the same, values-dev.yaml, values-staging.yaml, values-prod.yaml override what needs to change — replicas, resource limits, ingress hosts, feature flags. Sensitive values from Key Vault via CSI driver, not baked into Helm values.

“What’s your approach to Kubernetes RBAC?”

Least privilege. Namespace-scoped roles, not cluster-wide. Developers get read access to their namespace, deploy access via CI/CD service account only. No kubectl apply in production by humans. Pipeline does the deployment, humans approve the gate.

Terraform

“How do you structure a Terraform project?”

Modules for reusable components — network, compute, storage. Environment-specific tfvars files. Remote state per environment. I keep the module repo separate from the environment repo — modules are versioned and consumed like libraries. Avoids the monolith problem where one change risks everything.

“How do you handle drift?”

Terraform plan on a schedule — daily or on PR. If plan shows drift, investigate before applying. Drift usually means someone made a manual change in the portal. Fix the process, not just the state. In regulated environments I've added plan output to pull request comments so reviewers can see infrastructure changes alongside code changes.

“State locking — why and how?”

Prevents two people or pipelines from writing state simultaneously. Corrupted state is one of the worst things that can happen in Terraform. Azure Blob Storage handles locking natively via storage lease. DynamoDB table for AWS. Never skip this.

GitHub / Git

“You have 4 GitHub certifications. What’s your GitHub Actions approach?”

Reusable workflows for common patterns — build, test, scan, deploy. Composite actions for smaller shared steps. Self-hosted runners when we need specific tooling or network access. Matrix builds for multi-platform or multi-version testing. Branch protection rules enforcing status checks before merge. I've also set up GitHub Advanced Security — Dependabot, code scanning, secret scanning — across enterprise orgs.

“Monorepo or multi-repo?”

Depends on team structure and dependency patterns. Monorepo if teams share a lot of code and need atomic changes across services. Multi-repo if teams are autonomous and services are independently deployable. Most enterprises I've worked with end up with a hybrid — a handful of monorepos per domain, not one giant repo and not 500 tiny ones.

C# / .NET / React (for this specific role)

“The role mentions C# and React — how comfortable are you supporting those builds?”

My last engagement was exactly this — migrating a legacy .NET/C# application to React frontend, containerised, Azure-hosted, MSSQL moved to Azure SQL SaaS. So I've recently built and maintained the CI/CD pipelines for both stacks. I'm not writing production C# or React — but I can read the code, debug build failures, manage NuGet and npm dependencies, and configure the pipeline stages for both. That's what this role needs.

DORA Metrics & SRE

“How do you measure DevOps success?”

DORA metrics: deployment frequency, lead time for changes, change failure rate, mean time to recovery. Not because they're fashionable — because they measure flow. At Dematic, deployment frequency went from manual releases every few weeks to multiple deploys per day. Change failure rate dropped because we added automated testing gates. I track these from day one on any engagement.

Security & Governance

“How do you bake security into the pipeline?”

Shift left. SAST in the build stage — SonarQube, Semgrep, or GitLab SAST templates. Dependency scanning for known CVEs. Container image scanning before push to registry. Secret scanning on every commit. At Nestlé I implemented Terraform IaC governance — policy-as-code to prevent non-compliant infrastructure from being provisioned. Security isn't a stage at the end. It's a quality gate at every stage.

PART 4: STORIES — STAR FORMAT BANK

Have these ready. Each one maps to a common behavioural question.

”Tell me about a time you solved a difficult technical problem.”

Dematic. Simulation workloads taking 11 hours. Investigated the pipeline — found serial execution where parallel was possible, unnecessary full rebuilds, no caching. Redesigned the pipeline architecture. Got it to 24 minutes. 98% reduction. Client extended the contract indefinitely.

”Tell me about a time you had to work with a difficult stakeholder.”

Nestlé. Global platform, three continents, multiple teams with different priorities. India team wanted speed, Spain team wanted governance, UK team wanted autonomy. Wrote the SRE playbooks as the common ground — everyone follows the same runbooks, everyone gets the same platform. Playbooks became the contract between teams.

”Tell me about a time you had to deliver under pressure.”

Dematic. Won the engagement, first on the ground. No team, no infrastructure, no CI/CD. Built the delivery team, established the platform, and had pipelines running inside the first sprint. Short engagement became a long-term partnership because we delivered from week one.

”Tell me about a time something went wrong.”

Be honest. Pick a real one. Pipeline broke in production, missed a config change, underestimated a migration. The structure is: what happened → what I did → what I learned → what I changed so it wouldn’t happen again. The “what I changed” is the part they care about.

PART 5: PRE-INTERVIEW CHECKLIST

24 hours before:

• Research the client (not just the recruiter). Company size, tech blog, GitHub org, job postings for adjacent roles — these tell you the real tech stack.
• Check LinkedIn for the interviewer. What’s their background? Adjust your language accordingly — CTO gets architecture talk, team lead gets pipeline specifics.
• Prepare 3 questions from Part 2 that are specific to this company.
• Test camera, mic, background. Clean desk, good lighting, no distractions.

During the interview:

• Lead with what you’ve done, not what you know.
• Numbers beat adjectives. “98% reduction” beats “significantly improved.”
• Ask your questions throughout, not just at the end.
• If you don’t know something, say so. “I haven’t used that specific tool, but here’s how I’d approach it” is always better than bluffing.
• Close with: “Is there anything about my experience that gives you concern? I’d rather address it now.”

After the interview:

• Send a short follow-up email to the recruiter within 2 hours. One line: “Thanks for the intro. Interview went well. I’m keen. Let me know next steps.”