Interview guides · Axos Clearing

Axos Clearing Software Engineer Interview Guide

Axos Clearing Software Engineer interview guide: the four reported rounds, SQL indexing and OOP questions, take-home and Wonderlic prep, and a 7-day plan.

The 60-second brief

Axos Clearing is described to candidates as a firm that provides clearing and custody services for broker-dealers, registered investment advisors (RIAs) and introducing brokerages, within a banking and financial technology setting. Software engineers there are reported to write backend code for transaction processing, design relational database schemas and move transactional data between internal and external systems. Depending on the team, candidates describe work such as migrating legacy systems to newer frameworks, building customer-facing portals for broker-dealers, tuning databases, integrating third-party financial tools and building internal tools that automate manual banking steps.

This guide is for candidates interviewing for a Software Engineer role at Axos Clearing, from entry level up to senior positions, since candidates report the same loop shape across that range. It covers the four reported stages, the behavioral questions candidates describe (motivation, resume depth, self-directed work, vague requirements), the foundational technical topics (SQL indexing, clustered versus non-clustered indexes, object-oriented principles, secure transaction handling, unit testing) and the cognitive test. Reported languages for the role are Java, C# and PHP, with Symfony named for the take-home.

Candidates report four stages over roughly 3-5 weeks: a phone screen, a hiring manager interview, a take-home assignment for certain teams, and a standardized cognitive assessment such as the Wonderlic.

Focus areas

Database Indexing
SQL
Behavioral Interviewing

Overview

The loop candidates describe is short and leans on communication more than on algorithm puzzles. The first two stages are mostly conversation about your background, and candidates say the technical questions are foundational: how an index works, what the principles of OOP are, how you would keep a transaction-handling application secure. That shifts preparation away from grinding hard problems and toward being able to explain familiar material clearly, with mechanics, trade-offs and a concrete example from your own work.

The role itself is database and backend heavy. Reported work includes designing relational schemas, optimizing queries, processing transactional data and debugging production problems on clearing operations. Prepare SQL beyond syntax: be able to explain what a B-tree index does to a lookup, why a clustered index fixes row order while a non-clustered index is a separate structure with pointers back to rows, what an index costs on every write, and when you would leave a column unindexed. Pair that with a rehearsed answer on keeping data correct when concurrent transactions touch the same account or balance.

Candidates also report that detail matters in how you tell your story. Short, high-level answers about your resume draw requests for more, and they report being asked to separate what the team did from what you personally did. Build two or three project stories with context, your exact contribution, the technologies, the root cause of a hard problem and the outcome. The behavioral prompts about working without mentorship and about vague or changing requirements fit the same preparation.

Two stages need their own practice. Where a take-home applies, candidates mention building a basic CRUD web application over a weekend in PHP with Symfony, Java or C#, followed by a live technical review, so rehearse building a small, tested, documented application and explaining every choice in it. The cognitive assessment is a timed test of pattern recognition, word logic and mental arithmetic that candidates say can disqualify even a strong technical performance, so give it deliberate timed practice rather than treating it as a formality.

The Axos Clearing interview process

These are the stages candidates describe, in the order they describe them. The take-home appears only for certain teams, and the hiring manager stage varies by team and seniority.

Phone Screen

Candidates describe a call with a recruiter that covers your background, behavioral questions and a discussion of the benefits package. Candidates also report that the recruiter gauges your interest in the role and checks that your baseline expectations fit what the company offers. Treat it as a structured conversation: have a tight resume walk-through, a specific answer to why this company and the financial sector, and a list of questions about benefits, location and the remaining stages.

What to demonstrate

How clearly you summarize your background and recent work
Whether your motivation for this company and for clearing and banking is specific
Whether your expectations on benefits and location line up with the offer

How to prepare

Write a resume walk-through that gives each role a headline and then goes deeper on one project, and rehearse it aloud until it holds together without notes.
Prepare a reason for applying that names something about clearing, custody or financial systems engineering, as covered in the question on why you want to work at Axos Clearing.
Write down questions on benefits, including how the 401k match vests, and take notes during the call so you can compare them with the offer later.
Ask about the in-office or hybrid expectation for the team, since candidates report an on-site preference in some locations.

