Century Pacific Food Software Engineer Interview Guide

The 60-second brief

Century Pacific Food is a Philippine food and beverage company, and candidates describe this Software Engineer role as software that supports how goods get from production lines to consumers. The reported work areas are warehouse operations and logistics and application management, so the code you write or maintain feeds supply chain and operational decisions. Candidates describe the engineer as a technical partner to internal departments, turning requests from logistics or warehouse staff into specifications, building and maintaining applications, and reviewing teammates' code.

This guide is for engineers interviewing for a Software Engineer position at Century Pacific Food. It covers the four reported stages, the technical and behavioral questions candidates report (debugging a production issue, scalable and maintainable code, unit testing and quality assurance, learning a technology on a deadline), the live coding session candidates mention, and a one-week plan. It does not assume a specific language, because candidates describe the stack as depending on the team.

Candidates report four rounds over roughly three to five weeks: an HR screen, a technical assessment, a leadership assessment and a final decision. A live coding session with a developer and a closing conversation with the head of the IT group are both mentioned.

Focus areas

• Application Management
• Live Coding
• Coding Problem Solving

Overview

Candidates describe the work as business software in a manufacturing and distribution setting. The reported areas are warehouse operations and logistics, plus application management: keeping existing systems running, fixing them when they fail, and extending them when operations change. That shapes what a good answer sounds like. A defect in this kind of system shows up as a wrong stock count, a stuck order or a report that disagrees with the floor, so your debugging and testing stories land best when they name a concrete symptom, the evidence you gathered and the fix that held.

The technical side is reported as live coding, general coding problem solving and software engineering fundamentals. The reported questions are practice-oriented rather than puzzle-oriented: how you debug a complex production issue, how you keep code scalable and maintainable, and how you approach unit testing and quality assurance. Prepare each as a short method you can state in order, backed by one real example from your own work with a number attached, such as a defect rate, a response time or a deployment you made safer.

The people side matters as much. Candidates report that the leadership assessment looks at leadership qualities and cultural alignment, with conflict resolution, communication with non-technical colleagues in logistics or operations, and mentoring junior developers as the named areas. Even as an individual contributor you need two or three stories where you disagreed about technical direction, explained a technical constraint in plain language, or helped a less experienced teammate. Rehearse them in the situation, task, action, result shape.

Requirements candidates describe are modest and broad: strong programming in the languages the team uses, solid database knowledge, and experience building or maintaining enterprise applications. Logistics or supply chain software, cloud infrastructure and agile working are listed as pluses. Read the job posting for the exact languages, then spend your coding practice there, and make sure you can talk about schemas, queries and data consistency in the applications you have maintained.

The Century Pacific Food interview process

Candidates report four stages in order: Initial HR Screen, Technical Assessment, Leadership Assessment and Final Decision, spread over about three to five weeks. Treat this as what candidates describe rather than a published schedule, and confirm the format with your recruiter.

Initial HR Screen

Candidates describe this first stage as an HR screening of basic qualifications and fit for the role. No technical questions are reported for it, so the goal is a clear, short account of your background and a concrete reason for wanting a software role at a food and distribution business. Use it to confirm what the later stages will look like.

What to demonstrate

• Basic qualifications against the role's reported requirements: programming, database knowledge, enterprise application experience
• Fit for the role, as described by HR
• Communication: how clearly you summarise your own career

How to prepare

• Prepare a two-minute walk through your CV that highlights applications you built or maintained and the databases behind them.
• Write down why you want this company and role, referring to the reported work areas of warehouse operations, logistics and application management.
• Have your availability, location and compensation expectations ready, and ask HR what each later stage involves.

Technical Assessment

Candidates describe deeper technical evaluation of coding skills and problem solving, and mention a live coding session with a developer. The reported topic areas are live coding, coding problem solving, application management and software engineering fundamentals, with code optimization, system architecture and debugging methodology named as things to be ready for. Practise talking while you code, because the session is a conversation as much as a solution.

What to demonstrate

• Hands-on coding ability in a live session
• Problem solving: breaking a requirement down and choosing an approach out loud
• Debugging methodology and root cause analysis
• Awareness of testing and quality assurance practice

How to prepare

• Solve two or three small coding problems in your main language while narrating, then write the unit tests for them afterwards.
• Prepare a spoken method for the production debugging question: reproduce, narrow the cause, fix, confirm and prevent a repeat.
• Prepare a concrete answer to the scalable and maintainable code question, with one performance improvement you measured.
• Prepare how you structure unit tests and wider quality checks, naming what you test at each level and what you leave to others.

Leadership Assessment

