02What to expect

A maintenance dashboard says that every job is complete. A field engineer says that two visits never happened. Which system do you trust, how do you investigate, and how do you prevent the discrepancy from returning? That is a useful problem to practise for software supporting real operations: the difficult part begins where a correct-looking screen meets incomplete data and human workflows.

This guide helps you prepare for a Software Engineer conversation under the Acorn Engineering name. You will work through an event-processing exercise, a SQL reporting problem, an operational system design, and a practical debugging scenario. Each exercise includes assumptions, a solution approach, and follow-up questions so you can practise explaining your decisions, not just recognise terminology.

Before you prepare: confirm the legal employer, location, and job description. The UK business at acornlimited.co.uk describes mechanical and electrical building services. The separate Acorn Engineering Company describes manufacturing and custom products. These are different contexts. The building-services examples below are appropriate if your opportunity relates to the UK business; they are not evidence of a particular vacancy, technology stack, or hiring process.

Evidence status, September 6, 2026: the official pages reviewed for this guide do not establish a Software Engineer interview loop. No verified role-specific candidate report is used here. The exercises and study schedule are PracHub preparation recommendations, not questions reported from Acorn interviews. Confirm the assessment format with your recruiter before allocating most of your time to one topic.

03Your preparation map

Open the full-size diagram

An editorial study map. These steps describe how to prepare, not Acorn's hiring stages.

Start with one concrete deliverable in each area. A working function shows coding fluency; a small database query exposes how you handle missing records; an architecture sketch makes failure assumptions visible; a project story demonstrates how you work with people. Together, these give you material for several interview formats without depending on an unverified account of the company's process.

04Understand the role before choosing your study topics

The UK Acorn site's careers page directs applicants to its vacancies and describes opportunities in facilities management and mechanical and electrical services. That context helps you choose realistic practice scenarios, but it does not prove that a particular software team builds sensor platforms, uses Python, or conducts an algorithms assessment.

Ask for the actual job description. Mark every explicit reference to languages, databases, integrations, users, deployment environments, and support responsibilities. Then map each requirement to something you can demonstrate. If the posting names SQL and internal applications, spend time on data correctness and workflow design. If it names embedded programming, replace the web-service exercise with memory, timing, interfaces, and device testing. If it emphasises application support, prepare incident diagnosis and reliable change management.

A useful opening question is: “Who uses the software this role owns, and what becomes difficult for them when it is unavailable?” The answer gives you an engineering objective. A scheduler needs dependable job status; a technician may need to work without connectivity; a manager may need traceable reports. You can then discuss tradeoffs in terms of the people affected.

For “Why this role?”, connect a verified aspect of the opportunity to a truthful example from your work. Avoid claiming enthusiasm for an invented internal platform. A stronger answer might explain that you enjoy translating an operational problem into a dependable tool, then describe how you validated a similar tool with its users.

05Interview conversations to prepare for

Until the recruiter confirms the format, prepare the following conversations as a flexible menu. The order, duration, and number of assessments are not confirmed Acorn facts.

Recruiter or hiring-manager conversation

Prepare a concise account of your background, one relevant project, and the kind of work you want to own. Explain your contribution separately from your team's output. For example, “I designed the retry policy and added reconciliation” is more informative than “we built a scalable platform.” Be ready to discuss location, availability, and the role's balance of development, integration, and support.

Ask whether the technical assessment involves live coding, a take-home task, existing code, or a project walkthrough. Also clarify whether documentation and AI tools are permitted. These details should change your practice conditions; they should not be guessed from another employer's process.

Coding or practical technical discussion

Practise making the problem smaller before implementing it. Restate the input and expected output, work through a tiny example, and identify one ambiguity. Choose a solution, explain its complexity, and test the failure cases. If you run out of time, describe what is correct now and what remains unfinished.

For a take-home exercise, reserve time for a short README that explains how to run it, important assumptions, test coverage, and limitations. A small, reproducible solution gives a reviewer more useful evidence than a large project whose setup fails.

Architecture or project deep dive

Prepare to draw a system you actually understand. Start with users and the core workflow, then introduce components only when a requirement needs them. Explain a failure scenario and a recovery path. If your design depends on ordering, uniqueness, or a transaction, state exactly where that guarantee comes from.

For a past project, practise answering: Why this design? What alternatives did you reject? What broke? What would you change at a different scale? These questions reveal understanding more reliably than a catalogue of technologies.