Hiring Manager Interview

Candidates describe a meeting with the hiring manager and often a few team members. They report that it varies by team and seniority: some people get an entirely behavioral, experience-focused conversation, others get foundational technical questions or detailed probing of the resume. Prepare for both. Have project stories ready to go several layers deep, and have crisp spoken answers for database indexing, OOP, secure transaction design, unit testing and concurrent transaction integrity.

What to demonstrate

Depth and accuracy when you explain your own past projects, including your personal contribution
Foundational knowledge of relational databases and indexing, and of object-oriented programming
How you work through unclear requirements and tasks with little guidance

How to prepare

For two projects, write the context, your own actions, the technologies, the root cause of the hardest problem and the business result, and mark which parts the team did.
Practice the indexing answers aloud: how an index speeds a lookup, clustered versus non-clustered, the write cost, and a case where you would skip an index.
Prepare a short answer on data integrity under concurrent transactions covering database transactions, isolation, locking and idempotent retries.
Outline your approach to unit tests for money-handling code: rounding, boundaries, failure paths and test data.

Take-Home Assignment

For certain teams, candidates report a take-home over a weekend to build a basic application, followed by a live technical review. Named examples include a basic CRUD application using Symfony and PHP, and candidates mention Java and C# as options. Candidates describe strong submissions as clean and well documented, with the author able to explain the mechanics behind the technology choices. Plan for two deliverables: the working application and your spoken walk-through of it.

What to demonstrate

Working, readable, documented code in a typical web stack
Your handling of relational data and basic transaction safety in a small application
How well you can explain and defend your own technology choices in the live review

How to prepare

Build a small CRUD application in your strongest of Java, C# or PHP with an MVC framework, with a relational schema, validation, a few unit tests and a README, then walk through it aloud.
Decide in advance how you will handle money amounts, input validation, authentication and error responses, so the review has deliberate decisions to discuss.
Be ready to explain every index, foreign key and framework feature in your project, and what you would change with more time.
Rehearse the spoken answers for troubleshooting a critical bug in production and for the unit-testing question, since a review can move from your code to how you work.

Cognitive Assessment

The last stage candidates describe is a standardized cognitive test, such as the Wonderlic assessment, completed regardless of how the technical stages went. Candidates describe it as a timed, 50-question test of pattern recognition, word logic and quick math without a calculator, and warn that missing the benchmark can disqualify an otherwise strong candidate. You cannot study specific answers, so prepare through timed practice and pacing.

What to demonstrate

Processing speed under a strict time limit
Pattern recognition, deductive word logic and reading comprehension
Mental arithmetic with fractions, percentages and basic algebra

How to prepare

Take several full timed practice tests so the pace and question formats are familiar before the real one.
Refresh fractions, percentages, ratios and simple algebra, and practise doing them mentally with no calculator.
Decide a pacing rule: answer the quick items first and move on from a stuck item instead of sinking time into it.
Do the test rested, in a quiet place, and keep it on the calendar next to the technical stages.

Where candidates lose points

Answering the resume walk-through with a list of technologies and no account of what you personally built

Candidates report that short answers draw follow-up requests for more. For each project say the problem, your exact contribution, the technologies, the root cause of the hardest issue and the result.

Describing project work as "we" throughout, so your own contribution cannot be separated from the team's

Candidates report being asked about your exact technical footprint. Mark in your notes which decisions and code were yours, and say "I" for those while crediting the team for the rest.

Explaining indexing as "it makes queries faster" without the structure, the write cost or the clustered versus non-clustered distinction

Explain a B-tree lookup versus a full scan, how a clustered index orders the rows themselves while a non-clustered one holds pointers, the extra work on insert and update, and when you would skip an index on a small or low-selectivity column.

Treating the take-home as a quick working demo with no tests, no README and no thought about concurrent or invalid transactions

Add validation, a few unit tests, a short README and a note on how the code behaves when two requests update the same record, because the live review is a conversation about those choices.

Leaving the cognitive assessment until the night before, or assuming strong technical rounds will cover a weak score

