What to expect
An order is cancelled just as a warehouse begins fulfilment. The order-management screen says cancelled, but a shipment label has already been created. Which action is still reversible, and how do the systems converge? This is a useful Acuver Consulting preparation scenario because supply-chain software lives between independent systems and physical operations.
Acuver Consulting describes order management, warehouse management, and software engineering services. Its order-management page provides an omnichannel fulfilment context. Those sources support choosing supply-chain examples; they do not establish a specific client assignment, technical stack, or interview loop.
The cases below are original practice exercises, not reported company questions or a map of Acuver's production systems. Confirm whether the opening focuses on implementation, custom development, quality engineering, or managed services before deciding how much time to spend on each area.
Think in state transitions and ownership
An order, a reservation, a pick task, and a shipment are different entities. Each may have a different owner and lifecycle. A strong design answer explains which system can authorise a transition and which systems merely display it. “Sync the status” is incomplete unless you define whose status wins and why.
Prepare one example of coordinating a change across teams or services. Describe the contract, what could fail independently, and how you reconciled partial progress. This is relevant even if your previous domain was not retail: the reasoning transfers, while the business assumptions must be restated.
Coding case: choose a warehouse for a complete order
Original practice exercise: each warehouse has stock by SKU, a distance score, and an identifier. Choose the nearest warehouse that can fulfil the entire order. Break distance ties by identifier. Combine repeated order lines before checking stock. If no warehouse can fulfil the whole order, return no candidate; split fulfilment is outside this first contract.
For an order A:2 and B:1, a nearby warehouse with A:5 but B:0 is ineligible. A more distant warehouse with A:2 and B:1 is eligible. If another eligible warehouse has the same distance, the identifier rule makes output reproducible.
Aggregate the order, scan each warehouse, and check every required SKU. With W warehouses and K distinct requested SKUs, a direct solution takes O(W × K) checks after aggregation. You can retain the best candidate without sorting all warehouses. Test exact stock, missing SKUs, duplicate lines, no candidate, ties, and input order changes.
The function selects a candidate from a snapshot; it does not reserve stock. State that distinction before discussing concurrency. A production workflow must attempt an authoritative reservation and handle a failure if another order consumed stock after the read.
When asked to support split shipments, obtain the objective. Minimising shipment count, distance, delivery time, and cost can produce different answers. Do not quietly extend a greedy nearest-warehouse rule and call it optimal for every objective. Work through a small counterexample and explain the chosen tradeoff.
SQL case: identify orders with no shipment record
Assume orders(id, state) and shipments(id, order_id). Find orders marked shipped but with no related shipment record.
SELECT o.id
FROM orders AS o
WHERE o.state = 'shipped'
AND NOT EXISTS (
SELECT 1
FROM shipments AS s
WHERE s.order_id = o.id
)
ORDER BY o.id;
This is a consistency check under the exercise's state contract. Test a shipped order with a shipment, a shipped order without one, and an unshipped order without one. If one order can have multiple shipments, existence alone does not prove that all lines shipped. A line-level completeness report needs quantities and the correct join grain.
For operations, include the state-change timestamp and an agreed propagation window before alerting. Otherwise ordinary asynchronous delivery will look like corruption. Distinguish delayed records, rejected shipments, and invalid transitions in the discrepancy output.
Design case: reservation, fulfilment, and cancellation
Begin with an order state machine and a separate reservation state machine. For the exercise, an order cannot be confirmed until stock is reserved. Every transition has an identifier and version so a repeated message cannot advance the same state twice.
Send fulfilment work through a durable handoff. A warehouse acknowledgement means the work was accepted, not necessarily completed. Define the later events that indicate picking, dispatch, and delivery. Keep an audit trail linking them to the originating order and line items.
Cancellation is a request that may race with irreversible progress. At each stage, define what can still be cancelled and what becomes a return or exception workflow. If the warehouse is unreachable, do not label cancellation complete merely because the order service recorded the request. Show pending resolution and reconcile when communication returns.
Use compensating actions for operations that cannot share one database transaction. Releasing a reservation is different from deleting an order history. A compensation can itself fail, so it needs status, retry policy, and ownership. Saying “roll back everything” is not enough across independent systems.
For omnichannel views, allow search and status screens to use derived data while preserving an authoritative decision point for commitments. Explain how sequence numbers, timestamps, and reconciliation prevent a late status event from restoring an obsolete state.
Debugging: a cancelled order still ships
Trace the cancellation request, reservation release, warehouse command, and dispatch event. Compare which system knew about cancellation at each point. Was the shipment already irreversible, was the event delayed, or did an old version overwrite the cancellation state?
Separate a genuine business race from a software defect. The recovery path may involve an exception workflow rather than pretending the shipment never happened. Preserve the timeline and communicate the confirmed state to the responsible users.
Add tests that cancel before reservation, after acceptance by the warehouse, during an outage, and after dispatch. Include duplicate cancellation messages and out-of-order updates. A useful post-incident change makes the pending state visible and gives operators a bounded reconciliation queue.
Client communication and technical judgment
Prepare a story about making a requirement concrete across teams. Describe how you converted “real-time inventory” into a specific freshness target or “cancel immediately” into stage-dependent behaviour. Show how you recorded the agreement and tested it with representative scenarios.
Ask which system owns order state, how implementations are tested against client workflows, and how support handles reconciliation. If a product or platform is named in the posting, connect your examples to it; do not assume that every project uses the same vendor stack.
Your practice deliverables
Build the warehouse selector, the shipment-consistency query, and a cancellation sequence with an outage. Add one deliberate partial-failure case and show how an operator would detect and resolve it without losing order history.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Acuver Consulting'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 warehouse selection 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 warehouse acknowledgement and order transition history visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate a cancellation racing with warehouse shipment. 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 a cancelled order ships because two systems disagree. 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 Acuver Consulting 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 Acuver Consulting.