Acumen Software Engineer Interview Guide

The 60-second brief

The reported role description says Software Engineers build and run the technology behind Acumen's financial management services and its participant-directed programs, which support people living independently. It names clients, support coordinators and internal operations teams as the people the work affects. Candidates describe projects spanning enterprise applications, data workflows and integrations between internal platforms and outside third-party services, with security and compliance expectations on the data involved. The requirements candidates report are a modern language (Java or Python are named), object-oriented programming, relational databases with SQL, web applications, APIs, and cloud or enterprise frameworks. Healthcare, fintech, enterprise SaaS and statistical data analysis are listed as a plus.

This guide is for Software Engineer candidates preparing for Acumen's reported process, at any level from entry to senior. It covers each of the four reported stages and gives question-by-question approaches to the reported technical, data-analysis, design and behavioral questions. It also includes a seven-day plan that rotates through Java and OOP fundamentals, SQL, statistics and regression, integration design, and a rehearsal of your take-home walkthrough. The data-analysis and statistics sections matter even if you see yourself as a pure backend engineer: candidates report one loop weighted toward data analysis, statistics, probability and regression.

Candidates report four stages over roughly 3-5 weeks: Recruiter Screening, a Take-Home Assignment, a Technical Review Call on the take-home results, and an Onsite/Virtual Loop of several interviews plus written tests.

Focus areas

• Data Analysis
• Statistics
• Probability

Overview

The reported questions fall into four groups. Technical and domain knowledge covers your past projects and their architecture, choosing a language (framed as Java versus C), reversing a string iteratively and then recursively, OOP and data structures, and SQL joins and data manipulation. Data analysis and coding covers walking through your take-home methodology, testing whether a statistical claim or trend is significant, preprocessing raw data and choosing a model, and optimizing a code snippet or data pipeline. System design covers scalable enterprise components, third-party and internal API integrations, and performance, security and data privacy. Behavioral covers your background, cross-functional work and handling ambiguity.

For a software role, the data side of this loop is unusual. Candidates report one loop weighted toward data analysis, statistics, probability and regression. The take-home is also reported as either a data exercise or a coding exercise. Prepare to clean a messy dataset, run and explain a significance test, and read a multiple-regression output (coefficients, p-values, R-squared, collinearity), alongside your usual coding preparation.

The reported stages make the take-home central. Candidates describe a technical call held specifically to review take-home results, so whatever you submit is the material you will defend. Build the submission so you can explain it: tests, a README listing your assumptions and trade-offs, and a short list of what you would change with more time. The final loop also includes written tests, and their format is not reported. As general preparation, practise writing Java or Python and SQL by hand, and ask your recruiter what the tests involve.

Acumen's work, as reported, includes integrations with outside services and data under security and compliance requirements. The reported design questions focus on integrations, enterprise scalability, and performance, security and privacy. Prepare idempotent retries, failure handling for partner APIs, access control, encryption and keeping personal data out of logs to the level of concrete mechanisms.

The Acumen interview process

Candidates report these four stages in this order, taking about 3-5 weeks in total. The reported questions are not tied to specific stages, so prepare all of them before the final loop.

Recruiter Screening

Candidates describe a first conversation with a recruiter about their background and role expectations. No technical questions are reported for this stage. The reported background question (how your experience matches the role) is the natural thing to have ready here. Use the call to learn the format of the next stages: whether your take-home will be a coding exercise or a data exercise, which languages you can use, what the review call covers, and what the written tests in the final loop look like.

What to demonstrate

• Background: candidates report this call covers it, so be ready to map your experience to the reported requirements (Java or Python, OOP, relational databases and SQL, web applications and APIs)
• Role expectations: also reported as a topic, so bring your own questions about level, work arrangement and the next stages

How to prepare

• Write a short pitch that moves from your current role to one or two relevant projects and then to why this role. Name the overlap with the requirements directly: Java or Python, SQL, APIs, and any data-analysis, healthcare or fintech experience.
• List your questions for the recruiter: take-home format (coding or data) and allowed language, whether there is a deadline, what the review call covers, and what kind of written tests the final loop includes.
• Prepare a two-sentence answer on why you want to work on software for financial management services and participant-directed programs.

Take-Home Assignment

