What to expect
A candidate finishes an assessment, sees a receipt, and closes the browser. Minutes later, one response is missing from the review queue. A useful Acuity Insights preparation question is how you would make that submission durable, traceable, and understandable to both the candidate and the reviewer.
Acuity Insights describes admissions, assessment, program-management, and education analytics products. Its assessment help page explains that Casper responses are scored by human raters. These product facts suggest relevant preparation around workflows, access boundaries, and data quality. They do not establish the company's engineering interview format or make Casper a confirmed assessment for software applicants.
This guide's exercises use an invented submission-and-review service. They are engineering practice, not a description of the company's scoring algorithm, fairness methodology, or proprietary assessment content. Keep that distinction clear when discussing the business with a recruiter.
Prepare around a consequential user journey
Think through the candidate, reviewer, and institution as different users with different permissions. A candidate needs a reliable receipt and a way to recover from a broken connection. A reviewer needs the correct work item and rubric version. An institution needs appropriately scoped results with clear status. A single “completed” flag is unlikely to explain all three perspectives.
For frontend work, practise keyboard navigation, meaningful errors, and reconnect behaviour. For backend work, practise atomic submission, idempotency, and assignment workflows. For analytics, focus on row grain, missing data, and versioned definitions. Choose the track from the job description rather than assuming every engineer works on assessments.
Coding case: allocate review work without duplicates
Original practice exercise: each response requires two distinct reviewers. A reviewer has a remaining capacity and may be ineligible for particular responses. Produce a deterministic greedy assignment for responses in identifier order, choosing eligible reviewers with the most remaining capacity and breaking ties by reviewer identifier.
Specify that this is a heuristic, not an optimiser guaranteed to find every feasible allocation. If fewer than two eligible reviewers remain for a response, mark it unassigned and do not partially consume capacity. Returning one reviewer and silently moving on would conceal an incomplete job.
For a tiny example, reviewers A and B each have capacity 1 and C has capacity 2. With two responses and no exclusions, the first gets C and A, and the second gets B and C under the stated tie rule. Add an exclusion for C on the second response and the greedy ordering may need reconsideration. Explain that a global matching or flow formulation is a different solution when completeness is required.
A direct implementation builds the eligible list for each response, sorts it, selects two, and updates capacity only after selection succeeds. With R responses and U reviewers, this straightforward approach is O(R × U log U). Test zero capacity, exclusions, a single eligible reviewer, equal capacities, deterministic output, and an impossible workload.
The important follow-up is fairness of operational assignment, not a claim about assessment fairness. Workload balancing alone does not establish unbiased evaluation. If asked about quality, discuss what additional domain expertise, monitoring, and review process would be needed, while keeping the engineering guarantees precise.
SQL case: count completed reviews at the right grain
Assume responses(id) and reviews(id, response_id, reviewer_id, status). Count distinct reviewers with completed reviews, including responses with none. Draft reviews do not count.
SELECT r.id,
COUNT(DISTINCT v.reviewer_id)
AS completed_reviewers
FROM responses AS r
LEFT JOIN reviews AS v
ON v.response_id = r.id
AND v.status = 'complete'
GROUP BY r.id
ORDER BY r.id;
Test two completed rows from the same reviewer, one completed row from another reviewer, a draft, and a response with no rows. The distinct count describes coverage; it does not decide which score version is authoritative. If reviews can be revised, model the active revision explicitly before aggregating scores.
Explain which records the query is allowed to expose. An administrator's coverage report and a candidate's status page should not share unrestricted access simply because they use the same tables. Test tenant scoping and intentionally limited output fields in addition to the arithmetic.
Design case: durable assessment submission
Separate draft saving from final submission. For this exercise, a final submission references a versioned manifest of required answers. The server validates completeness and commits the final state before returning a durable receipt. The browser's local success state is not sufficient proof that the server accepted all answers.
For large media, upload to controlled object storage and verify completion before finalisation. A manifest should reference exact object versions or checksums rather than mutable filenames. Define how abandoned uploads expire, and how a retry discovers whether a previously submitted manifest already succeeded.
Create review work from the committed submission using a durable handoff. If work creation runs asynchronously, surface “submitted, awaiting review” rather than conflating submission and review completion. Use stable job identifiers so a redelivery does not create duplicate assignments.
Version the rubric or configuration used for a review. If an administrator edits instructions midway through a cycle, decide whether existing work remains under the original version or requires a controlled transition. Historical results should remain interpretable after the configuration changes.
Keep access narrowly scoped by role and organisation. Candidate data should not appear in generic debugging logs by default. Use identifiers and event metadata sufficient for tracing, with controlled access to actual response content. This is a design exercise about minimising unnecessary exposure, not a claim of compliance with a particular law.
Debugging: receipt exists but review work is missing
Start with the receipt identifier and its committed submission. Was the final manifest complete, did every referenced object exist, and did the review-handoff event enter durable storage? If the event exists but no work item does, inspect worker attempts and deduplication decisions rather than asking the candidate to resubmit immediately.
Investigate whether a malformed response caused the entire batch to stall or whether one failed item was silently skipped. A queue length alone can hide an old stranded submission. Track the oldest unassigned submission and make failure reasons inspectable without exposing response content broadly.
Recover by creating the missing work idempotently from the committed record. Verify that the candidate's receipt still refers to the same version. Then add a reconciliation test between accepted submissions and expected review work so the defect becomes detectable before a user reports it.
Explain product care through concrete engineering
Prepare a project story about preserving user work through a network failure or making a difficult workflow accessible. Explain what the user saw, what state the system retained, and how you verified recovery. “We cared about users” is less informative than a specific example of preventing a lost submission.
Ask which product area the role serves, how assessment-cycle peaks are tested, how configuration changes are versioned, and how engineering collaborates with domain specialists. If discussing analytics, ask how missing or revised data is represented so dashboards do not quietly treat absence as zero.
Your practice deliverables
Build the deterministic reviewer allocator, test the coverage query, and draw a submission receipt path with one broken-network scenario. Add a mock discussion about incomplete media upload and explain how you would communicate the difference between a saved draft and a final submission.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Acuity Insights'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 reviewer allocation 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 submission receipt and complete media manifest visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate a media upload finishing after a submission retry. 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 receipt exists but no reviewer receives the response. 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 Insights 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 Insights.