navi Data Analyst Interview: Questions, Experience & Prep (2026)

Navi is one of India's most active fintech companies, building products across personal loans, health insurance, and mutual funds. As of July 2026, 60 open Data Analyst roles at Navi were tracked across major job boards, which puts it among the more active hirers in the fintech space right now.

The interview process typically runs across 3-4 rounds. Candidates report a screening call, followed by a SQL or Python test (live or take-home), then a case or business metrics round, and a final behavioural round. The process generally moves faster than at large IT companies.

Navi analysts work closely with product and business teams. That means the interview tests whether you can frame a problem, not just query a database. Expect questions anchored to loan funnels, user activation, retention, and risk signals.

Market salary bands for Data Analysts (jobradar data, July 2026)

Actual Navi offers depend on the specific role, the band budgeted, and your negotiation. Use these as a starting benchmark.

These questions come up frequently in Navi Data Analyst interviews, based on what candidates have shared publicly. They reflect Navi's fintech focus across lending, insurance, and product metrics.

1. How would you define and measure the key metrics for Navi's personal loan disbursement funnel?
2. Write a SQL query to find the top products by disbursement volume in the past 30 days, broken down by city.
3. Loan application completions dropped noticeably this week. Walk me through how you would investigate.
4. How would you segment Navi's user base to identify strong candidates for a health insurance upsell?
5. Explain precision and recall in plain terms. When would you favour one over the other in a credit risk context?
6. How would you design a dashboard to track SIP retention for Navi's mutual fund product?
7. A dataset has missing income values for a large share of loan applicants. How do you handle that before building a model?
8. How would you set up an A/B test to measure the impact of a new onboarding flow on app activation rates?
9. What metrics would you monitor daily to judge the health of a lending portfolio?
10. A PM says 'just pull the numbers.' How do you make sure you deliver something decision-ready instead of a data dump?
11. How would you detect anomalies in Navi's daily transaction data, and what threshold would trigger an alert?
12. Tell me about a time a data quality issue changed, or almost changed, a business decision.

Q: Loan application completions dropped this week. How would you investigate?

*Situation:* At my previous company, a digital lending startup, we noticed a sharp drop in loan application completions on a Monday morning.

*Task:* I needed to find the root cause quickly because the business team was preparing a weekly leadership report.

*Action:* I first checked whether the drop was across all funnel steps or isolated to one screen. I queried the event logs and found the drop was concentrated at the income-verification step. I cross-referenced the timing with a deployment from the previous Friday and looped in the engineering team. They confirmed a form-validation bug had been pushed and was rejecting valid income inputs.

*Result:* The bug was patched within hours. I also set up an automated alert on step-level completion rates so any similar drop would surface quickly in the future, rather than waiting for someone to notice manually.

---

Q: A PM says 'just pull the numbers.' How do you deliver something actually useful?

*Situation:* A product manager at my last company asked me to 'pull activation data' for a new feature with a tight deadline.

*Task:* I had to deliver something meaningful, not just a raw export, without slowing down the turnaround.

*Action:* I spent five minutes asking three quick questions: what decision does this inform, what is the comparison baseline, and who is the audience. The PM clarified they needed to decide whether to roll the feature out to all users or keep it in beta. I built a comparison table showing activation rates for the test group versus control, segmented by user tenure on the platform.

*Result:* The PM walked into the leadership call with a clear recommendation and told me it saved a lengthy back-and-forth that would have happened with a raw data dump. After that, the team adopted a one-page brief template for all data requests.

---

Q: Tell me about a time a data quality issue changed a business decision.

*Situation:* Our team was about to recommend increasing credit limits for a user segment based on repayment data.

*Task:* I was asked to do a final sanity check before the recommendation went to the credit risk committee.

*Action:* While validating, I found that repayment timestamps from one source system were recorded in UTC but our analytics pipeline was treating them as IST. This made some late repayments appear on-time. I flagged the issue, corrected the pipeline logic, and re-ran the full analysis.

*Result:* The corrected data showed the segment's on-time repayment rate was lower than originally reported. The committee delayed the credit limit increase and ran a smaller pilot instead. The finding also triggered a broader audit of all timestamp fields in our data warehouse.

