Broadridge Software Engineer Interview Guide

The 60-second brief

Broadridge builds technology for financial services, and the Software Engineer role develops and maintains the applications behind those services. Candidate descriptions of the work mention data processing, financial transactions and regulatory compliance, with day-to-day duties that include designing and implementing solutions, working with cross-functional teams, reviewing peers' code and resolving defects and performance problems.

This guide is for candidates interviewing for a Software Engineer position at Broadridge. It covers the three reported stages (Initial Screening, Technical Interviews, HR Interview), preparation for the reported Java, SQL, debugging, data and system design questions, and a set of behavioral stories to rehearse. The technical questions are written up in the question list; this page tells you how to organise your preparation around them.

Candidates report three stages over roughly 3-5 weeks: an Initial Screening, a set of Technical Interviews that include coding assessments and system design discussions, and a closing HR Interview about fit.

Focus areas

• Java (core)
• DSA (Data Structures & Algorithms)
• Docker

Overview

The reported question set is weighted toward fundamentals. Java comes up as core language knowledge (abstract class versus interface, garbage collection, multithreading, object-oriented principles), and the topic breakdown candidates describe also lists data structures and algorithms, Big-O analysis, Docker and Kubernetes. SQL appears twice, once as query performance and once as schema design. That mix rewards depth on a small number of topics: being able to explain why something works, not only name it.

The design questions are anchored in money and data. One asks about handling real-time financial transactions, another about a database schema for a financial application, and a third about the factors in designing a RESTful API. The shared concerns are correctness under retries and failure: unique request identity, never losing or double-applying a transfer, exact decimal arithmetic and an audit trail. Prepare these as one connected story rather than three separate answers.

The problem-solving questions are open-ended: debugging software that is not working as expected, finding anomalies in a dataset, and describing a complex problem you solved. Each is answered with a method, so practise saying your sequence out loud: reproduce, narrow, test a hypothesis, confirm the fix. Candidates also report behavioral questions on difficult colleagues, tight deadlines and juggling several projects. Have four written-out stories ready before the first stage, because the same story often fits more than one prompt.

Requirements candidates describe list Java and SQL, data structures and algorithms, software design principles, and database experience, with cloud and DevOps familiarity as a plus. If your Java is rusty, spend the first days on the language runtime and concurrency; if your SQL is mostly ORM-generated, spend time reading execution plans by hand.

The Broadridge interview process

Candidates describe three stages and a total of about 3-5 weeks; team and location can change the details, so confirm the exact schedule with your recruiter.

Initial Screening

Candidates report an Initial Screening as the first stage, used to check your qualifications against the role. Nothing more specific about its format has been reported, so treat it as a conversation about your background and be ready for a short technical question in case one appears. Your goal is a crisp, factual account of what you have built and why this role fits.

What to demonstrate

• How well your experience matches the Java, SQL and database requirements candidates describe for the role
• How clearly you summarise your own past projects and your part in them
• Practical fit: location, availability and the logistics of the later stages

How to prepare

• Write a two-minute walk through your CV that names the languages, databases and deployment tooling you used on each project
• Pick one project where you used Java or SQL in depth and be ready to give its data volume, your design choices and one thing you would change
• Prepare a short, honest reason you want a financial-technology role, tied to something you have actually built
• Ask the recruiter for the structure and format of the technical stage, including whether coding is live or a timed assessment

Technical Interviews

Candidates report several technical interviews, with coding assessments and system design discussions among them. The reported question set in this guide covers the content such a stage would draw on: Java language and runtime topics, SQL tuning, debugging, anomaly detection in data, and designs for transactions, schemas and REST APIs. Approach it by splitting preparation into three tracks, language and runtime fundamentals, hands-on coding with complexity analysis, and design.

What to demonstrate

• Working code and the ability to state its time and space complexity, since coding assessments are part of the reported format
• Command of Java core topics and SQL as listed in the requirements candidates describe
• The ability to structure a design discussion around financial correctness, data modelling and API contracts

How to prepare

