Q401: Implementation Drill Building Copy Code and Copy Console Controls

What Interviewers Want To Evaluate

This drill tests whether you can implement a small but polished interaction from end to end.

Copy controls are part of the practice-ground workflow because learners repeatedly move code and output into notes, chats, docs, or bug reports.

The interviewer wants to see async handling, state ownership, accessibility, and failure behavior.

Short Interview Answer

I would build copy code and copy console as separate controls because they copy different artifacts. Each control should derive text from current state, handle empty content, call the Clipboard API, show success or failure feedback, and remain keyboard accessible. I would keep feedback local to each panel so copying code does not overwrite console feedback.

Control Placement

Place controls near their target:

copy code in the editor panel header
copy console in the console panel header
clear console beside console actions
run code near editor actions

This makes the target obvious.

Users should not wonder what a copy button will copy.

State Model

Use local copy state:

idle
copying
copied
empty
failed

For two panels, keep two states:

codeCopyState
consoleCopyState

Separate state prevents feedback collisions.

Text Derivation

Code text:

current editor value
trim only for empty check
preserve original formatting when copying

Console text:

join visible console entries
include log level if useful
include error messages
avoid copying internal object noise

Copy the thing the learner expects, not hidden implementation data.

Empty Behavior

For empty editor:

show "Nothing to copy"
do not call clipboard
keep button enabled or visibly explain state

For empty console:

show "Run code first"
or "Console is empty"

The message should guide the next action.

Clipboard Failure

Failure can happen because:

Clipboard API unavailable
browser blocks permission
page is not secure
write operation rejects

Show a short failure message:

Copy failed
Use manual selection

Do not silently fail.

Accessibility

Controls need:

button element
aria-label or visible label
visible focus style
status text near the button
polite live feedback if needed
touch-friendly size

If the button text changes to Copied, that can be enough for many cases.

For more complex feedback, use a small status region.

Feedback Reset

Reset after a short time:

1500ms
2000ms

Avoid layout shift.

The button should not grow much wider when text changes.

Stable dimensions keep the toolbar calm.

Testing Plan

Test:

copy code success
copy console success
empty editor feedback
empty console feedback
clipboard rejection
feedback resets
button keyboard activation
dark and light theme contrast

Clipboard should be mocked in tests.

That makes success and failure deterministic.

Common Mistakes

• One generic copy button with unclear target.
• Copying stale console state.
• Losing code formatting.
• Showing feedback only in a toast that disappears too fast.
• Silently failing when Clipboard API rejects.
• Making copy controls inaccessible to keyboard users.
• Letting feedback text shift the toolbar.

Final Mental Model

Copy controls are:

targeted
current
async-aware
recoverable
accessible
stable

Small tool interactions become trust signals when they work every time.