Google SWE Interview Questions: Real DSA and System Design Problems (2026)

If you are searching for Google SWE interview questions, you are probably past the generic advice stage. You want problems that have actually shown up in Google coding and system design rounds; not another "grind 500 LeetCode" post.

This guide covers 5 data structures and algorithms (DSA) questions and 5 system design questions reported by Google candidates in 2025–2026. Each DSA problem includes the statement, a worked example, how to approach it, and the follow-up Google interviewers tend to ask.

For a live, updated list of what candidates are reporting right now, see Google interview questions on InterviewTruth.

---

What to expect in a Google SWE interview

Google software engineer interviews typically include:

• 1–2 coding rounds — medium-to-hard DSA, often with a follow-up that forces you to optimize time or space
• 1 system design round (L4+) — breadth over depth; you are expected to cover major components quickly
• Googleyness / behavioral — collaboration, ambiguity, and trade-off reasoning

The DSA problems below are not guaranteed repeats, but they reflect patterns Google actually tests: monotonic stacks, sliding windows, scheduling, string transforms, and tree path problems.

---

5 Google DSA interview questions

Problem 1: Count people visible to the last person

Source: Google L3 interview experience (LeetCode Discuss)

Problem statement

Given an array representing the heights of people standing in a line, determine how many people are visible to the last person in the array.

Person A is visible to person B if there is no one between them who is taller than both A and B.

Example

Input:  [1, 10, 5, 7, 6, 3, 2, 4]
Output: 5

The people with heights 2, 3, 6, 7, and 10 are visible to the person with height 4.

How to approach it

Walk from right to left and maintain a monotonic stack (decreasing heights). For each person, pop everyone shorter than them from the stack — those popped people are not visible to anyone further left. Each person you keep on the stack is visible to the current person.

For the last-person-only version, simply count how many people remain visible when processing index n - 2 down to 0.

Follow-up (common at Google)

Find the number of visible people for every person in the list, not just the last one.

Use the same monotonic stack, but record the count as you pop. This yields an O(n) time, O(n) space solution for both the base problem and the follow-up.

Pattern: Monotonic stack · visibility / next-greater-element variant

---

Problem 2: Find all anagram indices in a string

Source: Google L4 interview experience (LeetCode Discuss) (post may be deleted)

Problem statement

Given two strings s and p, return all start indices of anagrams of p within s.

Example

Input:  s = "cbaebabacd", p = "abc"
Output: [0, 6]

Explanation: "cba" at index 0 and "bac" at index 6 are anagrams of "abc".

How to approach it

Use a sliding window of size len(p) over s, combined with a hashmap (or fixed-size frequency array for lowercase English letters) to track character counts.

1. Build a frequency map for p.
2. Slide the window across s, updating counts as characters enter and leave.
3. When the window's frequency map matches p's map, record the start index.

Complexity: O(n) time, O(1) space if you use a 26-element array (fixed alphabet).

Pattern: Sliding window · hashmap frequency counting

This is closely related to LeetCode 438 — Find All Anagrams in a String.

---

Problem 3: Minimum time to complete tasks on N CPUs

Source: Google L4 AMML interview experience (LeetCode Discuss)

Problem statement

Given N CPUs and the time taken to finish each of M tasks, determine the minimum time required to complete all tasks. Each CPU can execute only one task at a time with no cooldown period.

Example

Input:  N = 2, tasks = [3, 1, 4, 2, 5]
Output: 8

With 2 CPUs: one finishes [5, 2] in 7 time units, the other finishes [4, 3, 1] in 8. Minimum completion time is 8.

How to approach it

This is a load-balancing / parallel scheduling problem.

1. Minimum time lower bound = max(max(tasks), ceil(sum(tasks) / N)).
2. Binary search on the answer: for a candidate time T, greedily assign tasks to CPUs (longest-processing-time-first works well) and check whether all tasks fit within T.
3. If feasible, try a smaller T; otherwise, increase T.

Follow-up (common at Google)

After finding the minimum time, find the least number of CPUs needed to achieve that minimum time.

Binary search on N instead of T: for a fixed minimum time, check whether k CPUs can finish all tasks within that bound. Increase or decrease k accordingly.

Pattern: Binary search on answer · greedy scheduling

---

Problem 4: Find all ambigram words

Source: Google four-round interview experience (LeetCode Discuss)

Problem statement

Given a list of words, return all words that are ambigrams — words that look the same when viewed from different orientations (flipped vertically, mirrored horizontally, or rotated 180°).

Example

Input:  ["pod", "mom", "hello", "swims", "NOON"]
Output: ["mom", "swims", "NOON"]

How to approach it

Define a bidirectional character mapping for the orientation you are checking. Common 180° rotation pairs: b↔q, d↔p, n↔u, m↔w (case-dependent), and self-maps like o, x, H, I, O, X.

For each word:

1. Use two pointers — one at the start, one at the end.
2. Check whether word[i] and the transformed counterpart of word[j] match under your mapping.
3. If all pairs match, the word is an ambigram.

Clarify with your interviewer which orientation(s) to support. Google often leaves this intentionally ambiguous to test how you handle underspecified problems.

Pattern: Two pointers · string validation · character mapping

---

Problem 5: Tree path sum within a range

Source: Google onsite interview experience (LeetCode Discuss)