• Practise coding solutions in Java under a clock, and state Big-O for every solution before you are asked
• Rehearse spoken explanations of abstract class versus interface, how garbage collection reclaims memory, and how threads share state, each with a short code example
• Take one slow query, read its EXPLAIN output and write down three different ways to speed it up and what each costs
• Design the real-time transaction system end to end on paper, redo it with a different failure (duplicate request, database down), and sketch how you would run the service with Docker and Kubernetes

HR Interview

Candidates report the final stage as an HR Interview focused on fit and alignment with company values; the values named in candidate descriptions are teamwork, integrity and innovation. Reported behavioral questions (a difficult team member, a tight deadline, prioritising several projects) are not tied to a single stage, so keep your stories ready for any round. Approach this stage with specific stories and a clear view of what you want from the role.

What to demonstrate

• Whether your account of past teamwork is specific and credible
• How you talk about conflict, deadlines and competing priorities
• Alignment between what you want from the job and what the role involves

How to prepare

• Write four stories in situation, action, result form: a complex problem, a difficult collaborator, a tight deadline, and a time you juggled several projects
• For each story, add one number or observable outcome and one thing you would do differently
• Prepare two or three questions about the team, its code review habits and how work is shared among engineers
• Practise telling each story in under two minutes using 'I' for your own decisions and 'the team' only for shared work

Where candidates lose points

Defining Java concepts from memory without an example, for instance reciting that an interface has no state but never showing when you would choose it over an abstract class

For abstract class versus interface, garbage collection and multithreading, prepare a definition, a code example and one trade-off or failure case (shared mutable state without synchronisation, a reference that keeps an object alive). Say it aloud before the loop.

Answering the SQL performance question with 'add an index' and nothing else

Start from the execution plan. Explain scans versus index lookups, composite index column order, predicates that cannot use an index (functions on indexed columns), selecting only needed columns, join order and when to rewrite a subquery. Mention the cost of indexes on write-heavy tables.

Treating the real-time financial transaction design as a generic scalable web service and skipping correctness

Cover idempotent requests with a unique key, atomic debit and credit, an append-only ledger or audit trail, exact decimal or integer-minor-unit amounts, and what happens on a retry or downstream outage. Add scale (partitioning, queues) only after these are covered.

Jumping to a fix when asked how to debug misbehaving software, or listing tools instead of a sequence

Say the order: reproduce and get a failing case, check what changed recently, read logs and metrics, bisect to isolate the component, form one hypothesis at a time, then confirm the fix with a test. Use the anomaly question the same way: define normal, then choose a method.

Giving behavioral answers where 'we' hides your own decision, or where the difficult colleague is the villain

Write each story with your own actions as the spine, include a trade-off or a mistake, and report an outcome you can measure. For the difficult-colleague story, show what you changed in your approach, not only what they did wrong.

Questions & practice

Can you explain how garbage collection works in Java?

Medium · Technical Questions

Approach

1. Explain reachability. The collector traces from GC roots (local variables on thread stacks, static fields, JNI references) and reclaims any object that cannot be reached. It is not reference counting, so unreachable cycles are collected too.
2. Describe the generational layout. New objects go into Eden. A minor GC copies the live ones into a survivor space, and objects that survive enough cycles are promoted to the old generation. This works because most objects die young. Old-generation collection marks live objects, then sweeps and compacts.
3. Name the collectors and their trade-offs. Serial suits small heaps, Parallel maximises throughput, and G1 (the default since JDK 9) is region-based with a pause-time goal set by -XX:MaxGCPauseMillis. ZGC and Shenandoah do most of their work concurrently for very short pauses. CMS was removed in JDK 14.
4. Cover what GC does not solve. Objects held by static collections, unbounded caches, unremoved listeners or ThreadLocals stay reachable and leak. File handles and sockets still need try-with-resources, and finalize() is deprecated.
5. Close with diagnosis. Enable GC logging with -Xlog:gc*, take a heap dump with jcmd or jmap, and look for the dominating retainers in a heap analyser. Also tell 'Java heap space' apart from 'Metaspace' OutOfMemoryErrors.

