Interview guides · Accuenergy

Accuenergy Software Engineer Interview Questions & Guide 2026

Accuenergy software engineer prep: algorithm drills where every complexity claim has to name the assumption under it.

The 60-second brief

As a Software Engineer at Accuenergy, you will play a critical role in developing the technical solutions that drive the company’s energy management and monitoring products. This position is situated at the intersection of hardware integration and web-based application development, requiring a versatile engineer who can bridge the gap between complex energy data and intuitive user interfaces.

Most rounds test how you handle an under-specified problem more than what you recall. A wrong first approach you correct out loud is recoverable; a constraint you assumed silently and were never given is the expensive mistake.

Focus areas

Reserve inventory without overselling under concurrent allocation
Reconcile a movement ledger against derived positions
Keep a site operating during a network partition

Overview

You will contribute to the R&D efforts that define how clients interact with Accuenergy power meters and software platforms. Whether you are working on PHP-based web development or contributing to broader application architecture, your work directly influences the reliability and functionality of products used in industrial and commercial energy management. This is a role for engineers who enjoy technical depth, project ownership, and the challenge of building scalable tools in a specialized, high-precision industry.

The Accuenergy interview process

Accuenergy candidates report 4 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

Pre-Interview Code Assessment

Most of the time lost in this format is not lost to thinking. It goes to a standard-library call you half-remember, an off-by-one in a loop bound, and a debugging loop that mutates code at random until something passes. When output is wrong, stop re-reading the whole function: take the smallest input that reproduces it and walk the state through by hand, printing intermediates if the environment allows. Guessing at a fix without a failing case you understand is how a five-minute bug becomes twenty, and the clock does not pause while you do it.

What to demonstrate

Whether you reach the right structure without a detour, and can write it from memory rather than only recall that one exists
Whether overflow is considered where the language has fixed-width integers, since a signed 32-bit value stops at 2,147,483,647 and then wraps in Java, is undefined behaviour in C++, and does not arise in Python, whose integers grow instead
Whether recursion depth is treated as a constraint on large inputs, given that CPython's default limit is 1000 frames and a deep recursion can exhaust the stack in any language where an iterative version would not
Whether a failing case is isolated and explained before any edit is made to the code

How to prepare

From an empty file and with no references open, implement the pieces you lean on most: a heap push and pop, an iterative DFS with an explicit stack, and a binary search whose midpoint is written lo + (hi - lo) / 2, which avoids the overflow that (lo + hi) / 2 can hit in a fixed-width integer type
Time yourself on the ten library calls you look up most, such as sorting with a custom comparator, splitting and joining strings, and finding the next key at or above a value in an ordered map, until the lookup is gone
Take a solution you know is broken and, before touching it, write one sentence naming the input, the expected value and the actual value. Repeat until you do it without deciding to.

HR Interview

When a round has no standard shape, it is often there because something is still open: an area no earlier conversation reached, a round where the signal came out mixed, or a decision someone is not ready to make alone. Work out which by going back over what each earlier round actually covered rather than how it felt, and arrive able to give evidence on that point without being asked twice. Weak answers replay the loop's earlier material at the same depth. Strong ones go a level deeper and stay consistent with what you already said.

What to demonstrate

Whether your account of a project matches the one you gave earlier in the loop, since what you said before may be available to whoever runs this round
Whether you can go a level deeper on something already covered, reaching the decision and its alternatives rather than repeating the summary
Whether you state your own uncertainty accurately, including parts of a system you did not build and decisions you inherited, instead of claiming even ownership across all of it
Whether you can answer a question you handled poorly earlier by naming what you missed, rather than delivering a polished second version as if the first had not happened

How to prepare

Reconstruct the loop on one page: for each round, the questions you were asked and the answer you actually gave, not the better one you thought of afterwards. The gaps on that page are your best available guess at why this round exists.
Take the two claims you made earlier that carry the most weight and assemble the backing for each: the measurement, the date, what broke, the decision you would make differently now.
Write down the three facts about your work that must not drift between tellings, such as team size, timeline and your own role, and check your stories against that list rather than trusting recall under pressure