Candidates describe this stage as covering leadership qualities and cultural alignment, and say leadership and collaboration topics come up in the manager and final interviews. The named areas are conflict resolution on technical direction, working with non-technical stakeholders in logistics or operations, and mentoring junior developers. It is the stage where behavioral stories carry the most weight.

What to demonstrate

• Leadership qualities shown through examples, even in an individual contributor role
• Cultural alignment, as candidates describe it
• Conflict resolution on technical direction
• Communication with non-technical colleagues

How to prepare

• Write one story per reported area (disagreement, explaining a technical problem to a non-technical colleague, helping a junior developer) in situation, task, action, result form.
• Prepare the story about learning a new technology or framework under a tight deadline, including what you chose not to learn.
• Rehearse explaining a technical limitation to someone in operations without jargon, in under a minute.
• Prepare two questions about the team's current technical challenges to ask at the end.

Final Decision

Candidates describe the last stage as the point where they are told the outcome after all assessments. They also mention a final interview with the head of the IT group, where the reported advice is to connect your experience to the company's technical direction and your longer-term contribution. Responsiveness between stages is reported as helpful, since candidates say they are notified after each one.

What to demonstrate

• Overall outcome across the earlier stages
• Alignment between your experience and the IT group's direction, in the final interview candidates describe
• Longer-term potential to contribute

How to prepare

• Prepare a short account of where you want to grow technically and how that connects to application management, warehouse and logistics software.
• Reread your stories and technical examples so they are consistent with what you told earlier interviewers.
• Prepare questions about the roadmap and current technical priorities, and keep your phone and email available between stages.

Where candidates lose points

Answering the production debugging question by jumping to a fix, or by listing tools, without a sequence.

State the order out loud: confirm the symptom and its scope, check what changed recently, form one hypothesis you can disprove, read logs or data to test it, fix, add a test or alert, and write up the cause. Back it with one real incident including the wrong guess you made first.

Describing scalable and maintainable code with generic words such as clean code and best practices.

Give two specific habits with evidence: for example a measured query or loop you optimised, and a refactor, naming or review convention that made a module easier for a teammate to change. Say what trade-off you accepted.

Treating unit testing and quality assurance as one list of frameworks.

Explain what you test at each level, unit, integration and manual or acceptance checks, which edge cases you always cover (empty input, duplicates, boundaries), and how a failing test becomes part of your review and release routine.

Going quiet or rushing to code in the live coding session.

Restate the problem, confirm inputs and edge cases, outline the approach, then code while narrating. Run through a small example by hand at the end and fix what it exposes. Practise this with a partner or a recording before the session.

Giving technical stories with no business context, so a manager hears what you built but not why.

For every story, state who needed it, what problem it solved and the measurable effect. Practise explaining one technical trade-off to a non-technical listener in plain words, since cross-functional communication is a reported topic.

Questions & practice

How do you approach unit testing and quality assurance in your development workflow?

Medium · Technical and Coding Proficiency

Approach

1. Describe the test pyramid and why it has that shape: many fast unit tests on pure logic, fewer integration tests against a real database (for example one started in a container), and a small number of end-to-end tests on the flows that matter most. Lower layers run faster and point to the exact failing unit.
2. Say what a good unit test looks like: arrange-act-assert, one behaviour per test, a name that states the behaviour, and deterministic results (inject the clock and seed the randomness). Cover boundaries such as empty input, a single element, maximum size, nulls, zero or negative quantities, duplicates and timezone edges.
3. Mock only at boundaries you do not own, such as HTTP clients or external gateways. Too much mocking ties tests to implementation details, so a refactor breaks them without any change in behaviour. Test SQL against a real database, because constraints, transactions and NULL handling cannot be faithfully mocked.
4. For a bug, write a test that reproduces it and fails first, then fix the code, so the regression stays covered. Treat coverage as a signal, not a goal: 100% line coverage can still miss branches, and tests with weak assertions execute code without checking it. Mutation testing shows whether the assertions catch changes.
5. Fit QA into the workflow: CI runs lint, type checks and the test suite on every pull request, code review comes before merge, staging uses production-like data, and releases go out behind feature flags with monitoring. Quarantine flaky tests and fix them; rerunning them until they pass is not a fix.

Follow-up

• How do you test code that depends on the current time or on a third-party API?
• A test passes locally but fails intermittently in CI. How do you diagnose it?
• You must change a legacy module that has no tests. What do you write before touching it?

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?

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?

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?

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?

How do you ensure your code is scalable and maintainable?

Medium · Technical and Coding Proficiency

Approach

