# Nomura Interview Guide (2026): Global Markets Tech and Strats

Source: https://www.techinterview.org/companies/nomura/
Updated: 2026-07-12 · techinterview.org

**TL;DR —** Nomura's Global Markets Tech and Strats interviews test coding, applied math, and markets knowledge together: expect data structures and algorithms, probability and mental-math questions, and problems on how you'd model or price real trading scenarios. Strats roles lean harder on quantitative reasoning and Python or C++, while tech roles weight system design and software fundamentals. Behavioral rounds center on why Nomura, why markets, and how you work under pressure on a trading floor.

## Global Markets engineering and strats: two different interviews

Nomura's technology hiring splits into two lanes, and which lane you land in changes the whole interview. A "Software Engineer" on Global Markets gets algorithmic coding plus a lot of questions about Java concurrency and how a trading system holds together under load. A "Strat" or "Quant Developer" still writes code, but someone in the room will also walk them through a probability problem built around a random walk, or ask them to price a simple option in their head. Same firm, different rooms, different prep.

Some context that matters for the interview: a large slice of Nomura's international markets business, and the technology behind it, came from buying Lehman Brothers' Europe and Asia operations in 2008. That's why the London and Tokyo tech centers are so deep, why much of the stack is Java and C++ rather than whatever's trendy, and why interviewers tend to care about production systems that have survived a decade of rates and FX flow. New York is smaller than London for markets tech but still runs real desks. Nomura also owns Instinet, its agency-model equities execution arm that handles cash, program, and electronic trading in every market outside Japan — Instinet runs its own stack and its own hiring loop, separate from the core Global Markets desk teams, so if you're interviewing there expect a somewhat different set of interviewers and priorities. There's also a large engineering site in Mumbai, Powai — formally Nomura Services India — that supports the group's trading operations, research, IT, financial control, risk, and legal work worldwide, not just an offshore helpdesk.

## Getting from application to Superday

For graduate and early-career roles, it usually starts with an online application and a set of online tests: numerical and logical reasoning, sometimes a situational judgment questionnaire, then a coding assessment on HackerRank or a similar platform. The coding test is two or three problems, LeetCode easy-to-medium, timed at around 60 to 90 minutes. Nothing exotic here — arrays, strings, hash maps, maybe one problem that wants a clean [O(n)](/big-o-cheat-sheet/) instead of the obvious O(n²). Nomura's own graduate program description is upfront that this is a two-year track with structured rotations that vary by division before you settle permanently on a desk or platform team, so the interview is partly assessing whether you're someone worth investing two years of training in.

Experienced hires often skip the aptitude tests and go straight to a technical phone screen with a hiring manager or a senior engineer from the desk. Expect one coding problem shared over a collaborative editor, plus questions pulled straight out of your CV. If you claim low-latency Java on your résumé, they will ask what actually happens during a garbage collection pause and how you'd keep one off a hot path. For Powai and other campus hires, the first round is typically a video or phone conversation with someone from the actual business area you applied to, not a generic recruiter script.

The final stage is a Superday (New York) or assessment center (London and Tokyo): a run of interviews, usually four or five, stacked one after another with barely a break, across a morning or a full day. Grads may also get a group case exercise. The rounds mix live coding, a [systems or design discussion](/category/system-design/), and [behavioral questions](/post/3233460379/behavioral-interview-questions-2026-star-method-amazon-leadership-principles-and-winning-answers/) about why markets, why Nomura, and how you handle a production incident mid-session when a pricing feed goes stale.

## Inside the technical rounds: coding, concurrency, and probability

### Coding

Standard data-structures-and-algorithms fare, weighted toward things that come up in real systems. Hash map and [two-pointer](/post/3233474160/coding-interview-two-pointers-sliding-window-patterns-array-string-problems-fast-slow-pointer-variable-window/) problems, string parsing, interval merging, a binary search variant, occasionally a light dynamic programming question. They care less about whether you memorized the hardest DP on LeetCode and more about whether you write clean, correct code, reason about edge cases out loud, and state the time and space complexity without being nudged. On the low-latency C++ side, expect questions on move semantics, RAII, cache-friendly data layout, and why you'd avoid allocation in a tight loop.

### Systems and concurrency

For anything markets-facing, concurrency is the real filter. Java teams will push on the memory model, volatile versus synchronized, the difference between a ConcurrentHashMap and a synchronized map, thread pools, and lock contention. A common design prompt: sketch an order book, or the matching component of one, and talk through how you'd keep it consistent and fast with many threads reading and writing. Others ask you to design a market-data distribution system, a feed handler fanning ticks out to hundreds of downstream consumers without falling behind. They want to hear about backpressure, sequencing, and what happens when a slow consumer can't keep up.

### Probability for strats

Strat and quant-dev candidates get a probability round. It isn't stochastic-calculus-heavy for most dev roles, but expect expected value, conditional probability, Bayes, and combinatorics posed as quick questions. Typical ones:

- A symmetric random walk starts at 10 and stops the instant it hits either 0 or 30. What's the probability it hits 30 before it hits 0? Write the ruin probability at each interior point as the average of its two neighbors, note that the boundary conditions force the solution to be a straight line between 0 and 30, and read off the answer: 10/30, or 1/3. What they're checking is whether you set up the difference equation (or invoke a fair-game, no-drift argument) instead of just asserting the linear answer from memory.

