Capri Global Capital Platform Engineer Interview: Questions, Experience & Prep (2026)

Capri Global Capital is a well-established NBFC (non-banking financial company) focused on retail and MSME lending across India. As of July 2026, knok's job radar shows the company has 17 open Platform Engineer positions, reflecting active investment in its digital infrastructure. Across India, Platform Engineer roles are in demand with 204 openings tracked, strongest in Bangalore (29 roles), Delhi (12), and Pune (10).

Platform Engineers at Capri Global Capital typically work on the backbone that keeps the lending platform running: cloud infrastructure, CI/CD pipelines, Kubernetes clusters, observability stacks, and internal developer tooling. Because Capri Global operates in a regulated financial environment, interviewers pay particular attention to reliability, security posture, and compliance-aware infrastructure design.

Candidates report a process that typically includes a technical phone screen, one or two in-depth technical rounds covering infrastructure and system design, and a final conversation with a senior leader or manager. Preparation should focus equally on hands-on platform tooling and on your ability to explain trade-offs clearly.

These are the questions candidates report most often in Capri Global Capital Platform Engineer interviews, based on patterns seen across similar NBFC and fintech engineering roles:

1. Walk us through a CI/CD pipeline you built or significantly improved. What tools did you choose and why?
2. How do you manage Kubernetes cluster upgrades with zero downtime in a production environment?
3. Describe how you have implemented infrastructure as code. What challenges did you face with drift or state management?
4. How would you design an observability stack for a financial services platform? What metrics, logs, and traces would you prioritise?
5. Tell us about a production incident you owned end to end. How did you detect it, contain it, and prevent recurrence?
6. How do you enforce security and compliance controls (such as secrets management, network policies, or audit logging) in a cloud-native environment?
7. Walk us through your experience with cloud cost management. How do you balance cost, performance, and reliability?
8. How do you handle on-call responsibilities? Describe your approach to runbooks and post-mortems.
9. Capri Global serves a large number of borrowers through a digital platform. How would you ensure high availability for a critical loan-processing service?
10. How do you collaborate with application developers to define SLOs and error budgets?
11. Describe a time you introduced a new platform capability that improved developer productivity. How did you drive adoption?
12. How do you stay current with platform engineering trends, and how do you evaluate whether a new tool is right for your organisation?

Use the STAR format for every behavioural or scenario question. Keep Situation and Task brief, spend most of your time on Action, and make your Result concrete even without precise numbers.

---

Q: Tell us about a production incident you owned end to end.

*Situation:* At my previous company, a misconfigured Kubernetes resource limit caused a critical payment processing service to be OOMKilled repeatedly during peak traffic hours.

*Task:* As the on-call platform engineer, I was responsible for restoring service quickly and then finding the root cause so it could not happen again.

*Action:* I immediately raised the memory limit as a short-term fix to restore service. I then pulled logs and metrics from our observability stack, identified that a recent deployment had changed resource requests without a corresponding review step. I added mandatory resource-limit checks to our CI pipeline and updated the on-call runbook with clear steps for this class of failure.

*Result:* Service was restored within minutes of the alert firing. The CI check caught similar misconfigurations in several subsequent deployments before they reached production, and the team reported feeling more confident handling the same incident class independently.

---

Q: Walk us through a CI/CD pipeline you built or significantly improved.

*Situation:* My team inherited a legacy deployment process that relied on manual steps and SSH access to servers, making releases slow and error-prone.

*Task:* I was asked to design and implement a modern CI/CD pipeline that would allow developers to ship changes safely and frequently.

*Action:* I chose GitHub Actions for CI and ArgoCD for GitOps-based continuous delivery to Kubernetes. I introduced environment-specific promotion gates, automated integration tests at each stage, and secrets management through Vault. I ran workshops to get the development teams comfortable with the new workflow.

*Result:* Release frequency increased noticeably within the first quarter, and rollback time dropped from hours to minutes because every deployment was a versioned Git commit. Developer satisfaction with the release process improved significantly based on team retrospective feedback.

---

Q: How do you enforce security and compliance controls in a cloud-native environment?

*Situation:* At a previous role supporting a fintech product, an internal audit flagged that several microservices were storing secrets in environment variables rather than a secrets manager, creating a compliance risk.

*Task:* I needed to remediate the current exposure and put guardrails in place so the same pattern could not be introduced again.

