Daesung Electric Software Engineer Interview Guide

The 60-second brief

Daesung Electric makes electrical components and systems, and candidates describe the Software Engineer role as software that sits next to that hardware. The work they list spans embedded software that controls hardware, MS SQL databases that support manufacturing operations, and manual testing of the products and the software around them. The common thread is that your code is judged against physical behavior, so current, voltage and the mechanical form of the product are part of the conversation as well as the language you write in.

This guide is for candidates interviewing for a Software Engineer position at Daesung Electric, whether on the embedded, database or testing side, and whether experienced or early-career. It covers the four reported domain questions, the stack candidates list (Python, SQL, C/C++), the CAD assessment reported for junior applicants, and how to rehearse behavioral stories. It does not cover a specific team, because no team names are reported.

No named round sequence is reported. Candidates describe a deep-dive technical interview followed by management and compensation discussions for experienced hires, and several technical assessments, including CAD tests in Catia or Creo, for people early in their careers.

Focus areas

• Based on Software Engineer interviews across companies
• Problem Solving
• System Design

Overview

The role as candidates describe it is multidisciplinary. A single job might be firmware for a controller, schema and query work in MS SQL for manufacturing data, or a test suite and manual test plan for a product. The reported questions reflect that mix: they ask how current and voltage show up in software design, how plastic molding constraints and sheet metal design affect software, and what matters when you debug software that drives electrical hardware. None of them is a pure algorithm puzzle, so grinding only coding problems leaves a gap.

Prepare in two layers. The first layer is the language and tool fluency for your track: C or C++ for embedded work, Python for scripting and tooling, SQL for database roles, and a working vocabulary of testing methods. Candidates report topics such as real-time constraints and hardware-software communication for embedded work, query optimization and schema design for MS SQL, and reliability in manual or automated testing. The second layer is domain translation: being able to say what a voltage reading means, why a tolerance on a molded or bent part changes a software assumption, and how you would isolate a fault between code and hardware.

Reports also mention less common topics: integrating software with CAD-modeled physical parts and optimizing code for low-power or hardware-constrained targets. Early-career applicants report CAD tests using Catia or Creo, so if you are in that group, spend real time in one of those tools rather than assuming the software interview is the only gate.

Because a skill on your resume can be explored in depth, trim anything you cannot discuss at the level of trade-offs. Use the seven-day plan to build a short set of explanations you can give aloud, each starting from the physical or data requirement and ending at the software decision.

Where to focus your preparation

No named rounds are reported for Daesung Electric, so the guide uses a single preparation stage built from the loop shapes candidates describe for experienced and early-career applicants.

Preparation focus

Candidates do not report named rounds or an order, so confirm the format with your recruiter. What is reported differs by seniority. Experienced candidates describe a deep-dive technical interview followed by management and compensation discussions. Early-career candidates describe a more layered process with several technical assessments, including CAD tests in Catia or Creo. Treat the technical conversation as one that moves between code and the physical product: reported questions cover current and voltage in software design, plastic molding constraints, sheet metal design within an embedded environment, and debugging software that controls electrical hardware. Prepare each of those as a short spoken answer that starts from the requirement, states assumptions, and ends at a software decision you can defend.

What to demonstrate

• Fluency in the language and tools of your track: C or C++ for embedded work, Python, SQL or MS SQL
• Whether you can connect software behavior to electrical parameters and mechanical constraints
• Testing and debugging method for software that touches hardware

How to prepare

• Ask the recruiter which track the role is on (embedded, MS SQL database or testing), whether a CAD test applies, and where the role is based
• Refresh Ohm's law, power as voltage times current, and how an analog reading becomes a value your code uses, then explain the current and voltage question aloud
• Write a repeatable debugging sequence for hardware-controlled software and rehearse it against the debugging question
• If you are early-career, practice basic part modeling in Catia or Creo so the CAD assessment is not your first exposure

Where candidates lose points

Answering the current and voltage question with textbook definitions and no software consequence

State the relationship (voltage equals current times resistance, power equals voltage times current), then tie it to code: scaling an ADC reading into volts or amps, setting over-current and under-voltage thresholds, filtering noisy samples, and deciding what the software does when a limit is crossed.

Debugging hardware-controlled software by guessing and changing code

Practice a fixed sequence: reproduce the fault, record the inputs and outputs around it, check power and wiring or a known-good unit before blaming logic, change one variable at a time, and confirm the fix by removing it and seeing the fault return.

Giving a generic "add an index" answer on an MS SQL question

Talk through reading the execution plan, spotting scans and key lookups, writing predicates that can use an index, choosing key and included columns, and keeping statistics current. For schema design, cover keys, constraints and data types for production or test records.

Staying silent or bluffing on plastic molding, sheet metal or CAD topics you have not worked with

Say what you know, then reason from the interface: which dimensions, tolerances or material limits the software consumes, and who owns them. Name the questions you would ask the mechanical engineer. Remove tools from your resume that you cannot discuss in depth.

Behavioral stories that say "we" throughout and never show your own decision

