How to Interview a Remote Developer

Question 1: Walk me through a project you built from scratch. What were the first three technical decisions you made?

What it reveals: Whether the developer thinks architecturally from the start or just starts coding. The first three decisions reveal how they approach scope and structure before writing a line.

Strong answer looks like: They describe specific, considered decisions: database schema approach, authentication pattern, API design. They explain the reasoning behind each, not just what they chose.

Watch out if: They describe features built rather than decisions made. They cannot remember early technical choices. This signals execution without ownership.

Question 2: Tell me about a time your code caused a bug in production. What happened and what did you do?

What it reveals: Accountability and how they handle failure. Every experienced developer has caused a production bug. A developer who says they have not is either inexperienced or not being honest.

Strong answer looks like: They describe the bug clearly, own their part in it without deflecting, explain what they fixed, and describe what they changed in their process to prevent recurrence.

Watch out if: They blame an unclear brief, another team member, or the framework. Or they have no example at all. Both are signals about how they will behave when something goes wrong on your project.

Question 3: I need a feature that lets users export a report as a PDF. What questions do you ask before you start writing code?

What it reveals: Whether they gather requirements before building or build and discover. The questions they ask reveal whether they think about the full scope or just the immediate implementation.

Strong answer looks like: They ask about report content, file size expectations, whether it is server-side or client-side, authentication requirements for the download, styling needs, and whether it needs to be async.

Watch out if: They jump straight into the implementation approach without asking any clarifying questions. This is the pattern that produces rework. They are solving a problem they have not fully defined.

Question 4: You are three days into a sprint and you realise a task is going to take twice as long as you estimated. What do you do?

What it reveals: Communication patterns under pressure. This is the scenario that separates developers who manage expectations early from those who push and miss the deadline.

Strong answer looks like: They say they flag it immediately, explain what changed, propose options (descope, extend, split the task), and let the client or tech lead make the call with full information.

Watch out if: They say they work harder to hit the deadline. Or they wait until the deadline is missed to raise it. Either answer tells you something important about how delivery pressure is handled.

Question 5: Show me a piece of code you wrote that you are not happy with. What would you change now?

What it reveals: Self-awareness and whether they hold themselves to a standard. Developers who cannot identify imperfect code in their own work either do not review it critically or are not comfortable showing weakness.

Strong answer looks like: They identify something specific, explain why it is suboptimal (performance, readability, maintainability), and describe what a better approach would look like. The willingness to criticise their own work is the signal.

Watch out if: They say all their code is clean. Or they pick a trivial example like a variable name. Genuine self-awareness produces genuine examples, not curated ones.

Question 6: How do you handle a technical disagreement with a colleague or a client about the right approach?

What it reveals: Whether they can advocate for a position while staying collaborative. This matters in remote engagements where disagreements happen in text and without the social cues of a shared office.

Strong answer looks like: They describe a specific example where they made their case with reasoning, listened to the counterargument, and either changed their view with new information or found a compromise. They do not need to win.

Watch out if: They say they always defer to the client. Or they say they always stand by their technical judgment. Neither answer reflects how good collaborative development actually works.

Question 7: You join a project with an existing codebase. There is a part of it you think is poorly structured. What do you do?

What it reveals: Pragmatism versus perfectionism. A developer who immediately rewrites everything they disagree with is expensive. A developer who documents, raises the issue, and proposes a refactor plan is valuable.

Strong answer looks like: They say they understand the existing structure first, raise the issue with the tech lead with a specific example and a proposed improvement, and work within the current approach until there is a plan to change it.

Watch out if: They say they refactor as they go without flagging it. Or they say they leave it and just work around it. Neither pattern produces a clean codebase over time.

Question 8: What does your typical approach look like for a feature that has no clear requirements yet?

What it reveals: Whether they can operate with ambiguity or need full specification to start. Remote work produces ambiguous situations. A developer who stalls without complete requirements creates blockers.

Strong answer looks like: They describe identifying the core of the feature that is clear, building that first, documenting the assumptions they are making, and flagging the unclear parts with specific questions rather than waiting for everything to be defined.

Watch out if: They say they wait until requirements are fully defined before starting. In a remote context with timezone differences, this approach makes ambiguity a blocker rather than a conversation.

The question:

Tell me about a project where the scope changed significantly after you started. What happened and how did you handle it?

Layer 1: Take-home task

(60 to 90 minutes)

Give the developer a small, realistic task from your actual codebase or a simplified version of it. Not a Leetcode puzzle. A real problem you have solved or one that is coming. The task should be completable in 60 to 90 minutes at the seniority level you are hiring. Review the output for code structure, naming conventions, error handling, and whether they wrote any tests.

Layer 2: Code review session

(30 minutes)

Share a piece of code with intentional flaws: a missing index, an N+1 query, a function that does too many things, an insecure input handling. Ask the developer to review it as if it were a PR on their team. This tests code quality judgment without requiring them to write under pressure.

Layer 3: Architecture conversation

(20 minutes)

Describe a real system design challenge you face or have faced. Ask them how they would approach it. You are not looking for the right answer. You are listening for how they think through trade-offs, what questions they ask before proposing a solution, and whether they acknowledge uncertainty rather than projecting false confidence.

Requirement handling

How thoroughly did they gather context before solving a problem? Did they ask the right questions in Questions 3 and 8?

Accountability

Did they own mistakes and handle pressure scenarios clearly? Questions 2 and 4 are the primary signals here.

Code judgment

Did their take-home task and code review session show production-grade thinking, not just working code?

Communication under ambiguity

How do they handle incomplete information? Do they flag it constructively or does it become a blocker?

Collaboration pattern

Do they advocate for their view while remaining open to being wrong? Question 6 is the clearest test.