Comet Software Engineer Interview Guide

The 60-second brief

Candidate reports describe Comet's Software Engineer role as backend and infrastructure work: core backend services, data pipelines and high-concurrency systems. The reports do not name a specific consumer product, customer or tech stack, so this guide does not guess at one. What they do state is that the engineer designs, builds and maintains the systems behind the product, and that reliability and scale are the recurring themes. For preparation, treat the role as a backend position where you will be asked to reason about traffic growth, data stores, availability and how you would test and operate what you build.

This guide is for engineers preparing for Comet's Software Engineer loop, including the SDE-2 level that candidates mention, where the reported experience range is roughly three to six years.

Candidates report three rounds over roughly three to five weeks: Technical Screening, Deep-Dive Interviews and a Practical Assessment that is described as a hands-on coding or system design task.

Focus areas

• Interview Assessments
• Time-Constrained Coding/Design Tasks
• System Design

Overview

The reported questions cluster around one theme: how a backend system behaves as load, data volume and requirements change. Four of the seven are design or architecture questions (a high-scale traffic scenario, high availability, schema design for a fast-changing product, and microservices versus a monolith). Two cover engineering practice (testing distributed systems, and prioritising when scope exceeds time). One is a story about optimising slow code. That mix means you need a repeatable way to structure a design answer, plus two or three real stories from your own work.

The topics candidates list under architectural scalability are load balancing, database sharding and replication, and caching layers, with example prompts about a sudden tenfold spike in API traffic and which metrics to watch. Prepare these as a chain rather than three separate facts: where traffic first saturates, what a balancer or cache buys you, what sharding or replication costs in consistency and operations, and how you would notice trouble before users do.

The role lists a strong backend language, distributed-systems experience and familiarity with relational or NoSQL databases as must-haves, and cloud infrastructure (AWS or GCP), Kubernetes and CI/CD as extras. Be ready to explain how your main language and framework behave under the hood, and to name concrete tools you have used for deployment and monitoring. Do not claim stack knowledge you cannot defend in detail.

Candidates also report that the practical stage can be a take-home, that it can be intensive for SDE-2 roles, and that writing down assumptions and constraints alongside the code matters. Practise producing a small, correct, tested solution with a short written rationale, rather than a large one. Since the reported emphasis is on explaining why a design was chosen, rehearse stating the alternative you rejected and the cost of your choice in every answer.

The Comet interview process

Candidates describe the loop as three stages in this order, with details varying by team and seniority. The stages below say what is reported and how to prepare for each.

Technical Screening

Candidates describe the Technical Screening as an initial check of technical skill and fit for the role. Little else is reported about its format, so prepare for a conversation that can touch your primary language, the frameworks you rely on and a compact design scenario. Candidates also say that work arrangements (hybrid or remote, which varies by team) get clarified at the initial screen, so bring that question with you. Aim for short, structured answers: state the requirement, the main trade-off and your choice.

What to demonstrate

• Core technical skill at an introductory level, as the stage is described
• Fit for the role and the team
• Clarity in explaining how your primary language and frameworks work

How to prepare

• Pick your main backend language and rehearse how its runtime, concurrency model and common framework behave under load.
• Practise a two-minute design answer for a sudden tenfold spike in API traffic: load balancing, caching, replication, and what you would monitor.
• Prepare a short account of the largest system you owned: its data store, its failure modes and what you changed.
• Write the questions you want answered about team, stack and work arrangements.

Deep-Dive Interviews

The Deep-Dive Interviews are reported as in-depth sessions on specific technical competencies and problem solving. This is where the schema design, high availability, microservices versus monolith and testing questions fit by type. Candidates also report that failing to articulate trade-offs is a common stumbling block, so every answer should end with the option you rejected and why. Expect to go deeper than a first pass: follow your own answer to the failure case and the cost.

What to demonstrate

