Averypartners Software Engineer Interview Guide

The 60-second brief

Averypartners works in the materials science industry. Candidates describe its software engineers building and maintaining the systems behind supply chains, manufacturing processes and the delivery of materials to clients, including software that has to connect to physical manufacturing and distribution systems. The role covers both older legacy systems and new platforms. Engineers work in cross-functional teams with product managers on feature specifications and with operations teams on integration. The responsibilities candidates list run from requirements gathering to deployment and maintenance, plus code reviews, mentoring junior engineers, architecture discussions and documentation.

This guide is for software engineers preparing for an Averypartners loop. The five reported questions are mostly about your own experience: a complex challenge you solved, debugging code you did not write, depth in a language, keeping code scalable and maintainable, and learning a technology under a deadline. The guide also covers the technical task or coding session that candidates say some teams run. The reported topics are behavioral interviewing, communication, interpersonal judgment, critical thinking and resume review, so most of the preparation here starts from your own projects.

Candidates report a process that usually starts with a recruiter screen, moves to technical assessments, and finishes with conversations with hiring managers and cross-functional team members. They say it takes roughly 3 to 6 weeks from application to decision.

Focus areas

• Behavioral Interviewing
• Communication Skills
• Interpersonal Skills / Interpersonal Judgment

Overview

Engineers at Averypartners write software for an industrial business. Candidates describe systems for supply chains, manufacturing and distribution that connect to physical production, and work that splits between legacy systems and new platforms. In practice your code has users outside software, such as operations teams. Some of what you touch will be older code that nobody on the current team wrote. The reported debugging and maintainability questions come straight from that situation.

The reported questions focus on your experience more than on puzzles. Four of the five ask about something you have done: a hard technical problem, a debugging approach, your history with a language such as Java or JavaScript, and a time you learned a tool under deadline pressure. Resume review is one of the reported topics, and candidates say interviewers follow up on the specific decisions in past projects. Your resume works as the syllabus. Every project on it needs a decision you can defend, an alternative you rejected and a result you can put a number on.

The technical side changes by team. Candidates report either a technical task or a coding session, with an emphasis on problem-solving approach over syntax. The listed areas are code quality, data structures, algorithm efficiency and frameworks from the job description. The example scenarios include optimising a given function and designing a system for a stated data volume or constraint. Prepare one language well enough to explain why a HashMap lookup is constant time on average, or why a nested loop over two lists becomes quadratic. Also practise talking through a small design that has to handle a stated load.

Candidates say they met engineering managers and project leads, and in some loops plant or operations managers. Answers that work for one engineer can lose an operations listener. Practise explaining each story twice: once with the technical detail, and once in terms of the operational result, such as fewer manual steps, faster order processing or a shorter outage on a line.

Where to focus your preparation

Candidates describe the order and format as changing by location and team, so this guide treats the reported recruiter screen, technical assessments and stakeholder conversations as one preparation stage.

Preparation focus

Candidates report a recruiter screen first, then technical assessments, then conversations with hiring managers and cross-functional team members. They name engineering managers, project leads and sometimes plant or operations managers among the people they met. Depending on the team, the technical part is either a task to complete or a coding session. Candidates also report detailed questions about the projects on their resume. Prepare in three layers. First, a resume you can defend line by line. Second, written answers to the five reported technical and domain questions. Third, enough hands-on practice in one language (Java and JavaScript are the examples the role gives) that you can optimise a function out loud. At the recruiter screen, ask which technical format your team uses and who you will meet, then weight the rest of your preparation accordingly.

What to demonstrate

• Whether you can explain the decisions behind the projects on your resume, which candidates report being asked about in detail
• Working, readable code and an account of its efficiency in the technical task or coding session some teams use
• Whether you can explain technical work clearly to engineering managers, project leads and, in some loops, operations staff

How to prepare

