Interview Round 3

Live Coding Interview

Master the REACTO framework for thinking out loud, handling real-time problem-solving, and impressing your interviewer. These practices and templates will guide you through a live 40-minute coding session with screen sharing.

40 min
Duration
2
Problems
REACTO
Framework
100%
Communication
ROUND 3

What to Expect

Round 3 is a live, timed coding interview with screen sharing. The interviewer watches you code in real time and evaluates both your solution and your thought process.

Session Format

Duration
40 minutes
Problem Count
2 problems
Difficulty
Medium–Hard
Setup
Screen share + IDE

What the Interviewer Evaluates

1
Problem understanding: Do you ask clarifying questions? Do you restate the problem in your own words?
2
Approach clarity: Can you explain your algorithm before coding? Do you discuss trade-offs?
3
Code quality: Is your code clean, readable, properly formatted? Do you handle edge cases?
4
Testing discipline: Do you trace through examples? Do you identify and fix bugs?
5
Communication: Are you silent and heads-down? Or do you explain decisions as you code? The latter is strongly preferred.
⚠️
Critical reminder: The interviewer is not just checking if your solution works. They want to understand how you think. A working solution with poor communication is worse than a partially-working solution with excellent communication and clear thinking.

Time Allocation (40 minutes for 2 problems)

Allocate roughly 18–20 minutes per problem to account for overlap and final discussion:

Phase Duration Action
Clarify 2–3 min Ask questions, restate problem, confirm understanding with interviewer
Examples 2 min Write 2–3 test cases including edge cases
Approach 3–4 min Discuss algorithm, complexity, get buy-in from interviewer
Code 8–10 min Write clean, readable solution; narrate as you type
Test 2–3 min Trace through examples, find and fix bugs
Optimize 1–2 min Discuss further improvements (if time permits)
FRAMEWORK

The REACTO Method

REACTO is a structured approach to live coding interviews. It stands for Repeat, Examples, Approach, Code, Test, Optimize. Follow it step-by-step, and you'll impress any interviewer.

R — Repeat

Restate the problem in your own words. Clarify inputs, outputs, and constraints. Ask for confirmation.

Your opening line:
"Let me make sure I understand the problem correctly. We're given [description], and we need to return [description]. Is that right?"
1
Restate the problem as you understand it (in 1–2 sentences).
2
Clarify: "What are the input types and size? Any constraints I should know?"
3
Confirm: "Is it OK if I assume [common assumption]?" (e.g., "inputs are always valid")
4
Wait for feedback before moving on. Clarification now prevents mistakes later.

E — Examples

Write 2–3 concrete examples on the whiteboard or in comments. Include at least one edge case.

Your phrase:
"Let me work through a few examples to make sure I understand this correctly."
csharp
// Example 1: Typical case
// Input: arr = [1, 2, 3], target = 5
// Output: [0, 2] (arr[0] + arr[2] = 1 + 3 = 4... wait, that's wrong)
// Let me reconsider...
// Output should be indices where sum equals target

// Example 2: Edge case — single pair
// Input: arr = [2, 3], target = 5
// Output: [0, 1]

// Example 3: Edge case — no solution
// Input: arr = [1, 1, 1], target = 5
// Output: [] or error indicator
💡
Why examples first? Writing examples forces you to deeply understand the problem and catches misunderstandings early. It's easier to fix a wrong assumption at the examples stage than after coding 10 minutes of wrong logic.

A — Approach

Describe your algorithm before coding. Discuss time/space complexity. Get the interviewer's buy-in.

Your phrase:
"I'm thinking of using [data structure / algorithm] because [reason]. This would give us O(n) time and O(n) space. Does that sound reasonable to you?"
1
Outline your approach in plain English (not code).
2
State time complexity and why. Example: "Hash map lookup is O(1), so we do N lookups = O(N) total."
3
State space complexity.
4
Mention any trade-offs: "A sorting approach would be O(n log n) but use no extra space, whereas my approach is O(n) time with O(n) space. I prefer speed here."

C — Code

