What to expect
A shopper orders a particular product variant while an inventory import arrives from a warehouse. The storefront reports availability, but fulfilment rejects the order. A useful Acushnet preparation exercise is to trace the difference between product identity, sellable inventory, reservation, and shipment.
The official Acushnet employment site identifies Acushnet as the home of Titleist and FootJoy. Its locations page shows a manufacturing and business footprint. Those facts support a product-and-operations context; they do not confirm which systems a particular Software Engineer team builds or how it interviews candidates.
This guide uses an invented product availability and fulfilment scenario. It is appropriate preparation if the opening involves commerce, enterprise applications, or integrations. For a different technical specialism, use the job description to replace the scenario rather than presenting it as an actual Acushnet architecture.
Prepare for the boundary between products and systems
Distinguish a product family from a stock-keeping unit. A parent product can be available while one specific size, colour, or configuration is not. That distinction affects schemas, APIs, caches, and user messages. In an interview, state the entity you are counting or reserving before discussing scale.
Ask whether the role is focused on customer-facing applications, manufacturing systems, enterprise integration, or data. Prepare a relevant story about moving information between systems with different definitions. Demonstrate how you caught a mapping problem before it reached users, and how you recovered when the upstream data changed.
Coding case: reserve a basket atomically in memory
Original practice exercise: given an inventory dictionary and a list of basket lines, produce an updated inventory if every requested quantity is available. Repeated lines for the same SKU must be combined. Reject the whole basket if any line is invalid or insufficient, and leave the original inventory unchanged.
For stock A = 5 and B = 2, basket lines A:2, A:2, B:1 leave A = 1 and B = 1. A:3 plus A:3 must fail even though each individual line would pass against the original stock. That example exposes why validation has to consider the combined quantity.
A clear solution first aggregates requested quantities by SKU, then validates all totals, and finally applies them to a copied dictionary. Its expected work is O(n + s), where n is the number of basket lines and s the number of stock entries copied. If you return only a change set, explain how the caller applies it atomically rather than silently claiming the same space cost.
Test an empty basket, repeated SKUs, exact depletion, an unknown SKU, zero or negative quantities, and failure after another line would have succeeded. The input must remain unchanged on failure. Returning a partially modified inventory is a common correctness bug disguised as progress.
Then distinguish this exercise from a live reservation service. A copy of a dictionary does not protect against concurrent orders or process failure. In production, define storage-level concurrency, reservation expiry, and what makes a reservation confirmed. Avoid treating a successful availability read as a guarantee that stock remains available a moment later.
SQL case: compare stock with active reservations
Assume stock(sku, on_hand) has one row per SKU and reservations(id, sku, qty, status) contains reservations. Calculate an available quantity using only active reservations, including SKUs with none.
SELECT s.sku,
s.on_hand - COALESCE(
SUM(r.qty), 0
) AS available
FROM stock AS s
LEFT JOIN reservations AS r
ON r.sku = s.sku
AND r.status = 'active'
GROUP BY s.sku, s.on_hand
ORDER BY s.sku;
Test stock with an active reservation, a released reservation, and no reservations. Decide whether negative availability is an error to expose or a value to clamp in a particular interface; silently clamping it in the source report can conceal overselling.
If inventory is partitioned by warehouse, both the schema and aggregation must include that dimension. Joining SKU totals to multiple warehouse rows can multiply reservations. Explain the data grain and include a fixture with one SKU at two warehouses before using the query in a broader design.
Design case: synchronise product availability
Give catalog data and inventory data separate ownership. A catalog service answers what the product is; inventory and reservation logic answer whether a specific quantity can be committed. Search may use an approximate availability view, while checkout requires a fresh authoritative decision.
Define an inventory import version or source sequence. An old file arriving after a newer one must not restore obsolete stock. Preserve the imported snapshot and its interpretation so a discrepancy can be traced to a source row. Validate duplicate SKUs, unknown warehouses, and malformed quantities before replacing a current view.
Model reservations with explicit states such as active, confirmed, released, and expired. These are exercise states, not company facts. A timeout in the payment or order flow should not leave inventory reserved forever. Conversely, retrying a confirmed order must not reserve the same stock twice.
Keep an order identifier stable through reservation and fulfilment. If the warehouse rejects a shipment request, distinguish “request delivered” from “accepted for fulfilment.” Record the rejection reason and route it for recovery rather than assuming that message delivery completes the order.
Design the user experience for uncertainty. A product page can say an item is available, but checkout should explain a changed quantity clearly and preserve the rest of the basket. A generic failure screen is less helpful than a recoverable choice tied to the affected variant.
Debugging: only one variant keeps overselling
Choose a failing SKU and follow its catalog identity, warehouse mapping, import history, reservations, and orders. Check whether two source identifiers collapse into one SKU or whether a product-level cache is being reused for all variants. A bug limited to one variant often points to mapping or granularity before it points to database throughput.
Compare the stock update sequence with reservation creation. Determine whether an import overwrites on-hand data while ignoring outstanding commitments, or whether a retry creates duplicate reservations. Reproduce the race with two simultaneous requests or reversed import order.
Contain the affected variant using the agreed operational process and reconcile the records before replaying imports. Add tests for duplicate lines, late files, concurrent reservations, and fulfilment rejection. Explain which metric would detect a recurrence without relying on customer complaints.
Project stories that show practical ownership
Prepare a story about discovering a mismatch between two systems' identifiers or states. Describe the example that made the defect obvious, the mapping you changed, and the test that prevented recurrence. A second story can focus on a release coordinated with non-engineering users who depend on predictable workflows.
Ask which systems own product and inventory data, how changes are rolled out during busy periods, and what support responsibilities belong to the role. Connect questions to the job description rather than assuming a particular enterprise software vendor.
Your practice deliverables
Build the all-or-nothing basket function, check available stock with the SQL example, and draw a reservation lifecycle. Extend the exercise to two warehouses or a partial shipment only after specifying the changed promise to the customer.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Acushnet'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 atomic baskets 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 SKU reservation and warehouse acknowledgement visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate two baskets reserving the last unit of one variant. 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 one size oversells while other variants look healthy. 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 Acushnet 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 Acushnet.