A practical roundup of firsthand Bloomberg New Grad software-engineering reports from the 2025 and 2026 hiring cycles.

Coverage: 98 deduplicated candidate experiences across the United States, United Kingdom, Germany, India, Japan, and unspecified locations. The evidence covers recruiter and campus pipelines, technical screens, virtual and in-person loops, HR, engineering-manager rounds, offers, rejections, pending cases, and ghosting.

For a fren~

Beginning of A Story

Bloomberg’s loop has a recognizable shape, but the questions and even the number of rounds still depend heavily on the interviewer, location, and recruiting channel.

1. Five conversations is the most recognizable full loop, not a guarantee. A common path is one technical screen, two more technical rounds, HR, and an engineering-manager interview. Campus candidates sometimes did the technical rounds in person, while other candidates had them back-to-back on Zoom.
2. The first hour often follows a 10/40/10 rhythm. Expect roughly ten minutes on introductions, a project, and “Why Bloomberg?”, about forty minutes of coding, and the final ten minutes for complexity, dry runs, follow-ups, and your questions.
3. Medium problems dominate, but “medium” hides a lot of variation. Some candidates saw familiar tagged questions. Others received Bloomberg-flavored class design, streaming state, graph, debugging, or system-design prompts that did not resemble a memorized LeetCode statement.
4. The follow-up is often the real interview. O(1) operations, less memory, arbitrary character sets, changing input order, very large traffic, or one more business requirement repeatedly turned an ordinary solution into the part that mattered.
5. Execution rules vary. Some rounds required compiling and running code in HackerRank. Others asked only for clean code, test cases, and a careful dry run. Confirm the expectation before you start.
6. Resume work is not filler. Project ownership, technical choices, tradeoffs, failures, scope control, and communication appeared from the first screen through the final manager round.

Recruiter, phone-screen, and campus-screen patterns

Screen 01: One problem with a long optimization ladder

Observed across: New York and unspecified U.S. New Grad reports

1. Five to fifteen minutes of introductions, resume, or motivation.
2. One medium problem for most of the technical block.
3. Several follow-ups on complexity, storage, scale, or changed requirements.
4. A dry run and explicit time/space analysis before candidate questions.

This format can feel easier than a two-question round, but it gives the interviewer more time to keep changing the problem.

Screen 02: Two problems in about forty minutes

Observed across: New York, campus, London, Frankfurt, Pune, and Tokyo reports

1. A first problem that is often familiar enough to solve quickly.
2. A second problem or object-design task that tests whether the candidate can switch patterns under time pressure.
3. Follow-ups may be verbal even when the base problem must be coded.

Candidates who did well consistently described the same habit: clarify first, get agreement on the approach, then write the implementation.

Screen 03: Campus and conference pipelines move differently

Observed across: U.S. university visits, GHC, and smaller event pipelines

Some candidates interviewed on campus, waited outside, and learned the same day that they would continue. Others received a virtual first round and were later invited to campus. Conference pipelines could begin directly with an onsite-style technical round. None of those formats reliably predicted the final outcome.

Screen 04: Same-day continuation is scheduling, not a promise

Observed across: U.S. virtual superdays and campus loops

Candidates were often told to reserve three or four hours because rounds two, three, and HR might happen on the same day. Some continued immediately. Others were split across several days or even two weeks because of interviewer availability. A missing same-day invite was sometimes a rejection signal, but not consistently enough to treat it as a rule.

Live interview question bank

Hash maps, caches, and constant-time state

1. Randomized participant set. Support adding a unique ID, removing an ID, and returning a uniformly random active ID, all in average O(1) time. Follow-ups asked about empty state, duplicates, and class boundaries.
2. LRU-style state. Implement or design an LRU cache, browser-history variant, nested-bracket structure, or recently used record store. Candidates were asked to justify the hash-map-plus-linked-list split and remove library shortcuts.
3. Hit counter. Track events in a rolling time window, then answer counts efficiently. Follow-ups pushed toward O(1) time and space or changed the timestamp assumptions.
4. Autocomplete. Design the classes and update/query operations for an autocomplete service. The source did not always preserve ranking rules, which is exactly why requirements clarification matters.
5. Latest, maximum, and average stock price. A trader appends or removes the latest daily price; an analyst queries latest, max, and average, with all operations requested in O(1). Strong answers separated domain roles instead of putting everything in one class.
6. URL or browser history. Insert and remove history records, navigate state, or print stored URLs with constant-time lookup. Follow-ups exposed why a linked list alone still has linear search.

Strings and parsing