Write clean, readable code. Narrate as you go. Use meaningful variable names. Leave comments for complex logic.

Your phrase:
"Now I'll write the code. First, I'll initialize a hash map to store seen values..."
csharp
public int[] TwoSum(int[] nums, int target) {
    // Map: value → index
    var seen = new Dictionary<int, int>();

    for (int i = 0; i < nums.Length; i++) {
        int complement = target - nums[i];

        // Check if we've seen the complement
        if (seen.ContainsKey(complement)) {
            return new int[] { seen[complement], i };
        }

        // Store this number if not seen
        if (!seen.ContainsKey(nums[i])) {
            seen[nums[i]] = i;
        }
    }

    return new int[0];  // No pair found
}
💡
Narration matters: As you type, explain what you're doing. "I'm iterating through each number and checking if we've seen its complement in the map..." This shows the interviewer you're thinking clearly and aren't just copy-pasting muscle memory.

T — Test

Manually trace through your examples. Find bugs. Fix them on the spot.

Your phrase:
"Let me trace through my first example to verify this works..."
text
// Trace Example 1: nums = [2, 7, 11, 15], target = 9
// i=0: nums[0]=2, complement=9-2=7, seen={}, 7 not found
//      seen[2]=0 → seen={2→0}
// i=1: nums[1]=7, complement=9-7=2, seen={2→0}, found!
//      return [0, 1]
// Expected: [0, 1] ✓

// Trace Example 2 (edge case): nums = [3, 3], target = 6
// i=0: nums[0]=3, complement=3, seen={}, 3 not found
//      seen[3]=0 → seen={3→0}
// i=1: nums[1]=3, complement=3, seen={3→0}, found!
//      return [0, 1]
// Expected: [0, 1] ✓

O — Optimize

If time remains, discuss improvements. Could you use less space? Faster algorithm? Handle more edge cases?

Your phrase:
"The solution is O(n) time and O(n) space. We could potentially optimize space by using a sorted two-pointer approach (O(n log n) time, O(1) space), but I think the hash map is better here since we want the indices, not just a true/false answer."
⚠️
Don't optimize prematurely: Only discuss optimization if your initial solution works and you have time. A working O(n) solution beats an unfinished O(n log n) attempt.
SETUP

Environment & Tools

Be prepared with a familiar IDE and template. Seconds matter in a 40-minute interview.

Recommended IDEs for Live Interviews

IDE Pros Cons
VS Code Lightweight, quick to load, great C# support (with OmniSharp) Requires extensions, occasional IntelliSense lag
JetBrains Rider Best C# support, excellent debugging, fast refactoring Heavier, may be slower on weak machines
LINQPad Minimal setup, instant feedback, great for quick C# scripts Less IDE-like, no project structure

Pre-Interview Checklist

1
Test your IDE: Launch it, write a simple "Hello World" in C#, compile, run. Verify it's fast.
2
Have a template ready: Create a boilerplate file with a class and blank method signature. Copy-paste it at interview start to save 30 seconds.
3
Learn keyboard shortcuts: Ctrl+Shift+I (format), Ctrl+/ (comment), Ctrl+X (delete line), etc. Your speed matters.
4
Test screen sharing: Share your IDE with a friend or colleague beforehand. Verify code is readable at the shared resolution.
5
Clean desk: Minimize distractions. Close email, Slack, etc. Have only the IDE and whiteboard/paper visible.

C# Template for Quick Start

csharp
using System;
using System.Collections.Generic;
using System.Linq;

public class Solution {
    public int SolveProblem(int[] input) {
        // Your code here
        return 0;
    }

    // Test locally
    public static void Main() {
        var sol = new Solution();
        // Add test cases
    }
}
TEMPLATES

Communication Templates

Use these exact phrases and templates to guide your interviews. They sound natural while keeping you on track.

At the Start

Opening statement:
"I'll start by understanding the problem, write a few examples, discuss my approach, code it up, and then test it with the examples. Does that sound good?"

Problem Understanding