Follow-up

• A service's heap climbs slowly until it crashes after a few days. How do you find the leak?
• What is the difference between a minor GC and a full GC, and what can trigger a full GC?
• Does calling System.gc() guarantee a collection?

Explain the concept of multithreading and how it works in Java.

Medium · Technical Questions

Approach

1. Define the model. Threads in one JVM share the heap but each has its own stack. In practice you create Runnable or Callable tasks and submit them to an ExecutorService thread pool rather than managing raw Thread objects. Since Java 21, virtual threads make blocking I/O-heavy code cheap to run concurrently.
2. Explain the hazards with an example. count++ is a read-modify-write, so two threads can both read 5 and both write 6. Visibility is the second problem: without a happens-before edge (synchronized, volatile, Thread.start/join), one thread may never see another's write.
3. Match the tool to the problem. Use synchronized or ReentrantLock for compound critical sections, volatile for a visibility-only flag (it does not make count++ atomic), AtomicInteger or LongAdder for counters, and ConcurrentHashMap for shared maps. Use BlockingQueue for producer-consumer and CountDownLatch or CompletableFuture for coordination.
4. Cover deadlock. It needs mutual exclusion, hold-and-wait, no preemption and circular wait. Prevent it with a global lock ordering (for example, always lock the lower account id first in a transfer) or tryLock with a timeout. Diagnose it with a thread dump from jstack or jcmd Thread.print, which reports Java-level deadlocks.
5. Size pools deliberately. For CPU-bound work, a pool about the size of the core count. For I/O-bound work, more threads. Use a bounded queue with a rejection policy so a traffic spike cannot exhaust memory.

Follow-up

• What exactly does volatile guarantee, and why is it not enough for a counter?
• How would you find and fix a deadlock in a running production service?
• What is the difference between Runnable and Callable, and how do you get a result or exception back from a pool?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

How do you optimize an SQL query for better performance?

Medium · Technical Questions

Approach

1. Measure before changing anything. Run EXPLAIN (EXPLAIN ANALYZE in PostgreSQL) and read the plan for full scans on large tables, row estimates far from actual counts, nested loops over big inputs, and sorts or hashes spilling to disk.
2. Fix access paths with indexes on the WHERE, JOIN and ORDER BY columns. In a composite index, put equality columns before range columns, because the index serves its leftmost prefix. A covering index (INCLUDE columns in PostgreSQL) allows index-only scans.
3. Keep predicates sargable. WHERE YEAR(created_at) = 2024, a leading-wildcard LIKE '%abc' or an implicit type cast on the indexed column blocks a normal index seek. Rewrite as a range such as created_at >= '2024-01-01' AND created_at < '2025-01-01'.
4. Reduce the work the query does: select only the columns you need instead of SELECT *, filter before joining and aggregating, and replace correlated subqueries with joins or EXISTS. Use NOT EXISTS rather than NOT IN when the subquery can return NULL, and use keyset pagination instead of a large OFFSET.
5. State the trade-offs. Every index slows inserts and updates and takes storage, stale statistics mislead the planner until you run ANALYZE, and an N+1 pattern from an ORM is often the real cost rather than any single query.

Follow-up

• An index exists on the filtered column but the plan still shows a sequential scan. What are the possible reasons?
• Can a composite index on (a, b) help a query that filters only on b?
• When would you use a materialized view or denormalise instead of tuning the query?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

What is the difference between an abstract class and an interface in Java?

Medium · Technical Questions

Approach

1. Start with the structural differences. An abstract class can have constructors, instance fields, any access modifier, and both concrete and abstract methods. An interface has no constructors and no instance state, and its fields are implicitly public static final.
2. Cover inheritance. A class extends at most one abstract class but can implement many interfaces, so an interface describes a capability that unrelated types can share (Comparable, Runnable), while an abstract class shares state and code within one family of types.
3. Bring in the Java 8+ changes. Interfaces can have default and static methods since Java 8 and private methods since Java 9, so the 'interfaces have no code' line is out of date. What they still lack is per-instance state and constructors.
4. Give a concrete choice. I would use an abstract class for a template method that needs shared fields (a base ReportGenerator holding a formatter and calling an abstract render step) and an interface for a pluggable contract (a PricingStrategy). Also note that only an interface with a single abstract method can be the target of a lambda.

