Why does it matter whether a technical phone screen's shared editor can run code?
answer
- Two kinds of session link, not one
- The difference is what counts as proof
- No run button means you are the runtime
- Ask during setup, before the problem arrives
basics
~20 sWhether the shared editor executes code decides what counts as proof. A running editor lets you demonstrate correctness by executing a case; a plain collaborative editor means you must trace the code aloud instead, because nothing will ever be run.
solid answer
~50 sShared-editor session links come in two kinds. Some execute code and print output, and some are plain collaborative text with syntax colouring and no run button. In a running editor the screener expects execution to be part of your evidence: you are supposed to add a couple of inputs and actually run them, and code that was never executed reads as untested. In a non-running editor nothing you write will ever be executed, so the equivalent proof is a deliberate dry run — walking one small input through the code out loud, then one edge case. The practical move is to settle this in the first minute by asking whether the session runs code and whether you may add your own inputs. Guessing wrongly costs you either the run you never did or minutes spent hunting a button that does not exist.
go deeper
Ask one logistics question during setup: does this editor run code, and can I add my own inputs? Then behave accordingly — run something small early if you can.
Explain why the two editor types demand different evidence: execution output in one, a spoken line-by-line trace of a small concrete input in the other.
Adapt mid-call when the environment surprises you — a missing convenience, a slow sandbox, a link that fails — without losing the clock or the thread of the problem.
Own the tradeoff when choosing a screening tool for your own team: a running editor gives sharper correctness evidence but rewards environment familiarity, which is a bias worth naming in the debrief.
## Two kinds of session link The **shared-editor session link** a screener sends is not one product family. Broadly it is either: - **A running editor.** It executes what you type and shows output, sometimes with a small set of preloaded cases. You can print intermediate values, run one input, fix, and run again. - **A non-running editor.** Collaborative text with syntax colouring, and nothing more. It may look identical at a glance — same dark theme, same line numbers — but there is no execution behind it. Both are common, and the same company may use different ones for different rounds. You cannot reliably tell from appearance, so you ask. Something as plain as *does this session run code, and can I add my own inputs?* costs eight seconds in the setup window and changes how you spend the next half hour. ## Why the answer changes your behaviour What shifts is **what counts as proof of correctness**. ### In a running editor Execution is available, so the screener's baseline expectation is that you use it. Code that is written, declared finished, and never run is read as untested work, and that reading is fair — you had the button. Practical consequences: - **Run early, on something tiny.** Getting one trivial input to produce output within the first few minutes proves the environment works and that you know how to invoke your own code there. Discovering at minute 40 that the entry point was never being called is a bad discovery. - **Print intermediate values while developing, and clean them up before the end.** The archived session is read afterwards; a wall of leftover debug output is noise on your own artefact. - **Add your own cases.** Preloaded cases, when they exist, are usually the happy path. An empty input, a single element, and a duplicate are the three that catch most bugs in this format. - **Expect the environment to be modest.** These sandboxes are slow, have short output limits, and may lack niceties you rely on locally. Do not spend the clock fighting them; if a convenience is missing, write the three lines by hand and move on. ### In a non-running editor Nothing will ever execute, so **your voice is the runtime**. The screener judges correctness from a trace you perform: - Pick a small concrete input — four or five elements, not a general case — and walk it through the code line by line, saying what each variable holds. - Then take one edge case and do the same, quickly. - Say what you *would* have run if you could. Naming the cases you would test is itself evidence of testing instinct, and it is the closest available substitute. A silent candidate in a non-running editor gives the screener no correctness evidence at all, only a plausible-looking block of text. That is a common way to fail a screen while writing code that would have passed. ## The failure this distinction prevents The classic phone-screen loss is spending the whole clock reaching for the optimal solution and never running anything. The running-editor version is obvious: a beautiful unrun rewrite in the session at minute 52. The non-running version is subtler — a candidate polishes an approach in their head, never traces it aloud, and the screener writes *could not confirm the solution worked*. Knowing which editor you are in tells you which form of proof you owe, and therefore when you have to stop developing and start demonstrating. ## Setup hygiene either way Open the session link a few minutes before the call, not at the start of it. Check it loads, check you can type in it, and check whether a run control exists. Six minutes lost to a broken link is six minutes off the problem, and the clock does not stretch to compensate. If the link genuinely fails, say so immediately rather than fighting it silently — screeners have a fallback and would rather use it at minute two than minute twelve. ## What to ask, and when During the setup window, before the problem is given: 1. Does this session run code? 2. May I add my own inputs, or should I only use what is here? 3. Is there anything about the environment I should know — missing conveniences, output limits? All three are logistics questions, not hints, so they cost nothing. Asking them after you have already written thirty lines costs a great deal more.
- If the session link runs code, when in the call should you run it for the first time?Within the first few minutes, on something trivial — a hard-coded input producing any output at all. That confirms the environment works and that your entry point is actually invoked. Discovering at minute 40 that nothing was ever being called is a self-inflicted failure, and it is the point at which recovery time no longer exists.
- Should you clean up debug printing before the call ends?Yes, if there is a minute to spare. The session link is archived and read afterwards by people who were not on the call, so its final state is your artefact. Leftover debug output is not fatal, but a tidy final version with the cases you ran still visible reads as deliberate rather than abandoned.
- What if the shared-editor session link will not load when the call starts?Say so within the first minute rather than fighting it quietly. Screeners keep a fallback — a different link, a plain document, occasionally screen sharing — and would far rather switch at minute two than at minute twelve. Silent troubleshooting burns the only resource the stage is short of.
saying these in an interview costs you the question
- Assuming every shared editor executes code
- Writing a full solution and never running it when running was possible
- Declaring code correct in a non-running editor without tracing any input
- Burning several minutes fighting a missing convenience in the sandbox
- Opening the session link for the first time when the call begins