HackTheRounds Interview Experiences

Bloomberg SDE New Grad Interview Experience (2026) - OOP Tesla Equity Design & Kafka EM Round, Offer

Bloomberg 2026 SDE New Grad loop with OOD focus: phone screen social graph BFS and vowel substrings, VO1 TV retention, VO2 Tesla equity O(1) class design, EM Ka

By Anonymous ยท 2026-03-31

Background

The part of the Bloomberg New Grad loop nobody warns you about is how much object-oriented design shows up, specifically in VO2 and at the tail end of the EM round. I came into the loop assuming it would be a pure coding gauntlet like the Amazon SDE pipeline. It is not. Bloomberg grades you heavily on whether you can split a problem into sane classes and defend the boundaries under follow-up pressure. I am a CS masters student applying through the Bloomberg careers site for the 2026 SDE New Grad program, NYC office, and this post is the OOD-heavy recap I would have wanted before I went in.

Timeline

Total: 5 weeks from first contact to offer.

Phone Screen (45-60 min)

Two coding problems, advertised as medium difficulty. The screener was pleasant and clearly running to a fixed script.

Problem 1: Find the first matching partner in a social graph

Problem: Given a social graph as an adjacency list and a starting user, find the first connected user who satisfies a given predicate. Breadth-first from the start, the start node itself does not count as its own partner, and ties break by BFS visit order.

Plain BFS on the adjacency list. Queue starts with the start user's neighbors (not the start itself), and the predicate is evaluated on dequeue. Return as soon as a match is found. O(V + E) time, O(V) space for the visited set.

I wrote it in about 10 minutes. The interviewer asked what changes if the graph can be cyclic (nothing, the visited set handles it) and what changes if the predicate is expensive to evaluate (batch-evaluate by BFS level). Small clarifications, nothing tricky.

Problem 2: Count vowel substrings (LC 2062 variant)

Problem: Given a lowercase string, count the contiguous substrings that contain all five vowels at least once and zero consonants. The brute force is O(n^3), the two-pointer sliding window is O(n).

I wrote the O(n^2) brute force first, which passes, and the interviewer nudged me to the O(n) sliding window. Track the last consonant position and the earliest start of a valid all-vowel window, then for each index count how many valid substrings end there in O(1) using the last-consonant anchor.

We finished with 10 minutes of questions about Bloomberg engineering culture. No follow-up.

VO1 (60 min)

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

Round 1: TV show user retention

Problem: Given per-episode retained user counts for a 10-episode show, return the earliest episode number such that at least 70 percent of users watching at that episode will go on to finish all 10. Return -1 if no such episode exists.

Straight suffix-ratio scan. For each episode n from 1 to 10, check whether retained[9] / retained[n] is at least 0.7. Smallest n satisfying this wins. O(10) time.

The interviewer asked me to remove the explicit if branch in the inner check and pushed on edge cases. I rewrote the comparison using multiplication: retained[9] 10 = retained[n] 7 , which also sidesteps divide-by-zero when episode 1 loses everyone. Follow-ups covered the "everyone drops off at episode 1" case (-1, naturally) and "everyone watches all 10" (return 1, trivially).

Practice it: [[problem/499?company=11|TV Show User Retention Analysis]]

VO2 (60 min): the OOD round

This is the round that decided my loop. Bloomberg runs VO2 as a combined coding plus OOD session, and the grading rubric weighs the OOD half more than candidates expect.

Round 2: Tesla equity price service

Problem: Design an in-memory service tracking the price history of a single equity. A Trader can post a new daily price or remove the most recent posted price. An Analyst can query the latest price, the all-time maximum price, and the running average across all posted prices. Every operation must be O(1).

The data-structure half is two stacks plus running accumulators. Primary stack holds the price history in posting order. A parallel max-stack pushes the current running max on each post, so a remove pops both stacks in sync. Running sum and count are kept as two additional scalars, updated incrementally on each post and remove. Average = sum / count, O(1).

The interviewer then asked for a median query under the same O(1) constraint. That is impossible for strict O(1) on arbitrary data, but two heaps give O(log n) with a balanced max-heap on the lower half and a min-heap on the upper half. I sketched the balancing rule aloud and the interviewer accepted the reduction.

The OOD half was where the follow-up lived. The interviewer wanted the service split into three classes: Equity (owns the price storage primitives and enforces invariants), Trader (write-side API, references Equity), and Analyst (read-side API, references Equity). Expected design points:

  • Encapsulation: no public price-history field on Equity. Everything goes through methods.
  • Single-responsibility: Trader does not compute analytics, Analyst does not post.
  • Observer hook: an Analyst can register for a "price updated" callback. The Equity notifies registered observers on each post or remove. Standard observer pattern.

I did not have to write full code. The interviewer wanted to see that I could defend "why three classes and not one" and "what invariants each class enforces."

HR Round (45 min)

Pure behavioral. Five prompts:

  • Tell me about a disagreement with a teammate.
  • Tell me about something new you learned recently.
  • Why computer science.
  • Why Bloomberg.
  • Something that is not on your resume.

Short answers. The HR interviewer was timing loosely, cutting people off around 90 seconds per prompt. Prepare one 90-second take per story, not the full STAR monologue you would use for Amazon.

EM Round (45 min)

Resume plus behavioral for the first 15 minutes, then system design for the remaining 30. The EM was sharper than the VO interviewers and pushed harder on the design.

Design prompt: Build a message queue system. Basically Kafka from zero.

I was not prepared for this prompt specifically. My walkthrough covered:

  • Producers and consumers talking to a cluster of broker nodes.
  • Topic partitioning for horizontal scale, with each partition as an append-only log file on disk.
  • Consumer groups pulling from partition offsets, with offset commits for at-least-once delivery.
  • Replication across brokers for durability.

The EM pushed on leader election across brokers, which is where I stalled. The right answer is Raft (or similar consensus): the leader sequences all writes for its partitions, followers replicate in order, and a failover re-elects a new leader on timeout. I got there with help.

Behavioral prompts: best and least favorite things about my current team, and why Bloomberg over another NYC offer I had mentioned. Concrete answers, no deflection.

Result

HR called three business days after the EM round with the offer. Compensation matched the published band. The whole loop, from phone to offer, ran in under 30 days.

Tips

  1. Prepare for OOD as hard as coding. Bloomberg VO2 grades class-boundary discipline separately from algorithm correctness. Know the observer pattern, know when to split a service into multiple classes, and be able to defend the boundaries under pushback.
  2. For the Tesla equity problem, two stacks beats a sorted structure. Candidates over-engineer this with balanced BSTs. Two stacks plus running sum is strictly O(1) per operation and is the intended solution.
  3. Rewrite ratio comparisons as multiplications. On the TV retention problem, `a/b >= 0.7` becomes `a * 10 >= b * 7`. Sidesteps floating point and divide-by-zero in one move.
  4. Keep HR behavioral answers under 90 seconds. The HR interviewer is timing loosely but strictly. Bloomberg's behavioral footprint is short across the loop, which rewards candidates with tight 90-second versions of each core story over the full STAR monologue.
  5. Prep one system-design answer per major pattern for the EM round. Message queue, Top-K analytics, chat service, distributed KV store. The Kafka prompt is increasingly common at Bloomberg EM rounds, and candidates who have not prepped it specifically stall on leader election.
  6. Ask about NYC commute and WLB at the end of each round. This sounds like filler, but Bloomberg interviewers seem to actively weigh "will this person accept if we offer." Showing you have thought about the commute and are excited about the office signals seriousness without costing you time.