An LSEG (London Stock Exchange Group) Codility invitation can create two very different reactions. First comes relief: your application moved forward. Then comes the harder question: what does a seven-question test actually look like, and will the percentage at the end decide whether you are shortlisted?
Before guessing at one anonymous candidate's questions, run a timed diagnostic with PracHub's real interview questions and written solutions. Use it to measure the things Codility is likely to expose quickly: problem recognition, implementation speed, debugging discipline, complexity, and edge-case coverage.
The most useful current evidence is specific, not universal. An August 2026 candidate applying through an Indian on-campus process for LSEG's 2027 graduate intake reported seven questions in two hours: six coding tasks and one multiple-choice question. A second recent account described about seven Codility tasks spanning problem solving and debugging. LSEG has not published that exact blueprint as a global standard, so your invitation remains the final authority.
This guide explains what the current reports do and do not prove, how Codility calculates an overall percentage, and how to prepare without relying on leaked questions or an imaginary cutoff.
Quick Answer: What Should You Expect?
For the reported India 2027 graduate batch, prepare for a two-hour Codility assessment with seven total items, including six coding tasks and one MCQ. Current reports suggest the coding portion may mix ordinary problem solving with debugging or code-fixing work rather than presenting six equally long algorithm problems.
The percentage shown after submission is an assessment score, not a percentile ranking. Codility says an overall test score combines points earned across tasks. Coding tasks can measure correctness and, where configured, performance on large inputs; tests may also use different task weights.
No public LSEG source confirms a universal passing score. A strong percentage can help, but the number alone does not let a candidate predict shortlisting with certainty. LSEG says applications are reviewed against programme requirements, recruiting proceeds on a rolling basis, and successful candidates receive an invitation to the next stage.
What LSEG Officially Confirms for the 2027 Programme
LSEG's official Graduate Programmes page lists a September 2027 start for its 12-month Engineering/Tech Graduate Programme. Locations include Bengaluru and Hyderabad as well as offices in Romania, Sri Lanka, Thailand, the United Kingdom, and the United States.
The programme covers the software development lifecycle from requirements and coding through testing and deployment. LSEG also highlights pathways such as cloud, DevOps, QA and automation, data, cybersecurity, and other emerging engineering areas. That breadth is one reason a mixed assessment can be more plausible than six identical DSA questions.
LSEG's broader Early Careers guidance says eligibility varies by programme and location. It also says applications are reviewed on a rolling basis, assessment deadlines appear in the invitation, and candidates who pass a stage receive the next invitation by email.
What LSEG does not publish is equally important. Its public pages do not promise seven questions for every country, name one global Codility cutoff, or explain a fixed formula for ranking all applicants.
Is the LSEG Codility Assessment Really Seven Questions?
The seven-question format is a credible current signal, but it should be labeled correctly.
- Detail: Platform; Current evidence: Two August 2026 candidate reports name Codility; Confidence: Medium for the reported India batch; How to use it: Practice in a browser-based coding environment
- Detail: Question count; Current evidence: One candidate reports 6 coding + 1 MCQ; another says around 7 tasks; Confidence: Medium; How to use it: Simulate several short tasks, not only two long problems
- Detail: Time limit; Current evidence: One on-campus candidate reports 2 hours; Confidence: Medium; How to use it: Rehearse a 120-minute mixed mock
- Detail: Task mix; Current evidence: Reports mention problem solving, debugging, and an AI/ML-related MCQ; Confidence: Low to medium; How to use it: Cover coding fundamentals and code reading; do not overfit to one MCQ topic
- Detail: Percentage result; Current evidence: One candidate says Codility displayed an overall score; Confidence: Medium; How to use it: Treat it as task points, not a percentile
- Detail: Shortlisting cutoff; Current evidence: No official LSEG cutoff is public; Confidence: Unknown; How to use it: Do not self-reject or assume progression from a guessed threshold
This article is therefore about the reported 2027 India graduate assessment, not every LSEG role. A database, DevOps, experienced-hire, internship, or another country's assessment can have different tasks and timing.
What the Seven Tasks May Be Testing
Six coding questions in two hours sounds extreme if you picture six full LeetCode mediums. The more reasonable preparation model is a mixed set with different scopes, although only your assessment screen can confirm the actual composition.
Short Implementation Problems
Expect some tasks where the main challenge is translating a compact specification into correct code. Arrays, strings, maps, sets, sorting, counting, and careful condition handling are high-value foundations because they support many short assessment problems.
The key skill is reaching a complete solution quickly without skipping the constraints. A ten-line implementation can still fail on duplicate values, empty results, integer overflow, or an incorrect boundary.
Debugging and Code-Fixing Tasks
A current candidate account explicitly mentions debugging. Codility's own task library includes bug-fixing tasks that ask candidates to correct existing code, sometimes with only a small number of changes.
Practice reading before rewriting. Reproduce the failure, identify the violated invariant, make the smallest justified change, and rerun both the failing case and a nearby regression case. This is closer to day-to-day engineering than memorizing an algorithm name.
One Technical MCQ
One candidate reported a single AI/ML-related MCQ. That is useful context, but one report is not a syllabus. Do not spend hours memorizing machine-learning trivia unless the job description emphasizes it.
Review the fundamentals connected to your role: time and space complexity, language behavior, data structures, testing, databases, operating systems, networking, and basic software engineering judgment. Use PracHub's software engineering fundamentals questions to find gaps after your coding diagnostic.
What Does the Codility Percentage Mean?
The clearest answer comes from Codility's official documentation. Its candidate report guide says the overall score combines points earned on each task. Individual coding tasks are scored for correctness and, where applicable, performance.
Correctness means passing test cases, including corner cases. Performance measures whether a solution remains practical on larger inputs. Codility also supports weighted scoring, so seven visible items do not necessarily contribute one-seventh of the final score each.
It Is Not a Percentile
A 60% result does not mean you performed better than 60% of candidates. It usually means your submission earned 60% of the available weighted points. Without LSEG's applicant distribution and decision rule, you cannot convert that into a rank.
It Is Not the Number of Questions Solved
Partial correctness matters. A solution may pass some hidden test groups and earn part of a task's points. Another solution may appear complete on samples but lose correctness or performance points on the full evaluation.
Passing Samples Does Not Guarantee Points
Codility explains that example cases exist to clarify the prompt and may not count toward the score. The submitted solution is checked against additional cases for requirements, corner cases, and scalability. This is why a reassuring OK during the test is not the same as a full final score.
Does the Percentage Decide LSEG Shortlisting?
The score almost certainly matters because it is the primary technical output of the assessment. Codility lets employers compare overall scores and inspect task-level results. But there is no evidence that one public percentage automatically determines every LSEG decision.
Codility allows employers to set their own passing score and recommends choosing it using internal test runs, expected candidate performance, desired progression volume, or historical data. That means a cutoff, if LSEG uses one for this campaign, can be specific to the assessment and hiring batch.
LSEG may also consider eligibility, application fit, assessment integrity signals, role demand, and available interview capacity. This is an inference from the platform's capabilities and LSEG's published process, not a claim about a secret LSEG formula.
Is 60% Enough?
No reliable public source can answer that. A current candidate reported a score in the 60s and was still waiting for clarity. That anecdote establishes uncertainty, not a threshold.
Prepare for the next round while you wait. If you advance, the invitation can arrive before you feel ready; if you do not, the same preparation transfers to other software engineering processes.
Does Below 40% Mean Automatic Rejection?
Not necessarily, based on public evidence. One current candidate reported a result below 40% and asked whether progression was still possible, but the discussion did not provide a verified outcome or official rule.
Do not confuse Codility documentation about default similarity-check processing with an LSEG hiring cutoff. A platform setting used to decide which submissions receive a plagiarism check is not proof of the employer's shortlist threshold.
A Better 120-Minute Strategy for Seven Questions
With many tasks, allocation matters more than solving in order. Use the first minutes to understand the entire scoring surface.
Minutes 0-8: Scan and Classify
Read all seven items and note the required output, constraints, likely complexity, and task type. If the interface displays weights, use them. Mark quick wins, medium implementations, and uncertain tasks.
Minutes 8-50: Bank Complete Solutions
Finish the clearest coding tasks first. After each one, test the minimum input, a normal case, duplicates or ties, and one boundary. Complete points are more valuable than six half-written ideas.
Minutes 50-95: Solve the Highest-Value Work
Move to the deeper implementation or debugging tasks. If two tasks look similar in difficulty, prefer the one with a clearer invariant or higher visible weight. Keep a hard stop so one stubborn problem does not consume the assessment.
Minutes 95-112: Capture Partial Credit and the MCQ
Return to incomplete tasks with a scoring mindset. A correct solution for a meaningful subset may earn points, but only if it compiles and follows the required interface. Answer the MCQ deliberately rather than leaving it to the final seconds.
Minutes 112-120: Defend Against Hidden Tests
Remove debug output, verify return types, and attack edge cases. Check empty or minimum inputs, all-equal values, duplicates, already sorted data, maximum sizes, overflow, and off-by-one boundaries.
What to Practice Before the LSEG OA
Start with implementation reliability. Practice arrays, strings, hash maps, sorting, prefix calculations, two pointers, and straightforward search. Add stacks, queues, heaps, graph traversal, and basic dynamic programming if your diagnostic shows those patterns are slow.
Then add debugging sessions. Take a working solution, introduce one boundary bug, and locate it using tests rather than random edits. Explain why the fix is sufficient. This trains the exact mental loop that code-fixing tasks reward.
Finally, rehearse in your chosen language. Know the standard library operations for maps, sets, sorting, queues, and parsing without looking them up. Complete at least one seven-item mock under a two-hour timer, because six familiar topics can still become difficult when context switching is slow.
Use the PracHub coding and algorithms collection for targeted drills, then switch to the software engineer question bank for a realistic mixed diagnostic.
A Five-Day LSEG Preparation Plan
On Day 1, run a timed diagnostic and label every lost point: misunderstanding, wrong complexity, syntax, implementation bug, or missed edge case. Your error pattern should decide the rest of the week.
On Day 2, repair arrays, strings, hashing, sorting, and complexity analysis. Complete submissions from a blank editor and test them against adversarial cases.
On Day 3, focus on code reading and debugging. Fix several small programs, state the invariant before editing, and verify that your change does not create a regression.
On Day 4, take a full 120-minute mixed mock with six coding tasks of varied length and one technical MCQ. Use the scan-first strategy and record where the clock changed your decisions.
On Day 5, redo only the failed tasks, review language syntax and core CS concepts, and verify the real invitation's deadline, allowed languages, browser requirements, and monitoring rules. Do not cram leaked prompts.
What Happens After the LSEG Codility Assessment?
LSEG's official Early Careers page says candidates receive an email invitation when they successfully pass an assessment stage, and that applications are reviewed on a rolling basis. It does not promise a universal response time.
The next step can differ by programme and region. LSEG's public guidance references later video and assessment stages, while company engineering hiring can include technical interviews and coding challenges. Your recruiter email is more reliable than a timeline from another office.
Use the waiting period for company-specific interview preparation. Practice explaining code, discussing trade-offs, and answering follow-ups, then prepare concise stories about ownership, collaboration, learning, and failure with PracHub's behavioral and leadership questions.
Practice with real questions from PracHub
PracHub does not currently have an eligible visible LSEG coding-console record for this page. The questions below are cross-company substitutes selected from real candidate reports. Their actual company and stored round stay visible; none is presented as a reported LSEG question.
- Question: Q1: Solve Prime Jumps and Pipeline Scaling; Evidence: Uber · Technical Screen; Difficulty: Medium; Main pattern: Graphs
- Question: Q2: Count Special Index Pairs; Evidence: Google · Technical Screen; Difficulty: Medium; Main pattern: Arrays and hashing
- Question: Q3: Implement an In-Memory Database; Evidence: Two Sigma · Technical Screen; Difficulty: Hard; Main pattern: Strings
- Question: Q4: Solve scheduling and collision problems; Evidence: J.P. Morgan · Technical Screen; Difficulty: Medium; Main pattern: Intervals
What the prompts actually ask
Q1. Solve Prime Jumps and Pipeline Scaling
Bank evidence: Uber, Technical Screen, Medium. An online assessment contains two independent coding problems. Solve both. Problem 1: Prime-Constrained Score Jump You are given an integer array score of length n and an integer k. You start at index 0, and your initial total is score[0].
Q2. Count Special Index Pairs
Bank evidence: Google, Technical Screen, Medium. Given an integer array nums of length n, count the number of index pairs (i, j) such that: - 0 <= i < j < n - nums[i] nums[j] is even - j - i is odd Return the total number of special pairs. Constraints & Assumptions - A product is even if at least one of the two numbers is even.
Q3. Implement an In-Memory Database
Bank evidence: Two Sigma, Technical Screen, Hard. Implement a simple in-memory relational database that processes a sequence of tokenized commands. You are given commands: List[List[str]], where each command is already split into tokens. Process the commands in order and return the result of every select command. Support the following operations: 1.
Q4. Solve scheduling and collision problems
Bank evidence: J.P. Morgan, Technical Screen, Medium. The interview included multiple algorithm questions in the same category: 1. Minimum concurrent resources for intervals You are given a list of time intervals, where each interval represents a meeting or a CPU task with a start time and an end time.
Run the set like an assessment
- Read all four prompts first. Give each a difficulty estimate and choose an order before coding.
- Hide the solution. Write the invariant, complexity target, and three edge cases before opening the editor.
- Use one timer. Preserve five minutes at the end for boundary, tie, scale, and output-format tests.
- Log the failure mode. Record the broken invariant or missed edge case, not merely the question title.
Frequently Asked Questions
Does LSEG use Codility for the 2027 graduate assessment?
Two current August 2026 candidate reports identify Codility for an LSEG Early Careers or 2027 graduate engineering assessment in India. LSEG does not publicly promise one platform for every programme, country, or experienced-hire role, so confirm the provider named in your own invitation.
Is the LSEG Codility assessment always seven questions?
No universal format is published. One current on-campus candidate reported six coding questions plus one MCQ in two hours, and another described around seven tasks. Treat that as a strong preparation signal for the reported batch, not a guarantee for every LSEG assessment.
What percentage is required to pass the LSEG assessment?
LSEG has not published a universal cutoff. Codility supports employer-defined passing scores and weighted tasks, so any threshold can depend on the test configuration, role, applicant pool, and hiring campaign. A score reported by another candidate cannot reliably predict your outcome.
Can LSEG see more than the final score?
Codility's employer report can include task-level correctness and performance, a coding timeline, out-of-focus events, pasted text, and configured integrity signals. The exact monitoring features depend on the employer's settings. Follow the rules displayed before your own assessment.
How soon does LSEG respond after the OA?
LSEG says applications are reviewed on a rolling basis and successful candidates receive the next-stage invitation by email, but it does not give one guaranteed response window. Monitor your inbox, spam folder, and candidate portal while continuing to prepare.
Final Takeaway
The reported LSEG Codility Assessment 2027 is best treated as a mixed, high-tempo engineering screen, not a hunt for six remembered LeetCode prompts. Seven items in two hours reward triage, complete implementations, debugging, and disciplined hidden-test checks.
Your displayed percentage reflects earned task points; it is not a percentile and does not reveal a public LSEG shortlist formula. Once you submit, stop trying to reverse-engineer a cutoff you cannot verify. Use PracHub's real company interview questions to prepare for the next technical stage and for the other processes your skills can unlock.
Sources and Methodology
This guide was updated on August 15, 2026. Official programme details and process guidance come from LSEG's Graduate Programmes, Early Careers, and engineering career journey pages.
Scoring explanations come from Codility's official documentation on candidate reports, solution assessment, weighted scoring, and candidate result visibility.
The seven-question format is based on an August 2026 LSEG 2027 on-campus candidate discussion and a separate LSEG Early Careers Codility account. These reports are anecdotal, role- and batch-specific, and are not presented as official LSEG policy. This article intentionally avoids reproducing proprietary assessment questions.
Originally published on PracHub.
Top comments (0)