I applied through a recruiter.
I interviewed with an employee from New York, and during my coding round, I gave a brute force and also an optimized solution, and I wrote the code within the first 20-30 minutes. I felt like it stopped being about evaluating my solution and turned into him continuously changing the problem. I'd answer one question, then he'd introduce a new assumption that wasn't part of the original design, for example, assuming a bounded executor queue with blocking submit(), even though my solution was based on Java's standard ExecutorService. It felt like he kept modifying the underlying behavior just to see where the solution would break instead of discussing the design I had actually written. I don't mind deep follow-up questions at all, but it became hard to know what I was supposed to optimize for because the assumptions kept changing. The interviewer I got will keep drilling into concurrency and may intentionally change the rules of the system. I felt like he wanted me to fail. Hopefully you get a different and fair interviewer.
How does ExecutorService limit concurrency? How would you make the visited set thread-safe?
The following metrics were computed from 1 interview experience for the MongoDB Software Engineer role in Toronto, Ontario.
MongoDB's interview process for their Software Engineer roles in Toronto, Ontario is extremely selective, failing the vast majority of engineers.
Candidates reported having very negative feelings for MongoDB's Software Engineer interview process in Toronto, Ontario.