Broadridge Financial Solutions Software Engineer Interview Guide

The 60-second brief

Candidates' descriptions place Broadridge Financial Solutions in financial-services technology: software for capital markets, wealth management and corporate governance, used by financial institutions. The work they mention includes trade processing, delivery of corporate communications, market-data security and data analytics platforms. A Software Engineer in this role takes part in the full software development life cycle (requirements, design, implementation, testing, deployment), joins code reviews, writes technical documentation, refactors older code and sometimes supports production systems.

This guide is for candidates interviewing for a Software Engineer position at Broadridge Financial Solutions, most likely on a Java or C# team. It covers the two reported rounds, the thirteen reported questions (language fundamentals, SQL and database management, and behavioral prompts), the coding and database scenarios candidates mention, and a seven-day plan that ends with a spoken mock.

Candidates report two rounds over roughly 2-4 weeks: a Recruiter Screen, then Technical Assessments that mix conceptual theory, hands-on coding and behavioral discussion. The number of technical stages is reported to vary by team and seniority.

Focus areas

• Technical interviews
• SQL
• Data Structures

Overview

The responsibilities candidates describe are ordinary full-cycle engineering: turning business requirements into working software, testing and deploying it, reviewing other people's code, keeping documentation current, refactoring older code and occasionally helping with production support. Because the systems handle financial transactions and must meet regulatory standards, the reported questions lean toward correctness: how a HashMap behaves under collisions, how to keep shared state safe across threads, how a database keeps a transfer atomic, and how to find records that are missing from a second table. Prepare to explain why code behaves as it does, not just to produce it.

The stack varies by team. Candidates mention Java with Spring, .NET with C#, and cloud work on AWS or Azure. Java or C#, strong SQL and solid object-oriented design are the requirements they list as essential; cloud platforms, CI/CD pipelines and some financial-domain knowledge are listed as nice to have. Pick the language you know best, and learn the other ecosystem's names for the same ideas: ConcurrentHashMap and ConcurrentDictionary, synchronized and lock, Hibernate and Entity Framework, Java 8 streams and C# LINQ.

The reported question set splits into three groups. Five are language fundamentals (HashMap internals, memory leaks in long-running applications, interface versus abstract class, threading and thread safety, Java 8 versus newer versions for functional programming). Four are SQL and database questions (tuning a slow query, INNER versus LEFT versus CROSS JOIN, stored procedures versus an ORM, transactions and ACID). Four are behavioral. Candidates also quote scenarios such as searching a rotated sorted array in O(log n), process versus thread, combining two tables to find missing records, and database deadlocks. Many roles are reported to include an online assessment or a live coding round, so allow time for hands-on practice as well as for theory.

Order your preparation by how much each area can be rehearsed. Language internals and SQL reward hands-on experiments you can run in an hour: write the hash table, create the race condition, force the deadlock, read the query plan. Behavioral answers need stories written down in advance, including the technology choices behind every project on your resume. Practise saying your reasoning aloud before you state a conclusion, since candidates describe communication as a recurring theme of the loop.

The Broadridge Financial Solutions interview process

Candidates describe two stages, a recruiter conversation followed by a set of technical assessments. Timelines are reported to vary, from quick turnarounds to multi-week gaps.

Recruiter Screen

Candidates report that the process opens with a recruiter screen that checks your qualifications and fit for the role. No technical content is reported for this stage, so treat it as the place to present your background clearly and to find out how the technical stage is organised for your team. The overall process is reported at about 2-4 weeks, and the number of later rounds is said to depend on team and seniority.

What to demonstrate

• How your background lines up with the requirements candidates describe: Java or C#, SQL and object-oriented design
• How clearly and concisely you summarise your experience
• Whether your stack experience matches the team's technology

How to prepare

• Write a short spoken summary of your career that names the languages, databases and delivery practices (CI/CD, cloud) you have actually used.
• Decide which of Java/Spring, .NET/C# or AWS/Azure is your strongest lane and say so plainly.
• Prepare a specific answer to why you want to work at Broadridge Financial Solutions, built from the business areas candidates list rather than general praise.
• Ask the recruiter how many technical stages your team runs and whether an online assessment or live coding is included.

Technical Assessments

