indium Data Analyst Interview: Questions & Prep (2026)

Indium Software is a quality engineering and digital services company headquartered in Chennai, with delivery centres across India. The company serves clients in manufacturing, BFSI, healthcare, and retail, so Data Analysts here are expected to work across domains and communicate findings clearly to both technical and non-technical audiences.

As of mid-2026, Indium has 8 open Data Analyst positions. Candidates report a process that typically runs two to three rounds: an initial screening call, a technical round covering SQL, Python or Excel, and sometimes a short take-home case, and a final discussion focused on past projects and stakeholder communication. Indium does not publicly confirm a fixed round structure, so treat this as a general pattern.

Salary bands for Data Analysts in India currently sit at 5-10 LPA for entry level (0-2 years), 10-18 LPA for mid level (3-5 years), and 18-30 LPA for senior level (6-9 years), based on knok jobradar data. Indium's offers tend to align with these market ranges, though actual packages vary by role level and negotiation.

Candidates interviewing for Indium Data Analyst roles typically encounter questions across three areas: SQL and data manipulation, business thinking, and behavioural scenarios. Here are the questions most commonly reported or logically expected given Indium's multi-industry client focus.

1. Walk us through a project where you cleaned and analysed a messy dataset. What tools did you use?
2. Write a SQL query to find the second-highest value in a column, or solve a similar ranking problem.
3. How do you handle missing values in a large dataset before building a report?
4. Explain the difference between INNER JOIN, LEFT JOIN, and FULL OUTER JOIN with a real example.
5. How do you decide which chart type to use when presenting data to a non-technical stakeholder?
6. Indium works with clients in manufacturing, BFSI, and healthcare. How would you adapt your analytical approach for a new industry domain you have not worked in before?
7. Tell us about a time your data analysis directly influenced a business decision.
8. How do you ensure data quality and accuracy in your dashboards or reports?
9. What is the difference between a data warehouse and a data lake? When would you recommend each?
10. Describe your experience with a BI tool such as Power BI or Tableau. Walk us through a dashboard you built end to end.
11. How would you approach building a KPI dashboard for a client who has never used one before?
12. A stakeholder disagrees with the trend your analysis shows. How do you handle that conversation?

Use the STAR format (Situation, Task, Action, Result) for all behavioural and project-based questions. Here are three worked examples.

Q: Walk us through a project where you cleaned and analysed a messy dataset.

*Situation:* My previous team received a large Excel export from the sales department with inconsistent date formats, duplicate rows, and several blank region codes.

*Task:* I was responsible for cleaning the file and producing a monthly revenue trend report for leadership within a tight deadline.

*Action:* I used Python with pandas to standardise date formats, remove duplicates, and fill missing region codes using a CRM lookup table. I then built summary pivot tables and visualised the final trends in Power BI.

*Result:* The report surfaced a significant revenue dip in Q3 that had gone unnoticed. Leadership used the findings to reallocate the sales budget for the following quarter, and the cleaning process I documented became the team's standard workflow.

---

Q: How do you handle missing values in a large dataset?

*Situation:* While working on a customer churn dataset for a retail client, I found that a substantial portion of the 'last purchase date' column was blank.

*Task:* I needed to decide whether to drop those rows, impute values, or flag them, without distorting the churn analysis.

*Action:* I first checked whether the missing data was random or systematic. It turned out that older records had simply not been migrated from a legacy system. I imputed dates using the account creation date as a proxy and added a separate flag column so downstream analysts could identify imputed rows.

*Result:* The churn model trained on the cleaned dataset performed significantly better in validation. The client adopted the flagging convention across all future data pipelines, making audits much faster.

---

Q: A stakeholder disagrees with the trend your analysis shows. How do you handle that conversation?

*Situation:* A senior manager at a manufacturing client insisted that sales in their western region were growing, but my dashboard showed a consistent decline over the second half of 2024.

*Task:* I had to reconcile the disagreement respectfully without dismissing the manager's perspective or compromising the accuracy of the data.

*Action:* I walked the manager through the data source, the date range selected, and exactly how the metric was defined. I then asked which figures they were referencing. It turned out they were tracking order volume while my dashboard showed revenue. We agreed to display both metrics side by side.

