2025–2026 Bloomberg New Grad Interviews: 98 Experiences (Part 3 :)

Continued from Part 2: question mechanics, optimization follow-ups, and interviewer-dependent formats.

Coverage: Timelines 23–36 of 50 detailed candidate reports. The 98-experience count applies to the complete series.

50 detailed candidate timelines, loops, and screens ～ continued

23: Five positive rounds, then rejection after debrief

Report date: November 2025 · Role: New Grad SWE · Result: Rejected

The first Zoom round used a challenging project, two coding tasks, and a compact high-traffic design follow-up. The next day’s campus loop covered an N-ary tree decoder, graph transformations, DFS-versus-BFS tradeoffs, a book-recording object model, and a top-K extension. HR felt encouraging.

The final manager had nearly 20 years at Bloomberg. The candidate spent more than 40 minutes on the resume, used a whiteboard, learned about Terminal and the manager’s own proud project, and left feeling excellent about the interaction. A week later HR said debrief was still underway; the rejection came that evening. The candidate’s own retrospective focused on answers that may have been too long and follow-ups that exposed weak generalization—not on rapport.

24: Invalid Transactions in strict linear time

Report date: November 2025 · Role: New Grad SWE · Stage: Campus loop

The first round used Invalid Transactions with input already time-sorted and required O(n) processing. The candidate grouped by user and maintained a sliding 60-minute window with city counts. A long reply discussion exposed the key bug: amount-based invalidity must remain set even after a transaction leaves the city-conflict window.

The second round generated every replacement of wildcards in a binary string, then designed a fair activity-registration system with register, unregister, and topK. The candidate proposed an LRU-like linked list plus hash map. The interview mixed algorithmic correctness with state ownership and API design.

25: Relaxed screen with Subsets and an eventual offer

Report date: November 2025 · Role: New Grad SWE · Location: New York City · Result: Offer

The first ten minutes covered the resume. The technical portion allowed the candidate to choose language and data structures and was described as relaxed. The first problem was easy; the second was medium and asked for all subsets of a list.

The public report confirms the offer but does not preserve the remaining loop. It is therefore evidence for one screen and its outcome, not for the complete route to the offer.

26: A simple BFS base problem with a difficult fuel follow-up

Report date: October 2025 · Role: New Grad SWE · Result: Passed VO1

A desert grid contained a car c and oasis o. The base task was shortest steps and yielded to ordinary BFS. The first follow-up gave the car finite fuel, consuming one unit per move. The second allowed arbitrary cells to refill arbitrary fuel amounts.

The candidate was comfortable with the base case and said the refill version was the true challenge. Code had to be written and explained but not executed. The author’s round contained no resume discussion; another candidate in the reply thread reported the opposite, so the article does not turn that into a universal rule.

27: No phone screen—referral straight to VO and offer

Report date: October 2025 · Role: New Grad SDE · Result: Offer

The candidate was referred September 11, went directly to VO1 on October 2, and completed a superday on October 8. Technical questions included a Two Sum variation, Flatten a Multilevel Doubly Linked List, Number of Islands, and Merge Intervals. HR used standard behaviorals.

The October 13 manager was a 20-year Bloomberg veteran who mostly described their own work and asked the candidate little. The author treated this as a compatibility conversation, not team matching. The offer call arrived October 23. This candidate’s first-round post and later full-process post were merged as one experience.

28: Most-read Bloomberg news as a dedicated system-design round

Report date: October 2025 · Role: New Grad SWE · Stage: Third interview

Every article click emitted read_event(articleId). The candidate had to design an API that returned the most-read recent news. The report does not define “recent,” K, duplicate readers, consistency, or throughput, and does not preserve the final architecture.

What it does establish is process variation: this was a dedicated New Grad system-design round before the manager interview. HackerRank was only the meeting surface; the candidate drew the design on a whiteboard and did no coding. Other candidates in the same cycle had coding instead.

29: Autocomplete, two fast VOs, then rejection after HR

Report date: October 2025 · *Role: 2026 New Grad SWE · Result: Rejected

The phone screen was object-oriented design for autocomplete, though the exact API and ranking rules were not preserved. VO1 used dictionary operations plus another coding problem. VO2 contained two more coding tasks. The candidate completed the VOs quickly, received immediate pass deciisions, and reached HR.

