Q418: Implementation Drill TypeScript Feedback Separation

What Interviewers Want To Evaluate

This drill tests whether you can separate compile-time feedback from runtime output in a TypeScript practice tool.

TypeScript learners need to know whether a problem came from the compiler or from their JavaScript behavior.

If all feedback is dumped into one console, the learning signal becomes noisy.

Short Interview Answer

I would give the TypeScript practice page a separate feedback area for transpile or type-related messages while keeping runtime logs in the console.

The code path should classify failures as compile or runtime failures.

Compile failures should stop execution and explain what needs fixing.

Runtime failures should appear in the console because the code already passed the TypeScript step.

Why Separation Matters

TypeScript introduces two different questions:

Is the code valid enough to compile?
Does the resulting JavaScript behave correctly?

Those are related, but not the same.

A learner should not confuse a type error with a runtime exception.

The UI should teach that distinction.

Feedback Zones

Use:

editor panel
TypeScript feedback panel
runtime console panel

The TypeScript feedback panel can start small.

It might show:

ready
transpiling
compile failed
compiled successfully

The runtime console should stay focused on console.log, console.error, thrown errors, and timeout messages.

State Model

Model feedback explicitly:

type TypeScriptFeedback =
  | { status: "idle" }
  | { status: "transpiling" }
  | { status: "success"; message: string }
  | { status: "error"; message: string };

This prevents vague booleans from spreading through the component.

It also makes rendering and copy behavior easier later.

Execution Flow

For TypeScript:

set feedback to transpiling
send source to transpile endpoint
if transpile fails, show feedback error and stop
if transpile succeeds, show success and run JavaScript
send runtime logs to console

For JavaScript:

skip TypeScript feedback
run source directly
send runtime logs to console

This keeps the two practice pages consistent without pretending they are identical.

UI Copy

Feedback text should be practical.

Good:

TypeScript could not compile this example.
Fix the type error before running the JavaScript output.

Weak:

Something went wrong.

Learners need classification.

Classification lowers debugging time.

Copy Support

A later version may let users copy:

source code
TypeScript feedback
runtime console

Keep these targets separate.

Someone asking for help with a type error should not need to paste unrelated runtime logs.

Someone debugging output should not need compiler details every time.

Testing Plan

Verify:

valid TypeScript runs
invalid TypeScript stops before runtime
feedback is cleared or updated on next run
runtime errors still appear in console
JavaScript page has no empty TypeScript panel
copy controls stay clear
dark and light themes keep status readable

The first implementation can be manual.

The state shape should make automated checks straightforward later.

Common Mistakes

• Mixing compiler errors with runtime logs.
• Running stale JavaScript after a compile failure.
• Showing success when only transpilation succeeded.
• Forgetting JavaScript and TypeScript have different feedback needs.
• Making copy targets unclear.
• Using one generic error state for every failure.

Final Mental Model

TypeScript practice feedback should separate:

compile step
runtime step
console output
learning guidance
copyable artifacts

That separation makes the practice ground easier to trust.