Allnorth Software Engineer Interview Guide

The 60-second brief

Allnorth is described as a firm providing engineering and technical services across several disciplines. Candidate accounts describe the Software Engineer role as writing the tools, systems and data-processing code that sit behind infrastructure projects, with surveying, civil and mechanical engineering workflows as the people being served. The work is described as cross-functional: you turn requirements from senior project supervisors and civil engineers into working software, sometimes in specialised settings such as municipal engineering or structural modeling, where candidates stress that results must be accurate and reliable. Day to day, accounts mention building tools that automate or streamline engineering workflows, maintaining and improving existing systems and contributing to planning for new projects, and keeping project managers informed while priorities shift between projects.

This guide is for software engineers preparing for the Allnorth Software Engineer loop. It covers the four reported rounds, the experience, project and stakeholder questions candidates report, how to build a portfolio you can share, and a seven-day plan.

Candidates report four rounds over roughly 3-5 weeks: Initial Screening, Technical Evaluations, Behavioral Assessment and Final Interviews. The reported questions are about your own experience, projects and collaboration rather than puzzle-style problems.

Focus areas

• Technical Interview Preparedness
• Communication
• Domain Experience (Engineering Projects)

Overview

The questions candidates report for this loop are almost all about your own history: what experience you bring, which projects you have built, what you learned from them, what your strengths are, why you want to work at an engineering services firm, and how you handle technical problems with colleagues who are not software people. None of the reported questions is an algorithm puzzle. Candidates are also told to be ready for whiteboard coding or system design, with the format varying by team, so the sensible plan has two tracks: a deep, rehearsed account of your past work, and enough live problem-solving practice that you can reason aloud when a technical scenario appears.

The technical stage is described as tied to the engineering domains the firm serves rather than purely theoretical. Candidate accounts say to be ready to go over architecture and technology choices in past projects, explain why you chose them, discuss what went wrong and what you changed, and show that what you built was meant to be maintained and to stay correct. That makes your project history the main study material. For each project you will want the problem, the constraints, the design, the options you rejected, your own role, the outcome and the lesson, written down and spoken aloud until you can tell it without notes.

The domain and the audience set this loop apart from a generic software loop. Accounts describe working with senior project supervisors, civil engineers and project managers, in areas such as municipal engineering, structural modeling, surveying and mechanical work. Nice-to-have items candidates mention include exposure to engineering software, municipal or structural project environments, and data management systems. You do not need to be a civil engineer, but you should learn the vocabulary well enough to ask sensible questions, and you should practice explaining a technical trade-off with no jargon.

Candidates also report requests to send previous work for review, so a portfolio is part of preparation rather than an afterthought. Choose pieces you can explain line by line, remove anything confidential from past employers, and write a short summary of each. The seven-day plan below spends its first days on projects and portfolio, then moves to strengths, motivation and stakeholder answers, then to technical drills and a full mock run.

The Allnorth interview process

Candidates describe these four stages and a total span of roughly 3-5 weeks, with a week or two sometimes separating major stages. Treat the order and content as what candidates report, not a published schedule.

Initial Screening

Candidates describe Initial Screening as a first pass on basic qualifications and fit. As preparation, line up your CV, your portfolio and your motivation against the role's listed must-haves: strong skills in the languages the team uses, experience carrying a project from idea to deployment, and clear professional communication. Go in with a tight spoken account of your background that points at those three things, and have the portfolio summaries ready in case work samples are requested.

What to demonstrate

• Whether your background matches the basic qualifications for the role
• Fit with a project-driven engineering services environment
• How clearly you present your resume and portfolio

How to prepare

• Write a short spoken summary of your career that names your main language, one project you took from conception to deployment, and one example of explaining your work to a non-specialist
• Prepare a specific reason for wanting to work in software for infrastructure and engineering projects, based on the domains the firm services (surveying, civil, mechanical, municipal, structural)
• Assemble a portfolio pack with a one-paragraph summary per piece of work, ready to send on request

Technical Evaluations

Candidates report Technical Evaluations as more in-depth than the screen, with senior leadership and hiring managers. The emphasis described is on how your skills apply to engineering domains: architecture and technology in past projects, the reasons behind your choices, lessons from failures, and whether your systems were built to be maintained and stay reliable. Candidates are also told to be ready for whiteboard coding or system design, with formats varying. Prepare project walk-throughs first, then practice reasoning aloud through an unfamiliar scenario.

What to demonstrate

• Depth of technical understanding in the projects you have built
• Whether you can explain why you chose a technology or design over the alternatives
• Attention to long-term maintenance and reliability in your code and systems
• How you structure a problem: constraints, options and trade-offs

How to prepare