R&D Team Interview

An unlabelled round is first an information problem, and the cheapest information is free. Whoever schedules it can usually tell you how long it runs, who will be in the room and what they work on, whether you will be writing code and in what environment, and whether anything is being sent beforehand. Ask in writing so the answer is on record, then prepare for the two or three formats those answers still leave open instead of betting on one. What separates a strong candidate is not guessing right; it is having an opening that works whichever one it turns out to be.

What to demonstrate

Whether you can start work from an ambiguous brief, since tolerating a vague scope without stalling is the same thing the job asks for
Whether the questions you asked beforehand were ones that change your preparation, such as duration, medium and who is joining, rather than ones whose answers you could not have acted on
Whether you adapt when the round turns out to be something other than what you were told, instead of spending the first ten minutes visibly recalibrating

How to prepare

Send one short scheduling message asking four things: how long, who is joining and what they work on, whether you will be writing code and where, and whether to prepare anything in advance. Treat a vague reply as real information, since it means the round is loosely structured and you will be shaping it yourself.
Write one opening that works in any of the formats still open: restate in your own words what you have been asked to do, then ask which of two directions is more useful to them. Say it aloud until it stops sounding recited.
Set up for the two most likely formats before the call starts, with a blank editor in the language you would choose and a shared document you can type into, so a format surprise costs you nothing in the first minutes

Discussion with Engineering Managers

You cannot drill a format you do not know, so put the preparation into material that travels. Three pieces of your own work, each rehearsed until you can take a follow-up you did not anticipate, will carry a conversation or a code walkthrough equally well. Specificity is what separates that from filler. A number needs its definition before it means anything: a p99 is over some window and measured at some hop, and a server-side figure excludes the queueing and network time a client would see. The number you cannot qualify is the one to leave out.

What to demonstrate

Whether your examples carry detail only someone who did the work would hold, such as what the binding constraint actually was, which alternative you rejected and why it was worse, and what you measured on each side of the change
Whether a number survives one follow-up, meaning you can say what it was measured over and whether it moved because of your change or merely alongside it
Whether a failure is described with the specific change that followed it, rather than a lesson stated in general terms
Whether your part in a team effort is stated accurately, including what other people did

How to prepare

Write a page on each of three projects covering the constraint, the option you rejected, the measurement before and after, and what went wrong. Cut any line you cannot take a follow-up on, since you are writing the parts you will be pressed on rather than a summary.
Recover the real figures while you still have access: request volume, data size, latency with its percentile and window, team size, timeline. Note where each came from, whether a dashboard, a design document or memory, and mark the estimates so you can say which they are out loud.
Take your weakest project story to someone who works in a different area and have them ask why four times in succession. The point where you run out of answer is the part to go and re-read before the round.

Where candidates lose points

Judging delivery windows and cut-offs in UTC

A delivery appointment, a receiving cut-off and a same-day promise are all statements about local wall-clock time at a specific stop, so evaluating them in UTC misclassifies on-time performance for any leg that crosses a zone, and misses cut-offs by an hour on the two days a year a region changes offset. The subtlety that catches experienced engineers is that converting a future local time to a UTC instant at write time bakes in the offset rules as they were known then: when a jurisdiction changes its rules, an appointment stored that way silently moves, which is why a future window is better stored as local wall time plus an IANA zone identifier and resolved at read time, while a past event is correctly stored as an instant. Duration arithmetic needs the same care, because a transit that spans a DST boundary is genuinely 23 or 25 hours long in local terms even though the elapsed instant count is unchanged. Storing only a date with no zone - common on partner feeds - is the version of this that cannot be fixed downstream, so the zone has to be captured at ingestion.

Floating-point quantities and implicit unit-of-measure conversions

Binary floating point cannot represent most decimal fractions exactly, so a chain of pallet-to-case-to-each conversions accumulates a residue that a later rounding turns into a unit that was created or destroyed, breaking conservation with no concurrency involved at all. The bug is slow and non-local: it surfaces as a cycle-count variance weeks later, at a node nobody changed, and it is untraceable because the arithmetic looked correct at every individual step. The fix is to hold quantities as integers in the smallest transacting unit, carry the UoM explicitly on every row that carries a number, store conversion factors as integers that are versioned in time, and reject a conversion that does not divide exactly instead of rounding it. The same discipline applies to money on the freight side, where an accessorial in floating-point dollars produces invoice reconciliation differences of a cent that cost more to investigate than the freight.

