What to expect
A customer changes an address and receives a revised quote. Before accepting it, another update changes the underlying policy information. Which version is being accepted, and can the service explain the difference? This is a useful software exercise for an insurance setting because correctness depends on time, versioning, and an auditable customer journey.
The official Acuity careers page identifies the insurance business and its focus on serving policyholders. Acuity Insurance is distinct from Acuity Brands and Acuity Insights. Use the exact employer and job description to determine whether your opening concerns policy systems, claims, customer applications, data, or another team.
The examples below are invented engineering exercises. They do not specify insurance coverage, underwriting rules, legal obligations, or Acuity's internal stack. This guide does not establish a current sequence of engineering interviews. Prepare to ask which technical format and business area apply to your opportunity.
Focus on business state, not just CRUD
An insurance workflow is a useful setting for demonstrating that a stored row has meaning beyond its latest field values. A draft, a quoted proposal, and an accepted change are different states. A past version may matter even after a newer one exists. In a design answer, identify the business event that makes a transition authoritative.
Prepare one project where correctness mattered more than immediate visual feedback. Explain how you made a workflow resumable, kept a history of decisions, or prevented a stale client from replacing newer data. If the role is frontend-focused, practise a clear review-and-confirm screen; if it is backend-focused, practise conditional updates and versioned data.
Coding case: select an effective configuration
Original practice exercise: a list of configuration records contains an identifier, an effective start, an effective end, and a value. Given time t, find the single record whose half-open interval contains t. Return no result for a gap and an explicit conflict for overlap. The values are synthetic configuration data, not policy advice.
For intervals [0,10) and [10,20), t = 10 selects the second record. At t = 20 there is no match. For [0,15) and [10,20), t = 12 is a conflict; selecting whichever record appears last would conceal invalid configuration.
A scan can track zero, one, or more matching records in O(n) time with constant additional state. If intervals are guaranteed sorted and non-overlapping, binary search is an optimisation, but the guarantee must be validated when configuration is published. Do not use the optimisation as a reason to ignore invalid input.
Test gaps, overlaps, exact boundaries, empty input, invalid end-before-start intervals, and records provided out of order. Decide how open-ended intervals are represented. If the caller provides a local time without an offset, ask for the intended interpretation rather than silently converting it.
For a follow-up, introduce a configuration change recorded today but effective yesterday. This creates two notions of time: when a rule applies and when the system learned it. Explain how you would reproduce a prior result using the information available at the time. The exercise becomes a version-history problem, not simply a lookup against the newest row.
SQL case: report the latest recorded policy version
Assume policy_versions(policy_id, version, status) with unique pairs of policy and version. Find the latest recorded version for every policy, including the status on that exact row.
SELECT p.policy_id, p.version,
p.status
FROM policy_versions AS p
WHERE NOT EXISTS (
SELECT 1
FROM policy_versions AS newer
WHERE newer.policy_id
= p.policy_id
AND newer.version > p.version
)
ORDER BY p.policy_id;
This query answers “latest recorded,” not “effective at a historical date.” Keep those meanings distinct. Test a policy with versions 1 and 3, another with only version 2, and a newer version whose status differs from the older one. Grouping by policy and selecting an unrelated status can accidentally combine values from different rows.
Discuss a composite index on the identifier and version in the context of a query plan and expected workload. If deleted or superseded records exist, define their meaning before filtering them out. The reporting contract should be understandable to someone outside the database team.
Design case: a versioned quote-and-accept workflow
Start with an immutable quote snapshot containing the input version, calculation version, result, and expiry. For this exercise, acceptance must reference that exact quote identifier. Recomputing against whatever data happens to be current at acceptance time would make the user's confirmation ambiguous.
When an input changes, create a new quote or require a refresh. State whether the old quote remains valid; that is a business rule to obtain, not an engineering assumption to hide. The interface should show the change clearly before confirmation and provide a durable reference afterwards.
Use a transaction or equivalent conditional operation to validate the quote's state and record acceptance. Two repeated requests for the same acceptance should return the same result rather than create two downstream actions. If the client loses its connection after commit, it should be able to recover using an idempotency key or acceptance identifier.
Treat notifications, documents, and external updates as follow-on work with their own statuses. A failed email does not mean an acceptance failed. A document-generation failure should be visible and retryable without repeating the business transition. Separate the authoritative state from its presentations.
Keep a controlled audit trail of versions and transitions, while avoiding unnecessary customer data in logs. In a test environment, use synthetic examples. Explain role-based access, tenant or account checks, and how support staff can trace a case without gaining broad access to unrelated records.
Debugging: the confirmation shows a different result
Gather the quote identifier, displayed input version, accepted version, and document version. Compare the calculation configuration used at each stage. Do not begin by assuming a numerical rounding defect: a stale quote or wrong version reference can produce an apparently plausible but incorrect result.
Identify whether the difference existed before acceptance or appeared during document rendering. If the authoritative result is correct but the presentation is stale, regenerating the document may be appropriate; if the wrong quote was accepted, a different controlled correction is needed. Name the responsible business decision rather than treating every discrepancy as a cache refresh.
Prevent recurrence with tests for input changes between quote and acceptance, duplicate acceptance requests, quote expiry, and downstream document retries. Verify the whole user journey with a stable identifier across each component.
Behavioral preparation and recruiter questions
Prepare a story about a requirement that changed after implementation began. Explain how you clarified which existing records or users were affected, documented the decision, and tested both old and new behaviour. A second useful story concerns a defect where technical correctness and customer communication needed coordination.
Ask which business workflow the team owns, how releases are tested against historical cases, and who defines effective-date rules. Ask about the confirmed interview format separately; business context does not establish whether there will be live coding, a take-home task, or an architecture discussion.
Your practice deliverables
Create the interval lookup, the latest-version query, and a quote-to-accept sequence with a retry path. Add two synthetic cases in which input changes between screens. Be able to explain what the customer confirmed and how the service can prove it later.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Acuity Insurance'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 effective intervals 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 accepted quote snapshot and its rule version visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate an effective-date change between quote and acceptance. 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 confirmation differs from the price the user accepted. 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 Acuity Insurance 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 Acuity Insurance.