Use STAR with a specific personal action and a measured result. Pick stories from the boundary of software and hardware, a test failure, or a database slowdown, and name the trade-off you weighed.

Questions & practice

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Explain the relationship between electrical parameters like current and voltage in your software designs.

Medium · Technical Domain Knowledge

Approach

1. Anchor on the physics the code depends on: V = I x R and P = V x I (so resistive loss is I^2 x R). Then say where each quantity enters the software: a value you measure, a limit you enforce, or an output you command.
2. Show the measurement chain end to end. A 12-bit ADC count becomes volts as raw x Vref / 4095 (or / 4096, per the datasheet's convention). Shunt current is I = Vsense / (Rshunt x amplifier gain). Calibrate the zero-current offset, and treat a full-scale reading as clipped, not as a true value.
3. On the control side, PWM duty cycle sets the average voltage the load sees (about D x Vsupply for a resistive load). Clamp commanded duty so the resulting current stays inside the component and wiring ratings.
4. Protection logic: give overcurrent and undervoltage thresholds hysteresis so they do not chatter, add a blanking window or I^2t-style accumulation so inrush current does not trip a fault, and decide whether a fault latches off or retries.
5. Numeric trade-offs: fixed-point vs float on a small MCU, a filter (moving average or IIR) chosen against sample rate and the response time protection needs, and units carried in names (mV, mA) so scaling bugs stay visible.

Follow-up

• Walk me through converting a raw 12-bit reading from a current-sense amplifier into milliamps, including the offset.
• A load draws a large inrush at switch-on and your overcurrent check trips. How do you fix it without hiding a real short?
• Why would you put hysteresis on a brownout threshold, and how do you pick the band?

How do you account for Plastic Molding constraints when designing software for manufacturing?

Medium · Technical Domain Knowledge

Approach

1. Clarify scope first: software that records and controls the molding process (machine and quality data), or firmware for a product that sits in a molded housing. Answer the one asked, and mention the other briefly.
2. For process software, name the parameters that decide part quality: melt and mold temperature, injection and hold pressure, cooling time and cycle time. Then tie them to the defects they cause when out of window: short shots, flash, sink marks, warpage.
3. Data design: one row per shot keyed by machine, mold, cavity and a monotonically increasing shot counter, with spec limits stored per part number and mold. Version the limits by effective date so old shots are judged against the limits active when they ran. Index on (mold_id, shot_time) for the usual queries.
4. Quality logic: alarm on any shot outside its limits, and track drift with SPC. Use X-bar/R charts for trends and Cpk = min(USL - mean, mean - LSL) / (3 x sigma) for capability. Link part or lot IDs to their shots for traceability.
5. For a product in a plastic housing, the constraint flows the other way. The resin's temperature rating and the wall thickness cap how much heat the electronics may dissipate, so firmware may need thermal derating and a temperature-based shutdown.

Follow-up

• Write the SQL to find, per mold, the shots in the last 24 hours whose hold pressure fell outside that mold's active limits.
• A machine resends shot records after a network drop. How do you keep the inserts idempotent?
• A new mold insert changes the acceptable cycle time. How does your schema handle limits that change over time?

Describe your approach to Sheet Metal Design integration within an embedded environment.

Medium · Technical Domain Knowledge

Approach

1. Restate the problem as the enclosure's effect on the electronics and firmware. A sheet-metal housing changes grounding, EMI, heat, radio performance and how connectors, switches and LEDs line up with cutouts.
2. Electrical side: bond the board's chassis ground to the enclosure at defined points, give ESD a path to chassis rather than through signal lines, and keep seams and apertures small enough that the shield still works. Firmware backs this up with CRCs on serial links and retry logic, so a noise burst costs a retry, not a corrupted command.
3. Radio and sensing: a closed metal box blocks RF, so a wireless module needs an external antenna or an aperture, verified by measuring signal strength in the closed enclosure. Steel parts can also skew Hall-effect or magnetic sensors, so calibrate those in the final assembly, not on a bare board.
4. Thermal: the metal can act as a heat spreader if the hot parts are thermally coupled to it. Log on-board temperature at maximum load inside the closed enclosure, and set firmware derating or shutdown thresholds from that data.
5. Process: review the CAD model with the mechanical engineer for connector and cutout positions, standoff heights and tolerance stack-up. Settle the ground-bonding and antenna positions before the sheet-metal layout is frozen, because moving a hole later costs far more than changing code.

Follow-up

• The device's wireless link works on the bench but drops once the lid is closed. What do you check, and in what order?
• How would you implement a lid or door interlock so a firmware bug cannot leave the hardware in an unsafe state?
• Which measurements would convince you that the enclosure is doing its job as a heat sink?

What are the primary considerations when debugging software that controls electrical hardware?

Medium · Technical Domain Knowledge

Approach

1. Safety first: set a current limit on the bench supply, isolate any mains or high-voltage section, and know which outputs could move a motor or energise a load before you single-step code that drives them. A breakpoint can freeze a PWM output in its on state.
2. Split hardware from software with measurements. Check the supply rails with a meter or scope, then compare what the pin actually does (oscilloscope or logic analyzer) with what the firmware believes it wrote. A swap to a known-good board separates a unit defect from a code defect.
3. Check configuration before logic: clock tree, pin multiplexing, GPIO mode and pull-ups, peripheral enable bits and the datasheet errata. Many 'the code is wrong' bugs are a misconfigured peripheral.
4. Look for timing and concurrency faults. These include shared data between an ISR and main code without atomic access (volatile stops the compiler from caching a value but does not make access atomic), stack overflow, and watchdog resets. Read the reset-cause register on boot and log it.
5. Mind the observer effect: printf in an ISR changes timing and can hide the bug. Prefer toggling a spare GPIO, a RAM trace buffer or a hardware trace. Correlate faults with electrical events such as motor start or relay switching, which point to brownout, ground bounce or EMI rather than logic.

Follow-up

• The controller resets only when the motor starts. How do you tell a brownout from EMI from a firmware fault?
• The bug disappears when you add debug prints. What does that tell you, and what do you do next?
• How would you test the overcurrent fault path without damaging hardware?

Suggested practice checklist

The plan starts by confirming your track, then builds electrical and embedded fundamentals, debugging method, MS SQL work and mechanical context, and ends with behavioral stories and a spoken dry run of the four reported questions.

Day 1 — Confirm your track and audit your resume

• Write the questions to send your recruiter: which track the role is on, whether a CAD test applies, the sequence of interviews, and location requirements
• List every language, tool and domain on your resume and mark each one you could discuss for ten minutes; plan to cut or refresh the rest

Deliverable: A written list of recruiter questions and an annotated skills list with each item marked ready, refresh or remove.

Day 2 — Electrical fundamentals for software engineers

• Write one page covering Ohm's law, power as voltage times current, voltage dividers and pull-up resistors, and how an ADC count converts to a voltage
• Outline a spoken answer to the current and voltage question that ends with thresholds, filtering and fault handling in code
• Say the answer aloud and note every place you used a term you could not define

Deliverable: A one-page formula sheet and a written outline of the spoken answer to the current and voltage question.

Day 3 — Embedded and constrained-code fundamentals

• Review C or C++ topics for embedded work: volatile, interrupt handlers sharing data with the main loop, fixed-width integers, fixed-point arithmetic and state machines
• Explain polling versus interrupts and how a watchdog timer and low-power sleep modes change design choices

Deliverable: A short written sheet of embedded concepts with an example for each, plus a solved memory-limited practice problem.

Day 4 — Debugging software that controls hardware

• Write a numbered debugging sequence: reproduce, capture signals and logs, isolate software from hardware with a known-good unit or simulated input, change one variable, confirm
• Apply the sequence to two invented faults, such as a sensor value that drifts after warm-up and a relay that chatters

Deliverable: A debugging checklist, two worked fault walk-throughs and a rehearsed spoken answer.

Day 5 — MS SQL query and schema work

• Practice reading an execution plan and explaining a scan versus a seek and a key lookup
• Design a small schema for production or test records, with keys, constraints and the indexes your main queries need

Deliverable: Solved SQL practice problems and a schema sketch with its main queries and supporting indexes.

Day 6 — Mechanical context and testing

• Outline answers to the plastic molding and sheet metal questions: which dimensions, tolerances and material limits the software consumes, and the questions you would ask a mechanical engineer
• Write a short test plan for a firmware feature covering normal, boundary, fault and power-cycle cases, and say what you would automate
• If you are early-career, spend a session modeling a simple part in Catia or Creo

Deliverable: Written outlines for the plastic molding and sheet metal questions, a test plan, and, for early-career candidates, a modeled part.

Day 7 — Behavioral stories and a full dry run

• Run a spoken dry run of all four reported questions back to back, then note the two weakest answers
• Write two questions to ask about current technical challenges and team workflow

Deliverable: Three written STAR stories, a recorded or timed dry run of the four reported questions, and two questions for the interviewers.

Behavioral prep: stories from the software and hardware boundary

Candidates report using the STAR method (Situation, Task, Action, Result) for behavioral answers, with the focus on your own contribution. For this role, build stories at the boundary between software and physical systems, or around testing and database problems, and be ready to explain the reasoning behind each technical decision and its trade-offs.

1. Tell me about a bug you traced to the boundary between software and hardware, and how you proved where it lived.
2. Describe a time you turned a requirement from a mechanical or electrical engineer into a software constraint or design decision.
3. Walk me through a database or query performance problem you diagnosed: the symptom, what you read, the change you made and the measured result.
4. Describe a test failure you could not reproduce at first and how you made it reproducible.
5. Tell me about a skill on your resume that someone explored in depth, and what you did when you reached the edge of what you knew.

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

• What would you do differently in the first five minutes, given the same dashboard and no more information?
• Which follow-up action did you deliberately not take, and why was dropping it the right call?

Reverse your own decision and price the reversal

Medium · reversibility · measurement · migrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach

1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.

Follow-up

• What in that decision was irreversible, and did you know it was irreversible when you made it?
• How did you tell the people who had already built on top of the original decision?