Follow-up

• A class implements two interfaces that both define the same default method. What happens, and how do you resolve it?
• Why did Java 8 add default methods, and what problem do they solve for library authors?
• How do sealed interfaces in Java 17 change the way you model a closed set of types?

Describe the principles of Object-Oriented Programming (OOP).

Medium · Technical Questions

Approach

1. Name all four principles and give each one a Java example, not just a definition. Encapsulation: private fields behind methods that enforce invariants, such as an Account whose withdraw() refuses to take the balance below its limit, so no caller can set the balance directly.
2. Abstraction: callers depend on what something does, not how. Example: code talks to a PaymentProcessor interface without knowing which implementation is behind it.
3. Inheritance and polymorphism: a subclass reuses and specialises a parent. Runtime polymorphism is method overriding resolved by dynamic dispatch on the object's actual type. Overloading is resolved at compile time from the declared argument types.
4. Show judgement, not just recall. Favour composition over deep inheritance trees, because subclasses break when a base class changes (the fragile base class problem). Mention Liskov substitution, using the classic Square-extends-Rectangle example where setWidth breaks the caller's expectations.
5. If there is time, tie the principles to SOLID (single responsibility, open/closed, Liskov, interface segregation, dependency inversion) as the design rules that come out of them.

Follow-up

• What is the difference between method overloading and overriding, and when is each one resolved?
• Give an example where you replaced inheritance with composition. What did it fix?
• Is Java a purely object-oriented language? Why or why not?

Given a dataset, how would you identify anomalies in the data?

Medium · Problem-Solving Questions

Approach

1. Clarify what 'anomaly' means here: a point outlier (one huge transaction), a contextual one (normal amount at an unusual hour or for that account) or a collective one (a burst of small transfers). Also ask whether labels exist and whether detection must run in real time.
2. Run data-quality checks first: nulls, duplicates, impossible values (negative quantities, future dates), out-of-range codes and broken references. Many 'anomalies' are ingestion bugs.
3. Use univariate statistics with their assumptions stated. A z-score above 3 assumes roughly normal data, and the outliers themselves inflate the mean and standard deviation. Robust alternatives are the IQR rule (below Q1 - 1.5IQR or above Q3 + 1.5IQR) and the modified z-score 0.6745*(x - median)/MAD, flagged above 3.5.
4. Compare against context. Per-entity baselines (each account against its own history, computed in SQL with AVG and STDDEV window functions partitioned by account) and seasonal comparisons for time series (the same hour last week, or a rolling window). For multivariate data, Isolation Forest or Local Outlier Factor, at some cost in explainability.
5. Validate and tune. Review a sample of flags with someone who knows the domain, set the threshold by the cost of false positives versus misses, and track how many flags are confirmed over time.

Follow-up

• Write the SQL that flags transactions more than three standard deviations above each account's own average.
• Without labelled anomalies, how would you choose and defend a threshold?
• How would this change if anomalies had to be flagged as transactions stream in?

Design a system that can handle real-time financial transactions. What considerations would you take into acco

Medium · System Design Questions

Design a system that can handle real-time financial transactions. What considerations would you take into account?

Approach

1. Fix the requirements before drawing boxes: which transaction types, peak throughput, latency target, and the invariants. No double-applied payment and no balance going below its allowed limit. State that correctness and auditability come before availability for the write path.
2. Core write path: an API layer with authentication and rate limiting feeds a transaction service that writes to a relational store in one ACID transaction. Use a client-supplied idempotency key under a unique constraint, so a retry after a timeout returns the original result instead of charging twice.
3. Model money as a double-entry ledger. Every transfer writes a debit and a credit that sum to zero, entries are append-only, and the balance is updated in the same transaction. Serialise concurrent updates to one account with SELECT ... FOR UPDATE or an optimistic version column.
4. Scale and integrate. Partition accounts by account id. A transfer across partitions needs two-phase commit or a saga with compensating entries, and each has trade-offs. Publish events to a durable log through a transactional outbox, so downstream fraud, notification and reporting consumers get at-least-once delivery and must be idempotent.
5. Close with reliability and controls: synchronous replication for committed writes, reconciliation jobs that compare the ledger against external statements, a full audit trail, encryption in transit and at rest, and alerts on latency and failure rate.