Hardcoding to the sample inputs

Solve the stated problem rather than the two examples; special-casing a literal to make a sample pass is obvious immediately and reads as either a misunderstanding or an attempt to fake progress. If you genuinely cannot generalise yet, say which part is a stub and what would replace it.

Writing code before the input contract is pinned down

Before the first line, state the types, the size bounds, whether duplicates, negatives or an empty input are possible, whether the input is sorted, whether you may mutate it, and what the function returns when nothing matches. Every one of those answers changes the code, and discovering one at minute twenty costs a rewrite you no longer have time for.

Questions & practice

How would you approach the integration of third-party services, such as the Google Maps API, into a web project?

Medium · data structures and algorithms

Approach

Restate the input: its shape, its size, and what is guaranteed about it.
Walk one small example through your approach before writing the whole thing.
State the target complexity and say which constraint rules the naive version out.

Follow-up

Which test case would catch an off-by-one here?
What is the worst case, and how likely is it on real data?

What are the common challenges you face when debugging web-based applications?

Medium · data structures and algorithms

Approach

Walk one small example through your approach before writing the whole thing.
Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.

Follow-up

Which test case would catch an off-by-one here?
What is the worst case, and how likely is it on real data?

How do you rate your proficiency in C++?

Medium · data structures and algorithms

Approach

Choose the data structure from the access pattern, not from familiarity.
State the target complexity and say which constraint rules the naive version out.
Name the brute-force solution and its complexity before improving on it.

Follow-up

What is the worst case, and how likely is it on real data?
Which test case would catch an off-by-one here?

Size dock doors from overlapping appointment windows

Medium · sweep line · intervals · time zones

For one node and one local calendar day you have up to 200,000 planned dock appointments from shipment_leg: leg_id, planned_arrive_at, planned_depart_at (both TIMESTAMPTZ), plus the node's IANA zone. A door is occupied over [arrive, depart). Return the minimum number of doors that lets every appointment start on time, and the maximal interval over which that peak is sustained. Target O(n log n). Say how you derive the day's boundaries and how you break ties between an arrival and a departure at the same instant.

Approach

Name the result before computing it: with one interchangeable door type, the minimum door count equals the maximum number of simultaneously occupied intervals. That equality is not a heuristic — interval graphs are perfect, so their chromatic number equals their clique number, and greedy left-to-right assignment achieves it. Say this, because it is what licenses solving a scheduling question with a counter.
Emit 2n endpoints, (t, +1) at each arrival and (t, -1) at each departure, sort by t, and at equal t order the -1 before the +1. Half-open occupancy means a trailer leaving at 10:00 frees the door for one arriving at 10:00; ordering arrivals first inflates the answer by exactly the number of back-to-back handoffs, which on a well-packed schedule is most of them.
Scan once with a running counter, tracking the maximum and the endpoint index where it was first reached. The peak is attained on a half-open interval between two consecutive endpoints, [t_i, t_{i+1}), not at an instant — report it that way or the operations team cannot act on it. Extend the interval while the counter stays at the maximum.
Complexity: O(n log n) dominated by the sort, O(n) space. If rows already arrive ordered by planned_arrive_at from an index, use the min-heap variant instead — push each departure, pop all departures at or before the current arrival, and the heap size is the current occupancy. Same time bound, O(peak) space rather than O(n), which matters when peak occupancy is 40 and n is 200,000.
Derive the day's boundaries from the zone, not from arithmetic on instants. Convert local midnight and the next local midnight to instants in the node's IANA zone; on a transition day that span is 23 or 25 hours, so adding 86,400 seconds silently drops or duplicates an hour of appointments. Decide explicitly what a zero-length dwell means — under half-open semantics it occupies nothing — and state it.