Candidates report a practical coding assessment or take-home assignment. The reported methodology question calls it a take-home data or coding exercise, so it may be either kind. The next reported stage is a call reviewing your results, so treat the submission as something you will explain line by line. Spend your time first on correctness and edge cases, then on readable structure, then on a README that lists your assumptions, how to run the code, the trade-offs you made and what you would do next. If it is a data exercise, show your cleaning steps and justify any statistical claim with a test and an effect size, not only a chart.

What to demonstrate

• Clean code with robust error handling, which candidates report as part of coding and implementation
• Readable structure and tests or validation checks that show the result is correct
• Written reasoning (assumptions, trade-offs) that you can defend in the review call

How to prepare

• Set up a Java project (JUnit) and a Python project (pytest, pandas) in advance, so the take-home time goes into the problem rather than setup.
• Write a README template with sections for Assumptions, Approach, How to run, Testing, Limitations and Next steps. Run your submission from a clean checkout before sending it, as general good practice.
• Do one practice data exercise end to end: load a messy CSV, deduplicate it and fix its types, handle missing values, run one significance test and one multiple regression, and write three findings with their caveats.

Technical Review Call

Candidates describe this as a follow-up call to review the results of the take-home. The reported question asking you to walk through your take-home methodology step by step matches this stage's stated purpose. Before the call, re-run your submission from scratch and re-read every file. Prepare a short structured walkthrough (problem, assumptions, approach, validation, results, limitations), and be ready to explain or change any part of the code on request. Point out your own shortcuts before anyone else finds them, and say how you would fix each one.

What to demonstrate

• The reported purpose of the call is a review of your take-home results
• Whether you can explain and justify each decision in your own submission

How to prepare

• Rehearse the walkthrough aloud against the structure problem → assumptions → approach → validation → results → limitations.
• List three weaknesses in your submission, with the fix for each and its cost.
• Practise one change live: add an input validation rule, handle an input 100 times larger, or swap an O(n²) step for a hash-map lookup, then explain how the complexity changes.

Onsite/Virtual Loop

Candidates report several targeted interviews plus written tests, held onsite or virtually. Which question goes to which interview is not reported, and neither is the format of the written tests. Prepare all four reported groups: technical and domain knowledge (projects, language choice, string recursion, OOP, SQL), data analysis and coding (significance, preprocessing and model choice, optimization), system design (scalable enterprise components, integrations, performance, security and privacy) and behavioral. As optional preparation, practise writing code and SQL by hand and checking it by tracing small inputs.

What to demonstrate

• Clean code with robust error handling, which candidates report as part of coding and implementation
• Coverage of the four reported question groups across the several interviews and the written tests

How to prepare

• Hand-write the iterative and recursive string reversal, one class hierarchy, and three SQL queries (an anti-join, a latest-row-per-key query and an aggregate after a one-to-many join), then trace each on a small input.
• Rehearse the integration design aloud, covering idempotency keys, retries with backoff, a dead-letter queue and a reconciliation job.
• Prepare STAR stories for the three reported behavioral prompts, plus a project deep dive that covers architecture decisions and the alternatives you rejected.

Where candidates lose points

Writing the recursive string reversal with substring copies and calling it O(n), with no mention of stack depth

Practise the index-based recursive helper that swaps chars[i] and chars[j]. Be able to explain why substring recursion is O(n²), and say why recursion can overflow the stack on long input in Java or Python, which is why the iterative version is the one to ship.

Not being able to explain or change your own take-home on the review call

Re-run the submission from a clean checkout before the call and re-read every file. Prepare a list of your shortcuts with a fix for each, and rehearse one change live, for example scaling the input or adding a validation rule, so the review becomes a discussion rather than a defence.

SQL that inflates totals through a one-to-many join, or a NOT IN that silently returns nothing

Before writing a query, decide what one output row means. Aggregate child tables before joining them, and use NOT EXISTS for anti-joins. Check each query on a small example table of three or four rows, including a NULL and a duplicate key, before you trust it.

Calling a trend significant because the chart goes up, or quoting a p-value with no effect size or check of assumptions

For every claim, state the null hypothesis, the test you chose and why, the confidence interval and the effect size. Check independence, seasonality and confounders, and correct for multiple comparisons when you test many segments.

An integration design that retries failed calls with no idempotency, or that logs personal data in plain text

In any design involving partner APIs, cover idempotency keys, backoff with jitter, a dead-letter queue and reconciliation. Also say explicitly where personal and financial fields are encrypted, masked and kept out of logs.

