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.
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.
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) |
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.
Restate the problem in your own words. Clarify inputs, outputs, and constraints. Ask for confirmation.
Write 2–3 concrete examples on the whiteboard or in comments. Include at least one edge case.
// 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
Describe your algorithm before coding. Discuss time/space complexity. Get the interviewer's buy-in.
Write clean, readable code. Narrate as you go. Use meaningful variable names. Leave comments for complex logic.
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 }
Manually trace through your examples. Find bugs. Fix them on the spot.
// 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] ✓
If time remains, discuss improvements. Could you use less space? Faster algorithm? Handle more edge cases?
Be prepared with a familiar IDE and template. Seconds matter in a 40-minute interview.
| 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 |
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 } }
Use these exact phrases and templates to guide your interviews. They sound natural while keeping you on track.
Work through these problems using the REACTO framework. This is where you practice the communication patterns.
Given an array of intervals intervals[i] = [start_i, end_i], merge all overlapping intervals and return an array of non-overlapping intervals.
"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?"
// 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: []
"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?"
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(); }
// 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]] ✓
"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."
Given the root of a binary tree, determine if it is a valid binary search tree (BST). A valid BST must satisfy:
"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?"
// 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
"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."
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); }
// 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 ✓
"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."
These are the most frequent errors candidates make in live coding interviews. Learn from them.
Even over video, your body language and tone matter. You want to project confidence and clarity.
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.