Morgan Stanley Software Engineer Interview Questions
& Process

There were three rounds in the interview process: first, a recruiter call, then an in-person round that was a mix of technical and behavioral questions, followed by a final round which was again technical + behavioral. Because this was a junior role, about half of the interview focused on my resume, particularly my tech stack from past internships and projects. The other half was dedicated to technical and behavioral questions, which were actually simpler than I anticipated. The technical part involved LeetCode easy/medium problems, specifically focusing on two-pointers and linked lists, along with consecutive questions about basic data structures (lists, sets, maps) and their time complexities. It's also important, depending on the specific role, to know the concepts of the programming language you're using. For instance, if it's a Java role, be prepared to discuss the trade-offs of Java compared to C++/Python, garbage collection, OOP, Collections interfaces, errors, and file handling. The behavioral questions consisted of two STAR method questions, like describing a time you had a conflict within your team and how you resolved it. Honestly, it wasn't the most challenging interview I've faced. If you really focus on your past experience, simple DSA, and OOP, you should do well.

The interview process was pretty straightforward with a bit of prep. It had 4 stages in total. First up was a chat with HR, which also involved speaking English. Then, there was a theoretical test covering common questions about the tech stack you'd be working on, plus some Git/Linux stuff (you can find these on most 'top 100 interview questions' sites). The third stage was a Zoom call where they threw an easy LeetCode-like problem at me, something like 'find duplicates in an array,' along with more theory. The last stage was a team-fit interview, basically a behavioral chat to see if we'd mesh well.

I interviewed for a Frontend Developer role. The first round was about JavaScript and React. The second round was a live coding task where I had to build a carousel. They also asked me some JavaScript output questions, which I think I nailed. Near the end, they asked how I'd do pagination, both infinite scrolling and the numbered kind. I went over a few ways to do it, talking about state management, loading data on the fly, and the whole user experience. But when I asked for feedback, they said my 'basics are weak' and I didn't consider accessibility, like how someone visually impaired would use the pagination. I was surprised because accessibility wasn't mentioned as a requirement for the task. If they had said it was important, I would have definitely talked about ARIA roles, keyboard navigation, and screen reader stuff. I do care a lot about accessibility and building stuff that works for everyone, so it was kind of a bummer to be told my basics were weak because it wasn't my first thought – especially when they didn't hint that accessibility was being judged. It made me think that interviews should be clearer about what they're looking for. Interviewers should give context so it's a fair test. When feedback isn't based on what was actually asked, good developers can get overlooked. Clearer interviews help candidates learn and also make the company look better and attract good people.