Questions & practice

How would you write a function to reverse a string and then make your code recursive?

Medium · Technical & Domain Knowledge

Approach

1. Iterative version: Java Strings are immutable, so convert to a char array and swap with two pointers from both ends until they meet. That is O(n) time and O(n) extra space for the array. Mention that StringBuilder.reverse() is the library call, and in Python s[::-1].
2. A naive recursive version, reverse(s) = reverse(s.substring(1)) + s.charAt(0), copies a substring at every level. That makes it O(n²) time and O(n) stack depth. Say this before improving it.
3. Better recursive version: a helper reverse(chars, i, j) that swaps chars[i] and chars[j] and then recurses on (i+1, j-1), with base case i >= j. This is O(n) time and O(n/2) stack depth. Java does not optimize tail calls and Python's default recursion limit is 1000, so very long strings can overflow the stack. That is why the iterative form is the one to ship.
4. Edge cases: null (decide whether to throw or return null), the empty string, a single character, and even versus odd lengths. For Unicode, swapping Java chars breaks surrogate pairs such as emoji, while StringBuilder.reverse() keeps them together. Combining characters still need grapheme-aware handling.

Follow-up

• Reverse the order of the words in a sentence in place, without reversing the letters inside each word.
• Check whether a string is a palindrome, ignoring case and punctuation, using O(1) extra space.
• Why is the substring-based recursion O(n²)? Show the sum of the copy costs.

Can you walk through the step-by-step methodology you used in your take-home data or coding exercise?

Medium · Data Analysis & Coding Assessments

Approach

1. Structure the walkthrough: restate the problem and what counted as done, then your assumptions, how you inspected the input, the approach you chose and the alternatives you rejected, how the code or analysis is organized, how you validated it, the results, and the limitations.
2. For a coding exercise, give the complexity of the main path, explain why you chose each data structure, and name the edge cases your tests cover (empty input, duplicates, malformed records, very large input).
3. For a data exercise, list each cleaning step and how many rows it affected. Explain how you handled missing values and outliers, which test or model supports each claim, and the effect size and uncertainty behind each finding.
4. Before anyone asks, name your shortcuts and how you would fix them. Re-run the submission from a clean checkout before the call so nothing surprises you.

Follow-up

• What changes if the input is 100 times larger or arrives as a stream?
• Why did you use this library or approach instead of the obvious alternative?
• Change one requirement now: what in your code has to move?

How would you evaluate if a statistical claim or dataset trend is significant?

Medium · Data Analysis & Coding Assessments

Approach

1. Make the claim precise: which metric, compared with what, over what period. Then state the null hypothesis (no difference, or a slope of zero) and the alternative.
2. Choose the test from the data. For a difference in rates, use a two-proportion z-test or a chi-square test. For a difference in means, use Welch's t-test. Mann-Whitney U does not test means: it asks whether one group tends to give larger values, a shift in distribution or median. If the claim really is about means on skewed data, use a bootstrap confidence interval or a permutation test on the mean instead. For a trend over time, regress the metric on time and test the slope coefficient, or use a Mann-Kendall test for a monotonic trend.
3. Report a confidence interval and the effect size, not just a p-value. A large sample can make a trivial effect significant. A p-value is the probability of data at least this extreme if the null is true, not the probability that the null is true.
4. Check the assumptions: independence (time series are often autocorrelated, which understates the standard error), seasonality, sample size and power, and confounding or Simpson's paradox. Use a multiple regression with controls if other variables move with the trend.
5. If many metrics or segments were tested, correct for multiple comparisons (Bonferroni, or Benjamini-Hochberg for the false discovery rate).

Follow-up

• The p-value is 0.04 on one of twenty segments you tested. Do you believe it?
• How would you work out the sample size needed to detect a given change?
• In a multiple regression, how do you interpret a coefficient whose sign flips when you add a control variable?

How do you preprocess raw datasets and choose appropriate models or algorithms?

Medium · Data Analysis & Coding Assessments

Approach

