Google 2027 SWE Intern VO, Fresh Recap: HashMap + Sliding Window and Graph BFS

Overview

I just finished my Google 2027 Intern VO. There were no particularly unusual questions, but Google clearly cares about:

Communication + coding fundamentals + follow-ups

Two technical rounds, about 45 minutes each.

Round 1 coding: HashMap + sliding window

A fairly typical HashMap + sliding window problem — not especially hard on its own.

My flow: brute force first → confirm the complexity with the interviewer → optimize to O(n).

The follow-ups were actually more detailed:

• What if the data is huge?
• What if the input is streaming data?
• What if memory isn't enough?
• Are there easy-to-miss edge cases?

Reference ideas: a sliding window is a single pass, which suits streaming data naturally — you only keep the window's state (the counts in the HashMap), not the whole input. If memory is tight, see whether the key space can be compressed (e.g. a fixed-size array for a fixed character set), or shard by key. Common edge cases: empty input, a window larger than the array, all elements identical, k = 0.

It felt like Google cares less about whether the final code runs and more about whether you can explain your thinking step by step.

Round 2 coding: Graph / BFS

Build a graph from the problem, then run BFS to get the result. After the basic version, the interviewer kept changing the conditions:

• What if the graph is huge?
• How do you handle cycles?
• What if you need to return the path, not just the result?
• How do you reduce extra space?

Reference ideas:

• Cycles: BFS keeps a visited set so each node is enqueued once; cycles can't cause infinite loops.
• Returning the path: record each node's parent when you enqueue it; once you reach the target, walk back through parent and reverse.
• Huge graphs / saving space: don't prebuild the whole adjacency list — generate neighbors on demand; when both start and target are known, bidirectional BFS usually explores far fewer nodes.

from collections import deque

def bfs_path(graph, start, target):
    """Shortest path in an unweighted graph: list of nodes from start to target, [] if unreachable"""
    parent = {start: None}            # also serves as the visited set
    q = deque([start])
    while q:
        u = q.popleft()
        if u == target:
            path = []
            while u is not None:
                path.append(u)
                u = parent[u]
            return path[::-1]
        for v in graph.get(u, []):
            if v not in parent:
                parent[v] = u
                q.append(v)
    return []

I missed an edge case early in this round, but fixed it after a hint from the interviewer. Getting stuck for a moment in a VO isn't a big deal — the key is not going silent; keep the interviewer aware of what you're thinking.

Recommended answer flow

clarify → explain brute force → optimize → code → dry run → edge cases → complexity

My biggest takeaway: Google VO doesn't require the optimal solution instantly. When you hit an unfamiliar variant, calmly identify the problem type first and think proactively about edge cases and likely follow-ups — the whole interview becomes much steadier. You can practice this deliberately in mock interviews.

If you're preparing for 2027 Summer Intern, start now with Google's frequent Medium problems + practicing explaining out loud — there's plenty of time!