Problem statement

Given a binary tree and a sum range [lmin, lmax], determine whether there exists any path in the tree such that the sum of the nodes along the path equals a target sum kSum.

This is similar to LeetCode 437 — Path Sum III, with an added range constraint on valid path sums.

Example

Input:  root = [10, 5, -3, 3, 2, null, 11], lmin = 5, lmax = 15, kSum = 8
Output: true

Path 5 → 3 sums to 8, which is within [5, 15].

How to approach it

Use DFS with prefix sums:

1. At each node, maintain a running prefix sum from the root.
2. For the current prefix sum curr, check whether curr - kSum exists in your prefix-sum frequency map (meaning a path ending here sums to kSum).
3. Only count paths whose sum falls within [lmin, lmax].
4. Backtrack: remove the current prefix from the map when leaving the node.

Complexity: O(n) time, O(h) space for the recursion stack and hashmap (where h is tree height).

Pattern: DFS · prefix sum on trees · path counting

---

5 Google system design interview questions

System design at Google rewards breadth and structured thinking over deep expertise in one component. Below are five prompts repeatedly reported across Google L4–L5 interview experiences. Prepare a 35–45 minute outline for each.

1. Design Google Maps Street View image storage

What interviewers probe

• Storage at petabyte scale (object storage vs. block storage)
• Image tiling, zoom levels, and spatial indexing (geohash, quadtree)
• CDN placement for low-latency tile delivery
• Metadata service for location → tile mapping
• Ingestion pipeline for 360° panorama stitching

Key trade-offs: Storage cost vs. retrieval latency; pre-computed tiles vs. on-the-fly rendering.

---

2. Design a search system (web crawler + search)

What interviewers probe

• Crawler: URL frontier, politeness (robots.txt), deduplication (Bloom filter), distributed crawling
• Indexer: inverted index, tokenization, stemming
• Ranking: PageRank intuition, relevance signals, freshness
• Query path: load balancer → query service → index shards → result aggregation
• Scale: sharding strategy, replication, cache hot queries

This is the classic Google system design question. Cover the full pipeline end-to-end before diving deep on any single piece.

---

3. Design Google Photos

What interviewers probe

• Upload pipeline (resumable uploads, thumbnail generation, EXIF extraction)
• Storage tiering (hot vs. cold, deduplication via perceptual hashing)
• Search by metadata, faces, and objects (ML inference pipeline)
• Sharing and permissions model
• CDN for photo delivery; consistency for album edits

Key trade-offs: Storage deduplication vs. privacy; eventual consistency for album sharing.

---

4. Design a distributed object storage system

What interviewers probe

• Consistent hashing for data distribution
• Replication factor and read/write quorum (e.g., 3-replica, W=2, R=2)
• Leader election and failure detection (heartbeats, gossip)
• Erasure coding vs. full replication for cost
• API design: PUT, GET, DELETE with versioning

Think S3 or GCS. Interviewers want to hear how you handle node failures without losing data.

---

5. Design a real-time collaborative text editor

What interviewers probe

• Operational Transformation (OT) vs. Conflict-free Replicated Data Types (CRDTs)
• WebSocket or WebRTC for real-time sync
• Cursor presence and awareness
• Offline editing and merge on reconnect
• Persistence layer and document versioning

Key trade-offs: OT is simpler for centralized servers; CRDTs handle peer-to-peer and offline better but are harder to implement.

For more system design pitfalls to avoid, see our post on common system design interview mistakes.

---

How to use this list effectively

1. Solve each DSA problem in 35–40 minutes under timed conditions — that is roughly what you get in a Google coding round.
2. Always practice the follow-up. Google interviewers rarely stop at the base problem.
3. For system design, practice out loud. Draw boxes, label data flows, and state trade-offs before optimizing any component.
4. Cross-check with live reports. Questions rotate. Use InterviewTruth's Google interview questions page to see what candidates are posting this week.

---

Frequently asked questions

What DSA topics does Google ask most?

Recent Google SWE interview questions cluster around trees, graphs, arrays with two pointers or sliding windows, monotonic stacks, and scheduling/greedy problems. Hard dynamic programming appears less frequently at L3 but is common at L4+.

How hard are Google coding interview questions?

Most Google coding rounds are LeetCode medium with an optimization follow-up. A strong candidate solves the base problem in 15–20 minutes and spends the remaining time on the follow-up and edge cases.

Does Google repeat interview questions?

Sometimes. Candidates report seeing variations of problems from recent interview experiences. That is why tracking recently asked Google questions is more useful than random LeetCode grinding.

How many system design rounds does Google have?

L3 (new grad) candidates typically have 0–1 system design rounds. L4 and above usually have 1 dedicated system design round, sometimes 2 for senior roles.

What is the best way to prepare for Google SWE interview questions?

Focus on signal over volume: solve 50–80 curated problems that match recent Google patterns, practice 5–10 system design outlines, and do timed mock interviews. Quality and pattern recognition beat raw problem count.

---

Final thoughts

Google SWE interview questions are challenging, but they are not random. The DSA problems above share a common thread — each has a clean optimal solution once you recognize the pattern. The system design prompts reward candidates who think in pipelines, trade-offs, and failure modes.

Start with the five coding problems on this page. Then browse live Google interview reports to stay current. Good luck.