Interview experience
BlackRock interview experiences covering Online Assessment (HackerRank), Technical Interview(s), Superday (final round). Round-wise notes, common questions, and what candidates report clears each stage.
Explore: Interview experience · HR interview questions · Overview · Placement papers · Preparation guide
BlackRock’s software engineering hires go through a HackerRank-plus-Superday loop - standard DSA and systems fundamentals, distinct from the firm’s separate and more finance-heavy Quantitative Research interview track.
Interview experience
BlackRock interview experiences covering Online Assessment (HackerRank), Technical Interview(s), Superday (final round). Round-wise notes, common questions, and what candidates report clears each stage.
HR interview questions
BlackRock HR interview questions with sample answer frameworks - motivation, relocation, STAR stories, and culture-fit prompts.
| Round | Duration | What they test |
|---|---|---|
| Online Assessment (HackerRank) | 60-90 min | 2-3 coding problems - DSA, SQL, or OOP |
| Technical Interview(s) | 45-60 min each | Live coding, resume/project deep-dive |
| Superday (final round) | 3-4 back-to-back panels | System design, coding, behavioral fit |
These answers are compiled from public candidate reports and prep guides, not from an official notice, and drives differ. The instruction screen of your own test is the final word.
| Question | Answer |
|---|---|
| How many questions and how long? | India campus drives use a multi-section test of roughly 1.5 to 1.75 hours: aptitude, reasoning, verbal, flowcharts and SQL/DBMS, with some easy-to-medium coding or tree questions. One 2024 VIT report gives the aptitude section as 39 questions in 47 minutes. Off-campus and intern loops more often use HackerRank with 2-3 coding problems. |
| Which platform is it on? | eLitmus for most recent India campus drives (2023-2024 reports from VIT, Manipal and others). HackerRank for many off-campus and internship invites. |
| Does it have negative marking? | No public report confirms either way. Candidate write-ups of the eLitmus-based BlackRock test do not mention a penalty, so read the instruction screen before guessing. |
| Is there a sectional cutoff? | Not published, but every section is separately timed, so treat each one as something you must clear. Within a section you can skip and come back; skipped questions reappear at the end of that section. |
| How much is the cutoff? | Not published; shortlists are relative to the batch. In one 2024 campus drive about 997 students sat the test, 146 were shortlisted for interviews and 50 got offers. Candidate-reported eligibility is often 7.5+ CGPA with no standing arrears. |
| Which section is hardest? | Flowcharts, by most reports: 2-3 large flowcharts with 5-8 decision boxes each, 3-5 questions per chart, and some blank boxes you fill from the options. |
| Is there coding? | Light in the campus test - tree questions such as BST formation and preorder/postorder traversal, plus SQL output questions. HackerRank-based off-campus OAs are mainly coding. |
| Is there a hackathon route? | Sometimes. One 2024 Mumbai campus report describes a 24-hour hackathon whose top team went straight to interviews, while everyone else took the eLitmus test. |
These themes come from candidate reports on Glassdoor and GfG. They show the level and style, not a fixed list.
| Role | Reported questions and topics |
|---|---|
| Software engineer (campus fresher) | Why you chose your project’s tech stack and architecture, relational vs non-relational databases, JWT, cookies and OAuth with an example. Verbal DSA: detect a loop in a linked list and its time complexity, then compare sorting algorithms and explain merge sort vs quick sort and when to use each. |
| Software engineer intern (Gurgaon) | Medium LeetCode-style live coding, theoretical SQL questions, one puzzle, and project questions from your resume. One 2025 intern report: one DSA question, one SQL question and resume questions. |
| Software engineer (off-campus) | Aptitude test with pseudocode, SQL input/output, reasoning and English, then a technical round on SQL queries, problem solving and data structures, then HR. Some 2025 loops run up to three technical rounds, the first opening with a DSA coding question. |
| HR round (all roles) | Introduce yourself in a minute, what you know about BlackRock, why BlackRock, whether you are open to new tech stacks and roles, and your plans for a master’s degree. |
Asked across every role: a resume project walked through in depth, SQL, and why BlackRock. Several candidates note a strong focus on BlackRock’s stated values, with some interviewers saying which value they were screening for.
Many off-campus and intern software loops use HackerRank with 2-3 coding problems (easy-to-medium DSA, occasional SQL/OOP). India campus drives often use eLitmus multi-section tests instead: aptitude, verbal, reasoning, flowcharts, SQL, and short coding or output-prediction blocks - timed section by section with no going back to an earlier section. Treat aptitude and flowcharts as first-class prep; candidate reports show coding-only revision failing shortlists when ~1000 sit the OA and only ~150 reach interviews. Either format is a hard filter before technical panels.
Common questions
One or two 45-60 minute rounds mixing live coding with a detailed walkthrough of your resume projects. Interviewers ask you to explain a feature you’re proud of concisely, then push on the reasoning behind your technical choices.
Common questions
Round-by-round breakdowns are on the BlackRock interview experience page.
BlackRock’s final round for many engineering tracks: 3-4 back-to-back panels in a single sitting, in person or virtual, each run by a different interviewer or pair. It compresses system design, additional coding, and behavioral evaluation into one day.
Common questions
Sample answer frameworks for each of these are on the BlackRock HR interview questions page.
BlackRock recruits for Software Engineer/technology roles and for a separate Quantitative Research track, and the two loops look quite different. Quant Research interviews lean heavily on financial modeling, probability, and analytical case questions, with onsite panels that can run a full day across 4-5 sessions. If you’re applying to a Software Engineer, backend, or platform-engineering role, your process is the DSA-plus-Superday loop described above - don’t over-index on finance prep unless your specific req calls for it.
Prep guides split BlackRock into HireVue or Superday analyst paths versus Aladdin engineering (DSA plus SQL). For India tech hubs, organise prep around these clusters.
Framework: State invariants first (balances, idempotent updates, audit trail), then code. Interviewers probe whether you would ship a clever race or a boring correct ledger.
Framework: Finish coding with tests, then be ready for a JOIN or second-highest salary SQL follow-up. Campus OAs mix both.
Framework: Separate ingest, compute, and serve. Mention ordering, back-pressure, and lagging consumers without inventing Aladdin internals you have not used.
Framework: Map STAR stories to fiduciary client focus, collaboration, performance, ownership, and long-term impact. Superday panels notice recycled vague stories.
Define dp[i][w] as the best value using the first i items with capacity w. For each item you either skip it, keeping dp[i-1][w], or take it if its weight fits, giving value[i] + dp[i-1][w - weight[i]], and you take the maximum of the two. The table is (n+1) by (W+1), so time and space are both O(n times W) - pseudo-polynomial, not polynomial, because W is a numeric value rather than an input length. Space collapses to O(W) by keeping a single row and iterating the capacity loop downward, which is the standard follow-up; iterating upward instead turns it into the unbounded knapsack, where an item may be reused. Being able to state that distinction cleanly is usually what separates a memorised answer from an understood one.
Walk the array keeping two running values: the best sum ending at the current index, and the best sum seen anywhere so far. At each element, the best sum ending here is either the element alone or the element plus the previous running sum, whichever is larger - which is the dynamic-programming recurrence current = max(x, current + x). Update the global maximum after each step. The result is O(n) time and O(1) space, versus O(n squared) for checking every subarray with prefix sums. The edge case interviewers probe is an all-negative array: initialising the answer to zero wrongly returns zero, so initialise both variables to the first element instead. Tracking the start and end indices just means recording where the running sum restarted.
Use Floyd’s tortoise and hare: advance a slow pointer one node at a time and a fast pointer two at a time. If they ever meet, there is a cycle; if the fast pointer reaches null, there is not. To find the entry point, reset one pointer to the head and then advance both one step at a time - they meet exactly at the start of the cycle, because the distance from the head to the cycle entry equals the distance from the meeting point to the entry, modulo the cycle length. Total cost is O(n) time and O(1) space, which is the whole reason to prefer it over the obvious hash-set solution that stores every visited node in O(n) space. The same technique gives the middle node of a list in one pass.
Separate ingestion, processing, and serving. Ingest from exchange feeds into a partitioned log such as Kafka, partitioning by instrument symbol so that all updates for one instrument stay ordered on one partition while different instruments scale out independently. Processing consumers maintain the current book or last-tick state, writing hot state to an in-memory store like Redis for low-latency reads and appending the full history to a time-series or columnar store for analytics and replay. Serving splits by access pattern: a push channel over WebSocket for live subscribers, and a query API backed by the time-series store for historical requests. The details that matter in the discussion are back-pressure when a consumer falls behind, idempotent handling of duplicate messages using sequence numbers, and the choice to keep only the latest value per symbol via log compaction rather than replaying millions of ticks when a client reconnects.
CAP says that when a network partition occurs, a distributed system must choose between consistency - every read sees the latest write - and availability - every request gets a non-error response. It is not a menu of three from which you pick two, because partitions are a fact of networked life rather than a design option; the real choice is what you do during one. A system of record for positions or trades chooses consistency, refusing writes rather than risking divergent balances, which is what a consensus protocol like Raft gives you at the cost of unavailability when a quorum is lost. A dashboard, a recommendation feed, or a cache chooses availability and reconciles afterwards. PACELC is the useful extension: even when there is no partition, you still trade latency against consistency, which is exactly why read replicas serve stale data.
A hash table maps a key’s hash to a bucket index; collisions occur whenever two keys land in the same bucket, which is inevitable once the number of keys approaches the number of buckets. Separate chaining stores colliding entries in a per-bucket list or tree, so lookup is O(1) on average and degrades to O(n) - or O(log n) if the bucket is treeified - when hashing is poor. Open addressing instead probes for the next free slot using linear probing, quadratic probing, or double hashing, which is more cache-friendly but suffers clustering and needs tombstones on deletion. Resizing happens when the load factor crosses a threshold, typically 0.75, doubling the table and rehashing every entry at O(n) cost - but because that happens only after n insertions, the amortised cost per insertion stays O(1).
Single Responsibility says a class should have one reason to change; Open/Closed says you should extend behaviour without editing existing code; Liskov Substitution says a subtype must honour its base type’s contract, so a subclass that throws on a method the base supports is a violation; Interface Segregation says clients should not depend on methods they do not use; and Dependency Inversion says high-level modules should depend on abstractions rather than concrete implementations. In review these appear as concrete smells: a service class that parses input, hits the database, and formats output, a chain of if-else on a type code that should be polymorphism, or a class that constructs its own database client instead of receiving one. The last of those is the one that most directly blocks testing, since you cannot substitute a fake for a dependency the class creates itself.
They are assessing whether you understand the system beyond the part you wrote, and whether you made decisions rather than followed instructions. Structure it as the problem and its constraints, the design you chose, at least one alternative you rejected and why, the measured outcome, and what you would change now. Quantify wherever possible - latency before and after, rows processed, number of users - because a number invites the follow-up questions that let you show depth. Be precise about which parts were yours versus the team’s; overclaiming collapses the moment they ask about an implementation detail. Finally, have a genuine failure or limitation ready, since the most common closing probe is what broke in production and what you learned from it.
Repeatedly replace the number with the sum of squares of its digits until you reach 1 (happy) or enter a cycle without 1 (not happy). Use a hash set or Floyd cycle detection on the iteration sequence. Time is O(log n) per step in digit count; space O(1) with Floyd. This pattern appears in reported BlackRock OAs and phone screens as a warm-up implementation problem.
Classic approaches: subquery with MAX(salary) WHERE salary < (SELECT MAX(salary) FROM emp), or DENSE_RANK() OVER (ORDER BY salary DESC) filtered to rank 2. Campus OAs also test JOIN types across three tables - practise SQL50-style joins and subqueries under time pressure, not only LeetCode arrays.
HashSet: unordered, O(1) average insert/lookup. TreeSet: sorted order via red-black tree, O(log n) operations. LinkedHashSet: insertion order with hash-table speed. Pick based on whether iteration order or sorting matters - a common Java internals follow-up after live DSA on campus panels.
Most recent India campus drives use eLitmus for a multi-section test (aptitude, reasoning, verbal, flowcharts and SQL/DBMS, about 1.5 to 1.75 hours). Off-campus and internship invites more often use HackerRank with 2-3 coding problems.
No public report confirms either way. Candidate write-ups of the eLitmus-based BlackRock test do not mention a penalty, but each section is timed separately, so read the instruction screen before you start guessing.
BlackRock’s software engineering loop typically runs 3-4 stages: 1. An online assessment on HackerRank (2-3 coding problems covering DSA, SQL, or OOP, roughly 60-90 minutes). 2. One or two technical screens (45-60 minutes each) with live coding plus a resume/project deep-dive. 3. A Superday-style final round - 3-4 back-to-back panels in one sitting covering system design, more coding, and behavioral fit. Overall timeline runs 3-6 weeks and is fairly selective.
Expect core DSA (arrays, dynamic programming problems, linked-list manipulation) at easy-to-medium difficulty in HackerRank-style live coding, plus core concepts in distributed systems design for more senior loops. Interviewers also ask you to give a concise explanation of a feature or project you’re proud of, and probe SQL and OOP fundamentals depending on the team.
Software engineering candidates typically go through an online HackerRank assessment, one or two technical interviews, and a final Superday of 3-4 back-to-back panels. Round count and format vary by team and level, and some India campus loops compress the whole process into a day or two after the online test.
Yes. The Software Engineer track is a fairly standard product-company loop: DSA coding, SQL/OOP, and systems-design fundamentals. The Quantitative Research track is heavier on financial modeling, probability, and analytical reasoning, with multi-session onsite panels that can run a full day. This page and the linked prep pages focus on the software/technology track, not quant research or trading roles.
Practice HackerRank-style DSA and dynamic-programming problems at easy-to-medium difficulty, revise SQL and OOP fundamentals, and prepare a clear, concise walkthrough of a project or feature you built end to end. For the Superday, be ready to repeat solid technical and behavioral answers across several back-to-back panels without losing energy.
Superday is BlackRock’s final-round format for many engineering and analyst tracks: 3-4 back-to-back interviews in a single sitting (in person or virtual), mixing system design, live coding, and behavioral questions with different interviewers. Each panel evaluates you independently, so consistency across the day matters as much as any one strong answer.
Not usually for India campus technology roles. Many global analyst paths use a recorded video screen, but India campus technology loops more often open with a coding OA, then technicals and a Superday-style final. Confirm the invite rather than assuming every req includes HireVue.
Aladdin is BlackRock’s widely known portfolio and risk platform. For SWE interviews, treat it as context for building reliable, auditable systems, not as a trivia quiz on proprietary modules you have never touched.
Use this as a default four-week loop before a BlackRock 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 BlackRock often cite ₹18-35 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 BlackRock interview experience page. For OA papers and coding drills, use BlackRock on placementpapers.app. OA quick answers and role-wise questions draw on GfG’s BlackRock SDE interview experience, Glassdoor candidate reviews for BlackRock Gurgaon and Mumbai, and a VIT campus write-up of the eLitmus test.