• Write a one-page technical dossier for each of your three strongest projects: components, data flow, technology choices, rejected alternatives, what failed and what you changed
• Practice a coding warm-up in your main language and one design sketch for a field-measurement tool that covers unit and coordinate-system normalisation, validation against reference values, offline field capture with later sync, an audit trail of who changed which measurement, and versioned report outputs
• Review data handling basics (schema design, safe concurrent updates, paging through large result sets) using the SQL practice drills, since data management systems are a listed nice-to-have

Behavioral Assessment

Candidates describe the Behavioral Assessment as a check on behavioral traits and cultural alignment. The material that comes up in candidate accounts is team-oriented work, handling feedback constructively, learning from challenges and communicating with colleagues outside software. The practical approach is a bank of real stories, each with the situation kept short, your own decision in the middle, and a result plus a lesson at the end.

What to demonstrate

• How you work in a team and take feedback
• How you communicate with project supervisors and other non-software colleagues
• What you take from past challenges and how you apply it later

How to prepare

• Write four stories with the structure of situation, your decision, result and lesson: a strength in action, a project that went wrong, a disagreement with a non-software colleague, and a deadline trade-off
• Rehearse each story aloud until the situation takes two or three sentences and most of the time goes on your reasoning
• Prepare one example where you explained a technical constraint to a non-specialist and what changed as a result

Final Interviews

Candidates say Final Interviews can be intensive and may be in person or virtual, finishing the evaluation. Little else is reported about their content, so prepare for a repeat and deepening of everything above: your project dossiers, your behavioral stories and your motivation, with answers that stay consistent with what you said earlier. Bring questions of your own, and after the interview follow up promptly if you hear nothing, which candidate tips advise.

What to demonstrate

• Final evaluation of your technical and behavioral fit
• Overall fit for a collaborative, project-driven environment
• Overall technical and communication standing after the earlier stages

How to prepare

• Keep a one-page record of what you said in each earlier stage, including the projects and numbers you cited, so final answers match
• Prepare questions about the types of projects the team supports, how requirements arrive from supervisors and engineers, and how software work is planned across several projects
• Run a full back-to-back mock that covers a project walk-through, a behavioral story and a technical scenario, to build stamina for a long final stage

Where candidates lose points

Walking through past projects as a list of features and technologies, with no reasoning about why you built them that way

For each project, prepare the problem, the constraints, the options you rejected and why, your own role and the outcome. Say the reason before the technology name. Practice with a friend who interrupts with "why not the simpler option?"

Saying "we" throughout, so the listener cannot tell what you personally decided, built or fixed

Write each project story with two columns: what the team did and what you did. In the interview, state your own decision explicitly, then credit the team for the rest. This matters most when you talk about lessons learned and strengths.

Giving a lessons-learned answer that is a platitude ("communication is important") rather than a change in how you work

Anchor each lesson in a specific failure: what broke, what it cost, what you changed afterwards (a test, a review step, a requirements check with the supervisor), and where you applied the changed habit later.

Being unable to share or explain your previous work when asked, or sending material that includes a past employer's confidential code or data

Prepare the portfolio pack before the first stage. Use work you can explain line by line, remove confidential details or replace them with a sanitized example, and add a short summary of each piece. Check what you are allowed to share before sending.

Explaining technical constraints to non-software colleagues in jargon, or answering the motivation question with something that would fit any employer

Learn the vocabulary of the firm's domains (surveying, civil, mechanical, municipal and structural work) and practice describing a trade-off with an everyday analogy and a consequence for the project. For motivation, name the kind of engineering software work that interests you and why.

Questions & practice

Can you walk me through your past projects?

Medium · Project Management and Problem Solving

Approach

1. Choose two or three projects and cover each one in the same order: the problem and its users, the architecture (inputs, processing, storage, interfaces), your own contribution, and a measurable outcome.
2. Be ready to sketch the data flow and explain each technology choice, including the option you rejected and the trade-off behind that decision, such as speed of delivery against maintainability.
3. Cover what happened after launch as well as the build: how it was tested, deployed and monitored, and who maintained it. Candidates report that long-term maintenance and reliability come up in technical discussion.
4. Say clearly what was yours. Use 'I' for your work and name the team's parts separately.
5. Give a short summary of each project first, then offer to go deeper on the most technical one.

Follow-up

• What was the hardest bug in that project, and how did you find it?
• If you rebuilt it today, what would you change in the architecture?
• How did you verify the tool's numbers against the engineers' hand calculations, and what happened when they disagreed?

What were the key lessons learned from your previous technical projects?

Medium · Project Management and Problem Solving

Approach

1. Pick a real setback with a concrete cost: a missed requirement, a data error that reached users, a slipped deadline. A success presented as a lesson does not answer the question.
2. Use this structure: what happened, the root cause (technical or process), the specific mechanism you added afterwards (a validation check, a test, a review step, a sign-off with stakeholders), and evidence that it worked on a later project.
3. Make the lesson technical and checkable. For example: unit or coordinate conversions went unvalidated, and you then added input checks plus tests against reference values the engineers supplied.
4. Turn general lessons like 'communicate more' into specific actions: who you now confirm requirements with, how often, and in what form.
5. Take ownership of your part. Do not blame a teammate or a client.

Follow-up

• How did you apply that lesson on your next project?
• What would have caught the problem earlier, and why was it not in place?
• Did anyone else have to change how they worked for the fix to stick?

How do you approach technical challenges when working with non-software stakeholders?

Medium · Project Management and Problem Solving

Approach

1. Start from the stakeholder's goal and vocabulary. Restate the engineering requirement in their own terms and units, then confirm acceptance criteria using worked examples: sample inputs with the output they expect.
2. Check the software against results they already trust, such as hand calculations or existing spreadsheet outputs, before you build on top of it.
3. Present trade-offs in plain language as options, each with its cost, risk and timeline, and let them decide on engineering or project grounds rather than technical preference.
4. Keep the feedback loop short with working increments or screenshots, and give status updates in a fixed shape: what is done, what is blocked, which decision you need from them.
5. Back it up with a short STAR story about a time a misunderstood requirement was caught and resolved this way.

Follow-up

• Tell me about a time a stakeholder insisted on something you thought was technically wrong.
• How would you explain a delay caused by a technical problem to a project manager?
• How do you confirm you understood a requirement before you build it?

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?

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?

What is your previous experience relevant to our company?

Medium · Experience and Qualifications

Approach

1. Pick two or three pieces of your work that match what candidates say this role involves: software and data tools for engineering work such as surveying, civil, mechanical, municipal or structural projects. Lead with the closest match, not with your oldest job.
2. For each piece, give one line each on what you built, who used it and the result, with a number: records processed, hours of manual work removed, error rate before and after.
3. If you have no engineering-domain work, connect what you have done to it: internal tools for non-software users, pipelines where wrong numbers have real consequences, or validating measurement or spreadsheet data.
4. Name the language and stack you used and why you picked it. Candidates report being asked about the reasons behind technical choices.
5. Avoid reciting your CV in date order. Finish with the one skill you would bring to the team from day one.

Follow-up

• Which of those projects was closest to engineering or infrastructure work, and which part was yours?
• What would you need to learn first to build tools that civil or structural engineers use every day?
• Which language are you strongest in, and what did you most recently ship with it?

Can you send us your previous work for review?

Medium · Experience and Qualifications

Approach

1. Say yes, then say exactly what you can share and in what form: public repositories, a short portfolio document, or screenshots and a recorded demo for closed-source work.
2. Never send code your employer owns. For that work, write a one-page case study per project instead: the problem, a sketch of the architecture, what you built, the outcome. Or share a small sample you wrote yourself that shows the same technique.
3. Pick two or three strong pieces rather than sending everything. Give each a README covering how to run it, which files to look at first, how it is tested and what its known limits are.
4. Be ready to walk through anything you send. Reread it beforehand and note one thing you would refactor and why.
5. Confirm the format they want and when they need it, then send it promptly. Candidates report that this request is common in the process.

Follow-up

• Walk me through the piece you sent: what would you refactor first, and why?
• How did you test it, and what did the tests leave out?
• Which parts did you write yourself, and which came from a team or a library?

Why are you interested in working for this company?

Medium · Experience and Qualifications

Approach

1. Base the answer on the work candidates describe: engineering and technical services, with software supporting surveying, civil and mechanical engineering workflows. Name the part that connects to your own background.
2. Use three parts: what draws you to building software for engineers, what you already bring to that work, and what you want to get better at in this role.
3. Research the kinds of projects the firm takes on using its public materials, so you can name one type of work specifically instead of praising the company in general terms.
4. Show that you understand the users are engineers and project staff who depend on the tool's output. Give an example of how you have built for users like that before.
5. Avoid answers that would fit any employer, and do not lead with pay or location.

Follow-up

• What do you know about the kinds of projects the firm works on?
• How does this role fit where you want to be in a few years?
• Why software for engineering work rather than a product company?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

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

Approach

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

Follow-up

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

Suggested practice checklist

The plan starts with your evidence and the domain, builds project dossiers and a portfolio, practices the reported experience, motivation and stakeholder questions aloud, then adds technical drills and a full mock.

Day 1 — Map the loop and the role

• List the four reported stages (Initial Screening, Technical Evaluations, Behavioral Assessment, Final Interviews) and, next to each, what you would need to show
• Make a table of the role's must-have skills (core languages, project conception to deployment, communication) against one piece of evidence each from your own work
• Write a glossary of ten terms from surveying, civil, mechanical, municipal and structural work, each with a one-line plain explanation

Deliverable: A one-page evidence table plus a ten-term glossary.

Day 2 — Project dossiers

• Choose your three strongest projects and write a one-page dossier for each: problem, constraints, architecture, technology choices, rejected alternatives, your role, outcome
• Answer "Can you walk me through your past projects?" aloud for each project, ending each in a clear line about your own contribution
• Mark where each dossier shows reliability or maintainability work (tests, validation, monitoring, documentation)

Deliverable: Three project dossiers and three spoken walk-throughs recorded or timed by you.

Day 3 — Lessons learned and debugging

• For each project, write one failure or challenge, what you did about it, and what you changed in your practice afterwards
• Answer "What were the key lessons learned from your previous technical projects?" aloud using two of those stories

Deliverable: Three lesson stories and one written debugging sequence.

Day 4 — Experience, portfolio and motivation

• Write and speak a tailored answer on your relevant experience, linking your background to engineering and infrastructure software work
• Assemble the portfolio pack: pick the pieces, remove confidential content, add a short summary for each, and decide how you would send it
• Write a motivation answer that names the kind of work you want to do on engineering workflow software and why

Deliverable: A spoken experience answer, a ready-to-send portfolio pack and a written motivation answer.

Day 5 — Strengths and non-software stakeholders

• Prepare "Tell me about your strengths as an engineer." with two strengths, one episode each and one stated limit
• Write an answer to "How do you approach technical challenges when working with non-software stakeholders?" using a real example in which you reframed a technical constraint for a non-specialist

Deliverable: Two spoken answers (strengths and stakeholders) and one written deadline story.

Day 6 — Technical depth for the second round

• Design a tool that takes field measurements, validates them and produces a report. Reason aloud about units and coordinate systems, duplicate or late field uploads, concurrent edits by several engineers, and how a signed-off report stays reproducible
• Code and narrate these warm-ups, stating the complexity of each: parse a CSV of survey points and reject malformed rows (O(n)), compute polygon area with the shoelace formula (O(n)), merge overlapping chainage or station ranges (O(n log n) for the sort), and convert units with tolerance checks

Deliverable: Two written SQL explanations, one design sketch covering those constraints, and four narrated warm-ups with complexity stated.

Day 7 — Full mock run

• Run a back-to-back mock: a screening-style introduction, a project walk-through, a technical scenario, two behavioral stories and a motivation answer
• Write three questions to ask about project types, how requirements reach the software team and how work is planned across projects, and a short follow-up message you could send after an interview

Deliverable: A completed mock, an updated story bank, three questions to ask and a follow-up message.

Behavioral prep: strengths, lessons and working with non-software colleagues

Candidates describe the Behavioral Assessment as a check on traits and cultural alignment, and the reported questions center on your strengths, your motivation, lessons from past projects and working with colleagues outside software. For this role that means stories about owning a decision, learning from a setback, taking feedback and explaining technical problems to engineers and project managers. Prepare real episodes with specific results instead of general statements.

1. Why are you interested in working for this company?
2. What were the key lessons learned from your previous technical projects?
3. How do you approach technical challenges when working with non-software stakeholders?
4. Tell me about a time you took critical feedback on your work and what you changed afterwards.
5. Describe a project where priorities shifted midway and how you kept the people depending on your software informed.

Tell me about your strengths as an engineer.

Medium · Experience and Qualifications

Approach

1. Choose two or three strengths and tie each to one concrete episode, rather than listing adjectives. A strength is credible when it is visible in a decision you made: "I add a validation check that compares tool output with hand-calculated values" shows care for correctness in a way that "I am detail-oriented" does not.
2. Pick strengths that fit this role as candidates describe it: producing accurate and reliable software, turning requirements from engineers and supervisors into working tools, building things that are maintainable, and explaining technical issues in plain language. Do not invent a link to the firm; connect each strength to the kind of work you have actually done.
3. Structure each strength as claim, evidence, result. Claim in one sentence, a two-sentence situation, what you personally did, then a result you can point to: an error class removed, a manual step automated, a hand-off that stopped failing. Use only your real numbers; if you have none, name the observable change.
4. Add a limit. Say what the strength costs you (thoroughness can slow a first release, for example) and the habit you use to manage it. This shows self-awareness and prepares you for the follow-up about weaknesses.
5. Mistakes that sink this answer: generic claims such as "fast learner" and "team player" with no story, taking credit for a team result without saying what you did, and a strength unrelated to software work. Keep it short enough to leave room for follow-up questions.

Follow-up

• Tell me about a time that strength backfired or was the wrong approach.
• What would a teammate say is your weakest area, and what are you doing about it?
• What evidence shows that this is a real strength and not just a habit you like?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

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

Approach

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

Follow-up

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

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?