LESSON 9 · Advanced

Interview lab: design, troubleshoot and code

Plain-English notes, safe code skeletons, IBM i commands, and a checkpoint you can use before opening the deeper question bank.

After this lesson

Learning notes

Use a repeatable answer frame

For a design question, state the business goal and constraints first. Then name the object or service you would use, show the data and job flow, and explain authority, commitment, monitoring, and recovery. End with one trade-off and one test that would change your decision.

For a troubleshooting question, state the symptom you would measure, the first log or command you would inspect, and the safe mitigation. Interviewers are looking for a controlled investigation, not a list of commands.

  1. Clarify the goal and constraints
  2. Choose the smallest IBM i design that fits
  3. Name failure, authority, and consistency behavior
  4. Describe observability and recovery
  5. Give a test and a measured trade-off

Find the hidden failure window

Tricky questions often hide an assumption: a library list is stable, a queue entry is processed once, a record is unlocked, a service program interface never changes, or a batch job can simply be rerun. Challenge the assumption and offer a safer design with an operator path.

When a requirement is ambiguous, state what you would ask before coding. A short clarifying question can prevent a technically correct answer from solving the wrong problem.

A compact investigation checklist

DSPJOB JOB(*) OPTION(*JOBLOG)
DSPLIBL
DSPOBJAUT OBJ(APPDATA/*ALL) OBJTYPE(*ALL)
WRKACTJOB SBS(*ALL)
DSPJOBQ JOBQ(APPDATA/BATCHQ)

Explain code in both RPG styles

The fixed and fully free examples should express the same business behavior. In an interview, describe the input, lookup, status check, update, and test cases before showing source. Mention what you would add in production: prototypes, error handling, commitment scope, logging, and a concurrency decision.

Keep the code skeleton intentionally small. The goal is to show safe control flow and the questions you would resolve with the team, not to pretend a five-line snippet is a complete application.

Safe update skeleton

Fixed format

FProducts        UF   E             K DISK
C     productId    CHAIN     ProductRec
C                   IF        %FOUND(Products) AND newQty >= 0
C                   EVAL      quantity = newQty
C                   UPDATE    ProductRec
C                   ENDIF

Fully free

**FREE
dcl-f Products keyed usage(*update);
chain productId ProductRec;
if %found(Products) and newQty >= 0;
  quantity = newQty;
  update ProductRec;
endif;

Open the detailed question chapters

Practice checkpoint

Answer all five, then review the explanations. The interactive site stores your completed learning checkpoints in this browser.

  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 for this path