A. O. Smith Software Engineer Interview Guide

The 60-second brief

A. O. Smith makes residential and commercial water heating equipment and water treatment products. Candidates describe the Software Engineer role as spanning connected-home features on the iCOMM platform, tooling for factory-floor improvement and water heater firmware. They report working alongside mechanical, quality and manufacturing engineers, with Milwaukee, WI and Ashland City, TN named as locations.

This guide is for candidates interviewing for a Software Engineer opening at A. O. Smith. It covers the three reported rounds, the coding, design and behavioral questions candidates report, and a seven-day plan that practises them. The stack candidates describe is Java, C#, Python or C++ depending on the team, AWS or Azure, REST APIs and relational databases, with IoT, embedded work and MQTT listed as extras.

Candidates report three rounds over roughly 3-5 weeks: a Recruiter Screen, a Technical Screening and a Panel Interview that mixes system design, deeper coding and behavioral questions.

Focus areas

• Software Engineering (General)
• Product Engineering
• Quality Engineering (General)

Overview

The reported question set is practical rather than puzzle-driven. The coding examples are merging two sorted telemetry logs by timestamp, parsing a stream of sensor readings and raising an alert after three consecutive readings above a threshold, and a rate limiter for an internal API. The data-structure toolkit behind them is small: two pointers, a heap for merging more than two sources, a counter that resets on a miss, and a queue or token bucket. Write each one cleanly in the language you are strongest in, with named variables and tests for empty input, ties and out-of-order data.

The design questions lean on connected devices: monitoring the health of thousands of commercial water heaters, device registration through an event-driven service, a caching layer in front of a primary database, and the security of an API for a smart home device. Candidate tips stress offline modes and intermittent connectivity, and candidates report a question about firmware over-the-air updates for devices that lose Wi-Fi. For every design, say what a device does while it cannot reach the cloud, how a retried message avoids double-applying, and how a device proves who it is.

The remaining questions test engineering judgement you can only answer from experience: zero-downtime database migrations, optimizing a slow query, unit testing code that depends on hardware APIs, prioritizing technical debt, and working with engineers outside software. Candidates describe those colleagues as mechanical, quality and manufacturing engineers, so prepare stories where you translated a software limitation for a non-software audience. Prepare the slow-query, migration and technical-debt items as decisions you made, with a measurement before and after. For testing against hardware APIs, bring a concrete seam you introduced and the failure cases it caught.

The A. O. Smith interview process

Candidates describe three stages. The sequence and the contents of each stage below are what they report, and the panel is described as usually virtual or onsite.

Recruiter Screen

Candidates report an opening conversation about your background, where you would be willing to work and a high-level look at your technical experience. Treat it as the round where your story has to be short, concrete and consistent with your CV, and where logistics get settled before the technical stages.

What to demonstrate

• How your background maps to a Software Engineer opening
• Fit with the locations and working model on offer
• A high-level picture of the languages and platforms you have used

How to prepare

• Write a short walk through your CV that names the languages and platforms you have genuinely shipped with, matched to the stack candidates describe: Java, C#, Python or C++, AWS or Azure, REST APIs and relational databases.
• Ask which site and team the opening is in and whether it is remote, hybrid or onsite, since candidates report that roles tied to hardware testing or manufacturing may need presence on site.
• Prepare a short, honest reason for being interested in connected water heating products, after reading about the iCOMM platform and the product lines.

Technical Screening

Candidates report a conversation with a hiring manager or a senior engineer about your past projects and architecture decisions, followed by a light coding or technical Q&A session. For specialized roles such as IoT or embedded work, candidates say the questions can turn to domain topics. The practical way to prepare is to be able to defend your own designs and to have a few fundamentals ready to say aloud.

What to demonstrate

• Ability to explain the architecture decisions in your own past projects
• Working code on a small problem, if a coding portion is included
• Fundamentals you can state precisely when asked

How to prepare

• Pick two projects and write down, for each, the main design decision, the alternative you rejected, what failed in production, and what you changed afterwards.
• Rehearse small coding tasks on streams and sorted data, such as the telemetry log merge, until you can write them with edge cases in one pass.
• Practise out loud the fundamentals this guide lists: protocol trade-offs for devices, testing around hardware dependencies, and database changes on a live system.

Panel Interview

Candidates describe a panel that spans system design, deeper coding and behavioral or leadership questions, held virtually or onsite, and some report meeting engineers from adjacent disciplines. Because several areas arrive in one stage, practise switching between a whiteboard design, a coding exercise and a personal story without losing structure.