Candidates describe a series of technical evaluations that combine conceptual theory, hands-on coding and behavioral discussion. Topic areas they list are data structures (hash tables, linked lists, trees), algorithms (sorting, searching, recursion), how components interact in a distributed system, SQL (GROUP BY, HAVING, subqueries, normalization, indexing) and language internals in Java or C#. Many roles are also said to include an online assessment or a live coding round. Split your preparation into three tracks: explain-it questions, write-it questions and tell-it stories.

What to demonstrate

• Working code with stated time and space complexity, which is what a hands-on coding stage inherently tests
• Understanding of language internals such as HashMap behaviour, memory leaks and thread safety
• SQL fluency across joins, query tuning, transactions and deadlocks
• How clearly you explain your reasoning and describe past decisions

How to prepare

• Rehearse the HashMap, memory leak, interface versus abstract class, threading and Java 8 versus newer versions questions aloud, with one code example each.
• Write the join, missing-records and slow-query answers against a real database and read the execution plan.
• Practise a rotated sorted array search, linked-list and tree problems, and sorting trade-offs with complexity stated before you code.
• Prepare four STAR stories covering a hard decision under deadline, a disagreement, learning an unfamiliar technology and your reasons for choosing this company.

Where candidates lose points

Answering the HashMap question with 'it uses hashing' and nothing about buckets, equals, resizing or what happens when many keys collide

Be able to walk through the path of a put: hashCode, bucket index, equals comparison along the chain, resize when the load factor threshold is passed (defaults of 16 buckets and 0.75 in Java), and the switch from a linked chain to a tree for long chains in Java 8 and later. Write a small chained hash table once so you can explain it from memory.

Saying 'use synchronized' for thread safety without naming what is shared, or confusing a thread with a process

Start from shared mutable state and list the options: immutability, confinement to one thread, atomic classes, concurrent collections and explicit locks. Reproduce a lost-update race, fix it two ways, and add a two-lock deadlock you resolve with consistent lock ordering. Know the process-versus-thread distinction in terms of address space and scheduling.

Describing joins and query tuning only in words, without writing the query or reading an execution plan

Write the INNER, LEFT and CROSS JOIN outputs for small tables, and the missing-records query with LEFT JOIN ... IS NULL and with NOT EXISTS, noting why NOT IN misbehaves with NULLs. For tuning, run EXPLAIN, point to the full scan or poor join, add or change an index, and show the plan change.

Treating transactions and ACID as definitions, with no example of an isolation problem or a deadlock

Use a transfer between two accounts to show atomicity and consistency, then show what dirty reads, non-repeatable reads and lost updates look like at lower isolation levels. Explain how deadlocks occur and how consistent lock ordering and short transactions reduce them.

Giving behavioral answers in 'we' with no personal decision, or being unable to explain technology choices on your own resume projects

Write each story with your own decision, the alternatives you rejected and a measurable result. For every resume project, prepare why you chose the language, framework and database, what went wrong and what you would change.

Questions & practice

Explain the concept of Threading and how you ensure thread safety in your applications.

Medium · Technical Fundamentals

Approach

1. Define the terms. A process has its own address space. Threads in one process share the heap but each has its own stack. Thread-safety problems only come from shared mutable state, so first name which state is shared and which thread owns it.
2. Explain the two failure modes. Atomicity: count++ is a read-modify-write, and check-then-act (if absent, put) can interleave between threads. Visibility: without a happens-before edge, one thread may never see another's write. volatile fixes visibility but does not make count++ atomic.
3. Pick tools from cheapest to most expensive: immutable objects and thread confinement; atomic classes (AtomicLong, or LongAdder under heavy contention); concurrent collections using atomic operations such as ConcurrentHashMap.compute or merge, not get-then-put; synchronized or ReentrantLock for multi-field invariants. In C# the equivalents are lock, Interlocked and ConcurrentDictionary.
4. Use an ExecutorService rather than raw Thread objects, so pool size, queueing and shutdown are under control. Keep critical sections short, and never make I/O calls while holding a lock.
5. Deadlock: it needs mutual exclusion, hold-and-wait, no preemption and circular wait. Prevent it by always taking locks in the same global order, or with tryLock and a timeout. Detect it with a thread dump: jstack reports a Java-level deadlock when it finds one.

Follow-up

• Why is a volatile int counter still wrong when several threads increment it?
• Two threads transfer money between the same two accounts in opposite directions. How do you stop them deadlocking?
• When would you choose ReentrantLock over synchronized?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