For metric and funnel questions
Start by defining the metric clearly, then break the funnel into steps. State which step you would measure first and why. Always connect the metric to a business outcome, for example: 'if this drops, disbursement revenue falls directly.'

For SQL questions
Think out loud. State which tables you would use, the join logic, and any filters before writing code. Navi interviewers care about whether you understand the data model, not just whether you can produce correct syntax.

For case and 'why did this metric drop' questions
Use a structured breakdown: check data quality first, then segment by dimension (time, geography, channel, user cohort), then form a hypothesis, then validate. This shows you do not jump to conclusions before ruling out a data or logging issue.

For A/B testing questions
Cover: what you are testing and why, how you split the groups, what the primary metric is, which guardrail metrics you watch, and how long you would run the test. If sample size or statistical power comes up, mention that you would calculate the minimum detectable effect before launching.

For behavioural questions
Use STAR structure: Situation (brief context), Task (your responsibility), Action (what you specifically did), Result (a concrete outcome). Keep Situation short. Spend most of your time on Action and Result.

Navi interviewers typically look for a small set of qualities that separate analysts who are genuinely useful from those who just know the tools.

Product sense close to the data. They want to see that you think in terms of user behaviour and business outcomes, not just query outputs. An answer that connects a SQL result to a lending or insurance insight lands much better than one that stops at the number.

Structured thinking under pressure. Expect ambiguous questions. Interviewers watch whether you ask a clarifying question before diving in, or make assumptions and run with them. Asking one focused question before starting is almost always the right move.

Honest communication about uncertainty. Navi's data teams value analysts who say 'I am not sure, here is how I would find out' over those who bluff. This matters especially in fintech, where bad data can affect credit decisions with real consequences.

Ownership mindset. Candidates who have proactively flagged a data issue, improved a pipeline, or built something the team did not ask for stand out. Have at least one story ready where you went beyond the brief.

SQL and Python fluency, not mastery. You do not need to know every function. Write clean, readable queries and explain your logic. Python comfort with pandas and basic descriptive stats is a plus for most mid and senior roles.

Week 1: Technical foundations
Practice SQL daily, focusing on window functions (RANK, LAG, LEAD), CTEs, and aggregation with GROUP BY and HAVING. Work through a solid set of practice problems on any SQL platform you prefer. For Python, make sure you are comfortable with pandas for data cleaning and basic charting with matplotlib or seaborn.

Week 2: Domain knowledge and case practice
Read about how lending funnels work and what metrics a fintech typically tracks (disbursement rate, EMI bounce rate, activation rate, SIP retention). Then practice one case scenario per day: pick a metric-drop situation and talk through your investigation out loud, as if explaining to a product manager.

Week 3: STAR stories and mock interviews
Write out five to six STAR stories from your own experience. Cover at least one data quality issue, one cross-functional collaboration, and one instance where your analysis changed a decision. Do at least two timed mock interviews with a peer, using actual questions from the list above.

Before the interview
Review Navi's current product lineup on their website. Know what their personal loan, health insurance, and mutual fund products do, because interviewers often anchor case questions to real Navi scenarios. Prepare two or three genuine questions for the end, focused on the team's data stack or how analysts collaborate with product managers.

Jumping to the query before framing the problem. Many candidates open a SQL question by writing code immediately. Interviewers at product-first companies like Navi want to see that you understand what you are measuring before you start measuring it.

Treating missing data as a minor footnote. In fintech, missing income or repayment data can mean very different things: the user dropped off, a system failed, or there is a fraud signal. Saying 'I would just fill it with the mean' raises flags. Always discuss why data might be missing before deciding how to handle it.

Vague STAR answers. Saying 'I worked with the team to improve the dashboard' tells an interviewer nothing. Be specific: what was the metric, what did you change, what was the before-and-after result.

Not asking clarifying questions. Candidates who dive straight into an ambiguous case often solve the wrong problem. Pause, ask one or two focused questions, then proceed.

Over-engineering the solution. Navi values analysts who deliver clear, correct answers quickly. A short, readable query beats a long, complex one that the reviewer cannot follow in a reasonable review time.

Ignoring guardrail metrics in A/B test answers. Saying you would optimise only for the primary metric without watching for side effects (for example, loan approval rate going up while fraud rates also rise) suggests a lack of real testing experience.