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

Runway is a generative AI company best known for its video and image generation platform. The Platform Engineering team builds and operates the cloud infrastructure that trains, evaluates, and serves large AI models at scale. If you land an interview here, expect deep conversations about Kubernetes, GPU workloads, CI/CD for ML pipelines, observability, and developer experience for ML engineers.

As of July 2026, Runway has 4 open Platform Engineer roles. Across India, knok jobradar tracked 204 Platform Engineer openings in the same period, with Bangalore leading at 29. Runway's interview process typically includes a recruiter screen, one or two technical rounds covering systems design and infrastructure deep-dives, and a final conversation around values and team fit. Candidates report the full process spanning two to four weeks.

These questions reflect publicly reported interview experiences and the known scope of the Platform Engineer role at Runway. Prepare a concrete example for each.

1. How have you designed a Kubernetes platform to support GPU-intensive ML training jobs at scale?
2. Walk us through how you would build a CI/CD pipeline for a team shipping ML models to production.
3. How do you handle autoscaling for bursty, GPU-heavy inference workloads? What tradeoffs did you make?
4. Describe your experience with infrastructure-as-code tools such as Terraform or Pulumi. How do you manage state across multiple environments?
5. How would you design a multi-tenant platform so that different ML teams can deploy their own model-serving containers without interference?
6. What is your approach to observability: metrics, logs, and tracing in a distributed platform running AI workloads?
7. Runway's models require storing very large model artifacts. How would you design a reliable and cost-efficient artifact registry or storage layer?
8. How do you define and maintain SLOs when the underlying workloads are experimental and hard to predict?
9. Tell me about a time you improved the developer experience for a team of ML engineers or data scientists.
10. How do you approach security for a platform that ingests and processes large volumes of user-generated media?
11. Describe a situation where you had to balance shipping fast with keeping the platform stable.
12. How do you think about cloud cost optimisation for GPU clusters that run intermittently at high utilisation?

Q: How have you designed a Kubernetes platform to support GPU-intensive ML training jobs?

*Situation:* At my previous company, ML engineers ran training jobs on manually provisioned VMs. There was no resource isolation, jobs competed for the same GPUs, and failures were difficult to debug.

*Task:* I was asked to build a self-service Kubernetes platform that could schedule GPU jobs reliably and let the ML team submit work without waiting for the ops team.

*Action:* I provisioned GPU node pools on GKE with NVIDIA device plugins installed, set resource quotas per team namespace, and integrated Argo Workflows for job orchestration. I added Prometheus and Grafana dashboards scoped to GPU utilisation and job queue depth, and wrote runbooks for the most common failure modes. I ran a dry-run with the ML team before full rollout and iterated on quota defaults based on their feedback.

*Result:* Job failures from resource contention dropped noticeably within the first month. The ML team could submit and monitor jobs independently, and the ops team stopped fielding ad-hoc provisioning requests.

---

Q: Tell me about a time you improved the developer experience for ML engineers.

*Situation:* New ML hires at my company were spending several days getting cluster access and local environments set up. Each person had a slightly different configuration, which caused reproducibility problems across experiments.

*Task:* Reduce onboarding friction and standardise the development environment so ML engineers could be productive quickly.

*Action:* I built a self-service portal backed by Helm charts. Base container images were pre-built with pinned CUDA versions and standard ML libraries. New engineers received cluster access and a working Jupyter environment through a single onboarding script. I ran two feedback sessions with the ML team during rollout and updated the scripts based on their input.

*Result:* Candidates from similar platform roles publicly report cutting environment setup from multiple days to a few hours. Our internal feedback matched that pattern, and repeated complaints about environment issues stopped appearing in team retrospectives.

---

Q: Describe a situation where you balanced shipping fast with keeping the platform stable.

*Situation:* A product team needed a new model-serving endpoint live within a week for an upcoming launch. The standard review and staging process took two weeks.

*Task:* Find a way to meet the deadline without bypassing the safety checks that protect production.

*Action:* I sat with the product and ML teams to map the minimum viable checks: load testing at expected traffic levels, a documented rollback plan, and a feature flag so we could disable the endpoint without a full deploy. I parallelised the review steps that could run simultaneously and flagged the two steps that could not be skipped. We completed a compressed but complete review in four days.