1. Cascading duplicate removal. Remove runs of k equal characters until the string stabilizes. Variants changed simultaneous versus sequential removal and asked for an in-place two-pointer solution instead of an extra stack.
2. Run-length encoding. Convert a string such as aabbcc to 2a2b2c, then discuss malformed input, long counts, or streaming input.
3. Decode String. Expand an expression such as 2[a2[bc]]. Candidates needed a correct stack or recursive parser and a clean dry run through nesting.
4. Equalize frequency with one deletion. Decide whether removing one character can make every remaining character frequency equal. Interviewers asked candidates to avoid assumptions about a tiny alphabet.
5. Wordle checker. Compare a guess with a target and distinguish correct position, present-but-wrong position, and absent letters. Duplicate letters are the important edge case.
6. Anagrams at scale. Valid-anagram and group-anagram variants added arbitrary ASCII or Unicode characters and asked for constant-factor improvements to hash-map access.
7. Streaming palindrome. Design track(char) and isPalindrome() for a character stream described as potentially terabytes long, with query time below O(n). One candidate could not produce a fully convincing exact solution; the report did not establish that a rolling hash was acceptable.

Trees, graphs, and grids

1. Shortest path with fuel. Find the shortest grid path from a car to an oasis. Then cap available fuel, and finally allow arbitrary cells to refill different amounts. The base case is ordinary BFS; the refill state is the real design problem.
2. Invalid transactions. Transactions are sorted by time. Mark amounts over a threshold and transactions by the same user in different cities within 60 minutes, while preserving independent invalidation reasons in linear time.
3. Vertical order and column reconstruction. Traverse a tree by horizontal column and top-to-bottom order to reconstruct a string. Variants changed the tree’s geometric placement rules.
4. N-ary minimum-sum path. Return a root-to-leaf path with the smallest node-value sum, not merely the sum.
5. Count ships through an API. Use hasShips(a, b) to count ships in a rectangle. Querying individual cells worked but triggered an optimization follow-up.
6. Grid defense. Choose a tower position that covers the most houses within Manhattan distance k.
7. Paths with obstacle eliminations. Find a shortest grid path while traversing at most k blocked cells, so the visited state must include remaining eliminations.
8. Graph transformations and social connections. Reports included BFS/DFS conversions, first qualifying partners, route insertion and enumeration, and follow-ups that changed the graph state or required an optimal traversal.

Intervals, streams, and market events

1. Meeting rooms and maximum overlap. Compute the minimum room count, then return the maximum number of simultaneous intervals.
2. Merge typed intervals. Merge overlapping intervals while preserving a category, which turns one global merge into grouped processing.
3. Most-read news. Consume read_event(articleId) and serve the most-read recent articles. The useful discussion is defining “recent,” update volume, duplicate readers, and consistency.
4. Mutable Stock Price Top K. Support updates and top-K queries while handling stale heap entries or discussing a scalable architecture.
5. User-retention threshold. Given episode-by-episode churn, find the point at which a target percentage can still finish a season. Follow-ups covered complete churn, complete retention, and simplifying conditional logic.

Object-oriented and system design

1. Blackjack or card system. Model a deck, shuffle/draw behavior, players, empty-deck safety, and who owns the decision to continue drawing.
2. Connect Four. Build the game state and operations, then defend class ownership and win detection.
3. Subway-card swipes. Design a complete class beginning at initialization, with enough state to support station entry/exit behavior.
4. To-do or activity registration. Support add/delete/query operations, completed IDs, registration fairness, or top-K users.
5. Kafka / distributed commit log. Explain producers, consumers, topics, partitions, brokers, retries, replication, acknowledgements, leader election, durability, and ordering.
6. Reconciliation system. A Frankfurt report received a full reconciliation design prompt, while other candidates saw small data-structure design instead of high-level architecture.
7. Modernize a legacy service. Discuss technology tradeoffs, scalability, reliability, migration order, and how to reduce rollout risk.
8. Debug a failing service. An engineering manager gradually introduced failures into a single-machine file service and evaluated the debugging process rather than asking for code.

Behavioral and manager prompts

1. Why Bloomberg, and what can Bloomberg offer that a general big-tech company cannot?
2. Walk through a project you owned. Why did you choose that architecture?
3. What failed, what did you change, and how did you measure the result?
4. How did you control scope when requirements grew?
5. Describe disagreement, weak teammate delivery, conflict, or difficult feedback.
6. What do you want from your next job, and what are you worried about when joining?
7. Explain one technical concept to a technically literate person who does not know the domain.
8. If you disappeared tomorrow, could another engineer continue your project?

50 detailed candidate timelines, loops, and screens

Ordered newest to oldest by report month. Reports from the same month retain source order; when a source preserved only a broader time window, the date line says so explicitly.

01: Sliding-window users, stock updates, and relentless tradeoffs

Report date: May 2026 · Role: New Grad SWE · Location: New York City · Status: Pending

