Interview experience
Morgan Stanley Interview Questions and Answers (2026)
Overview
Section titled “Overview”Morgan Stanley’s technology loop runs a timed coding test into a HireVue screen and a multi-interview Superday, with system-design prompts consistently framed around trading and market-data systems.
Morgan Stanley interview process at a glance
Section titled “Morgan Stanley interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Timed coding test | 60-90 min | 2-3 HackerRank DSA problems, unsupervised |
| Phone screen | ~30 min | Background, motivation, light technical |
| HireVue Video Interview | 48-72 hrs to complete | Recorded behavioral answers, AI + human review |
| Superday | 4-5 back-to-back interviews | DSA, financial-systems design, behavioral fit |
Timed coding test
Section titled “Timed coding test”An unsupervised, timed HackerRank test - usually 2-3 problems in 60-90 minutes. No interviewer is watching, so correctness and complexity matter more than talking through your approach.
Common questions
- Longest Increasing Subsequence
- Design an LRU Cache
- Graph and dynamic-programming problems
- Array/string manipulation at medium difficulty
Phone screen
Section titled “Phone screen”A shorter conversational round confirming background, motivation, and basic technical comfort before the more involved HireVue and Superday stages.
Common questions
- Walk me through your resume and background
- Why are you interested in financial technology?
- Light technical or project-related questions
HireVue Video Interview
Section titled “HireVue Video Interview”A recorded, one-way interview candidates complete within 48-72 hours of receiving the invite. Responses go through both AI scoring and human review for borderline candidates, so structured, complete answers matter.
Common questions
- Why Morgan Stanley, and why technology within a bank?
- Tell me about a time you handled pressure or a tight deadline
- Describe a project you’re proud of and your specific contribution
- Tell me about a disagreement with a teammate and how you resolved it
Superday
Section titled “Superday”The final round: 4-5 interviews packed into one day, mixing bread-and-butter DSA with system-design questions that are almost always framed around trading and market-data systems, sometimes including a hiring manager or a senior engineer/Executive Director.
Common questions
- Design a real-time risk calculation system - scalability, latency, fault tolerance
- Design a low-latency order matching engine - in-memory processing, data structures
- Coding problems on graphs, DP, or database design and optimization
- Detailed discussion of a previous project, especially anything finance- or trading-adjacent
- “Why Morgan Stanley, why finance, tell me about a time you disagreed with a teammate”
Full round-by-round narratives are on the Morgan Stanley interview experience page.
Financial-systems system design: a genuine quirk
Section titled “Financial-systems system design: a genuine quirk”Unlike a generic product-company loop where system-design questions might be “design Twitter” or “design a URL shortener,” Morgan Stanley’s Superday design prompts are consistently framed around trading and markets - a real-time risk calculation system, a low-latency order matching engine. You don’t need prior trading-desk experience to answer these well, but you do need to be comfortable reasoning about scalability, latency, and fault tolerance using a financial-systems example rather than a generic web-app one. Candidates who prep only generic system-design templates without translating them into a markets context tend to struggle here.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How do you find the Longest Increasing Subsequence efficiently?
The classic dynamic-programming solution defines dp[i] as the length of the longest increasing subsequence ending at index i, computed by scanning all earlier indices with a smaller value and taking the best plus one - that is O(n squared) time and O(n) space. The optimal solution is patience sorting: maintain an array tails where tails[k] is the smallest possible tail value of an increasing subsequence of length k+1. For each element, binary search for the first tail that is greater than or equal to it and overwrite it, or append if the element exceeds every tail. The length of tails is the answer, giving O(n log n) time. Note that tails is not itself a valid subsequence - to reconstruct the actual sequence you must store predecessor indices alongside.
Q: How do you design an LRU cache with O(1) get and put?
Combine a hash map with a doubly linked list. The hash map maps key to node, giving O(1) lookup; the doubly linked list keeps nodes in recency order with the most recently used at the head and the least recently used at the tail. On get, find the node through the map and move it to the head. On put, either update and move to the head, or insert a new node at the head and, if capacity is exceeded, remove the tail node and delete its key from the map. A doubly linked list is required because eviction and re-linking need O(1) access to a node’s predecessor, which a singly linked list cannot give. Sentinel head and tail nodes remove most of the null-handling edge cases, and in production you would also need locking or a concurrent variant since a cache is shared across threads.
Q: How do you detect a cycle in a directed graph?
Run a DFS with three colours: white for unvisited, grey for on the current recursion stack, and black for fully explored. If DFS reaches a grey node, that is a back edge and the graph has a cycle. Using a plain visited set is the common bug - revisiting a black node is fine in a directed graph and does not imply a cycle. The alternative is Kahn’s algorithm: repeatedly remove nodes with in-degree zero; if fewer than V nodes come out, the remainder form a cycle. Both are O(V + E) time and O(V) space. This matters in finance because dependency graphs - a pricing pipeline where instruments derive from other instruments - must be acyclic before you can topologically order the evaluation.
Q: Find the next greater element for each entry in an array of prices.
Use a monotonic decreasing stack of indices. Scan left to right; while the stack is non-empty and the current price exceeds the price at the stack’s top index, pop that index and record the current price as its next greater element; then push the current index. Any indices left on the stack at the end have no greater element to their right. Each index is pushed and popped at most once, so it is O(n) time and O(n) space, versus O(n squared) for the nested-loop version. The same monotonic-stack pattern solves the daily-temperatures span, stock-span, and largest-rectangle-in-a-histogram problems, which is why Morgan Stanley interviewers like it as a follow-up chain.
Q: How would you design a low-latency order matching engine?
Keep the whole book in memory and avoid anything that touches disk on the hot path. Model each side of the book as a price-ordered structure - typically a sorted map, or an array of price levels for the tight range around the touch - where each price level holds a FIFO queue of resting orders, so matching follows price-time priority: best price first, and within a price, the earliest order first. An incoming aggressive order walks the opposite side from the best price, filling against resting orders until its limit price is passed or its quantity is exhausted; the remainder rests in the book. Keep a hash map from order id to its node so a cancel is O(1) rather than a scan. Single-threaded matching per instrument fed by a lock-free ring buffer usually beats a multi-threaded design because it removes lock contention and keeps the book in cache; durability comes from writing the input event stream to a replicated journal before matching, so state can be rebuilt by replay.
Q: How would you design a real-time risk calculation system?
Take positions and market data as two input streams. Positions change on trade events; market data - prices, curves, volatilities - arrives continuously. Publish both into a durable log such as Kafka partitioned by book or instrument, so a compute tier can scale horizontally and each partition is processed in order. The calculation tier maintains current state per book and recomputes exposures and sensitivities incrementally rather than from scratch, since recomputing an entire portfolio on every tick will not meet the latency budget - a tick affecting one instrument should touch only the positions referencing it. Heavy scenario work such as historical or Monte Carlo VaR runs as a batch on a compute grid, with results cached and served alongside the incremental numbers. Design for late and out-of-order market data with event-time watermarks, keep every result traceable to the exact market snapshot used, and be explicit that correctness and auditability outrank raw speed on a risk system, unlike on the matching engine.
Q: A query has become slow. How do you diagnose and fix it?
Start with the execution plan rather than guessing. Look for full table scans on large tables, nested-loop joins over big row counts, and a large gap between estimated and actual rows, which points at stale statistics. Common fixes: add a composite index whose leading column matches the most selective equality predicate and whose later columns cover the ORDER BY, so the engine avoids a sort; make predicates sargable by not wrapping the indexed column in a function - WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01' beats WHERE YEAR(created_at) = 2026, because the second cannot use the index; and select only the columns you need so the index can cover the query and skip the row lookup. Beyond that, replace correlated subqueries with joins or window functions, refresh statistics, and consider partitioning by trade date for large historical tables. Always measure before and after on realistic data volumes.
Q: What are the ACID properties, and what do the SQL isolation levels actually prevent?
Atomicity means a transaction applies entirely or not at all, implemented with an undo log. Consistency means every committed transaction leaves the database satisfying all constraints. Isolation means concurrent transactions do not observe each other’s partial work. Durability means a committed transaction survives a crash, implemented by write-ahead logging to stable storage before the commit is acknowledged. The isolation levels trade concurrency against three anomalies: READ UNCOMMITTED allows dirty reads; READ COMMITTED prevents dirty reads but allows non-repeatable reads; REPEATABLE READ prevents both but can still allow phantom rows; SERIALIZABLE prevents all three, at the cost of the most locking or the most aborted transactions under optimistic concurrency. Financial ledgers usually run at REPEATABLE READ or SERIALIZABLE for balance-affecting writes, while reporting reads run lower to avoid blocking the write path.
Frequently asked questions about Morgan Stanley interviews
Section titled “Frequently asked questions about Morgan Stanley interviews”What is the Morgan Stanley interview process for freshers?
Morgan Stanley’s Technology Analyst loop typically runs: 1. Application (on-campus via college placement cell, off-campus via the Morgan Stanley Careers portal, or through referrals). 2. A timed coding test - usually 2-3 HackerRank problems, 60-90 minutes, no interviewer watching. 3. A phone screen. 4. A HireVue recorded video interview (48-72 hours to complete after the invite link arrives) with AI-plus-human review for borderline candidates. 5. The Superday - the final round, with 4-5 back-to-back interviews in one day mixing technical (DSA plus system design) and behavioral content, sometimes including a hiring manager or a senior engineer/Executive Director. Total duration: roughly 3-4 weeks from application to offer.
What questions are asked in Morgan Stanley interviews?
Coding rounds are bread-and-butter DSA - stack/hashing problems, graphs and dynamic programming (longest increasing subsequence, LRU cache), plus SQL and database-design questions. System-design prompts lean into financial systems: designing a real-time risk calculation system, a low-latency order matching engine, or discussing market data and order management at a fresher-appropriate depth. Behavioral rounds check ownership, teamwork under pressure, and always include at least one ‘why Morgan Stanley, why finance’ style question.
How many rounds are there in the Morgan Stanley interview?
Morgan Stanley typically runs 5 touchpoints: a timed coding test, a phone screen, a HireVue video interview, and a Superday with 4-5 back-to-back interviews. Some drives compress the phone screen and HireVue into one step, or skip a round for stronger-profile candidates - check that cycle’s college placement communication.
What is the Morgan Stanley Superday like?
Superday is the final round: 4-5 interviews packed into a single day, mixing technical (DSA plus a financial-systems design prompt) and behavioral content, sometimes with a hiring manager and a more senior engineer or Executive Director in the loop. Banks screen hard here for people who will stay past the training program, so expect at least one interview built almost entirely around ‘why Morgan Stanley, why finance, tell me about a time you disagreed with a teammate’ rather than pure technical depth.
How should I prepare for Morgan Stanley interviews?
Practise timed DSA (especially graphs, DP, and design questions like LRU Cache) and be ready to design a simple financial system - a risk calculator or an order-matching engine - discussing scalability, latency, and fault tolerance in plain language. Revise OOPs and SQL, prepare one crisp project narrative, and rehearse the HireVue format ahead of time since responses go through both AI scoring and human review. Use STAR for behavioural answers, and prepare a genuine answer for why you want financial technology specifically.
Does Morgan Stanley ask finance-specific system design questions for tech roles?
Yes, this is one of the more distinctive parts of Morgan Stanley’s technology loop. Even fresher-level system-design prompts are framed around trading and markets - designing a real-time risk calculation system or a low-latency order matching engine - rather than a generic ‘design Twitter’ style question. You don’t need trading-desk experience, but you should be able to reason about scalability, latency, and fault tolerance using a financial-systems example.