EXL Service Data Architect Interview: Questions, Experience & Prep (2026)

EXL Service is a global analytics and digital operations company with a strong foothold in insurance, banking, healthcare, and financial services. With 398 open roles currently listed, EXL is hiring at scale, and Data Architect positions sit at the core of its analytics delivery model.

Knok's job radar tracked 57 Data Architect openings across India as of July 2026, with the most activity in Delhi (8), Bangalore (7), and Chennai (5), followed by Hyderabad (2) and Pune (1). The interview process typically spans two to four rounds, covering technical design, domain knowledge, and stakeholder communication. Candidates report that EXL panels value structured thinking and the ability to translate a business problem into a scalable data solution, not just familiarity with tools.

These questions are drawn from candidate reports and EXL's publicly stated focus areas. Expect the panel to probe both technical depth and your ability to work with client teams.

1. Walk us through a data architecture you designed end-to-end. What decisions did you make and why?
2. How do you choose between a data warehouse and a data lake for a given use case?
3. Describe your approach to data modelling and give an example where a poor model caused downstream problems.
4. How have you handled data governance or data quality issues in a previous project?
5. EXL works heavily in insurance and BFSI. How would you design a claims data model for an insurance carrier?
6. What is your experience with cloud data platforms such as Azure Synapse, AWS Redshift, or Google BigQuery?
7. How do you approach master data management in an enterprise with multiple source systems?
8. A client's reporting pipeline is slow and producing inconsistent numbers. How do you diagnose and fix it?
9. Explain the difference between a star schema and a snowflake schema, and when you would choose each.
10. How do you ensure a data architecture remains scalable as volumes grow by an order of magnitude?
11. Describe a time you had to convince a non-technical stakeholder to change their approach to data. How did you do it?
12. How do you manage metadata and data lineage across a complex multi-source environment?

Use these as templates. Swap in your own context and project details.

Q: Walk us through a data architecture you designed end-to-end.

*Situation:* A mid-size insurance client had policy, claims, and agent data sitting in three separate legacy systems with no unified view for reporting.

*Task:* I was asked to design a consolidated architecture that would support both operational reporting and predictive analytics.

*Action:* I started by mapping all data sources and their refresh frequencies. I proposed a medallion architecture on Azure Data Lake: a raw layer for ingestion, a curated layer for cleaned and standardised data, and a consumption layer modelled as a star schema for BI tools. I worked with the client's IT team to define data contracts and built quality checks at each layer boundary. I also documented lineage using Azure Purview so the compliance team could trace any number back to its source system.

*Result:* The client moved from four-day-old batch reports to near real-time dashboards, and the compliance team signed off without a single audit finding in the first quarter.

---

Q: How have you handled data quality issues in a previous project?

*Situation:* During a healthcare analytics project, a key metric showed a significant discrepancy when compared against the client's manual counts. Everyone blamed the ETL pipeline.

*Task:* I needed to find the root cause and fix it without stopping the daily reporting cycle.

*Action:* I traced the lineage of the metric field back through three transformation steps. I found that two source tables used different patient ID formats, and a join was silently dropping rows. I introduced a reconciliation check that compared row counts before and after every join and raised an alert when the drop exceeded the agreed threshold. I also added a data quality dashboard so the analytics team could catch similar issues before they surfaced in reports.

*Result:* The metric reconciled to within the agreed tolerance, and the team independently caught two more similar issues the following month before they reached any dashboard.

---

Q: Describe a time you convinced a non-technical stakeholder to change their approach to data.

*Situation:* A finance director at a banking client insisted on storing all historical transactions in a single flat table, saying 'it is simpler for the business team to query.'

*Task:* I needed to explain why that design would create serious performance and governance problems at scale, without making the director feel dismissed.

*Action:* Instead of showing an entity-relationship diagram, I built a simple spreadsheet comparing query times at current data volumes versus projected volumes, using publicly reported industry growth benchmarks. I also highlighted two regulatory requirements around data retention that a flat structure would make harder to enforce. I then offered a hybrid approach: a business-friendly virtual table on top of a properly normalised physical model, so the director kept the simplicity they wanted at the query layer.

*Result:* The director approved the redesign, and the virtualised query layer became the standard reporting interface for that client's entire finance team.