Candidates report the test can disqualify on its own. Take timed practice tests in the days beforehand and rehearse mental arithmetic and pacing.

Questions & practice

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

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.
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.
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.
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?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

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

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.
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.
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.
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 does indexing work in SQL, and how does it improve performance?

Medium · Technical & Architecture

Approach

Explain the structure: most relational indexes are B-trees (B+ trees) holding the key values in sorted order with pointers to rows. A lookup walks root to leaf in O(log n) page reads instead of scanning all n rows, and because leaves are ordered, the same index serves range filters, ORDER BY and some GROUP BY without a sort.
Cover composite indexes and the leftmost-prefix rule: an index on (account_id, trade_date) helps WHERE account_id = ? and WHERE account_id = ? AND trade_date BETWEEN ? AND ?, but not a filter on trade_date alone. Put equality columns before range columns.
Mention covering indexes: if every column the query needs is in the index (or in INCLUDE columns where supported), the engine answers from the index alone and skips the table lookup.
State the costs and when not to index: each INSERT, UPDATE and DELETE must maintain every index, indexes take storage and memory, and they add little on small tables or low-selectivity columns. Name the patterns that defeat an index: a function on the column (unless an expression index exists), LIKE '%abc' with a leading wildcard, and implicit type conversion.
Show how you verify: run EXPLAIN (EXPLAIN ANALYZE in PostgreSQL) before and after, compare a full scan with an index seek or scan, and note that the planner may still choose a full scan when a query returns a large share of the table.

Follow-up

Given an index on (account_id, trade_date), which of three queries you are shown can use it, and why?
When would you decide not to add an index to a column that appears in a WHERE clause?
An index exists but the plan still shows a full scan. What do you check?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Explain the principles of Object-Oriented Programming.

Medium · Technical & Architecture

Approach

Name the four principles and give each a concrete example in Java or C#, not a dictionary definition. Encapsulation: an Account class keeps its balance private and exposes deposit and withdraw methods that enforce rules such as no negative amounts, so no caller can put the object into an invalid state.
Abstraction: callers depend on an interface such as PaymentProcessor with a process method and do not know whether the implementation calls a card network or an internal ledger. Swapping implementations does not change the calling code.
Inheritance: SavingsAccount extends Account to reuse behaviour. Add the caveat that a subclass must be usable anywhere its parent is (Liskov substitution), and that composition is often safer than deep hierarchies because it avoids tight coupling to a base class.
Polymorphism: overriding gives runtime dispatch, so a List<Account> can call calculateInterest and each subtype runs its own version. Overloading (same method name, different parameter lists) is resolved at compile time. Keep the two distinct.
If there is room, tie it to design principles that follow from these, such as single responsibility and dependency inversion, and show how they make a class easy to unit test by injecting its dependencies.

Follow-up

What is the difference between an abstract class and an interface in Java or C#, and when would you pick each?
Give an example where inheritance was the wrong choice and composition would have been better.
What is the difference between overloading and overriding?

How would you design a basic application to handle user transactions securely?

Medium · Technical & Architecture

Approach

Outline the pieces first: a client, an API layer over HTTPS, an authentication service, the transaction service and a relational database. Authenticate with hashed passwords (bcrypt or Argon2, never plain or fast hashes) plus MFA, and authorise every request by checking that the caller owns the account in the request, which prevents insecure direct object references.
Model money correctly: store amounts as integer minor units or DECIMAL, never floating point, and record movements as an append-only ledger (a debit and a matching credit per transfer) rather than only overwriting a balance. The ledger doubles as the audit trail.
Make a transfer atomic: debit and credit inside one database transaction. Prevent races with SELECT ... FOR UPDATE on both account rows, locked in a consistent order such as ascending account id to avoid deadlocks, or with a single conditional UPDATE ... SET balance = balance - amount WHERE id = ? AND balance >= amount, then check the affected row count.
Make retries safe: the client sends an idempotency key with each transfer, the server stores it under a unique constraint, and a repeated key returns the original result instead of moving money twice.
Finish with the basics: parameterised queries against SQL injection, input validation on amount and currency, TLS in transit and encryption at rest for sensitive fields, rate limiting on login and transfer endpoints, and logs that never record credentials or full account numbers.

