Interview practice · Advanced

Real-world design scenarios

Practice explaining an end-to-end solution and defending its trade-offs.

Learn this topic first: Interview lab: design, troubleshoot and code →

6 explained questions · 5 practice MCQs

Questions and answers

1. Design an order-posting operation that updates stock and accounts. (Intermediate)

Define one order as a business transaction with a stable operation ID. Validate the order, obtain required stock/account protection in a consistent order, make participating updates, record the result, and commit only when the invariant holds.

Keep remote notification outside the lock-holding path by recording outbound intent. On failure, roll back and report a meaningful result. Test insufficient stock, concurrent posting, duplicate requests, and a lost response after COMMIT. Explain who owns retry and reconciliation.

2. Design a nightly import of a large external file. (Advanced)

Land the file in a controlled IFS location with an explicit encoding and immutable input identity. Validate its format and counts, load into staging, and classify bad rows with actionable reasons before updating production data.

Process in coherent commit units with durable checkpoints and unique business keys. Keep a run ledger with accepted/rejected counts and reconciliation totals. Avoid a single opaque “file processed” flag; a partial failure should identify exactly which business units can be safely resumed.

3. Two clerks edit the same customer. How do you avoid overwriting changes? (Advanced)

Do not hold a database lock for the entire human editing interval unless that is a deliberate business requirement. Return a version token with the displayed data, then condition the update on that version.

If no row is updated, reload and show a conflict instead of overwriting blindly. Decide whether field-level merging is acceptable or whether the user must review the entire record. Audit the accepted change and test updates arriving in either order.

4. Design a data-queue worker for payment posting. (Advanced)

Persist the payment request with a unique operation key and status. Send a notification containing that key, then let a worker atomically claim or validate the request and perform the business transaction.

Record completion durably and treat repeated queue entries as expected duplicates. Reconcile pending records if a worker dies after receive. Add bounded retries, quarantine for invalid requests, and monitoring of age as well as queue depth. Do not rely on the queue as the sole payment ledger.

5. A legacy program must become an API. What would you change first? (Advanced)

Identify the business function beneath the screen flow and extract a typed request/response boundary. Remove assumptions about display files, per-user globals, interactive inquiry replies, and caller library lists.

Define authorization, idempotency, error mapping, and commit ownership before adding the HTTP wrapper. Test repeated requests in the same server job and parallel calls where supported. Preserve old screen callers through an adapter if that reduces rollout risk.

6. How would you migrate a critical DDS file toward SQL definitions? (Advanced)

Inventory physical data, logical files, constraints, native consumers, record formats, and level-check expectations. Define the target schema and compatibility approach, then rehearse migration on a realistic copy with row counts and business reconciliations.

Plan dependency rebuilds, authorities, journaling, cutover, and rollback. Compare both native and SQL behavior, including nulls, keys, and defaults. A successful CREATE TABLE is only a small part of proving that existing business applications still behave correctly.

Practice checkpoint

  1. 1. Who should commit an order that changes stock and accounts?
    1. Each low-level update independently
    2. The printer program
    3. The queue consumer before validation
    4. The coordinator of the complete order unit
  2. 2. What makes a large import restartable?
    1. Durable run identity and coherent checkpoints
    2. Only a progress percentage on screen
    3. Only QTEMP staging
    4. Only a large buffer
  3. 3. What avoids overwriting a clerk’s intervening change?
    1. An unconditional update from the stale screen
    2. Conditional update using a version token
    3. Only a longer timeout
    4. Only a different terminal
  4. 4. What should a payment queue entry reference?
    1. Only an untracked amount
    2. Only the terminal number
    3. A durable request with a unique operation key
    4. Only the current time
  5. 5. Before exposing a screen program as an API, remove:
    1. All validation
    2. All authorization
    3. All error reporting
    4. Interactive and hidden per-session assumptions
Show answer key and explanations

1. D — The coordinator of the complete order unit The complete invariant must hold before the unit commits.

2. A — Durable run identity and coherent checkpoints A new job must be able to identify completed and remaining business work.

3. B — Conditional update using a version token Optimistic conflict detection protects changes made after the initial read.

4. C — A durable request with a unique operation key A durable request supports deduplication and crash recovery.

5. D — Interactive and hidden per-session assumptions Server requests need explicit contracts and predictable state lifetimes.

IBM documentation and further reading