Restating:
"Let me make sure I understand. We're given [input], and we need to return [output]. The constraint is [constraint]. Is that correct?"
Clarifying:
"A couple of questions: Can the input be empty? Are there negative numbers? Is the input always sorted?"

Algorithm Discussion

Proposing approach:
"I'm thinking of using a two-pointer approach because it lets us solve this in one pass. Time complexity would be O(n) and space O(1). What do you think?"
Discussing trade-offs:
"We could also use a hash map (O(n) time, O(n) space) or sorting (O(n log n) time, O(1) space). I prefer the hash map because it's faster and this problem doesn't require us to preserve order."

While Coding

Narrating logic:
"I'll initialize a hash map to store values I've seen. Then I iterate through the array. For each element, I check if the complement is in the map. If yes, we found our pair. If not, I store this element."
Handling edge cases:
"Let me add a check for empty input here at the top."
When stuck:
"Let me think through this for a second... I'm getting stuck on [specific issue]. Can I think out loud? [Explain your reasoning]. What do you think?"

Testing & Debugging

Before testing:
"Let me trace through my first example to make sure this logic is sound."
Found a bug:
"Oh, I see the issue. I'm not handling [edge case]. Let me fix that." (Then fix it.)
All tests pass:
"Great, the solution passes all my test cases. Let me review it once more for any potential bugs... Looks good to me!"

Complexity Analysis

Explaining time:
"The time complexity is O(n) because we iterate through the array once, and each hash map lookup/insert is O(1)."
Explaining space:
"The space complexity is O(n) in the worst case, because we might store all elements in the hash map."

Finishing Up

Offering optimizations:
"If we wanted to optimize further, we could [idea], but I think this solution is solid for the given constraints. Do you have any questions about the approach?"
PRACTICE

2 Practice Problems with Full REACTO Walkthrough

Work through these problems using the REACTO framework. This is where you practice the communication patterns.

Problem A: Merge Intervals
Given a collection of intervals, merge overlapping ones and return the result.
Medium LeetCode 56
A

Problem Statement

Given an array of intervals intervals[i] = [start_i, end_i], merge all overlapping intervals and return an array of non-overlapping intervals.

Example 1
[[1,3],[2,6],[8,10],[15,18]]
Output
[[1,6],[8,10],[15,18]]

Full REACTO Walkthrough

R — Repeat

"So we have an array of intervals, and we need to merge the ones that overlap. An overlap means one interval's end is at or after another's start. We return a new array with the merged intervals. Right?"

E — Examples

text
// Example 1: Overlapping intervals
// Input: [[1,3],[2,6],[8,10],[15,18]]
// [1,3] and [2,6] overlap → merge to [1,6]
// [8,10] doesn't overlap with [1,6]
// [15,18] doesn't overlap with [8,10]
// Output: [[1,6],[8,10],[15,18]]

// Example 2: One interval contains another
// Input: [[1,4],[4,5]]
// [1,4] and [4,5] overlap at 4 → merge to [1,5]
// Output: [[1,5]]

// Example 3: Edge case — empty input
// Input: []
// Output: []

A — Approach

"I'll sort the intervals by start time. Then I'll iterate through and merge overlapping ones. Sorting gives us O(n log n), and merging is O(n), so overall O(n log n) time. Space is O(n) for the output. Does that work?"

C — Code

csharp
public int[][] Merge(int[][] intervals) {
    if (intervals.Length == 0) return new int[0][];

    // Sort by start time
    Array.Sort(intervals, (a, b) => a[0].CompareTo(b[0]));

    var result = new List<int[]>();
    int[] current = intervals[0];

    for (int i = 1; i < intervals.Length; i++) {
        if (intervals[i][0] <= current[1]) {
            // Overlapping: merge
            current[1] = Math.Max(current[1], intervals[i][1]);
        } else {
            // No overlap: add current to result, start new
            result.Add(current);
            current = intervals[i];
        }
    }

    result.Add(current);  // Don't forget the last one
    return result.ToArray();
}

T — Test

