Akron Polymer Products Software Engineer Interview Guide

The 60-second brief

Akron Polymer Products appears in candidate reports as an injection molding business. Software Engineers there are described as building and maintaining the software behind molding operations. Reported duties include production-cycle monitoring, quality-control tooling and sensor data work. The role is described as working closely with Injection Mold Process Engineers, who know the physical limits of the machines, while the software engineer turns those limits into digital workflows. Candidates also describe owning a project through to deployment and later maintenance.

This guide is for Software Engineer candidates preparing for the two reported stages: a single interview session and a tour of the production floor. It covers the motivation and behavioural questions candidates report, the topic areas they describe (process automation, system reliability, cross-functional communication), how to turn your past projects into answers, and a seven-day plan. The preparation here centres on stories, reasoning and questions rather than algorithm drills.

Candidates report two rounds over roughly 2-4 weeks: one comprehensive interview with two interviewers covering technical capability and cultural fit, then a production floor tour. A decision is reported to follow about a week after the interview.

Focus areas

• Software Engineering (general)
• Interview Communication (Q&A)
• Question Asking & Requirements Clarification

Overview

The work described for this role sits between software and a physical process. Reported duties include production-cycle monitoring, quality-control tooling and sensor data work, done alongside Injection Mold Process Engineers, with the engineer owning the project through to deployment and maintenance. For preparation, this means every project you discuss should be told with the physical or operational consequence visible: what the software touched, what happened when it was wrong, and who relied on it.

Candidates report three topic areas: process automation, system reliability and cross-functional communication. For automation, have a before-and-after story: a manual step or data-collection chore you removed, how you checked the automated version matched the manual one, and what it saved. For reliability, be ready to reason about software that has to stay up while equipment keeps running: what happens when a sensor reading is late, missing or implausible, how you roll out a change without interrupting production, and how you would find out something had silently stopped working. For communication, practise explaining a technical limit to someone who does not write code.

The reported questions are why you want to work here, what interests you about the intersection of software and injection molding, and how you handle an environment that bridges office-based engineering and production-floor realities. Reported scenarios add troubleshooting a software issue that affected a physical process and keeping code maintainable for other engineers. Vague enthusiasm answers none of these. Learn enough about how injection molding is done to ask informed questions, connect your own projects to the reported duties, and keep a short list of questions for the tour. SQL is the one listed stack topic, so also be comfortable describing how you would read per-cycle records out of a relational store for a quality report.

The Akron Polymer Products interview process

Candidates describe two stages: a single comprehensive interview session, then a tour of the production floor. The descriptions below are what candidates report, not a published process.

Comprehensive Interview

Candidates report one comprehensive session with two interviewers that covers both technical capability and cultural fit. The reported topic areas are process automation, system reliability and cross-functional communication, and the reported questions are about motivation and about handling the office-and-floor divide. Approach it as a structured conversation about your own work: have a small set of projects you can explain end to end, and answer each question by naming the decision you made, why you made it and what changed as a result.

What to demonstrate

• Technical capability as shown through projects you built and the design choices behind them
• Motivation for software work tied to injection molding
• Reported areas: process automation, system reliability and cross-functional communication

How to prepare

• Write a one-page sheet for each of three or four projects: the problem, your design, the alternative you rejected and why, and the outcome
• Prepare spoken answers to why you want to work here and what interests you about the intersection of software and injection molding, each tied to a specific reported duty such as sensor data, production monitoring or quality control
• Rehearse a troubleshooting story about software that affected a physical process, and a concrete answer on keeping code maintainable for other engineers
• Prepare one example of explaining a technical requirement or limit to a non-technical colleague

Production Floor Tour

The second reported stage is a tour of the production floor. Candidates report it as a chance to ask the engineering team about day-to-day challenges, and reports say engagement during it is taken as a sign of interest. Treat it as a working conversation in the setting the role operates in. Look at how the equipment is arranged and how people interact with it, and let that prompt specific questions about how software and process engineers work together.

What to demonstrate

• Interest in the manufacturing side of the work, as reported for this stage
• A chance to ask the engineering team about day-to-day challenges, as reported
• A reported motivation question asks how you handle bridging office and floor

How to prepare

• Write four or five specific questions that name the plumbing. Molding machines commonly connect through PLCs and controllers, with OPC UA or Euromap 77 (Euromap 63 on older machines), into an MES or historian and a SQL store. Ask which of these the team uses and how process engineers hand over requirements
• Prepare a question on what the team does when a monitoring tool or data feed stops reporting, and one on how per-cycle records are queried from the relational store for quality reports
• Read a plain-language overview of how an injection molding cycle runs and what quality problems look like, so your questions use the right vocabulary
• Prepare your answer on bridging office-based engineering and production-floor realities as a story with a real person on the operations side

Where candidates lose points

Answering why you want to work here with general enthusiasm for manufacturing or for the company's size

Name the specific work: production monitoring, quality control, sensor data integration or working beside Injection Mold Process Engineers. Link each to a project of yours so the answer shows you have done something similar.