How do you optimize a slow-running SQL query?

Medium · SQL and Database Management

Approach

1. Measure before changing anything. Get the actual plan, not just the estimate: EXPLAIN ANALYZE in PostgreSQL (MySQL 8.0.18+ has it too), or the actual execution plan in SQL Server. Also confirm the query is slow because of its plan and not because it waits on locks held by another session.
2. Read the plan for the expensive node. Look for full scans of large tables, nested loops over large inputs, sorts or hashes spilling to disk, and estimated row counts far from actual ones. A large estimate gap usually means stale statistics, fixed with ANALYZE or UPDATE STATISTICS.
3. Fix sargability before adding indexes. A function on the column (WHERE YEAR(trade_date) = 2025) should become a range on trade_date. Implicit type conversions and LIKE '%term' with a leading wildcard also block index seeks.
4. Design the index for the query. Equality columns go first in a composite index, then the range or ORDER BY column. A covering index (INCLUDE columns in SQL Server and PostgreSQL 11+) avoids lookups back into the table. Every index slows inserts and updates and uses storage, so name that cost on write-heavy tables.
5. Rewrite the query shape where it helps: select only the columns needed, and replace correlated subqueries with a join or EXISTS. For deep pages, use keyset pagination (WHERE id > last_id) instead of a large OFFSET. Then re-run the plan and compare the actual numbers.

Follow-up

• An index exists on the filtered column, but the plan still scans the table. What are the possible reasons?
• What column order would you use for an index serving WHERE account_id = ? AND trade_date > ? ORDER BY trade_date?
• The query is fast in testing and slow in production with the same SQL. What do you check?

Explain the difference between INNER JOIN, LEFT JOIN, and CROSS JOIN.

Medium · SQL and Database Management

Approach

1. INNER JOIN returns only the row pairs where the ON predicate is true. Rows with no match on either side disappear. If the join is one-to-many, each left row repeats once per match, so check the cardinality before you SUM or COUNT afterwards.
2. LEFT JOIN keeps every row from the left table and fills the right table's columns with NULL when nothing matches. Watch the classic trap: a condition on a right-table column in WHERE (WHERE o.status = 'OPEN') removes those NULL rows and turns it into an inner join. Put that condition in the ON clause instead.
3. Finding missing records is an anti-join: LEFT JOIN b ON a.id = b.a_id WHERE b.a_id IS NULL, or NOT EXISTS. Avoid NOT IN (subquery) when the subquery can return NULL: the predicate is never true for any row, so the query returns nothing.
4. CROSS JOIN has no join condition and returns the Cartesian product, m x n rows. It is useful on purpose, for example every account crossed with every calendar date, then a LEFT JOIN to the facts to show days with no activity. By accident, it is how a forgotten join condition multiplies the row count.
5. For completeness, FULL OUTER JOIN keeps unmatched rows from both sides, which helps when reconciling two sources that should hold the same records.

Follow-up

• Write a query that lists the customers who have no orders in the last 30 days.
• Why does adding WHERE right_table.col = 'X' after a LEFT JOIN change the row count?
• How would you reconcile two tables that should hold the same trades, and show the rows missing from each side?

Explain the internal working of a HashMap and how it handles collisions.

Medium · Technical Fundamentals

Approach

1. Describe the layout: a Node<K,V>[] table whose length is a power of two. The key's hashCode is spread with h ^ (h >>> 16), and the bucket index is (n - 1) & hash. That bitmask only works because n is a power of two, and it lets the high bits influence small tables.
2. Collisions are handled by chaining: each bucket holds a linked list of nodes. On get or put, the map walks the chain and compares hash first, then equals(). This is why equal objects must return equal hashCodes, and why a key mutated after insertion becomes unreachable.
3. Java 8 treeification: when a chain reaches 8 nodes (TREEIFY_THRESHOLD) and the table has at least 64 buckets, the bucket becomes a red-black tree, so a bad bucket costs O(log n) instead of O(n). A smaller table resizes instead. A tree bucket that shrinks to 6 or fewer nodes goes back to a list.
4. Resizing: the default capacity is 16 and the load factor 0.75. When size passes capacity x 0.75, the table doubles. Each node either stays at index i or moves to i + oldCap, depending on the bit (hash & oldCap), so no full rehash is needed. Average get and put are O(1). Each resize is O(n), but the cost is amortised.
5. Edge cases: one null key is allowed and goes to bucket 0, and null values are allowed. HashMap is not thread-safe: concurrent puts can lose entries, and in Java 7 a concurrent resize could create a cycle in a chain. Use ConcurrentHashMap when threads share the map.

