What to expect
A building operator selects a new lighting scene. The cloud accepts the request, one gateway is offline, and the dashboard still shows the old state. Does an accepted command mean the lights have changed? That distinction is a productive Acuity Brands practice problem: software needs to connect user intent with devices whose state may be delayed or uncertain.
The official Acuity brands page distinguishes lighting and intelligent-spaces businesses. Its IT/Software careers page also describes work supporting organisational technology and processes. The supplied company name remains Acuity Brands here, but candidates should confirm the business unit and whether the opening is product engineering, embedded development, cloud services, or internal IT.
The exercises below focus on a connected-lighting scenario. They are original preparation material, not a claim about the company's internal architecture or actual interview questions. A business-systems vacancy may justify a different emphasis, especially around enterprise applications and data integration.
Choose the right engineering track
For an embedded role, review memory ownership, timeouts, state machines, device interfaces, and reproducible tests. For cloud or backend work, practise concurrency, versioning, authentication, and fleet visibility. For a frontend role, show clear pending, failed, and confirmed states instead of hiding network uncertainty behind a success toast.
Ask which operating environment, language, hardware family, and deployment responsibility belong to the opening. Do not assume that all teams share one stack. Prepare one past project in which an external component behaved differently from the happy-path contract and explain how you detected and contained that difference.
Coding case: resolve competing lighting rules
Original practice exercise: each rule has a start time, end time, priority, unique identifier, and target brightness. At a given integer time t, select the active rule with greatest priority. Break equal-priority ties using the lexicographically smallest identifier. Intervals are half-open: start is included and end is excluded. With no active rule, return an explicit default.
For rules A covering [0,10) at priority 1 and B covering [5,8) at priority 2, time 6 chooses B, time 8 chooses A, and time 10 chooses the default. Naming the boundary convention prevents two schedules from both claiming the exact handover instant. Validate invalid intervals and brightness values before selection.
A direct solution scans all rules, filters for start <= t < end, and compares priority plus identifier. It takes O(n) time and constant extra space if it retains only the best candidate. This is often the right starting answer. If asked to handle many queries, discuss sorting endpoints or indexing intervals, but explain how overlapping priorities and updates affect the index.
Tests should include empty input, exact start and end boundaries, overlapping rules, ties, an invalid rule, and deterministic selection regardless of input order. Add a local override only after defining its precedence and expiry. A permanent override and an override that expires at midnight are different contracts.
For a real device-control system, do not extrapolate this toy resolver into safety behaviour. Ask which decisions must remain local, who defines defaults, and what independent protections exist. The interview exercise is about making precedence and uncertainty explicit, not designing unverified operational policy.
SQL case: find devices with no recent heartbeat
Assume devices(id) and heartbeats(device_id, received_at), with normalised timestamps. The caller supplies a cutoff time in the same representation. Include devices that have never reported.
SELECT d.id, MAX(h.received_at)
AS last_seen
FROM devices AS d
LEFT JOIN heartbeats AS h
ON h.device_id = d.id
GROUP BY d.id
HAVING MAX(h.received_at) IS NULL
OR MAX(h.received_at) < :cutoff
ORDER BY d.id;
Test a device with a recent heartbeat, one with an old heartbeat, and one with none. A heartbeat exactly at the cutoff is recent under this contract. An older row must not cause a device with a newer row to be classified as stale. Aggregating before comparing addresses that mistake.
Absence of a heartbeat indicates missing observation, not proof that a light is off or broken. Keep communications health separate from reported device state. In your answer, explain how clock skew, delayed delivery, device retirement, and maintenance windows affect the operational meaning of this report.
Design case: deliver a scene change with honest status
Model desired state and observed state separately. A cloud-side write records the requested scene and its version. The device or gateway acknowledges the version it actually applied. The UI should not label the action complete merely because the API accepted it. Show pending, applied, expired, or failed states and the timestamp of the latest observation.
Give commands identifiers and sequence or version information. If version 12 arrives after version 13, the receiver needs a policy for rejecting obsolete work. If a device reboots and loses volatile state, explain how it discovers the desired state again. A fresh reconciliation pass may be more appropriate than replaying every historical command.
Define the offline boundary. The gateway may continue a previously downloaded schedule while disconnected, but the exact behaviour is an exercise assumption that must be agreed. Avoid promising that the cloud can guarantee an immediate physical action across a broken network. Instead, describe what can be observed and what remains uncertain.
Partition access by site or tenant and check permissions on each command, not only in the interface. Record who requested a change, what changed, and which devices acknowledged it. Avoid relying on predictable device identifiers as an access control mechanism. Include tests that try to issue a command for a different site.
For rollout, separate configuration changes from firmware changes. A scene update may be reversible immediately; a failed firmware deployment may require another recovery path. In a design discussion, start with one device group, observe outcomes, and specify the condition that stops a wider rollout.
Debugging: the dashboard reports success but the scene is wrong
Choose one command and device. Compare the requested version, gateway receipt, device acknowledgement, and UI state. Determine whether the UI is displaying desired state as observed state, whether an older command arrived later, or whether a local override is still active. These are different hypotheses with different repairs.
Check which timestamps come from the cloud and which from a device clock. A sorting error can appear to be a transport problem. Inspect a sequence of events around reconnection rather than a single log line. If a command expired while offline, show that outcome instead of silently applying obsolete intent.
Finish with a regression test that recreates the failure: reorder commands, interrupt the network, or retain a stale browser cache. Explain what evidence would establish that the right scene was applied, and who is responsible for verifying physical behaviour outside the software test environment.
Project stories and questions for the team
A useful story concerns the gap between acknowledgement and completion. Describe how you exposed a long-running operation to users, handled cancellation, or distinguished stale data from live state. If your background is web applications rather than devices, make the analogy explicit without claiming experience you do not have.
Ask which responsibilities live at the edge, how simulated devices are used in testing, how compatibility across versions is managed, and what telemetry helps a support engineer diagnose a site. These questions reveal whether the team needs strength in product software, fleet operations, or internal IT.
Your practice deliverables
Produce a deterministic rule resolver, a stale-heartbeat query, and a desired-versus-observed state diagram. Add a mock incident involving an offline gateway. Review your design by asking whether a user can tell the difference between “requested,” “received,” and “applied” at every point.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Acuity Brands'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 rule precedence 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 desired scene and the latest device observation visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate a gateway reconnecting with an older command. 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 dashboard says applied while the device is offline. 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 Brands 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 Brands.