Interview experience
Bloomberg interview experiences covering Recruiter/HR Screen, Technical Interview 1, Technical Interview 2, Engineering Manager Round, +1 more. Round-wise notes, common questions, and what candidates report clears each stage.
Explore: Interview experience · HR interview questions · Overview · Placement papers · Preparation guide
Bloomberg runs a HackerRank-CodePair loop with a technical bar on the higher side, shaped throughout by the company’s C++, low-latency, real-time-data engineering culture behind the Terminal.
Interview experience
Bloomberg interview experiences covering Recruiter/HR Screen, Technical Interview 1, Technical Interview 2, Engineering Manager Round, +1 more. Round-wise notes, common questions, and what candidates report clears each stage.
HR interview questions
Bloomberg HR interview questions with sample answer frameworks - motivation, relocation, STAR stories, and culture-fit prompts.
| Round | Duration | What they test |
|---|---|---|
| Recruiter/HR Screen | 30-45 min | Background, motivation, location/visa logistics |
| Technical Interview 1 | ~60 min | DSA (LeetCode medium-hard) via HackerRank CodePair |
| Technical Interview 2 | ~60 min | DSA plus systems-design fundamentals |
| Engineering Manager Round | 30-45 min | Past technical decisions, engineering judgment |
| HR/Final Round | ~30 min | Cultural fit, compensation discussion |
These answers are compiled from public candidate reports for Bloomberg’s India (mainly Pune) software engineer hiring, not from an official notice, and loops differ by team and year. Your recruiter’s email is the final word.
| Question | Answer |
|---|---|
| Is there an online assessment? | Usually not, in public India reports. Most new-grad and intern accounts start with a recruiter call and a live phone or CodePair coding interview (2025 Pune Glassdoor reports also open with a phone screen, not a test); on campus, a coding interview follows registration and the pre-placement talk. A few prep guides mention a 1-2 problem HackerRank test, so check your invite. |
| Does it have negative marking? | No MCQ test is reported, so there is nothing to be negatively marked. Screening is done in live coding interviews scored by the interviewers. |
| How many coding questions per round? | Usually 1-2 LeetCode-medium problems or 1 hard in about 60 minutes. A 2022 Pune new-grad phone round asked Meeting Rooms II and a variation of LRU Cache; an October 2025 Pune report describes one LeetCode-hard problem with hints, plus intro and one project. |
| Which platform is it on? | HackerRank CodePair on most loops, with camera on; the August 2022 Pune new-grad report also coded on HackerRank, and one intern report names HackerEarth or HackerRank. Code is often only dry-run rather than compiled, so walk through test cases yourself. |
| Which language should I use? | Any mainstream language is accepted. If C++ is on your resume, expect follow-ups on memory, move semantics and cache behaviour. |
| How much is the cutoff? | Not published; shortlists are relative to the pool. One PICT Pune on-campus drive (January 2023) went from about 300 registrations to 11 candidates in the in-office design round and 3 offers. A 7.5+ CGPA preference is sometimes cited, but we found no recent report confirming a CGPA bar. |
| How many rounds in 2025? | One January 2025 Pune offer report lists four: a remote phone screen, an onsite technical interview, an onsite non-technical interview and a remote HR interview, with travel and stay paid. |
| Do freshers get system design? | Often, yes. Reported fresher design rounds include an e-commerce site like Amazon (2022 Pune new grad) and an Uber-style cab service (2023 PICT campus). |
Bloomberg hires freshers as software engineers and software engineering interns. These are questions candidates have reported on GeeksforGeeks and other public write-ups; they show the level, not a fixed list.
| Role | Reported questions and topics |
|---|---|
| New-grad SWE (Pune) | Meeting Rooms II, a variation of LRU Cache, a variation of Invalid Transactions with requirements changed midway, design an e-commerce website like Amazon, and a deep dive into a past project with a recruiter and a senior engineer. |
| SWE intern | Implement your own list class with O(1) access and resizing, and explain how much extra memory to allocate. A variant of Maximum Nesting Depth of the Parentheses returning all index pairs. A phone directory searchable by both name and number. Tracking trades to return total quantity per stock and the top K traded stocks as new trades arrive. What unit testing is. A 2023 off-campus intern round (90 minutes): first non-repeating character in a string and an even-odd logic problem, plus resume projects. |
| SWE (campus, 2024) | A problem like Design Underground System on CodePair with no template, so you choose the classes and methods yourself, then run it and defend complexity. |
| C++-heavy teams | Move semantics, cache lines and false sharing, memory ordering, virtual function cost, hash-map collision handling. |
Asked across every role: why Bloomberg (specific to the Terminal or market data, not the brand), whether you applied for the right role and graduation year, a past internship or project in detail, and teamwork stories.
A 30-45 minute call before any technical evaluation, covering your background, why Bloomberg, and logistics like location or visa status. It’s a filter for fit and eligibility, not a technical bar.
Common questions
One or two ~60 minute sessions over HackerRank CodePair/Zoom, usually split into several shorter coding segments (roughly 3-4 problems total across the loop) rather than one long problem, at LeetCode medium-to-hard difficulty. Later rounds add graphs, trees, or DP, and system-design fundamentals.
CodePair specifics (candidate-reported): Many Pune and remote loops use HackerRank CodePair with camera on and screen share. Some rounds provide no code template - you define classes, methods, and data members yourself (similar in spirit to Design Underground System or custom hash-map problems). Interviewers often ask you to run the solution and defend time/space complexity line by line.
Common questions
Round-by-round breakdowns are on the Bloomberg interview experience page.
Bloomberg’s distinctive round - instead of a fresh coding problem, an engineering manager walks through a real technical decision from your past work and pushes on the reasoning, trade-offs, and what you’d change with hindsight.
Common questions
A closing ~30 minute conversation on cultural fit and compensation, after the technical bar has already been cleared.
Common questions
Sample answer frameworks for each of these are on the Bloomberg HR interview questions page.
Bloomberg’s core product, the Terminal, is a massive, decades-old C++ system that ingests huge volumes of real-time market data with strict latency and reliability requirements, and much of it has to interoperate with legacy components rather than being built from scratch. That shapes the interview even for candidates applying to generalist SWE roles: expect coding and system-design questions framed around streaming data, time-series storage, or high-throughput pipelines rather than typical consumer-app scenarios, and expect deeper follow-up if C++ appears on your resume.
Bloomberg’s India engineering hiring is centred on Pune, but the interview panels are global. A 2023 intern report had a Pune engineer in round 1 and two London engineers in round 2, and Pune new-grad loops use the same CodePair coding, system design and manager rounds described for Bloomberg’s other offices. Do not expect an easier India version of the bar.
What differs is logistics. Campus drives in India can move the design round into the Pune office, packages are quoted in LPA rather than base salary plus bonus, and HR will ask about relocation to Pune. This page covers India software engineer hiring; if your recruiter is in London or New York, the rounds will look the same but compensation and visa questions will differ.
Competitor guides stress hard DSA, hash maps and trees, plus a serious Why Bloomberg behavioural bar. Organise around these clusters.
Framework: Clarify input, state complexity early, code cleanly, then probe edge cases. Silent coding fails even when the algorithm is right.
Framework: Frequency maps and stream problems, tree DFS or BFS, graph traversal with visit hygiene. Have one follow-up optimisation ready (space or bidirectional search).
Framework: Why the Terminal or market data path must stay correct and fast. Talk about freshness, ordering, and failure visibility in plain language.
Framework: Specific Why Bloomberg (product + your systems interest). Ownership, conflict, explaining tech to non-engineers. Vague brand answers sink offers after strong coding.
A move constructor or move assignment takes an rvalue reference and steals the source object’s heap pointers instead of copying the buffer, leaving the source in a valid but unspecified state. That turns an O(n) copy of a vector or string into an O(1) pointer swap, which is why it matters in a latency-sensitive codebase. Moves happen automatically from temporaries and from objects you pass through std::move, and the compiler will only choose them if your move operations are marked noexcept - otherwise containers like vector fall back to copying during reallocation for the strong exception guarantee. Declaring a destructor or copy operation suppresses the implicit move, which is the usual reason a class silently copies.
A cache line is the unit the CPU moves between memory and cache, typically 64 bytes, so reading one byte pulls in the whole line and touching nearby data afterwards is nearly free. False sharing happens when two threads write to different variables that happen to live in the same cache line: the hardware coherence protocol invalidates the line on the other core after every write, so the threads ping-pong the line between caches and throughput collapses even though there is no logical contention. The fix is to pad or align hot per-thread counters to their own cache line, typically with alignas(64). This is a routine Bloomberg follow-up because it explains why a lock-free structure can still be slow.
Every atomic operation carries an ordering that constrains how the compiler and CPU may reorder surrounding accesses. Relaxed guarantees only atomicity of that one variable, with no ordering, and suits a plain counter. A release store guarantees every write before it is visible to any thread that performs an acquire load reading that value, which is exactly the handshake used to publish a filled buffer to a consumer. Sequentially consistent, the default, additionally imposes a single global order across all such operations and is the safest but slowest. In a low-latency queue you pair release on the producer’s index publish with acquire on the consumer’s read.
Use a monotonic deque holding indices whose values are in decreasing order. For each new element, pop indices from the back while their values are less than or equal to the incoming value, then push the current index; pop from the front when the index there falls outside the window. The front index always holds the current window’s maximum. Each index is pushed and popped at most once, so the whole pass is O(n) time with O(k) space, beating the naive O(n times k) rescan and the O(n log k) heap version - and it is a natural fit for a streaming price feed.
Maintain two heaps: a max-heap for the lower half and a min-heap for the upper half. Push each new value into the max-heap, then move its top into the min-heap, then rebalance by moving the min-heap’s top back if the min-heap has grown larger, which keeps the sizes within one of each other. The median is the max-heap’s top when the total count is odd, or the average of both tops when it is even. Insertion is O(log n) and reading the median is O(1). If values fall in a small fixed range, a counting or indexed structure can beat that, which is a good optimisation to volunteer.
Partition by instrument and by time window so each write lands at the end of one shard, and store points column-wise rather than row-wise since queries read one field over many timestamps. Use delta-of-delta encoding for timestamps and XOR encoding for floating-point prices - consecutive ticks differ in very few bits - which compresses a tick to a handful of bits and multiplies effective cache and disk throughput. Keep recent data in an in-memory ring buffer for low-latency reads, roll it into immutable compressed blocks on disk, and precompute rollups such as per-minute open, high, low and close so chart queries never scan raw ticks.
A class with virtual functions gets a hidden pointer to a vtable, an array of function pointers, and each object stores that pointer as its first member. A virtual call reads the object’s vtable pointer, indexes it, and calls through the resulting pointer, so it costs an extra indirection and, more importantly, cannot be inlined and may mispredict in the branch predictor. In hot paths this is why performance-focused C++ codebases prefer templates and CRTP, or a switch on a small tag, over deep virtual hierarchies. Never call a virtual function from a constructor - the vtable pointer still refers to the base class at that point.
Keep an array tails where the entry at index i is the smallest possible tail value of an increasing subsequence of length i plus one. For each element, binary search for the first tail that is greater than or equal to it and overwrite that position, or append the element when it exceeds every tail. The length of tails at the end is the answer. This is O(n log n) time and O(n) space, versus the O(n squared) dynamic-programming version. Note that tails is not itself a valid subsequence - reconstructing the actual sequence needs a parallel predecessor array.
Keep a hash map from symbol to running quantity and a min-heap of size K keyed by frequency (or quantity). Each incoming trade updates the map in O(1), then adjust the heap: if the symbol is already tracked, update its key (lazy deletion or map of heap positions); if new and the heap is full, compare against the smallest entry and replace only when the new count exceeds it. Top-K queries read the heap in O(K log K) if you need sorted order, or O(K) for an unsorted snapshot. This pattern matches reported Bloomberg intern questions on streaming trades (AAPL, MSFT, etc.) with dynamic inserts after each query.
Open addressing probes alternate slots in the same array (linear, quadratic, or double hashing) until an empty slot appears; load factor must stay below roughly 0.7 to keep probes short. Separate chaining buckets colliding keys in linked lists or trees. std::unordered_map typically uses buckets with chained nodes. Interviewers use this to test whether you understand why average O(1) lookup can degrade and why rehashing happens when the table grows. In a latency-sensitive service, predictable memory and cache behavior sometimes favors flat maps or custom allocators over generic containers.
Treat the array as having a virtual sentinel smaller than all elements at both ends. Binary search on index mid: if nums[mid] < nums[mid+1], a peak exists to the right; otherwise to the left. Narrow until one index remains. Each step halves the search space, so O(log n) time and O(1) space. Bloomberg new-grad reports sometimes use this pattern with extra constraints (2D grid, multiple peaks) - state the invariant aloud before coding.
You may get a medium design prompt (parking lot, elevator, file system) with follow-ups: how would you change the design for concurrency, persistence, or new requirements mid-interview? Structure the answer as entities, invariants, and public methods first; defer optimization until the interviewer asks. Public reports describe one OOP design question with branching follow-ups rather than two unrelated LeetCode mediums in the same phone screen.
Two hash maps: name to phone and phone to name, kept in sync on insert, update, and delete. Deletes must remove both keys atomically from the caller’s perspective - if only one map updates, lookups become inconsistent. For duplicate names, map name to a set of numbers or use a composite key. Reported Bloomberg intern rounds used this as a CS-fundamentals bridge before coding.
Baseline: flag transactions over amount threshold and pairs with the same name in different cities within a time window. Follow-ups often shrink or expand the window, add dispute states, or require streaming processing. Clarify whether output must be sorted, whether times are UTC, and whether duplicate flags merge. Use a map keyed by name to lists of (time, amount, city) and sweep or sort per name for window checks.
Usually not, in public India reports. Most new-grad and intern accounts start with a recruiter call and a live phone or HackerRank CodePair coding interview of 1-2 LeetCode-medium problems, and campus drives start with a coding interview after the pre-placement talk. A few prep guides mention a 1-2 problem HackerRank test, so check your invite.
Not published; shortlists are relative to the pool. One PICT Pune on-campus drive in January 2023 went from about 300 registrations to 11 candidates in the in-office system-design round and 3 offers. A 7.5+ CGPA preference is sometimes cited, but we found no recent report confirming a CGPA bar.
Bloomberg typically runs 3-5 rounds for a Software Engineer role: 1. Recruiter/HR Screen (30-45 minutes) - background, location/visa logistics, and motivation for joining. 2. Technical Interview(s) (about 60 minutes each) - usually one or two rounds via HackerRank CodePair/Zoom, with LeetCode medium-to-hard level DSA problems. 3. Engineering Manager Round (30-45 minutes) - goes deep on past technical decisions and engineering judgment rather than fresh coding. 4. HR/Final Behavioral Round (about 30 minutes) - cultural fit and compensation discussion.
Mostly LeetCode medium-to-hard data structures and algorithms - often 2 mediums or 1 hard per round - plus systems-design fundamentals. The Engineering Manager round is distinctive - it’s less about solving a new problem and more about defending a past technical decision, so be ready to explain a choice you made on a project and what you’d do differently now.
Because the Bloomberg Terminal is largely a decades-old C++ codebase handling massive real-time data volumes, even generalist SWE interviews often lean toward streaming, time-series, and low-latency themes. Teams that work close to the Terminal frequently run at least one coding round specifically in C++, with follow-ups on memory ordering, cache behavior, and move semantics - even candidates who pick another language may get C++-flavored questions if their resume lists it.
Most Bloomberg SWE drives run 3-5 rounds: a Recruiter/HR Screen, one or two Technical Interviews (each usually 3-4 shorter coding segments rather than two long ones), an Engineering Manager round, and a final HR/behavioral round. Exact structure varies by team and location.
Practice LeetCode medium-to-hard problems since Bloomberg’s technical bar is on the higher side for a fresher process, and brush up basic systems-design thinking around high-throughput, low-latency data systems. For the Engineering Manager round, prepare a genuine story about a technical decision you made, including the trade-offs and what you’d change - Bloomberg cares more about how you think than about a ‘correct’ answer.
Unlike consumer-scale interview themes (eventual consistency, massive user counts), Bloomberg’s system-design and coding questions center on ultra-low-latency, high-reliability systems that ingest large volumes of financial data without loss, often integrating with legacy mainframes or long-lived C++ services. Expect a noticeably more rigorous DSA bar than a typical fresher process, even for generalist roles.
Yes - candidate guides repeatedly say so. Strong coding with a generic Why Bloomberg is a common failure mode. Prepare product-specific motivation and STAR stories with the same seriousness as DSA.
Yes - most India engineering reports centre on Pune. Confirm location on your specific req and be ready to discuss relocation honestly in HR.
Use this as a default four-week loop before a Bloomberg drive. Adjust to your invite timeline.
10-day crash version: Days 1-4 timed DSA, days 5-7 resume projects + CS fundamentals, days 8-9 mock interviews out loud, day 10 HR STAR stories on the HR page.
Candidate-reported fresher/early-career packages for Bloomberg often cite ₹25-40 LPA. Treat forum numbers as ranges, not guarantees - confirm the written offer letter for your team and location.
Interview process details and sample questions on this site are editorially organized from public candidate reports and hiring write-ups, with round structure, prep notes, and company-specific framing added by our team. For round-by-round stories, see the Bloomberg interview experience page. For OA papers and coding drills, use Bloomberg on placementpapers.app. Screening quick answers and role-wise questions draw on GeeksforGeeks Bloomberg reports (SWE fresher, Pune 2022; SDE intern, off-campus; Software Engineer Intern off-campus 2023), the August 2022 Pune SWE post on LeetCode Discuss and 2025 Pune Glassdoor reports seen via search snippets, and the PICT and 2024 Pune campus accounts summarised on the interview experience page.