What to expect
A person spends twenty minutes completing a government-service form on a phone. The session expires during submission, and the page loses their answers. A useful Ad Hoc preparation exercise is to redesign that journey so the person can understand what happened and recover their work.
Ad Hoc publishes material about public-service delivery and engineering. Its 2018 engineering recruitment article described practical homework and blind grading at that time. Treat this as dated official evidence: it does not prove the same sequence, assignment, grading practice, or time expectations apply to a 2026 opening. Check the current careers entrypoint and the instructions for your application.
This guide focuses on practical software, accessible forms, durable submissions, and clear delivery decisions. Its practice exercises are original and unrelated to any actual homework solution. The goal is to prepare you to explain your work and its limits under the rules your recruiter provides.
Translate public-service needs into engineering requirements
Start with a user journey rather than a technology list. Ask what the person is trying to complete, which information they must supply, and what happens if they are interrupted. A successful submission is only one outcome; saving a draft, correcting an error, and understanding a pending status also matter.
For frontend work, practise semantic controls, keyboard navigation, meaningful error messages, and preserving input. For backend work, practise durable receipts, retry-safe writes, and integrations with older systems. For a broader role, explain how you would work with design, research, and delivery partners to test the journey with representative constraints.
Coding case: validate without losing the user's work
Original practice exercise: validate a small application containing name, email, and contact preference. Return a list of structured errors while retaining the submitted values for correction. The exercise requires a non-empty name, a basic email shape when email is the preferred contact method, and a supported preference value.
Define error objects with field, code, and message. Do not replace the entire form with a generic failure. Validation should be deterministic and should not silently change a value that may be meaningful to the user. For example, trimming surrounding spaces for an emptiness check is different from rewriting a person's name.
Keep this exercise's email check deliberately modest; a small pattern is not proof that an address exists or can receive mail. If the system needs verification, describe a separate verification workflow. Avoid turning a convenient input check into an unsupported guarantee.
Test a missing name, email preferred with no address, another supported preference without an email, unknown preferences, whitespace-only input, and multiple errors together. Preserve valid fields and show all relevant errors in one pass where practical. The complexity is proportional to the fields and input lengths examined.
For the interface, connect each error to its field and provide an error summary that helps users reach the correction. Test keyboard use and focus after an unsuccessful submission. Client-side validation can improve feedback, but the server must still validate the authoritative request.
SQL case: find submissions with no durable receipt
Assume applications(id, state) and receipts(id, application_id). Find applications marked submitted without a receipt record under this exercise's contract.
SELECT a.id
FROM applications AS a
WHERE a.state = 'submitted'
AND NOT EXISTS (
SELECT 1
FROM receipts AS r
WHERE r.application_id = a.id
)
ORDER BY a.id;
Test a submitted application with a receipt, a submitted application without one, and a draft. This query diagnoses a specific invariant; it does not prove downstream processing or a successful service decision. A receipt should say what was accepted and when, not promise an outcome the service has not reached.
If receipt generation is asynchronous, define a delay window before treating a missing row as a defect. Better still, distinguish the durable receipt record from optional email delivery. An email failure should not make the person's submission disappear.
Design case: a resumable application journey
Separate draft state from final submission. Save drafts with clear feedback about what is stored on the server and what remains only in the browser. A person should not have to infer persistence from a spinner. Consider device sharing and session expiry when deciding how long local data remains available.
On submission, validate the server-side snapshot and atomically record the accepted application and receipt reference. A repeated request with the same logical identifier should retrieve the same result. If the network drops after commit, a refreshed page should be able to discover the receipt rather than force a second application.
Use clear status language for the handoff to downstream systems: received, processing, needs information, or another agreed state. These are example labels, not government-program rules. Do not present “request sent” as “decision complete.” Each state should have a next action or an understandable waiting condition.
Keep the user interface usable under slower connections and partial failures. Avoid making a large script download the only way to discover an error or contact route. Test long text, zoom, keyboard use, and small-screen layouts. If a component cannot support these conditions, name the limitation and provide a practical fallback in the design.
Use role-based access and data minimisation for staff tools. Operational logs should identify a failing application without casually reproducing every answer. Retention and disclosure requirements need the actual program's policies; do not invent them from a generic interview exercise.
Debugging: the person is unsure whether submission worked
Start with the logical submission identifier, if available, and the server's accepted state. Compare that with the receipt record, the response, and the browser's last visible message. Distinguish a lost acknowledgement from a rejected request and from a downstream processing delay.
If the server accepted the application, guide recovery toward the existing receipt. If validation failed, restore the user's input and show actionable errors. A generic “please try again” can create duplicate work and force the person to repeat effort unnecessarily.
Add tests for session expiry before submission, response loss after commit, an unavailable downstream system, and browser reload during processing. Review the messages with someone outside engineering to check that the difference between saved, submitted, and processed is understandable.
Prepare a practical work sample thoughtfully
If the current application instructions include homework, follow those instructions exactly. Ask about time expectations, permitted assistance, and what the reviewer will run. The dated Ad Hoc article is useful context for practical work, but it is not permission to assume the same rules now.
For your own practice project, include a short README, a reproducible run command, a few high-value tests, assumptions, and known limitations. Explain one tradeoff you deliberately made. A reviewer should be able to understand what works without reverse-engineering your development environment.
Behavioral stories and team questions
Prepare a story about improving a frustrating user workflow and another about communicating a limitation early. Explain how feedback changed the implementation, what you tested, and what remained unresolved. Use actual evidence rather than assuming that shipping a feature proves it improved access.
Ask how engineers collaborate with researchers and designers, how accessibility is reviewed, how releases are coordinated with service owners, and how incidents are communicated. These questions connect technical decisions to the mission without pretending every project has identical constraints.
Your practice deliverables
Build the structured validator, test the missing-receipt query, and sketch a resumable form. Run one mock in which the network fails after submission. Your answer should help both another engineer and the person trying to complete the service understand what happens next.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Ad Hoc'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 structured validation 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 durable receipt and recoverable application state visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate a connection dropping after submission but before confirmation. 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 person cannot tell whether an application was submitted. 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 Ad Hoc 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 Ad Hoc.