Worked solution (25 min)

Write the endpoint tuple with the tie-break baked into the sort key — for example (t, kind) where departure sorts as 0 and arrival as 1 — rather than handling ties in the scan body.
Implement the scan, returning both the maximum and the [t_i, t_{i+1}) span at which it holds.
Build a fixture of six appointments where three are strictly back-to-back at the same minute, and hand-compute the answer before running.
Add an appointment spanning the local DST transition and derive the day window from the zone, asserting the appointment count inside the window.
Re-run with the input shuffled to confirm the result depends only on the set of intervals.

Expected result: The back-to-back fixture needs one door, not three; the reported peak is a half-open interval between two endpoints; on the transition day the local window is 23 or 25 hours and no appointment is dropped or double-counted.

Verify it yourself

Flipping the tie-break to arrivals-first changes the answer on the back-to-back fixture — if it does not, the fixture is not actually testing the tie.
The maximum equals the largest number of intervals containing any single probe instant, checked by brute force on a small fixture.
The result is identical under any permutation of the input.

Follow-up

Doors are typed: some break pallets, some are parcel-only. Does max-overlap still equal the door count?
Appointments have a tolerance — a trailer may start up to 20 minutes late without penalty. How does that change the objective, and is it still solvable by a sweep?
Half the appointments are actuals and half are plans. Which do you sweep for tomorrow's staffing, and which for last week's utilisation report?

Fold late, out-of-order scan events into one status per leg

Medium · window functions · event time · monotonic fold

observation_event holds event_id, subject_type, subject_id, observed_status, occurred_at, received_at, dedupe_key (UNIQUE) and processing_status. A lookup table maps observed_status to status_rank SMALLINT along a progress lattice. Write one query returning the current status of every shipment leg that received an event in the last hour, such that a picked_up event arriving after a delivered event never changes the answer. Then explain exactly which part of your ordering makes a shuffled replay of the same batch produce identical output.

Approach

Separate the two jobs. Deduplication is the UNIQUE on dedupe_key at ingest, because partner feeds resend whole windows; ordering is the fold. Either alone leaves a defect: dedupe without a lattice still lets a stale event win, and a lattice without dedupe double-counts a replayed window in anything that aggregates.
Select the affected legs in one CTE by received_at >= now() - interval '1 hour', then fold over every event for those legs, not only the recent ones. Restricting the fold's input to the recent window is the failure: a lone late picked_up would be the only row considered and the leg would regress.
Fold as a maximum over the lattice: SELECT DISTINCT ON (subject_id) subject_id, observed_status FROM ... ORDER BY subject_id, status_rank DESC, occurred_at DESC, event_id DESC. The equivalent form is ROW_NUMBER() OVER (PARTITION BY subject_id ORDER BY status_rank DESC, occurred_at DESC, event_id DESC) = 1.
The determinism comes from the final event_id tiebreak. Rank and occurred_at alone leave two equal-rank events at the same instant to be resolved by heap order, which changes when rows are re-inserted, so the shuffled replay differs in exactly the cases nobody tests. With a total order over the tuple the fold is a max, which is commutative and associative and therefore order-insensitive.
Do not advance a leg on occurred_at alone. The timestamp is device-reported and can be wrong, which is why the lattice rank leads the ORDER BY and why clock_offset_ms is worth storing: a future-dated event with a low rank then cannot promote itself past a delivered.
Keep superseded rows and mark processing_status = 'superseded' rather than deleting them. The discarded event is usually the one that explains a delivery dispute, and deleting it makes the trace unanswerable.

Worked solution (30 min)

Build a fixture for one leg with picked_up at T0, in_transit at T1, delivered at T2, then insert the picked_up row last so arrival order contradicts event order.
Write the CTE selecting affected subject_ids by received_at, then the DISTINCT ON fold joined to the rank lookup.
Run it and confirm delivered is returned, then shuffle the insert order of the same batch into a fresh table and re-run.
Add a second delivered event at the identical occurred_at from a different source and confirm the event_id tiebreak still picks one deterministically.

