Cigna Data Scientist SQL and Coding Interview 2026
TL;DR
Cigna’s Data Scientist SQL and coding interviews prioritize real-world query precision over algorithmic complexity. Candidates fail not from syntax gaps, but from misaligned business logic. The bar is execution under ambiguity—your code must defend a decision, not just return rows.
Who This Is For
You are a mid-level data scientist with 2–5 years of experience, applying to Cigna roles like Data Scientist II or Healthcare Analytics Specialist. You’ve passed resume screens at UnitedHealth, Optum, or CVS, but stalled at onsite stages. You understand joins and aggregations, but struggle when interviewers pivot from coding to “So what would you tell the business?”
What does Cigna’s Data Scientist SQL round actually test?
Cigna’s SQL interviews test diagnostic precision, not query speed. In a Q3 2025 debrief, a candidate wrote flawless syntax but was rejected because they counted patient claims instead of unique members—misreading eligibility rules buried in the schema notes. The issue wasn’t the GROUP BY; it was the assumption.
Hiring managers aren’t looking for LeetCode-style optimization. They want to see you validate edge cases: active vs. terminated coverage, overlapping plan periods, claims with zero-dollar liability. One HM told me, “If you don’t check for dual enrollment, you’ll overcount utilization by 18% in real reports.”
Not a syntax test, but a logic containment exercise.
Not about window functions, but about temporal integrity.
Not “can you write SQL,” but “can you defend your counts?”
In a real 45-minute session, you’ll get one prompt: analyze utilization trends in a Medicare Advantage population. You’ll have three tables—members, claims, and planeffectivedates. The catch? Gaps in coverage create artificial spikes. The strong candidates add lead/lag checks to isolate continuous enrollment. The rest get tripped up by double-counting.
You have 10 minutes to ask clarifying questions. Use them. One candidate passed solely because they asked, “Are we counting service dates or paid dates?” That question surfaced a known data quality issue in Cigna’s legacy warehouses.
How is Cigna’s coding screen different from tech companies?
Cigna’s coding screen focuses on data shaping, not algorithm design. Unlike Amazon or Meta, you won’t reverse a binary tree. Instead, you’ll clean and reframe clinical data for business consumption.
In a recent screen, candidates received a CSV of ER visits with missing triage codes and inconsistent facility IDs. The task: standardize facilitytype (e.g., “Urgent Care,” “Freestanding ED”) and flag visits likely to result in admission. One candidate used regex and casewhen logic to map facility strings—solid, but incomplete. The top scorer added a secondary layer: they joined to a reference table of ZIP codes to infer urban vs. rural settings, then flagged facilities with >30% admission rates as potential observation units.
The difference? Context stacking. Tech screens reward minimal, elegant code. Cigna rewards contextual scaffolding.
Not clean code, but clinically grounded code.
Not runtime efficiency, but domain fidelity.
Not code golf, but risk-aware transformation.
Python is tested in pandas, not recursion. You’ll get a DataFrame of lab results and need to compute rolling 90-day averages per patient. The trap? Patients with sparse data. The HM wants to see you handle small-N cases—cap the average, impute conservatively, or exclude with justification.
One debrief turned on missingness logic. A candidate used .fillna(0) on hemoglobin levels. The HC lead shut it down: “Zero isn’t missing. Zero is fatal. That’s a clinical misread.” The hire used forward-fill with a 14-day window and documented the assumption.
What kind of case study appears in the onsite coding session?
The onsite case study is a 90-minute take-home: analyze cost drivers in a commercial diabetes cohort. You get synthetic data—member demographics, claims, pharmacy fills, and HbA1c trends. Deliverable: a Jupyter notebook with code, visualizations, and 3–5 recommendations.
The top submissions don’t start with code. They begin with cohort definition. In one HC meeting, two candidates built identical regression models. One was rejected. Why? They included members with only one pharmacy fill—likely false positives. The other restricted to members with ≥2 fills and a diagnostic code, citing CDC guideline thresholds.
Cigna values diagnostic rigor over model complexity. A simple bar chart with clean labels and a risk-adjusted comparison beat a ROC curve in two separate evaluations last year.
Not insight density, but decision clarity.
Not model accuracy, but cohort validity.
Not statistical novelty, but clinical plausibility.
One candidate passed by identifying a spike in insulin costs tied to a single specialty pharmacy. Their code isolated NPI-level spend and flagged it for formulary review. The HM said, “That’s the exact pattern we’re trying to catch in real life.”
Another failed by building a random forest to predict hospitalization without first checking for data leakage—future lab values were in the training set. The HC noted, “This wouldn’t pass peer review in our actuarial team.”
You must document assumptions. One line: # Assuming no prior treatment history for members under 18. That’s the signal they want—explicit reasoning, not implicit defaults.
How much Python do you actually need?
You need pandas and basic control flow—not Django or pytest. Cigna’s Python screen is a 45-minute live session focused on data transformation, not software engineering.
In Q2 2025, the prompt was: “From a claims DataFrame, calculate the gap in care for colorectal cancer screening.” You had memberid, lastcolonoscopydate, birthdate, and enrollment_start. The solution required:
- Age calculation at end of year
- Identify members aged 45–75
- Flag those without a colonoscopy in the last 10 years
- Adjust for disenrollment gaps
The weak solutions used .apply() with lambda and missed the disenrollment adjustment. The strong ones used vectorized operations and a left join to enrollment history.
One candidate failed because they treated birth_date as screening eligibility. The HM said, “Age at screening matters, not birth. You’re auditing performance, not predicting.”
Not computer science, but audit logic.
Not function elegance, but temporal correctness.
Not code reuse, but regulatory alignment.
You won’t write classes or decorators. You will write functions that mirror Cigna’s internal quality measures—HEDIS, STAR, or CDC benchmarks. Know how those define compliance windows.
If you can write a function that calculates denominator (eligible members) and numerator (met criteria) for a clinical measure, you’re ahead.
How do they evaluate coding during the onsite?
Cigna evaluates coding on three dimensions: correctness, maintainability, and defensibility. In a debrief last November, two candidates produced identical outputs. One was rejected. The difference? Code comments.
The rejected candidate wrote: # filter data.
The hire wrote: # restrict to continuously enrolled members to avoid undercounting preventive service gaps, per HEDIS RXC-1.
The HC valued explicit justification over brevity. One senior reviewer said, “We deploy these analyses. If someone can’t read your code and trust it, it doesn’t matter if it runs.”
Comments must reflect policy awareness. “Excluding Medicaid duals” isn’t enough. “Excluding Medicaid-Medicare dual eligibles per CMS risk adjustment guidelines” is.
Not code that works, but code that withstands audit.
Not efficiency, but traceability.
Not cleverness, but compliance.
Variable names matter. memberid is fine. idx1 is not. One candidate used tmpdf_2 after a join. The HM noted, “We don’t know what that is. That doesn’t scale.”
You’ll be asked to explain a line of your code. One candidate was asked, “Why did you use a left join here instead of inner?” They answered, “Because I want to preserve members even if they have no claims—those are the healthy ones we’re trying to identify.” That response alone elevated their score.
Preparation Checklist
- Take a real Cigna-like dataset (e.g., CMS public use files) and write a HEDIS measure calculation from scratch
- Practice writing SQL that handles time gaps in enrollment—use LEAD/LAG to detect breaks
- Build a pandas notebook that computes a quality metric with documented numerator/denominator logic
- Memorize 3–5 clinical guidelines (e.g., USPSTF screening intervals) to justify cohort rules
- Work through a structured preparation system (the PM Interview Playbook covers healthcare data case studies with real HC debrief examples from UnitedHealth and Cigna)
Mistakes to Avoid
- BAD: Writing SQL that assumes every claim line is a unique event
One candidate counted ER visits by counting claim lines. But a single visit can have 5–10 lines (facility, radiology, physician). They overcounted by 300%.
- GOOD: Aggregating claims to visit level using claimid and servicedate, then deduplicating by member and facility
- BAD: Using .dropna() without assessing missingness mechanism
A candidate removed all rows with missing lab values. The HM asked, “Are those tests not ordered, or not recorded?” The candidate couldn’t answer.
- GOOD: Stratifying missingness by facility type and flagging for data quality review
- BAD: Returning a p-value without checking distribution assumptions
One data scientist ran a t-test on readmission costs without log-transforming. The HC noted skewed distributions invalidate the test.
- GOOD: Plotting distribution, applying log transformation, and stating assumption checks in comments
FAQ
Do Cigna Data Scientist interviews include LeetCode-style problems?
No. You will not see trees, graphs, or dynamic programming. Coding is applied to healthcare data transformation—cleaning, aggregating, and validating. One 2025 session included a string parsing task for ICD codes, but that was the most complex algorithmic ask.
Is Python or SQL weighted more in the evaluation?
SQL is slightly more important. You’ll use it in every round. Python appears in the take-home and one live session. Strong SQL with basic Python beats strong Python with shaky joins. Most rejections trace to incorrect patient counts, not inefficient code.
How long does the coding process take from screen to offer?
The average timeline is 21 days. Day 1: recruiter call. Day 3–5: SQL screen. Day 7–10: take-home case. Day 12–15: onsite with live coding. Day 18–21: HC decision. Delays occur if the HM is reviewing utilization reports during Q4 open enrollment.
Ready to build a real interview prep system?
Get the full PM Interview Prep System →
The book is also available on Amazon Kindle.