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

Optum, the health services arm of UnitedHealth Group, runs large clinical, claims, and pharmacy data platforms across India. The company had 38 Data Analyst openings tracked by knok job radar as of July 2026, making it one of the more active hirers among the 319 Data Analyst roles live nationally at that time.

Candidates typically report a structured process: a recruiter screen, one or two technical rounds covering SQL and analytical thinking, and a final business or behavioural round. The exact sequence varies by team, so treat any specific order you read online as illustrative rather than fixed.

The role sits at the intersection of healthcare data (claims, clinical, pharmacy, member records) and business reporting. Interviewers therefore test both your SQL depth and your comfort reading data in a regulated, patient-focused context. You do not need clinical expertise, but basic familiarity with how health data is structured is a visible advantage.

These questions come up repeatedly in candidate-shared experiences for Optum Data Analyst roles. Expect a mix of technical and behavioural questions across rounds.

1. Write a SQL query to identify patients who exceed a visit threshold within a rolling window. Interviewers want to see window functions, GROUP BY, and HAVING used correctly together.

1. How would you detect anomalies in claims data? They are looking for your diagnostic approach, not just a library name or a one-line answer.

1. Explain the difference between INNER JOIN, LEFT JOIN, and FULL OUTER JOIN with a healthcare example. Expect a follow-up asking you to choose the right join for a specific scenario.

1. You notice a sudden drop in reported claims for a region. Walk me through how you would investigate. This tests structured thinking and familiarity with data pipelines.

1. How do you handle missing values in a patient dataset? They want to hear you weigh imputation against exclusion, not just say 'fill with mean'.

1. Describe a time you built a dashboard or report that changed a business decision. A behavioural question testing real impact, not just technical output.

1. What is the difference between a fact table and a dimension table? Give an example from a healthcare context. Data warehousing fundamentals are tested frequently at Optum.

1. Write a query to calculate hospital readmission rates within a defined look-back window from an admissions table. Candidates report this or a close variant appearing in technical screens.

1. How would you validate data quality after a pipeline migration? They want a systematic checklist approach, not a single check.

1. Walk me through a Python or R analysis you have done end to end, from raw data to insight. Expect drill-down questions on every choice you made.

1. How do you communicate a technically complex finding to a non-technical stakeholder? Optum has many clinical and operations stakeholders, so this comes up regularly.

1. What do you know about HIPAA and why does it matter to a Data Analyst at a health company? Basic compliance awareness is expected, not legal expertise.

Q: Describe a time you found a data quality issue that others had missed.

*Situation:* I was working on a monthly claims reconciliation report at my previous company. The totals matched on the surface, but a colleague's downstream model kept producing unexpected results.

*Task:* I needed to trace the discrepancy back to its source before the quarterly business review.

*Action:* I wrote a row-level reconciliation query comparing the source tables to the aggregated report layer. I found that one payment category was being double-counted because a recent ETL change had introduced a duplicate join key. I documented the issue, raised it with the engineering team, and backfilled the corrected figures.

*Result:* The downstream model stabilised, and the team added a row-count check to the pipeline so the same class of error would surface automatically in future.

---

Q: Tell me about a time you had to explain a complex analysis to a non-technical audience.

*Situation:* I had completed a segmentation analysis showing which member groups were underusing preventive care services. The audience was a team of care coordinators with no data background.

*Task:* I needed them to act on the segments, not just nod along during the presentation.

*Action:* I dropped the technical slides entirely and built a one-page summary with a plain-language description of each segment and a specific suggested action per segment. I walked through two real anonymised member profiles so the pattern felt concrete rather than abstract.

*Result:* The coordinators prioritised the highest-risk segment in their outreach schedule for the next quarter. The following cycle's report showed stronger preventive screening uptake in that group.

---

Q: Describe a situation where you had to work with incomplete or messy data.

*Situation:* I was asked to build a trend report on pharmacy adherence, but the source data had inconsistent drug-name formatting across several regional systems.

*Task:* I had to standardise the data before any analysis was possible, without losing records or introducing false duplicates.

*Action:* I built a mapping table that normalised drug names to a master formulary list, applied fuzzy matching for records that did not join cleanly, and flagged a small residual set for manual review by the pharmacy operations team.

*Result:* The cleaned dataset covered the vast majority of records, the trend report shipped on time, and the mapping table was reused by two other analysts on subsequent projects.