Expected result: One row per leg carrying the highest-ranked status ever observed, identical across every insert ordering of the same batch, with the late picked_up present in the table and marked superseded rather than absent.

Verify it yourself

Replay the batch in five random orders and diff the result sets; they must be byte-identical.
Remove the event_id tiebreak and confirm the equal-timestamp case becomes unstable across replays.
Restrict the fold input to received_at in the last hour and confirm the leg regresses to picked_up, reproducing the trap.
Confirm every input event is still present with a processing_status, so no evidence was discarded.

Follow-up

An event arrives a week late for a leg that is already invoiced. Does the fold apply it, reject it as late, or apply it and emit a correction?
The stream is partitioned by source_id rather than by subject_id. What ordering guarantee do you actually have, and what breaks?
How would you materialise this fold so the customer-facing status read is not running a window function per request?

Write the reconciliation query that finds ledger and position variance

Easy · aggregation · outer joins · reconciliation

inventory_movement(movement_id, item_id, node_id, lot_id, state, delta_qty) is the ledger; inventory_position(item_id, node_id, lot_id, state, qty, version, last_movement_id, reconciled_through_movement_id) is its running sum, written in the same transaction as each movement. Write one query that reports every key whose stored qty disagrees with the sum of its movements, including keys present in only one of the two tables, bounded by a watermark movement_id you pass in. State what the job does with each variance, and how you avoid re-summing four billion rows every night.

Approach

Aggregate once and join once: a CTE doing SELECT item_id, node_id, lot_id, state, SUM(delta_qty) AS ledger_qty FROM inventory_movement WHERE movement_id <= :w GROUP BY 1,2,3,4, then FULL OUTER JOIN inventory_position USING those four columns. One pass plus one hash aggregate, O(n) in movements scanned; a correlated subquery per position row instead costs one index scan per key and is orders of magnitude slower at 40 million keys.
Use FULL OUTER JOIN, not LEFT. A key with movements and no position row is the signature of a lost position update, and a position row with no movements is the signature of a write that bypassed the ledger. Both disappear under a LEFT JOIN from either side.
Compare with IS DISTINCT FROM and COALESCE the join keys out of both sides, so a missing row reads as a variance rather than as NULL = NULL evaluating to unknown and being filtered away.
Run both sides in one snapshot: either a single statement, or a REPEATABLE READ transaction. Reading positions in one transaction and movements in another manufactures variances for every key written in between.
Make it incremental with reconciled_through_movement_id: sum only movements in (reconciled_through, :w] and add that delta to the previously verified total. The catch is that sequence values are handed out before commit, so a movement whose id is below :w can become visible after the scan and would then never be re-summed. Set :w to a max(movement_id) observed a few minutes earlier, beyond the longest write transaction, and full-scan one partition per night on a rotation as a backstop.
A variance is reported, not repaired. Rewriting qty to match the ledger hides the double-applied retry that caused it; only a physical count may produce a cycle_count_adjust movement, and the location should be flagged unreliable to planning until it is counted.

Follow-up

The job finds 14 variances, all on one node, all negative. What do you look at first, and what would make you suspect the reconciliation job itself rather than the data?
How do you run this without the nightly scan competing with the ATP read path for buffer cache and I/O?
What does the query return for a key whose only movements are a receipt and its exact reversal, and is that row worth reporting?

Gateway that books carriers at most once through timeouts

Medium · idempotency · outbox · backpressure · rate limiting

The Carrier Integration Gateway buys bookings and labels from 30 partners. Peak is 300 booking calls per second, partner p99 is 3 seconds, and stalls of several minutes occur. Each partner admits roughly 10 requests per second and rejects the rest. A booking is physically irreversible: a duplicate is a second trailer and a second invoice. Design the call path and the retry path so one shipment leg is booked at most once, including what is recorded before the call and how an ambiguous timeout is resolved.

Approach

