Averis Software Engineer Interview Guide

The 60-second brief

Candidate reports for Averis do not name a specific product. The role as described involves designing, building and maintaining the systems behind the company's internal platforms and the services it provides. Engineers own modules across the whole development lifecycle, review peers' code, take part in architecture discussions, and work out requirements with product managers and sometimes operations staff in agile, cross-functional teams. Because the business domain is not spelled out, read what you can find about Averis's business before the interviews so your design examples and project stories connect to it.

This guide is for software engineers interviewing at Averis who work in Java, Python or C++. It prepares you for the stages candidates report: a coding assessment often hosted on HackerRank, technical interviews on data structures, algorithms, system design and code quality, and managerial conversations about past projects, failures and teamwork. It covers the five reported questions in depth, the relational-database and concurrency topics the role's requirements point to, and the cloud, CI/CD and container tools listed as nice-to-haves.

Candidates report a structure that varies but usually starts with an initial screen, moves to a technical assessment often run on HackerRank, and continues with several technical and managerial interviews.

Focus areas

• Adult Learning Theory
• Learning Experience Design (LXD)
• Technical Interview Structure for System Design

Overview

The requirements candidates describe for this role are concrete: proficiency in at least one of Java, Python or C++, a solid grasp of software design patterns, and experience with relational databases. Cloud platforms (AWS, Azure or GCP), CI/CD pipelines, Docker and Kubernetes are listed as nice-to-haves. Day to day, the role owns modules end to end: production code, peer review, architecture discussions and requirement-setting with product managers. Your preparation should match that mix: algorithmic coding in your strongest language, database and concurrency fundamentals, and design reasoning you can defend.

The reported questions fall into two groups. Four are about your own technical history: a complex project you led, how you debug a production issue under pressure, how you choose a technology stack for a new feature, and how you keep code maintainable and scalable. The fifth is a design prompt that leaves the system unnamed and asks for high traffic plus data consistency. Candidates also mention scenarios such as walking through an algorithm's complexity and tuning a database query for a high-concurrency workload. Build three or four project stories with real numbers, and a design skeleton you can apply to any system.

For the coding assessment, practise on HackerRank itself so reading input, writing complete functions and checking edge cases feel routine. Every solution should come with a stated time and space complexity, since candidates report complexity walkthroughs as a scenario.

Candidates also report that the interviews feel like a two-way conversation and that you should be ready to steer the discussion of your past projects and technical decisions. Some describe inconsistent experiences with interviewers. If a prompt is vague, as the open design question is by construction, state your assumptions out loud and confirm them before you build on them.

Where to focus your preparation

No fixed round order is reported, so this guide treats the loop as one preparation stage built around the stages candidates describe. Confirm the exact sequence and format with your recruiter.

Preparation focus

Candidates describe a structure that changes between loops but generally includes an initial screen, a technical assessment that is often hosted on HackerRank, and several technical and managerial interviews. Across these stages they report coverage of coding, system design and how you work in a team, along with conversations about past projects in which you are expected to explain your decisions. Some candidates report that interviewer quality is uneven. Prepare in three layers. First, get fluent at timed problem solving in one language on HackerRank, stating complexity as you go. Second, practise design and database reasoning: the open high-traffic, data-consistency prompt and query tuning under concurrency. Third, write out project, debugging, stack-choice and failure stories with numbers so the managerial conversations rest on specifics. Ask your recruiter which stages your loop includes and whether you will write code live.

What to demonstrate

• Working, efficient code in the assessment format candidates report (often HackerRank), with the complexity stated
• System design for high traffic with explicit data-consistency guarantees
• Depth on your own past projects, the technical decisions in them and how you debugged production problems
• Teamwork, handling failure and learning, which candidates report being discussed

How to prepare

• Solve problems on HackerRank in Java, Python or C++ and write the time and space complexity of each solution
• Practise the high-traffic, data-consistency design prompt on two different systems, writing out the exact mechanism that prevents duplicate or lost writes
• Run EXPLAIN on a slow relational query, add a matching index and explain the before-and-after plans
• Write project, production-incident, stack-choice and failure stories with numbers, then say each one aloud

