This guide covers what actually happens in a 45-minute Google algorithm interview. It’s not about being smart—it’s about communicating clearly, executing under pressure, and showing your thinking process.

What Google Interviewers Actually Evaluate

Google uses a structured rubric. Interviewers are trained to assess:

1. Problem Decomposition & Communication (25-30% weight)

Interviewers are listening for your thinking process, not just your final answer.

What they’re assessing:

  • Do you understand the problem? (Ask clarifying questions)

  • Can you break it into sub-problems? (Explicit planning, not jumping to code)

  • Do you communicate your approach before coding?

  • Are you aware of trade-offs? (Time vs. space, accuracy vs. speed)

Red flags (what kills this score):

  • Jumping to code immediately without discussion

  • Going silent (hard for interviewer to follow your thinking)

  • Proposing a solution without explaining why it works

  • Not asking clarifying questions (assumes a problem is well-defined)

Green flags (what makes this score):

  • "Let me understand the problem first—are the inputs always positive? Can the array be empty?"

  • "I think the brute force would be O(n²) because I’d check every pair. But I think we can do better by…​"

  • "Let me think about edge cases: empty input, single element, duplicates…​"

  • "I’m going to use a hash map here because we need O(1) lookups"


2. Code Quality & Execution (30-35% weight)

Your code must run. It must be clear. It must handle edge cases.

What they’re assessing:

  • Does the code actually solve the problem (or close to it)?

  • Is it readable? (Clear variable names, logical structure)

  • Do you test it? (Trace through examples, check edge cases)

  • Do you handle off-by-one errors, boundary conditions?

Red flags:

  • Code that doesn’t compile/parse (syntax errors even in pseudocode)

  • Vague variable names (i, j, temp, x with no context)

  • No testing—you write code and don’t check it works

  • Forgetting edge cases (empty arrays, null inputs, single elements)

Green flags:

  • Clear variable names: result, leftPointer, seen (not x, p, s)

  • Explicit helper functions for clarity (even if slightly longer)

  • Testing with at least one example before declaring "done"

  • Mentioning edge cases: "This handles empty arrays, duplicates, and negative numbers"


3. Testing & Verification (10-15% weight)

You can’t run code in a Google Doc. But you can trace through it.

What they’re assessing:

  • Do you test your solution with examples?

  • Can you trace through code mentally and spot bugs?

  • Do you verify edge cases?

Red flags:

  • Writing code and saying "I think it works" without testing

  • Missing obvious bugs when tracing through examples

  • Only testing happy path (no edge cases)

Green flags:

  • "Let me trace through with the example [1, 2, 3]…​"

  • "What if the array is empty? My code would…​ yes, handles it"

  • "What if there are duplicates? …​ Yes, the hash map treats them independently"


4. Optimization & Awareness (15-20% weight)

If you solve it with brute force, acknowledge the limits and propose improvements.

What they’re assessing:

  • Do you recognize a better approach exists?

  • Can you articulate why your solution isn’t optimal?

  • Can you suggest how to optimize (even if you don’t have time to code it)?

Red flags:

  • Ignoring obvious optimizations (e.g., O(n²) when O(n) exists)

  • Not discussing trade-offs

  • Shrugging if stuck ("I don’t know how to optimize this")

Green flags:

  • "This is O(n²) because we check every pair. But we could use a hash map to bring it to O(n)…​"

  • "I’m using O(n) extra space for the hash map. We could optimize to O(1) space with two pointers, but the code is trickier…​"

  • "If I had more time, I’d consider dynamic programming for this, but let me solve the simpler version first"


Interview Flow: Structure Your 45 Minutes

You have 45 minutes. Here’s how to allocate time:

Minutes 0-3:    Clarify the problem (2-3 min)
Minutes 3-8:    Discuss & plan approach (5 min)
Minutes 8-33:   Code & trace through (25 min)
Minutes 33-38:  Test with examples (5 min)
Minutes 38-45:  Optimize & discuss (7 min)