text
// Trace Example 1: [[1,3],[2,6],[8,10],[15,18]]
// After sort: [[1,3],[2,6],[8,10],[15,18]] (already sorted)
// current = [1,3]
// i=1: [2,6], 2 <= 3? yes, merge → current=[1,6]
// i=2: [8,10], 8 <= 6? no, add [1,6], current=[8,10]
// i=3: [15,18], 15 <= 10? no, add [8,10], current=[15,18]
// End: add [15,18]
// Result: [[1,6],[8,10],[15,18]] ✓

O — Optimize

"The solution is already O(n log n) due to sorting, which is optimal. We could use a different data structure (like a tree), but sorting is the simplest approach here."

Problem B: Validate Binary Search Tree
Given a binary tree, determine if it is a valid BST.
Medium LeetCode 98
B

Problem Statement

Given the root of a binary tree, determine if it is a valid binary search tree (BST). A valid BST must satisfy:

  • The left subtree of a node contains only nodes with values less than the node's value
  • The right subtree of a node contains only nodes with values greater than the node's value
  • Both left and right subtrees must also be valid BSTs
Example 1
Tree: [2,1,3] → true
Example 2
Tree: [5,1,4,null,null,3,6] → false

Full REACTO Walkthrough

R — Repeat

"We have a binary tree, and we need to check if it's a valid BST. That means each node's value must be greater than all values in its left subtree and less than all values in its right subtree. Is that right?"

E — Examples

text
// Example 1: Valid BST
//     2
//    / \
//   1   3
// 1 < 2 < 3? Yes, valid BST

// Example 2: Invalid BST
//     5
//    / \
//   1   4
//      / \
//     3   6
// Right subtree of 5 is [1,4,3,6]
// Node 3 (left child of 4) is in right subtree of 5, so must be > 5
// But 3 < 5, so it's invalid

// Example 3: Edge case — single node
// Single node is always a valid BST

A — Approach

"I'll use a recursive approach with min/max bounds. For each node, I track the valid range [min, max]. The node's value must be within this range. For the left child, the max becomes the parent's value. For the right child, the min becomes the parent's value. Time: O(n), Space: O(h) for recursion stack."

C — Code

csharp
public class TreeNode {
    public int val;
    public TreeNode left;
    public TreeNode right;
}

public bool IsValidBST(TreeNode root) {
    return IsValidBSTHelper(root, long.MinValue, long.MaxValue);
}

private bool IsValidBSTHelper(TreeNode node, long min, long max) {
    if (node == null) return true;

    // Check if current node is within bounds
    if (node.val <= min || node.val >= max) {
        return false;
    }

    // Recursively check left and right subtrees
    // Left subtree: max becomes node.val
    // Right subtree: min becomes node.val
    return IsValidBSTHelper(node.left, min, node.val) &&
           IsValidBSTHelper(node.right, node.val, max);
}

T — Test

text
// Trace Example 1: [2,1,3]
// IsValidBSTHelper(2, -∞, +∞)
//   2 in (-∞, +∞)? yes
//   Left: IsValidBSTHelper(1, -∞, 2)
//         1 in (-∞, 2)? yes
//         Left: null → true
//         Right: null → true
//         return true
//   Right: IsValidBSTHelper(3, 2, +∞)
//          3 in (2, +∞)? yes
//          Left: null → true
//          Right: null → true
//          return true
//   return true && true = true ✓

O — Optimize

"This solution is already optimal. In-order traversal could work too (track the last value and check if current is greater), but the min/max approach is clearer and equally efficient."

PITFALLS

Common Mistakes & How to Avoid Them

These are the most frequent errors candidates make in live coding interviews. Learn from them.

1. Jumping to Code Without a Plan

❌
Mistake: Interviewer asks a question, and you immediately start typing code without discussing approach first.
✓
Fix: Always follow REACTO. Spend 3–4 minutes on R, E, and A before writing a single line of code. The interviewer wants to see your thinking, not your typing speed.

2. Silence While Coding

❌
Mistake: You code for 10 minutes without saying anything, then say "Done!" The interviewer has no idea if you're thinking clearly or just randomly guessing.
✓
Fix: Narrate constantly. "I'm initializing a hash map... Now I'm looping through the array... For each element, I check if the complement exists..." This shows your reasoning and lets the interviewer catch misunderstandings early.