• Ask the recruiter whether your team runs a technical task or a live coding session, which language you may use, and which stakeholders are on the panel
• Write a one-page resume map: for each project, the problem, your own decision, the alternative you rejected, and a measured result
• Rehearse the five reported Technical and Domain Knowledge questions aloud, from the complex-challenge story to the debugging walk-through
• Optimise two or three functions in Java or JavaScript out loud: state the current complexity, find the bottleneck, swap in the better data structure, and re-state the complexity

Where candidates lose points

Being unable to explain a project on your own resume past its headline: why a component was built that way, what you owned, what the numbers were.

Go through every resume bullet and write down the problem, your decision, the alternative you rejected and the measured result. If you cannot fill those in for a bullet, rewrite it or remove it, since resume review is a reported topic.

Telling the complex-challenge or learn-on-the-fly story as 'the team did it', with long background and no decision of your own.

Keep the situation to two sentences, then describe what you chose, what you rejected and why, using 'I'. End with a number and one thing you would change.

Answering the unfamiliar-codebase question with 'I would add print statements until I found it' or 'I would rewrite the module'.

Give a sequence: reproduce and minimise, trace the path from the entry point, check git history and bisect, write a failing test, fix, then ask the owner a specific question if you are still stuck.

Answering the language-experience question with a list of frameworks and no depth, then failing a basic follow-up on HashMap behavior or the JavaScript event loop.

Pick the language you know best and rehearse its core mechanics (collections, concurrency, async model) together with one project where each one mattered. If your experience with the named language is thin, say so plainly.

Explaining a technical result to a project lead or operations manager in pure engineering terms, so the business effect gets lost.

For every story, prepare a version that leads with the operational result (fewer manual steps, faster order handling, less downtime) before the technical detail. Candidates report meeting non-engineering stakeholders in some loops.

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?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

1. Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
2. Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
3. Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
4. Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

• The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
• The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

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?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

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?

Can you walk us through a complex technical challenge you solved in a previous project?

Medium · Technical and Domain Knowledge

Approach

1. Choose a problem with a real constraint, such as a slow batch job, a flaky integration or a data migration with no downtime allowed, where you made the main call yourself. Describe the situation in two sentences, then spend most of the answer on the reasoning.
2. State the options you considered and why you rejected each one. For example: 'I could have scaled the job horizontally, but the bottleneck was N+1 queries, so I batched the lookups into one IN query and added an index on order_id.'
3. Give a measured result: runtime before and after, error rate, hours saved for the operations team. Say how you verified it, for example load test, before/after metrics or a canary.
4. Close with what you would do differently. That shows you can judge your own work, and it gives the interviewer an obvious place to dig deeper.
5. Use 'I' for your own actions and name the people you worked with. A story told entirely as 'the team did X' hides your contribution, and resume review is a reported topic.

Follow-up

• Which alternative came closest to winning, and what would have made you choose it?
• How did you confirm the fix caused the improvement and not some other change shipped at the same time?
• What would break first if the input volume grew tenfold?

How do you ensure your code is scalable and maintainable for future team members?

Medium · Technical and Domain Knowledge

Approach

1. Answer with practices you actually use and show one example of each. Small modules with one responsibility and clear interfaces. Meaningful names. Design patterns only where they remove coupling, for example strategy for interchangeable pricing rules or dependency injection so that a hardware or ERP client can be replaced with a fake in tests.
2. Keep maintainability safe with tests and process: unit tests on business rules, integration tests at system boundaries, CI that runs them on every change, and code reviews focused on readability and risk. Code reviews and mentoring are both listed responsibilities, so have a review story ready.
3. Treat scalability as something you measure. Profile before optimising, then use the standard levers: stateless services that scale horizontally, pagination and indexes on hot queries, caching with a clear invalidation rule, and queues to absorb bursty work.
4. Write down why, not only what: a README for setup, a short architecture decision record for non-obvious choices, and comments only where the code cannot explain itself.
5. Name the trade-off: early abstraction and speculative generality make code harder to change. A good rule is to abstract on the second or third real use case, not the first.