Adjust based on problem difficulty. A simple problem might take 15 min to code; a hard one might take 30. The structure is a guide, not a rule.

Minutes 0-3: Clarify

What to say:

"Let me make sure I understand the problem:
- We have an array of integers
- We need to find two numbers that sum to a target
- Can there be duplicates in the array?
- Should I return indices or the values themselves?
- What if no solution exists?"

Why this matters:

  • Shows you’re thinking, not assuming

  • Prevents wasting 20 minutes solving the wrong problem

  • Some problems are ambiguous; clarifying saves time

  • Interviewers may give hints based on your questions

Time to use: 2-3 minutes max. If the problem is clear, move on.


Minutes 3-8: Plan Your Approach

Don’t code yet. Discuss.

What to say:

"I think I'll use a hash map approach:
1. Iterate through the array
2. For each number, check if (target - number) is in the map
3. If yes, I found the pair; if no, add the current number to the map
4. Time: O(n), Space: O(n)

The brute force would be nested loops O(n²), but the hash map is better."

Why this matters:

  • Interviewer knows your plan before you code (easier to follow)

  • If your plan is wrong, they can correct you before you code

  • Shows algorithmic thinking, not just coding ability

  • Saves time: you won’t code yourself into a corner

Time to use: 5 minutes. High-level, not pseudocode.


Minutes 8-33: Code

Now write real code in the Google Doc.

Pace:

  • First 10 min: Structure the function, variable initialization

  • Next 10 min: Core loop/logic

  • Last 5 min: Handle edge cases, clean up

What to do:

  • Write slowly and clearly (no autocomplete; handwriting is slow but forces clarity)

  • Use consistent indentation (spaces, not tabs)

  • Name variables clearly

  • Explain as you code: "I’m using a Map called seen to store numbers I’ve seen"

  • Ask out loud before each step: "Should I add error handling here?"

Pace guide (rough):

  • 5 problems/week = 1 problem per day = 25 min coding per day ✓

  • During interviews, if you’re past 25 min and not close to done, simplify (don’t over-engineer)


Minutes 33-38: Test

Trace through your code with examples.

What to say:

"Let me test with the example [2, 7, 11, 15], target = 9:
- i=0, num=2, target-num=7, not in seen, add 2 to seen: seen={2}
- i=1, num=7, target-num=2, IS in seen, return [0, 1]
Great, it works.

What about edge cases?
- Empty array: The loop doesn't run, we return undefined (or -1, depending on spec)
- Array with one element: Same, loop runs once, no pair found
- Duplicates: If we had [2, 2] with target 4, we'd find it correctly"

Why this matters:

  • Catches bugs before the interviewer does

  • Shows you can verify your own code (big plus)

  • Demonstrates understanding (you can predict output)

Time to use: 5 minutes. Test 2-3 examples and 2-3 edge cases.


Minutes 38-45: Optimize & Discuss

If you solved it early, optimize. If you’re still coding, this is catch-up time.

What to say (if time allows):

"The current solution is O(n) time, O(n) space.

For two-pointer approach, we could:
1. Sort the array: O(n log n)
2. Use left/right pointers to find the pair: O(n)
3. Total: O(n log n) time, O(1) space (in-place)

The hash map is better in practice (O(n) vs O(n log n)), but two-pointers uses constant space. Trade-offs."

If you’re stuck or haven’t finished:

  • Don’t panic—many candidates don’t finish

  • Ask for a hint: "I’ve hit a wall with testing. Could you give me a hint?"

  • Or propose simplifying: "Let me code the happy path first, then handle edge cases"

Finishing isn’t always required. Clear communication, good code, and showing your process often scores higher than rushing to a finish line with buggy code.


What to Say Out Loud: The Phrases That Matter

Interviewers can’t read your mind. You must narrate your thinking. Here are the exact phrases that make a difference:

Stating the Algorithm

Instead of: "I’m going to use a hash map" Say: "I’ll use a hash map here because we need O(1) lookup to check if we’ve seen a number before. That brings the time complexity from O(n²) to O(n)."

The why is more important than the what. Anyone can use a hash map. You’re showing that you know why.


Discussing Trade-Offs

Instead of: "This might not be optimal" Say: "The current solution is O(n) time and O(n) space. We could optimize space to O(1) using two pointers instead, but that requires sorting first, making it O(n log n) time. For most cases, O(n) time is better than O(n log n), so I’ll stick with the hash map approach."


Addressing Edge Cases

Instead of: "It probably handles edge cases" Say: "Let me think about edge cases: If the array is empty, the loop doesn’t run and we return undefined, which is correct. If the array has one element, same behavior. If there are duplicates, the hash map treats each instance separately, so we’re fine."


Acknowledging Complexity

Instead of: Silence while you code Say: "The nested loop here is O(n), and the inner operation is O(1), so overall O(n). Let me trace through to make sure…​"


Clarifying Before Coding

Instead of: Asking no questions Say: "I want to make sure: Does the problem want me to handle negative numbers? What if there are no solutions? Should I return indices or values?"


Recovery from Mistakes

Instead of: Erasing and starting over silently Say: "Actually, I think there’s an off-by-one error here. Let me trace through…​ yes, I should start from index 1, not 0, because…​"


When Stuck

Instead of: Staring at the problem Say: "I’m not immediately seeing a better approach than brute force. What data structure would help me optimize the slow part? …​ Oh, a hash map for lookups—that’s what I was missing."


Common Mistakes to Avoid

Mistake 1: Jumping Into Code Immediately

What happens: You start typing code before discussing approach. Midway, you realize your approach is wrong. Wasted 10 minutes.

Fix: Spend 5 minutes discussing. Even if your approach is wrong, catching it early saves time.


Mistake 2: Going Silent

What happens: You’re thinking, but not talking. Interviewer has no idea if you’re stuck, debugging, or just quiet. Hard to give hints.

Fix: Narrate everything. "I’m thinking about how to optimize this step…​" Even wrong thinking is better than silence.


Mistake 3: Not Testing Code

What happens: You write code, declare victory, and it’s actually wrong. Interviewer has to read your code to spot the bug. Bad look.

Fix: Always trace through with at least one example. Takes 2 minutes, catches most bugs.


Mistake 4: Writing Pseudocode Instead of Real Code

What happens: You write for each num in array: instead of actual JavaScript. The interviewer accepts it as a shorthand, but it signals you’re less confident in real syntax.

Fix: Write real JavaScript, even if it’s slower. Use consistent patterns:

// Good
for (let i = 0; i < arr.length; i++) {
  const current = arr[i];
  if (map.has(target - current)) {
    return [map.get(target - current), i];
  }
  map.set(current, i);
}

// Less good (pseudocode)
for each num in arr:
  if seen has (target - num):
    return pair
  seen[num] = true

Mistake 5: Using Libraries That Don’t Exist

What happens: You write const result = _.sortBy(arr) and the interviewer says "Let’s assume underscore isn’t available." Now you have to rewrite.

Fix: Stick to built-in JavaScript:

  • Array.prototype.sort, push, pop, slice, splice, filter, map, reduce

  • Map, Set (ES6 standard)

  • Object for simple maps (caveat: only string keys)

  • lodash, ramda, custom libraries


Mistake 6: Not Asking Clarifying Questions

What happens: You solve the problem as written, but the interviewer meant something slightly different. Wrong solution.

Fix: Ask 2-3 clarifying questions: - What type of inputs? (always positive? can be zero? null?) - Edge cases: (empty input? single element?) - Return type: (indices, values, count?) - Constraints: (time limit? space limit?)


Mistake 7: Over-Engineering