3. Not Testing Your Code

❌
Mistake: You finish coding, and the interviewer asks "Can you test this with an example?" You realize there's a bug you missed.
✓
Fix: After coding, immediately trace through your examples by hand. Catch bugs before the interviewer points them out. You get partial credit for finding and fixing your own bugs; you lose points for bugs the interviewer finds.

4. Ignoring Edge Cases

❌
Mistake: Your solution works for typical cases but fails on empty arrays, single elements, or negative numbers.
✓
Fix: In your examples, always include at least one edge case. Then check your code handles it. Add explicit edge-case handling if needed (e.g., "if (arr.Length == 0) return ...").

5. Incorrect Complexity Analysis

❌
Mistake: You claim O(n) time, but there's a nested loop making it O(n²).
✓
Fix: After coding, count the loops and operations carefully. Say "I have one loop through n elements, and each operation (dict lookup) is O(1), so O(n) total." Double-check before saying it confidently.

6. Overthinking or Underthinking

❌
Mistake: You implement a complex DP solution when a simple greedy approach works. Or vice versa.
✓
Fix: In the "Approach" step, propose a solution, state its complexity, and ask the interviewer if it's acceptable. If they say "That works, but can we do better?", then optimize. Otherwise, code it up.

7. Panicking When Stuck

❌
Mistake: You get stuck on a detail (e.g., how to initialize a 2D array) and freeze. Interview time evaporates.
✓
Fix: Say it out loud: "I'm stuck on [detail]. Let me think for a moment..." or "Can you remind me the syntax for [thing]?" Asking for syntax help is fine; not thinking clearly is not.
PRESENCE

Body Language & Non-Verbal Communication

Even over video, your body language and tone matter. You want to project confidence and clarity.

What to Do

1
Look at the camera: When speaking, look at the camera, not the screen. It feels more natural for the interviewer.
2
Nod and confirm: When the interviewer speaks, nod occasionally to show you're engaged. Say "Got it" or "I understand" to confirm you're following.
3
Speak clearly: Don't rush. Speak at a pace the interviewer can follow. Avoid "um," "uh," and filler words.
4
Use your hands: Gesture naturally while explaining. It makes you sound more confident and engaged.
5
Smile occasionally: A subtle smile shows you're relaxed and confident, not panicked.

What NOT to Do

❌
Don't: Slouch, avoid eye contact, type frantically, sigh heavily, or tap your fingers. These signal stress or disengagement.
❌
Don't: Go silent for long stretches. If you need to think, say "Let me think about this for a moment" instead of 30 seconds of awkward silence.
❌
Don't: Blame the problem or the interviewer. If something is unclear, say "I might be misunderstanding; can you clarify?" not "This problem is confusing."

Managing Your Energy

💡
Before the interview: Do a quick 5-minute exercise (stretch, walk, push-ups). It boosts your energy and calms nerves. Eat a light snack and drink water. Don't drink too much caffeine (jitters). Get a good night's sleep the night before.
💡
During the interview: Remember: the interviewer wants you to succeed. They're rooting for you. You've prepared. Trust yourself. If you make a mistake, stay calm and fix it. One bug doesn't fail you.
FINAL TIPS

Summary & Last Reminders

✓
DO: Follow REACTO. Spend time on planning. Explain your thinking. Test your code. Ask for help if stuck. Communicate clearly.
✗
DON'T: Rush to code. Stay silent. Skip testing. Ignore edge cases. Assume the interviewer knows what you're thinking.

The Golden Rule

A partially correct solution with excellent communication beats a fully correct solution with zero explanation. The interviewer cares about your process and reasoning, not just the final answer. If you think clearly out loud and test carefully, you'll succeed even if the first approach has minor bugs.

The Day Before

The Day Of

🚀
You've got this! Toptal interviews test your problem-solving and communication. You're prepared. The REACTO method will guide you through any problem. Trust the process, think out loud, and code cleanly. Best of luck!