What to demonstrate

• System design for connected devices, covering ingestion, APIs and security
• Deeper coding with attention to structure, naming and edge cases
• Collaboration across disciplines and handling of setbacks

How to prepare

• Draw the device fleet monitoring design from scratch, then repeat it with the added requirement that devices lose connectivity for hours and reconnect with a backlog.
• Rewrite the sensor-threshold alert and the rate limiter behind a clean class or function boundary, then refactor each once for readability.
• Prepare four stories using the situation, task, action, result structure: working with a non-software team, a deadline compromise, technical debt versus features, and critical review feedback.

Where candidates lose points

Answering the zero-downtime migration question with a single ALTER and a maintenance window

Describe the expand/contract sequence: add the new shape, dual-write, backfill in batches, switch reads behind a flag, drop the old shape last. State that old and new application versions run together during a rolling deploy, and that DDL needs a lock timeout so it cannot block traffic.

Designing the device monitoring or registration system as if every heater is always online

Cover what a device does while disconnected: buffer readings locally, send with timestamps and sequence numbers, retry with idempotency keys, and let the cloud mark a device stale by last-seen time. Mention how firmware updates resume after a dropped connection.

Saying 'I would mock the hardware' without explaining how

Describe the seam: a small interface around the hardware API, a fake that can simulate timeouts, malformed replies and disconnects, tests of your logic against the fake, and a thin set of tests against a real or simulated device to check the fake matches reality.

Merging the two telemetry logs by concatenating and sorting, or missing edge cases

Use two pointers over the already-sorted inputs for linear time and constant extra space beyond the output. State the tie rule, handle one input running out and empty inputs, and mention a heap for merging many logs. Test each case out loud.

Telling behavioral stories in the plural, with no clear decision of your own and no result

For every story, write one sentence that begins 'I decided' and one measurable result. Cover the four reported themes: working with a non-software team, a deadline compromise, debt versus features, and critical review feedback.

Questions & practice

Write an algorithm to merge two sorted logs of telemetry data based on timestamps.

Medium · Technical and Coding

Approach

1. I confirm the contract first: each log is already sorted by timestamp, both use one clock and zone (I normalise to UTC epoch if not), and I ask whether equal timestamps, or the same reading appearing in both logs, can occur.
2. Two pointers, one per log: compare the heads, emit the smaller, advance that pointer; when one log runs out, append the rest of the other. That is O(n + m) time, and written as a generator it needs O(1) extra memory beyond the output.
3. On a tie I take from the first log (compare with <=), which keeps the merge stable; if the same reading can appear in both logs, I break ties by device id or sequence number and drop exact duplicates as I emit.
4. Edge cases I test: either log empty, both empty, one log entirely earlier than the other, long runs of equal timestamps, and an input that is not actually sorted, which I detect by comparing each timestamp with the previous one from the same log and then raise or route aside.
5. For k logs I generalise with a min-heap of (timestamp, log index, position): O(N log k) time and O(k) memory. In Python, heapq.merge(*logs, key=...) does this lazily.

Follow-up

• The logs are multi-gigabyte files on disk: how does the merge change, and what does its memory use depend on?
• Devices buffer readings while offline and upload them late: how would you merge a live stream instead of two finished logs?
• How would you test this function, and which generated inputs would you use?

Explain the differences between TCP and UDP, and when you would use each in an IoT context.

Medium · Technical and Coding

Approach

1. TCP is connection-oriented: a three-way handshake, then a reliable, ordered byte stream with acknowledgements, retransmission, flow control through the receive window and congestion control, on a header of at least 20 bytes. UDP sends independent datagrams with an 8-byte header and no delivery, ordering or duplicate guarantees, but it preserves message boundaries and needs no connection setup.
2. The cost of TCP on a constrained device: handshake round trips (plus TLS on top), per-connection state, and head-of-line blocking, where one lost segment holds back everything behind it until it is retransmitted.
3. I use TCP where every message must arrive intact and in order: control commands, configuration changes and firmware images. MQTT, the common publish/subscribe protocol for device-to-cloud messaging, runs over TCP, usually with TLS.
4. I use UDP where the newest value supersedes a lost one or latency matters more than completeness: frequent sensor samples, local discovery (mDNS and SSDP use UDP multicast), and constrained links running CoAP, which sits on UDP, offers optional confirmable messages and is secured with DTLS.
5. If I pick UDP but need some reliability, I say what I would add: sequence numbers, application-level acks with retries and backoff, idempotent message ids, and payloads small enough to fit one datagram so IP fragmentation is avoided.