What happens: You write validation, error handling, and comments. Very professional. Also took 35 minutes to code.

Fix: Simple code in 20 minutes > professional code in 35 minutes. Solve the problem first, polish if time remains.


Mistake 8: Forgetting Variable Scope (JavaScript-Specific)

What happens: You use a variable outside its scope. Code doesn’t parse.

Fix: In a Google Doc, indentation and scope matter. Be explicit:

// Bad: missing declaration
function twoSum(arr, target) {
  for (let i = 0; i < arr.length; i++) {
    // oops, what's 'result'? declared where?
    if (result[0] === target) { }
  }
}

// Good: declared at top
function twoSum(arr, target) {
  const seen = new Map();
  for (let i = 0; i < arr.length; i++) {
    // ... use seen
  }
  return -1; // or throw error
}

Google Doc Coding Tips: The Reality

You’ll code in a Google Doc with:

  • No syntax highlighting (text is all one color)

  • No autocomplete (you type every character)

  • No error checking (no red squigglies)

  • No ability to run/test code (you trace manually)

This is awkward. Prepare for it.

Practical Tips

1. Use Consistent Indentation

In a Google Doc without syntax highlighting, indentation is your only visual cue for code structure.

// Use 2 spaces, consistently. Helps readability in plain text
function solve(arr) {
  const map = new Map();
  for (let i = 0; i < arr.length; i++) {
    const complement = target - arr[i];
    if (map.has(complement)) {
      return [map.get(complement), i];
    }
    map.set(arr[i], i);
  }
  return -1;
}

2. Name Variables Clearly

Without types, names are everything.

  • leftPointer, rightPointer (Two pointers? Clear what they are)

  • seen, visited (A set of things we’ve encountered)

  • maxSum, currentSum (The purpose is obvious)

  • l, r (Without context, confusing)

  • i, j, k (Classic, but generic outside loops)


3. Use Helper Functions

If part of your solution is complex, extract it. Makes code clearer:

// Without helper: dense
function solve(graph) {
  const visited = new Set();
  const result = [];
  function dfs(node) {
    if (visited.has(node)) return;
    visited.add(node);
    result.push(node);
    for (const neighbor of graph[node]) {
      dfs(neighbor);
    }
  }
  for (const node in graph) {
    dfs(node);
  }
  return result;
}

// With helper: Clearer structure
function dfs(node, graph, visited, result) {
  if (visited.has(node)) return;
  visited.add(node);
  result.push(node);
  for (const neighbor of graph[node]) {
    dfs(neighbor, graph, visited, result);
  }
}

function solve(graph) {
  const visited = new Set();
  const result = [];
  for (const node in graph) {
    dfs(node, graph, visited, result);
  }
  return result;
}

4. Comment the Non-Obvious

Don’t comment every line. Comment the why, not the what.

// Bad: obvious comments
const arr = [1, 2, 3];
const len = arr.length; // Get the length

// Good: explains intent
const arr = [1, 2, 3];
const len = arr.length; // Exclude last element in loop (sliding window)

// Good: explains algorithm choice
const seen = new Map(); // Hash map for O(1) lookup (vs. set which loses indices)

5. Trace Through with Test Cases

Since you can’t run code, you must mentally execute it. Do this out loud:

Let me trace through with arr = [2, 7, 11, 15], target = 9:

i=0, arr[0]=2, target-2=7, seen={}, no match, seen.set(2, 0) → seen={2→0}
i=1, arr[1]=7, target-7=2, seen has 2! Return [0, 1]

Correct!

What to Do If You’re Stuck

You’re 20 minutes in. You have no idea how to proceed. What do you do?

Getting stuck is normal. How you handle it matters more than not getting stuck.

Option 1: Ask for a Hint

What to say:

"I'm stuck on how to optimize this beyond brute force. Could you give me a hint?
The slow part is checking every pair... is there a data structure that would help?"

