Backend Engineer | Zenskar
JP Morgan Chase | SDE 3 | YOE 3.4
Microsoft SDE - 2 | Interview Experience | Status Pending
eBay || SWE3 Interview Experience || Bangalore
Bloomberg | Interview Experience | Senior Software Engineer | NYC | Nov 2025
Nutanix MTS-4 Interview Experience (Rected)
Summary
I interviewed for the MTS-4 role at Nutanix, going through an Online Assessment, a coding round, an LLD round, and an HLD round. Despite performing well in most rounds, I was ultimately rejected due to my performance in the Low-Level Design round.
Full Experience
I recently interviewed for an MTS-4 position at Nutanix. I have a total of 6.5 years of experience, with my education being a B.tech from a tier-3 college and an M.tech from IIT.
Round 1: Online Assessment
This round consisted of 2 coding questions, both at a LeetCode medium difficulty level. I was able to solve both of them successfully.
Round 2: Coding Round
This round focused on a coding problem similar to one found on LeetCode Discuss. The specific problem involved recursively deleting leaf nodes in a multi-tree structure. We had a lot of discussion about different approaches, as well as their time and space complexities. I received positive feedback after this round.
Round 3: Low-Level Design (LLD)
The task for this round was to design a paint application, similar to Microsoft Paint. I was expected to deliver running code within an hour, based on the following requirements:
- The user should be able to draw different shapes (like circles, rectangles, squares, triangles, etc.).
- If a user draws a rectangle inside another rectangle on the screen, how would I ensure that these are stored in their exact positions in our database?
- More than one user should be able to draw on the same screen and see each other's changes, similar to Google Docs.
For the first requirement, I suggested taking x,y coordinates from the frontend and storing them in the DB. However, the interviewer indicated that this would involve too much processing on the frontend, and they preferred a backend-heavy system. This round did not go well for me, and I anticipated a rejection.
Round 4: High-Level Design (HLD)
Despite the LLD round not going well, they had already scheduled the HLD round, so I attended it. The problem involved a scenario with N servers, where 2 <= N <= 50. Each server processes data based on its own configuration file. The admin needed a system where they could update a single configuration file, and all other files would automatically get updated. The constraint was that we could not use a common configuration service; the files had to remain with the individual servers.
I initially proposed a common configuration service where all servers could read values, allowing the admin to update just that one service. But the interviewer reiterated that they didn't want a common configuration service and insisted on files residing with the servers. I then came up with different approaches. This round went pretty well; the interviewer was friendly, and we had a healthy discussion.
After two days, I received a call from HR stating that the feedback from the LLD round was not positive, and they would not be proceeding further with my application. I am still looking for a solution for the LLD round, and any suggestions would be helpful.
Interview Questions (3)
Design a paint application similar to the one in Windows, with the expectation to deliver running code within an hour. The requirements were:
- The user should be able to draw different shapes (like circle, rectangle, square, triangle etc).
- If a user draws a rectangle inside another rectangle on screen, how would you ensure that these are stored in their exact positions in the database?
- More than one user should be able to draw on the same screen and see each other's changes, similar to Google Docs.
Design a system for N servers (where 2 <= N <= 50). Each server has its own configuration file, and all configuration values are stored within these files. The administrator needs to update a single configuration file, and all other server files must automatically reflect these changes. The key constraint is that a common configuration service is explicitly not allowed; the configuration files must remain local to each server.