Follow-up

• What do MQTT QoS levels 0, 1 and 2 guarantee, and which would you choose for a temperature sample versus a shut-off command?
• A device on unreliable Wi-Fi holds a TCP connection open for days: how does each side detect that the connection is dead?
• Why is QUIC built on top of UDP rather than TCP?

How do you approach writing unit tests for code that relies heavily on external hardware APIs?

Medium · Technical and Coding

Approach

1. I put the hardware behind an interface that the code under test depends on (a thin adapter or hardware abstraction layer) and inject it, so the logic never calls the vendor SDK or the serial port directly.
2. For most tests I use a stateful fake device (setpoint, current temperature, fault flags) rather than per-call mocks, and keep mocks for interaction checks such as asserting that a shutdown command was sent exactly once.
3. I spend most test cases on failure paths: timeouts, partial or corrupted frames with a bad checksum, a disconnect mid-transaction, out-of-range sensor values and busy or error codes, and I assert that the code retries, fails safe or reports the fault as designed.
4. I make time injectable (a fake clock and scheduler) so retry, backoff and polling logic run instantly and deterministically, with no sleep calls anywhere in the suite.
5. Unit tests cannot prove the fake behaves like the real device, so I add contract tests that run the same assertions against the fake and against a real unit or recorded traces, and keep hardware-in-the-loop tests in a separate CI stage.

Follow-up

• The vendor SDK exposes static functions and global state: how do you create a seam without rewriting it?
• How would you test code that depends on interrupt timing or on the order of callbacks from the device?
• A test passes against the fake but the feature fails on a real heater: how do you find the cause and stop it recurring?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Design a system to monitor the health and status of thousands of commercial water heaters deployed globally.

Medium · System Design and Architecture

Approach

1. I scope it first: which signals (temperature, operating status, fault codes, heartbeat), who consumes them (a fleet dashboard, alerts to service staff, history for analysis) and how fresh an alert must be; then I do the load arithmetic aloud as devices x messages per interval x payload size.
2. Ingest: each device keeps an outbound TLS connection, authenticated with its own certificate, to an MQTT broker or managed IoT gateway in its region; messages land on a stream partitioned by device id so one device's readings stay ordered.
3. Processing splits three ways: a last-known-state store keyed by device id for the dashboard, a time-series store partitioned by device and time (raw data kept briefly, downsampled rollups kept longer), and a stateful rule engine that raises alerts.
4. Health is more than the absence of errors: I track last-seen per device, mark it offline after several missed heartbeats (an MQTT Last Will message covers unclean disconnects), keep offline separate from faulted, and add hysteresis and deduplication so a flapping device does not raise repeated alerts.
5. For intermittent connectivity, devices buffer readings locally with sequence numbers and upload the backlog on reconnect; ingestion is idempotent on (device id, sequence), each reading carries its device event time so late data lands in the right window, and reconnects use jittered exponential backoff to avoid a thundering herd.

Follow-up

• A cloud region is unavailable for an hour: what do the devices do, and what happens when they all reconnect?
• How would you detect a heater that reports normally but whose temperature sensor is drifting?
• Storage grows with the fleet: what do you keep raw, what do you downsample, and for how long?

How would you design a caching layer to reduce load on our primary database during peak usage hours?

Medium · System Design and Architecture

Approach

1. Before adding a cache I find out what the peak load is: which queries dominate, the read/write ratio, how skewed the keys are, and how much staleness each query tolerates. An index, read replicas or a materialised view may fix it more cheaply.
2. Default design: cache-aside with Redis or Memcached in front of the database. A read checks the cache and on a miss queries the database and sets the key with a TTL; a write commits to the database and then deletes the key rather than updating it.
3. I name the race: a slow reader can miss, read the old row, and write it into the cache after the writer's delete. A short TTL bounds that window; for data that must never be stale I version the keys or do not cache it.
4. Peak-hour stampede protection: single-flight rebuilds (one request recomputes a hot key while others wait or receive the stale value), jittered TTLs so keys do not expire together, and pre-warming known hot keys before the peak.
5. Failure mode: if the cache is unreachable the database must not absorb the full load at once, so I add short timeouts, a circuit breaker and load shedding. I size memory from the working set, use LRU eviction, and monitor hit ratio, evictions and database queries per second.

