Capri Global Capital Data Engineer Interview: Questions & Prep (2026)

Capri Global Capital is a mid-size NBFC (Non-Banking Financial Company) with a growing focus on data-driven lending decisions. With 17 open Data Engineer roles listed as of July 2026, the company is actively building out its data infrastructure team, likely to support credit analytics, risk modeling, and regulatory reporting pipelines.

Data Engineers here typically work on ingestion pipelines from loan origination systems, transforming raw financial data into clean datasets for analysts and ML teams. The stack candidates report includes cloud platforms (AWS or Azure), Python, SQL, and tools like Apache Spark or Airflow, though this varies by team.

Salary bands (knok jobradar, July 2026):

The interview process typically spans 2-4 rounds including a technical screen, a coding or take-home exercise, and a managerial or system design discussion. Candidates report that domain knowledge of financial data (loan records, EMI schedules, credit bureau data) gives a meaningful edge over purely SaaS or e-commerce backgrounds.

These questions come up repeatedly in Capri Global Capital Data Engineer interviews, based on what candidates report across job prep communities:

1. Walk me through a data pipeline you built end-to-end. What were the bottlenecks?
2. How would you design a pipeline to ingest daily loan disbursement data from multiple branches with inconsistent formats?
3. Capri works with sensitive financial data. How do you handle PII masking and data governance in your pipelines?
4. Explain the difference between a star schema and a snowflake schema. Which would you use for a credit analytics warehouse and why?
5. How do you handle late-arriving data in a streaming or batch pipeline?
6. Describe a time you caught a data quality issue before it reached a downstream report or model.
7. What is your experience with regulatory or compliance reporting, such as RBI guidelines for NBFCs?
8. How would you optimise a slow SQL query running on a large transactions table?
9. Walk us through your experience with orchestration tools like Airflow or Prefect.
10. How do you version and document your pipelines so others on the team can maintain them?
11. If a business analyst reports that a dashboard number looks wrong, how do you investigate and fix it?
12. How would you build a reconciliation job that verifies loan repayment data matches across two source systems?

Use the STAR format (Situation, Task, Action, Result) to make your answers concrete and easy to follow.

---

Q: Walk me through a data pipeline you built end-to-end.

*Situation:* At my previous company, the finance team was pulling loan disbursement data manually from three different source systems each week, pasting it into Excel, and sending it to leadership. Errors were common and the process consumed a full working day.

*Task:* I was asked to automate this into a reliable daily pipeline with clean output the business could trust.

*Action:* I built an Airflow DAG that extracted data from two MySQL databases and one REST API each morning, applied transformation logic in Python to standardise branch codes and currency fields, loaded the result into a Redshift table, and triggered a Slack alert if row counts fell outside expected ranges.

*Result:* The manual effort dropped to near zero. Data was available by 7 AM each morning, and a recurring discrepancy that the old process had been masking for months was caught and fixed within the first week.

---

Q: How do you handle data quality issues before they reach downstream consumers?

*Situation:* On a credit bureau integration project, we were receiving raw CIBIL data files daily. The files occasionally arrived with missing fields or duplicate records that would corrupt our risk scoring models if not caught.

*Task:* I needed to add a validation layer that would hold bad data without stopping the pipeline entirely.

*Action:* I wrote a Great Expectations suite that checked for null rates, value ranges, and duplicate primary keys on every incoming file. Files that failed were quarantined to a separate S3 prefix and an alert was sent to the on-call engineer. Clean records continued to the next stage. I also added a daily summary table so the data ops team could review quarantine rates over time.

*Result:* We caught a batch of corrupted records in week two that would have skewed our default prediction model. The product team later adopted the same validation pattern for two other data sources.

---

Q: How would you optimise a slow SQL query on a large transactions table?

*Situation:* A reporting query on our loan transactions table was taking a very long time in production, consistently blocking a daily finance report that leadership depended on.

*Task:* I was asked to bring the runtime down without changing the output or restructuring the table.