Why this works: - Shows you’re not avoiding the problem - Gives interviewer a chance to help (which is their job in interviews) - Interviews are collaborative, not adversarial - Getting a hint and solving is often fine; solving alone without help is not always required


Option 2: Simplify the Problem

What to say:

"Let me code the happy path first: assume the array is sorted and has a solution.
Then I'll add complexity for unsorted arrays and edge cases."

Why this works: - Shows you can break problems into steps - Gets something on the board (better than stuck silence) - Often, the simple version reveals the pattern for the hard version


Option 3: Think About Data Structures

What to say:

"The slow part is finding duplicates. What data structure makes 'have I seen this before?'
O(1)? ... A set or hash map. Let me try that approach."

Why this works: - Forces algorithmic thinking - Often unsticks you (many problems have a data structure at their core) - Shows problem-solving process


Option 4: Brute Force First

What to say:

"Let me code the brute force solution: nested loops, O(n²). It's not optimal,
but it works. Then I can optimize if time allows."

Why this works: - Guarantees a working solution - Interviewer sees your baseline - Optimization (if time) is a bonus - Often, brute force → optimal is just removing redundancy


Option 5: Ask a Clarifying Question

What to say:

"I'm not sure what you mean by 'optimize for space'. Do you mean I should avoid
extra data structures, or just minimize overall memory usage?"

Why this works: - Sometimes your misunderstanding is the blocker - Shows you’re thinking about the problem, not giving up - Clarification might reveal the insight


Language-Specific: JavaScript Gotchas

You’ve chosen JavaScript. Here are things that surprise strong backend developers.

Map vs. Object

Object: Simple maps with string keys

const map = {};
map['key'] = 'value';
if ('key' in map) { }

// Problem: All keys are converted to strings
const map = {};
map[1] = 'one';
map['1'] = 'two'; // Overwrites! 1 and '1' are the same key

Map: Proper key-value storage

const map = new Map();
map.set(1, 'one');
map.set('1', 'two'); // Different keys! 1 and '1' are distinct

if (map.has(1)) { } // O(1) lookup
const value = map.get(1);
map.set(key, value);
map.delete(key);
/////// Iterate
for (const [key, value] of map) { }

In interviews, unless the problem explicitly uses strings as keys, default to Map. It’s clearer and safer.


Set for Uniqueness

When you need to track "have I seen this?"

const seen = new Set();
seen.add(value);
if (seen.has(value)) { }
seen.delete(value);

// Iterate
for (const value of seen) { }

Array Methods Matter

Common ones you’ll use:

// Access
arr[0]; // O(1)
arr.length;

// Mutate
arr.push(value);        // O(1) amortized, add to end
arr.pop();              // O(1), remove from end
arr.unshift(value);     // O(n), add to start (shifts everything)
arr.shift();            // O(n), remove from start

// Copy/slice
const copy = arr.slice(); // Shallow copy of entire array
const part = arr.slice(2, 5); // Copy elements [2, 3, 4]
arr.splice(2, 3, 'new'); // Mutate: remove 3 elements at index 2, insert 'new'

// Search/filter
arr.indexOf(value);     // O(n) linear search
arr.includes(value);    // O(n) linear search
arr.filter(fn);         // O(n) returns new array
arr.map(fn);            // O(n) returns new array
arr.reduce(fn, init);   // O(n) accumulate

// Sort (mutates)
arr.sort((a, b) => a - b); // O(n log n) comparison sort
arr.reverse(); // O(n) mutate in place

shift() and unshift() are O(n) because they shift every element. For a queue, use an array with push() and shift(), but be aware of the cost. For better queue performance, consider a custom implementation.


Strings Are Immutable

You can’t modify a character in place:

const str = "hello";
str[0] = 'H'; // Doesn't work! Strings are immutable

// Solution: convert to array, modify, convert back
const arr = str.split('');
arr[0] = 'H';
const result = arr.join('');