Follow-up

• Tell me about an abstraction you removed because it made the code harder to change.
• How would you start improving a legacy module that has no tests and that production depends on?
• How would you know whether a codebase is getting more or less maintainable over time?

Can you explain a time you had to learn a new technology on the fly to meet a project deadline?

Medium · Technical and Domain Knowledge

Approach

1. Use STAR, but keep the Situation short and spend most of the Action on how you learned. Name the technology, the deadline pressure and why the existing tools would not work.
2. Show a learning method: official documentation and a getting-started tutorial, a small spike that proves the one capability you needed, existing uses of the tool in the codebase, and a short session with someone who already knew it.
3. Show how you managed the risk. Limit the scope to the subset of the tool the project needed, raise the risk with your lead early, and keep a fallback in case the spike failed.
4. Give a concrete Result: shipped on the date or not, what broke after launch, and what you did next, such as a cleanup pass, tests you added or a write-up so teammates could maintain it.
5. The mistake that sinks this story is presenting heroics as a plan: late nights with no communication, or no admission of what you got wrong in the first version.

Follow-up

• What did you get wrong in your first version because you were new to the tool?
• How did you check that your code followed the technology's conventions, not just that it worked?
• What would you have done if the spike showed the tool could not meet the deadline?

How do you approach debugging code when you are unfamiliar with the existing codebase?

Medium · Technical and Domain Knowledge

Approach

1. Reproduce the bug before reading much code. Get the exact input, environment and steps, and reduce them to the smallest failing case. Without a reliable reproduction, every theory you form is a guess.
2. Find the entry point for the failing behavior (HTTP handler, scheduled job, message consumer) and trace the call path with a debugger breakpoint or targeted logging. Read only the code on that path, not the whole repository.
3. Use the history: run git log and git blame on the files involved, check recent deploys and config changes, and run git bisect between a known-good and a known-bad commit when a regression is likely.
4. Read the existing tests for the module to learn its intended contract, then write a failing test that captures the bug before changing any code. That test becomes the proof of the fix.
5. Timebox solo investigation, then ask the code owner a specific question ('this cache is never invalidated on update; is that intended?'). Afterwards, write down what you learned for the next person, since documentation is part of the role.

Follow-up

• The bug only happens in production and you cannot reproduce it locally. What do you do next?
• How do you debug an intermittent failure that looks like a race condition?
• The module has no tests at all. How do you change it safely?

Suggested practice checklist

The plan starts with your resume, because candidates report detailed resume review. It then works through each reported question, the coding fundamentals listed for the technical stage, and the stakeholder conversations, and ends with a full rehearsal.

Day 1 — Confirm the format and map your resume

• Email the recruiter to ask whether your team uses a technical task or a live coding session, which language you may use, and who is on the panel.
• Write a resume map: for each project, the problem, your decision, the rejected alternative and a measured result.
• Write your answer to the language-experience question for your strongest language, with one project behind each claim.

Deliverable: A recruiter email asking about the format, a one-page resume map, and a written language-experience answer.

Day 2 — Build the complex-challenge story

• Pick the hardest technical problem on your resume map and write it as STAR, keeping the Situation to two sentences and including at least two rejected options.
• Write a second story about a decision you reversed, including what it cost to undo.
• Record yourself telling both stories, then cut every sentence that does not describe a decision or a result.

Deliverable: Two STAR stories (complex challenge and reversed decision) and a recording of each.

Day 3 — Debug code you did not write

• Clone an unfamiliar open-source repository in your main language, pick a closed bug issue, check out the commit before the fix, and reproduce the bug.
• Find the cause by tracing from the entry point and using git log, blame or bisect, and write a failing test before looking at the real fix.
• Turn the process into a five-step spoken answer to the debugging question.

Deliverable: A reproduced bug with a failing test, and a five-step debugging answer you can say aloud.