• Depth in specific technical areas such as data stores, availability and architecture style
• Methodical problem solving, including how requirements are narrowed before designing
• Ability to explain the reasoning and trade-offs behind a design

How to prepare

• Work the schema question end to end: start from the access patterns, then evolve a table with additive changes and backfills while the product keeps shipping.
• Write a one-page comparison of a monolith and microservices for a team of your size, naming the operational cost of each.
• List the availability patterns you can defend (redundancy, health checks, failover, graceful degradation, retries with limits) and the failure each one does not cover.
• Prepare your distributed-systems testing answer: unit and contract tests, integration with real dependencies, fault injection and load tests.

Practical Assessment

The Practical Assessment is reported as a hands-on coding or system design task, and candidates say a take-home version can appear for SDE-2 roles and can be intensive. The reported advice is to finish the core requirements first, then add extras, and to write down the assumptions and constraints behind your choices. Treat the written rationale as part of the deliverable. If the task is live, narrate the same decisions aloud.

What to demonstrate

• Working, readable code or a coherent design produced from a concrete brief
• Prioritisation when the scope is larger than the time available
• Documented assumptions and a justified approach

How to prepare

• After each exercise, write a short note listing your assumptions, what you cut and what you would add next.
• Practise a small design task end to end: requirements, API, data model, one bottleneck and one failure mode.
• Rehearse your answer to scope exceeding time: what is mandatory, what is deferred and how you would say so.

Where candidates lose points

Answering the traffic-spike design with a list of components and no numbers or bottleneck

Estimate request rate, payload size and data volume first, find the first resource to saturate, then add a balancer, cache or replica only where it relieves that point. Finish with the metrics you would watch.

Declaring microservices or a monolith the better choice without tying it to team size and operations

Compare them on deployment independence, data ownership, network failure modes, debugging and the team that must run them. Say when you would split a monolith and what you would extract first.

Designing the schema for today's fields and ignoring how it changes in production

Start from access patterns and key queries, then explain additive migrations, backfills in batches, nullable-then-required columns and when a flexible column is justified over a new table.

Spending the practical assessment on extra features while core requirements are shaky or untested

Implement the stated requirements first, write tests for the edge cases, then add extras. Put assumptions, constraints and what you deliberately left out in a short written note.

Describing testing of distributed systems as unit tests only

Name the layers: unit, contract tests between services, integration against real dependencies, and fault injection for timeouts, retries and partial failure. State what each layer cannot catch.

Questions & practice

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

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

Approach

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

Follow-up

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

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

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

Approach

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

Follow-up

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

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?

How do you approach database schema design for a rapidly evolving product?

Medium · System Design and Architecture

Approach

1. Model the core entities normalised, with surrogate primary keys, foreign keys, NOT NULL and unique constraints. These are the parts that rarely change, and constraints catch bugs while the product is moving fast. Keep genuinely unstable or sparse attributes in a JSON column (for example Postgres JSONB with a GIN index) and promote a field to a real column once it stabilises and gets queried or validated.
2. Change the schema with expand/contract (parallel change). Add the new column or table, deploy code that writes to both, backfill in small batches, switch reads, then drop the old structure in a later release. Every migration must work with both the previous and the next application version, because a rolling deploy runs both at once.
3. Know which DDL takes locks. In Postgres, ADD COLUMN without a default is metadata-only, and since version 11 so is a non-volatile default. CREATE INDEX CONCURRENTLY avoids blocking writes but cannot run inside a transaction block. Setting a column NOT NULL scans the table, so add a NOT VALID check constraint, validate it, then set NOT NULL.
4. Keep migrations versioned in source control and applied by a tool such as Flyway or Alembic, never by hand. Backfills are throttled jobs that can resume, not one giant UPDATE that holds locks and bloats the write-ahead log.
5. State the trade-off: JSON columns buy speed of change at the cost of type checks, referential integrity and good planner statistics. Entity-attribute-value tables are usually worse than either option.

Follow-up