Telling a troubleshooting story that stays inside the code and never reaches the physical process

State the physical symptom, how you separated a software fault from a sensor, machine or process cause, what evidence you used, the fix, and the check you added so it could not recur silently.

Treating the production floor tour as a break between interviews

Candidates report that engagement during the tour counts as a sign of interest. Bring four or five questions about data flow, handoffs between process and software engineers, and failure handling, and refer back to what you see.

Describing projects by tools and tasks without explaining why you chose the approach

Your own projects are the material under discussion, so your design reasoning is the evidence. For each project, state the alternatives, why you chose one, what it cost and the effect it had, and say what you would change now.

Answering the maintainability question with slogans like clean code and good documentation

Give concrete practices from your work: naming and module boundaries, tests around the parts that touch hardware or data feeds, a runbook for whoever is on call, review habits and a handover you actually gave.

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?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

• The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
• How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

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?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Why do you want to work here?

Medium · Cultural Alignment and Motivation

Approach

1. Anchor the answer in the work as candidates describe it: software for injection molding operations covering production monitoring, quality control and sensor data, built alongside Injection Mold Process Engineers. Pick the one part that actually draws you and say why, instead of praising the company.
2. Back it with one short piece of your own history: a tool you built that changed an operational outcome, such as removing a manual data-entry step or catching bad output earlier. For example: "I replaced hand-copied machine readings with a logging script, and I want more work where the result shows up on a line, not only on a dashboard."
3. Explain why this role over a pure software job: the feedback loop runs to physical parts, you work next to process engineers, and candidates describe owning a project through deployment and maintenance. Give a concrete reason for each point. A list of adjectives is not a reason.
4. Only make claims you can back up. Do not cite products, customers or numbers you have not checked. If you researched the company, say what you read and what question it left you with. That question is also one to bring to the Production Floor Tour.
5. Finish by saying what you would want to learn first, for example how sensor and cycle data reach software today and who uses it on the floor.

Follow-up

• What do you already know about injection molding, and how did you learn it?
• Why move from a software-only environment to one that sits next to a production floor?
• What part of this job do you expect to find hardest in your first few months?

What interests you about the intersection of software and injection molding?

Medium · Cultural Alignment and Motivation

Approach

1. Show a working model of the process. Each cycle runs clamp, inject, pack/hold, cool and eject. Each shot produces measurable parameters (melt and mold temperature, injection speed and pressure, hold time, cooling time, cushion, total cycle time) that software can record per cycle and link to the part that cycle made.
2. Go deep on one intersection rather than listing many. A good one is per-cycle capture plus statistical process control. Chart a parameter such as cushion or peak injection pressure on an individuals chart and set limits from a stable baseline. Estimate sigma from the average moving range (MR-bar divided by 1.128), not the overall standard deviation, because drift inflates the latter and widens the limits. Three-sigma limits alone are slow to reveal small sustained drift, so add run rules (Western Electric or Nelson) or an EWMA or CUSUM chart to flag it before it becomes short shots, flash or sink marks. Control limits describe the process; spec limits describe the part. Keep the two apart.
3. Cover reliability, which candidates report as a discussion area for this role. Software next to a running line has to survive dropped readings and network outages. Buffer data locally, timestamp it where it is read, and make ingestion idempotent. Shot counters can reset after a controller restart, a mold change or a rollover, so key each reading on machine, mold or job, shot counter and controller timestamp (or a collector sequence ID). Keying on machine plus cycle number alone would merge distinct cycles as duplicates after a reset, while this key still lets a re-sent batch be recognised.
4. Be honest about your background. If you have no manufacturing experience, name your closest analogue (event pipelines, device telemetry, monitoring and alerting) and say what you would need to learn from the process engineers, such as which parameters actually predict a bad part on a given mold.
5. Avoid buzzwords with no data story behind them. If you bring up predicting defects, say what the label would be (scrap or good part, and who records it), which features you would use, and how you would check alerts against what operators actually saw before anyone relies on them.

Follow-up

• A machine's scrap rate rises overnight with no setting changes. How would you use cycle data to find the cause?
• How would you keep a floor-side data collector working, without losing or duplicating readings, when its network link drops for an hour?
• How would you explain a control-chart alert to an operator or process engineer who does not write code?

Read latency spikes on a sixty-second sawtooth

Medium · cache stampede · single-flight · ttl

The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.

Approach

1. Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
2. Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
3. Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
4. De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.

Follow-up

• The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
• How does your answer change if the recompute takes 4 seconds instead of 250 ms?

Suggested practice checklist

The plan follows the two reported stages: a comprehensive interview built on your own projects and a production floor tour. It spends the days on project stories, the reported motivation and behavioural questions, reliability reasoning and questions to ask.

Day 1 — Map the loop and the role

• Write the two reported stages and what each asks of you: a conversation about your work, then a floor tour
• List the reported duties (production cycle monitoring, quality control, sensor data integration, working with process engineers) and note which of your projects match each
• Compare yourself against the nice-to-have areas candidates describe, industrial automation, manufacturing processes and hardware-software interfacing, and mark the gaps you must explain honestly