Where candidates lose points

Telling the complex-project story in the plural, so your own decisions never become visible

For every challenge in the story, say what you personally designed, decided or wrote, and name who owned the rest. Rehearse it aloud and count how often you say 'I' when describing decisions.

Answering the production-debugging question with a generic checklist instead of an incident you actually handled

Pick one real incident and prepare its numbers: impact, how quickly you mitigated it, the hypothesis that turned out wrong, the root cause and the follow-up you shipped. Use the mitigate, timeline, narrow, verify, prevent structure to tell it.

Drawing boxes for the high-traffic design prompt without saying which data must never be wrong or how that is enforced

Before drawing anything, name the invariant (no overselling, no double charge) and write the exact enforcement mechanism: a conditional update, a unique constraint, an idempotency key or a version check. Then say how replica lag and caching interact with it.

Submitting assessment code that passes the sample input but fails on edge cases, with no complexity stated

In HackerRank practice, test empty input, a single element, duplicates, negative numbers and the largest input size before submitting, and write the time and space complexity next to every solution.

Naming technologies such as Kubernetes, a cache or a message queue in a stack-choice answer and then being unable to explain them

For every tool you mention, prepare two sentences on how it works internally and why you picked it over an alternative. The cloud, CI/CD and container tools are listed as nice-to-haves, so it is better to say honestly how much you have used them than to overclaim.

Questions & practice

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?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

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

Hard · reconciliation · range hashing · throttling

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

Approach

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

Follow-up

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

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?

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?

Can you walk us through a complex project you led and the specific technical challenges you encountered?

Medium · Technical Projects and Experience

Approach

1. Pick a project where you made the technical decisions yourself, not only implemented tickets. Open with one sentence of context: what the system did, who used it, and one scale number such as requests per second, row counts, users or team size.
2. Name two specific challenges. For each, give the options you weighed, the one you chose, why, and evidence that it worked. Example shape: 'Batch imports locked the orders table; I compared chunked commits with a staging table plus swap, chose chunking because it kept the schema unchanged, and p99 write latency during imports fell from X to Y.'
3. Keep your contribution separate from the team's. Say 'I' for what you designed, wrote or decided, and name who did the rest. A story told entirely in the plural hides your own role.
4. Only name components you can explain one level deeper: the schema, the failure handling, how you tested the risky part and how it was deployed. Expect a follow-up on any of them.
5. Close with the outcome and one thing you would do differently. A specific retrospective point shows judgement without undercutting the result.

Follow-up

• If traffic had been ten times higher, which part of that design would have failed first?
• What alternative did you reject, and under what conditions would it have been the better choice?
• How did you test the riskiest change before it reached production?

What is your process for choosing a specific technology stack for a new feature?

Medium · Technical Projects and Experience

Approach

1. Start from requirements, not tools: latency and throughput targets, the shape of the data, whether it needs transactions or joins, expected growth, and how long the feature will live.
2. Then weigh the constraints that usually decide the choice: what the team already runs and can operate during an outage, familiarity and hiring, licence and hosting cost, fit with existing auth, CI/CD and monitoring, and how mature the library or service is.
3. Default to the existing stack and make a new technology earn its place with a requirement the current one cannot meet. For example, keep a relational database when the feature needs transactional updates across related rows, and add a search engine only when full-text relevance or faceting is required.
4. Reduce risk with a time-boxed spike against the hardest requirement. Record the options and the reason for the choice in a short decision record, and keep the choice reversible by putting it behind an interface or a single service boundary.
5. Use a real decision from your own work, including the cost you knowingly accepted.

Follow-up

• Tell me about a technology choice that turned out wrong. How did you move off it?
• How would you persuade a team that prefers a different stack?
• When is it worth adding a new language or database to an existing system?

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

Medium · Technical Projects and Experience

Approach