Generate booking_idempotency_key and persist it on shipment_leg with status requested before the socket is opened. The durable row is the memory, not the process, which is what makes a crash mid-call recoverable. Send the key to the partner where their contract supports one, but never depend on their deduplication: their window is short, their key is often derived from fields you may legitimately change, and older integrations have no such concept.
Add an explicit unknown status between requested and confirmed, entered on any timeout, connection reset or 5xx. Nothing on the request path may re-issue from unknown. A sweeper reads rows in unknown and asks the partner about that key - a lookup by reference, or the next manifest - and re-issues with the same key only when the partner affirmatively has no such booking.
Make invocation asynchronous from the caller. The orchestrator commits its saga step and an outbox row in one local transaction; a relay publishes; the gateway consumes. That is at-least-once publication, not exactly-once, so the gateway consumer must itself deduplicate on (leg_id, booking_idempotency_key) - the outbox moves the problem, it does not remove it.
Size the queues from the numbers. By Little's law, 300 calls per second held 3 seconds is 900 concurrent calls, so connection and worker budgets are per-partner and total 900 plus headroom. A partner receiving 100 per second of demand against a 10 per second limit accumulates 90 per second of backlog: 5,400 queued after a minute, which is a 9-minute drain at their limit. So every partner gets a bounded queue with a token bucket, and overflow sheds by class - rate quotes dropped, tenders deferred against their cut-off, and a tender that will miss its physical departure escalated to an alternate carrier instead of waiting.
Separate retryable from terminal. A partner rejection - embargoed lane, undeliverable address, expired account - is not a retry candidate; it goes to a dead-letter queue keyed by leg with the partner's raw error preserved, and the orchestrator sees a terminal failure it can re-source rather than a call that quietly never completes.

Follow-up

A partner has no idempotency concept and no lookup by reference. What is left to you, and what do you hand to operations?
A stall lasts 40 minutes and 60,000 legs are queued. What do you cancel, what do you keep, and how do you avoid a thundering retry the moment the partner recovers?
Where is the line between the gateway retrying and the orchestrator re-sourcing, and who owns the cut-off decision?

Allocate through a regional failover with unknown replication state

Hard · failover · replication lag · consistency · durability

The inventory primary sits in one region with an asynchronous standby in another, typically 2 seconds behind. The region becomes unreachable at peak, with 3,000 allocations and 3,000 ATP reads per second in flight. Decide whether to promote, what happens to allocations that may have committed without replicating, and what ATP answers meanwhile. Then quantify the cost of making the allocation write synchronous instead, given today's 4 ms transaction and about 42 allocations per second on the hottest item-node pair.

Approach

Split the decision by operation class before touching the failover mechanics. ATP reads can move to the standby at once with a stated staleness, because a 2-second-old read only mis-advertises and the allocation write re-checks anyway. Allocations cannot: promoting an asynchronous standby discards up to 2 seconds of committed allocations, several thousand at this rate, and each one is a promise already made to a customer.
Recover those from the requester's durable intent, not from the database that just vanished. If the orchestrator wrote its saga step and an outbox row in one local transaction before calling, every lost allocation can be re-driven after promotion under its original idempotency key, and allocation's partial unique index makes a re-drive that did replicate fail closed instead of double-claiming. Without that intent record the loss is simply unrecoverable, and the honest design refuses allocations until the primary returns rather than pretending otherwise.
Price synchronous replication in the currency that actually binds, which is hot-row throughput rather than average latency. A cross-region synchronous commit adds tens of milliseconds inside the transaction, turning a 4 ms hold into roughly 65 ms and dropping one row from about 250 to about 15 allocations per second, below the 42 demanded - so the promotion tail becomes an outage every promotion. A synchronous standby in a second zone of the same region costs 1-2 ms, leaves the hold near 6 ms and the ceiling near 170 per second, still four times demand.
So the configuration is: synchronous in-region for zero data loss on a node or zone failure, asynchronous cross-region for the regional case, and promotion of the cross-region standby as a deliberate human decision with a written procedure. Automatic promotion of an asynchronous standby is how a regional blip becomes two primaries and a permanently split ledger that reconciliation cannot repair, because both halves are internally consistent.
Define the degraded contracts explicitly for the gap. ATP serves the conservative bucketed answer from the standby with staleness stated; allocate returns a typed unavailability so the orchestrator holds lines in sourcing rather than cancelling or retrying them into a storm. After promotion, replay the outbox, then run the reconciliation re-sum before any node's availability is trusted again, because the re-summed positions are the only evidence of what actually survived.

