cross-ING Software Engineer Interview Guide

The 60-second brief

Candidates describe cross-ING as an engineering firm building industrial and robotic solutions, where software is tied closely to mechanical execution. The Software Engineer openings they mention are titled Full Stack Senior Software Developer and Software-Ingenieur:in Robotics, the German title for a robotics software engineer. In this role you write code, take part in code reviews and architectural planning, and work alongside mechanical and systems engineers so that software features match the physical requirements of a project.

This guide is for a Software Engineer candidate at cross-ING, on either the full-stack or the robotics track. It covers the recruiter screening call and the technical assessments, the questions candidates report about their experience, a challenging project they led, the software development lifecycle in a team and debugging under a deadline, plus the design, refactoring and code-quality scenarios that appear in reports. The role lists C++, Python or Java as core languages, depending on the team.

Candidates report two rounds over roughly 2-4 weeks: a Recruiter Screening Call, then Technical Assessments that depend on the role. They describe the conversation as experience-based rather than built around theoretical puzzles.

Focus areas

• Full-Stack Development
• Robotics Software Engineering
• Engineering Experience Explanation

Overview

The reported questions are almost all about your own track record: talk about your previous experiences, explain your experience as an engineer, describe the most challenging technical project you have led, explain how you run the software development lifecycle in a team, and describe debugging a complex system under tight deadlines. None of these has a single correct answer, so preparation means building a small set of real projects you can tell precisely: what you owned, which decisions you made, which alternatives you rejected, and what changed as a result.

Candidates also report scenario questions that sit in the technical depth area: architecting a module for a new robotic system, refactoring a legacy codebase to improve performance, and keeping code quality high when errors are expensive. The areas listed for this stage are system design, debugging and troubleshooting, and development practices such as clean code, testing and documentation. Prepare each as a short, structured answer that you can give out loud and extend with a diagram or a concrete example from your own work.

The stack matters less than the integration. The role is described as software working closely with hardware, with regular syncs between software, mechanical and systems engineers, and the languages listed are C++, Python and Java. Decide early whether you are telling a full-stack story or a robotics story, pick the examples that fit that track, and be ready to explain a technical decision to someone outside your discipline. Candidates also report that stating your concrete role in past projects, not the team's, is what makes answers land.

The cross-ING interview process

Candidates report two rounds across about 2-4 weeks, a Recruiter Screening Call and then Technical Assessments. This is how candidates describe the process, not a published schedule, and scheduling can shift.

Recruiter Screening Call

Candidates report a first call with a recruiter about your background and your fit for the role. Treat it as the first delivery of your career story: the same narrative you will repeat in later conversations, so it should be clear and consistent. Say which track you are targeting (full-stack or robotics), which of C++, Python or Java you work in, and what you have personally shipped. Candidates are also advised to keep a written record of recruiter communication and to follow up if a reply is late, since schedules can change.

What to demonstrate

• Your background and fit for the role, as the call is described by candidates
• How clearly you summarise your engineering experience in your own role
• Whether your experience matches the full-stack or robotics direction of the opening

How to prepare

• Rehearse the answer to the question about your previous experiences until it names a track, two or three projects and your part in each
• Prepare the explanation of your experience as an engineer with one concrete outcome per project
• Map your languages and tools to the C++, Python and Java the role lists, and note where you have industrial or hardware-adjacent exposure
• Write a few questions about the team's current projects to ask, and confirm in writing what the rest of the loop contains

Technical Assessments

Candidates report role-specific technical assessments after the recruiter call. The format is described as experience-based dialogue more than puzzle solving, and the areas listed are system design, debugging and troubleshooting, and development practices such as clean code, testing and documentation. Example scenarios reported include architecting a module for a new robotic system, refactoring a legacy codebase for performance and assuring code quality when stakes are high. Prepare a worked story for each area and rehearse the questions about your most challenging led project, your team lifecycle and debugging under a deadline.

What to demonstrate