1. Treat maintainability and scalability separately, because they are different properties. Maintainability is how cheaply and safely the next engineer can change the code. Scalability is how the system behaves as load or data grows.
2. For maintainability, name concrete practices: small modules with clear interfaces; dependency injection so business logic can be unit tested; design patterns used where they remove real duplication (strategy for swappable algorithms, adapter around a third-party API, repository around data access); and review backed by linting and tests in CI.
3. For scalability, name the mechanisms: stateless services that scale out behind a load balancer, indexes that match actual query patterns and are checked with EXPLAIN, pagination instead of unbounded reads, caching of hot reads with a clear invalidation rule, and a queue for slow work.
4. State the trade-off. Abstraction added before a second real use case usually makes code harder to change, so I generalise when the third similar case appears, and I measure before I optimise.
5. Anchor the answer with one refactor and one performance fix from your own work, each with a before-and-after metric and the tests that made the change safe.

Follow-up

• How do you decide that code needs a refactor rather than another patch?
• Which tests do you write for code that talks to a relational database?
• How would you make this service handle ten times its current load?

How would you design a [specific system] to handle high traffic and ensure data consistency?

Medium · Problem-Solving and System Design

Approach

1. The reported prompt leaves the system unnamed, so practise one skeleton on two or three systems, for example a booking or inventory service and an order ledger. Fix the scope first: core operations, read/write ratio, peak requests per second, data size, and which operations must never be wrong.
2. Lay out the high-traffic path: load balancer, stateless app servers that scale horizontally, a cache for hot reads (cache-aside with a TTL and delete-on-write), a relational primary with read replicas, and a message queue that absorbs write bursts and moves slow work off the request path.
3. Make consistency explicit. Keep invariants inside transactions. Prevent double writes with unique constraints and conditional updates (UPDATE stock SET qty = qty - 1 WHERE id = ? AND qty > 0, or a version column for optimistic locking). Use client idempotency keys so retries are safe, and send read-your-own-writes reads to the primary, because replicas lag.
4. When one primary cannot take the writes, partition by a key that keeps each transaction on one shard (account or user id) and say which queries become cross-shard. For workflows that span services, prefer an outbox table plus consumers over two-phase commit, and accept eventual consistency only where the business can tolerate it.
5. Close with failure modes (cache down, replica behind, queue backed up, hot key) and the metrics that would warn you first: p99 latency, replication lag and queue depth.

Follow-up

• Two users try to buy the last item at the same instant. Walk through exactly what happens.
• Replica lag reaches several seconds. Which reads break, and how do you fix them?
• One key gets far more traffic than the others. What changes in your design?

How do you approach debugging a critical production issue under pressure?

Medium · Technical Projects and Experience

Approach

