How to Run a Remote Technical Interview with a Shared Code Editor

Remote technical interviews fail for boring reasons far more often than for interesting ones. The candidate cannot install the tool you asked them to use. Screen sharing turns the code into a blurry 480p stream. Someone pastes a function into the video-call chat and the indentation is destroyed. By the time the two of you are actually looking at the same code, fifteen minutes of a forty-five minute slot are gone.

This guide is written for engineers and hiring managers who conduct live coding interviews over video. It covers how to set up a shared workspace in under a minute, how to structure the session so you learn something useful, and what to pay attention to while the candidate is typing. The examples use Get My Code, but the structure applies to any real-time collaborative editor.

1. Why screen sharing is the wrong tool

Screen sharing feels like the obvious choice because it needs no setup. In practice it has three problems that specifically hurt interviews:

• Only one person can type. If you want to suggest a small change, add a test case, or fix a typo in the prompt, you have to narrate it and wait for the candidate to make the change. That interrupts their flow and consumes time.
• Resolution and latency. Compressed video makes small text hard to read, and a two-second delay between a keystroke and you seeing it makes it impossible to follow fast typists.
• Nothing survives the call. When the meeting ends the code is gone unless someone remembers to copy it. Debrief discussions then rely on memory.

A shared editor solves all three: both people edit the same document, text is rendered locally so it is always crisp, and the workspace persists at a URL you can open again during the hiring debrief.

2. Preparing the workspace before the call

Do this five minutes before the interview, not during it.

1. Create a route with a meaningful name. Instead of a random URL, type a custom one directly into the address bar, for example getmycode.in/acme-backend-interview-oct-20. Any route name that is not already taken becomes your workspace. Avoid putting the candidate's full name in the URL.
2. Paste the problem statement at the top. Write the prompt as a comment block in the language you expect the candidate to use. Include the function signature you want, one or two example inputs with expected outputs, and any constraints (time complexity, no external libraries, and so on). Candidates read far more carefully when the prompt is in the editor rather than read aloud.
3. Select the language. Use the language dropdown so syntax highlighting matches. If the candidate is free to pick, leave it on plain text and let them switch when they start.
4. Decide whether to password-protect it. If you are logged in you can mark the route private and set a password. For most interviews this is unnecessary since the URL is unguessable, but it is useful when the prompt is confidential.

When the call starts, paste the link into the video chat. The candidate clicks it, sees the prompt immediately, and can start typing. No account, no download.

3. Structuring the session

A forty-five minute slot works well with roughly this split:

• 5 minutes: context. Explain the problem verbally while they read it in the editor. Confirm they understand the examples before they write anything.
• 25 minutes: coding. This is the part the shared editor is for. Stay quiet unless they are stuck for more than a couple of minutes or heading somewhere that will waste the whole slot.
• 10 minutes: walkthrough and extension. Ask them to trace through one of the examples. Then add a new requirement directly in the editor ("now the input can contain duplicates") and watch how they adapt.
• 5 minutes: their questions.

Because you can type too, the extension step becomes much more natural. You add a test case; they make it pass. That back-and-forth is close to how real pair programming feels and tells you more than a monologue.

4. What to watch for while they type

Seeing every keystroke in real time is more information than most interviewers are used to. Some of it is signal and some is noise.

Useful signals:

• Do they write an example or a test before the implementation, or dive straight into the loop?
• When something does not work, do they re-read the prompt, add a print statement, or stare at the screen?
• Do they name things clearly on the first pass, or go back and rename once the shape of the solution is clear? Both are fine; never renaming is a mild negative.
• How do they respond when you change a requirement mid-way? Rewrite from scratch, or adapt the existing structure?

Noise you should ignore:

• Typos, backspacing, and pauses. Everyone types worse when watched.
• Forgetting the exact name of a standard library function. Tell them, and move on.
• Syntax errors they would catch instantly with a compiler. The editor highlights syntax but does not run code, so judge the logic, not the semicolons.

5. Handling common problems

The candidate's connection drops. Nothing is lost. The content is saved as they type, so when they rejoin the same URL the code is exactly where they left it. Use the gap to take notes.

They want to run the code. Be upfront that the workspace is an editor, not a sandbox. If running code matters for the role, keep a separate online compiler open and paste into it, or let the candidate run it locally and paste the output back into the shared editor as a comment.

You interview several candidates in a day. Create one route per candidate rather than wiping and reusing a single one. It costs nothing, and you will want each candidate's code intact for the debrief.

6. After the interview

Open the route again when you write your feedback. Reading the final code in a calm moment, rather than from memory, produces fairer and more specific evaluations. If other interviewers on the panel want to see it, send them the link. Once the hiring decision is made, delete the route from your routes page or let it expire; do not keep candidate code longer than you need it.

Summary

The goal of a live coding interview is to watch someone think. Every minute spent fighting tooling is a minute of that lost. A shared, zero-install editor with a prompt already waiting in it removes nearly all of that friction, lets you participate instead of just observe, and leaves you with a durable artifact for the debrief. Set it up before the call, keep the prompt in the editor, interact through the code, and ignore the typos.