HR covered standard behaviorals, “Why Bloomberg?”, and the training program. Unlike the technical rounds, HR ended with “wait for an update.” The rejection arrived two workdays later. The source cannot establish why, but it clearly contradicts the idea that HR is always a formality.

30: Campus Collatz problem and a memoization hint

Report date: October 2025 · Role: 2026 New Grad SWE · Result: Rejected

A campus recruiter moved quickly from notification to a one-hour first round. The opening covered a project of the candidate’s choice, how they chose among technical options, and “Why Bloomberg?”

The coding task implemented the Collatz process. The follow-up asked how to optimize repeated calls. After the candidate considered powers of two, the interviewer nudged them toward caching prior results. A dry run revealed a bug in what should be stored for the current result; two hints helped identify the line. No same-day continuation followed, and the candidate later treated the outcome as a rejection.

31: A campus question list that shows breadth, not certainty

Report date: October 2025 · Role: New Grad SWE · Stage: Campus process

The author collected nine problem references seen in the process: Insert Delete GetRandom, Number of Islands, 3Sum, Invalid Transactions, Gas Station, LRU Cache, Search in Rotated Sorted Array, Top K Frequent Elements, and Binary Tree Vertical Order Traversal.

They warned that Bloomberg modified the base questions and cared about optimization. Resume depth also varied: one interviewer might pick any technology from a project and probe it. The author’s process had five rounds, beginning online and continuing in person at the school. Because the source does not map each question to one round, the article does not manufacture a fake sequence.

32: EMEA Count Ships round where the naive API call was legal

Report date: October 2025 · Role: New Grad SWE · Location: EMEA office · Status: Waitlisted in the source

Two interviewers ran the one-hour second round in an office. A hasShips(a, b) API reported whether a rectangle contained at least one ship; the candidate had to implement a total count.

The author confirmed that calling hasShips(a, a) on every cell was allowed. The interviewer then asked how to optimize, which is where divide-and-conquer pruning becomes relevant. The candidate later said the next stage would be system design, but the thread never recorded that interview or a final outcome beyond the waitlist label.

33: RandomizedSet and Next Greater Element II variants

Report date: October 2025 · Role: New Grad SWE · Result: Rejected

A five-year Bloomberg interviewer opened with resume and shallow technical follow-ups, then gave variations of Insert Delete GetRandom in O(1) and Next Greater Element II. The candidate had a large-company internship and came through a referral.

No variation details survive, which limits how much the questions teach. The useful timeline detail is that the rejection arrived two days later, despite the candidate rating the technical difficulty average.

34: Two sorted strings and a precise one-hour screen

Report date: October 2025 · Role: New Grad SWE · Location: United States · Result: No offer

The Zoom round used ten minutes for resume and “Why Bloomberg?”, forty minutes for coding in a shared HackerRank console, and five minutes for candidate questions. The task supplied two sorted strings and asked for characters present in the first but not the second.

This is a small report, but it is concrete about the timing, platform, input shape, required output, and outcome. It supports the screen-format pattern without implying that this exact task is common.

35: Four campus questions, including an uncommon DP problem

Report date: September 2025 · Role: New Grad SWE · Result: Rejected

The Zoom round explored an internship project, Partition List, and Path Sum II. The in-person round continued with resume details, Product of Array Except Self, and Edit Distance.

The candidate completed the problems but described the onsite interviewer as distracted and repeatedly occupied with something on paper. The rejection followed. In replies, the author said the event was at a large East Coast CS school and that Zoom versus onsite did not change the substantive evaluation. They considered the DP problem uncommon, but still worth a light review.

36: Scam transactions plus a small object-design exercise

Report date: September 2025 · Role: New Grad SWE · Location: New York City · Result: No offer

The candidate described one LeetCode-easy problem and one easy object-oriented-design question. The preserved prompt involved a list of transactions and deciding which were fraudulent or invalid.

The report lacks the invalidation rules, so this article does not silently equate it with any particular public problem. Its value is showing that a coding round can combine a small algorithm with class/interface design even when neither feels conventionally hard.