*Action:* I migrated all secrets to HashiCorp Vault with a sidecar injection pattern on Kubernetes, so applications consumed secrets through the Vault agent without code changes. I then wrote an OPA (Open Policy Agent) policy that blocked new deployments using environment variable secrets, integrated it into the admission controller, and updated the developer onboarding documentation.

*Result:* The audit finding was resolved before the deadline. The OPA policy caught several attempts to re-introduce the old pattern at admission time, effectively making compliance the path of least resistance for developers.

The STAR method (Situation, Task, Action, Result) works for behavioural questions. Keep Situation and Task brief, spend most of your time on Action, and make your Result concrete even if you use qualitative language rather than precise figures.

For system design questions, candidates report that interviewers at financial companies respond well to a structured approach:

1. Clarify requirements and constraints (scale, SLA expectations, regulatory requirements for financial data).
2. Identify the key failure modes and reliability goals before picking tools.
3. Propose a solution, then walk through trade-offs of alternatives.
4. Address operational concerns: monitoring, alerting, runbooks, and upgrade paths.

For tool-choice questions, explain your reasoning using a simple framework: what problem the tool solves, what you evaluated against it, and why you chose it for that specific context. Avoid claiming any tool is universally best.

For incident questions, follow the lifecycle: detection, triage, containment, root cause analysis, prevention. Interviewers at financial companies care especially about the prevention step because repeat incidents can affect regulatory standing.

Based on patterns across NBFC and fintech platform engineering interviews, Capri Global Capital interviewers typically look for these qualities:

Reliability mindset. Financial platforms process real money. Interviewers want to see that you think about failure modes proactively, not just after something breaks. Talk about SLOs, error budgets, and graceful degradation.

Compliance awareness. Capri Global operates in a regulated environment. Candidates who naturally mention audit logging, secrets management, network policies, and data residency stand out from those who treat security as an afterthought.

Ownership. Platform engineers here are expected to own incidents fully, not just escalate. Your incident examples should show you drove resolution and follow-through, not just flagged the problem.

Developer empathy. The platform team exists to make application developers more productive. Candidates who talk about self-service tooling, internal developer portals, and reducing cognitive load for their users tend to receive strong feedback.

Clear communication of trade-offs. Interviewers report valuing candidates who can explain why they chose an approach over alternatives, rather than candidates who simply list technologies.

Week 1: Core technical revision

Revise Kubernetes internals (scheduling, resource management, networking, RBAC), at least one major cloud provider's core services (compute, managed Kubernetes, object storage, IAM), and your CI/CD toolchain of choice. Be able to explain how each component works, not just that you have used it.

Week 2: Financial domain and company context

Read about NBFC regulations in India and how they affect platform decisions (data localisation, audit trails, RTO/RPO expectations for core lending systems). Look at Capri Global Capital's public announcements to understand what they have been building. Review the 17 open Platform Engineer roles on knok to see which skills appear most often across the listings.

Week 3: Practice and mock interviews

Practice STAR answers for your top five past projects. Do at least two timed system design sessions covering high-availability architectures for payment or loan-processing systems. Review post-mortems publicly shared by fintech companies for inspiration on the kind of reliability thinking interviewers appreciate.

Throughout: Keep a list of the specific outcomes from your own work. Relative improvements ('reduced by roughly half', 'cut from hours to minutes') are more persuasive than vague claims, and more honest than inventing precise figures.

Listing tools instead of solving problems. Saying 'I have used Terraform, Helm, ArgoCD, Prometheus' tells an interviewer very little. Lead with the problem you were solving, then name the tools.

Skipping the 'why'. Candidates who cannot explain why they chose Kubernetes over VMs, or Vault over AWS Secrets Manager for their specific use case, typically score lower on system design rounds.

Treating security as optional. At a financial company, a platform design that does not mention secrets management, network segmentation, or audit logging will raise red flags immediately.

Vague results in STAR answers. 'It worked better' is not a result. 'Deployment time dropped from hours to minutes and rollbacks became self-service' is. Even qualitative improvements are stronger than no result at all.

Ignoring the developer experience angle. Platform engineers who only talk about infrastructure and never mention the developers who consume it miss a key part of what Capri Global is likely looking for.

Not asking good questions. Candidates report that interviewers respond well to thoughtful questions about the team's current reliability challenges, on-call culture, and roadmap. Arriving with no questions signals low interest.