• How do you rename a column on a large, hot table without downtime?
• A backfill touches 200 million rows. How do you run it without hurting production latency?
• When would you pick a document store over a relational schema for this product?

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?

How would you design a system to handle [specific high-scale traffic] within a limited timeframe?

Medium · System Design and Architecture

Approach

1. Pin the traffic down before drawing boxes: peak requests per second, read/write ratio, burst shape (a spike at a known time versus steady growth), payload size and how long the peak lasts. A quick estimate such as 50k reads/s and 2k writes/s at peak decides whether a cache and a queue are enough or whether the data layer must be partitioned.
2. Keep the request tier stateless behind a load balancer so it scales horizontally. If the spike happens at a known time, pre-scale before it starts: autoscaling reacts to load that has already arrived and lags a sharp burst.
3. Take reads off the database with a CDN or edge cache for shared content and an in-memory cache (cache-aside with TTLs) for hot keys. Name the hot-key risk and how you handle it: request coalescing, or replicating the key across shards.
4. Absorb write bursts with a durable queue. Accept the request, persist it, return 202, and let workers drain at a rate the database can sustain. Attach an idempotency key to each write so client retries do not create duplicates.
5. Protect the core with admission control: token-bucket rate limits per client, load shedding with 429 or 503 once queue depth or latency crosses a threshold, and graceful degradation of non-essential features. The trade-off you accept is eventual consistency on the queued writes.

Follow-up

• One key, such as a single popular item, receives most of the traffic. How do you stop it overloading one cache node or one shard?
• The queue is growing faster than the workers drain it. What do you monitor, and what do you do?
• How would you load-test this before the real spike to confirm the design holds?

What architectural patterns would you use to ensure high availability for our core service?

Medium · System Design and Architecture

Approach

1. Start from a target and a budget. 99.9% availability allows about 8.8 hours of downtime a year, and serial dependencies multiply: two 99.9% dependencies in series give roughly 99.8%. That arithmetic tells you which hard dependencies to remove or make optional.
2. Remove single points of failure. Run several stateless replicas across availability zones behind a load balancer with health checks, and give the database a primary, a standby and automated failover. State the RPO trade-off: asynchronous replication can lose acknowledged writes on failover, while synchronous replication adds write latency.
3. Contain failures between services with timeouts on every call, retries with exponential backoff and jitter (only for idempotent operations), circuit breakers that fail fast once a dependency is unhealthy, and bulkheads (separate pools) so one slow dependency cannot exhaust every thread.
4. Plan degraded modes: serve stale cached data, disable non-essential features with flags, and queue writes when a downstream service is down rather than failing the whole request.
5. Treat deployment as an availability risk. Use rolling or canary releases with automatic rollback on error-rate or latency alerts, and keep schema changes backward compatible so old and new versions can run side by side.

Follow-up

• During a failover both nodes believe they are primary. How do you prevent split-brain (quorum, fencing tokens, leases)?
• Your retries make an outage worse. How does a retry storm happen, and what stops it?
• When would you choose active-active across regions over active-passive, and what does it cost you in consistency?

Can you explain the trade-offs between microservices and monolithic architectures in our context?

Medium · System Design and Architecture

Approach

1. Start by asking about the context: team size and how many teams ship, deploy frequency, whether parts of the system have very different scaling or reliability needs, and how mature CI/CD and observability are. The right answer depends on these, and saying so is the substance of the answer.
2. Monolith strengths: one deployable, in-process calls with no network failure modes, ACID transactions across modules, simple local debugging and refactoring. Its costs show up with scale: coupled releases, one slow build, the whole unit scaled for its hungriest component, and one bad module able to take everything down.
3. Microservices strengths: independent deploys and scaling, fault isolation, clear team ownership. Their costs: network latency and partial failure on every call, no cross-service transactions (you need sagas with compensating actions and a transactional outbox), a database per service, distributed tracing, and per-service pipelines, plus orchestration such as Kubernetes.
4. Give a concrete recommendation. A modular monolith with enforced module boundaries is usually the right start for a small team. Extract a service (strangler-fig style) only where there is a real seam: a component with a different scaling profile, release cadence or failure domain.
5. Name what makes a split go wrong: services that share a database or must deploy together form a distributed monolith, which carries the costs of both designs and the benefits of neither.

