Bloomberg Telephonic + onsite
Anonymous User
2139

YOE: 5+ year. Location: SF

Telephonic:
1.) Find a valid BST. What if you have to scale it for an input data set that doesn't fit memory on a single system.
2.) Given a string of words.. how many sentences can you form. Just a basic count matching kinda problem. The interviewer then asked how would you scale it. Basically he wanted to hear the words - "Map reduce"

Virtual Onsite:
1.) Candy crush problem. I myself asked the question that do we have the input as a string or a stream so the interviewers were like first code for string and then extend it for stream. Time + space complexity discussion.
2.) You have to register students for an event in FCFS basis. If the registered list if full then put the students on waitlist. Students should be allowed to deregister. Also, implement a function sendEmail to send email given a string indoor or outdoor. If indoor send email to 1000 students if outdoor send email to 8000 students. It was LRU cache problem basically. Same data structures dictionary combined with DLL.
3.) System Design with HM + EM: Implement Uber bike kinda functionality. Discussed how many calls to you anticipate. Initially I said that Google handles 60k requests per sec so let's assum 0.5% of that in the peak hours. Then it also occured to me the calls here are limited by the number of inventory aka cycles we have. Then they asked my about what all APIs would I implement - acquireBike, releaseBike. Then they asked what should be the SLA of this API. I said not more than 500 ms or so because the user should scan his phone or slide the CC and bike should unlock almost immediately. Then they discussed what all components will be critical here. I mentioned Payment is the most critical component. Then somehow the discussion was directed towards the storage layer. I mentioned Bike, User table and trips to save all past trips. My idea was to save all in-progress trips in the Redis Cache. Also, I suggested we can keep some data on the user's phone itself. Then they asked if it was a security concern. I told them if we are just saving the current trip user's info then it shouldn't be a concern. And when the trip ends we invalidate the cache and move the info to persistent storage.
This was followed by why do you want to change, when did you fight as if the whole world is on a vendata againt their colleagues blah blah. Some other "just talking" kind of questions. I just don't understand why have companies started asking these questions.
4.) More "talking", cook-up stories in STAR format kinda interview with some 17+ years experienced person.

wrap-up: Recruiter call. Till then technical interview result was already with her she said it looks positive but next they sent me the standard "Thank you for your time" email. I asked for feedback. The HR said they can't disclose the nitty gritty details but they look to hire people who are either great at coding or great at design but I was neither.

Comments (10)