For design questions: Use a 'Context, Options, Decision, Trade-offs' structure. State the business context first, name two or three architectural options you considered, explain which you chose and why, then call out the trade-offs you accepted. EXL interviewers want to see that you do not jump straight to one solution.

For diagnostic questions: Use 'Observe, Hypothesise, Test, Fix.' Describe what symptoms you observed, list your hypotheses in order of likelihood, explain how you tested each, and then describe the fix. This shows systematic thinking rather than guesswork.

For stakeholder questions: Use 'Audience, Concern, Bridge, Outcome.' Identify the stakeholder's actual concern, which is often not what they say out loud. Find a bridge between their language and the technical reality. Propose the change and state what resulted. EXL values consultative skills because Data Architects interface directly with client teams.

For domain questions covering insurance or BFSI: Show that you know the business objects such as policy, premium, claim, and loss ratio before you start talking about tables and schemas. Name the regulatory or compliance constraints that shape the data model. EXL's clients are often regulated entities, and awareness of compliance signals maturity to the panel.

EXL Data Architect panels typically look for four things.

Technical rigour: You should be comfortable designing schemas, discussing normalisation trade-offs, selecting cloud platforms for given workloads, and explaining the difference between ETL and ELT approaches. Vague answers like 'it depends on the situation' with no follow-up on the actual factors tend to end conversations quickly.

Domain familiarity: EXL's core verticals are insurance, banking, financial services, and healthcare. Candidates who can speak about claims data, policy administration, or patient data flows without needing a glossary stand out clearly. If your background is in a different domain, bridge to it explicitly: 'In retail, the equivalent of a claims cycle is the returns process, and here is how I handled the data side of it.'

Client communication: EXL delivers to external clients, so interviewers want evidence that you can explain a complex design decision to a business audience. Use concrete examples from your own experience rather than theoretical descriptions.

Scalability thinking: Interviewers will probe whether your designs anticipate growth or need to be rebuilt every few years. Mention partitioning strategies, indexing, caching layers, or incremental loading patterns wherever they are relevant to what you are describing.

Week 1: Technical foundation
Revise data modelling concepts, including star schema, snowflake schema, and data vault, and practise explaining when you would choose each. Draw entity-relationship diagrams for insurance or banking scenarios from scratch. Review the key differences between OLTP and OLAP and be ready to explain them conversationally.

Week 2: Cloud and tooling
Pick one cloud platform you know best (Azure, AWS, or GCP) and be able to map a full architecture onto it from ingestion to consumption. Review at least one data catalogue or metadata tool such as Azure Purview, AWS Glue Data Catalog, or Apache Atlas.

Week 3: Domain and case prep
Read EXL's published case studies and annual reports to understand the industries they serve. Prepare two or three stories in STAR format from your own experience. Practise answering out loud, not just in your head, because EXL interviews are conversational rather than whiteboard-heavy.

Week 4: Mock rounds and review
Complete at least two mock interviews with a peer or mentor. Record yourself answering 'walk me through a design you built' and listen back for filler words and vague claims. Tighten any answers that lack a concrete result.

Knok checks 150+ job sites nightly, applies to Data Architect roles matching your resume, and messages HR for you, so new EXL openings reach the right contact before most candidates have even refreshed the job board.

Jumping to a solution without stating assumptions. Data Architect interviews reward structured thinking. Naming a technology in your first sentence without explaining what business problem it solves signals pattern-matching rather than genuine design.

Ignoring data governance and lineage. Many candidates focus entirely on pipelines and schemas and forget that enterprises need to know where data comes from and who changed it. Weave governance into your answers naturally rather than treating it as an afterthought.

Treating domain knowledge as optional. EXL's clients are in regulated industries. Saying 'I have not worked in insurance but I can learn quickly' is a weaker position than 'In my BFSI project I worked with transaction and settlement data, which has similar compliance constraints to claims data.'

Underplaying stakeholder work. Candidates sometimes describe technical decisions without mentioning how they got buy-in. At a consulting-oriented firm like EXL, interviewers want evidence that you can sell a design to a sceptical client, not just build it.

Not preparing questions to ask. Candidates report that strong applicants ask about the data maturity of the client engagement, the team structure, and what success looks like in the first six months. Asking nothing at the end signals low engagement.