1. Profile the data before changing anything: column types, row counts, duplicates, the share of missing values in each column, value ranges and category frequencies. Write down anything that looks wrong.
2. Clean in an order you can repeat. Fix types and parse dates, remove exact duplicates, then handle missing values by dropping rows, imputing the median or mode, or adding a missing-value indicator, depending on how much is missing and why. Investigate outliers before capping them, encode categoricals (one-hot for low cardinality), and scale features for distance-based or regularized models.
3. Split train and test before fitting any imputer, scaler or encoder, and fit them inside a pipeline. Otherwise test-set information leaks into training. Split by time if the data are temporal.
4. Choose the model from the target and the need to explain it. Start with linear or multiple regression for a numeric target, or logistic regression for a binary one, as interpretable baselines, and check collinearity with VIF. Move to tree ensembles only if they clearly beat the baseline on cross-validation.
5. Evaluate with metrics that fit the task: MAE or RMSE and R-squared for regression. For heavily imbalanced classification, report precision-recall AUC (average precision) alongside precision and recall at a chosen threshold. ROC-AUC can look optimistic when positives are rare, which matters when only 2% of rows are positive. Explain why accuracy misleads on imbalanced data.

Follow-up

• How would you detect target leakage in a feature?
• Two predictors are highly correlated. What does that do to your regression coefficients?
• Only 2% of rows are positive. What changes in your training and evaluation?

What steps would you take to improve or optimize a given code snippet or data pipeline?

Medium · Data Analysis & Coding Assessments

Approach

1. Measure before changing anything. Time the snippet, use a profiler (or EXPLAIN for queries) and find the step that dominates. Write tests that pin the current output so a refactor cannot change behavior unnoticed.
2. Fix the algorithm first. Replace a nested-loop lookup (O(n²)) with a HashMap or HashSet (O(n)). Do not concatenate Strings in a loop in Java (use StringBuilder). Do not re-sort or re-read data inside a loop, and cache results that are computed repeatedly.
3. Then fix I/O. Replace N+1 queries with one join or a batched IN query, push filters and aggregations into the database, add an index for the filtering column, and batch inserts.
4. For a pipeline, process only new or changed records instead of reloading everything. Make each step idempotent so a retry cannot duplicate rows, parallelize independent partitions, and add row-count and null-rate checks between stages.
5. State the trade-offs: memory against speed, added complexity and cache invalidation. Say how you would show the gain with the same benchmark and the same input.

Follow-up

• The code is fast now, but the database is the bottleneck. What next?
• How do you prove that the refactor did not change the output?
• One partition of the pipeline stops advancing while the others finish. How do you debug it?

Can you explain how you handle database queries, joins, and data manipulation in SQL?

Medium · Technical & Domain Knowledge

Approach

1. Start with the grain: decide what one output row represents, then join outward from that table. Explain the join types. INNER keeps only matches. LEFT keeps every row of the driving table. Find rows with no match with NOT EXISTS or a LEFT JOIN ... WHERE right.id IS NULL.
2. Name the fan-out trap. Joining a one-to-many table before SUM or COUNT duplicates the parent rows, so aggregate the child table in a CTE or subquery first and join the totals afterwards. Use COUNT(DISTINCT ...) only when you understand why duplicates appeared.
3. Know the core tools: WHERE filters rows and HAVING filters groups; ROW_NUMBER() OVER (PARTITION BY key ORDER BY ts DESC) gets the latest row per key; SUM() OVER gives running totals; COALESCE handles NULLs. NOT IN returns no rows if the subquery contains a NULL.
4. For data manipulation, run multi-statement changes in a transaction. Use an idempotent upsert (INSERT ... ON CONFLICT in PostgreSQL, MERGE elsewhere), and use bind parameters from application code so user input cannot inject SQL.
5. On performance, index the join and filter columns, read the plan with EXPLAIN, and know that wrapping an indexed column in a function, or comparing it with a mismatched type, can stop the index from being used.

Follow-up

• Write the query that returns each client's most recent transaction.
• Your totals doubled after adding a join. How do you find the cause and fix it?
• This join is slow on a large table. What do you check first in the plan?

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?

Can you explain your previous software projects and walk through the core architecture decisions you made?

Medium · Technical & Domain Knowledge

Approach

1. Choose one project you can describe in depth. Open with the context: who used it, roughly what load or data volume it handled, and its constraints (a deadline, compliance, a legacy system). Then describe the architecture in words: clients, services, data store, external integrations and how they communicate.
2. Present two or three decisions as trade-offs: the option you chose, the alternative you rejected and why. Examples: a relational database instead of a document store because the data had joins and needed transactions; a queue between the API and a slow partner call so user requests did not block.
3. Be clear about your own part. Say "I designed the retry layer" rather than describing the team's work as yours.
4. End with a result you can measure (latency, error rate, release frequency) and one decision you would now make differently, with the reason.