Follow-up

• An order must reserve inventory in one service and charge payment in another. How do you keep them consistent without a distributed transaction?
• Which component would you extract first from an existing monolith, and how do you migrate traffic to it safely?
• How do you version an API between services so one team can deploy without breaking another?

How do you approach testing strategies for complex, distributed systems?

Medium · Problem-Solving and Technical Execution

Approach

1. Layer the tests. Fast unit tests cover pure logic with the clock, randomness and I/O injected. Integration tests run against real dependencies started in containers (Testcontainers, for example) rather than mocks of the database or broker. A thin end-to-end suite covers only the few critical user paths.
2. Test the boundaries between services with consumer-driven contract tests (Pact, for example), so a provider change that breaks a consumer fails in the provider's CI rather than in a shared staging environment.
3. Test failure behaviour explicitly. Deliver the same message twice and assert idempotency; reorder messages; kill a worker in the middle of a job; inject latency, timeouts and dropped connections with a fault proxy such as Toxiproxy; check that retries, timeouts and circuit breakers behave as intended.
4. Make concurrency bugs reproducible: control time with a fake clock, use deterministic seeds, and add property-based tests for invariants (no duplicate charges, totals conserved). Retry-until-green and sleep-based waits hide real races, so treat flaky tests as bugs.
5. Extend testing into production: canary releases compared on error rate and latency, synthetic checks on key flows, and controlled fault-injection experiments, all backed by metrics and traces that show whether the system kept its guarantees.

Follow-up

• A test passes locally and fails one run in twenty in CI. How do you find the cause?
• How would you prove that a consumer is idempotent under at-least-once delivery?
• What do you test before running a schema migration across a service that has several running versions?

Given a set of requirements, how do you prioritize tasks when the scope is larger than the available time?

Medium · Problem-Solving and Technical Execution

Approach

1. List every requirement and sort it into must, should and could (MoSCoW) against one question: what has to work for the result to be judged complete. Write rough estimates next to each item so the cut is a visible decision and not a guess.
2. Build a thin vertical slice first: one path working end to end, with input, core logic, storage and output, before deepening any single layer. Something runnable early means a hard stop still leaves a working result.
3. Protect quality on the core path rather than spreading effort: tests for the main logic and its edge cases, clear error handling, readable structure. Leave optional features out rather than half-building them.
4. Write down assumptions and deferred items as you go, in a README or decision log: what you assumed where the requirements were ambiguous, what you cut, why, and how you would build it next. Candidates report take-home assessments for some roles, and this is where that write-up matters.
5. Set checkpoints to re-plan. At each one, compare progress with the estimates and cut scope again if you are behind, instead of working on and missing the core.

Follow-up

• A stakeholder says every item is a must-have. How do you get to a real priority order?
• Halfway through, you find the core feature will take twice your estimate. What do you do, and who do you tell?
• Which item did you cut, and how would you have added it with another day?

Read latency spikes on a sixty-second sawtooth

Medium · cache stampede · single-flight · ttl

The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.

Approach

1. Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
2. Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
3. Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
4. De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.

Follow-up

• The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
• How does your answer change if the recompute takes 4 seconds instead of 250 ms?

Suggested practice checklist

The plan follows the three reported rounds: system design and scalability first, then schema and architecture trade-offs, then hands-on coding and the written rationale.

Day 1 — Map the loop and your stack

• Write the three reported rounds in order and note what each type of question needs from you.
• List your primary language, database and deployment tools, and write two sentences on how each behaves under load.
• Pick two projects from your own work to mine for stories on performance and trade-offs.