Deliverable: A one-page loop map with a duty-to-project matching table and a list of gaps.

Day 2 — Build your project sheets

• Choose three or four projects and write one page each: the problem, your design, the alternative you rejected, the outcome and what you would change
• Mark where each project touched an operational or physical consequence, and add the people who depended on it
• Rehearse explaining each design choice out loud, since your past projects are the main material reported for the interview

Deliverable: Three or four project sheets, each with a rejected alternative and a stated outcome.

Day 3 — Motivation answers

• Read a plain-language overview of how injection molding works and write down the terms you do not know
• Write and then speak your answer to why you want to work here, tied to one or two reported duties and one of your projects
• Write and speak your answer to what interests you about the intersection of software and injection molding, with a specific example of software affecting a physical outcome, such as per-cycle capture feeding a control chart

Deliverable: Two spoken answers recorded, plus a glossary of molding terms for the tour.

Day 4 — Troubleshooting a software issue that hit a physical process

• Write the story in STAR form: the physical symptom, how you separated software cause from sensor, equipment or process cause, the evidence, the fix and the safeguard you added
• Prepare for follow-ups: what you would have done if the fix failed, and how you would have spotted the issue earlier

Deliverable: A written troubleshooting story with the diagnostic steps numbered, plus the practice question's reasoning.

Day 5 — Bridging office and production floor

• Write your answer on handling an environment that bridges office-based engineering and production-floor realities, with a named colleague from the operations side and what you learned from them
• Write a technical requirement or limit of yours in plain language for a non-technical colleague and check it contains no jargon

Deliverable: One spoken story on the office-to-floor question and one jargon-free explanation.

Day 6 — Reliability, automation and maintainability

• List the failure cases for software that monitors running equipment: late, missing or implausible sensor readings, a stalled data feed, a counter reset, a bad release, and for each the safe behaviour and the alert
• Write the before-and-after story of something you automated, including how you proved the automated result matched the manual one
• Write your concrete answer on keeping code maintainable for other engineers, with tests, runbook and handover examples.
• Prepare one ownership story that runs from inception through deployment and maintenance, and say who kept using the result

Deliverable: A failure-case table, an automation story, a maintainability answer with examples and an end-to-end ownership story.

Day 7 — Full dry run and tour questions

• Run a mock with a friend playing two interviewers, covering the motivation questions, one troubleshooting story and one project deep dive
• Finalise four or five tour questions, including the machine-interface and data-store questions, and mark which ones you would change depending on what you see
• Review your project sheets once more and rehearse the three reported behavioural questions in order

Deliverable: A completed mock with feedback notes, and a final list of tour questions.

Behavioural preparation

The reported behavioural questions ask for evidence that you can work between engineering and operations: why this work, how you handle the office-and-floor divide, how you diagnosed a physical-impact problem, how you kept code maintainable and how you worked with non-engineers. Use STAR and spend most of the time on your actions and reasoning.

1. Why do you want to work here?
2. What interests you about the intersection of software and injection molding?
3. Describe a time you had to troubleshoot a software issue that was impacting a physical process.
4. How do you ensure your code is maintainable for other engineers?
5. Tell me about explaining a technical requirement or limit to someone who does not write code, and what changed afterwards.

How do you handle working in an environment that bridges office-based engineering and production-floor realiti

Medium · Cultural Alignment and Motivation

How do you handle working in an environment that bridges office-based engineering and production-floor realities?

Approach

1. Choose a story with two audiences: you on the engineering side, and operators, technicians or process engineers on the other. If you have no factory experience, use the nearest equivalent, such as a warehouse, lab, support or operations team that ran on your software, and say plainly that it is an analogue.
2. Use STAR but spend most of the time on Action. Show how you went to see the real process before changing anything: watched it run, sat with the people operating it, and read the logs or readings that showed what actually happened. The point is that you checked the requirement against reality.
3. Show translation in both directions: how you turned a physical constraint into a software requirement, and how you explained a software limit (a delay, a failed read, a release window) in terms the other side could act on without jargon.
4. Show change safety where a mistake costs physical output: staged rollout, a manual fallback, checking the new logic against recorded data before it went live, and how the people on the floor were told. Name the mechanism you used.
5. Finish with the result and a habit you kept, such as visiting the source of the data before writing an integration. Use a number only if it is real. The story fails if the other side is portrayed as people who do not understand technology, or if nobody from the floor appears in it.

Follow-up

• Tell me about a time a production-side requirement conflicted with what you thought was good engineering. How did it end?
• A release is ready but the line is running. What do you check, and who do you speak to before deploying?
• How do you learn a physical process you have never seen before building software for it?

Estimate work you have never done and defend the range

Hard · estimation · backfills · expand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach

1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.

Follow-up

• How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
• Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

• Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
• The author says clients cannot handle a 409. How do you check whether that is true?