For technical questions (SQL, Python, stats): Think out loud from the start. State what the query or approach needs to accomplish, write it step by step, then explain any trade-offs such as performance, edge cases, and null handling. Candidates report that Optum interviewers care more about reasoning than a perfect first attempt.

For data investigation questions (anomaly, pipeline drop, quality check): Use a structured diagnostic flow. Start with: is this a data issue or a real-world change? Then check volume, then check source systems, then check transformations. Name each step before diving into it so the interviewer can follow your logic.

For behavioural questions: Use the STAR format (Situation, Task, Action, Result). Keep Situation and Task brief, spend most of your time on Action (what you specifically did, not 'we'), and make the Result concrete, even if you can only say 'the report was adopted by the team' rather than quoting a metric.

For healthcare-specific questions (HIPAA, clinical data): Show awareness without overclaiming expertise. A line like 'I have not worked with PHI directly, but I understand the key obligations around de-identification and access controls' is honest and well-received. Interviewers want to know you will not accidentally create a compliance risk.

For stakeholder communication questions: Name the audience first ('the stakeholders were clinical operations managers with no SQL background'), then describe how you changed your communication style to match them. Specificity signals real experience.

Based on patterns candidates report from Optum Data Analyst interviews, interviewers evaluate several things beyond raw technical skill.

Healthcare domain curiosity. You do not need clinical expertise, but you should be able to discuss claims, pharmacy, or member data with some familiarity. Candidates who have done even basic reading on how health insurance data flows tend to stand out in the conversation.

Structured thinking under ambiguity. Many questions are deliberately open-ended. Interviewers want to see you impose structure on a fuzzy problem, not wait for them to narrow it down for you.

SQL depth, not just breadth. Window functions, CTEs, and performance awareness (indexes, avoiding SELECT *) represent the expected bar. Knowing that GROUP BY exists is not enough.

Communication as a default habit. Optum Data Analysts typically present findings to clinical, finance, and operations teams. Interviewers look for signs that you default to plain language and visual simplicity, not jargon-heavy slides.

Ownership of past work. When you describe a past project, be ready to explain every choice you made, including ones that did not work out. Deflecting to 'my team did...' is a common flag that interviewers notice.

Week 1: SQL and data fundamentals

Practise window functions (ROW_NUMBER, RANK, LAG, LEAD), CTEs, and multi-table joins on a healthcare-themed dataset if you can find one. Work through at least one claims aggregation or readmission problem from scratch. Review slowly-changing dimensions and fact-dimension table design.

Week 2: Domain and tools

Read one introductory overview of how health insurance claims flow from provider to payer to analyst. If you use Python, refresh pandas groupby, merge, and handling of missing values. If your background is more Excel or BI tools, be ready to explain the same logic you would apply in SQL.

Week 3: Behavioural and communication prep

Write out three to four STAR stories covering: a data quality fix, a stakeholder communication challenge, a time you worked under a tight deadline, and a time your analysis changed a decision. Practise saying them aloud, not just writing them.

Mock interview

Do at least one timed mock where you write SQL on paper or a plain text editor with no autocomplete. Optum technical rounds candidates report are sometimes conducted on a shared screen with a simple editor, so practise in that format.

Research Optum specifically

Read the job description line by line and map each requirement to a story or skill you can demonstrate. Interviewers notice when a candidate has clearly read the JD versus applying generically.

Over-engineering the SQL answer. Some candidates write a complex nested subquery when a simple CTE would be cleaner and easier to explain. Prioritise readable code you can walk through step by step.

Ignoring nulls. A very common interview trap is a dataset with nulls that changes the final answer. Always state how you would handle nulls before writing a query, even if the interviewer has not mentioned them.

Vague STAR answers. 'I helped improve the process' is not a result. Anchor your result to something observable: a report that shipped, a stakeholder who changed their decision, a pipeline that stopped failing.

Overclaiming on healthcare knowledge. If you have not worked in health data before, say so clearly and pivot to what you have done in adjacent domains such as finance, operations, or logistics. Trying to bluff on clinical terminology typically backfires.

Not asking clarifying questions. On open-ended problems, jumping straight to an answer without asking about data availability, granularity, or business context signals a habit that causes expensive mistakes in real work.

Arriving without questions. Interviewers at most companies, and candidates report this at Optum too, interpret 'no questions' as low interest. Prepare two or three genuine questions about the team's data stack or the problems they are currently solving.