Follow-up

Two withdrawals hit the same account at the same moment. How does your design stop it from going negative?
The client times out and resends the transfer request. What happens?
Why not store balances as a double, and how would you handle rounding?

What is your approach to writing unit tests for a financial application?

Medium · Technical & Architecture

Approach

Keep the domain logic (interest, fees, allocation, validation) in plain classes with no database or network calls, so unit tests are fast and deterministic. Structure each test as arrange, act, assert, with one behaviour per test and a name that states the rule being checked.
Test the edges that matter for money: zero, negative and maximum amounts, rounding at the precision boundary, and the rounding mode itself (HALF_EVEN versus HALF_UP). In Java use BigDecimal built from strings, and compare with compareTo, because equals treats 2.0 and 2.00 as different.
Use parameterised tests (JUnit 5 @ParameterizedTest, xUnit [Theory], PHPUnit data providers) for rule tables such as fee tiers, and add property-style checks for invariants, for example that total debits equal total credits after any sequence of transfers.
Remove hidden inputs: inject a clock so date logic (business days, holidays, month end) is testable, and mock external services such as price feeds or payment gateways. Do not mock the code under test or simple value objects.
Cover the failure paths as deliberately as the happy path: insufficient funds, duplicate requests, invalid currency, and a downstream error. Leave database constraints and real concurrency to integration tests against a real database instead of faking them in unit tests.

Follow-up

How would you test logic that depends on today's date or on business-day calendars?
What would you mock in a test of a transfer service, and what would you leave real?
How would you test that concurrent balance updates are safe, and is that still a unit test?

Can you explain the difference between a clustered and non-clustered index?

Medium · Technical & Architecture

Approach

A clustered index determines the physical order of the table: its leaf level holds the full rows sorted by the clustered key, so a table can have only one. A non-clustered index is a separate sorted structure holding the key columns plus a locator back to the row, and a table can have many.
Be specific about engines: in SQL Server a PRIMARY KEY becomes the clustered index by default if none exists, and a table without one is a heap. In MySQL InnoDB the table is always clustered on the primary key (or the first unique NOT NULL index, otherwise a hidden row id). PostgreSQL stores tables as heaps; its CLUSTER command reorders a table once but the order is not maintained.
Explain the lookup cost: a non-clustered index on a clustered table stores the clustering key as its locator (InnoDB secondary indexes store the primary key), so fetching other columns needs a second traversal, a key lookup. A covering index, with INCLUDE columns in SQL Server, removes that step.
Give the trade-offs for choosing the clustered key: narrow, unique, rarely updated and ideally ever-increasing, such as an identity column. A wide key bloats every non-clustered index; a random GUID causes page splits and fragmentation on insert. Range scans on the clustered key, such as trades by date for one account, read contiguous pages.

Follow-up

Why is a random GUID usually a poor clustered key, and what would you use instead?
An execution plan shows many key lookups. How do you get rid of them?
How does PostgreSQL handle this, given it has no maintained clustered index?

Describe your process for troubleshooting a critical bug in production.

Medium · Behavioral & Experience

Approach

Contain first, diagnose second: confirm scope and severity (which users, which accounts, still happening or not), then stop the damage by rolling back the last deploy, turning off a feature flag or pausing the batch job that writes bad data. Say out loud that restoring service comes before finding the root cause.
Build the timeline before forming a theory: what changed and when (deploys, config, schema migrations, upstream feeds, data volume). Line it up against the first error in logs and metrics, and follow one failing request end to end using a correlation or request id.
Reproduce outside production with the same data shape (a sanitised copy of the failing record, the same config). Then narrow it down: bisect the commits between the last good and first bad release, or swap one component at a time, until a single change flips the result.
Fix the cause, not the symptom: write a failing regression test first, then the fix, and ship it through the normal review path. For financial data, also find every record written while the bug was live and correct it with an auditable repair script instead of hand-editing rows.
Close with a short written postmortem: trigger, root cause, why monitoring did not catch it sooner, and one or two concrete changes (an alert, a validation, a test) that stop the same class of bug.