Follow-up

• What would break first if usage grew tenfold?
• How did you test and deploy it, and what went wrong in production?
• Which decision would you reverse today, and what would the migration cost?

Why is Java better than C, or how do you choose the appropriate programming language for a given problem?

Medium · Technical & Domain Knowledge

Approach

1. Reject the premise politely: neither language is better in general. Each fits different constraints, so the answer depends on the problem.
2. Java runs on the JVM with garbage collection, bounds-checked arrays, strong static typing, a large standard library and mature concurrency tools. That makes it a safer and faster-to-build choice for enterprise services, APIs and database-backed applications. The costs are JVM startup time, memory footprint and garbage-collection pauses.
3. C gives manual memory management, pointers, a minimal runtime and predictable low-level control, which suits operating systems, drivers, embedded devices and hot inner loops. The costs are buffer overflows, use-after-free bugs and slower development.
4. Give a decision procedure: performance and memory limits, safety requirements, available libraries and frameworks, the existing codebase and how it interoperates, and what the team knows. Close with an example: for a web service that talks to a relational database and partner APIs, you would choose Java or Python over C.

Follow-up

• How does garbage collection work in Java, and when do its pauses matter?
• When would you pick Python over Java for a backend service or a data pipeline?
• What does the JIT compiler do, and why does a Java service often get faster after warm-up?

What are your familiarity levels with object-oriented design principles and data structures?

Medium · Technical & Domain Knowledge

Approach

1. Give each OOP principle an example from your own code. Encapsulation: private fields with validated setters, or an immutable value object. Inheritance: a shared abstract base class. Polymorphism: one interface, several implementations chosen at runtime. Abstraction: callers depend on an interface, not a concrete class.
2. Show judgement about when to use each: composition over inheritance, interfaces for dependencies so they can be mocked in tests, and patterns you have actually used, such as Strategy for interchangeable rules, Factory for construction and Adapter for wrapping a third-party API behind your own interface.
3. For data structures, explain how access patterns drive the choice. ArrayList gives O(1) indexed access. HashMap gives O(1) average lookup and depends on a consistent equals/hashCode contract. TreeMap gives O(log n) lookup in sorted order. PriorityQueue is a heap for top-k problems. ArrayDeque serves as a stack or queue. HashSet handles deduplication.
4. Back your self-assessment with a quick example: model an invoice with line items and discount rules out loud, naming the classes, their fields and their responsibilities, and say which structure stores each collection.

Follow-up

• What breaks if you override equals but not hashCode?
• When would you use an abstract class instead of an interface?
• Describe a case where inheritance made a design harder to change, and how you would refactor it.

How do you approach designing a scalable system or component for enterprise software?

Medium · System Design & Architecture

Approach

1. Start with requirements, using a financial-management setting as the example. The users are clients, support coordinators and internal operations staff. A typical workflow is submitting a request, having it approved, and paying through a partner. Ask about volumes and growth, availability and latency targets, and compliance constraints on the data, and write the assumptions down before designing.
2. Describe a baseline that holds up: stateless application servers behind a load balancer so you can add instances, a relational database with indexes chosen for the main queries (the submit, approve and pay states), read replicas or a cache for read-heavy pages, and a queue with workers for slow jobs such as reports, bulk imports and the partner payment call.
3. Derive the enterprise concerns from those users. Role-based authorization separates what a client, a coordinator and an operations user can see or change. An audit log records who submitted, approved or changed each item. Per-client data isolation ensures one client never sees another's records. Schema migrations run without downtime (expand, then migrate, then contract).
4. Cover operations and failure: health checks and instances across availability zones, timeouts on every dependency (especially the partner), metrics, logs and alerts. Say what fails first as load grows (usually the database) and what you would do about it: query tuning, caching, replicas, and partitioning last.

Follow-up

• The primary database is at 90% CPU. What do you do this week, and what do you do this quarter?
• How do you change a column type on a large table without downtime?
• How do you stop one client from seeing another client's data?

How do you manage integrations with third-party platforms and internal APIs?

Medium · System Design & Architecture

Approach

