kiwi Platform Engineer Interview: Questions, Experience & Prep (2026)

Kiwi currently has 3 open Platform Engineer roles (data: knok jobradar, 2026-07-08). Platform Engineers at kiwi are typically responsible for the internal developer platform, CI/CD infrastructure, Kubernetes clusters, and cloud tooling that lets product teams ship faster and more reliably. Candidates report a process that usually includes a recruiter screen, a technical round covering systems and coding, one or more design discussions, and a final conversation with a hiring manager. The exact number of rounds can vary, so treat this as a typical pattern.

Across all companies in the knok jobradar snapshot, 204 Platform Engineer roles were open on that date, with Bangalore leading at 29 openings, followed by Delhi (12), Pune (10), Hyderabad (5), Chennai (2), and Mumbai (1). Kiwi's 3 roles represent a focused but active hiring push for this function.

Technical and system design questions

1. Walk us through how you have designed or improved a CI/CD pipeline at scale.
2. How do you approach Kubernetes cluster management and capacity planning for a fast-growing product?
3. Describe your hands-on experience with infrastructure-as-code tools such as Terraform or Pulumi.
4. How do you implement observability (metrics, logs, and traces) for a distributed system?
5. What is your approach to secrets management and access control in a cloud environment?
6. How would you design a self-service developer platform so teams can provision environments on demand?
7. Describe your experience with multi-cloud or hybrid-cloud setups and the trade-offs involved.

Behavioural and situational questions

1. Tell us about a time you handled an on-call incident where a platform outage affected multiple product teams.
2. Describe a time you reduced infrastructure costs while keeping reliability intact.
3. How do you evaluate and introduce new tooling to a team that is resistant to change?
4. How do you balance developer experience against security and compliance requirements?
5. Describe how you handle breaking changes or dependency upgrades in shared platform components.

Q: Walk us through how you designed or improved a CI/CD pipeline at scale.

*Situation:* Our engineering team's monorepo builds had grown slow, causing deployments to queue up and developers losing focus while waiting for feedback.

*Task:* I was asked to redesign the pipeline so teams could ship faster without reducing test coverage or reliability.

*Action:* I introduced remote build caching with a distributed cache layer, split the pipeline into parallel stages along service boundaries, and migrated from a legacy Jenkins setup to GitHub Actions. I also added incremental test selection so only tests relevant to a changed diff would execute.

*Result:* Feedback loop times improved considerably, which the platform team tracked and confirmed in the next quarterly review. Developers reported higher confidence in the pipeline's reliability.

---

Q: Tell us about a time you handled an on-call incident where a platform outage affected multiple teams.

*Situation:* A misconfigured Kubernetes admission webhook started rejecting all pod scheduling requests across our staging and production clusters simultaneously during a peak deploy window.

*Task:* As the on-call platform engineer, I needed to restore service quickly and prevent the same issue from recurring.

*Action:* I identified the failing webhook within minutes using cluster event logs, disabled it as a temporary mitigation, and coordinated a hotfix with the security team who owned the webhook config. I then added a pre-deployment validation step to our IaC pipeline to catch webhook misconfigurations before they reach the cluster.

*Result:* Services were restored quickly, and the same class of misconfiguration has not recurred since the guard was added.

---

Q: Describe a time you reduced infrastructure costs while maintaining reliability.

*Situation:* Our cloud spend had grown faster than headcount due to over-provisioned compute and unused resources that had accumulated over several quarters.

*Task:* I was asked to audit and reduce costs without impacting service-level targets.

*Action:* I ran a utilisation audit using cloud-native cost tools, identified idle resources and oversized node pools, and worked with product teams to right-size workloads. For stable, predictable workloads I moved to reserved capacity, and I set up automated scale-down for non-production environments outside business hours.

*Result:* Monthly cloud spend dropped noticeably over the following quarter, and the approach became a standard quarterly review process. Reliability metrics stayed within target throughout.

For system design questions, structure your answer in three layers: first state the goals (developer experience, reliability, security), then describe the architecture (tools, data flows, failure modes), and finally explain how you would measure success. Kiwi interviewers typically probe for trade-offs, so volunteer the downsides of your choices before they ask.

For behavioural questions, the STAR format works well: Situation (one or two sentences of context), Task (what you specifically owned), Action (concrete steps you took, not what 'the team' did), and Result (a measurable or observable outcome). Keep each STAR answer to two to three minutes when spoken aloud.

For cost or reliability questions, show that you think in terms of trade-offs rather than absolutes. Saying 'we accepted slightly higher latency in exchange for a simpler, cheaper architecture' signals maturity. Avoid framing every decision as a clear win with no downsides.

Based on what candidates report from platform engineering interviews at product companies of kiwi's profile, interviewers typically look for four qualities.

Ownership mindset. Platform engineers serve internal customers. Interviewers want to see that you treat developer productivity as your product metric, not just uptime.

Depth in at least one area. Whether that is Kubernetes internals, Terraform at scale, or observability pipelines, candidates who can go deep on one platform domain tend to perform better than those who stay at the surface across all topics.

Communication across functions. You will need to explain trade-offs to security, finance, and product teams. Interviewers often test this by asking how you handled pushback or convinced a sceptical stakeholder.

Operational discipline. Runbooks, post-mortems, automated alerts, and capacity planning come up frequently. Having concrete examples ready signals that you build for the long term, not just for the demo.

Week 1: core platform concepts

Review Kubernetes architecture (scheduler, kubelet, etcd, admission controllers) and practise explaining how each component fails. Revisit your Terraform or Pulumi workflows and be ready to describe state management, module design, and how you handle drift.

Week 2: system design practice

Practise designing a self-service developer platform from scratch. Cover the golden path (code commit to production deploy), secrets management, RBAC, and observability hooks. Time yourself and aim to cover trade-offs out loud.

Week 3: behavioural prep and company research

Write out three to four STAR stories covering: an incident you resolved, a cost or efficiency improvement, a time you drove adoption of a new tool, and a time you handled conflict between platform needs and product deadlines. Research kiwi's engineering blog or public talks to understand their stack and values.

Week 4: mock interviews and live practice

Do at least two timed mock system design sessions with a peer or mentor. Review common cloud provider certification practice questions (not to memorise answers but to stress-test gaps). Candidates report that kiwi's interviewers appreciate candidates who ask clarifying questions rather than jumping straight to solutions.

As you apply, knok checks 150+ job sites nightly, applies to Platform Engineer roles matching your resume, and messages HR on your behalf, so your active applications keep moving while you focus on prep.

Staying too high-level in design rounds. Saying 'we would use Kubernetes' without explaining why, how, and what the failure modes are signals shallow experience. Go one level deeper than you think is necessary.

Using 'we' instead of 'I' in behavioural answers. Interviewers are evaluating your contribution. Be specific about what you personally decided, built, or changed.

Ignoring the human side of platform work. Many candidates nail the technical questions but struggle when asked about adoption or stakeholder management. Have a story ready about convincing a resistant team to migrate to a new platform tool.

Not asking questions. Candidates who ask nothing at the end of a round can appear disengaged. Prepare two or three genuine questions about the team's biggest platform challenges, their on-call culture, or how they measure developer experience.

Overclaiming results. Saying costs dropped dramatically with no context sounds vague at best and unbelievable at worst. Anchor results in relative terms or explain the baseline clearly so the interviewer can judge the actual impact.