*Result:* The updated dashboard gave leadership a complete picture. Both parties were satisfied, and the client subsequently adopted the dual-metric view as their standard weekly report.

For SQL questions: state your approach before writing code. Explain which clause or function you will use and why, then write the query. If there are multiple solutions (a subquery vs. a window function), mention both and note which performs better on large tables. This shows you think beyond syntax.

For 'how do you handle X' process questions: use a three-part structure. First, diagnose (what do you check first?). Second, decide (what are your options and their trade-offs?). Third, document (how do you make sure the next person understands what you did and why?). This signals maturity beyond simply saying 'I fix it.'

For domain-adaptation questions (common at Indium given their multi-industry client base): use an 'ask, map, validate' structure. Ask the client what decisions the data needs to support. Map your existing analytical skills to their domain metrics. Validate your output with a domain expert before presenting broadly. This shows you can onboard quickly without pretending to know an industry you do not.

For stakeholder communication questions: lead with empathy, then evidence. Acknowledge the stakeholder's perspective, show the data transparently, and offer to reconcile differences rather than 'win' the argument. At a services company like Indium, keeping client relationships intact while staying rigorous is exactly what interviewers are looking for.

Indium is a services company, so every Data Analyst is client-facing to some degree. Interviewers are not only checking technical skill; they are assessing whether you can represent the company well in front of a client.

Technical fluency, not perfection. You are expected to write clean SQL, work with Python or Excel confidently, and know your way around at least one BI tool. You do not need to know every advanced technique, but you should be honest about gaps and demonstrate that you learn quickly.

Clear communication. Can you explain a trend to someone who has never seen a pivot table? Interviewers often ask you to 'explain this to a non-technical person' mid-answer to see how you simplify without losing accuracy.

Domain curiosity. Because Indium serves multiple industries, they value analysts who actively try to understand a client's business context rather than just running queries in isolation. Mentioning that you researched a client's sector or asked business questions before diving into data signals well.

Ownership. Stories where you spotted a problem proactively, raised a data quality issue before it reached the client, or suggested a better metric resonate far more than stories where you simply executed instructions.

Week 1: Technical foundations
Revise core SQL: JOINs, GROUP BY, window functions (ROW_NUMBER, RANK, LAG), and subqueries. Practice on platforms like HackerRank or StrataScratch. Refresh your Python pandas skills: reading files, handling nulls, merging dataframes, and exporting clean outputs. Timed practice matters more than passive review.

Week 2: Tools and storytelling
Build or revisit a dashboard in Power BI or Tableau using a public dataset. Practice narrating what the dashboard shows as if you are presenting to a client with no data background. Record yourself once; it surfaces filler words and unclear transitions faster than any other method.

Week 3: Indium-specific prep
Read Indium's public case studies and blog posts to understand which industries and problem types they focus on. Prepare two or three project stories from your own experience that map to their client domains (manufacturing, BFSI, healthcare, retail). Frame each story in STAR format and time yourself to keep it under three minutes.

Before the interview
Prepare two or three genuine questions for the interviewer. For example: what does the typical data stack look like on a client engagement, or how do analysts collaborate with the testing and engineering teams at Indium? Sharp questions signal real interest and also help you assess whether the role is right for you.

Memorising queries without understanding them. Interviewers at Indium typically follow up with 'why did you write it that way?' or 'what happens if the table has millions of rows?' If you cannot explain the logic, a memorised answer backfires immediately.

Giving generic answers to domain questions. Saying 'I would learn the domain' is not enough. Show a method: what questions would you ask the client, which KPIs would you look at first, how would you validate your understanding? Specific methods stand out; vague intentions do not.

Skipping the 'so what' in project stories. Describing what you did without connecting it to a business outcome is the most common gap candidates report. Always end a project story with what changed because of your analysis.

Underselling communication skills. Many candidates focus entirely on the technical part of their stories. At a services company, the moment you presented findings, handled pushback, or simplified a complex chart for a client is often more memorable to the interviewer than the SQL you wrote.

Not asking any questions. Ending the interview with 'no, I think I am fine' signals low engagement. Two or three genuine questions about the team, the tech stack, or the client engagement model leave a much stronger impression.