The screen began with a recent project, storage choices, QPS growth, production bugs, and cache invalidation. Coding then designed a five-minute active-user counter. A queue plus per-user counts worked for ordered events; follow-ups introduced duplicate users, out-of-order timestamps, sharding, frequent queries, cached results, cleanup, and inclusive time boundaries.

The second task used Mutable Stock Price Top K to maintain updated stock prices and answer top-K queries. The candidate proposed a heap plus a map and lazily discarded stale heap entries after updates. The interviewer cared less about obscure tricks than about tradeoffs, edge cases, and whether the candidate could explain every state transition.

02: Pune offer after hints, long waits, and honest team matching

Report date: April 2026 · Role: Entry-level/New Grad SWE · Location: Pune · Result: Offer

A recruiter reached out in late November. Round one spent 20 minutes on a project and 40 minutes on one tagged DSA task. Round two added a tagged problem and a trie challenge; the candidate could not finish the trie code but explained a hash-map alternative after hints and still advanced.

The supposed “system-design” round instead asked for a specific data structure and one tricky edge case. Feedback took two weeks, and the final HR/manager invitation took almost another month. After the manager conversation, Bloomberg proposed an SRE match. The candidate said their real interest was SWE, waited, followed up, and ultimately received the SWE offer.

03: Five-round 2026 loop ending after the manager conversation

Report date: April 9, 2026 · Role: New Grad SDE · Result: No offer

The candidate summarized an initial DSA screen, a superday elimination loop with two more technical interviews and HR, and a final engineering-manager conversation about experience and culture fit. They described the process as rigorous and said the rounds felt strong, but the final outcome did not match expectations.

This report is short on exact coding mechanics, so it is used for process shape and late-stage outcome—not to support a question-frequency claim.

04: Reliable enrichment aggregation over an event stream

Report date: March 2026 · Role: New Grad SWE · Status: Outcome not disclosed

Documents passed through multiple semantic enrichers. Events contained document ID, enricher ID, and payload. The Document Enrichment Stream Aggregator had to ignore unrelated enrichers and publish a document only after every configured required enricher had arrived.

The reliability follow-up forced partial publication ten seconds after a document’s first event, even if one enricher never responded. A workable design needed per-document state, first-seen timestamps, idempotent emission, and either lazy expiration checks or a periodic scanner. The source included executable demonstration code; the important interview signal was reasoning about incomplete distributed work, not copying that implementation.

05: Count Ships followed by nested decode, then a rejection

Report date: March 2026 · Role: New Grad SWE · Result: Rejected

The first problem was Count Ships in a Rectangle. The candidate produced the hard solution by hand. The second was Decode String. Time expired before the second implementation was complete, even after hints.

The preceding conversation focused on the candidate’s most recent internship. Bloomberg had no visible public New Grad role; a recruiter had contacted the candidate through LinkedIn. The report does not preserve the exact hints, so the rejection cannot be reduced to one guessed technical mistake.

06: Correct multilevel-list code after an unclear pointer explanation

Report date: March 2026 · Role: New Grad SWE · Result: Rejected

After a short project discussion, the candidate had to solve Flatten a Multilevel Doubly Linked List. The hard part was reconnecting the tail of a flattened child list to the rest of the parent chain.

The candidate struggled to describe those pointer relationships during the first dry run, then became much clearer once coding began. They completed a working recursive solution and answered the follow-ups, but still received a rejection. Their own lesson was specific: for pointer problems, establish the reconnection invariants before writing code rather than hoping the code will make the explanation clearer.

07: Two City Scheduling and a subway-connectivity ambiguity

Report date: March 2026 · Role: New Grad SWE · Result: Rejected

The interviewer first went deeply into the resume, then asked Two City Scheduling with an Odd Candidate Count. The second task supplied subway-station connections and asked whether arbitrary station pairs were connected.

The source never resolves whether connections were directed, whether constant-time queries were required, or how the graph was represented. That ambiguity led commenters to propose both Union-Find and strongly connected components. The author only confirmed that both problems required candidate-written tests. This is precisely the kind of prompt where asking about direction, update frequency, and query volume is part of the solution.

08: Linked list, arrays, graph/backtracking, HR, then scalable-system debugging

Report date: March 24, 2026 · Role: New Grad SWE · Result: No offer

The first three rounds moved through linked lists, arrays/hash tables, and graphs/backtracking. HR discussed prior experience and collaboration. The final round used a scalable-system design/debugging scenario and focused on identifying failures, reliability, maintainability, and the reasoning behind tradeoffs.

The candidate’s public retrospective did not expose exact prompts, but it clearly supports a five-round path and an engineering-focused final stage. They praised the conversations while continuing to search for a New Grad role, indicating that the completed loop did not produce the hoped-for outcome.

Continued in Part 2 with timelines 09–22.