- You roll a die repeatedly and sum the results; what's the probability you land on exactly a given total rather than skipping past it? This is a renewal problem, and for a large target the probability settles near 2/7, the reciprocal of the average roll of 3.5. They want the long-run reasoning, not a case-by-case enumeration.

- Three people each draw a card; what's the chance a specific person holds the highest one? By symmetry every person is equally likely to hold the top card, so it's 1/3; the trap is grinding through conditional draws when a one-line symmetry argument settles it.

- A test with known false-positive and false-negative rates comes back positive; what's the probability you actually have the condition? This is Bayes' theorem, and the lesson is that a low base rate can leave the posterior small even after a positive result. Plug in concrete numbers, a rare condition and a good-but-imperfect test, so the base-rate effect is visible.

Do the arithmetic out loud, sanity-check the answer, and don't reach for a formula you can't derive. The interviewer is grading the reasoning, not the recall.

## Legacy Java, desk proximity, and a Tokyo center of gravity

Nomura sits in the middle of the bank-tech spectrum. Nobody's chasing the newest framework here, and nobody's pretending this is a big-tech clone. Teams sit close to the desk, so an engineer on rates e-trading talks to actual traders and sees the P&L impact of what they ship. That's the draw for a lot of people: your code moves real money the same day, and the feedback loop is short. The flip side is legacy. There's plenty of long-lived Java, some large in-house frameworks, and the usual bank constraints around change control, entitlements, and compliance sign-off. If you want to rewrite everything in Rust on a whim, this isn't the place.

The Japanese-parent culture shows up in quiet ways. Decision-making can be more consensus-driven and slower than a US shop, hierarchy is a bit more visible, and Tokyo carries real weight in the org rather than being a satellite office. London is the largest markets-tech hub and feels like a typical London banking floor. Hours for engineers are generally saner than the front-office banker stereotype, you're not pulling investment-banking-division nights, but a live trading system doesn't wait until morning to break.

## Comp: where Nomura lands

Bank base salaries for technology trail what FAANG and the [top quant shops](/quant-firm-interview-guides/) pay, and that gap is real at every level. Where banks differ is the bonus: a meaningful share of [total comp](/total-comp-calculator/), discretionary, tied to both firm and individual performance, and deferred above certain thresholds — a chunk held back and paid out over the following few years, sometimes as restricted stock rather than straight cash. What you don't get is the equity-refresh engine that pushes a senior big-tech package well past base. So Nomura can look competitive on cash base against a mid-tier tech company and behind on total comp against Google or a top hedge fund.

The ranges below are approximate 2026 figures for technology roles and will move with location, desk, level, and how you [negotiate](/post/3233474669/salary-negotiation-2026/). Treat them as a frame, not a quote, and check current offer data on Levels.fyi, Glassdoor, and Blind before you anchor.

| Level (typical Nomura title) | London base salary, approx GBP (2026) | New York base salary, approx USD (2026) | Typical annual bonus (share of base) |
| --- | --- | --- | --- |
| Graduate / Analyst engineer | £48,000–£68,000 | $95,000–$135,000 | 5–20% |
| Associate / mid-level SWE (roughly 3–6 years) | £75,000–£120,000 | $140,000–$200,000 | 10–35% |
| VP / senior engineer | £120,000–£175,000 | $180,000–$270,000 | 20–60%+ (partly deferred) |

Tokyo comp is denominated in yen and structured differently again; base tends to be lower in dollar terms with housing and other allowances in the mix, so compare total packages rather than headline base. Across all three locations the biggest single swing is the bonus, and in a weak year for markets it compresses fast.

## Where to put your prep time

[Grind LeetCode](/study-plan/), but weight it toward mediums and toward clean execution rather than exotic problems: arrays, hash maps, two pointers, trees, intervals, one or two [DP patterns](/algorithm-patterns-cheat-sheet/). For a Global Markets SWE role, drill your language internals. For Java, that's the concurrency package, the collections, GC behavior, and the memory model; for C++, move semantics, RAII, and where allocations hurt. Be able to design an order book or a market-data fan-out on a whiteboard and defend your choices under load.

For strats, add a probability rotation. *Fifty Challenging Problems in Probability*, *Heard on the Street*, and the green book (*A Practical Guide to Quantitative Finance Interviews*) cover the exact style of question they ask, random walks and ruin problems included. Practice narrating your reasoning, because the interviewer is following the path, not just checking the number.

On the behavioral side, have a real answer for "why markets" and "why Nomura" that isn't generic. Name a specific product area, rates, FX, or equities e-trading, and say why the desk-adjacent work appeals to you. Read a little about the firm too; knowing that the international markets business traces back to the Lehman acquisition, that Instinet is Nomura's equities execution arm rather than a separate company you'd apply to blind, and that Tokyo is a genuine center of gravity rather than a branch office, signals you did more than apply to every bank on the street.

The engineers who do best here aren't the ones with the flashiest algorithm chops. They're the ones who write correct concurrent code, explain a tradeoff a trader would actually care about, and stay calm when a feed goes stale at 3pm. Prep for that, and the coding round mostly takes care of itself.