HackTheRounds Interview Experiences

Bloomberg New Grad SDE Interview Experience (2026) - TV Retention, Tesla Equity OOD & Kafka Design, Offer

Bloomberg 2026 SDE New Grad full loop in NYC: phone screen on vowel substrings, TV Show User Retention coding, Tesla Equity O(1) OOD design, HR round, and EM ro

By Anonymous ยท 2026-03-31

Background

Writing this one up fast because the memory is still fresh. I just accepted the Bloomberg 2026 SDE New Grad offer for the NYC office last week. I'm a masters student finishing up this spring, applied through the careers site in early fall, and the whole pipeline moved faster than any other full-time loop I did this cycle. Total time from phone screen to offer call was under a month, which was almost alarming.

A quick note on why this post exists separately from other Bloomberg writeups: the new-grad loop has a different shape than the experienced-SDE loop. Fewer architecture questions, more OOD, one explicit EM round at the end that is basically a system-design stress test dressed up as a conversation. If you are prepping for full-time new grad specifically, that shape matters.

Timeline

Total: about 5 weeks from phone to offer.

Phone Screen (45-60 min)

Two coding problems. The recruiter warned me ahead of time that this round was "two easy-mediums" and she wasn't exaggerating.

Problem 1: Social graph, given as an adjacency list representation. Starting from a given user, find the first connected "partner" that matches a specific predicate. Classic BFS, the only thing to be careful of is whether the start node can count as its own partner (the interviewer said no).

Problem 2: Count vowel substrings of a string. The kind of problem where the O(n^2) brute force passes, but the interviewer nudged me toward the O(n) sliding window after I coded the brute force. You track the position of the last consonant and the earliest start of a valid vowel-only window; for each index you can count how many valid substrings end there in O(1).

I finished both with 10 minutes left for questions. The interviewer was friendly, seemed to already be thinking about the next round, and we ran over.

VO1 (60 min)

Self-intro, project deep dive, behavioral, then coding.

Behavioral ( 15 min): - Tell me about a project you led. - Tell me about a time you got stuck and how you got unstuck. - Why Bloomberg?

Have STAR versions ready. The "why Bloomberg" question is the one people underprepare. "I like finance" is not an answer. I talked about the Terminal specifically as an engineering artifact: thousands of keyboard shortcuts, a decades-long backward-compat story, a real-time data plane that other industries still cannot match. That landed.

Coding Problem: TV Show User Retention

Each show has exactly 10 episodes. For each episode we have the number of users who watched it. Given all that data across many shows, find the earliest episode n such that at least 70% of the users who started episode 1 of some show also finished all 10 episodes.

I worked through the mechanics carefully before coding. For each show, the retention after episode n is viewers[n] / viewers[0] . I needed the smallest n such that for every show under consideration, viewers[9] / viewers[0] = 0.7 . The tricky interpretation was "for all shows" vs "for at least one show" and I asked, which the interviewer appreciated.

High-level approach: iterate episode n from 0 upward and for each show with nonzero episode-1 viewers, check whether episode-10 retention clears the threshold. The smallest n for which every qualifying show passes is the answer. Skip shows that nobody started so they don't short-circuit the result to -1.

Follow-ups the interviewer actually asked:

  1. What if episode 1 had zero viewers for a given show? Skip it.
  2. What if every show already satisfies the condition at episode 0? Return 0, the loop handles that.
  3. Can you rewrite the inner check without a branch? I used a boolean aggregator approach, which he accepted.

Ten minutes for questions at the end. I asked about WLB and NYC commutes. He was warm about it, said "let me confirm your next round right now," and scheduled VO2 live.

VO2 (60 min)

Same structure: self-intro, BQ, then a coding/OOD hybrid.

BQ: - Tell me about a disagreement with a teammate and how you resolved it. - What is something on your resume you think is under-appreciated?

Coding + OOD Problem: Tesla Equity Tracking System

Design a real-time equity system for Tesla stock where:

  • A `Trader` can update the latest price each day, or remove (undo) the most recent price.
  • An `Analyst` can query: latest price, maximum price seen so far, average price.
  • All operations must be O(1).

This is three monotonic-structure tricks wrapped in an OOD skin. The two-stack max pattern works: maintain a primary stack of prices plus a parallel stack of max-so-far where each push stores the max of the new price and the current top. Pushing and popping stay O(1) for max queries. A running sum plus count gives O(1) average. Latest is just the top of the price stack.