Closures for Memoization

Dynamic programming often uses closures for memoization:

function createCounter() {
  const memo = {}; // Closure: memo persists between calls

  function fib(n) {
    if (n in memo) return memo[n]; // Check memo
    if (n <= 1) return n;
    memo[n] = fib(n - 1) + fib(n - 2); // Store result
    return memo[n];
  }

  return fib; // Return the function that closes over memo
}

const fib = createCounter();
console.log(fib(10)); // Uses memoization

typeof vs. instanceof

Know the difference (edge cases matter in interviews):

typeof 5;          // "number"
typeof "hello";    // "string"
typeof {};         // "object" (beware: arrays, null, objects all "object")
typeof [];         // "object"
typeof null;       // "object" (historical bug!)

Array.isArray([]);  // true
Array.isArray({});  // false

// For null checks
if (value === null) { }
if (value == null) { } // Checks null OR undefined

Checklist: Before You Start Your Interview

Preparation (day before):

  • Solve 2-3 problems under timed conditions (45 min in Google Doc, no IDE)

  • Write code in Google Doc specifically (no IDE autocomplete)

  • Sleep 7+ hours (sleep consolidates memory)

Day of:

  • Eat something; don’t interview hungry

  • Use a quiet room, good internet

  • Close other tabs/notifications (interview requires focus)

  • Have water nearby

Interview start (first minute):

  • Test your mic/video (if video interview)

  • Take 30 seconds to breathe

  • Read the problem carefully (twice)

  • Ask clarifying questions before jumping to code

During coding:

  • Narrate your approach before writing code

  • Use clear variable names

  • Trace through with at least one example

  • Check edge cases (empty, single element, duplicates)

  • If stuck, ask for hints (it’s okay!)

After first solution (if time):

  • Discuss optimizations (even if you don’t code them)

  • Ask "Are you looking for anything else?" (give interviewer a chance to ask follow-ups)


Rubric Scoring: What Interviewers Record

Google uses a standardized rubric. Your performance falls into one of 4 buckets:

Score What It Means Examples

Strong Hire

You solved the problem cleanly and communicated well

Correct solution, good code, clear explanation, optimized

Hire

You solved it (mostly), showed good thinking, minor issues

Off-by-one error but caught it; understood approach; could optimize

Maybe/Borderline

You struggled but showed some promise

Partially correct; needed hints; or correct but code quality poor

No Hire

You didn’t demonstrate competency

Didn’t understand problem; incomplete solution; silent/non-communicative

You don’t need "Strong Hire" on both interviews. "Hire" on both is typically enough to move forward. The bar is: Can you solve a medium problem and communicate your thinking?


Post-Interview: What Happened?

After both interviews (assuming you don’t get feedback immediately):

If you felt okay: - Feedback usually comes in 3-5 business days - Don’t obsess over it in the meantime

If you felt bad: - One bad interview doesn’t disqualify you (interviewers expect some variance) - Even if that interview was a "No Hire", the other one can carry you

If you move forward: - Next round is usually system design (different skills; see your system design guide)

If you don’t move forward: - Ask for feedback if available (it’s worth knowing what to improve for next time) - It’s not personal; algorithm interviews are noisy


Final Reminders

1. Communication > Perfection

A semi-correct solution explained well beats a correct solution explained poorly.

2. The Interviewer Wants You to Succeed

They’re not trying to trick you. They want to hire you (hiring is hard). Help them understand your thinking.

3. 45 Minutes Is Short

Finishing perfectly is hard. Finishing well (clear communication, decent code, some testing) is the real bar.

4. You Already Have the Skills

You’re a senior architect. You think in terms of trade-offs, modularity, and optimization. You already do this at scale. Algorithms are just smaller, more explicit versions of the same thinking.

Go in confident. You’ve prepared. You understand the patterns. You know how to communicate. You’ll do well.