Acumen Fiscal Agent Software Engineer Interview Guide

The 60-second brief

Candidate-facing descriptions say Acumen Fiscal Agent's software helps organizations manage financial and operational resources, and that engineers are involved from requirements through to maintenance. Candidates describe working with product managers, UX designers and data analysts. One reported design question, about real-time financial transactions, comes from the financial domain, so prepare to talk about correctness: idempotent writes, consistent data and query performance.

This guide is for software engineers preparing for the Acumen Fiscal Agent loop. Candidates describe the core requirements as Java, Python or C#, web frameworks and tools (.NET, React, Git, Docker), database design and methodical debugging, with AWS or Azure, agile practice and secure development as extras, plus several years of experience. The guide covers each reported round, specific answers to all seventeen reported questions, the database and design topics around them, and a seven-day plan.

Candidates report four rounds over about 3-5 weeks: Initial Screening, Technical Interview, Behavioral Interview and Final Evaluation.

Focus areas

• Software Engineering
• Technical Leadership
• System Design

Overview

Candidates describe software for managing financial and operational resources, with engineers involved from requirements to maintenance, alongside product managers, UX designers and data analysts. Preparation therefore splits into two parts: technical depth in one language and in databases, and evidence that you can turn a business requirement into working, reviewed software with other people.

The stack candidates describe is concrete: Java, Python or C# as the main language, web frameworks such as .NET and React, Git and Docker as tools candidates list, and database design with query optimization. AWS, Azure, agile delivery and security practices are listed as extras. Pick one interview language and know it below the syntax level: how it manages memory, how it represents decimal money, and how its standard library searches and sorts. Example questions candidates mention also include memory management and the difference between relational and non-relational databases, so review indexing, transactions and when a document store fits.

The seventeen reported questions fall into five groups. The largest group is five conversational technical questions: which languages you know, object-oriented principles, a hard technical problem you solved, code quality and version control. Four are design questions: a real-time financial transaction system, choosing a technology stack, a system you designed, and scaling under load. Two are problem-solving cases, a sudden drop in software performance and analysing a dataset for insights. Two are coding fundamentals, reversing a string and searching a sorted array. Four are behavioral. The topic areas candidates list are Software Engineering, Technical Leadership, System Design, Software Architecture and Scalability.

Because the coding questions are small, rehearse edge cases, complexity and clean code for them; an off-by-one in binary search or a quadratic string build is easy to slip into on a short problem. For the financial-transaction design question, prepare idempotency, a double-entry ledger, decimal amounts and reconciliation. For the behavioral and leadership questions, bring your own decisions and measurable outcomes, ideally from code review and cross-functional work like the work candidates describe for this role.

The Acumen Fiscal Agent interview process

Candidates report the four stage names below, each with a one-line description. The format inside each stage is thinly reported, so ask your recruiter about it as you go.

Initial Screening

Candidates describe the Initial Screening as a check of technical aptitude and fit for the role. No specific format or question set is reported for it. Prepare your background against the requirements candidates describe: Java, Python or C#, web frameworks and tools, databases and debugging. Have a short, specific account of what you built, in which language, against which database, and what you personally owned. Also use this stage to learn the rest of the loop: which language you may code in, and whether the technical stage includes live coding.

What to demonstrate

• Technical aptitude, as candidates describe the stage
• Fit between your experience and the requirements candidates describe: Java, Python or C#, web frameworks, databases, debugging

How to prepare