*Result:* The endpoint launched on time with no incidents in the first two weeks. I documented the compressed review checklist so the team could reuse it for future time-sensitive launches.

For systems design questions, think out loud and structure your answer in three layers: what you are building, how the components connect, and where the failure points are. Runway cares about ML-specific concerns, so always address GPU scheduling, model artifact storage, and serving latency alongside generic reliability.

For behavioral questions, use STAR: Situation (brief context), Task (your specific responsibility), Action (what you personally did, not what the team did), and Result (observable or measurable outcome). Keep Situation and Task short. Spend most of your time on Action and Result.

For trade-off questions, name the trade-off explicitly before taking a position. For example: 'This is a cost-versus-latency trade-off. For batch training I would prioritise cost, but for real-time inference I would prioritise latency.' A clear point of view matters more than hedging every answer.

For 'how would you' questions, anchor your answer in something you have actually built before extending to the hypothetical. This shows practical experience rather than textbook knowledge.

Deep Kubernetes and cloud infrastructure knowledge. Runway runs large, complex workloads on managed cloud platforms. Expect to go well beyond basic Kubernetes into GPU node management, resource quotas, custom schedulers, and cluster autoscaling under real load.

Understanding of ML workloads specifically. Generic cloud experience is not enough. You should understand why GPU workloads behave differently from CPU workloads, how model artifacts are versioned and stored, and what makes inference serving distinct from a typical web API.

Reliability and observability instincts. Interviewers want to see that you design for failure from the start. Be ready to discuss SLOs, alerting thresholds, runbooks, and how you have handled on-call incidents in past roles.

Developer empathy. Platform engineers at AI companies serve ML engineers as internal customers. Interviewers look for candidates who have worked closely with ML teams, understood their pain points, and built tooling that reduced friction rather than adding it.

Cost awareness. GPU compute is expensive. Candidates who can speak to cost optimisation strategies, spot instance usage, and right-sizing node pools stand out from those who only talk about reliability.

Week 1: Core infrastructure revision
Revise Kubernetes internals: the scheduler, resource limits and quotas, node affinity, taints and tolerations, and the GPU device plugin. Practise designing a GPU node pool architecture on paper. Make sure you can explain Terraform or Pulumi state management clearly, not just the syntax.

Week 2: ML platform specifics
Learn how model training pipelines differ from general batch jobs. Study tools commonly used in ML platforms: Argo Workflows or Kubeflow for orchestration, MLflow for experiment tracking, and object storage patterns for large model artifacts. If you have not worked with GPU workloads directly, read publicly available engineering blog posts from AI infrastructure teams.

Week 3: Observability and reliability
Practise designing an observability stack for a distributed system: what metrics matter for GPU jobs, how you structure dashboards, and how to write useful alerts that do not generate noise. Prepare two or three past incidents you can discuss using STAR, focusing on diagnosis and what changed afterwards.

Week 4: Mock interviews and research
Do at least two timed systems design mock sessions focused on ML platform components. Review Runway's publicly available product and engineering content to understand what their platform needs to support. Prepare specific questions for the interviewer about the team's current challenges and how they measure platform success.

While you prepare, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so relevant openings reach you without daily manual searching.

Treating this like a generic SRE or DevOps interview. Runway is an AI company. Candidates who answer every question with web-application patterns and ignore GPU scheduling, model artifact management, and ML pipeline orchestration tend to find the technical rounds much harder than expected.

Vague results in STAR answers. Saying 'things improved' or 'the team was happy' is not enough. Even without precise numbers, describe the direction and scale: 'job failures dropped noticeably,' 'onboarding went from days to hours,' or 'we eliminated a whole category of on-call alerts.'

Skipping trade-offs. Platform engineering is built on trade-offs. Candidates who give one-sided answers without naming what they gave up (cost, latency, simplicity, speed) come across as less experienced than they may actually be.

Not asking questions. Runway interviews typically leave time for your questions. Candidates who ask nothing signal low interest. Prepare two or three specific questions about the team's infrastructure challenges, on-call setup, or how they measure platform success.

Underestimating the ML knowledge bar. You do not need to be an ML researcher, but you do need to understand the infrastructure needs of ML training and inference well enough to have an informed conversation with ML engineers.