Follow-up

• One key, such as a fleet-wide summary, receives most of the reads: how do you stop its cache node becoming the bottleneck?
• The cache is flushed in the middle of the peak: what happens to the database, and how do you recover?
• When would you choose write-through or write-behind over cache-aside?

Walk me through how you would architect an event-driven microservice to handle device registration.

Medium · System Design and Architecture

Approach

1. I lay out the flow: a device ships with a unique identity (serial number plus a certificate or secret), a user claims it from the app, and the registration service validates the claim, writes the device record and owner link, and publishes a DeviceRegistered event.
2. To avoid a dual write between the database and the broker I use the transactional outbox pattern: the device record and the event row commit in one transaction, and a relay publishes outbox rows to the topic.
3. Delivery is at least once, so every consumer (credential provisioning, notifications, the device-state read model) is idempotent, recording processed event ids or upserting by serial number. Partitioning the topic by device id keeps each device's events in order.
4. I model registration as a state machine (unclaimed, pending, active, deregistered) and cover the awkward cases: the same serial claimed twice, a device resold to a new owner, and a claim that expires before the device first connects.
5. Operations: a dead-letter queue with alerting for poison messages, versioned event schemas that only change additively, and a correlation id carried from the app request through every event for tracing.

Follow-up

• Credential provisioning succeeds but the notification consumer keeps failing: what does the user see, and how does the system recover?
• A new service needs every device registered so far: how do you backfill it from the event history?
• Why not have the registration service call the other services synchronously instead?

What are the key security considerations when designing an API for a smart home device?

Medium · System Design and Architecture

Approach

1. Two kinds of caller, two identities: users authenticate with OAuth 2.0 / OpenID Connect using short-lived access tokens and refresh tokens; each device has its own certificate or key for mutual TLS, never a secret shared across the fleet, so one compromised unit can be revoked alone.
2. Authorization on every object: each request checks that the caller owns, or has been granted, that specific device id. Broken object level authorization is the first item in the OWASP API Security Top 10, and here it would let one user control another person's heater.
3. Commands are validated on the server and again on the device: setpoints within safe bounds, scopes that separate read from control, idempotency keys and timestamps to reject replayed commands, rate limits per user and per device, and an audit log of every change.
4. Network shape: the device keeps an outbound TLS connection to the cloud and receives commands over it, so no inbound port is opened on the home network; any local LAN interface also requires authentication.
5. Lifecycle: firmware images are signed and verified on the device before install, keys can be rotated and revoked, an ownership transfer revokes the previous owner's tokens, and usage data is treated as personal because it reveals when a home is occupied.

Follow-up

• Private keys for a batch of devices leak from the factory: how do you detect misuse and recover?
• A third-party smart-home platform wants to control heaters on users' behalf: how do you grant, scope and revoke that access?
• How would you secure the firmware update path end to end?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.

Approach

1. Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
2. Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
3. Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
4. Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.

Follow-up

• The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
• You now count takeovers. What alert fires on that counter, and at what threshold?

Suggested practice checklist

The plan follows the three reported rounds: logistics and your own projects first, then data and coding fundamentals, then the IoT-flavoured design questions, and finally a full mixed rehearsal of the panel.

Day 1 — Map the loop and your own material

• Write the three reported rounds in order and note what each covers, then mark the one you are least ready for.
• Write a short CV walk-through that names the languages and platforms you have shipped with, using the stack candidates describe.
• Choose two past projects and write the main design decision, the rejected alternative and what failed for each.

Deliverable: A one-page loop map, a written CV script, and two project notes with decision, alternative and failure.

Day 2 — Database changes and slow queries

• Write an expand/contract plan for adding a column to a table that serves live traffic, listing each deploy and its rollback.
• Write out your slow query story with the symptom, the EXPLAIN evidence, the fix and the before and after numbers.

Deliverable: A step-by-step migration plan with rollbacks, a solved practice exercise, and a one-page slow query story with figures.

Day 3 — Coding on telemetry streams

• Implement the merge of two sorted timestamped logs with two pointers, with tests for ties, empty input and one log ending early.
• Extend it to merge many logs with a heap and state the time complexity in terms of total entries and number of logs.
• Write a stream function that raises an alert after three consecutive readings above a threshold, and a token-bucket rate limiter, each with tests.

Deliverable: Three working functions in your main language: the log merge, the threshold alert and the rate limiter, each with a short test list.