Follow-up

• How do you handle a transfer between two accounts that live on different shards?
• The downstream notification service is down for an hour. What happens to transactions in that time?
• How would you detect and repair a ledger that disagrees with an external settlement file?

How would you design a database schema for a financial application?

Medium · System Design Questions

Approach

1. List the core entities and normalise them for transactional use: customers, accounts (with type, currency and status), transactions as headers, ledger_entries as lines (transaction_id, account_id, amount, debit or credit), and a balances table or snapshot.
2. Store money correctly: NUMERIC/DECIMAL with fixed scale, or an integer in minor units, never FLOAT or DOUBLE, which cannot represent 0.10 exactly. Carry an ISO 4217 currency code on every amount, and keep FX rates in their own table with an effective timestamp.
3. Enforce integrity in the database: foreign keys, NOT NULL, CHECK constraints on amount sign and status values, and a unique idempotency key on transactions. Make sure the entries of each transaction sum to zero inside the same database transaction that writes them.
4. Make history immutable and auditable. Never UPDATE or DELETE a posted entry; correct it with a reversing entry. Store timestamps in UTC (timestamptz), keep booking date and value date separately, and keep change history for reference data such as account details.
5. Plan for volume and reads: index (account_id, created_at) for statements, range-partition the ledger by date, and send reporting to a read replica or warehouse so analytics queries do not compete with posting.

Follow-up

• How do you get an account's current balance quickly: sum the entries or maintain a stored balance? What are the risks of each?
• How would the schema handle a reversed or disputed transaction?
• How would you migrate this schema to add a new column to a very large ledger table without downtime?

Discuss the factors to consider when designing a RESTful API.

Medium · System Design Questions

Approach

1. Model resources as nouns with stable, hierarchical URIs (/accounts/{id}/transactions) and use methods for their meaning. GET is safe and idempotent, PUT and DELETE are idempotent, POST is not, and PATCH is a partial update that is not guaranteed to be idempotent.
2. Use status codes precisely: 201 with a Location header on create, 204 for no body, 400 for malformed input, 401 (not authenticated) versus 403 (not allowed), 404, 409 for state conflicts, 422 for validation, and 429 for rate limits. Return one consistent error body, for example RFC 9457 problem details, which replaced RFC 7807.
3. Make retries safe. Accept an Idempotency-Key header on POSTs that move money or create records, and support conditional updates with ETag and If-Match (412 Precondition Failed on a stale version) for optimistic concurrency.
4. Design for large and changing data: cursor-based pagination rather than deep offsets, explicit filtering and sorting parameters, and a versioning scheme (/v1 path or a header). Treat additive fields as non-breaking, and give clients a deprecation window before removing or renaming anything.
5. Cover security and operations: HTTPS only, OAuth 2.0 bearer tokens with per-resource authorisation checks, input validation, rate limiting, Cache-Control on cacheable GETs, and request ids in responses for tracing.

Follow-up

• How would you introduce a breaking change without breaking existing clients?
• An operation takes minutes to complete. How do you expose it over REST?
• When would you choose PUT over PATCH for an update, and what does each require of the client?

How would you approach debugging a piece of software that is not functioning as expected?

Medium · Problem-Solving Questions

Approach