Day 4 — Coding fundamentals and function optimisation

• Solve the idempotency-fingerprint and merged-event-stream practice problems in your interview language, stating time and space complexity aloud.
• Take a function you wrote with nested loops and rewrite it using a hash map or a sort, then explain the before and after complexity.
• Revise the core mechanics behind your language answer: HashMap internals and concurrency for Java, or the event loop and promises for JavaScript.

Deliverable: Two solved practice problems with complexity notes, and one before-and-after optimisation write-up.

Day 5 — Scalable and maintainable code, and designing for volume

• Write your answer to the scalable-and-maintainable question, with one real example each for module design, tests, reviews and documentation.
• Work the keyset-paging and per-tenant cap SQL practice problems, and note the index and the concurrency control each one depends on.
• Outline a small design for a stated load, for example order events from several plants: the components, where the data is stored, the index or queue that absorbs growth, and what fails first at ten times the volume.

Deliverable: A written maintainability answer, two solved SQL problems, and a one-page design outline.

Day 6 — Learning under pressure and stakeholder communication

• Write the learn-a-technology-on-the-fly story, focusing on how you learned, how you managed the risk and what you cleaned up afterwards.
• Prepare a code-review disagreement story and a peer-feedback story, and write the review comment you actually left.
• Rewrite your two strongest stories as a version for an operations manager that leads with the operational result.

Deliverable: A learn-on-the-fly STAR story, two feedback stories, and two operations-facing versions of your main stories.

Day 7 — Full rehearsal

• Have a friend ask all five reported questions in random order, with follow-ups taken from this guide, and record the session.
• Solve one unseen coding problem aloud in the format your recruiter confirmed.
• Write three questions for your interviewers about the team's systems, such as how much of the work is legacy and how software is released to plants.

Deliverable: A recorded mock with notes on the weakest answer, one solved coding problem, and three questions for your interviewers.

Behavioural preparation

Candidates report behavioral interviewing, communication, interpersonal judgment, critical thinking and resume review as the topics for this role, and say interviewers ask for specific examples of past contributions. Prepare stories in which you made the call, can name what it cost, and can explain the result to an engineer and to an operations stakeholder.

1. Can you walk us through a complex technical challenge you solved in a previous project?
2. Can you explain a time you had to learn a new technology on the fly to meet a project deadline?
3. Tell me about feedback from a peer on your code that you disagreed with at first. What did you change, and what did you keep?
4. Describe a time you had to tell a project lead or operations stakeholder that a delivery was at risk. How did you explain the blocker, and what did you offer instead?
5. Tell me about a junior engineer you helped through a review or a first feature. What did you change in how you explained things?

What is your experience with [specific technology/language, e.g., Java, JavaScript]?

Medium · Technical and Domain Knowledge

Approach

1. Fill the bracketed slot with the language on the job description you know best, and state your level honestly: years, project types, and the version you used. Then back every claim with a specific project.
2. For Java, be ready to go below the surface: how HashMap uses hashCode and equals (and why overriding one without the other breaks lookups), when to choose TreeMap or LinkedHashMap, ConcurrentHashMap compared with a synchronized map, ExecutorService for thread pools, and garbage collection pauses you have actually seen.
3. For JavaScript, be ready to explain the event loop: promise callbacks run as microtasks before the next setTimeout macrotask. Also cover async/await error handling with try/catch, closures (var compared with let in a loop), and how 'this' is bound in arrow functions compared with regular ones.
4. Name a framework or library you used with it and one trade-off you hit, for example ORM convenience against hand-written SQL for a reporting query.
5. If the slot names a language you have not used much, say so and map it to one you know well. Bluffing on a detail is easy to expose in a follow-up.

Follow-up

• What happens if you put a mutable object in a HashSet and then change a field used in its hashCode?
• In what order do console.log calls inside a setTimeout, a resolved promise's then and synchronous code run?
• What do you dislike about this language, and how do you work around it?

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?

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?