Day 4 — Protocols and testing around hardware

• Write a one-page comparison of TCP and UDP for a device sending periodic readings, covering delivery, ordering, overhead and when each fits.
• Write a small class that wraps a hardware API behind an interface and test it with a fake that simulates timeouts and bad replies.
• Practise saying both answers aloud and trim whatever rambles.

Deliverable: A one-page protocol comparison, a tested wrapper class with its fake, and a recorded spoken answer for each question.

Day 5 — Design a device fleet and its registration

• Draw the monitoring architecture for thousands of water heaters: ingestion path, storage, alerting, and how stale devices are detected.
• Draw the event-driven device registration service, including duplicate events, retries and failure handling.
• Design firmware over-the-air updates for heaters that often lose Wi-Fi: signed images, resumable chunked download, A/B partitions with rollback and a staged rollout.

Deliverable: Three labelled design diagrams with a failure list for each, plus a written debugging sequence from the practice exercise.

Day 6 — Caching and securing a device API

• Design a caching layer for a primary database under peak load: what to cache, invalidation, and what happens on a cache outage.
• Write a security checklist for a smart home device API covering device identity, user authorization, transport encryption and abuse limits.

Deliverable: A caching design with failure modes, a one-page API security checklist, and the solved concurrency practice exercise.

Day 7 — Behavioral stories and a mixed panel rehearsal

• Write situation, task, action, result outlines for working with a non-software team, a deadline compromise, debt versus features and critical feedback.
• Record yourself telling each story and cut anything that does not describe your own decision or a measured result.
• Run a mixed rehearsal: one design question, one coding exercise and one story in sequence, without stopping to look anything up.

Deliverable: Four written story outlines with a result each, four recordings, and a notes page from the mixed rehearsal listing your weakest transitions.

Stories for cross-team and quality-minded rounds

The behavioral and leadership portion of the panel is reported to cover collaboration across disciplines, deadline trade-offs, technical debt and receiving critical feedback. For a role that links software with physical products, prepare stories where you changed your plan because of someone else's constraints and where you made a reliability decision under pressure.

How do you handle database migrations in a production environment with zero downtime?

Medium · Technical and Coding

Approach

1. Start from the constraint: during a rolling deploy, old and new application versions hit the same schema at once, so every intermediate schema must work for both. That rules out one-step renames, drops and type changes and points to the expand/contract pattern.
2. Expand: add the new nullable column or table without rewriting existing rows (check this for your engine and version), set lock_timeout on the DDL so it fails fast instead of queueing behind a long transaction and blocking all traffic, and build indexes without a write lock, for example CREATE INDEX CONCURRENTLY in PostgreSQL.
3. Migrate: release code that writes both the old and new shapes, then backfill old rows in small primary-key batches with pauses, idempotent and resumable, while watching replication lag and lock waits. Check row counts or checksums before reads move.
4. Switch and contract: put reads behind a feature flag so rollback is a flag flip, stop writing the old shape, and drop it in a later release. The destructive step goes last because it is the only one you cannot undo.
5. If asked as a story, name the table, its row count, your migration tool and what a plain ALTER would have broken. For device data, add that older firmware may keep sending the old payload shape, so the old field stays accepted until that fleet is gone.

Follow-up

• How would you backfill a 500-million-row table without causing replication lag or lock contention?
• The new code has a bug after you dropped the old column. What was your rollback plan before that step?
• How do you rehearse the migration against production-sized data before running it?

Describe a time you had to optimize a slow-performing query or application feature.

Medium · Technical and Coding

Approach

1. Open with the symptom and a number: which page, job or endpoint, what the latency or timeout was, who noticed. Then say you measured before changing anything, using EXPLAIN ANALYZE, the slow query log, a profiler or APM traces, to find the real bottleneck.
2. Name the actual cause: a sequential scan on a filtered column, an index that existed but could not be used, an N+1 pattern from an ORM, a sort spilling to disk, lock waits, or oversized payloads. Say how you ruled out the other candidates.
3. Describe the fix and its price: a composite index with equality columns before range columns and the extra write cost, a batched query replacing a loop, keyset instead of offset pagination, or a cache and the staleness you accepted.
4. Close with before and after on the same measurement, tested at production-like data volume, and the guard you left behind such as an alert, a regression test or a query-plan check in review. Use your own real numbers.
5. The story sinks if the answer is 'I added an index' with no evidence it was the cause or that it fixed anything.