1. Pin down the symptom: expected versus actual behaviour, the exact input, environment and version, and whether it happens every time. Then reduce it to the smallest reproduction you can run repeatedly.
2. Ask what changed: recent deploys, config, dependency upgrades, data shape. For a regression with a known good version, git bisect finds the offending commit in about log2(n) steps.
3. Read the evidence before theorising: the full stack trace (including the root 'Caused by'), logs around the failure with a request or correlation id, and metrics showing when it started. Then test one hypothesis at a time with a breakpoint or a targeted log line, narrowing the code path by halves.
4. Fix the root cause, not the symptom. First write a test that fails because of the bug, then make it pass, and confirm the fix in the environment where the bug appeared.
5. For intermittent failures, suspect timing, shared state, resource exhaustion or environment differences. Adding a debugger can change the timing and hide the bug, so lean on logs, thread dumps and stress runs instead.

Follow-up

• The bug only happens in production and you cannot attach a debugger. What do you do?
• A test fails once in every fifty runs. How do you find out why?
• How do you show that your fix addressed the cause and did not just hide the symptom?

Suggested practice checklist

The plan follows the reported rounds and question set: Java fundamentals first, then SQL and schema design, algorithms, design and debugging, and behavioral stories last. Each day ends with something you can say aloud or hand to a friend to check.

Day 1 — Java object model: classes, interfaces and OOP

• Write a short Java example showing an abstract class with shared state and an interface with a default method, and note when you would pick each
• Explain the main object-oriented principles (encapsulation, inheritance, polymorphism, abstraction) using one small domain, for example payment types
• Prepare a spoken answer for each of the two questions that includes one code example and one trade-off

Deliverable: Two spoken answers (abstract class versus interface, OOP principles) each backed by a working Java example you wrote.

Day 2 — JVM memory and concurrency

• Write out how garbage collection works: reachability from roots, generational heap, minor versus major collection, and why a stray reference causes a leak
• Write a small multithreaded program with a shared counter, show the race, then fix it with synchronized, an atomic class and an ExecutorService
• Prepare short answers on volatile, deadlock and thread pools

Deliverable: A runnable race-condition demo with two fixes, plus a one-page garbage collection explanation.

Day 3 — SQL performance and schema design

• Take a slow query on a table you create locally, read its EXPLAIN output, and apply at least three changes, recording the plan before and after
• Design a schema for accounts, transfers and ledger entries, choosing key types, amounts type, constraints and indexes
• Solve the soft-deleted accounts practice problem and compare its unique-constraint approach to your schema

Deliverable: A before-and-after execution plan write-up and an annotated schema for a financial application.

Day 4 — Data structures, algorithms and Big-O

• Solve three array or hash-map problems in Java, stating time and space complexity before coding
• Work the heaviest-tenants practice problem and explain which structure (hash map, heap or counting) you picked and why
• Review the common structures and their costs: array, linked list, hash map, heap, tree

Deliverable: Three solutions in Java with complexity written beside each, plus a one-page table of structure costs.

Day 5 — System design: transactions, APIs and containers

• Design the real-time financial transaction system: write path, idempotency key, ledger, queueing and failure handling
• List the factors in designing a RESTful API: resource naming, verbs, status codes, pagination, versioning, error format and safe retries
• Sketch how you would package a Java service in a Docker image and run it on Kubernetes, covering configuration, health checks and scaling

Deliverable: A design diagram with a failure walk-through, a one-page API checklist and a short container deployment sketch.

Day 6 — Debugging and finding anomalies in data

• Write your debugging sequence on one page, then apply it aloud to a bug you actually fixed
• Pick a dataset and flag anomalies three ways: summary statistics with a threshold, a distribution-based method such as z-score or interquartile range, and a business-rule check
• Write what you would do with a flagged record and how you would check for false positives

Deliverable: A debugging checklist you can recite, and a short script or query that flags anomalies in a sample dataset.

Day 7 — Behavioral stories and mock loop

• Write four stories in situation, action, result form for the complex problem, difficult team member, tight deadline and prioritisation questions
• Tell each story aloud and cut it to the version that keeps your decisions and a measurable result
• Run a full mock: a two-minute CV walk-through, one Java question, one design question, and one behavioral story

Deliverable: Four finished stories, each with one metric and one lesson, plus a recorded or witnessed mock run.

Behavioural preparation