Follow-up

• What happens if you change a field used in hashCode() after the object is already stored as a key?
• How does ConcurrentHashMap make updates safe without locking the whole table, and why does it reject null keys and values?
• How would you build an LRU cache on top of LinkedHashMap?

Describe the difference between an interface and an abstract class in the context of OOP.

Medium · Technical Fundamentals

Approach

1. Start with the structural rules in Java. A class extends one class but can implement many interfaces. An abstract class can have constructors, instance fields with state, and members of any visibility. Interface fields are implicitly public static final, and an interface has no constructors.
2. Cover how interfaces have changed. Java 8 added default and static methods, and Java 9 added private methods, so interfaces can share behaviour but still cannot hold per-instance state. C# 8 added default interface implementations too.
3. Give the deciding rule with an example. Use an interface for a capability that unrelated types share (Comparable, or a PaymentGateway contract with several vendor implementations). Use an abstract class when closely related types share state and a fixed algorithm, for example a template method in a base report generator whose subclasses fill in formatting steps.
4. Mention the trade-offs. Adding an abstract method to an interface breaks every implementor unless you give it a default. A deep abstract-class hierarchy couples subclasses to base-class internals, so composition plus an interface is often easier to test and mock.
5. Edge case: if a class implements two interfaces that each supply a default method with the same signature, it does not compile until the class overrides the method. Inside the override it can call A.super.method() to pick one.

Follow-up

• Can an abstract class have no abstract methods, and why would you write one?
• Two interfaces define the same default method. What does the compiler require, and how do you call one of them?
• Would you replace this abstract base class with composition? What would change in the tests?

What are the key differences between Java 8 and newer versions regarding functional programming?

Medium · Technical Fundamentals

Approach

1. Anchor on what Java 8 introduced: lambdas, functional interfaces (Function, Predicate, Supplier, Consumer), method references, the Stream API, Optional, default methods, and CompletableFuture for composing async work.
2. Java 9 to 11 added: Stream.takeWhile, dropWhile, ofNullable and a three-argument iterate (9); Optional.ifPresentOrElse, or and stream (9); immutable factories List.of, Set.of and Map.of (9); var and Collectors.toUnmodifiableList (10); Predicate.not, Optional.isEmpty and var in lambda parameters (11).
3. Java 12 to 17 added: Collectors.teeing (12); switch expressions (14); records, Stream.toList() and mapMulti (16); sealed classes (17). Records and sealed types support modelling data as immutable algebraic types.
4. Java 21 finalised pattern matching for switch and record patterns. Together with sealed interfaces, a switch can destructure records and the compiler checks the cases are exhaustive, which is a more functional style than visitor classes.
5. Edge cases worth naming: Stream.toList() returns an unmodifiable list, while collect(Collectors.toList()) guarantees nothing about mutability. Collectors.toUnmodifiableList throws on null elements; Stream.toList allows them. Also mention the parallel stream pitfalls: they share the common ForkJoinPool, and stateful lambdas are a bug.

Follow-up

• When would you write a plain loop instead of a stream?
• How would you handle a checked exception thrown inside a lambda passed to map()?
• Would you use Optional as a field or method parameter? Why or why not?

When would you use a Stored Procedure versus an ORM like Hibernate or Entity Framework?

Medium · SQL and Database Management

Approach