Collaboration and operational judgment

Prepare examples of clarifying a vague request, handling a disagreement, investigating a defect, and delivering a change safely. Use real events and real outcomes. If you do not have numerical measurements, describe a verifiable qualitative result rather than inventing percentages.

06Worked coding exercise: keep the latest valid asset update

Editorial practice prompt: an internal application receives asset updates. Each event contains an asset identifier, event identifier, integer version, and status. Events may be duplicated or arrive out of order. Produce the latest event for each asset.

This exercise connects basic hash-map reasoning to a realistic integration problem. It is not a reported Acorn question.

Clarify the contract

Assume that event identifiers are globally unique and an identical redelivery may be ignored. Versions increase independently for each asset, and an event with a lower version must not replace a newer one. Two distinct events for the same asset and version are a conflict. The function should raise an error for that conflict rather than silently choose an arbitrary status. Treat a duplicate event identifier with changed contents as invalid input too.

The input for this exercise is already structurally validated: each event has the required fields with the agreed types. In a service, you would validate the payload before this function and decide how to record or quarantine invalid input.

A reference implementation

def latest_by_asset(events):
    seen_ids = {}
    seen_versions = {}
    latest = {}

    for event in events:
        eid = event["event_id"]
        aid = event["asset_id"]
        version = event["version"]

        if eid in seen_ids:
            previous = seen_ids[eid]
            if previous != event:
                raise ValueError(
                    "ID reused"
                )
            continue

        key = (aid, version)
        if key in seen_versions:
            raise ValueError(
                "Version conflict"
            )

        saved = event.copy()
        seen_ids[eid] = saved
        seen_versions[key] = eid
        current = latest.get(aid)
        if (
            current is None
            or version
            > current["version"]
        ):
            latest[aid] = saved

    return latest

For pump-7, versions 3, 1, 3 with the first event redelivered at the end should leave version 3 as the result. A later version 4 should replace it. An update for fan-2 belongs to a separate sequence and must not affect pump-7.

The algorithm makes one pass. Under ordinary hash-map assumptions, expected time is O(n). Space is O(n + a), where n is the number of distinct input events and a is the number of assets. Do not claim constant memory: the implementation retains identifiers and versions to detect conflicts, including conflicts in older events.

Tests and follow-ups

Test empty input, an identical duplicate, reversed arrival order, multiple assets, reused identifiers with changed content, and two different events at the same asset version. Include an older-version conflict after a newer version has arrived; checking only the currently latest event would miss that case.

Then explain the limits. This function does not provide durable deduplication after a process restart. A production consumer needs persistent state and concurrency control. If two consumers update the same asset, the check and write must be atomic. If the stream is unbounded, define retention or a bounded input window rather than retaining every identifier forever.

What makes an answer stronger: show the invariant in plain language: “For each asset, the selected event always has the largest accepted version seen so far.” Then explain which extra state exists for validation and why a timestamp alone might not establish a reliable order.

07Worked SQL exercise: identify overdue work without losing empty sites

Editorial practice prompt: an operations manager wants every site and the number of work orders that are past their due time and not completed. Sites with zero overdue work must still appear.

Assume two tables: sites(id, name) and work_orders(id, site_id, due_at, status). For this exercise, status is non-null and completed is the only excluded state. A due time strictly before the database's current timestamp counts as overdue. Null due times are excluded until the business defines how to handle them.

SELECT
    s.id,
    s.name,
    COUNT(w.id) AS overdue_count
FROM sites AS s
LEFT JOIN work_orders AS w
    ON w.site_id = s.id
   AND w.due_at < CURRENT_TIMESTAMP
   AND w.status <> 'completed'
GROUP BY s.id, s.name
ORDER BY overdue_count DESC, s.id;

The location of the filters matters. Putting conditions on w in the WHERE clause can remove the null-extended rows produced by the left join, so a site with no qualifying work disappears. COUNT(w.id) counts matching work orders; COUNT(*) would count the retained site row even when no work order matches.

Walk through three sites on paper: one with two overdue orders, one with only completed orders, and one with no orders at all. The counts should be 2, 0, and 0. Add a work order due exactly at the evaluation timestamp to verify the strict boundary.

Before treating the result as a business report, ask whether cancelled or paused work counts, which timezone defines deadlines, and whether multiple visits belong to one work order. If a join to visits creates several rows per order, the query may overcount. Fix the data grain before adding DISTINCT as a blanket repair.