1. Make scalable concrete before changing anything: expected request rate, data growth and a latency target. Then profile to find the actual hot path. Fix algorithmic cost first, for example replacing a nested loop that matches every order against every product (O(n*m)) with a hash-map lookup (O(n+m)).
2. At the database layer, remove N+1 query patterns by batching or joining, index the columns used in WHERE and JOIN clauses, confirm the plan with EXPLAIN ANALYZE, and page large lists with keyset pagination (WHERE id > last_seen ORDER BY id LIMIT k). A large OFFSET still reads every row it skips.
3. Keep services stateless so they scale horizontally behind a load balancer. Move slow work such as report generation or notifications onto a queue, and make the workers idempotent because most queues deliver at least once. Cache read-heavy, rarely changing data with an explicit TTL or invalidation rule.
4. For maintainability, keep business rules apart from I/O so the rules can be unit-tested without a database, give each module one reason to change, inject dependencies at the boundaries, and run formatting, linting and tests in CI on every change so code review covers design instead of style.
5. Name the trade-offs. Do not build for load nobody has forecast. Splitting into services adds network failures and deployment overhead. Write down a significant design decision and its reasoning (a short decision record) so the next engineer can see why the code is shaped the way it is.

Follow-up

• Walk through code you refactored for maintainability: what was wrong with it, and how did you confirm the refactor did not change behaviour?
• A report endpoint gets slower every month as data grows. How do you find the bottleneck and fix it?
• When would you decide not to add a cache?

Design the bulk write endpoint a migration script retries blindly

Medium · batch api · partial failure · idempotency

A customer's migration script pushes 2 million resources through POST /v1/resources:batch, up to 500 items per call, and retries any call that errors or times out. Within a call some items fail validation, some collide with rows that already exist, and some succeed. Specify the request and response shape, whether a batch is atomic or per-item, how idempotency works for the call and for each item, the status code for a mixed outcome, the size and item-count limits with their error codes, and exactly what the script does after a timeout mid-batch.

Approach

1. Choose atomicity deliberately and price it. All-or-nothing means one transaction holding locks for the whole batch on a primary already absorbing about 1.2k writes/second, which bounds batch size by lock duration, and it turns one bad row into 499 rejections the script must resend. Per-item partial success is the right default for a migration, and the contract's job is then to make a partial outcome impossible to miss.
2. Require a client-supplied id on every item and echo it in every result. Deriving a per-item key from the array index breaks the first time the script resends a batch with the failures removed: the indices shift, previously-succeeded items acquire new keys, and they are created a second time.
3. Key the effects at two levels. The call's Idempotency-Key covers an exact resend of the same bytes; per-item keys of (tenant_id, client_item_id) make a partially-applied batch safe to resend whole. Resending an identical batch must reproduce the same per-item results, not 500 conflicts the script has to interpret.
4. Answer a mixed outcome with one status plus per-item detail: 200, or 207 borrowed from WebDAV if you prefer it - document whichever you pick - carrying an array of client_item_id, per-item status, and either resource_id or an error code from the same taxonomy the single-item endpoint uses. Reserve 4xx for the request as a whole: unparseable body, too many items, payload over the limit (413). Put a failed count at the top level so that even a script checking only the cheapest thing cannot conclude success while rows were dropped.

Follow-up

• At 500 items per call, what is the wall-clock time for 2 million rows, and what pacing do you publish so the migration does not become an incident?
• One item in every batch fails with the same code. How does the script discover that without a human reading logs?

Can you walk me through your process for debugging a complex production issue?

Medium · Technical and Coding Proficiency

Approach

1. Start with impact and mitigation before root cause: which users or flows fail, since when, how often. If a recent deploy or config change lines up with the first bad metric, roll it back or turn the feature flag off first. Restoring service comes before explaining the failure.
2. Build a timeline of deploys, config changes, schema migrations, traffic spikes and dependency incidents, and line it up against the first anomaly. Follow one failing request through the logs by its request or trace id instead of grepping timestamps across services.
3. Reproduce with the smallest failing case: take the real input from the logs and replay it locally or in staging. If it will not reproduce, add targeted logging or metrics around the suspect path. If the code changed, run git bisect between the last good and first bad commit, which needs about log2(n) builds.
4. Sort intermittent failures by class and check each against the evidence: concurrency (a retried request writing twice, a lost update), resource exhaustion (connection pool, memory, disk, file handles) or data-dependent input (nulls, encoding, timezone and DST boundaries). Ask whether failures track load, time of day or particular records.
5. Close the loop: fix the root cause, not only the trigger. Add a regression test that fails before the fix, add the alert that would have caught it sooner, and write a blameless postmortem with a timeline and owned action items.

Follow-up

• You cannot attach a debugger in production and logs are thin. What do you add first, and how do you keep personal or sensitive data out of the new logs?
• How would you show that your fix resolved the issue, and that it did not just stop on its own?
• Rollback is off the table because a schema migration already ran. What do you do instead?