• Write a background summary that names the language, framework and database of each recent project and the part you owned.
• For each must-have skill (Java/Python/C#, web frameworks and tools, database design, debugging), write one sentence pointing to a project where you used it.
• List questions for the recruiter: the interview language, whether coding is live, and what the Final Evaluation consists of.

Technical Interview

Candidates describe the Technical Interview as a deeper look at problem-solving and technical skills. Candidates report that coding, if asked, is often done in real time. The reported technical questions span conversational topics (languages, object-oriented principles, code quality, version control), design (real-time financial transactions, stack choice, scaling, a system you designed), problem-solving cases (a performance drop, analysing a dataset) and two coding fundamentals (reversing a string, searching a sorted array). No report says which of these come up in this stage. Prepare all of them, and for any code you write, give the complexity and walk through the edge cases before you finish.

What to demonstrate

• Problem-solving and technical skills, as candidates describe the stage
• Coding, if asked, is often done in real time, per candidate reports

How to prepare

• Write string reversal and binary search from scratch in your interview language, testing empty, single-element, not-found and duplicate inputs.
• Outline the real-time financial transaction design end to end: idempotency keys, a double-entry ledger, row locking, an outbox for events and a reconciliation job.
• Rehearse the performance-drop case as an ordered diagnosis sequence: quantify, correlate with changes, locate the time, mitigate, fix, verify.
• Review the stack candidates list for this role: one of Java, Python or C# in your interview language, plus database design and query optimization (indexes, EXPLAIN plans, relational versus non-relational trade-offs).

Behavioral Interview

Candidates describe the Behavioral Interview as a look at interpersonal skills and fit within the team. No report maps specific questions to this stage, but the four reported behavioral questions are the natural material to prepare for it: working with a difficult team member, how you led a project or initiative, how you prioritize across multiple deadlines, and what motivates you. Build a small set of true stories that cover these themes. Each should have a decision you made, the alternative you rejected and a measurable result.

What to demonstrate

• Interpersonal skills, as candidates describe the stage
• Fit within the team, as candidates describe the stage

How to prepare

• Write five or six STAR stories and map each one to the four reported behavioral questions.
• Keep spare stories for related prompts candidates mention elsewhere: advocating for your ideas, giving and receiving feedback, and learning a new technology quickly.
• Include one story drawn from a code review disagreement and one from working with a product manager, designer or analyst.
• Rehearse each story aloud using "I" for your actions, and end with a number: defects, latency, delivery date or adoption.

Final Evaluation

Candidates describe the Final Evaluation as a combined assessment of technical and interpersonal competencies. No format, participants or question set is reported for it. Prepare as if both sides of the loop could come up again: your strongest system story with its architectural decisions, your reasoning on choosing a stack, and two or three behavioral stories you have not used yet. Ask your recruiter beforehand what the stage consists of.

What to demonstrate

• Technical competencies, as candidates describe the stage
• Interpersonal competencies, as candidates describe the stage

How to prepare

• Have a system you designed ready to explain, with two or three decisions, the alternatives you rejected and what you would change.
• Write a stack-choice decision for a financial back-office application, weighing Java versus C#/.NET, relational versus document storage, and AWS versus Azure.
• Write a few specific questions about the team's stack, code review practice and how releases reach production.

Where candidates lose points

Representing money as float or double in the transaction design or in code.

State early that amounts are stored as integer minor units or exact decimals (BigDecimal, C# decimal, Python Decimal, NUMERIC in SQL). Also state the rounding rule and where rounding happens. Practise saying this in the first minutes of the real-time financial transaction question.

A financial transaction design with no idempotency, ledger or reconciliation, so a client retry or a processor timeout double-charges or loses money.

Build the design around an idempotency key with a unique constraint, append-only double-entry ledger rows written in one database transaction, a state machine for unknown outcomes, an outbox for events and a reconciliation job. Rehearse the cross-shard transfer and the timeout-then-retry follow-ups until you can answer them without hesitating.

Fumbling the easy coding questions: binary search off-by-one or mid overflow, or string reversal by repeated concatenation.

Write both from scratch in your interview language without an IDE, then test empty, single-element, not-found, duplicate and Unicode inputs. State the time and space complexity for each version you write, and pick one interval convention (closed or half-open) and keep to it.

Answering the performance-drop case with a list of fixes (add a cache, add servers) instead of a diagnosis.

Learn an ordered sequence: quantify the drop, correlate it with recent changes, locate the time with traces or profiling, mitigate, find the root cause, verify with the same metric, then add a regression guard. Practise it on a memory-growth scenario and on a query whose plan changed.

Behavioral and leadership stories told in "we", with no decision you made and no measurable result.

Before the Behavioral Interview, map five or six stories to the reported prompts (difficult teammate, leading a project, competing deadlines, motivation). Each should name your decision, the alternative you rejected and a number. Keep a spare story or two unused for the Final Evaluation.

Questions & practice

Write a function to reverse a string. What is the time complexity of your solution?

Medium · Coding / Algorithms

Approach

1. Two pointers on a mutable character array: swap the left and right characters and move both inward until they meet. This takes O(n) time and O(1) extra space.
2. Know your language. Java and C# strings are immutable, so convert to char[] (then swap, or use Array.Reverse in C#) or use Java's StringBuilder.reverse(); each costs O(n) extra space. In Python, s[::-1] is O(n). Building the result with += in a loop is O(n^2) in Java and C#, so avoid it.
3. Cover the edge cases: null input, the empty string, one character and an even-length string. A recursive version works but uses O(n) stack and can overflow on long input.
4. Raise Unicode, and separate the cases. Swapping chars in a char[], or calling Array.Reverse in C#, splits surrogate pairs (emoji). StringBuilder.reverse() in Java keeps surrogate pairs together but still detaches combining marks and breaks ZWJ emoji sequences. Only grapheme-cluster reversal gets all of these right.
5. For grapheme clusters, java.text.BreakIterator follows extended grapheme clusters only from JDK 20. On older JDKs use the regex \X or ICU4J's BreakIterator. In C#, use StringInfo or the TextElementEnumerator it returns.

Follow-up

• Reverse the order of words in a sentence in place.
• How would you handle emoji and combining accents correctly?
• Use the same technique to check whether a string is a palindrome.

Explain how you would implement a search algorithm to efficiently find an item in a sorted array.

Medium · Coding / Algorithms

Approach

1. Binary search: keep lo and hi, compute mid = lo + (hi - lo) / 2 (this avoids int overflow in Java and C#), compare, and discard half each step. Time is O(log n). Space is O(1) iteratively or O(log n) recursively.
2. State the loop invariant and match it to the bounds. Use lo <= hi with a closed interval, or lo < hi with a half-open one. Most off-by-one bugs come from mixing the two.
3. Edge cases: an empty array, a single element, a target smaller than all or larger than all elements, and a target that is absent (return -1 or the insertion point).
4. With duplicates, write the lower-bound variant to find the first occurrence and the upper-bound variant for the last. Know the library versions: Arrays.binarySearch, Array.BinarySearch (which returns the bitwise complement of the insertion index) and Python's bisect.
5. Mention when linear search wins: very small arrays, or unsorted data searched once, where sorting first costs O(n log n).

Follow-up

• Return the first and last positions of a target that appears several times.
• Search a sorted array that has been rotated at an unknown pivot.
• How would you search a sorted stream whose length you do not know?

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?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

What programming languages are you most proficient in, and how have you applied them in your projects?

Medium · Technical / Domain Questions

Approach

1. Lead with one primary language (Java, Python or C#, the three candidates list) and name a second you use regularly. Do not list everything you have touched.
2. For each language, give one project: what you built, why that language fit, and one feature you relied on, such as Java streams and CompletableFuture, C# async/await and LINQ, or Python generators and type hints.
3. Show depth below the syntax: how the runtime manages memory (JVM or .NET generational GC, CPython reference counting plus a cycle collector) and one problem it caused you, such as a leak or GC pauses.
4. Tie it to the domain: money needs exact decimal types (BigDecimal in Java, decimal in C#, Decimal in Python) or integer minor units, never float or double.
5. Be honest about levels. Saying "production experience in C#, working knowledge of Python" is more credible than claiming expertise in all three.

Follow-up

• How does garbage collection work in your main language, and when has it caused you a problem?
• How would you represent and round currency amounts in that language?
• If you had to switch to Java or C# here, what would you need to learn first?

Can you explain the principles of object-oriented programming and provide examples of how you've used them?

Medium · Technical / Domain Questions

Approach

1. Name the four principles and give a concrete use of each. Encapsulation: an Account class with a private balance, changed only through deposit and withdraw methods that enforce invariants such as no overdraft. Abstraction: a PaymentProcessor interface that hides vendor details.
2. Polymorphism through interface implementation: ACH and card processors implement PaymentProcessor and are called through that one interface. Inheritance is a separate case: a SavingsAccount extends a base Account and overrides interest accrual while reusing the shared balance logic.
3. Explain why composition is often better than inheritance, using the Account hierarchy as the example: deep hierarchies are fragile, and injecting a strategy object (for example a fee-calculation policy) is easier to test and change than another subclass.
4. Mention SOLID, especially Liskov substitution (a subclass must honour the parent's contract) and dependency inversion (depend on interfaces, inject implementations, mock them in tests). Contrast interfaces with abstract classes in Java or C#: abstract classes can hold shared state; interfaces can have default methods but no instance fields.
5. Close with a real example from your code where applying a principle, or dropping one, made a change easier.

Follow-up

• When would you avoid inheritance, and what would you use instead?
• What is the difference between an interface and an abstract class in your language?
• How does dependency injection make this design easier to unit test?

Describe a challenging technical problem you faced and how you resolved it.

Medium · Technical / Domain Questions

Approach

1. Pick a problem with real technical depth, such as a race condition, data corruption, a memory leak or a slow query. A deadline crunch or a process problem does not count.
2. Situation and task in two sentences: the system, the symptom and the impact (failed transactions, slow pages, wrong reports).
3. Spend most of the answer on the diagnosis: hypotheses in order, the evidence for each (logs, profiler, EXPLAIN plan, a reproduction), and what you ruled out.
4. Give the fix and its trade-off, the measured result (latency from X to Y, error rate to zero), and what you added so it cannot recur: a test, an alert or a guard.
5. The answer fails if your part is unclear. Say "I" for your own actions and name who else helped.

Follow-up

• How did you confirm the root cause and not just a symptom?
• What would you do differently if you met the same problem again?
• What did you change in testing or monitoring afterwards?

How do you ensure code quality and maintainability in your projects?

Medium · Technical / Domain Questions

Approach

1. Work in layers. Automated tests come first: unit tests for business rules such as fee and balance calculations, integration tests against a real database, and a few end-to-end tests, all run in CI.
2. Code review comes next, and candidates list it as part of this role. Keep pull requests small, review for correctness and clarity before style, and leave formatting to linters and static analysers.
3. Maintainability: clear module boundaries, names that use the business vocabulary, no duplicated business rules, and short decision records for architectural choices.
4. Pay down debt deliberately. Refactor behind tests, and add characterization tests before changing untested legacy code.
5. Give evidence from your own work, such as an escaped-defect rate that fell or a refactor that cut the time to add a feature.

Follow-up

• How do you handle a reviewer who disagrees with your approach?
• How do you safely change legacy code that has no tests?
• Is there a coverage target you trust, and why or why not?

What experience do you have with version control systems, and how do they fit into your development workflow?

Medium · Technical / Domain Questions

Approach

1. Describe your Git workflow concretely: short-lived feature branches, pull requests with review and CI checks, merge to main, and tags for releases.
2. Compare branching models. Trunk-based development with feature flags keeps integration continuous. GitFlow suits scheduled releases but makes merges larger and later.
3. Merge versus rebase: rebase your own branch for a linear history, but never rewrite a shared branch. Use revert, not reset, to undo something already pushed.
4. Name tools you have used to solve a real problem: git bisect to find the commit that caused a regression, reflog to recover lost work, cherry-pick for a hotfix.
5. Cover hygiene: one atomic commit per change with a message that explains why, and no secrets in the repository. A leaked key must be rotated, because history keeps it.

Follow-up

• Production needs a hotfix while main has unreleased work. What do you do?
• How would you recover a commit you lost with git reset --hard?
• How would you find which commit introduced a bug among hundreds?

How would you approach designing a system to handle real-time financial transactions?

Medium · System Design / Architecture

Approach

1. Fix requirements first: transaction types, peak throughput, latency target, and the non-negotiables. No transaction may apply twice, balances must never go wrong, and every change needs an audit trail.
2. Core write path: an API that requires an idempotency key, stored under a unique constraint so a retry returns the original result. Then a relational database transaction that writes balanced double-entry ledger rows (debits equal credits) to an append-only table. Lock the account rows with SELECT ... FOR UPDATE, or use a version column for optimistic concurrency. Store amounts as integer minor units or decimals.
3. Model each transaction as a state machine (pending, authorized, settled, failed, reversed). When an external processor times out, the outcome is unknown: keep the transaction pending and resolve it by status query or reconciliation, never by blindly retrying.
4. Publish events through a transactional outbox to a queue for notifications, reporting and analytics. This avoids the dual write, where the database commits but the message is lost.
5. Scale by partitioning on account ID. Transfers across partitions need a saga with compensating entries. Add a daily reconciliation job against bank or processor files, plus encryption and access logging for sensitive data.

Follow-up

• A client retries after a timeout. How do you guarantee it is not charged twice?
• How do you move money between two accounts that live on different shards?
• Your ledger and the bank's settlement file disagree. What happens next?

What factors do you consider when choosing a technology stack for a new application?

Medium · System Design / Architecture

Approach

1. Start from requirements: workload shape (transactional, analytical, real-time), consistency needs, expected scale, latency, and security or compliance constraints.
2. Then the team and organisation: languages the team already knows and the platforms it already operates, plus what the organisation can hire for and run. For this role, Java, Python or C# are the languages candidates describe, and .NET, React, Docker, AWS and Azure appear in the frameworks, tools and cloud services they list.
3. Then the ecosystem: library maturity, community and support life, licensing, observability tooling and total running cost.
4. Give a worked choice. For a financial back-office application, a relational database fits because the data has transactions, joins and constraints. C#/.NET fits if the organisation already runs on Azure. A React front end fits if the team knows it. Name what you gave up.
5. Make the decision explicit: a scored comparison, a short prototype on the riskiest part, and a written decision record so the reasoning outlives the meeting.

Follow-up

• When would you choose a non-relational database instead?
• How do you weigh team familiarity against a technically better tool?
• A stack choice turned out wrong a year in. How would you migrate away?

Describe a system you designed and the architectural decisions you made.

Medium · System Design / Architecture

Approach

1. Pick one system you know end to end and state its context: users, traffic or data volume, and constraints such as latency, budget or compliance.
2. Describe the architecture aloud in data-flow order: clients, API layer, services, data stores, queues, caches and external integrations.
3. Choose two or three decisions, such as monolith versus services, database choice, sync versus async processing or a caching strategy. For each, say the alternative you rejected and why.
4. Give the results in numbers (throughput, p99 latency, cost, incident count) and one decision you would reverse now, and why.
5. Make your role explicit: what you designed, what you only implemented, and how you got agreement on the design.

Follow-up

• What breaks first at ten times the load?
• How did you keep data consistent between components?
• What would you redesign if you started again today?

How do you approach scaling applications to handle increased user load?

Medium · System Design / Architecture

Approach

1. Measure before changing anything. Find the bottleneck with metrics and profiling (CPU, memory, database time, external calls), and load-test to find the limit.
2. Keep the application tier stateless behind a load balancer, with sessions in a shared store or tokens, so it can scale out with autoscaling.
3. Fix the database in order of cost: indexes and query rewrites first, then connection pooling, then read replicas (with replication lag in mind), then partitioning or sharding as a last resort.
4. Add caching where reads dominate: a CDN for static assets, and an in-memory cache with TTLs and explicit invalidation for hot reads. Never serve a stale balance to a decision that moves money.
5. Move slow work (reports, notifications, exports) to queues and workers, and add rate limiting and backpressure so a spike degrades service gracefully instead of cascading.

Follow-up

• After adding read replicas, how do you give a user read-your-own-writes?
• Writes, not reads, are the bottleneck. What now?
• How would you design a load test for this?

Walk us through how you would tackle a significant drop in software performance.

Medium · Problem-Solving / Case Studies

Approach

1. Confirm and quantify the problem. Which metric moved (p50 or p99 latency, throughput, error rate), on which endpoints, since when, and for all users or one segment?
2. Correlate with changes: deploys, configuration, feature flags, traffic shape, data growth and dependency health. A drop that starts at a deploy points to a rollback.
3. Locate where the time goes with traces and profiling: database, external calls, CPU, GC pauses or lock contention. Common causes are a missing index or a query plan change after data growth, N+1 queries, connection pool exhaustion, a memory leak, and a cache miss storm.
4. Mitigate first (roll back, scale out, disable a feature), then fix the root cause. Verify with the same metric you started from.
5. Close the loop with a blameless postmortem and a regression guard, such as a latency alert, a load test in CI or a query-plan check.

Follow-up

• How would you show that a slow query regressed because its plan changed?
• Memory grows steadily until a restart. How do you find the leak?
• Rolling back did not fix it. What next?

Given a set of data, how would you approach analyzing it to derive actionable insights?

Medium · Problem-Solving / Case Studies

Approach

1. Start from the decision the analysis should inform and the metric that would change it, before touching the data.
2. Understand the data: its source, grain (one row per transaction, per account or per day), time zones, and quality problems such as nulls, duplicates, outliers and late-arriving records.
3. Explore with SQL or pandas: distributions, trends over time, and breakdowns by segment such as client type, region or product. Form hypotheses and check each one against the data.
4. Guard the conclusions: correlation is not causation, small segments are noisy, and confounders need controlling. Say what evidence would make a finding actionable.
5. Communicate one or two findings, each with the evidence, the recommended action and the expected impact, in a chart a non-technical stakeholder can read.

Follow-up

• How do you handle missing or inconsistent records?
• How would you test whether the pattern you found is causal?
• How would you turn this one-off analysis into something repeatable?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Each day targets one part of the four reported rounds and the reported questions behind it, using the stack candidates list: Java, Python or C#, .NET, React, Git, Docker and database design.

Day 1 — Background, languages, Git and Docker

• Write a background summary naming the language, framework and database of each recent project and the part you owned, then list recruiter questions: interview language, whether coding is live, and the Final Evaluation format.
• Answer the languages question with one project per language, including memory management and decimal money handling in your main language.
• Write your Git workflow answer: branching model, merge versus rebase, and one real use of bisect or reflog.
• Containerise a small service in your main language: write the Dockerfile, then explain image layers, build caching and why you would keep secrets out of the image.

Deliverable: A background summary with recruiter questions, a languages answer, a version-control answer and a working Dockerfile with a short explanation.

Day 2 — Coding fundamentals with edge cases

• Write string reversal in your interview language three ways (two pointers, library call, recursion) and state the complexity of each.
• Write binary search, then lower-bound and upper-bound variants, and test empty, one-element, absent-target and duplicate inputs.
• Solve the follow-ups: reverse words in place, and search a rotated sorted array.

Deliverable: Tested solutions for string reversal, binary search and its variants, plus both follow-ups, with complexities noted.

Day 3 — OOP, code quality, databases and React

• Model Account, SavingsAccount, Transaction and a PaymentProcessor interface in your language to show encapsulation, inheritance, polymorphism and composition.
• Write a code-quality answer covering tests, code review, CI gates and legacy refactoring, with one metric from your own work.
• Work the practice question on why an owner filter ignores the listing index, write out the EXPLAIN reasoning, then compare relational and non-relational databases for financial records.
• Explain React state and rendering for a form-heavy back-office screen: where state lives, controlled inputs, validation and what triggers a re-render.

Deliverable: A class model, a code-quality answer, an index analysis with a database comparison, and a written React state and rendering explanation.

Day 4 — Real-time financial transaction design

• Outline the full design: idempotency keys, a double-entry ledger, row locking, a transaction state machine, an outbox and reconciliation.
• Write the SQL for the ledger tables and a transfer that locks both accounts in a consistent order to avoid deadlock.
• Work the practice question on holding a per-tenant cap against concurrent creates, as practice in transactional concurrency.
• Work the practice question on diffing a projection against the primary, and treat it as a reconciliation job.

Deliverable: A design outline, ledger schema and transfer SQL, plus worked answers to the concurrency and reconciliation practice questions.

Day 5 — Scaling, microservices, stack choice and your own system

• Write the scaling answer as an ordered bottleneck sequence: measure, stateless tier, indexes, pooling, replicas, caching, queues, sharding.
• Write a short answer on when to split a monolith into services and what it costs: distributed transactions, operational overhead, and service boundaries drawn around data ownership.
• Write a stack decision for a financial back-office application covering Java versus C#/.NET, relational versus document storage, React for the front end, and AWS versus Azure.
• Write the system-you-designed story with its context, data flow, two or three decisions with rejected alternatives, and numbers.

Deliverable: A scaling answer, a monolith-versus-services trade-off note, a stack decision record and a system story.

Day 6 — Problem-solving cases and distributed-systems outlines

• Write the performance-drop diagnosis sequence and apply it to a query-plan regression and to connection pool exhaustion.
• Work the practice question on edge instances growing in memory until a nightly restart, from heap evidence to the fix.
• Analyse a sample transactions dataset for one actionable insight, covering grain, data quality, segments and the causal caveats.
• Outline the two example design questions candidates mention. Authentication across platforms: OIDC/OAuth2 single sign-on through a central identity provider, short-lived access tokens with refresh tokens, and revocation. Data consistency: strong versus eventual consistency, idempotent consumers, the outbox pattern, and sagas versus two-phase commit.

Deliverable: A diagnosis sequence with two applied scenarios, a memory-leak walkthrough, a one-insight analysis with its evidence, and outlines for authentication and data consistency.

Day 7 — Behavioral stories and the Final Evaluation

• Write STAR stories for the challenging technical problem, a difficult teammate, leading a project, competing deadlines and motivation.
• Add stories for advocating an idea, giving or receiving review feedback, and learning a new technology quickly.
• Rehearse every story aloud in "I", and mark which unused ones you are holding back for the Final Evaluation.

Deliverable: A story bank mapped to every reported behavioral prompt, with a quantified result per story and a reserve set for the final stage.

Behavioural preparation

Candidates describe the Behavioral Interview as a look at interpersonal skills and fit within the team. The first four prompts below are the reported behavioral questions, covering conflict, leadership, prioritisation and motivation. The last two are example questions candidates mention for other areas. This role involves code reviews and work with product managers, UX designers and data analysts, so stories from those collaborations fit best. Each story should show a decision you made, the alternative you rejected and a result you can measure.

1. Describe a time when you had to advocate for your ideas in a team setting.
2. Can you describe a project where you had to learn a new technology quickly?

Describe a time when you had to work with a difficult team member. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Pick a real conflict over behaviour or approach, such as a teammate who blocked reviews, missed handoffs or dismissed feedback. Describe behaviour, never personality.
2. Show that you tried to understand them first: what pressures or incentives explained the behaviour.
3. Describe the direct, private conversation: the specific behaviour, its impact on the work, and what you agreed to change, including your own part.
4. Escalate only after that, and say why it became necessary. Give the outcome in work terms, such as faster review turnaround or a delivered milestone.
5. The story fails if it blames the other person, ends with your manager fixing it, or has no change in your own behaviour.

Follow-up

• What would you have done if nothing changed after your conversation?
• What did you learn about your own contribution to the conflict?
• How is your working relationship with that person now?

Can you give an example of how you have led a project or initiative?

Medium · Behavioral / Leadership

Approach

1. Choose a project where you owned the outcome, ideally as a technical lead or a lead without formal authority. Being a member of the team is not enough.
2. Cover how you scoped and planned it: breaking it into milestones, identifying the riskiest piece and tackling it first, and agreeing priorities with product, design or analytics partners.
3. Show leadership moments: a technical decision you made and defended, a risk or slip you caught early, and how you unblocked or developed teammates.
4. End with measured results (delivery date, adoption, defect rate, cost) and one thing you would run differently.
5. Tie the story to the Technical Leadership topic candidates report: mention design reviews, code review standards or mentoring if they were part of it.

Follow-up

• How did you handle a teammate who kept missing commitments?
• What did you cut from scope, and how did you decide?
• How did you know the project succeeded?

How do you prioritize tasks when faced with multiple deadlines?

Medium · Behavioral / Leadership

Approach

1. Give a method: list everything, then rank by impact and by the cost of being late. A regulatory or financial deadline is harder than an internal one. Also weigh dependencies, meaning who is blocked on you.
2. Show communication. Tell stakeholders early which item slips and why, and renegotiate scope rather than quietly missing a date.
3. Protect focus by batching interruptions and finishing the highest-impact item before starting the next.
4. Prove it with a real example: the competing deadlines, the ranking you chose, the trade-off you announced and the result.
5. Do not answer "I work longer hours". That describes effort, not prioritisation.

Follow-up

• Two stakeholders both say their request is top priority. What do you do?
• A production incident lands in the middle of this. How does your plan change?
• Tell me about a deadline you missed and how you handled it.

What motivates you to excel in your work?

Medium · Behavioral / Leadership

Approach

1. Name one or two motivations that are specific and true: shipping something people rely on, solving hard correctness problems, or growing others through review and mentoring.
2. Back each one with evidence: a time the motivation made you go beyond the task, such as adding reconciliation checks nobody asked for or improving a slow query that hurt users.
3. Connect it to the role candidates describe: software for managing financial and operational resources, where you can point to correctness and reliability work you have done.
4. Avoid generic lines ("I love coding") and answers that are only about pay or title. Do not recite the employer's mission back.

Follow-up

• What demotivates you, and how do you deal with it?
• Tell me about work you did beyond your assigned scope.
• What do you want to get better at in the next year?