What to expect
A bank-facing integration times out after accepting a request. The caller retries, but the original request may already have been processed. Can your service distinguish a missing response from a missing operation? This is a useful Acute Informatics practice scenario because integration correctness depends on more than receiving an HTTP success code.
Acute Informatics' published company profile describes a core-banking context. The document is historical; it should not be used to infer a current customer, vacancy, stack, or interview sequence. Confirm the current role directly, especially whether it is software development, implementation, or support.
The examples here use synthetic transaction records to practise deduplication, reconciliation, and diagnosis. They are not financial instructions or a specification for a real banking platform. Employer-specific rounds and coding tests were not established by the sources reviewed for this guide.
Build confidence in data and integration fundamentals
Prepare to explain object modelling, database transactions, error handling, and API contracts in one coherent example. A strong answer distinguishes a request, an accepted business operation, a posted record, and a notification. Those states may occur at different times and should not be compressed into a single success flag.
Ask which databases and programming languages the opening names, how production support is shared, and whether an assessment involves existing code or greenfield implementation. For an implementation role, practise reading a mapping specification and identifying ambiguous fields. For a developer role, practise writing small functions and tests rather than only describing tools.
Coding case: reconcile two transaction exports
Original practice exercise: two files contain records with transaction identifier, amount in integer cents, and currency. Compare them by identifier and report missing-left, missing-right, and mismatched-value records. Duplicate identifiers inside either file are invalid and must be reported separately.
Use A:100 USD and B:200 USD in the first file, and A:100 USD plus B:250 USD plus C:50 USD in the second. A agrees, B differs, and C is absent from the first file. Adding another A row must not silently overwrite the earlier one in a map.
Build a map for each side while validating uniqueness. Compare the union of identifiers and classify each one. The expected time is O(n + m), with O(n + m) storage for two in-memory files. State what changes for larger files: sorting and merge comparison, external storage, or partitioned processing may be needed.
Do not add amounts across currencies. Equality requires both the amount and currency to match under the exercise contract. Decide whether leading zeros or case differences in identifiers are meaningful before normalising them. An aggressive cleanup step can merge distinct business records.
Test empty files, duplicate identifiers, changed currency, zero amounts, negative adjustments if allowed, and a row present on only one side. Preserve the original values in the discrepancy output so an operator can investigate without reconstructing the input from memory.
SQL case: find duplicate import identifiers
Assume imports(batch_id, txn_id, amount_cents) stores raw imported rows. Identify repeated transaction identifiers within the same batch.
SELECT batch_id, txn_id,
COUNT(*) AS row_count
FROM imports
GROUP BY batch_id, txn_id
HAVING COUNT(*) > 1
ORDER BY batch_id, txn_id;
A transaction appearing once in each of two batches is not a duplicate under this query's definition. That may be a replay requiring a separate cross-batch check. Define the uniqueness scope explicitly: source, account, business date, and operation type may all matter in a real system.
This query detects repeated identifiers but does not choose which row to trust. If duplicate rows disagree, surface the conflict. Selecting an arbitrary row or summing duplicates can make the report appear clean while damaging correctness downstream.
Design case: receive and reconcile an external operation
At intake, authenticate the caller and validate the payload. Give each logical request a stable identifier scoped to its origin. Persist the accepted request and its state before acknowledging durable acceptance. Define whether a repeated identifier with an identical payload returns the existing result and how a changed payload is rejected.
Separate request status from downstream posting status. A timeout while contacting another system leaves an uncertain outcome, not necessarily a failed operation. Before retrying, use the downstream system's supported status lookup or idempotency mechanism. If neither exists, describe the need for reconciliation and controlled human resolution rather than claiming retries are automatically safe.
Keep an immutable record of the request and versioned processing attempts. Store enough information to correlate the source identifier with a downstream identifier. Logs should support that trace without becoming an uncontrolled copy of sensitive account details. Use synthetic data for tests and examples.
Define a reconciliation process that compares accepted requests with downstream results. Group discrepancies by known failure states, unknown outcome, and processing delay. An item still within the agreed latency window should not be classified the same way as one stranded overnight.
Design replay as a deliberate operation with a bounded scope and visible results. Reprocessing an input should not repeat a completed business action. The replay path needs the same guards as normal processing; bypassing them because the work is “administrative” creates another route to duplicate side effects.
Debugging: two records disagree after a timeout
Start with the source request identifier and trace the timeline of attempts. Was there one logical request with multiple transport attempts, or did the caller generate a new identifier on every retry? Compare the accepted payload, downstream lookup, and reconciliation outcome.
Check the boundaries where data was transformed. A decimal separator, sign convention, currency code, or timestamp interpretation can create a mismatch without any transport failure. Reproduce one record through the mapper and inspect the exact output before investigating system-wide throughput.
For recovery, produce a discrepancy list with identifiers and classified causes. Do not automatically repost uncertain operations. Explain how the responsible operational owner can confirm the outcome, and which test or contract change would make the same uncertainty less likely next time.
Explain your support and delivery judgment
Prepare a story about diagnosing a defect with incomplete information. State how you narrowed the scope, preserved evidence, and communicated uncertainty. A second story should explain a change that required coordination between developers and a client or operational team.
Ask how environments differ, what automated integration tests exist, how test data is managed, and who approves data corrections. These questions help you understand the role while keeping your interview answer grounded in engineering decisions you can actually support.
Your practice deliverables
Create the two-file reconciler, a duplicate-import report, and a request-state diagram that includes an unknown outcome. Then practise explaining why retrying a transport request and repeating a business operation are not always equivalent.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Acute Informatics's hiring timeline. Adjust it to the current job description and the time you actually have. If the recruiter confirms a different emphasis, move time toward that assessment instead of completing every exercise mechanically.
Days 1–3: turn the coding case into an executable contract
Implement the file reconciliation exercise in your strongest interview language. Before coding, write the input shape, invalid-input policy, tie-breaking rule, and expected output. Keep one deliberately small example that you can trace by hand. Add a test for each boundary described in the exercise rather than relying on a large random input to discover mistakes.
After the first working version, explain why your chosen data structure fits the operations you need. State both time and space costs, including retained retry history or copied state where relevant. Then change one requirement and identify which assumption breaks. Your goal is to demonstrate controlled reasoning when a problem changes, not to memorise one implementation.
Days 4–5: prove the SQL result on a tiny dataset
Create the tables used in the SQL case and insert a normal record, a missing-related-record case, and a duplicate or irrelevant record. Predict the output before executing the query. Check whether the result is one row per entity or one row per event, and whether null means missing data, unknown state, or a legitimate business value.
Explain how a join can multiply rows and why filtering a joined table in the wrong place can remove the very records you are looking for. For performance, begin with the lookup keys and expected access pattern; inspect an execution plan before promising that an index will solve the problem. Keep correctness and performance as separate review questions.
Days 6–9: draw the state boundary and break it
Use the architecture diagram as a starting point, then mark the operation that must be atomic. Write down what the caller is entitled to believe after a success response. For this case, make the stable transaction identifier and downstream status visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate a downstream timeout after the operation committed. Record the state before the failure, the durable evidence after it, and the next action each component takes. A useful recovery story explains how the system distinguishes an incomplete operation from a completed operation whose response was lost. It also states what an operator can inspect without making the incident worse.
Days 10–12: practise diagnosis and communication
Rehearse the incident where two transaction exports disagree after a retry. Give yourself a short log extract or a handful of records rather than omniscient knowledge of the bug. Separate observations from hypotheses. Name the first query or trace you would inspect and explain which competing explanations its result would rule out.
Prepare one experience from your own work that demonstrates similar judgment. Describe the constraint, the decision you personally made, and the evidence that the change helped. If you do not have production experience, use a course or personal project honestly and explain the additional controls a production deployment would require.
Days 13–14: run a mock and repair the weakest answer
Spend one session on coding and another on design. Ask your mock interviewer to challenge a hidden assumption rather than only checking the final answer. Afterward, choose one specific weakness: unclear failure semantics, an untested boundary, an ambiguous schema, or an explanation that begins with tools before requirements. Revise that artifact and run the same scenario again.
Frequently asked questions
Are these verified Acute Informatics interview questions?
No. The coding, SQL, and design cases are original preparation exercises informed by the company's public business context. The linked sources establish that context; they do not verify that these prompts appeared in an interview. Use any current recruiter instructions as the authority for your actual assessment format.
Which language should I use?
Use a language in which you can implement and test the exercise clearly, unless the current role or assessment specifies one. Practise explaining your standard library choices and failure handling. A company product page is not enough evidence to infer the language required in an interview.
What should I prioritise if I have only a weekend?
Complete one tested coding solution, run the SQL example against a tiny fixture, and walk through the failure scenario above. Then prepare two concise project stories and questions about the actual team. A small set of defensible answers is more useful than superficial familiarity with every possible technology.
For broader practice, use the PracHub Software Engineer question bank. Its questions are general role practice and should not be treated as verified questions from Acute Informatics.