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

Agrim has 69 open Data Analyst positions listed as of July 2026, making it one of the more active hirers in this space right now. Candidates report a process that typically runs two to four rounds, mixing a take-home or online SQL and analytics test with one or two technical interviews and a final discussion with a business or product stakeholder. The focus is consistently on practical data skills: writing clean SQL, interpreting business metrics, and communicating findings to non-technical teams.

Salary bands for Data Analysts across the broader market look like this:

Agrim's specific offers are not publicly confirmed at scale, but candidates typically fall within the mid-market band for their experience level.

These questions come up repeatedly in Agrim Data Analyst interviews, based on what candidates typically report for analytics-first companies at this stage:

1. Walk me through a time you turned raw data into a decision the business actually acted on.
2. Write a SQL query to find the top five districts by loan disbursement in the last 30 days, broken down by loan category.
3. A key metric drops sharply overnight. How do you investigate the root cause?
4. How would you build a dashboard to track repayment health for a lending portfolio?
5. Explain the difference between a LEFT JOIN and an INNER JOIN. When would you use each?
6. A product manager asks you to prove that a new feature improved user retention. How do you approach this?
7. How do you handle missing or inconsistent data in a large dataset before analysis?
8. What does cohort analysis mean, and when is it useful in a financial or lending context?
9. Describe a situation where your analysis showed something unexpected. How did you validate it and present it?
10. How would you measure the success of a new credit scoring model?
11. You have data from three different source systems that do not always agree. How do you decide which source to trust?
12. How comfortable are you with Python or R for data manipulation? Walk me through a recent task you used it for.

Q: Walk me through a time you turned raw data into a decision the business actually acted on.

*Situation:* At my previous role, the collections team believed that sending reminders on Day 3 after a missed payment was optimal, but they had no data to back this up.

*Task:* I was asked to analyse two years of repayment records to find the best reminder timing.

*Action:* I pulled the full history from the warehouse using SQL, segmented borrowers by loan size, geography, and past behaviour, built a cohort analysis in Python, and visualised recovery rates by day-of-reminder in a simple chart. I shared the findings with the collections head in a short walkthrough, not a long report.

*Result:* The team shifted reminders to Day 1 for high-risk borrowers and Day 5 for low-risk ones. Recovery rates improved noticeably in the following quarter, and the team cited this as a direct input into their revised SOP.

---

Q: A key metric drops sharply overnight. How do you investigate the root cause?

*Situation:* During an internship, our daily active user count fell sharply with no obvious cause.

*Task:* I had to diagnose whether this was a data pipeline issue, a product issue, or a real user behaviour change.

*Action:* I first checked the ETL pipeline logs for failures or delays, then compared the raw event counts in the source system against what landed in the warehouse. Once the data looked intact, I segmented the drop by platform, region, and user cohort. The drop was concentrated in Android users in two states, which pointed to an app update pushed the previous evening.

*Result:* I flagged this to the product team within a couple of hours of starting the investigation. The update was rolled back the same day, and DAU recovered within two days. The process I documented became the team's standard 'metric drop checklist.'

---

Q: How would you build a dashboard to track repayment health for a lending portfolio?

*Situation:* A new business unit at my company had no visibility into how their loan book was performing week to week.

*Task:* I was asked to design and build a repayment health dashboard from scratch.

*Action:* I started by interviewing the collections and finance leads to understand which decisions they made weekly and what data they lacked. I then defined five core metrics: on-time repayment rate, days-past-due distribution, early settlement rate, roll rate, and portfolio at risk. I built the SQL views, connected them to a BI tool, and added filters for loan type, geography, and relationship manager.

*Result:* The dashboard went live in three weeks and became the single source of truth for weekly business reviews. Two collection bottlenecks were identified in the first month that had been invisible before.

STAR (Situation, Task, Action, Result) is the most reliable structure for behavioural questions. Keep the Situation and Task brief (one or two sentences each) and spend most of your time on the Action and Result. Interviewers want to see how you think, not just what happened.

For SQL and technical questions, think aloud. State your assumption, write the query step by step, and mention edge cases (NULLs, duplicates, time zones) even if you do not fully code them. This shows rigour.

For metric-drop or root-cause questions, use a structured funnel:
1. Rule out data and pipeline issues first.
2. Segment the drop by time, geography, platform, and user type.
3. Form a hypothesis and test it against the data.
4. Confirm and communicate quickly.

For 'how would you build' questions, anchor on the business question before talking about tools. Say what decision the dashboard or model needs to support, then describe the metrics, then mention the stack. This shows you think like an analyst, not just a SQL writer.

Based on what candidates typically report from analytics roles at growth-stage Indian fintechs, Agrim interviewers look for a few specific traits.

Business context before technical depth. An analyst who can explain why a metric matters will land better than one who only talks about query optimisation. Tie every technical answer back to a business outcome.

Comfort with messy data. Lending and fintech data is rarely clean. Interviewers want to see that you ask about data quality proactively, not reactively.

Communication to non-technical stakeholders. You will be presenting to collections managers, product leads, and sometimes founders. Show that you can produce a chart or a one-pager that a non-analyst can act on.

Ownership and curiosity. Interviewers value candidates who noticed a problem before they were asked to look, or who dug one layer deeper than the original question. Bring one example of this to every interview.

SQL fluency. Window functions, CTEs, and aggregations are table stakes. Be ready to write these live or on a shared document without reference material.

Week 1: SQL and fundamentals
Practise window functions (RANK, ROW_NUMBER, LAG, LEAD), CTEs, and multi-table joins on a free platform like HackerRank or Mode. Focus on finance or e-commerce datasets since the logic is closest to what Agrim works with. Aim for a few medium-difficulty problems per day.

Week 2: Business analytics and metrics
Revise cohort analysis, funnel analysis, and A/B test interpretation. Pick two or three lending or fintech metrics (repayment rate, NPA, CAC) and be ready to define them, explain why they matter, and describe how you would track them.

Week 3: Storytelling and case prep
Prepare three STAR stories from your past work. At least one should involve finding an insight that changed a decision. Practise explaining your analysis in plain language, as if you are briefing someone who does not use SQL.

Before the interview
- Read Agrim's public blog posts, LinkedIn updates, or any press coverage to understand the business model.
- Prepare two or three smart questions to ask at the end, focused on how the data team is structured and what the biggest analytics challenges are right now.

Jumping to tools before the problem. Saying 'I would use Python and a Random Forest' before you understand the business question is a red flag. Always start with: what decision does this analysis need to support?

Writing SQL without handling edge cases. Forgetting NULLs, duplicate rows, or time-zone differences in live coding rounds is common and costly. Mention these even if you do not write the full solution.

Vague STAR answers. Answers like 'the team improved significantly' do not land. Quantify where you can, or at least be specific: 'recovery rates improved in the next quarter' is stronger than 'performance went up.'

Not asking clarifying questions. In case or scenario questions, jumping straight to an answer without clarifying the goal, the audience, or data availability looks rushed. A brief clarifying question shows structured thinking.

Underselling communication skills. Many candidates talk only about technical work and skip how they presented it. For a role that works with non-technical stakeholders, this is a gap interviewers notice.

Ignoring domain context. If you are applying to a fintech or agri-lending company, knowing basic terms like DPD, NPA, or credit utilisation signals genuine interest and preparation.