The reported behavioral questions ask about a complex project problem, a difficult colleague, a tight deadline and managing several projects. For a software engineer working on financial systems they come down to how you reason about trade-offs, how you work with other people when things are tense and how you communicate risk. Prepare stories that show your own decisions and results.

1. Tell me about feedback you received on your code and what you changed afterwards.

Discuss a time when you had to solve a complex problem in a project.

Medium · Problem-Solving Questions

Approach

1. Choose a problem where the cause or solution was not obvious at the start, such as a production defect, a performance regression or a data inconsistency. Avoid stories that were hard only because of effort or hours.
2. Spend the first part on how you narrowed it down: what you measured, which hypotheses you ruled out and how. A short sequence (reproduce, isolate, test, confirm) shows method better than listing tools.
3. State the options you considered and why you chose one, including what it cost. A visible trade-off (speed versus risk, quick patch versus proper fix) is more convincing than a flawless story.
4. Close with the result in observable terms (error rate, latency, fewer manual corrections) and what you did to stop it recurring, such as a test, an alert or a runbook. The mistake that sinks this story is using 'we' throughout so that your own decision never appears.

Follow-up

• What alternatives did you reject, and what made you sure?
• How did you confirm that your change, and not something else, fixed it?
• What would you do differently if the same problem came up again?

Describe a situation where you had to collaborate with a difficult team member. How did you handle it?

Medium · Behavioral Questions

Approach

1. Describe the friction in neutral, factual terms (missed handoffs, dismissive code review comments, changing requirements) rather than judging the person's character. A conflict story is not a complaint.
2. Show what you did first: a private conversation, finding out what constraint or pressure they were under, and agreeing on something concrete such as review turnaround, a shared definition of done or a written interface.
3. If the situation did not fully resolve, say so. Describe when you involved a manager and how you presented facts, not opinions. Escalating without trying a direct conversation first is a weak pattern.
4. End with the outcome for the work and the relationship, and one thing you learned about your own style. The mistake that sinks this story is one where you were right and they were wrong, with no change in your own behavior.

Follow-up

• What would you have done if they had not changed their behavior?
• At what point do you bring in a manager, and how do you present it?
• What did you learn about how you handle disagreement?

Can you provide an example of a time when you had to meet a tight deadline?

Medium · Behavioral Questions

Approach

1. Pick a deadline with a real consequence (a release date, a client commitment, a regulatory cut-off) and name it in the first sentence so the stakes are clear.
2. Show the scoping decision: what you cut or deferred, what you kept, and how you chose. Strong answers describe cutting scope with agreement from stakeholders, not working longer hours alone.
3. Show how you communicated the risk early, to whom, and what you offered (a reduced first release, a follow-up date). State which quality checks you refused to drop, such as tests on the critical path.
4. Report the outcome and the cleanup: what shipped, what the follow-up work was and when it was done. The mistake that sinks this story is a heroics narrative with no scoping, no communication and no mention of the debt left behind.

Follow-up

• What exactly did you cut, and who agreed to that?
• When did you tell stakeholders about the risk, and what did you say?
• What technical debt did the rush leave, and how was it repaid?

How do you prioritize your tasks when managing multiple projects?

Medium · Behavioral Questions

Approach

1. Open with the method in a sentence or two: list everything, then rank by impact, deadline, cost of delay and dependencies on other people. Then move straight to a real example, since an abstract framework does not stand out.
2. Use a concrete case with at least two competing projects. Say what you put first, what you postponed, and what information changed the order, such as a blocking dependency or an incident.
3. Explain how you communicate priorities: telling stakeholders what is not getting done and negotiating with the person who owns the priority when two requests conflict.
4. Describe how you re-plan when something urgent arrives, for example a production defect, and how you protect time for the planned work. The mistake that sinks this answer is claiming a to-do list or a tool is the method, with no judgement shown.

Follow-up

• Two managers each say their project is the top priority. What do you do?
• How do you handle an urgent production issue that lands in the middle of planned work?
• Describe something you decided not to do and how you told the requester.