1. Frame it as a choice of where the logic lives. Stored procedures keep set-based logic next to the data. ORMs such as Hibernate and Entity Framework map rows to objects and handle change tracking and the unit of work in the application.
2. Stored procedures fit heavy set-based work: bulk updates, batch jobs and reporting over many rows, where a single call avoids pulling rows over the network. They also allow security set-ups where the application account can EXECUTE procedures but cannot touch the tables. The costs: logic split across two codebases, harder unit testing, vendor-specific SQL, and schema deployments tied to application releases.
3. ORMs fit CRUD-heavy domain code: they give productivity, refactoring support and some database portability. Name their failure modes: N+1 queries from lazy loading (fix with JOIN FETCH or entity graphs in Hibernate, Include in EF), LazyInitializationException outside the session, and bulk updates that load every entity into memory.
4. Give the usual answer: ORM for transactional CRUD; native SQL or stored procedures for reporting, bulk and performance-critical paths. Hibernate calls procedures through StoredProcedureQuery; EF Core uses FromSql for queries and ExecuteSql for commands. Version the procedures with migration tooling such as Flyway, Liquibase or EF migrations.
5. Security edge case: both approaches block SQL injection only when values are passed as parameters. A procedure that concatenates input into dynamic SQL is still injectable, and so is an ORM native query built with string concatenation.

Follow-up

• How would you spot an N+1 problem in a Hibernate or EF application, and fix it?
• How do you test and version stored procedures alongside application code?
• A nightly job updates a million rows through the ORM and is slow. What would you change?

Describe your approach to handling database transactions and ACID properties.

Medium · SQL and Database Management

Approach

1. Define each property by its mechanism. Atomicity: all of the transaction's writes happen or none do (undo and the write-ahead log). Consistency: constraints and invariants hold after commit. Isolation: concurrent transactions do not see each other's partial work. Durability: once committed, data survives a crash because the log is flushed before commit returns.
2. Isolation levels and the anomalies each allows. Read Uncommitted permits dirty reads. Read Committed prevents those but permits non-repeatable reads. Repeatable Read prevents non-repeatable reads (phantoms depend on the engine). Serializable prevents all of them. Defaults: Read Committed in PostgreSQL and SQL Server, Repeatable Read in MySQL InnoDB. Snapshot isolation can still allow write skew.
3. Work through a transfer example. Debit and credit run in one transaction. Prevent lost updates with SELECT ... FOR UPDATE (pessimistic) or a version column checked on UPDATE (optimistic, @Version in JPA) with a retry. Lock both accounts in a fixed order, such as ascending id, to avoid deadlocks, and retry when the database picks a deadlock victim.
4. Application-level practice: keep transactions short, and make no remote calls or user waits inside them. In Spring, @Transactional rolls back on unchecked exceptions by default but not on checked ones, and a self-invoked method inside the same class bypasses the proxy, so no transaction starts.
5. Across services there is no single ACID transaction. Use the outbox pattern (write the event in the same local transaction) or a saga with compensating steps, plus idempotency keys so a retried message does not apply twice.

Follow-up

• Two requests update the same account balance at the same time. Which isolation level or locking stops a lost update?
• What happens when the database detects a deadlock, and how should the application respond?
• How would you keep a payment record and a notification event consistent when they live in different systems?

How do you manage memory leaks in long-running applications?

Medium · Technical Fundamentals

Approach