Follow-up

• How did you know the database was the bottleneck and not the application code?
• What did your fix cost on writes, and who else could it have affected?
• How did you make sure the slowdown did not return?

Tell me about a time you had to work with a team outside of software engineering to deliver a project.

Medium · Behavioral and Leadership

Approach

1. Choose a project where the other team's constraints were different from yours, such as a quality, manufacturing, hardware, operations or finance group. Candidates describe this role as working with mechanical, quality and manufacturing engineers, but any real cross-discipline project fits.
2. Say what each side needed. Name their constraints concretely (a test schedule, a safety rule, a line that cannot stop, a unit of measure) and the vocabulary gap between you, rather than saying communication was a challenge.
3. Describe the mechanism you built: a shared requirements page with worked examples, an agreed interface or data format, a demo on their real data, or acceptance criteria they signed off on. This is the decision you made.
4. Show one disagreement settled with evidence, such as a measurement, a prototype or a log, rather than escalation. End with the result and what you now do differently when you start a project with a non-software team.
5. The common mistake is casting the other team as the obstacle or saying 'I explained it to them'. Show that you changed your plan because of their constraints.

Follow-up

• What did you learn about their constraints that you did not know at the start?
• How did you explain a software limitation to someone without a software background?
• How did the two teams agree on what done meant?

Describe a situation where you had to make a technical compromise to meet a strict deadline.

Medium · Behavioral and Leadership

Approach

1. Pick a real deadline with a real consequence, and state it in a sentence. Then list the options you had, so the compromise reads as a chosen trade-off between alternatives and not as the only path.
2. Be exact about what you cut and why that part was safe: a feature scope, a second code path, an optimisation, a manual step instead of automation. Also state what you refused to compromise, such as data integrity, security checks or test coverage on the risky part.
3. Show you made the debt visible: a ticket with an owner, a note to the product owner or stakeholders about the risk, and a monitor or alert that would reveal if the shortcut started to hurt.
4. Close with what happened: the release shipped, the debt was repaid (say when and how), or it caused a problem and you handled it. Say what you would do differently.
5. The answer fails if the compromise was simply sloppy work, if it hid a risk from stakeholders, or if you claim it had no downside.

Follow-up

• How did you decide which corner was safe to cut and which was not?
• Was the shortcut repaid, and who made sure it happened?
• What would you have refused to cut, even under the same deadline?

How do you prioritize technical debt versus building new features?

Medium · Behavioral and Leadership

Approach

1. Give the principle first: debt is worth paying when it charges interest. Sort items by evidence of cost, such as repeated incidents, slow changes in one module, flaky tests and onboarding friction, and leave dormant code that nobody touches alone.
2. Quantify so the trade-off is not an opinion: hours lost per sprint, number of incidents traced to the area, or how many planned features run through that code. Put the figures in front of the product manager in delivery terms.
3. Use the rules you would actually apply: fix debt in the area a feature is about to change, agree a standing share of capacity for maintenance, and treat reliability or security debt as a priority regardless of the feature queue.
4. Back the framework with one real example where you paid down debt and one where you deliberately left it, and what each decision showed afterwards.
5. Avoid both extremes, 'features always come first' and 'refactor everything'. Both show you have not had to negotiate scope with someone.

Follow-up

• The product manager says no to your refactor. How do you make the case?
• How do you measure whether paying the debt worked?
• Tell me about debt you chose not to fix and why.

Tell me about a time you received critical feedback on a design or pull request. How did you handle it?

Medium · Behavioral and Leadership

Approach

1. Choose feedback that was substantive: a flawed data model, a missing failure mode, an approach that would not scale, or a risk in a pull request. Naming or style comments are too small to show anything.
2. Describe your first response: you asked questions until you understood the concern, separated the technical point from the tone, and checked the claim yourself by reproducing a case, writing a quick benchmark or reading the code path.
3. Say what you did with the result. If the reviewer was right, show the change you made and thank them; if you disagreed, show how you argued with evidence and reached an agreement without escalation.
4. State what changed in your habits afterwards, such as sharing a design note before coding, adding a checklist item or asking for early review on risky parts.
5. The answer fails if the story is about a reviewer who was wrong and you won, or if the tone is defensive. Show the outcome for the code or product, not just for your mood.

Follow-up

• What if you had still disagreed after checking the evidence?
• How has that experience changed how you review other people's code?
• What did you change in the next design you wrote?