Suggested practice checklist

The week follows the reported loop: a map of the stages first, then live coding, debugging, scalability and testing for the technical stage, then stories for the leadership stage, ending with a full mock.

Day 1 — Map the loop and the business

• Write the four reported stages in order and note beside each what candidates say it covers.
• Read public information about the company's food business and write five questions about how its warehouse, logistics and application teams work.
• Read the job posting and list the languages and database technologies you must be able to discuss.

Deliverable: A one-page loop map, five written questions about the business, and a list of the technologies from the job posting.

Day 2 — Live coding warm-up

• After each solution, state its time and space complexity and the edge cases you checked.
• Record yourself once and note where you went silent or skipped restating the problem.

Deliverable: Two solved exercises, each with stated complexity and an edge-case list, and a note of two narration habits to fix.

Day 3 — Debugging a production issue

• Write your step-by-step method for the debugging question and apply it to a real incident from your history.
• Rehearse the answer aloud, covering reproduction, narrowing the cause, the fix, confirmation and prevention.

Deliverable: A written debugging method with one real incident filled in, plus a spoken take of it.

Day 4 — Scalable and maintainable code

• Pick one performance improvement and one maintainability improvement from your work and write each with before and after evidence.
• Write a short answer on how you would keep a warehouse-style application correct as data volume and users grow: indexing, batching, retries and clear module boundaries.

Deliverable: Two evidence-backed examples and a one-paragraph answer to the scalable and maintainable question.

Day 5 — Unit testing and quality assurance

• Take a function you wrote on day 2 and write unit tests covering normal, boundary, empty and duplicate inputs.
• Write your testing approach in three layers (unit, integration, manual or acceptance) and say what each catches.
• Say aloud how a bug found in production becomes a regression test in your workflow.

Deliverable: A test file for one function and a spoken answer to the testing and quality assurance question.

Day 6 — Leadership and collaboration stories

• Write the learn-a-technology-on-a-deadline story in situation, task, action, result form, including what you cut.
• Write one story each for a technical disagreement, explaining a constraint to a non-technical colleague, and helping a junior developer.

Deliverable: Four written stories with a number or concrete outcome in each result.

Day 7 — Full mock and final-conversation prep

• Run a mock in loop order: a two-minute CV walk, a live coding problem, the technical questions, then two behavioral stories.
• Write a short statement of where you want to grow and how it connects to application management and logistics software.
• Finalise two questions about the team's current technical challenges and roadmap.

Deliverable: A completed mock with notes on weak spots, a growth statement and two closing questions.

Stories for the leadership stage

Candidates report that the leadership stage looks at leadership qualities and cultural alignment, with conflict resolution, communication across technical and non-technical teams, and mentoring named as areas to prepare. For a software engineer in a warehouse and logistics setting, that means stories where your decisions had a visible effect on teammates or on operations colleagues, told with the reasoning and the result.

1. Can you walk me through your process for debugging a complex production issue?
2. Tell me about a disagreement on technical direction and how it was resolved.
3. Describe explaining a technical problem or delay to a non-technical stakeholder, such as someone in operations or logistics.
4. Tell me about a time you helped a junior developer grow or got them unstuck.
5. Why do you want to build software for a food manufacturer and distributor, and where do you want to grow in the role?

Describe a time you had to learn a new technology or framework under a tight deadline.

Medium · Technical and Coding Proficiency

Approach

1. Choose a story where the deadline was real, the technology was new to you, and you made the key decisions. Name the technology and the deadline in one sentence, then explain what you already knew that transferred, for example a similar framework, language or database model.
2. Show a method rather than effort. A strong version: I listed what the deliverable needed from the new technology, learned only that slice, built a small throwaway spike to test the riskiest assumption, and asked a colleague who had used it to review my approach before I committed.
3. Show one real trade-off. Say what you cut or deferred to hit the date, such as skipping an optimisation or using the framework's default pattern instead of a custom one, and how you recorded it so it did not become hidden debt.
4. Close with the result and a number: shipped on time, defects found after release, load or time saved, or follow-up work you scheduled. Then say what you would repeat. The mistake that sinks this answer is a story of working long hours and reading tutorials with no decision, no risk management and no outcome.
5. Where you can, tie it to the stakeholders. If the work served an operations or logistics user, say how you told them what would and would not be ready, since the role involves translating between business needs and technical delivery.

Follow-up

• What did you cut or defer to meet the deadline, and what happened to it afterwards?
• How did you know your understanding was good enough to ship, before real users hit it?
• If you had the same deadline again, what would you do differently in the first two days?

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?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

• Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
• The author says clients cannot handle a 409. How do you check whether that is true?