1. First confirm it really is a leak. Under steady load, a leak shows as heap usage after full GC climbing over time. Rising peaks that drop back after collection are normal. Check GC logs or post-GC heap metrics before blaming the code, because an undersized heap gives similar symptoms.
2. Capture evidence. Take two heap dumps some hours apart with jcmd <pid> GC.heap_dump, and enable -XX:+HeapDumpOnOutOfMemoryError so a crash leaves one behind. In .NET, use dotnet-gcdump or dotnet-dump. Compare which object types grew between the dumps.
3. Analyse the retained size, not object counts. In Eclipse MAT, use the dominator tree and follow the path to GC roots to see which static field, cache, thread or listener is keeping the objects alive.
4. Name the usual causes and their fixes. Unbounded static maps or caches need a size or TTL bound (Caffeine, or LinkedHashMap.removeEldestEntry). Listeners and event handlers that are never unsubscribed must be removed. ThreadLocals on pooled threads need remove() in a finally block. Unclosed connections and streams belong in try-with-resources (using in C#). A key with a broken equals/hashCode keeps adding duplicate entries.
5. Prevention: alert on the post-GC heap trend, run soak tests at production-like load before release, and check native or off-heap growth with -XX:NativeMemoryTracking=summary plus jcmd VM.native_memory when the heap looks flat but the process RSS keeps growing.

Follow-up

• Heap after GC is flat, but the container keeps getting OOM-killed. Where do you look next?
• When is a WeakHashMap the right fix for a cache leak, and when does it fail to help?
• How would you find the leak in production without a heap dump that pauses the service for a long time?

Suggested practice checklist

Each day targets one cluster of the reported topics: the loop and your resume, language internals, OOP and Java versions, coding, SQL, database design and transactions, then behavioral stories with a spoken mock. Every day ends with something you can check.

Day 1 — Map the loop and write your pitch

• Write the two reported stages, Recruiter Screen and Technical Assessments, on one page, and list the topic areas candidates mention under the second.
• Write a spoken summary of your background that names the Java or C# stack, SQL work and any AWS/Azure or CI/CD experience you have.
• List each resume project with the technology choices you made, one problem you hit and what you would change.
• Write your answer to why you want to work at Broadridge Financial Solutions, using the business areas candidates list for the role.

Deliverable: A one-page loop map, a written career summary, a table of resume projects with choices and problems, and a written why-this-company answer.

Day 2 — Language internals: HashMap, memory leaks, threads

• Draw the HashMap structure and write a small chained hash table with put, get and resize to confirm your explanation of collisions.
• List the usual causes of leaks in long-running applications (static collections, unclosed resources, listeners, ThreadLocal values, caches without eviction) and write the diagnosis order: watch heap growth, take a heap dump, find what holds the objects.
• Reproduce a lost-update race on a shared counter, fix it with synchronization, an atomic class and a concurrent collection, then create and fix a two-lock deadlock.

Deliverable: A working hash table, a leak checklist with a diagnosis sequence, and a race and a deadlock program, each with its fix.

Day 3 — OOP design and functional features in Java

• Build a comparison of interface and abstract class: state, constructors, multiple inheritance, default methods since Java 8, and the equivalent in C#.
• List what Java 8 introduced for functional style (lambdas, streams, Optional) and what later versions added, such as var, switch expressions, records, sealed classes and Stream.toList.
• Rewrite a loop-based method as a stream pipeline and a data class as a record, noting where the newer form is clearer.

Deliverable: A written interface versus abstract class comparison, a Java version feature list, and a before and after code sample.

Day 4 — Data structures, algorithms and coding practice

• Implement a search in a rotated sorted array in O(log n) in your interview language and explain the case analysis out loud.
• Write linked-list reversal and tree traversals both recursively and iteratively, and state time and space complexity for each.
• Write a table comparing the sorting algorithms you know on worst case, memory use, stability and nearly-sorted input.

Deliverable: Working solutions with complexity notes for the rotated-array search, list and tree problems, a sorting comparison table, and two solved practice problems.

Day 5 — SQL joins, missing records and query tuning

• Create three small tables and write INNER, LEFT and CROSS JOIN queries, then explain each result set row by row.
• Write the missing-records query two ways, LEFT JOIN with IS NULL and NOT EXISTS, and show how NOT IN breaks when the subquery returns a NULL.
• Practise GROUP BY with HAVING and a subquery on a table of repeated rows.
• Take a slow query on a larger table, read its EXPLAIN output, add an index and show the changed plan.

Deliverable: A script of join and missing-records queries with expected output, plus a before and after execution plan for one tuned query.

Day 6 — Stored procedures, ORMs, transactions and deadlocks

• Write a stored procedure versus Hibernate or Entity Framework comparison covering set-based bulk work, the N+1 query problem, lazy loading, versioning and portability.
• Model a transfer between two accounts in a transaction, then show a lost update and a non-repeatable read at lower isolation levels.
• Open two sessions that lock rows in opposite order to produce a deadlock, then fix it with consistent lock ordering.
• Sketch a normalized schema for orders and customers to third normal form and say which columns you would index.

Deliverable: A decision table for stored procedures versus ORMs, a transaction script with the isolation anomalies, a reproduced and fixed deadlock, and a normalized schema.

Day 7 — Behavioral stories and a spoken mock

• Write STAR outlines for the tight-deadline decision, the disagreement and the new-technology story, each with the alternatives you rejected and a measurable result.
• Say each of the four behavioral answers aloud and cut anything that is not your own decision or reasoning.
• Run a mixed mock: one conceptual question, one coding problem and one SQL question from earlier days, explaining your reasoning before each answer.

Deliverable: Three written STAR outlines, a rehearsed why-this-company answer, and a recorded or noted mock with the weakest answer marked for repair.

Behavioral preparation for the Broadridge loop

Candidates report behavioral discussions inside the Technical Assessments, covering communication, conflict resolution and how you work in a team. For a software engineer working on financial systems, prepare stories that show your own decision, the trade-off you accepted and the result, and be ready to explain technical choices to non-technical stakeholders.

1. Walk me through a project on your resume and explain the technology choices you made.
2. Tell me about a time you explained a technical issue to someone outside engineering.

Describe a time you had to make a difficult technical decision under tight deadlines.

Medium · Behavioral and Leadership

Approach

1. Choose a decision with two genuine options and a real deadline, for example shipping behind a feature flag versus slipping the date, patching a defect versus fixing the underlying design, or adopting a library versus writing the component. Give the situation in two sentences, naming the options.
2. Spend most of the answer on how you decided: which option was reversible, what risk you accepted, what test or production evidence you had in the time available, and who you consulted. For a financial-systems role, name the correctness or reliability constraint that bounded the choice.
3. State the trade-off you accepted knowingly and how you contained it: a rollback plan, extra monitoring, a reduced scope agreed with the product owner, or a ticket to remove the shortcut.
4. Finish with the concrete outcome (what shipped, what held, what you measured) and one thing you would change. A story with no cost is not credible, and a story about working late is not a decision.

Follow-up

• What would you have cut first if the deadline had been halved again?
• How did you tell stakeholders about the shortcut you took?
• Did you ever pay back the technical debt, and how?

Tell me about a time you disagreed with a manager or peer. How did you resolve it?

Medium · Behavioral and Leadership

Approach

1. Pick a technical disagreement with a peer or manager where both positions were reasonable: a design choice, scope, an approach in a code review. State their position fairly in one sentence before stating yours, so it is clear you understood it.
2. Show how you moved the conversation from opinion to evidence: a small benchmark, a prototype, the specification, past incidents, or a comparison of options against the requirement.
3. Say how it ended. Either one of you was persuaded, you found a third option, or you asked a lead to decide and then committed fully to the outcome. If you lost, describe how you carried out the decision properly.
4. Cover the working relationship afterwards. The mistake that sinks this answer is casting the other person as wrong or choosing a trivial disagreement with no stakes.

Follow-up

• What would you have done if the evidence had been inconclusive?
• Have you ever had to implement a decision you disagreed with?
• What did you change afterwards in how you raise disagreements?

How do you approach learning new technologies when faced with a project requirement you haven't encountered be

Medium · Behavioral and Leadership

How do you approach learning new technologies when faced with a project requirement you haven't encountered before?

Approach

1. Start with how you scope the task: what exactly you must be able to do and by when, as opposed to learning the whole technology. This keeps the answer practical and not a list of resources.
2. Give one real instance, for example your first time using an AWS service, Spring's data layer, Entity Framework or an unfamiliar language, and walk through the sequence: the official documentation for core concepts, a small throwaway spike that exercises the riskiest part, reading how the existing codebase already uses it, then a specific question to a teammate after you have tried it yourself.
3. Explain how you verified what you learned: tests that pin the behaviour you relied on, comparing results with what the documentation claims, and a review by someone who knows the technology.
4. Close with what you left behind, such as a short note, an example or a pairing session that helped the next person. A generic answer like reading documents and watching videos, with no project attached, is the common weak version.

Follow-up

• What do you do when the documentation is poor or contradicts what you observe?
• How do you decide when to ask for help instead of continuing alone?
• What is the most recent thing you learned this way, and where did you use it?

Why do you want to work for Broadridge Financial Solutions specifically?

Medium · Behavioral and Leadership

Approach

1. Build the answer in three parts: the business areas candidates list for the role (capital markets, wealth management and corporate governance software), the engineering work described (Java or C#, SQL, the full development cycle including some production support), and your own evidence, such as a project where correctness, auditability or reliability mattered.
2. Before the interview, read the company's public material on the specific business lines and name one thing you actually found. Do not recite a careers page or praise the firm's size or reputation.
3. Make it personal and short, three or four sentences in the first person: what in your background makes this work a natural next step, and what you want to learn in the role.
4. Avoid an answer that would fit any bank or fintech, an answer about brand or pay only, and any claim about the firm that you cannot support.

Follow-up

• Which part of the business do you know most about, and where did you learn it?
• Why a financial technology company instead of a consumer product company?
• What would you want to learn in your first year in this role?