Deliverable: A one-page loop map, a stack summary and two chosen project stories.

Day 2 — Design for a traffic spike

• Answer the high-scale traffic design question aloud for a tenfold jump in API traffic, covering estimation, load balancing, caching and replication.
• Add the monitoring you would put in place: latency percentiles, error rate, saturation and queue depth.
• Redo the answer with one dependency down and record how it degrades.

Deliverable: A written design outline with capacity estimates, a metrics list and a failure case.

Day 3 — High availability and architecture style

• Write the high-availability patterns you would use, and for each the failure it does not protect against.
• Prepare a monolith-versus-microservices comparison with a recommendation for a small team and one for a large organisation.
• Say aloud when you would extract a service from a monolith.

Deliverable: A pattern table with limits, and two recommendations with reasons.

Day 4 — Schema design and data access

• Design a schema for a product whose fields keep changing, then script three live migrations with backfills.
• Write a note comparing relational and NoSQL choices for the same data.

Deliverable: A schema with a migration plan, the keyset paging solution and a relational-versus-NoSQL note.

Day 5 — Timed coding for the practical assessment

• Write tests for edge cases on each, including empty input, ties and out-of-order data.
• After each, write a short note of assumptions and what you cut.

Deliverable: Three working solutions with tests and three short assumption notes.

Day 6 — Testing, debugging and prioritisation

• Outline a test strategy for a multi-service system covering unit, contract, integration and fault-injection layers.
• Answer the scope-exceeds-time question with a concrete prioritised list from a past project.

Deliverable: A layered test plan, a written diagnostic sequence and a prioritised scope list.

Day 7 — Stories and full dry run

• Write your performance optimisation story with baseline, diagnosis, options, fix and measured result.
• Run one full mock: a design question, a coding task and your story, then record two questions for the interviewer.

Deliverable: A finished optimisation story, two supporting stories and a completed mock with two questions.

Performance, prioritisation and ownership stories

The reported behavioral material for this loop is about engineering judgement: how you found and fixed a slow code path, and how you prioritise when requirements exceed available time. Candidates also report that explaining the why behind decisions and admitting a suboptimal choice matter, so pick stories where you made the call, gave evidence and can state what you would change.

1. Given a set of requirements, how do you prioritize tasks when the scope is larger than the available time?
2. Tell me about a design decision you later realised was suboptimal. What did you change and how did you explain it?
3. Describe a time you shipped under a deadline, what you deliberately deferred and how you limited the risk.
4. Tell me about a time requirements were ambiguous or changing. How did you turn them into concrete technical tasks?

Describe a time you had to optimize a piece of code that was causing performance bottlenecks.

Medium · Problem-Solving and Technical Execution

Approach

1. Choose a case where you found the bottleneck by measurement: a profiler or flame graph, a query plan, or latency percentiles from monitoring. Open with the before number (for example p95 latency or CPU for one endpoint) so the improvement has a baseline. Use only figures you actually measured.
2. Spend your time on diagnosis and options. Say what you ruled out, what the hot spot was (an N+1 query, a missing index, an accidental quadratic loop, repeated serialization, lock contention) and the two or three fixes you weighed with their costs in complexity and risk.
3. Describe the change you chose and why it was proportionate: a targeted fix, not a rewrite. Give the after number from the same workload and say how you confirmed it, such as a benchmark, a canary or a load test.
4. Cover safeguards: how you checked that behaviour stayed correct, what could have broken, how you could roll back, and any regression test or alert you left behind.
5. Avoid the stories that sink this answer: no baseline or proof of cause, credit that belongs to the team, or optimising something that was never a user-visible problem.

Follow-up

• How did you know your change, and not traffic or caching effects, caused the improvement?
• What did the optimisation cost in readability or maintenance, and would you accept that trade again?
• How did you decide this was worth fixing now rather than leaving it?

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?

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?