• System design: how you break a component into modules and reason about its architecture
• Debugging and troubleshooting: your method for isolating and fixing a production issue
• Development practices: clean code, testing and documentation habits
• Familiarity with the stack you claim, whether full-stack or robotics

How to prepare

• Outline a robotic-system module on paper: inputs from sensors or other components, the interface it exposes, how it reports and recovers from failure, and how you would test it without the hardware
• Write a refactoring story with a measured before and after, and the tests that protected behaviour while you changed the code
• Write your debugging sequence as steps: reproduce, narrow down what changed, form a hypothesis, test it, confirm the fix, prevent recurrence
• Practise explaining one technical decision to a non-technical listener in plain language

Where candidates lose points

Answering the experience questions as a recital of employers and technology lists

Pick two or three projects and give each a role, a decision, a rejected alternative and a result. Practise the answer to the previous-experiences question out loud until it names those projects in order.

Saying 'we' for the whole story, so your own contribution is invisible in the most challenging project you led

Write the project down with a column for what you personally decided, built or reviewed. Describe the team's work briefly and spend most of the answer on your part.

Describing the software development lifecycle as a textbook list of phases instead of how your team actually works

Walk through a real change from requirement to production: who wrote the requirement, how it was reviewed, which tests ran, how it was released, and how you found out it worked.

Debugging story with no method: a long account of the incident but no sequence of hypotheses and checks

Structure it as symptom, what changed, how you narrowed it down, the root cause, the fix, and the safeguard you added. State what you cut or deferred because of the deadline and what you recorded for later.

Treating the design and refactoring scenarios as pure software problems, ignoring hardware interfaces, testing without the device and the cost of failure

For a robotic-system module, say how it talks to the physical side, how it fails safe, and how you would test it in simulation or with mocks. For a refactor, name the metric you measured and the tests that protected behaviour.

Questions & practice

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

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

Approach

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

Follow-up

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

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Talk about your previous experiences.

Medium · Professional Experience & Background

Approach

1. Give a short reverse-chronological walk. For each role, say in one line which system you worked on, which languages you used (name C++, Python or Java where they apply, since the role lists them) and what you personally built. Then stop and offer to go deeper on one project.
2. Lead with the experience that fits the track you applied for. For a robotics opening, start with work that touched hardware, sensors, controllers or real-time constraints. For a full-stack opening, start with a feature you owned end to end, from the data model and API through to the UI.
3. Give one outcome you can check for each role, such as a latency, defect rate, uptime figure or delivery date you measured, and say how you measured it. Leave out adjectives about the team.
4. Keep your own work separate from the team's in every sentence. Say what you designed, wrote or decided, and name what others owned, so it is clear which part you can defend in depth.
5. End with why you are moving now. Name the specific step up between your past work and this role, for example going from pure software to integrating software with mechanical and systems engineers.

Follow-up

• Which of those projects would you want to go deeper on, and what was the hardest technical decision in it?
• What would your last team say was your biggest contribution, and what did you leave unfinished?
• Which stack choice from that role would you make differently today, and why?

What was the most challenging technical project you have led?

Medium · Professional Experience & Background

Approach

1. Pick a project that was hard for technical reasons and where you set the direction. Good examples are design choices with competing constraints, such as real-time deadline against throughput, consistency against availability, or safety margin against cycle time. Avoid a project that was hard only because of scope or staffing.
2. Tell it in five parts: context, constraint, options, decision, result. Name at least two alternatives you rejected and the concrete reason each one lost. For example, you dropped a polling loop for an event-driven design because of timing jitter, or you deferred a service split because the team could not run two deploy pipelines.
3. Make the leading concrete. Say how you split the work, which interfaces you fixed first so people could build in parallel (API contracts, message schemas, hardware interface definitions), and how you tracked and reduced the biggest technical risk.
4. Put numbers on the result and the cost. Give the metric before and after, say what slipped, and name the technical debt you chose to leave and how you planned to pay it down.
5. Be ready to go one level deeper on every component you name: its data flow, its failure modes and how it was tested. For robotics work that includes simulation or hardware-in-the-loop tests, so that every part of the story holds up to a depth question.

