Hi all,

Finally took the last of the interviews at Bloomberg. The process was very accomodating. interviews.

My preparation: I have read some of the interview posts. What they say that you need to do a variety of problem. And I concur with them. Initially I had tried to solve more number of problems. Since then, I have switched gears and I try to solve a variety of problems

To understand the various problem types:

1. Binary Search or problems which can be solved by Binary search. You can find great articles in Leetcode itself.
2. DP/Recursion: To me both are same. And I was very comfortable with recursion. Infact to me, DP and other graph algorithms look like extension of recursion.
3. Graph: BFS/DFS/Topo.
4. Arrays:
5. Linkedlist and trees

Arrays have a varied amount of problems. So I devoted a lot of time to it.

I would not be able to tell you questions that were asked but LC has very much helped me in preparing various problems. I would tell you this that Bloomberg ask a lot of questions which can boil down to recursion. And you should practise recursion as such. Dig down problems like DP/graph etc and solve them with recursion even if you are not able to pass all the test cases. In my experience interviewers are more comfortable with recursion (Keep IT Simple) and tabular algorithm can be recreated when you have the recursion logic. I did not need any fancy algorithm. Although during the course of my preparation I was amazed at the solutions people could conjure. But alas, conjuring is one thing and explaining is another. A simple solution is easy to explain.

For design, I watched a lot of videos and familiarized myself with distributed caches and streaming systems. The I tried to design various systems myself like Youtube etc. And then I dig down their architecture and saw how close I was to their actual design.

But there are some basics that I came to know:

1. Shard a DB when there are too many writes. Duplicate a DB via master slave node to make sure data is available (too many reads). The two techniques are usually independent. Which means we can have an amalgamation of sharded db with master slave nodes. I found that using such a configuration helps in explaining scaling to the interviewer.
2. Streaming system like Kafka can act like a message queue. A message queue helps in separation of concern. Similar to any queue between two threads that makes both threads loosely coupled.
3. NoSQl can be easily sharded and maintained but doing so with SQL usually creates maintainence nightmares. But Youtube uses MySQL surprisingly. They have created a way around it.

Thanks a lot Leet coders. And hope this helps all of you.