*Action:* I ran EXPLAIN ANALYZE and found a full table scan on a date column used in every WHERE clause. The column had no index. I added a composite index on (loan_date, branch_id), rewrote a subquery as a CTE to reduce repeated scans, and moved an aggregation step earlier so we were grouping a much smaller dataset. I tested all changes in staging with a production-size data copy before applying them.

*Result:* The query went from taking most of the morning to finishing well within the reporting window. The finance team got their report on time from the next day onward, and I documented the changes in our internal wiki so future engineers understood the indexing decisions.

For pipeline and system design questions: Start with the data source and business need, then walk through ingestion, transformation, storage, and consumption in order. Mention failure handling and monitoring explicitly. Interviewers at financial companies like Capri care about what happens when things go wrong, not just the happy path.

For SQL optimisation questions: Lead with diagnosis (EXPLAIN plan, identify full scans or missing indexes), then the fix, then how you verified it. Avoid claiming you 'just rewrote it' without walking through your reasoning.

For behavioural questions: Use STAR cleanly. Keep the Situation short (one or two sentences). Spend most time on Action, which shows your actual skill. Quantify the Result if you can, but a qualitative outcome ('the report was trusted by leadership for the first time') is still stronger than vague statements.

For domain questions (RBI reporting, PII, credit data): If you have direct experience, lead with it. If not, describe how you would approach it: what you would read, who you would consult, how you would validate your solution. Honesty about gaps paired with a clear plan reads far better than bluffing.

Capri Global Capital is an NBFC, so interviewers look for candidates who understand that data here is not just interesting, it is regulated, consequential, and tied directly to lending decisions that affect real customers.

Domain awareness matters. Knowing what a loan account table looks like, why EMI schedules have edge cases, or what RBI asks for in reporting puts you ahead of candidates who only have e-commerce or SaaS backgrounds.

Reliability over cleverness. Interviewers typically favour engineers who build pipelines that fail loudly and recover cleanly over those who build complex systems that are hard to debug. Mention monitoring, alerting, and reconciliation naturally in your answers.

Communication with business users. Data Engineers at Capri commonly work with credit analysts, risk teams, and finance. Candidates who can translate a business problem into a technical design, and explain a technical issue to a non-technical stakeholder, consistently stand out.

Ownership. Smaller teams mean less specialisation. Be ready to talk about times you handled more than just the code: documentation, deployment, or direct stakeholder communication.

Week 1: Core technical review

Revise SQL window functions, query optimisation, and indexing. Practice designing a simple star schema for a loan portfolio. Set up a small Airflow or Prefect project locally if you have not used orchestration tools recently.

Week 2: Financial domain and system design

Read publicly available RBI guidelines on data reporting for NBFCs (the RBI website has these). Study what PII masking means in practice for Indian financial data. Practice designing a daily loan repayment ingestion pipeline out loud, covering both the happy path and failure scenarios.

Week 3: Interview practice

Prepare 3-4 STAR stories covering: a pipeline you built, a data quality incident, a performance fix, and a time you worked closely with a business team. Practice each story out loud until the timeline feels natural. Run a mock interview with a peer if possible.

Before each round: Review Capri Global Capital's recent news (annual reports, product launches) so you can reference business context naturally. Candidates report that showing genuine interest in the lending domain, not just the tech stack, leaves a positive impression.

Talking only about the tech, ignoring the business outcome. Saying 'I built an Airflow pipeline' without explaining what problem it solved or who used the data is a missed opportunity. Always connect your work to a business result.

Underestimating SQL. Some candidates assume SQL questions are easy and underprepare. Financial data roles at NBFCs rely heavily on SQL for reporting and reconciliation. Practice window functions and complex joins until they feel routine.

Bluffing on domain knowledge. If you have not worked with credit bureau data or RBI reporting before, say so clearly and pivot to how you would learn it. Interviewers who work with this data daily will notice inconsistencies in fabricated claims.

Skipping failure handling in design answers. A pipeline design that only covers the happy path signals inexperience. Always mention what happens when a source is down, a file is malformed, or a job fails halfway through.

Not asking questions at the end. Candidates report that teams at Capri expect genuine curiosity. Ask about the current data stack, the biggest challenge the team is solving, or how the data function is structured.