Worked solution (40 min)

Classify every operation as safe or unsafe on a 2-second-stale replica and write that classification down before choosing a failover posture.
Trace one allocation that committed a second before the outage through promotion, and name the exact durable record that lets you re-drive it.
Recompute the hot-row ceiling under in-region and cross-region synchronous commit and set both against the 42 per second demand.
Write the degraded contracts: what ATP returns, what allocate returns, and what the orchestrator does with each.
Write the post-promotion sequence - outbox replay, reconciliation re-sum, then re-enable - and say what is not trusted until it completes.

Expected result: Reads promoted immediately with stated staleness and writes not; lost allocations recovered by re-driving from the orchestrator's durable intent under their original idempotency keys; synchronous commit placed in a second in-region zone (hold about 6 ms, ceiling near 170 per second against 42 demanded) rather than cross-region (about 65 ms, ceiling near 15); and promotion as a deliberate decision followed by outbox replay and a reconciliation re-sum before availability is trusted.

Verify it yourself

Every allocation a customer was told about is either present after promotion or re-drivable from a record held outside the failed database.
The cost of synchronous replication is expressed as a change in the hot-row ceiling, not only as added average latency.
Nothing in the design permits the old primary and the promoted standby to accept allocations at the same time.
The degraded ATP answer errs toward under-promising and says so explicitly.

Follow-up

The old primary returns holding writes the standby never saw. What do you do with them, and what does the reconciliation job report about them?
How do you rehearse this? Describe a game day that exercises the promotion path without risking an oversell in production.
Which of the two regions' clocks do you trust for occurred_at ordering during the switch, and does it matter here?

One partner's leg statuses freeze while every other feed advances

Easy · poison message · head-of-line blocking · event ingest

Since 06:40 UTC no leg fed by one partner has changed status; every other feed is current. Ingest is healthy and CPU is flat, and observation_event rows from that source are still landing with current received_at and processing_status 'pending'. Consumer lag is growing on exactly one stream partition, whose head row has over 900 attempts and a byte-identical last_error on each one. Give the ordered diagnosis and the change that stops one unapplicable observation from stalling a partition again.

Approach

Separate the partner not sending from us not applying, because both look identical to a customer. Rows landing with current received_at and processing_status 'pending' prove ingestion is fine and the fold is stuck; if received_at had gone stale instead, this would be a partner or transport incident and nothing in the consumer would be at fault.
Read the blocked partition at its head, ordered by offset, and classify the error rather than counting it. An identical error string across 900 attempts is deterministic and implicates the payload; a varying set of connection resets, timeouts and 5xx implicates the downstream store. Only the deterministic case is a poison message.
Reproduce outside the consumer by running the fold over that one event. The usual cause here is an observed_status the partner added that has no rank in the progress lattice, or a subject_id whose leg does not exist yet, so the fold throws before it can write.
Decide the exit against the ordering contract, which is per subject and not per partition. Many legs hash into one partition, so blocking on one of them is a bug and not a guarantee. Park the row as processing_status 'rejected_malformed' with its offset in a dead-letter view, advance the offset, and block only the affected subject if the event is well-formed but not yet applicable.
Make the retry policy classify instead of counting. Deserialisation failures, unknown enum values and constraint violations are terminal and must never be retried in place; IO errors and timeouts are retryable with bounded attempts and backoff. Alert on oldest-pending age per partition, which turns positive within seconds, rather than on lag, which drifts up slowly and looks like normal backlog.

Follow-up

The parked event turns out to be a real delivered scan. How do you replay it after the code fix without double-applying, and what makes that safe?
What should the customer-facing status show for legs that were queued behind it?
The partition key is currently the leg id. What breaks if you key by partner instead, and what if you key randomly?

Suggested practice checklist

Roughly ninety minutes on weeknights with one longer weekend block. The plan cuts scope rather than compressing everything, on the assumption that one thing finished per night beats four half-started.

