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

LSEG (London Stock Exchange Group) runs exchanges, clearing houses, and data platforms used by banks, funds, and regulators worldwide. Their India engineering teams, primarily in Bangalore, Delhi, Hyderabad, and Pune, build pipelines that process billions of financial records daily: tick data, reference data, risk feeds, and compliance outputs.

With 129 open Data Engineer roles at LSEG right now, it is one of the most active hirers in this space. The process typically runs three to four rounds. Candidates report a technical screening call, a hands-on coding or case assignment, a system design discussion, and a final panel with senior engineers or a hiring manager. Exact structure and sequence vary by team and business unit.

Salary at a glance (Data Engineer, India market-wide):

These are market-wide ranges. LSEG-specific compensation is not publicly reported at a level that lets us quote it separately. Across the 542 Data Engineer openings tracked in the broader market, Bangalore leads with 92 openings and Delhi follows with 66.

These questions reflect themes candidates commonly report from LSEG data engineering interviews across product, risk, and compliance teams.

1. Walk us through how you would design a real-time pipeline to ingest and process high-frequency market tick data.
2. How do you handle late-arriving or out-of-order events in a streaming system? What trade-offs did you make in your approach?
3. Describe your approach to data quality checks at scale. How do you prevent bad data from reaching downstream consumers?
4. LSEG is heavily invested in Azure. What Azure managed services have you used for data engineering, and how did you choose between them?
5. How would you model a data lake or lakehouse to serve both raw market data and processed analytics layers?
6. Explain slowly changing dimensions (SCD). When would you use SCD Type 2 for financial reference data such as instrument or counterparty records?
7. Have you worked on pipelines with regulatory requirements such as MiFID II or EMIR? How did compliance constraints shape your design choices?
8. How do you manage schema evolution when upstream producers change their data structures without warning?
9. Describe a time you diagnosed and fixed a slow Spark job or SQL query on a very large dataset. What was the root cause?
10. How do you implement data lineage and auditability in a pipeline that handles sensitive financial data?
11. What is your experience with Apache Kafka or similar message brokers? How have you handled consumer lag or partition imbalance in production?
12. How do you approach access control and data governance for datasets that mix public market data with confidential client information?

Use these as templates. Swap in your own project specifics.

Q: How do you handle late-arriving events in a streaming pipeline?

*Situation:* At my previous company we built a real-time P&L calculation service that consumed trade events from Kafka. Occasionally, enrichment systems sent corrected events long after the original event had already been processed.

*Task:* I needed to ensure the P&L numbers stayed accurate without reprocessing the entire day's data each time a late event arrived.

*Action:* I introduced a watermark strategy in Apache Flink with a configurable late-arrival window. Events arriving after the window closed were routed to a separate correction queue, which fed a micro-batch reconciliation job that ran on a regular schedule. I also added a dead-letter topic so no event was ever silently dropped.

*Result:* Late-event corrections that previously required manual reconciliation work were handled automatically. The team reported a clear reduction in overnight data-fix tickets, though I cannot share exact internal figures.

---

Q: Describe a time you improved the performance of a slow Spark job.

*Situation:* A nightly job joining reference data with several months of trade records was running well beyond the morning business SLA, delaying risk reports the trading desk needed at market open.

*Task:* I was asked to bring the runtime within the required window without changing the output schema.

*Action:* I profiled the job and found two root causes: a massive shuffle from a skewed join key (a handful of high-volume instruments dominated the data) and repeated full reads from unpartitioned Parquet files. I applied salting to the skewed join, repartitioned the Parquet layer by instrument date, pushed filter predicates down to the file scan, and replaced a broadcast join on a table that was too large to fit in driver memory.

*Result:* Runtime dropped well within the target, and the risk team received their morning reports reliably before market open.

---

Q: How have you handled data quality in a high-volume financial pipeline?

*Situation:* Our team ingested pricing data from multiple vendor feeds. Different vendors used different conventions for null prices, zero prices, and stale quotes, causing silent errors in downstream analytics.

*Task:* I was responsible for designing a quality gate that caught bad records before they reached the analytics layer.

*Action:* I built a validation layer using Great Expectations, defining rules around price ranges, timestamp monotonicity, and cross-feed consistency. Failing records were routed to a quarantine table with a reason code attached. A daily summary went to the data operations team, and an alert fired if the failure rate crossed a threshold within the first hour of market open.

*Result:* The team caught a vendor-side pricing error within the first trading hour rather than discovering it post-close. The quarantine log became the source of truth for vendor SLA discussions.

STAR for behavioural questions: Open with a brief Situation (one or two sentences of context), the Task (your specific responsibility), the Action (steps you took, using 'I' not 'we'), and the Result (business impact or measurable improvement). If you cannot share exact numbers due to confidentiality, describe the direction of improvement and say so. Interviewers respect honesty about what you can and cannot disclose.

