5 exercises — covering the Temporal programming model, activities vs workflows, signals and queries, workflow versioning, and error handling patterns.
Structure for Temporal Workflow Engineer answers
Workflows vs Activities: workflows are deterministic, durable, and cannot perform I/O; activities do the actual work
Signals vs Queries: signals change workflow state (async); queries read workflow state (sync, no side effects)
Versioning: use GetVersion() / workflow.GetVersion() to safely change workflow logic without breaking in-flight runs
Error handling: activities retry automatically; workflows survive crashes; use compensating activities for saga pattern
0 / 5 completed
1 / 5
The interviewer asks: "Explain the difference between a Workflow and an Activity in Temporal. What rules must each follow?" Which answer is most precise?
Option B is strongest. It precisely defines the determinism requirement for workflows (same history → same commands), names the specific prohibitions (no random, no system time, no direct I/O), explains why (replay divergence), contrasts with activities (no determinism requirement, do actual I/O, retry independently), and names the most common mistake (I/O inside workflow → silent correctness errors on replay). Option A incorrectly states "both can call external services" — workflows cannot. Option C uses execution duration as the criterion — wrong; duration is not what distinguishes workflows from activities. Option D focuses on language — polyglot support is a feature but not the defining characteristic.
2 / 5
The interviewer asks: "How do you handle a change to workflow logic when there are already in-flight workflow instances?" Which answer is most operationally safe?
Option C is strongest. It names the specific API (workflow.GetVersion() / change ID), explains the mechanism (existing runs see old marker → old path; new runs → new path), describes the cleanup process (maintain both paths until old runs complete), recommends descriptive change IDs, and includes a testing method (replay test against old histories). Option A terminates in-flight workflows — data loss and business process interruption. Option B deploys without versioning — causes replay divergence for in-flight workflows, which manifests as panics or silent correctness errors. Option D claims Temporal handles this automatically — incorrect; the developer must use the versioning API.
3 / 5
The interviewer asks: "What is the difference between a Signal and a Query in Temporal? When do you use each?" Which answer is most precise?
Option B is strongest. It defines each with its key properties (signal: async, write, durable, queued; query: sync, read, no side effects, no history recording), gives concrete use cases for each, and addresses the important limitation: queries cannot reach a completed workflow. Option A is too vague. Option C states the write/read distinction but misses durability, queuing, side effects, and the completed workflow limitation. Option D uses signals for everything — queries have significantly lower overhead (no history write) for read operations; using signals for read operations pollutes the workflow history.
4 / 5
The interviewer asks: "How do you implement the Saga pattern in Temporal for a multi-step transaction?" Which answer is most complete?
Option B is strongest. It describes the compensation stack pattern (register compensations as you go, execute in reverse on failure), distinguishes retriable from non-retriable failures, and — critically — handles compensation failures (failed compensation → inconsistent state → human operator). Option A only retries the failed step — no compensation for already-completed steps, leaving the system in an inconsistent state. Option C claims Temporal has built-in saga support — incorrect; Temporal provides the durable execution primitives but the developer implements the compensation pattern. Option D uses a database transaction — this does not work across multiple services or external APIs.
5 / 5
The interviewer asks: "How do you observe and debug a Temporal workflow in production?" Which answer shows the most operational maturity?
Option C is strongest. It names five observability layers (workflow history, metrics with specific metric names, structured activity logging with correlation fields, search attributes, alerting), includes the critical warning about not logging inside workflow code (replay issue), and specifies actionable alert conditions. Option A relies on worker logs and restarting — logs alone miss the workflow history context; restarting does not fix a corrupted workflow. Option B uses print statements — does not survive in production and causes replay issues. Option D relies on Temporal Cloud — valid for managed Temporal but does not describe the observability design.