The coding bar at Barclays is LeetCode-medium, not the ninety-minutes-of-hard-DP gauntlet you get at a top-tier product company. That’s the first thing to calibrate. If you’re coming off a FAANG prep grind, you’re probably over-prepared on algorithms and under-prepared on the part Barclays actually cares about: whether you write clean, correct code, reason about a real system, and can talk through how a trade moves across a platform without hand-waving.
Barclays hires engineers along two tracks that feel different once you’re in the room. One is mainstream software engineering, spanning the retail bank, payments, risk, and the large platform teams in Glasgow, London, and Whippany, New Jersey. The other is markets technology and strats, closer to the trading floor, where BARX (the bank’s cross-asset electronic trading platform) lives and where quant-leaning developers price, hedge, and route orders in code. The process rhymes across both. What they push on is where the two diverge.
The rounds, from application to offer
For graduate and early-career roles it opens with an online application and a set of timed assessments: numerical and logical reasoning, plus a situational-judgement test that scores your answers against the bank’s values (Respect, Integrity, Service, Excellence, Stewardship, which internally get shortened to RISES). Experienced hires usually skip straight to a coding test, often a timed HackerRank-style set of two or three problems you solve in the browser in whatever language you pick.
Next is a recorded video interview. Barclays has run candidates through HireVue for years: a question appears on screen, you get a few seconds to think, and a fixed window to answer into a webcam. Some of it is behavioral and values-driven, and technical screens sometimes fold a coding element in here. It feels stiff because it is. Treat it as a rehearsal you can’t redo halfway through.
Then a technical phone screen with an actual engineer: one or two coding problems, questions about your CV and past projects, and specifics of your primary language. The final stage is where the vocabulary splits. In the UK, grads go to an assessment centre with a group exercise, a case study, and interviews. Experienced and US candidates get a Superday-style onsite loop, three to five back-to-back rounds mixing coding, system design, and behavioral, usually closing with a hiring-manager conversation.
| Stage | Format | What they’re checking | Typical length |
|---|---|---|---|
| Online assessment | Numerical/logical + situational judgement (grads); timed coding test, HackerRank-style (experienced) | Baseline aptitude, values fit, ability to code two to three problems unsupervised | 60–90 min |
| Video interview | Recorded, HireVue-style, one-way | Behavioral and values answers; sometimes a technical question | 20–30 min |
| Technical phone screen | Live with an engineer | One or two coding problems, CV deep-dive, language internals | 45–60 min |
| Final stage: Superday (US/lateral) or assessment centre (UK grads) | 3–5 interviews: coding, system design, behavioral, hiring manager | Depth of engineering, design judgment, values, team fit | Half day |
What the coding rounds actually test
Arrays, strings, hash maps, two pointers, a binary tree traversal, a graph BFS or DFS, and the occasional light dynamic-programming problem. The flavor is applied rather than exotic. You’re more likely to get something dressed up in domain language than a pure puzzle. A few in the shape they’re usually asked:
- “Given a stream of trades, find the first symbol that appears exactly twice.”
- “Merge two sorted arrays of timestamps in place.”
- “Validate a string of nested brackets from a config file.”
- “Detect a cycle in a dependency graph of settlement steps.”
What separates a pass from a fail here is rarely the trick. It’s whether you clarify the input, name your edge cases out loud (empty input, duplicates, one element), write code that compiles in your head, and state the time and space complexity without being asked. Interviewers also probe your language. If you put Java on your CV, expect questions on how HashMap resizes, what happens during garbage collection, and how you’d make a counter thread-safe. On the low-latency trading side it’s C++: RAII, move semantics, why you’d avoid an allocation on the hot path. Python shows up everywhere, and for strats roles it’s often the default.
Strats and quant developers: where probability shows up
If you’re interviewing for Quantitative Analytics or a strats desk, one round will lean mathematical. It’s not measure-theoretic proofs. It’s expected value, conditional probability, and whether you can set up a problem cleanly and then code it. Typical prompts: the expected number of fair-coin flips to see two heads in a row (the answer is six, but they want to watch you build the recurrence), the probability that at least two people in a room share a birthday, or a simple dice game where you decide whether to re-roll and compute the expected payoff.
The tell of a strong strats candidate is that they don’t treat the math and the code as separate skills. They’ll reason about a pricing or risk model, then implement a Monte Carlo estimate or a numerical solver and know why the result might be off. Brush up on distributions, Bayes, variance and covariance, and be ready to write the simulation, not just describe it.
System design and the BARX angle
Design questions appear for experienced hires, and they’re grounded in things the bank builds. Design a rate limiter. Design an idempotent payments API that can’t double-charge on a retry. Design a service that fans market data out to hundreds of downstream consumers. Sketch an order-matching engine and reason about how it stays correct under load.
If your target is BARX or markets technology, the conversation gets specific about latency, throughput, and resilience. How do you handle bursty market data without falling behind? What’s your failover story when a matching engine dies mid-session? Where does a cache help and where does it quietly give you stale prices? You don’t need to have built an exchange. You do need to talk in real tradeoffs (consistency versus latency, in-memory versus durable, push versus pull) rather than reciting a reference architecture. On the time-series side, kdb+/q is common enough on the trading floor that mentioning it credibly is a small edge.
What building there is actually like
Barclays is a bank, and the engineering experience reflects that. The retail and core-banking systems carry decades of history, so parts of the stack are older Java and process that exists because a regulator asked for it. You will spend real time on controls, change management, and audit trails that a startup would never tolerate. That’s the cost of the domain.
The markets and BARX teams are a different story and genuinely strong. Low-latency C++, high-volume data, and problems where a millisecond matters attract good engineers, and Glasgow and Whippany are real engineering centers rather than support annexes. The cloud migration to AWS has been running for years and is a steady source of greenfield work. The pace is calmer than a hedge fund or an early-stage startup, hiring is more stable, and layoffs are less capricious. In exchange you accept more bureaucracy and less individual autonomy than you’d get at a smaller shop. Some people find that trade worth it for the stability and the interesting trading-adjacent problems. Others get restless. Know which one you are before you sign.
Comp, and why the shape matters more than the number
Bank technology pay competes on base salary and trails big tech on total compensation, and the gap is almost entirely equity. Your package is base plus an annual discretionary bonus, and for higher earners a chunk of that bonus is deferred into stock that vests over several years. There’s no steady RSU refresh flowing the way it does at a large product company, so the ceiling is lower and the year-to-year number swings with how the bank and your desk performed.
Rough public bands, and you should treat these as approximate and check current, location-specific figures on levels.fyi and Glassdoor before you negotiate: London graduate software engineers land in the low-to-mid £50k range on base; US junior and analyst-level engineers in the New York and New Jersey area sit roughly around the $100k–$120k base band; VP-level engineers in New York commonly clear $150k base with a bonus that can add a meaningful fraction on top. Markets-technology and strats roles skew higher than the retail-bank equivalent at the same level. The variable is the bonus, and it’s genuinely variable, so don’t model your life around a peak year.
How to prep without over-indexing
Grind 100 to 150 easy-and-medium LeetCode problems across arrays, strings, hash maps, trees, and graphs, and stop there. Chasing hard DP is wasted effort for this loop. Spend the freed time knowing your primary language cold, because the follow-up questions on internals are where people quietly lose points. If you’re going for strats, rehearse expected-value and conditional-probability problems out loud and practice turning each into a short simulation.
Prepare four or five stories mapped to the RISES values in STAR form, because the situational-judgement test and the behavioral rounds both lean on them and a vague answer reads as a red flag. Do at least one real HireVue-style rehearsal on camera so the format doesn’t rattle you. And if you’re aiming at BARX or markets tech, read enough about electronic trading and order books to hold a specific conversation about latency and market-data flow. The candidate who can connect their code to how the desk actually makes money is the one the hiring manager remembers.
Similar company guides
Prepping for Barclays? Put it to work: