CABLExpress Software Engineer Interview Guide

The 60-second brief

Candidates describe CABLExpress as a provider of infrastructure solutions for clients running data centers and enterprise networks. The Software Engineer role sits between the physical hardware and the applications that manage it. Reports describe building and maintaining applications for data center operations, working alongside infrastructure architects, improving existing systems, writing tools for data management, and taking part in technical reviews and project planning. Reports also mention two focus areas a posting can lean toward, a Data Center Infrastructure Architect track and a Systems Application track, so check which one your posting resembles.

This guide is for candidates interviewing for a Software Engineer position at CABLExpress, including students and early-career engineers whose strongest material is an internship or a first role. It covers the reported phone screen and later team and leadership conversations, the five reported experience-style questions, how to connect your software background to data center infrastructure, and a day-by-day plan. It does not assume a coding round, because none is reported.

Candidates report a phone screen that checks your background, your technical interest and work authorization, followed by conversations with team members and with leadership. The emphasis they describe is on your past projects and the reasoning behind your choices, with no brain-teasers.

Focus areas

• Software Engineering
• Data Center Infrastructure Architecture
• Infrastructure Architecture

Overview

The reported work is application development and maintenance for data center operations, done close to infrastructure architects. That makes the interview a test of whether you can explain software that touches physical systems: what the system had to do, which constraints you worked within, and why you chose one design over another. Candidates are told to explain the why behind technical decisions, not just the how, so every project you plan to mention needs a reason attached to each major choice.

Reports describe a practical conversation about what you have done rather than puzzles. Reported example prompts include explaining a technical project you led from conception to deployment and how you keep code maintainable in a long-term infrastructure project. Reported topics also include troubleshooting, system optimization, technical documentation and industry certifications. Prepare one project that you can walk through end to end, one troubleshooting story, and one story about keeping something maintainable over time.

All five reported questions are filed under Experience and Background: walking through your most significant internship or role, the technical challenges in your last project, applying your skills to real-world infrastructure problems, why you are interested in software and data center infrastructure together, and adapting quickly to a new technical requirement. The first four are open conversation questions and the fifth is behavioral. Treat them as one story bank: three or four projects, each with a problem, a constraint, a decision, a result and something you would change.

The screening stage is also where reports say work authorization comes up, and location matters because roles are tied to Syracuse, NY or Norcross, GA. Certifications are listed as a nice-to-have, so have a clear sentence about any you hold or the one you would pursue and why. Spend a short block on the vocabulary of data centers (compute, storage, network, power, cooling, cabling) so your answer about the intersection of software and infrastructure names real layers rather than gestures at them.

Where to focus your preparation

The only structured stage in the record is a preparation focus, because no named round sequence is reported. Candidates describe a phone screen, then team-member and leadership conversations, so prepare for that pattern and confirm the details with your recruiter.

Preparation focus

No numbered round list is reported for CABLExpress. What candidates describe is a phone screen that verifies your background, your technical interest and your work authorization, followed by conversations with team members and with leadership. The questions they report are about your history: your most significant internship or role, the technical problems you solved, how you applied your skills to infrastructure problems, why software plus data center infrastructure interests you, and a time you adapted to a new requirement quickly. Approach this stage as a story-telling exercise. Keep a short version of each story for the phone screen and a deeper technical version for conversations with the team, and confirm with your recruiter whether any stage involves writing code.

What to demonstrate

• How clearly you explain a past project, including the reasoning behind your technical decisions
• How you structure a problem: what you defined, which constraints you named and how you reached a solution
• Whether you can describe technical work to non-technical stakeholders
• Whether your background and work authorization fit the posting and its location

How to prepare

• Write a one-page narrative for each of three projects or internships: problem, constraints, your decisions and why, the result, and what you would change
• Prepare a 60-second version of your most significant role for the phone screen and a longer technical version for team conversations
• Write a specific answer to why software combined with data center infrastructure interests you, naming one real project, course or system that led you there
• Ask the recruiter for the stage order, who you will speak with, whether code will be written, and the on-site expectations for Syracuse or Norcross

Where candidates lose points

Describing a project entirely as 'we' so your own contribution is invisible

For each project, write the two or three decisions that were yours and say them in the first person. Mention the team for context and then return to what you designed, built or fixed.

Explaining how a system was built without saying why it was built that way

For every major choice in a story, add a sentence beginning 'I chose X over Y because'. Reports tell candidates to explain the why behind technical decisions, so rehearse the alternative you rejected.

Answering the question about software and data center infrastructure with general enthusiasm

Name a concrete experience that connects the two, such as a tool that managed hardware, a networking project or a deployment you supported, and name the layers involved. If your link is academic, say which course or project and what you learned from it.

Being unready for the screening logistics: work authorization, location and certifications

Prepare short factual answers about your work authorization, your willingness to work from Syracuse or Norcross, and any certification you hold or plan to earn. Ask about on-site expectations at the screen rather than later.

A new-requirement story that ends with 'I learned it' and no evidence of the outcome

Finish with what shipped or changed because of your adaptation and how you know it worked, such as a test result, a deployment or a teammate's review. Then add what you would change.

Questions & practice

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?

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?

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

Easy · hashing · at-least-once · aggregation

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

Approach

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

Follow-up

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

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

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

Approach

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

Follow-up

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

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?

Can you walk us through your most significant internship or previous role?

Medium · Experience and Background

Approach

1. Open with a two-sentence frame: the team, the system it ran, and the part you owned. Say it as 'I owned X', not 'the team built X', so your own share is clear from the first line.
2. Go deep on one project instead of listing every task. Sketch the data flow (where the inputs came from, which services or scripts processed them, where the results were stored and who read them), then point to the piece you wrote.
3. Name one decision you made and its trade-off, for example: 'I chose a nightly batch job over a streaming consumer because the data only changed once a day, and it removed a service to operate.'
4. End with a result you can check: a number (runtime cut from hours to minutes, tickets closed, adoption by an ops team), or an honest statement that it was not measured and how you would measure it now.
5. Close by linking the work to the responsibilities candidates describe for this role, such as applications that support data center operations and tools for managing data. Do not claim experience you lack.

Follow-up

• If you rebuilt that system today, what would you change in its design and why?
• What was the hardest bug you hit in that role, and how did you find its root cause?
• Who used what you built, and how did you know it was working for them?

What specific technical challenges did you solve in your last project?

Medium · Experience and Background

Approach

1. Pick one challenge with a symptom you can measure, such as a slow query, a job that kept failing, or a memory leak. State the constraint that made it hard: legacy code, no test environment, or a deadline.
2. Walk through the debugging steps in order. I reproduced the problem, narrowed it down with logs, metrics or a git bisect, formed one hypothesis, tested it, and only then changed the code.
3. Give the alternatives you rejected and why. For example, a cache would have hidden the slow query but served stale data, while an index fixed the cause at the cost of slightly slower writes.
4. Separate the root-cause fix from any temporary workaround. Say what you added so it could not come back quietly: a regression test, an alert, or a runbook entry.
5. Keep a second challenge of a different kind ready (one design problem, one debugging problem) in case you are asked for another.

Follow-up

• How did you confirm your change caused the improvement, rather than a drop in load or some other change?
• What would have broken if your first hypothesis had been wrong and you had shipped it anyway?
• What did you leave behind so the next engineer could understand and maintain the fix?

How have you applied your technical skills to real-world infrastructure problems?

Medium · Experience and Background

Approach

1. Choose a story that touches operational infrastructure: servers, network devices, provisioning, monitoring, asset or inventory data, or deployment pipelines. If your experience is application-only, use a reliability or operations problem and say so plainly.
2. Define where the system starts and stops: which physical or network components were involved, which software touched them (scripts, APIs, config management, dashboards), and where the source of truth for their state lived.
3. Explain how you handled failure. Make automation idempotent so a rerun leaves the same end state. Use timeouts and retries with exponential backoff for unreachable devices, add a dry-run mode that shows changes before applying them, and know how to roll back.
4. Say how you tested without risking production equipment: a lab or staging rack, recorded device responses, or a small batch of devices before the full fleet.
5. Quantify the outcome (manual hours removed, incidents reduced, time to provision a host) and be honest about scale: ten devices and ten thousand need different designs.

Follow-up

• What happened when your automation failed halfway through a batch, and how did you recover the devices it had already changed?
• How would your approach change if the number of devices or sites grew tenfold?
• How did you keep the software's record of the infrastructure in sync with what was physically installed?

What made you interested in the intersection of software and data center infrastructure?

Medium · Experience and Background

Approach

1. Start with a specific moment, not a general statement: a networking course, a lab you set up, an internship ticket that made you trace a physical connection, or a home lab. One concrete detail makes the answer believable.
2. Show you understand what the overlap involves. Software in this space models physical facts such as which port connects to which, what is installed in each rack, and how much capacity is free. That data goes stale unless the tools make updating it easier than skipping it.
3. Back the interest with evidence: a project, coursework, or a certification you hold or are studying for. Candidates report that certifications come up for this role, so name your plan if you do not have one yet.
4. Tie it to the responsibilities candidates describe for the role, such as building and maintaining applications for data center operations and working with infrastructure architects. Say what you want to learn from that collaboration.
5. Finish with a short question about the team's current technical work. It turns the answer into a conversation and shows you have thought about the job itself.

Follow-up

• How would you keep a software record of physical connectivity accurate when technicians change cabling by hand?
• Which certification or area of infrastructure knowledge are you working on now, and why that one?
• If you joined, what would you want to understand in your first month before writing any code?

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 builds a story bank around the five reported experience questions, then adds the infrastructure link, troubleshooting and maintainability stories that reports mention, and finishes with a spoken mock.

Day 1 — Confirm the logistics and read the posting

• Read the posting and decide whether it leans toward the Data Center Infrastructure Architect track or the Systems Application track; list the skills and certifications it names
• Write a short factual answer for work authorization and for working in Syracuse or Norcross
• Email or ask your recruiter for the stage order, who you will meet and whether code will be written

Deliverable: A posting skills list with the track marked, two written logistics answers, and a message to the recruiter with your format questions.

Day 2 — Inventory your projects and your significant role

• List every internship and project you could discuss and pick three that show the most technical decisions
• For the strongest one, write the one-page narrative: problem, constraints, your decisions with reasons, result, what you would change
• Record a 60-second spoken version for the phone screen and listen for 'we' where you should say 'I'

Deliverable: A one-page narrative for your significant role, a recording of its 60-second version, and a ranked list of three projects.

Day 3 — Connect software to data center infrastructure

• Write the layers of a data center in your own words (compute, storage, network, power, cooling, cabling) and mark where software touches each
• Find the project of yours closest to infrastructure and write how you applied your skills to a real-world infrastructure problem
• Write your answer to why software combined with data center infrastructure interests you, naming one concrete experience

Deliverable: A one-page layer map, a written infrastructure-problem story, and a written motivation answer that names a concrete experience.

Day 4 — Troubleshooting, optimization and maintainability

• Write a troubleshooting story with the sequence you followed: symptom, hypotheses, the check that separated them, the fix and how you confirmed it
• Write an optimization story with a before and after measurement, or the reasoning if you could not measure
• Outline how you keep code maintainable in a long-term project: documentation, tests, review habits and handover

Deliverable: A troubleshooting story, an optimization story and a maintainability outline, plus a spoken run of the practice debugging question.

Day 5 — Adapting quickly and the behavioral drills

• Write the adapting-to-a-new-requirement story using Situation, Task, Action, Result with most of the words on Action
• Add the risk-reducing step you took and the result you can point to

Deliverable: A written adaptation story with a result, and spoken answers to two practice behavioral prompts.

Day 6 — Explain it to non-technical listeners and prepare certifications

• Re-tell your best project as if to a manager who does not code: the business problem, the outcome and one risk, without jargon
• Write a two-sentence answer about each certification you hold or plan to pursue and why it fits this role
• Write the project from the reported prompt about a technical project led from conception to deployment, with the milestones in order

Deliverable: A jargon-free project summary, a certification answer and a conception-to-deployment outline.

Day 7 — Spoken mock and questions to ask

• Answer all five reported questions aloud in sequence, recording yourself, and note any story that lacks a decision, a reason or a result
• Fix the weakest two stories and re-record them
• Write three questions for the team about its current technical challenges and how software and infrastructure teams work together

Deliverable: A recorded run of the five reported questions, two revised stories and three questions to ask.

Experience and adaptability stories

Reported questions in this loop are about your history and how you work with people: your significant internship or role, the problems you solved, how you adapted, and your interest in the field. Candidates are also told to be able to explain complex ideas to non-technical stakeholders and to work within a team. Prepare stories where you made the decision, with a reason and a result, and keep each one short enough to say aloud.

1. Tell me about the most significant internship or role you have held, and the decision you are proudest of in it.
2. Describe a technical problem you solved in your last project: what you tried first and how you confirmed the fix.
3. Describe a time you explained a technical decision to someone who was not an engineer. What did you leave out and why?
4. Tell me about a time you had to keep work maintainable for the person who would own it after you.

Can you describe a time you had to adapt to a new technical requirement quickly?

Medium · Experience and Background

Approach

1. Choose a story where a requirement changed or arrived late and you had to learn something to meet it, such as a new language, protocol, platform, hardware constraint or deployment target. If you have touched networking, embedded work or operations tooling, use that story because it links to the infrastructure side of the role.
2. Use a Situation, Task, Action, Result structure but spend most of the time on Action. Name what you needed to learn, how you decided the minimum you had to know first, and where you learned it (documentation, a prototype, a teammate, a code review).
3. Show how you reduced risk while moving fast: a small spike or test to confirm your understanding, a review by someone who knew the area, a rollback or fallback if the new piece failed.
4. Close with a concrete result and one change you would make next time, such as asking about the requirement earlier or writing down what you learned for the next engineer. Say 'I' for your own decisions and name the team only for what the team did.
5. Avoid a story that is only about working long hours. The point is the method you used to get competent in something unfamiliar, not the effort.

Follow-up

• What did you do first, and why was that the first step?
• How did you check that your understanding of the new requirement was correct before you shipped it?
• What would you do differently if the same change arrived again tomorrow?

Argue against a design, lose, and commit anyway

Medium · disagreement · service boundaries · decision records

Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

Approach

1. State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
2. Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
3. Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
4. Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.

Follow-up

• What threshold on that alert would have proved you right, and did anyone ever look at it?
• If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?