For a performance discussion, inspect an execution plan against representative data and consider indexes that support the join and selective filters. Do not promise that one composite index is universally best. Table size, overdue fraction, database engine, and write volume all matter.

08System design walkthrough: a dependable maintenance workflow

Editorial design exercise: design a service that accepts fault reports, creates work orders, and lets authorised staff see progress. This is a learning example, not a diagram of Acorn's infrastructure.

Open the full-size diagram

Keep the work order durable before depending on external delivery. The diagram illustrates one possible design for the exercise.

1. Establish the smallest useful scope

Start with manual reports and a staff-facing status view. Ask who can submit reports, how urgency is assigned, whether attachments are required, and what “resolved” means. For this exercise, assume humans review priorities and the system does not directly control physical equipment. If the real role involves control software, that introduces a different engineering scope that must be established with the team.

Choose an explicit source of truth for work-order status. A dashboard, email, and external scheduling tool can disagree temporarily; the design should say which record is authoritative and how discrepancies are reconciled. Avoid treating “notification delivered” as equivalent to “work assigned.”

2. Define a state model

A small state machine might be new → triaged → assigned → in_progress → resolved → closed. These are proposed states for the exercise. Define allowed transitions and who can make them. Reopening an order should preserve its history rather than erase the previous resolution.

Store a version on the work order. An update can include the version the user last read; reject a stale write and ask the client to refresh when another person has changed the record. This makes a lost-update problem visible instead of letting the last network request silently win.

3. Make submission safe to retry

Suppose a technician submits a report, the server commits it, and the connection drops before the response arrives. Retrying without an idempotency mechanism could create a second order. Accept a client-generated request identifier, scope it to the relevant tenant or account, and enforce uniqueness in storage. Return the existing result for a matching retry. Reject reuse of the identifier with a different payload.

Explain how long the identifier remains valid and what happens after that retention period. The important point is not the word “idempotency”; it is showing that one user action does not accidentally become two pieces of work after an ordinary network failure.

4. Separate durable state from external delivery

If creating an order and sending a notification are two independent operations, a crash between them creates a gap. One possible solution is an outbox row written in the same database transaction as the work order. A worker later delivers the event and records progress. This addresses the local commit-versus-publish gap; it does not magically make an external service process the message exactly once.

If the worker sends a message and crashes before marking it sent, it may send again. Use a stable event identifier and an idempotent recipient where available. Add bounded retries with backoff, a visible failure queue, and a way for an operator to recover failed deliveries. Describe who owns that queue and what constitutes an urgent failure.

5. Design the staff experience during failure

Show whether a status is current, stale, or awaiting synchronisation. A cached green indicator without a timestamp can mislead a user into believing the system is healthy. If a field client works offline, show unsent changes separately from confirmed server state and define a conflict policy for reconnecting.

For an integration outage, preserve accepted reports, expose delayed delivery, and provide a documented manual workflow. When the dependency recovers, reconcile outstanding records. Measure the age of the oldest undelivered event as well as the number of events: a small queue can still contain one neglected urgent item.

6. Finish with tests and tradeoffs

Test duplicate submissions, concurrent assignments, invalid state transitions, a worker crash after delivery, and a prolonged external outage. Check that users from one client or site cannot access another's records merely by changing an identifier. Explain how logs and audit history support investigation without exposing unnecessary personal information.

A good initial design can be a single application, a relational database, and a background worker. Add a separate broker or more services when throughput, isolation, or integration requirements justify them. Naming more components does not improve an answer unless you can explain the failure or requirement each component addresses.

09Debugging scenario: the dashboard says complete, the work is unfinished

Use the opening scenario as a mock interview. The most useful first move is to establish one affected work order, its expected state, and the evidence behind the complaint. Ask whether the problem affects one record, one site, or all recent updates. Record the timeline and compare the dashboard's last refresh with the authoritative record.

Trace the work-order identifier through the client request, API, database, delivery worker, and downstream system. Compare event versions and timestamps. Look for an old event overwriting a newer one, a mapping error between two status vocabularies, or a dashboard that treats “assigned” as “completed.” These are hypotheses to test, not conclusions to announce.

If users are making decisions from incorrect status, communicate the affected scope and arrange an appropriate temporary workflow. Preserve useful evidence before restarting services or replaying messages. A replay may repeat side effects; establish deduplication and the intended state before using it as a repair.