Follow-up

The deploy already ran a schema migration, so a rollback would break the old code. How do you recover?
How would you identify and repair every transaction the bug touched while it was live?
How do you tell the real cause from something that merely changed at the same time?

Suggested practice checklist

Seven days built around the four reported stages: resume stories first, then database and OOP fundamentals, secure transactions and testing, a take-home rehearsal, behavioral answers and timed cognitive practice.

Day 1 — Resume walk-through and project stories

Write the walk-through of your resume with a one-line headline per role and a deeper pass on your most complex project.
For that project, write the context, your own actions versus the team's, the technologies, the root cause of the hardest problem and the outcome.
Record yourself giving the answer and cut anything that does not show your own work.

Deliverable: A written resume walk-through, one detailed project story and a recording of the spoken version.

Day 2 — Indexing and relational database fundamentals

In any relational database you have, load a table with a few hundred thousand rows, run the query plan before and after adding an index, and note the difference.
Write the answer on clustered versus non-clustered indexes, covering row order, pointers back to the table and one clustered index per table.
List three cases where you would skip or drop an index, such as a small table, a low-selectivity column or a write-heavy table.

Deliverable: A saved before-and-after query plan, and a spoken two-minute answer on indexing with a clustered versus non-clustered comparison.

Day 3 — OOP principles and secure transaction design

Explain encapsulation, abstraction, inheritance and polymorphism aloud, each with an example from code you have written in Java, C# or PHP.
Outline a basic application that handles user transactions: authentication, input validation, parameterized queries, database transactions, an audit trail and no secrets in code.
Write a short answer on keeping data correct under concurrent transactions: transactions and isolation, row locking or optimistic versioning, idempotent retries.

Deliverable: A spoken OOP answer with four examples, plus a one-page outline of a secure transaction application with a paragraph on concurrency.

Day 4 — Testing financial code and production debugging

Write the unit-test plan for a function that calculates a fee or balance: normal cases, rounding, zero and negative amounts, boundaries and failure paths.
Write one answer on handling money in tests: decimal types rather than floats, fixed test data and no dependence on the clock or live services.
Outline your production-troubleshooting sequence: stop the impact, find what changed, read logs and metrics, reproduce, fix, add a test and write up the cause.

Deliverable: A test plan for one money-handling function and a numbered production-debugging routine with a real example from your own experience.

Day 5 — Take-home rehearsal

Build a small CRUD web application in your strongest language, using Symfony if you work in PHP, with a relational schema, validation and a few tests.
Add a README that states how to run it, your design decisions and what you would improve with more time.
Practice the live review: walk through the code, defend each framework and schema choice, and explain how a change would be deployed.

Deliverable: A working, tested CRUD application with a README, and a spoken walk-through of it.

Day 6 — Behavioral answers: motivation, independence, vague requirements

Write the answer on why you want to work at Axos Clearing and in clearing and banking, with at least one specific reason about the work itself.
Write a story about solving something with no mentor or documentation, including how you checked it was right.
Write a story about vague or changing requirements, covering the assumptions you wrote down, the smallest piece you shipped and how you confirmed it.
Rehearse all three aloud and add the technical details a follow-up would ask for.

Deliverable: Three written STAR stories and spoken run-throughs of each.

Day 7 — Timed cognitive practice and full mock

Take one full timed cognitive practice test and review every miss by type: pattern, word logic or arithmetic.
Run a mock of the hiring manager round: resume walk-through, one behavioral story, then indexing, OOP and secure transactions answered aloud.
Write the questions you want to ask about the team, the in-office expectation and the take-home format.

Deliverable: A scored practice test with an error log by question type, a recorded mock and a list of questions to ask.

Behavioral and resume preparation

Candidates report that the early stages are heavily behavioral and that your account of past work is explored in detail. For this role, that means project ownership, why you want this company and the financial sector, self-directed problem solving without mentorship, handling unclear requirements, and how you resolve technical disagreements. Use a STAR structure, add the technologies and the business result, and keep your own contribution distinct from the team's.

