Heartbeat AI GmbH Platform Engineer Interview: Questions, Experience & Prep (2026)

Heartbeat AI GmbH is a German AI company (GmbH is Germany's equivalent of a private limited company). With 40 open roles currently listed, the company is in an active hiring phase, and Platform Engineer is a central position for any company shipping AI at scale.

As a Platform Engineer at Heartbeat AI, you would typically own the infrastructure that underpins their AI platform: cloud environments, Kubernetes clusters, ML pipeline infrastructure, CI/CD automation, and observability systems. Because of the European customer base, GDPR-compliant infrastructure design is also likely to come up in the interview.

Candidates report that the process typically spans multiple rounds, starting with a technical screening call and progressing to a hands-on or take-home assessment, followed by system design and values-fit discussions. The overall timeline can vary by team and hiring volume.

Across India, there are 204 Platform Engineer openings as of July 2026, with Bangalore leading at 29 roles. Heartbeat AI's 40 open roles signal a company in growth mode, which means platform infrastructure is active product-level investment, not just maintenance work.

The following questions come up often in Platform Engineer interviews at AI companies like Heartbeat AI. Candidates report these themes based on publicly shared experiences for similar roles.

1. Walk us through how you have set up a Kubernetes cluster from scratch. What choices did you make on node configuration, networking, and storage?

1. How do you design a CI/CD pipeline for a machine learning project where model artifacts, data versioning, and code all need to be tracked together?

1. Describe your experience with Infrastructure as Code. Which tools have you used, and how did you handle state management and drift detection?

1. How would you design a platform to serve low-latency AI model inference at scale? What components would you choose and why?

1. What is your approach to platform observability? How do you decide what to instrument, and how do you respond to an alert that fires at 2 AM?

1. Heartbeat AI serves customers in Europe. How does GDPR affect the way you design data pipelines, cloud storage, and deletion workflows?

1. Tell us about a time your platform had an outage. What happened, how did you respond, and what did you change afterwards?

1. How do you manage secrets and credentials across environments? Walk us through a concrete setup you have used.

1. How do you balance developer experience (fast deploys, easy debugging) with platform stability and security requirements?

1. Describe how you would set up cost monitoring and optimisation for a cloud environment where GPU compute is a significant expense.

1. What is your experience with container security scanning, policy enforcement, or admission controllers in Kubernetes?

1. How do you approach platform migrations, such as moving workloads between cloud providers or upgrading Kubernetes versions with zero downtime?

Q: Walk us through how you set up a Kubernetes cluster from scratch.

*Situation:* At my previous company, we were running containerised services on bare cloud instances managed manually. Deployments were inconsistent and scaling required human intervention each time.

*Task:* I was asked to migrate everything to a managed Kubernetes setup and own the full cluster design, from node groups to networking to observability.

*Action:* I chose a managed Kubernetes service and used Terraform to provision all resources. I set up separate node groups for general workloads and GPU workloads, configured a node autoscaler for bursty traffic, and wrote Helm charts for all internal services. I introduced a GitOps tool for continuous delivery and integrated a monitoring stack from day one. I also ran knowledge transfer sessions so the rest of the team could operate the cluster without depending on me.

*Result:* Deployment frequency increased significantly and on-call incidents related to infrastructure dropped over the three months following the migration. The team could self-serve standard deployments without escalating to the platform team.

---

Q: Tell us about a time your platform had an outage.

*Situation:* We had a production outage affecting our API serving layer. A config change rolled out via the CD pipeline caused pods to crash-loop, and the liveness probe was not catching the issue fast enough to trigger an automatic rollback.

*Task:* I was the on-call engineer that night and needed to restore service quickly while also identifying the root cause.

*Action:* I immediately rolled back the deployment using the GitOps tool's UI, which restored service within a few minutes. The next day I ran a blameless post-mortem with the team. We found that the config change had no staging promotion gate and that the liveness probe timeout was too aggressive for our service startup time. I added a mandatory staging gate to the pipeline and tuned the probe settings. I also wrote a runbook for this failure mode so future on-call engineers could resolve it faster.

*Result:* Service was restored within minutes of the first alert. The same failure mode has not recurred since we added the staging gate, and the runbook has since been used by other engineers for related issues.

---

Q: How do you balance developer experience with platform stability?

*Situation:* Our platform team was under pressure to speed up build times and simplify deployments, but a compliance review had introduced strict security and audit requirements that we could not work around.

*Task:* I needed to improve developer feedback loops without weakening the compliance posture.

*Action:* I introduced ephemeral preview environments that spun up per pull request using lightweight namespaces on our existing cluster, with all security policies enforced via admission controllers. I added layer-caching to our Docker builds to cut build times. For secrets management, I migrated to a vault-based setup with short-lived dynamic credentials so developers did not need to manage long-lived keys.

*Result:* Developer satisfaction improved in our quarterly internal survey. We passed our next compliance audit with no findings related to secrets management. Platform-related escalations to our team dropped noticeably over the following quarter.

For behavioral questions, use the STAR structure throughout. Keep the Situation and Task brief (two or three sentences each) and spend most of your time on Action and Result. The more specific your actions, the more credible your story. Interviewers at product companies are listening for judgment calls, not just task completion.

For system design questions, open by clarifying requirements: expected scale, latency constraints, consistency needs, and any compliance constraints like GDPR. Sketch the high-level architecture first, then go deeper on individual components. Close by discussing trade-offs and what you would revisit with more time or budget. This shows you think in layers, not just components.

For 'how would you' infrastructure questions, structure your answer across four layers: the infrastructure layer (cloud, networking, compute), the platform layer (orchestration, secrets, CI/CD), the developer experience layer (APIs, tooling, self-service interfaces), and the observability layer (metrics, logs, traces). Covering all four layers signals a holistic platform mindset rather than a narrow operational focus.

For tool-choice questions, never just list names. Explain which problem each tool solves and why you chose it over the obvious alternative. Saying 'I used Karpenter because we needed faster scale-up than the Cluster Autoscaler could provide for bursty GPU workloads' is far more convincing than 'I used Karpenter for autoscaling.'

Heartbeat AI is building AI products, which means Platform Engineers are not just maintaining infrastructure. They are enabling model training, serving, and experimentation at scale. Here is what interviewers are typically looking for in this kind of role.

Ownership mindset. Can you take a platform problem end-to-end, from initial design to runbook, without someone holding your hand? Give examples where you drove a platform initiative, not just implemented a ticket handed to you.

Reliability thinking. Do you design for failure from the start? Show that you think in terms of failure modes, rollback strategies, and post-mortem culture rather than focusing only on keeping things running.

ML infrastructure awareness. You do not need to be a data scientist, but knowing how training jobs, model registries, feature stores, and inference servers work will set you apart from candidates who treat this as a generic cloud role. Show you understand what your ML engineering colleagues actually need from the platform.

GDPR-aware design. Since Heartbeat AI is a German company serving European users, data residency, deletion pipelines, and audit logging are legal requirements, not optional features. Mentioning these proactively in system design answers will leave a strong impression.

Clear communication. Platform teams are internal service providers. Interviewers want to see that you can document clearly, say no to unreasonable requests with a reasoned explanation, and give developers the context they need without over-engineering every interaction.

Week 1: Foundations review. Revisit Kubernetes internals (scheduling, networking, RBAC, admission controllers), Terraform state management and module design, and the advanced features of your preferred CI/CD tool. Practice explaining each concept out loud as if teaching a junior colleague. This quickly surfaces gaps in your understanding.

Week 2: ML infrastructure focus. Read up on how tools like MLflow, Kubeflow, or Ray are typically deployed on Kubernetes. Understand what a feature store does and why ML teams need model versioning separate from code versioning. You do not need hands-on experience with all of them, but knowing the concepts helps you answer 'how would you build a platform for AI workloads' questions with real credibility.

Week 3: System design practice. Do two or three timed system design sessions on topics like 'design a multi-tenant ML inference platform' or 'design a CI/CD system for a team running GPU training jobs'. Focus on articulating trade-offs clearly rather than producing a perfect architecture diagram.

Week 4: Behavioral prep and company research. Map your past projects to common interview themes: outage response, platform migration, developer tooling, cost optimisation. Read Heartbeat AI's public content (blog posts, LinkedIn updates, job descriptions for adjacent roles) to understand their product and engineering values. Prepare four or five stories in STAR format covering different competencies.

Throughout: Brush up on GDPR basics as they relate to infrastructure, particularly data residency, encryption at rest, deletion pipelines, and audit logging. These are likely to come up given Heartbeat AI's European market focus.

While you prepare, knok checks 150+ job sites nightly, applies to matching Platform Engineer roles on your behalf, and messages HR for you so opportunities do not slip through while you are focused on interview prep.

Listing tools without context. Saying 'I know Terraform, Helm, ArgoCD, Prometheus' without explaining what problems you solved with each will not impress an experienced interviewer. Always anchor tool mentions to a specific decision, trade-off, or outcome.

Skipping the 'why'. Platform questions are largely about judgment. If you say 'I used Karpenter for autoscaling', follow up immediately with why you chose it over the alternative and what limitations you encountered. The reasoning matters more than the tool choice itself.

Ignoring the ML context. This is an AI company. Treating the role as generic DevOps or SRE work, without showing awareness of ML-specific requirements like GPU node management, experiment tracking, or model versioning, can signal a poor fit for the team.

Vague outage stories. Some candidates give outage answers that are all action and no reflection. Interviewers want to see that you ran a post-mortem, changed something specific, and can explain the second-order effects of that change.

Underestimating GDPR. Candidates who wave off compliance with 'we encrypt everything' without showing depth on data residency, deletion pipelines, or audit trails leave interviewers unconvinced. GDPR is a legal requirement in the European market, not a checkbox.

Talking only about infrastructure, not developer experience. Platform Engineers serve internal developers. If all your answers focus on cluster configuration and none address the interface you built for your users (self-service tooling, documentation, escalation paths), you may come across as siloed from the people your platform is meant to help.