1. Mitigate before you diagnose. Confirm impact from user-facing signals (error rate, latency, failed jobs), then use the fastest reversible lever: roll back the last deploy, turn off a feature flag, fail over or shed load. Say what each lever costs.
2. Build a timeline of what changed just before the symptom (deploys, config, schema migrations, traffic shape, a dependency's status) and map the blast radius: every user or one tenant, every endpoint or one, every host or one. Narrowing the blast radius often halves the hypothesis space.
3. Go from metrics to traces to logs. Find the failing component on dashboards, follow one failing request through traces, then read the logs for that request id. Test the cheapest hypothesis that rules out the most causes: if only one host is erroring, a code bug is unlikely.
4. Keep communication running alongside: one incident owner, regular status updates to stakeholders, and a written log of what has been tried so that no experiment is repeated under pressure.
5. Finish by separating trigger from root cause, then the fix and a blameless postmortem with owned action items, such as an earlier alert, a regression test or a guardrail. Ground the whole answer in one real incident with impact numbers.

Follow-up

• The rollback did not stop the errors. What do you check next?
• How do you tell whether a spike in database connections is the cause or a symptom?
• What alert would have caught this before users noticed?

Suggested practice checklist

Days one to three build the coding and relational-database foundation the assessment and technical interviews draw on. Days four to six work the five reported questions, and day seven covers behavioral stories and a full mock.

Day 1 — Coding assessment: core patterns in your language

• Pick Java, Python or C++ and solve two problems each on hash maps, two pointers or sliding window, and BFS/DFS on HackerRank so its editor and input handling feel familiar.
• Solve the redelivered-event-batch and idempotency-fingerprint practice problems, then list and test their edge cases: empty batch, duplicate ids, out-of-order events, key order in nested objects.
• Write one line of time and space complexity under every solution.

Deliverable: Six passing HackerRank solutions, two practice-problem solutions with edge-case tests, and a complexity line for each.

Day 2 — Complexity walkthroughs and code quality

• Solve the projection-diff practice problem, then explain its complexity aloud, including why the per-row point-read version is worse.
• Do three heap, sorting or binary-search problems, and for each state the brute force, the improvement and the complexity of both.
• Refactor one solution from day one for readability: extract functions, rename variables and add unit tests.

Deliverable: A diff solution with a spoken complexity explanation, three brute-force-versus-optimised complexity notes, and one refactored, tested solution.

Day 3 — Relational databases under concurrency

• Take a slow query from your own work or a sample schema, run EXPLAIN, add a composite index that matches its WHERE and ORDER BY, and compare the plans. This prepares the reported scenario about tuning a query for high concurrency.
• Write the concurrent-edit update path from the practice question using a version column, and explain what the losing writer sees.
• Work the tenant denormalisation and live-backfill practice question: batch size, locking, and how reads behave during the backfill.

Deliverable: Before-and-after query plans with the chosen index, a version-checked UPDATE statement, and a written backfill plan.

Day 4 — System design: high traffic with data consistency

• Run the high-traffic, data-consistency prompt on two systems (inventory or booking, and an order ledger): requirements, estimates, diagram, consistency rules and failure modes.
• For each system, write the exact statement or mechanism that prevents duplicate or lost writes.
• Outline the maintainability-and-scalability answer using one refactor and one performance fix from your own work, each with a before-and-after number.

Deliverable: Two design diagrams with consistency notes, the anti-duplication mechanisms written out, and an outlined maintainability answer with two examples.

Day 5 — Project deep dive and stack choices

• Write the complex-project story: context with a scale number, two challenges with options and the choice made, the result, and what you would change.
• For each technology named in that story, write two sentences on how it works internally and why it beat an alternative.
• Build the stack-choice answer around one real decision: requirements, options, the spike, and the cost you accepted.

Deliverable: A written project story, a sheet explaining each technology in it, and a stack-choice answer based on a real decision.

Day 6 — Production debugging and incident story

• Write out one incident you handled as mitigation, timeline, hypothesis tests, root cause and follow-ups, with numbers for impact.
• Work the outage-ownership practice question and compare its structure with your own incident.
• Have a friend give you a symptom, such as p99 latency rising after a deploy that a rollback did not fix, and talk through your next three checks aloud.

Deliverable: An incident story with numbers, notes from the outage practice question, and a recorded walkthrough of the debugging scenario.

Day 7 — Behavioral stories and a full mock

• Write stories about a failure you learned from, a code-review disagreement, and explaining a trade-off to a non-technical stakeholder. Use the unblocking-a-teammate and deadline-debt practice questions as models.
• Run a mock aloud: one coding problem, the design prompt on a system you have not practised, and two behavioral prompts.
• Write three to five questions for your interviewers about the team's systems, its stack and how module ownership works.

Deliverable: Three written behavioral stories, notes from a full mock, and a list of three to five questions to ask.

Behavioural preparation

Candidates report that the managerial and technical conversations go deep into their past projects and technical decisions, and that failures, how they learn, and how they contribute to a team are also discussed. Prepare stories with specific decisions, numbers and your own role, plus at least one honest failure.

1. How do you approach debugging a critical production issue under pressure?
2. Walk through a complex project you led, and the technical challenges you had to solve in it.
3. What is your process for choosing a specific technology stack for a new feature?
4. Tell me about a technical decision of yours that turned out wrong: how you found out, what it cost, and what you changed afterwards.
5. Describe a time you explained a technical trade-off to a product manager or another non-technical stakeholder, and how you framed the options.
6. Describe a code review in which you and a colleague disagreed about a design, and how it was resolved.

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?

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?

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?