Follow-up

• If you started that project again tomorrow, which decision would you reverse, and why?
• Where did the design fail or come close to failing after release, and how did you find out?
• How did you handle an engineer on the team who disagreed with the architecture?

How do you approach the software development lifecycle in a team environment?

Medium · Professional Experience & Background

Approach

1. Walk through the cycle as you actually run it, stage by stage, and name what each stage produces. Requirements produce acceptance criteria. A design review for non-trivial changes produces a short design doc. Short-lived branches go through code review. CI runs the automated tests. Release happens in stages. Monitoring and a review close the loop after release.
2. Name the specific practices you have used and why. Examples: trunk-based development or short-lived feature branches; required review and green CI before merge; a test pyramid with many fast unit tests, fewer integration tests and a small number of end-to-end tests; and feature flags so that deploying code is separate from releasing it.
3. If you are applying to the robotics track, explain how the cycle changes when software drives hardware. Agree interface contracts early with mechanical and systems engineers, test in simulation and hardware-in-the-loop before field tests, and version firmware and software together so a field issue can be traced to an exact build.
4. Discuss the trade-offs instead of reciting a methodology. Sprints suit a team building features against a roadmap, while a Kanban-style flow suits a team with a lot of interrupt work. Add process where a mistake is expensive (safety-relevant code, shared interfaces) and cut it where it is cheap (internal tools).
5. Give one real example of the process at work: a review or test that caught a regression before release, or a gap that let one through, followed by the check you added to CI so it could not happen again.

Follow-up

• How do you handle a pull request that is too large to review properly?
• What do you do when a requirement changes halfway through an iteration?
• How do you decide which tests must pass before a release, and what can wait?

Describe a situation where you had to debug a complex system under tight deadlines.

Medium · Professional Experience & Background

Approach

1. Tell the story as a debugging sequence, not as an account of pressure. Start with the symptom and who was affected, then the first step you took to contain it (rollback, turning off a feature flag, failover, or a manual workaround on the machine) to buy time before searching for the root cause.
2. Show how you narrowed it down. Reproduce the problem first, then list what changed: code, config, a dependency, a hardware revision or the environment. Then bisect: git bisect between the last good and first bad build finds the culprit commit in about log2(n) test runs for n commits.
3. Show that you checked the evidence before trusting it. Line up logs and metrics by timestamp after confirming the clocks agreed. For concurrent or timing-sensitive code, note that adding logging or attaching a debugger can change the timing and hide a race, so you used low-overhead tracing, counters or ring-buffer logs.
4. Separate the fix you shipped for the deadline (a guard, retry, revert or config change) from the actual defect. Name the regression test or alert you added so the same failure could not come back unnoticed.
5. State the trade-off you made openly: what limitation you knowingly shipped with, who you told, where it was recorded, and whether the proper fix was actually done afterwards.

Follow-up

• How did you confirm the fix addressed the cause and not just the symptom?
• If you could not reproduce the failure locally, what would you have done next?
• What did you change in tooling or process afterwards so the next incident would be faster to diagnose?

Suggested practice checklist

Seven days built around the two reported rounds: a career story for the recruiter call, then the experience, project, lifecycle, debugging and design questions candidates report for the technical stage.

Day 1 — Map the two rounds and choose your track

• Write the reported sequence, Recruiter Screening Call then Technical Assessments, and list under each what you still need to prepare
• Decide whether you will tell a full-stack story or a robotics story, and write one sentence that names it
• List the languages you can discuss in depth from C++, Python and Java, with one real project for each

Deliverable: A one-page map of both rounds, a track statement, and a language-to-project list.

Day 2 — Build the career story

• Write the answer to the question about your previous experiences as an outline of three projects: context, your role, a decision, a result
• Rewrite it for the question about your experience as an engineer, changing the emphasis to your ownership
• Say both aloud and cut anything that is a list of tools without a decision