Follow-up he pushed on: "What if the analyst also wanted the median price in O(1)?" I said you cannot get pure O(1) without relaxing something, but the classic two-heaps pattern gives O(log n) update and O(1) median query. I sketched it: a max-heap for the lower half, a min-heap for the upper half, rebalance on every push. He was satisfied with "log n update, O(1) query, and the reason you can't do better than that in the comparison model."

Then he asked me to turn the design into separate Trader and Analyst classes so the domain boundary was clear. I refactored quickly: Trader holds a reference to an Equity and only exposes update and remove latest ; Analyst exposes the three queries. The shared state is the single Equity object. Clean and easy to test.

Again, 10 minutes of questions at the end, again on WLB and the NYC office. Again scheduled the next round on the call.

HR Round (45 min)

Pure behavioral. No coding. Questions I got:

  • Tell me about a disagreement with teammates.
  • Tell me about a time you learned something completely new from scratch.
  • Why computer science?
  • Why Bloomberg, again?
  • Talk about something you did not put on your resume.

That last one is a classic screening question. I had two "off-resume" items ready: a side project writing a small TUI for tracking my caffeine intake, and a pre-college stretch where I worked retail and learned to read people quickly. The TUI story did more for me.

The HR rep closed by saying she'd loop me into the EM round but could not book it the same day. That signal felt positive but I tried not to over-read it.

EM Round (60 min)

This was by far the hardest round of the loop.

Five minutes on my resume, then two behavioral:

  • What did you like most and least about your last team?
  • Why Bloomberg?

Then straight into system design: "Design Kafka from scratch."

I was not prepared for a full message queue design cold. I had skimmed some Kafka internals but had not rehearsed it. My first 10 minutes were rough. I started with producers and consumers and topics, which is the right skeleton, but I stumbled when he asked how to guarantee message ordering across partitions. I honestly did not know the leader-follower consensus answer, which is what he was looking for.

He gently redirected: "Think of it as a distributed log. One broker is the Leader for a partition. Others are Followers. Leader decides the offset order. Followers replicate. What protocol lets them agree on who the Leader is?"

Raft. Which I had read about in class but not prepped cold. I recovered and walked through the Leader-election + log-replication flow, added an ISR (in-sync replica) concept, and handled the follow-up about what happens when the Leader crashes mid-write.

By the end I felt shaky but he closed warmly: "Any questions about NYC?" and we spent the last 10 minutes chatting about the city. I thought I had blown the round but apparently the recovery mattered more than the rough start.

Practice it: [[problem/503?company=11|Design Kafka Message Queue]]

Result

Two days later I got the offer call. SDE new grad, NYC. Compensation was within 5% of where Bloomberg's published NYC new-grad band typically lands, which lined up with what peers had reported for previous cycles.

Tips

  1. For VO1 and VO2 back-to-back, pace your energy. Two 60-minute BQ+coding rounds is real fatigue. I ate lunch between them and kept my phone off; friends of mine who skipped lunch said they felt foggy in VO2.
  2. Tesla Equity style problems are a Bloomberg signature. Stack + aux-stack for O(1) max, running sum for O(1) average, two-heap for O(log n) median. If you can recite those three patterns on demand, you cover half of Bloomberg's new-grad OOD pool.
  3. "Why Bloomberg" demands specificity at the NG loop. Every round will ask it. Have a non-trivial answer that points at a concrete engineering artifact: the Terminal, their messaging bus, a blog post you read. "I like finance" gets dinged in the rubric.
  4. For the EM round, prep distributed-log basics. Kafka, Raft basics, leader election, partitioning, ISR. You do not need to implement Kafka but you have to know the vocabulary and why a Leader exists. I did not and it cost me 15 minutes of interview time.
  5. Ask about WLB on every round. Bloomberg cares about two-way fit and your interviewers get rated on how well they sold the team. A candidate who asks "what does your week actually look like?" gets the interviewer talking, and a talkative interviewer is a happy interviewer.
  6. Recover, do not spiral. In the EM round I felt my face go red when I couldn't answer the first architectural question. I recovered by saying out loud "let me back up and think through the log-replication piece from scratch." The slow-down saved me. Interviewers are watching whether you break or whether you re-regulate.

The Bloomberg NG loop moves fast. Expect a decision within 10 days of the onsite.