Finish the answer with two tracks: correction and prevention. Correction may mean reconciling affected records with an audit trail. Prevention may mean a state-transition check, a version constraint, a contract test for the integration, and monitoring for impossible status combinations. Explain how you would confirm the fix on representative records before widening it.

10How to make your project and behavioral answers specific

A project story is strongest when another engineer can understand the decision you faced. Use a short structure: situation, constraint, your action, evidence, and lesson. Spend less time naming the company or framework and more time on the moment when you had to choose.

For an ambiguity story, describe two interpretations of a request and how you discovered which one users needed. For an incident story, separate the immediate mitigation from the later fix. For a disagreement, explain the other person's concern fairly and what evidence helped resolve it. For a missed deadline, explain when you communicated the risk and how you changed the scope or plan.

Compare these two styles. “I improved reliability by adding monitoring” leaves the work invisible. “I found that retries were creating duplicate records, added a request identifier with a uniqueness constraint, and used a replay test to confirm duplicate submissions returned the original result” explains an engineering contribution. Use that level of detail only for work you actually did.

Bring two or three questions that expose the reality of the role: Which workflow causes users the most friction? How are integration failures detected? Who owns production support? How are changes tested with operational users? What would a useful first three months look like? The answers can help you judge the opportunity and choose relevant follow-up examples.

11A two-week preparation plan with visible outcomes

The following is an optional 20-hour practice budget across two weeks. It is an editorial schedule, not an estimate of Acorn interview difficulty or the proportion of topics in its interviews. Redistribute the time once you know the assessment format.

Open the full-size diagram

Hours are a proposed allocation for a candidate with existing software fundamentals. They are not measured interview statistics.

Use a simple self-review scale for each exercise: 0 means you cannot explain the approach; 1 means it works only on the happy path; 2 means it handles important edge cases; 3 means you can explain limitations and alternatives. This is a practice rubric, not an employer scorecard. Revisit the lowest-scoring area before adding another topic.

If you have one evening, build the role brief, solve one exercise aloud, and rehearse one project story. If you have several weeks, add repeated mocks and feedback rather than simply increasing the reading list. The goal is to make your reasoning clearer on the next attempt.

12Practice questions and useful next steps

Use the Software Engineer question bank for additional role-level practice. PracHub does not currently have a verified Acorn Engineering question bank for this guide. The exercises above are independent preparation prompts and should not be described as past Acorn interview questions.

After completing them, try these variations: make the event processor restart safely; add cancellation rules to the overdue query; support offline work-order updates; or explain how a failed notification is recovered without duplicating work. For each variation, write down the changed requirement before modifying the solution. That habit keeps an interview answer coherent as the interviewer introduces new constraints.

13Frequently asked questions

Is there a confirmed Acorn Engineering Software Engineer interview process?

Not from the official sources reviewed for this guide. Confirm the role, employer, and assessment format directly. Treat the conversation formats above as preparation options rather than a promised hiring sequence.

Do I need building-services knowledge?

If your opportunity is with the UK building-services business, learning the users and workflows can make your examples more relevant. That does not establish a requirement for specialist electrical, mechanical, or control-system qualifications. Use the job description to determine what the role actually requires.

Which programming language should I practise?

Use the language required by the assessment or the one in which you can write and test correct code clearly. Python is used in the worked example for readability, not because it is a verified Acorn requirement. If the role specifies another stack, translate the same contract and tests into that language.

Should I study system design or algorithms first?

Let the confirmed format decide. For a coding screen, prioritise implementation and edge cases. For an experienced-hire architecture conversation, spend more time on data ownership, failure recovery, and tradeoffs. If the format is still unknown, complete one worked example in each area before specialising.

What should I say when I do not know the answer?

State what you know, identify the missing assumption, and propose a way to test it. In a design discussion, an honest limitation followed by a reasonable next step is more useful than an unsupported claim about a tool's guarantees.

14Sources and scope

Company context was checked on September 6, 2026 against the UK Acorn homepage, its official careers page, and the separate Acorn Engineering Company manufacturing page. These sources support the identity and business-context distinction; they do not substantiate a Software Engineer vacancy or a role-specific interview loop.

All coding examples, architecture diagrams, preparation hours, and practice rubrics in this guide are original PracHub editorial material. Apply them to the requirements of your actual opportunity, and verify any employer-specific expectations with the hiring team.