Describe a specific challenge you faced in your last project—what was the root cause, and exactly how did you fix it?
Tell me about a disagreement with a teammate over a technical approach and how it was resolved.

Why do you want to work at Axos Clearing specifically?

Medium · Behavioral & Experience

Approach

Build the answer from three parts: the work (clearing, custody and transaction processing for broker-dealers, RIAs and introducing brokerages), what you bring to it (the database, backend or reliability work you have actually done), and why financial systems rather than any other industry.
Learn enough to explain clearing and custody in a sentence each: confirming and settling trades and keeping the records, and safekeeping client assets. Showing that you understand what the system does makes the answer specific.
Tie one reason to a real detail of the role, such as migrating legacy systems, building broker-dealer portals or automating manual banking processes, and connect it to a project of yours that looks similar.
Keep pay and benefits out of the answer. Candidates report that the benefits get plenty of airtime in the recruiter call, so a motivation built on them sounds thin.
Close by saying what you would like to work on first, and make sure it is consistent with the location and in-office expectations you have asked about.

Follow-up

What do you understand clearing and custody to mean, and who relies on them?
What about the financial sector interests you compared with other industries?
What kind of work on the team would you like to take on first?

Walk me through your resume and highlight your most complex technical project.

Medium · Behavioral & Experience

Approach

Open with a two-minute chronological pass: one headline per role covering the scope, the main technologies and one result. Then say which project you will go deep on and why it was the most complex.
For the deep project, use a fixed order: the problem and the stakes, the architecture and stack, the constraint that made it hard, the options you weighed, the decision you made, and the measured result.
Separate your contribution from the team's explicitly. Candidates report being asked about your exact technical footprint, so say "I designed the schema and wrote the settlement import" rather than "we built the pipeline".
Pick complexity that is technical, not just large: concurrency, data volume, a legacy integration, a migration, a performance problem. Be ready to explain every technology you list, because short high-level answers reportedly draw requests to elaborate.
Rehearse three layers of depth for the project: the overview, the mechanics (data model, queries, indexes, error handling), and what you would change now.

Follow-up

Which part of that did you personally build, and which did someone else?
Why did you choose that database or framework over the alternatives?
If you ran that project again, what would you do differently?

Tell me about a time you had to figure out a solution without any mentorship or training.

Medium · Behavioral & Experience

Approach

Choose a story where no mentor or documentation was available and the task was real: learning an unfamiliar framework, inheriting an undocumented service or building a feature in a stack nobody around you knew.
Show a method, not just persistence: how you broke the unknown into pieces, where you looked (source code, logs, official docs, small experiments), and how you built a small spike to test your understanding before committing to a design.
Say how you verified the result: tests, comparison against known good output, a review by someone later. A solution you never checked is the common weakness of this answer.
Include one moment when you chose to ask for help or escalate, and why. Working alone is not the same as never asking, and that shows judgment.
End with the result and what you left behind, such as a README, tests or a runbook, so the next person did not face the same blank page.

Follow-up

How did you know your solution was correct without anyone to review it?
At what point did you decide to ask someone for help?
What would you hand over so that a new teammate could pick it up?

How do you handle situations where business requirements are vague or changing?

Medium · Behavioral & Experience

Approach

Describe a concrete process: ask clarifying questions, write the assumptions down, confirm them with the stakeholder, and split the work so the clear parts can proceed while the unclear parts wait for answers.
Use an example from a domain with rules, such as a fee calculation, a settlement cut-off or a reporting field whose definition was unclear. Say who you asked and what you wrote down.
Show how you absorbed change: a thin vertical slice shown early, configuration or small interfaces in place of hard-coded rules, and a record of each decision and who approved it. In a regulated setting that record matters.
Name the trade-off between waiting and building to a guess, and explain how you decided which to do, for example by reversibility of the work.
Finish with the outcome and what changed in how you work afterward. Avoid answers that stop at "I communicate a lot".

Follow-up

What did you do when two stakeholders gave you conflicting requirements?
How did you handle a requirement that changed after you had built most of the feature?
How do you record decisions so the team can see why something was built the way it was?