1. Put each external platform behind its own adapter interface, so the rest of the code depends on your own domain model rather than the partner's schema. Keep the contract explicit (OpenAPI or a typed client), and keep credentials in a secrets manager with a rotation plan.
2. Make every outbound call safe to retry. Set a timeout, retry with exponential backoff and jitter only on retryable errors, and send an idempotency key so a timeout followed by a retry cannot apply a payment or record twice. Add a circuit breaker so a failing partner does not exhaust your threads.
3. Decouple with a queue for anything that does not need a synchronous answer. Failed messages go to a dead-letter queue with an alert and a replay tool. For inbound webhooks, verify the signature, deduplicate by event id and return quickly.
4. Keep a separate status for each stage (submitted, accepted, failed, confirmed), and run a scheduled reconciliation job that compares your records with the partner's and flags differences.
5. For internal APIs, version the contract, put correlation IDs in logs across services, run contract tests in CI and test in a partner sandbox before release.

Follow-up

• Your request to the partner timed out. Did it go through, and how do you find out?
• The partner changes a field format without notice. What catches it, and what limits the damage?
• How do you replay a day of failed messages without creating duplicates?

What factors do you consider when ensuring system performance, security, and data privacy?

Medium · System Design & Architecture

Approach

1. Performance: define latency and throughput targets first, then use profiling and EXPLAIN to find hot paths. Add indexes, pagination, caching with a clear invalidation rule and asynchronous processing for slow work, and load-test before launch rather than after.
2. Security: authenticate every caller, authorize every request against roles (least privilege), validate input and use bind parameters to block injection, keep secrets out of code, patch dependencies, and work through the OWASP Top 10 for web applications.
3. Data privacy: classify which fields are personal or financial, collect only what the feature needs, and encrypt in transit (TLS) and at rest. Mask or encrypt sensitive fields, keep personal data out of logs and analytics, use masked data outside production, and enforce retention and deletion rules.
4. Accountability: audit-log access to sensitive records, alert on unusual access, and limit who can query production. Name the tensions, such as caching sensitive data versus re-checking permissions, or field encryption versus searchability, and say how you would resolve each one.

Follow-up

• Where exactly would you encrypt a client's bank details, and who holds the key?
• How do you stop personal data from appearing in application logs?
• A cached response contains data the next user is not allowed to see. How did that happen, and what is the fix?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

Each day of the plan covers one group of reported Acumen questions or one reported stage. The order runs from fundamentals and SQL, through statistics and a rehearsal of the take-home, to integration design and a mock loop.

Day 1 — Background, projects and language choice

• Write your background pitch, mapping your experience to Java or Python, OOP, SQL, APIs and any data-analysis work.
• Write up one project deep dive: context, a description of the architecture, three decisions with the alternative you rejected for each, and one thing you would change.
• Write a Java-versus-C comparison covering memory management, safety, runtime cost and suitable domains, plus a procedure for choosing a language.

Deliverable: A background pitch, a one-page project deep dive and a language-choice comparison you can say aloud.

Day 2 — Coding fundamentals by hand

• Hand-write the iterative two-pointer string reversal and the index-based recursive version, then trace both on "", "a" and "abcd".
• Write the naive substring-based recursion and work out its O(n²) cost, then test where recursion overflows the stack in Java or Python.
• Model an invoice with line items and discount rules as classes using an interface and the Strategy pattern, and pick a collection for each field.

Deliverable: Two hand-written reversal functions with traces, a complexity note, and an annotated class sketch.

Day 3 — SQL joins and data manipulation

• Write and run an anti-join, a latest-row-per-key query with ROW_NUMBER, and an aggregate that avoids one-to-many fan-out.
• Reproduce the NOT IN with NULL trap on a tiny table and fix it with NOT EXISTS.
• Work through the practice question on why a filter ignores an index, and write down what makes an index unusable.

Deliverable: Three working queries, a NOT IN demonstration with its fix, and a note on index usage.

Day 4 — Statistics, regression and preprocessing

• On a public dataset, run a two-proportion test and Welch's t-test, then report the p-value, the confidence interval and the effect size for each.
• Fit a multiple regression, read its coefficients, p-values and R-squared, and check collinearity with VIF.
• Build a preprocessing pipeline (types, duplicates, missing values, encoding, scaling) that is fitted only on the training split.

Deliverable: A notebook with two tests, one interpreted regression and a pipeline that does not leak test data.

Day 5 — Take-home rehearsal and optimization