For system design questions: Start by asking clarifying questions about scale, latency needs, and consistency requirements before drawing anything. Then walk through your architecture in layers: ingestion, processing, storage, and serving. Call out trade-offs at each layer. LSEG interviewers reportedly value how you reason through options, not just whether you arrive at a particular tool.

For debugging and optimisation questions: Lead with how you diagnosed the problem before explaining the fix. Describe the signals you used (profiling output, query plans, job metrics) to identify the root cause. This shows engineering discipline rather than trial-and-error guessing.

For regulatory or compliance questions: Show that you understand why the requirement exists, not just what it says. Mention auditability, data lineage, and the real-world consequences of getting it wrong. LSEG operates under strict financial regulations, and interviewers want engineers who treat compliance as a design input from the start, not an afterthought.

Candidates who have interviewed at LSEG commonly report that interviewers prioritise a few things above raw tool knowledge.

Domain awareness. LSEG's core product is financial data. Interviewers want to see that you understand concepts like tick data, reference data, and settlement flows, and why accuracy in these systems has real-world consequences. You do not need to be a quant, but speaking the language of the domain makes a clear difference.

Production-grade thinking. LSEG runs critical market infrastructure. Answers that stop at 'it works in dev' tend to fall flat. Talk about monitoring, alerting, failure recovery, SLAs, and what happens when something breaks at market open on a high-volume day.

Trade-off reasoning. Interviewers frequently report caring less about a single 'correct' architecture than about how a candidate thinks through options. State your assumptions, explain your choices, and acknowledge what you are giving up with each decision.

Azure and cloud-native fluency. LSEG has a deep strategic partnership with Microsoft. Familiarity with Azure Data Factory, Azure Databricks, Event Hubs, and Delta Lake is a visible plus. Candidates who can map open-source tools to their Azure equivalents and explain when to prefer one over the other tend to stand out.

Collaboration and communication. Data engineers at LSEG work closely with quants, risk teams, and compliance officers. Interviewers look for candidates who can explain technical decisions to non-engineering stakeholders clearly and without unnecessary jargon.

Week 1: Core technical revision
Revisit distributed systems fundamentals: partitioning, replication, exactly-once semantics, and the CAP theorem in plain terms. Practice writing SQL window functions, CTEs, and reading query execution plans. Set up a small Kafka plus Spark Structured Streaming project locally if you do not have recent hands-on experience with either.

Week 2: LSEG-specific context
Read LSEG's public engineering blog and product pages to understand their key business lines: Workspace, FTSE Russell, and LCH clearing. Study what MiFID II transaction reporting requires from a data pipeline at a conceptual level. Candidates report that showing genuine domain awareness in the first round creates a strong early impression.

Week 3: System design and behavioural prep
Practice designing a market data ingestion pipeline end to end: raw feed to analytics-ready table, covering schema evolution, late data handling, and audit logging. Write out three to five STAR stories from your past work that cover debugging at scale, cross-functional collaboration, and a time something went wrong and how you resolved it.

Week 4: Mock interviews and Azure review
Do at least two timed mock sessions with a peer or mentor. Focus on thinking out loud during design questions. Review Azure documentation for Data Factory, Databricks, and Event Hubs so you can speak confidently to managed-service trade-offs.

If you are actively applying at the same time, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR directly on your behalf, so your job search runs in the background while you focus on preparation.

Treating LSEG like a generic tech company. LSEG is financial markets infrastructure, not a consumer product firm. Answers that ignore data accuracy, regulatory traceability, or market-hours constraints miss what their data engineers actually do day to day.

Jumping to solutions without clarifying requirements. In system design rounds, candidates who immediately name tools without asking about scale, latency, or consistency constraints tend to score lower. Interviewers at LSEG reportedly value the questions you ask before you start answering.

Vague STAR answers. Saying 'I improved pipeline performance' without explaining how you diagnosed the issue, what you changed, or what the outcome was gives the interviewer nothing to evaluate. Quantify where you can, and explain confidentiality constraints where you cannot.

Weak streaming fundamentals. Many candidates can name Kafka and Spark but cannot explain when to choose micro-batch over true streaming, or how to guarantee exactly-once delivery. LSEG pipelines are often latency-sensitive, and this gap surfaces quickly in a technical discussion.

Defaulting to on-premise or non-Azure tools. If your instinct is always open-source Hadoop without acknowledging Azure equivalents, you may come across as out of step with LSEG's cloud direction. Show that you know both and can choose deliberately based on the requirements.

Not asking questions at the end. Candidates who ask nothing tend to come across as disengaged. Prepare two or three genuine questions about the team's current pipeline challenges, how they handle regulatory data changes, or what the on-call experience looks like for a data engineer on that team.