Hello! This is part 3 of my Interview with Bloomberg series. If you want to read from the beginning, part 1 is here.
I passed both of my phone interviews with the Messaging Application and Application Integration teams at Bloomberg. They were both interested in moving forward with virtual “on-site” interviews, and so was I.
As mentioned in my previous post, I would need to have two separate on-sites, one for each team. A lot of work, but I think it will be worth it.
My HR mentioned that the interviews should take about half a day for each team. I asked her if it’s possible to squeeze both interviews into the same day, morning and afternoon. She says yes, so I go for it.
I didn’t prep too hard for Bloomberg because
- I passed my Amazon interviews and already had an amazing offer on hand
- got a little cocky from passing my Amazon interviews
- too tired to keep grinding any further at this point
I did 1-3 new Leetcode questions per day. I reviewed 3+ questions per day using the reflections on my spreadsheet of completed questions.
At this point, it felt like reviewing my previous questions was helping me more than doing new questions on Leetcode.
I was told to be prepared for system design questions for the Bloomberg interviews. For that, I just bought Grokking the System Design Interview Course. Lifetime purchase. Worth it. This is one of those courses that I will use time and time again in my future tech interviews.
Studied from this every day until I covered all the theoretical concepts, but ended up completing only a few of the case studies.
My interviews were scheduled to start at 9:30 AM, and estimated to end around 5 PM. Welp, I’m in for a long day.
I join the video call using a software called Nexi. Inside, I am met with two Bloomberg software engineers in the team. One of them has 20 years of experience in the company, while the other has 6 years. Quite the veterans.
We begin with a lot of chitchat. They are very nice people and help me feel comfortable and less nervous. We go over theoretical questions regarding some front-end frameworks. This part doesn’t go quite as smoothly as I had hoped. To be frank, I didn’t review any frameworks for the interview. Still, I try my best to answer questions based on experience and common sense.
Pro-tip: review your frameworks, the pros and cons
The first 30 minutes speed by and before I know it, I’m in the latter half of the interview with a technical question.
The interviews present a Leetcode-style question. I’m given a link to join them on HackerRank, where I find a question already laid out for me. I find it pretty straightforward. I do my usual wombo-combo:
- Re-iterate the question back to the interviewer
- Walkthrough examples, edge cases
- Discuss various solutions
- Discuss optimizations, choose a solution
- Code out the solution
- Test the code (they want to see me running the code right away, instead of walking through the code manually)
- Discuss any further optimizations as necessary
It goes by quite smoothly. Based on their feedback, I think they are satisfied with the technical part.
I ask them some questions about life at Bloomberg before the hour is up.
The 2 previous interviews leave the virtual room, and I am joined by 2 others.
Right after saying hello, my stomach drops as I realize this is gonna be a hard one - one of the interviewers’ audio was bad, and it was pretty hard to make out what he was saying. The other had a pretty strong accent, so I had trouble trying to understand his words.
After general hello and chit-chat, I try to point out the audio issue.
Me: “Hi sorry, I’m having a little trouble making out your audio, there’s a bit of noise coming out on my end.”
Him: “Oh, sorry lemme fix that” … “Is that better?”
*there’s literally no change
Me: *sweats “Uh, no not quite.”
Him: *tries again
*this whole thing repeats 3-4 times
*time’s ticking by
*audio gets a little better, but I still have trouble making out 1 out of every 5 words. Not a huge deal, but common…
*the other interviewer seems to be getting a little impatient
*doesn’t seem like there’s too much that could be done right now
Me: “It’s better now, let’s just move on”.
Pro-tip: test your mic and audio before the interview with a friend
I had the most uncomfortable interview of my life. The interviewer with bad audio, it was rare to hear a complete sentence from him without some noise disrupting the audio. And he had a bunch of questions prepared for me too. I wondered if I should just ask the other interviewer to talk instead, but I had trouble understanding the other interviewer’s accent lol rip
As we progress through the theoretical questions, I get one that I legit did not know the answer to. It was one of those questions you Google once to find out. I explain that I don’t know, but give them the best answer I have based on my experience and common sense.
It’s not a satisfactory answer. They
grill help me a little bit over this by asking some more questions. “Well, you said you think this is result A when case B happens. So, what about case C?” “How does that make sense when you get output D in case E?”
I don’t really get much further. We have spent more than half of the allotted interview time by this point, so we proceed to a technical question.
Instead of starting from a new fresh question, we branch off the question left by the previous interviewers.
My job is to take my previous solution and adapt it to follow some other specifications.
It’s very not Leetcode-like.
However, I find it pretty straightforward. I do the usual re-iterate, edge cases, discuss, implement, test, optimize bim bap boop kapow and we are done.
It’s pretty fun. Non-Leetcode technical questions = a lot of fun.
I ask some questions before our hour is up, then I’m off to the next round.
This time, it’s just one interviewer joining the call.
He’s a pretty polarizing guy. He carries this aura of charisma and seriousness, but also chimes in with a joke here and there. He’s a senior. With 20 years of experience at the company, he seems to be somewhere in the managerial rank, but also involved in some technical aspects. Not too sure.
With his voice and physical appearance, my best description of him would be the godfather. I couldn’t help but imagine 10 thugs behind the screen, ready to come and take me out at his will.
We start off with some chit-chat, but he doesn’t really seem to enjoy it. Or maybe he does? I can’t tell.
We head off into a technical question. Leetcode-style. It’s a challenging one, but thank goodness I did similar questions before.
Re-iterate, point out edge cases, discuss solutions, implement, test, optimize, beem bam boom. He’s happy with my solution. Boo yeah.
My surprise: he tells me this is the last interview I’m having with the team. Uh-oh. It seemed like you only get to proceed to the 4th round if they like you, and maybe this team doesn’t.
Oh well. I get a 30 min lunch break until my next session of interviews.
I looked up some answers to the theoretical questions that tripped me up.
Literally the first result on Google told me the answer within 10 seconds. *facepalm
Pro-tip: prepare for theoretical questions regarding frameworks
I join a call to meet 2 Bloomberg software engineers.
They are quite nice. Comparatively young, energetic, but also quite smart.
We chit-chat a little bit. They are quite friendly so this is easy. We walk through the product, teams, some theoretical questions, then jump into a technical question.
It’s a non-Leetcode style question. The question laid out some specs, and I need to deliver a module that meets those specs.
No tricks, no fancy algorithms. Just good old communication and coding.
It’s quite a handful. I make sure I understand the question, walk through examples, edge cases, and start implementing the code.
During my implementation, I trip on some unseen edge cases. I bring this up and revise my implementation on the go.
I keep verbally explaining what I’m doing, and the feedback is great. The 3 of us are all on the same page. #feelsgood
After around 30 minutes, we start testing the code against some test cases. Fails on some. I debug, discuss the issue, propose solutions, interviewers like my solutions, I implement the fix, and pass those failed tests.
I get a thumbs-up at the end. Yay.
I end the hour by asking them some questions.
That was a fun one.
Two different interviewers are on the call. After introductions, it’s clear to me that they are both very technically distinguished engineers in the company.
This time, it’s a system-design question.
And wow, system design questions are HARD.
I spend quite a bit of time trying to gather the scope and requirements. “What about this case? This scenario? Expected workflow in this other case?”.
The question is super ambiguous. I’m trying to scope it out as much as possible, but it seems like I’m hitting some dead-ends.
I begin to walk through some solutions. There’s a lot of back-and-forth with my interviewers. The process feels like trying to cross a river without getting my feet wet by carefully stepping on particular stones. The less wet my feet are by the end, the more points I will get.
It’s hard to tell which solution is the most effective solution, because:
- this question is really open-ended
- none of my solutions are the perfect solution.
- the interviewers don’t tell me which one seems to make the most sense, as they want me to figure it out for myself
I pick the solution that makes the most sense, and we begin to walk through the designs.
And whadaya know, it’s actually a little complicated to explain concepts via the coding pad, versus something like a whiteboard. Virtual interview problems…
As we carefully walk through the design, we address different criteria and specifications. Edge cases, performance considerations, everything.
I write some pseudo-code for the algorithm, which is a little questionable. Not a perfect algorithm.
After a lot of discussions and collaborative back-and-forth, our hour is almost up and the interviewers announce that this is enough.
Out of curiosity, I ask them what they would have done differently with this question. Turns out, this was an actual problem within Bloomberg, and my proposal wasn’t too far off from the actual implementation in their product.
We end the interview, and I move onto the next round. Kind of getting tired at this point.
I’m joined by a manager. Just the manager. Very friendly, very chatty. We start off with general chit-chat, and most of our questions and discussions are pretty spontaneous.
30 minutes into the pleasant chit-chat, I’m beginning to wonder if she has any actual interview questions prepared for me, and that’s when she says she will be handing me over to the next interviewer.
We have chit-chat for another 10 minutes. Pretty fun person actually. And I’m really curious about life at Bloomberg, so this is quite helpful.
I’m joined by the previous interviewer’s boss.
The manager’s manager.
Good mother lord. This is the boss round.
We get into the introductions. The interviewer has 14 years of experience, leading a 150+ member team, pushing out various projects, and just on a roll. He’s a little hyper and energetic when he talks, which rubs off on me and makes me energetic and hyper when I talk.
Again, we have a lot of chit-chat. I ask him questions about the products, the teams, the organization, competitors, his likes, dislikes, etc.
Some parts of the conversation are pretty down-to-earth. At one point I mention that I am a Bloomberg Businessweek Subscriber, and my interests in finance.
(No, I didn’t keep all those magazines, because they were taking up valuable dust space)
We talk for about 45 minutes, and then end the interview.
That was an energetic, exciting, and a little-too-hyper interview.
The HR comes in the end with pleasant chit-chat.
He basically needs the following info from me:
- which team(s) am I interested in following up on an offer for? I tell him I’m interested in both
- which interviews do I think went well? I tell him the 2nd team
Then he informs me about the compensation, benefits, relocation, and other things at Bloomberg. Nothing too specific about compensation since I don’t have an offer yet, but a lot of other good info.
We wrap up the call within 40 minutes, and my day is over.
It’s past 5, already dark outside, and I’m pretty beat.
The next day, I get a call from my HR.
“Congratulations Dan, both of the teams REALLY like you and want to give you an offer!”.
Wut? Both? The first team too? I thought I did pretty bad on that one, but cool.
“Would you have a preference as to which team you want to join?”
I state the team I’m interested in, and we proceed to have an offer negotiation with that team.
Pretty standard approach. They state a number, you ask for a counter-offer, they give you a counter-counter-offer, etc.
Pro-tip: check on levels.fyi to see what the salary scales are.
Looking for negotiation tips? Moonchaser has helped hundreds of software engineers negotiate with Amazon, Google, Facebook, AirBnB, Apple, and more. They offer a tailored negotiation experience, with everything from planning based on company-specific tactics and current trends, to mock negotiations with custom scripts. On top of it all, they offer live-guidance, in case you are stumbling during the actual negotiation. They only charge a small commission on the INCREASE of the offer, meaning if you don’t get a better offer, you don’t pay a single dime. Head over to Moonchaser and book your free consultation.
Thank you for reading my Bloomberg Interview Series! I hope it was helpful.
Grateful to have had this interview opportunity, so thanks to Bloomberg LP too.