• Do a practice take-home end to end in Java or Python, with tests and a README covering assumptions, trade-offs and next steps.
• Rehearse the walkthrough aloud: problem, assumptions, approach, validation, results, limitations.
• Profile a slow snippet, fix one algorithmic problem and one I/O problem, then work through the practice question on a stalled log partition.

Deliverable: A finished practice submission, a rehearsed walkthrough and a before-and-after benchmark.

Day 6 — Enterprise and integration design

• Design a service that syncs records with a third-party API, covering an adapter, idempotency keys, retries, a dead-letter queue and reconciliation.
• Extend the design to cover scale: stateless servers, read replicas, a cache, a queue for slow jobs and migrations without downtime.
• Add a security and privacy pass: role-based access, TLS and encryption at rest, field masking, keeping personal data out of logs, and audit logging.

Deliverable: One design diagram with written notes on failure handling, scaling and data protection.

Day 7 — Behavioral stories and a mock loop

• Write STAR stories for cross-functional work and for ambiguity, each including a real disagreement or a change of priorities.
• As optional practice for the written tests, hand-write one coding function and two SQL queries, then check them by tracing a small input.
• Run a mock loop with a friend covering one technical, one design and one behavioral question.

Deliverable: Two STAR stories, a checked set of hand-written answers and notes from the mock loop.

Behavioural preparation

The reported behavioral questions for this role cover three things: how your background matches the requirements, how you work with cross-functional colleagues and manage stakeholder expectations, and how you cope with ambiguity and changing priorities. Prepare stories from engineering work that involved non-engineers, such as product, QA, implementation or operations staff. Each story should include a decision you made, a disagreement or trade-off, and a result you can state.

1. Can you explain your previous software projects and walk through the core architecture decisions you made?

Can you tell me about your background and how your experience aligns with this role?

Medium · Behavioral & Background

Approach

1. Use a present → past → future shape: what you do now, one or two earlier experiences that show the skills this role lists, and why this role is the next step. Do not recite your CV in order.
2. Map your experience to the reported requirements explicitly: Java or Python, object-oriented design, relational databases and SQL, web applications and APIs, cloud platforms. Add healthcare, fintech, enterprise SaaS or data-analysis experience if you have any.
3. Include one concrete result: a system you built or an integration you delivered, with a number attached.
4. Close with a specific reason for Acumen: you want to build software for its financial management services and participant-directed programs. Avoid a generic line about wanting to grow.

Follow-up

• Which of the requirements is your weakest, and what are you doing about it?
• Why are you leaving your current role?
• What kind of work would you want to own in your first months?

How do you approach collaborating with cross-functional teams and managing stakeholder expectations?

Medium · Behavioral & Background

Approach

1. Use STAR with one real project in which you worked with non-engineers such as product, QA, implementation or operations staff, and in which expectations had to be managed (scope, a date or a technical limit).
2. In the Action part, show how you turned a technical constraint into its effect on the business, offered options with costs rather than a flat no, raised a risk early instead of at the deadline, and wrote down what was agreed.
3. Include a real disagreement and how you settled it: with data, a prototype or an agreed decision owner. Do not settle it by giving way silently or by going over someone's head.
4. End with a result and what you now do by default because of it. The mistake that sinks this answer is a story with no tension, in which everyone simply agreed.

Follow-up

• Tell me about a time you had to say no to a stakeholder. How did they react?
• How do you keep non-technical stakeholders informed during a long project?
• What would you do if a stakeholder kept changing requirements after work had started?

How do you handle ambiguity or shifting priorities in a fast-paced development environment?

Medium · Behavioral & Background

Approach

1. Pick a story where requirements were unclear or changed partway through, and where you acted rather than waited.
2. Show the steps: find out the goal behind the request, write down your assumptions and confirm them, build the smallest useful piece to get feedback, and re-plan openly when priorities moved, stating what the switch would cost in time and unfinished work.
3. Explain how you protected quality while moving fast: what you would not cut (tests on the risky path, data integrity), and what you put off on purpose and recorded.
4. Give the outcome and the lesson. Avoid stories that blame the people who changed direction. Changing priorities should come across as normal work that you handled well.

Follow-up

• What did you deliberately not do because priorities changed, and how did you communicate that?
• When is it right to push back on a priority change instead of accepting it?
• How do you decide what to build when nobody can tell you the requirements?