
When I applied for the Morgan Stanley Analyst role, I got the OA just a couple of days later. It included 24 multiple-choice questions and 2 coding tasks, both at a medium difficulty level. Below, I’ll share details about the two coding questions I got.
I am really grateful for the tool Linkjob.ai, and that's also why I'm sharing my entire interview experience here. Having an invisible AI assistant during the interview is indeed very convenient.



For this problem, the goal was to minimize the total number of hits needed to break all bricks. Each brick requires a certain amount of force k to break. A big hammer breaks a brick in one hit, while a small hammer requires k hits. So, the optimal strategy is to use the big hammer on the bricks with the highest newtons values, since replacing those saves the most total hits.
The first step is to sort the bricks in descending order of newtons, while keeping track of their original indices (since we need to return 1-based indices at the end). We can use the big hammer up to bigHits times, so we assign the top bigHits bricks to the big hammer and the rest to the small hammer.
To calculate the total hits:
For big-hammered bricks → add bigHits (1 hit each).
For small-hammered bricks → add the sum of their newtons values.
Then, collect the indices of bricks hit by each hammer, making sure to output them in ascending order. For example, with bigHits = 4 and newtons = [3, 2, 5, 4, 6, 7, 9], sorting gives [9, 7, 6, 5, 4, 3, 2]. The top 4 are hit by the big hammer, so the total hits = 4 + (3 + 2 + 4) = 13. The big-hammer and small-hammer indices are then derived from the sorted order and output accordingly.
Special cases to handle:
If bigHits >= n, all bricks are hit with the big hammer → small-hammer indices = [-1].
If bigHits = 0, all are hit with the small hammer → big-hammer indices = [-1].



The task was to find how many times s1 appears as a subsequence within s2, given that the length of s1 is fixed at 3. I recalled the dynamic programming approach for counting subsequences.
For the three characters of s1, say a, b, and c, we can count in stages:
The number of occurrences of a in s2;
For each position of a, count how many bs appear after it;
For each position of b, count how many cs appear after it.
The total sum of all these valid combinations gives the final count.
More concretely, I can use three arrays or variables to track the counts. First, traverse s2 to record the cumulative number of as up to each position. Then, during another pass, for every b encountered, add up the count of as before it. This forms an intermediate state. Finally, traverse s2 again, and for every c, add up all the intermediate b states before it. The sum of these values gives the result. This approach runs in O(n) time, where n is the length of s2, which efficiently handles the given constraints.
For example, if s1 = "ABC" and s2 = "ABCBABC", we find all positions of A, then for each A count how many Bs follow, and for each B, count how many Cs follow. Summing all valid combinations gives 5 total subsequences.
When I started preparing for the Morgan Stanley HackerRank test, I spent quite a bit of time exploring different platforms and found that sites like HackerRank and LeetCode had an enormous variety of coding challenges. I focused on problems that matched the topics I had seen in sample tests, such as string manipulation, graph algorithms, and basic data structures.
Here is a list of my favorite practice sites:
HackerRank
LeetCode
GeeksforGeeks
Linkjob.ai
Whenever I practiced, I made sure to filter problems by both difficulty and topic. Medium-level questions became my main focus since they closely resembled the type of problems on the actual test. I also tried a few harder problems from time to time to push myself a bit further and expand my problem-solving skills.
I made a table to organize my study plan:
Topic | Why It Matters | My Strategy |
|---|---|---|
Algorithms | Most coding questions use them | Practiced sorting, searching, and recursion daily |
Data Structures | MCQs and coding both test this | Reviewed arrays, stacks, queues, graphs, and trees |
Logical Reasoning | MCQs often test logic | Solved puzzles and brain teasers every morning |
Programming Basics | C concepts and syntax | Wrote small programs to reinforce fundamentals |
I dedicated extra time to graph algorithms and string manipulation, while also brushing up on SQL queries and basic web development concepts.
Here’s how I structured my preparation:
Use a mock interview platform like Linkjob.ai. I uploaded my personal resume and the position I was applying for. This allowed the AI to generate targeted practice questions that closely mirrored what I might encounter in the real test.
Familiarize myself with the question types. I reviewed sample questions for both multiple-choice and coding problems. Understanding the format beforehand made the actual test feel much less intimidating.
Practice consistently every day. I set aside dedicated time each day to solve problems. This regular practice helped me build both confidence and speed, so I could tackle questions more efficiently.
Simulate real test conditions. I always timed myself strictly while practicing. Treating each session like the real test helped me manage time pressure.
Review and reflect after each session. After completing practice problems, I analyzed mistakes, optimized my solutions, and reinforced concepts I struggled with. This reflection loop steadily improved my performance.
Tip: Simulating the test at least twice before the real thing can boost your performance. I felt much more prepared and less anxious on test day.
When solving problems, don’t try to write the complete code in one go, especially for questions that involve multi-step logic (such as counting subsequences or calculating optimal strategies). Break your code into smaller modules. For example, in a subsequence problem, first write a function to count the occurrences of a single character, then write another function to count combinations like “previous character + current character.” Test each module individually before integrating them. This approach helps quickly locate issues in each part and keeps your code logic clear, avoiding wasted debugging time caused by messy code structure.
When tackling algorithm problems, don’t immediately implement your approach. Start by working through a very small example manually. For instance, in the brick problem, if bigHits = 2 and newtons = [3, 1, 4], manually calculate that using the big hammer on 4 and 3 and the small hammer on 1 gives the correct result, then compare it with your code output. This method helps catch logical flaws early—such as missing original indices during sorting or miscalculating total hits—much more efficiently than waiting for test cases to fail after finishing the code.
If your code runs into timeouts, first examine nested loops, especially the operations inside the inner loop. For example, when handling long strings, if the inner loop repeatedly traverses substrings, consider storing intermediate results in arrays (like precomputing counts of a and b at each position in a subsequence problem). This trades space for time. Morgan Stanley’s test has strict time complexity requirements, but most timeout issues can be resolved by optimizing inner loops without needing to completely rewrite your code logic.
After passing the test, the subsequent technical interviews typically consist of 2–3 rounds. The first round focuses on coding exercises, while the later rounds often combine business scenarios with complex algorithm design. For some roles, there may also be system design–related technical questions.
Switch immediately to a simpler alternative approach rather than forcing a complex algorithm. Morgan Stanley places more emphasis on problem-solving ability than on algorithmic complexity.
For example, in a subsequence counting problem, if you forget the optimal dynamic programming implementation, you can start with a brute-force version to ensure the logic is correct, then gradually optimize. If even the brute-force version is difficult, try using a hash map or arrays to track key information, ensuring that you can pass at least some test cases. The goal is to avoid getting stuck and leaving the problem incomplete.
Before coding, identify the key formatting requirements and verify the format using sample inputs. While reading the problem, highlight the expected output format. When writing your code, handle any format-related logic first. After finishing your solution, test it using the sample inputs provided and compare your output carefully to ensure it matches exactly. This prevents losing points due to formatting issues even if the logic is correct.