Q422: Implementation Drill Run Status and Recovery States

What Interviewers Want To Evaluate

This drill tests whether you can model the lifecycle of a browser code run clearly.

A practice console is not only an output box.

It has states:

idle
running
completed
failed before execution
runtime error
timed out
cleared

Senior frontend implementation turns these states into useful UI instead of vague loading text.

Short Interview Answer

I would give each run a visible identity and render system lines for run state.

When the learner starts execution, the console should show that a specific run started.

When it completes, fails, times out, or gets cleared, the console should make that state visible.

This makes output easier to reason about and prepares the UI for future stop, retry, and saved-run features.

Why Run Identity Matters

Without run identity, users can wonder:

Is this output from the latest run?
Did my new code execute?
Did the console clear old output?
Did TypeScript fail before runtime?
Did a timeout come from this attempt?

A simple run number solves many of those doubts.

It does not need to be a database id.

It only needs to distinguish attempts inside the current session.

System Lines

Useful system lines:

Run #3 started.
Run #3 completed.
Run #3 stopped before execution.
Execution timed out after 3 seconds.
Console cleared.

These lines reduce ambiguity.

They also become useful when copied with console output.

If a learner asks for help, the helper can see what happened.

State Boundaries

Separate:

compile failure
runtime failure
timeout
empty output
manual clear

Compile failure means TypeScript did not produce runnable JavaScript.

Runtime failure means the JavaScript ran and threw.

Timeout means the worker did not finish in time.

Empty output means execution succeeded but no logs were captured.

Clear means the user intentionally reset the panel.

These should not all share the same message.

Recovery Design

Every failure state should have a recovery path.

Examples:

compile failure -> edit code and run again
runtime error -> inspect stack and fix logic
timeout -> reduce loop or add a base case
large output -> reduce logging
empty output -> add console.log or inspect return behavior

The UI does not need long instructions.

But the message should point in the right direction.

Button Behavior

During a run:

disable run button
keep copy output available if previous output remains
keep clear available if safe
show running label
avoid duplicate simultaneous runs

For the first version, disabling the run button is enough.

Later, a stop button can terminate the active worker explicitly.

Accessibility

Console output should use a live region.

System lines should not rely only on color.

The text itself should explain the state.

This helps:

screen reader users
keyboard-only users
users reviewing copied logs
users in dark mode

Clear text is more robust than styling alone.

Testing Plan

Verify:

run number increments
started line appears
completed line appears
empty output is explained
runtime error is still an error line
TypeScript compile failure is classified before runtime
clear console shows cleared state
run button disabled state has readable contrast

The first slice can use manual checks.

Automated coverage can target the state reducer later if the component grows.

Common Mistakes

• Showing Running... forever after a failure.
• Reusing old output without a new run marker.
• Treating TypeScript compile failure as runtime output.
• Making disabled buttons unreadable in dark mode.
• Clearing output without telling the user it was cleared.
• Allowing multiple overlapping runs accidentally.

Final Mental Model

Run status should answer:

what ran
what happened
whether output is current
how to recover

That is the difference between a text box and a useful practice console.