Deliverable: A written outline of three projects and a spoken run-through of both answers.

Day 3 — Prepare the most challenging project you led

• Choose one project where you set the direction and write its goal, constraints and the options you considered
• Record the numbers: what you measured before and after, and the risks you managed
• Sketch one diagram of the architecture that you can redraw from memory

Deliverable: A one-page project brief with options considered, measured results and a redrawable diagram.

Day 4 — Describe your team lifecycle and code quality

• Write the path of a real change in your team from requirement to production, naming the owner of each step
• List the practices you use to protect quality: review, tests, documentation, release checks
• Work through the practice question on turning a code review disagreement into a decision, and write the comment you would leave

Deliverable: A lifecycle walkthrough of one real change, a quality-practice list, and one written review comment.

Day 5 — Debugging under a deadline

• Pick an incident and write its timeline: symptom, what changed, hypotheses tested, root cause, fix
• Write what you deferred because of the deadline and the mechanism that kept that debt bounded
• Work through the practice question on shipping under a deadline and bounding the debt, then compare it with your own story

Deliverable: A debugging story with a timeline and a recorded deferral, plus a written answer to the deadline practice question.

Day 6 — Design and refactor scenarios

• Outline a module for a new robotic system: inputs, interface, failure handling and how you would test it without hardware
• Prepare a refactoring story that improved performance, with the measurement and the tests that protected behaviour
• Practise explaining one design decision in plain language to a non-technical listener

Deliverable: A module outline, a refactoring story with a before-and-after number, and a plain-language explanation.

Day 7 — Full dry run

• Run both rounds aloud in order: the recruiter conversation, then the experience, project, lifecycle and debugging questions
• Note every answer where you said 'we' without saying what you did, and fix it
• Write the questions you will ask about the team's current projects and technical challenges

Deliverable: A completed mock of both rounds, a list of answers to fix, and your questions for the team.

Experience and decision stories

The reported questions are about your own engineering history, so these prompts ask for specific stories where you owned a decision, with the alternative you rejected and the result. Prepare them in the first person, name your collaborators' disciplines, and keep a measurable outcome ready for each. The role involves working with mechanical and systems engineers, so include at least one story that crosses disciplines.

1. Talk about your previous experiences.
2. What was the most challenging technical project you have led?
3. Describe a situation where you had to debug a complex system under tight deadlines.
4. Tell me about a time you refactored legacy code to improve performance, and how you showed it was faster.
5. Describe a disagreement with a colleague about code quality and how it was resolved.

Please explain your experience as an engineer.

Medium · Professional Experience & Background

Approach

1. Open with one sentence that names your discipline and the kind of systems you build (for example web services and front ends, or software that controls hardware), then walk through two or three projects instead of every job you have held. A chronological list of employers and technologies is the usual way this answer goes flat.
2. Give each project the same shape: the context in a sentence or two, your specific responsibility, one technical decision with the alternative you rejected and why, and a result you can measure or observe. Phrase it in the first person, such as 'I designed the retry layer and chose a queue over polling because...'.
3. Separate what you did from what the team did. Say what you wrote, reviewed, debugged or decided yourself, and name the disciplines you worked with, since the role involves regular collaboration with mechanical and systems engineers.
4. Match the story to the opening. For a full-stack role, show work across the front end, services and data; for a robotics role, show an integration with hardware, sensors or real-time constraints, and say which of C++, Python or Java you used for it.
5. Close by connecting your experience to the next step: what you would want to build or own, and one thing you learned that changed how you work. Keep it concise so there is room for follow-up questions.

Follow-up

• Which of those decisions would you make differently today, and why?
• What did you write yourself, and what did you review, inherit or delegate?
• What changed measurably because of your work, and how did you know it was your change?

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?

Ship under a deadline and bound the debt you chose

Medium · pagination · technical debt · tradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach

1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.

Follow-up

• At what page depth does the offset version breach your latency budget, given your page size and row counts?
• What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?