Hello, this is part 2 of my Interview with Bloomberg series. Click here to start from part 1.

---

I was very interested in two teams at Bloomberg. Thus, I was set up for two phone screenings, one for each team.

Prep

To be honest, I didn’t prep too much. I was 5 months into my interview grind. I was burnt out. After hearing back from Amazon that I had passed their onsite, I really just wanted to stop and take a break.

I did 1-3 Leetcode questions a day up to the day of the interview.

First Phone Interview - Application Integration Team

My first phone interview is with the Application Integration team.

The introduction is quite standard. The interviewer gives me a general overview of the team, the product, open positions, what he looks for in a candidate, etc.

We spend quite a bit of time on chit-chat. Around 25 minutes.

Then we jump into a coding question. It’s a Leetcode medium. I find it pretty straight forward.

I re-iterate the question to make sure I understand it properly. I discuss the edge cases to consider. I discuss various solutions. Discuss the pros and cons. Ask the interviewer what solution he would like to see. He asks me what I think is the best. I choose one and explain why. He tells me to code it out.

I code it out. Pretty clean.

The interviewer is happy with the solution.

That went fast. We have time for another question, so he asks me another Leetcode medium.

I find this question pretty straight-forward as well. I re-iterate, consider edge cases, discuss, get feedback, implement, get feedback, and optimize after.

That goes pretty quickly as well. We still have time left so I ask him a bunch of questions before our 1 hour is up.

When the clock hit the 1-hour mark, we wrap up our pleasant chit-chat and hang up.

I feel good. That was a clean smooth interview.

Pro-tip: study deadlocks. They might ask you about it.

Second Phone Interview - Instant Messaging Team

The next day, I had my phone screening with the Instant Messaging Team.

Similar to the previous interview, we spent quite a bit of time on chit-chat. I think they really care about the candidate’s personality and vibe. But so do I, because I want to find out which team is the better team to join. I ask the interviewer a bunch of questions as well.

After 30 minutes, we jump into the coding question. It’s not a Leetcode-style question. It’s programming with a system design in mind. My interviewer gives me the problem scope: he wants me to provide a Javascript module with certain functions that handle a bunch of illustrated test cases.

Solving questions like these may sound different from Leetcode, but the approach is pretty much the same: re-iterate, go through examples, consider edge cases, discuss various solutions, get feedback, discuss a more optimal solution, implement, walk through the answer, debug and re-iterate as necessary.

However, I’m a little bit stuck on the optimization part. The interviewer wanted to see me implement a non-optimal solution first, and asked me to optimize after. However, the optimization was for certain edge cases. He doesn’t tell me what those certain edge cases were, so I’m stuck for about a minute trying to figure out what he’s hinting out to me. I walk through various scenarios with him: “With input A, this is the state. With input B, this is the state. Etc”. After going through a bunch of these, I realize that there is indeed room for optimization on certain workflows. I discuss my idea for optimization, which he likes, and I implement.

Time’s almost up by the time we are done. I ask him some more questions, and we wrap it up.

That was fun. I personally find tech interviews really fun when they have problems that aren’t like Leetcode, because you get to try a new fresh concept.

Pro-tip: Always walk through your code with examples to make sure it works!

Results

Literally the next day, I get the following email:

---

In my next post, I will write about the Virual “On-Site” Interview at Bloomberg.