Lseg Data Scientist Interview: Questions, Experience & Prep (2026)

LSEG (London Stock Exchange Group) is a global financial markets infrastructure company with a strong India presence. Following the Refinitiv acquisition, LSEG expanded its data and analytics capabilities, and Data Scientists there work on pricing models, risk analytics, financial indices, and workflow automation for traders and institutions worldwide.

With 129 open Data Scientist roles at LSEG as of July 2026, out of 937 Data Scientist openings tracked across India by knok jobradar, LSEG is one of the most active companies hiring for this profile right now.

Salary ranges for Data Scientists in India (knok jobradar, July 2026):

The interview process at LSEG typically spans multiple rounds covering Python coding, machine learning fundamentals, domain knowledge in financial data, and behavioral interviews.

Candidates report that LSEG interviews for Data Scientists typically cover these areas:

1. How would you build a model to detect anomalies in real-time trading data?
2. Explain how you would approach a class imbalance problem in a fraud detection dataset.
3. Walk us through a time you built a model that went into production. What were the challenges?
4. How do you evaluate a regression model when the business outcome is a financial risk score?
5. LSEG works with large time-series datasets from financial markets. How would you handle missing values in such data?
6. What is the difference between bagging and boosting? When would you use each in a financial prediction task?
7. How would you explain a complex machine learning model output to a non-technical stakeholder like a portfolio manager?
8. Describe your experience with Python libraries like pandas, scikit-learn, or PyTorch. Give an example of a production-grade pipeline you built.
9. How would you design an A/B test to measure the impact of a new pricing algorithm?
10. LSEG data products serve global clients. How would you ensure a model performs consistently across different markets or geographies?
11. Tell me about a situation where your analysis led to a business decision being reversed.
12. How do you stay current with advancements in NLP or large language models, and how could they apply to financial data?

Three STAR-format sample answers for common LSEG Data Scientist interview questions:

Q: Walk us through a time you built a model that went into production.

*Situation:* My team needed a model to flag high-risk trade settlements before they failed, reducing financial penalties for the firm.

*Task:* I was responsible for building the classification model, handling feature engineering from raw transaction logs, and coordinating with the engineering team on deployment.

*Action:* I started by analyzing several months of settlement data, identified key lag features like counterparty history and settlement time windows, and trained a gradient boosting classifier. I ran cross-validation with a time-based split to avoid data leakage, then worked with the DevOps team to containerize the model and set up monitoring for data drift.

*Result:* The model flagged high-risk settlements with strong recall in our holdout set and was deployed to the staging environment within a few weeks. The operations team reported a clear reduction in manual review time in the first month of use.

---

Q: How would you handle missing values in a large time-series dataset from financial markets?

*Situation:* On a previous project, I worked with tick-by-tick price data from multiple exchanges, and a meaningful portion of observations had missing values due to connectivity gaps.

*Task:* I needed an imputation strategy that preserved the temporal structure of the data without introducing future information.

*Action:* I used forward-fill as the primary method for short gaps, which is standard for financial time-series as it reflects the last known price. For longer gaps, I flagged those intervals separately and excluded them from evaluation. I also added a binary 'was_imputed' feature so the model could learn to discount those periods.

*Result:* The final model performed consistently across imputed and non-imputed periods, and the 'was_imputed' feature ranked among the top features by importance, validating the approach.

---

Q: Tell me about a situation where your analysis led to a business decision being reversed.

*Situation:* A product team at my previous company was about to deprecate a legacy data feed, believing it had low usage based on download counts.

*Task:* I was asked to do a usage analysis to confirm the decision before the team invested in migration work.

*Action:* I dug into the access logs and found that while raw download counts were low, the feed was used by several high-value institutional clients who queried it via API in small batches. I built a dashboard showing revenue attribution per feed and presented it to the product and sales leads.

*Result:* The deprecation was paused. The team invested in a modernized version of the feed instead, and one of the institutional clients expanded their contract the following quarter.

Two frameworks that work well for LSEG Data Scientist interviews:

STAR (Situation, Task, Action, Result) is the standard for behavioral questions. Keep the Situation and Task brief, spend most of your time on Action (what you specifically did), and close with a concrete Result. LSEG interviewers typically want to hear about production deployments, cross-functional collaboration, and dealing with messy real-world data.

PEDAL (Problem, Exploration, Design, Analysis, Learnings) works well for technical case questions, especially ones involving financial data. Define the problem clearly, explore the data you would want and why, design your modelling or analytical approach, explain how you would measure success, and close with what you would do differently or watch for in production. This framework shows structured thinking, which LSEG values because Data Scientists there work closely with product managers and quants who expect rigorous reasoning.

For both frameworks, tie your answer back to the business impact. At LSEG, this usually means risk reduction, pricing accuracy, client retention, or operational efficiency.

Based on what candidates report about LSEG Data Scientist interviews, interviewers look for four things:

Domain awareness. LSEG operates in financial markets infrastructure. You do not need to be a quant, but knowing what an index is, how settlement risk works, or why data quality matters in pricing will set you apart. Show you have read about LSEG's business lines before walking in.

Production mindset. LSEG is not a research lab. Interviewers want to know you have shipped models, not just notebooks. Talk about pipelines, monitoring, retraining, and how you handle model drift in a live system.

Communication across functions. Data Scientists at LSEG work with engineers, quants, and client-facing teams. Expect questions designed to see if you can explain a model decision to someone who does not know what a gradient is.

Python and SQL fluency. Candidates report that coding rounds focus on pandas, scikit-learn, and SQL for data manipulation. Know how to write efficient queries on large datasets and be ready to debug or optimize a given code snippet on the spot.

A four-week preparation plan for the LSEG Data Scientist interview:

Week 1: Company and domain foundation. Read LSEG's publicly available product pages on data analytics, indices, and risk solutions. Understand what Workspace (formerly Eikon) is and why financial professionals use it. Review basic financial concepts: bonds, equities, settlement, and market data feeds.

Week 2: Core data science and ML revision. Revise the fundamentals: bias-variance tradeoff, cross-validation, regularization, tree-based models, and evaluation metrics for imbalanced datasets. Candidates report that LSEG interviewers ask about these in the context of financial use cases, not generic textbook problems.

Week 3: Python and SQL practice. Practice writing pandas pipelines, handling time-series data, and optimizing SQL queries. Work through problems involving groupby operations, window functions, and joins on large tables. Focus on clean, readable code, since candidates report code reviews are part of some rounds.

Week 4: Behavioral stories and mock interviews. Prepare four to five STAR stories covering: a model you deployed, a time you dealt with bad data, a cross-functional collaboration, and a time you influenced a business decision with analysis. Practice saying these out loud, aiming for two to three minutes each.

If you are actively applying while you prepare, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so your applications keep moving while you focus on interview prep.

Common mistakes candidates make in LSEG Data Scientist interviews:

1. Skipping the business context. Jumping straight into model architecture without explaining what problem you are solving or why it matters. LSEG interviewers consistently ask 'so what did the business do with that?' Anchor every technical story to a real outcome.

1. Treating all data like clean tabular data. Financial data is messy, late-arriving, and often has structural breaks. If you only talk about standard imputation or normalization, you signal limited real-world exposure.

1. Overfitting your answers to theory. Reciting textbook definitions of precision and recall without explaining when you would prioritize one over the other in a specific business scenario loses points. Always connect concepts to decisions.

1. Not knowing LSEG's products at all. Candidates who have not done basic research on what LSEG actually sells are noticed. You do not need deep product knowledge, but showing you understand it is a financial data company (not just a tech company) matters.

1. Weak 'Result' in STAR answers. Ending a story with 'and it worked out well' instead of a specific outcome is the most common mistake. Use metrics where you have them; if you do not, describe the qualitative impact clearly.

1. Ignoring model monitoring. Saying you built a model and deployed it, with no mention of how you would know if it degraded in production, is a red flag for senior roles. Always mention how you would track performance after deployment.