Day 1 — Fix the scope and take a cold baseline

Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list and keep it visible all week.
Take one twenty-five-minute coding problem and one fifteen-minute design prompt cold, and write the single sentence naming what blocked each, because those two sentences decide where the remaining evenings go.
Set the week's rule: one thing finished every night, including the night you only have forty minutes.

Deliverable: A one-page scope with a not-doing list and two cold attempts, each carrying one sentence on what blocked it.

Day 2 — One pattern, written three times from blank

Choose the single pattern most likely to appear in your loop and write it three times from an empty file rather than editing the previous attempt.
On the third pass, write the invariant as a comment before the loop body and the complexity before the first line of code.
Stop at ninety minutes even if the third version is imperfect, and write the one thing you would fix given another hour.

Deliverable: Three independent implementations of the same pattern plus a note on what changed between them.

Day 3 — One design, only to the depth you can defend

Take one system shape and go only as far as requirements, interface and data model, refusing to draw a box you could not survive a follow-up about.
Attach one number to each non-functional requirement, deriving it rather than asserting it, and write the assumption the number rests on.
Write the one tradeoff you are choosing against and the observation that would make you reverse it.

Deliverable: One design at interface-and-schema depth with derived numbers and one written reversible tradeoff.

Day 4 — Only the fundamentals you will have to defend

Write, in under two hundred words each, the answers to the two questions that follow almost any implementation: why this structure and not the obvious alternative, and what happens to this code at a hundred times the input.
Write what an index actually costs: faster lookups on the indexed columns against a write that now maintains a second structure, plus the cases where the planner declines to use it anyway, low selectivity, or a predicate wrapping the column in a function.
Delete any answer you cannot deliver aloud in under a minute, since an answer that needs reading is not an answer you have.

Deliverable: Three written answers, each under two hundred words and each timed aloud.

Day 5 — Your own work, timed

Write a ninety-second and a four-minute version of your main project and time both aloud rather than reading them.
Prepare the two follow-ups that always come: what you would do differently, and how you knew it worked.
Put one number in the first sentence and be ready to say exactly where it came from and what it excludes.

Deliverable: Two timed narratives with one defensible number in the opening line.

Day 6 — The one full rehearsal, in the weekend block

Run a sixty-minute mock covering a coding round and a design round in one sitting with no break, because sustained attention is the thing evenings have not trained.
Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.

Deliverable: Mock notes naming three failure moments with a specific fix written under each.

Day 7 — Taper

Write the twenty-minute warm-up you will actually do on the morning: one problem you can already solve from a blank file, one design you can narrate, and nothing you have never seen.
Re-read only your own notes from this week and open no new material.
Write the logistics down: the editor or shared document you will be working in, whether execution and lookups are permitted, and the sentence you will use when you do not know something.

Deliverable: A one-page card holding the design structure, the project numbers, and the logistics.

The estimate and the day you knew

A slipped date is only a bad story if you sat on it. What matters is what you believed when you gave the number, the signal that told you it was wrong, how many days passed before you said so, and what you cut rather than asking for more time. Scope you defended counts as much as scope you dropped.

How do you handle complex tasks when working within a R&D-focused environment?

Medium · behavioural and engineering judgement

Approach

Name the disagreement and how you resolved it with evidence.
Give the blast radius: what could have broken, and what you measured.
State the situation in two sentences and spend the rest on the reasoning.

Follow-up

What did you decide not to do, and why?
How did you know your change caused the improvement?

Why did you decide to leave your last position?

Medium · behavioural and engineering judgement

Approach

State the situation in two sentences and spend the rest on the reasoning.
Name the disagreement and how you resolved it with evidence.
Give the blast radius: what could have broken, and what you measured.

Follow-up

How did you know your change caused the improvement?
What would you do differently if you ran that again?

What specific technical contributions are you most proud of in your career to date?

Medium · behavioural and engineering judgement

Approach

Pick a story where you made the decision, not one where you watched it.
Give the blast radius: what could have broken, and what you measured.
Close with what you would do differently, concretely.

Follow-up

What did you decide not to do, and why?
How did you know your change caused the improvement?