Google Software Engineer Entry Level (L3) Interview Preparation Guide

Software Engineer

Google

entry

6 rounds

Updated 6/15/2026

Google's entry-level software engineer interview process (L3) focuses heavily on fundamental coding skills, data structures, and algorithms. The interview consists of a recruiter screening call, a technical phone screen, and three technical coding rounds conducted virtually or in-person, followed by a behavioral assessment. Entry-level candidates are expected to demonstrate strong problem-solving abilities, clean coding practices, and cultural alignment with Google's values. The entire process typically spans 4-8 weeks.

Interview Rounds

Recruiter Screening

25 min4 focus topicsbehavioral

What to Expect

Your first interaction with Google, this 20-30 minute call is conducted by a Google recruiter via phone or video. The recruiter will verify your basic qualifications, discuss your educational background and relevant experience, assess your communication skills, and gauge your genuine interest in the company and role. This round focuses on confirming baseline fit before investing time in technical evaluations. The recruiter will explain the role, team dynamics, and provide clarity on the interview process and timeline.

Tips & Advice

Be genuine and concise when describing your background, focusing on software development projects, internships, and coursework. Highlight relevant programming languages (Java, Python, C++, JavaScript) and any frameworks or tools you've used. Show authentic enthusiasm for Google's products and mission—reference specific products or projects that excite you rather than generic praise. Ask thoughtful questions about the team and role to demonstrate genuine interest. Prepare a 2-3 minute summary of your experience emphasizing your coding ability and problem-solving mindset. Speak clearly, avoid unnecessary jargon, and be honest about your skill level—overselling leads to mismatches later.

Focus Topics

Learning Mindset and Adaptability

For entry-level roles, emphasize your enthusiasm for learning and growth. Share examples of picking up new programming languages, frameworks, or technologies on your own. Show comfort with challenges and explain how you approach learning new domains. Demonstrate that you view obstacles as learning opportunities.

Practice Interview

Study Questions

Motivation and Alignment with Google

Articulate specific reasons for wanting to work at Google beyond generic statements like 'it's a great company.' Reference particular Google products you use, engineering challenges Google solves, or aspects of their culture that resonate with you. Connect your career goals and values with what Google offers.

Practice Interview

Study Questions

Communication and Interpersonal Skills

Demonstrate clear articulation when explaining technical concepts, active listening when the recruiter speaks, and ability to ask thoughtful follow-up questions. Show collaboration mindset by discussing past team experiences. Your communication style during this call predicts how you'll participate in code reviews and cross-functional collaboration.

Practice Interview

Study Questions

Professional Background and Technical Foundation

Concisely communicate your educational background, internships, personal projects, and relevant work experience in software development. Clearly describe programming languages and frameworks you're proficient in, showing honesty about competency levels. For entry-level, internship experiences and substantial academic projects demonstrate capability.

Practice Interview

Study Questions

Technical Phone Screen

50 min5 focus topicstechnical

What to Expect

Your first technical evaluation, this 45-60 minute interview is conducted via video call using Google Meet or Hangouts. You'll write code in a shared Google Doc or collaborative coding platform with screen sharing required. The interviewer will present 1-2 algorithmic problems of medium difficulty that you're expected to solve in real-time. You'll discuss your approach, write functional code, handle edge cases, and explain your solution's time and space complexity. This round directly assesses your fundamental coding ability, problem-solving methodology, and understanding of core data structures and algorithms.

Tips & Advice

Before writing code, ask clarifying questions about problem constraints, input ranges, and expected output format. Verbalize your approach and discuss your algorithm strategy before implementing—this demonstrates clear thinking and allows the interviewer to provide guidance if you're headed in the wrong direction. Write clean, readable code using meaningful variable names and proper indentation. Aim to write approximately 30 lines of code per problem. Explicitly identify and handle edge cases like empty inputs, single elements, or boundary values. Analyze your solution's time and space complexity, and discuss potential optimizations. If stuck, think out loud and ask for hints rather than sitting silently. Test your solution mentally with provided examples before declaring it complete. Practice coding on Google Docs beforehand to become comfortable with the environment and its quirks.

Focus Topics

Clean Code and Clear Communication

Write code with descriptive variable names that reveal intent. Use consistent formatting and indentation. Include brief comments for non-obvious logic. Explain your solution approach clearly as you code. Discuss edge cases and defensive programming techniques. Your code should be readable and maintainable by others.

Practice Interview

Study Questions

Time and Space Complexity Analysis

Calculate Big O complexity for your solutions. Understand when O(n²) might be acceptable versus when O(n log n) is necessary. Recognize common complexity patterns: O(1), O(log n), O(n), O(n log n), O(n²). Trade-offs between time and space—sometimes using extra memory improves speed. Discuss optimization opportunities.

Practice Interview

Study Questions

Problem Decomposition and Algorithm Development

Ability to break complex problems into manageable components. Start by understanding the problem thoroughly, then develop a brute force solution, then optimize. Recognize problem patterns and apply standard algorithms. Validate assumptions about the problem with the interviewer.

Practice Interview

Study Questions

Data Structures Fundamentals and Selection

Deep understanding of arrays, linked lists, stacks, queues, hash tables, and sets. Know time and space complexities for each operation: insertion, deletion, search, and access. Understand when to use each data structure to solve different problem types. Recognize tradeoffs—hash tables provide fast lookup but use more memory; linked lists enable efficient insertion but require traversal for search.

Practice Interview

Study Questions

Arrays and String Problem-Solving

Master array and string manipulation including indexing, iteration, element searching, and transformation. Understand two-pointer technique for solving problems efficiently, sliding window approach for contiguous subarrays, and prefix sum technique for range queries. Be comfortable working with both 1D and 2D arrays. Practice substring and subarray problems, character frequency analysis, and string pattern matching.

Practice Interview

Study Questions

Onsite Coding Interview 1

45 min5 focus topicstechnical

What to Expect

The first of three onsite technical rounds (approximately 45 minutes), this interview focuses on coding problems involving arrays, strings, and basic data structure manipulation. You'll write code on a whiteboard, provided Chromebook, or virtual editor depending on your office location. The interviewer presents a medium-difficulty problem. You're expected to discuss your approach, write clean functional code, handle edge cases explicitly, and demonstrate optimization thinking. This round assesses your foundational problem-solving skills, coding proficiency, and ability to explain technical reasoning.

Tips & Advice

Treat the whiteboard or Chromebook like a production code editor—write clean, well-formatted code. Verify the problem requirements with the interviewer before solving. Discuss your approach and algorithm before writing code. Write out your solution step-by-step, explaining your logic for each section. Test your solution with provided examples and edge cases. If you make mistakes, explain what you'd correct rather than erasing everything repeatedly. For whiteboards, write larger and clearer than feels natural. Practice your preferred programming language on whiteboards and Chromebooks beforehand—the environment is different from your IDE and requires adaptation.

Focus Topics

Code Organization and Professional Standards

Write functions with clear, single responsibilities. Use variable names that reveal intent rather than cryptic abbreviations. Follow consistent formatting conventions and proper indentation. Include brief comments explaining non-obvious logic. Your code should be readable by others without extensive explanation.

Practice Interview

Study Questions

Solution Testing and Verification

Before declaring your solution complete, trace through it with provided test cases. Verify output correctness. Explicitly test edge cases you identified. Discuss your testing approach with the interviewer. Be willing to catch and fix bugs when you spot them.

Practice Interview

Study Questions

String Processing and Character-based Problems

Practice string algorithms: character frequency counting using hash tables, pattern detection, substring searches, and string transformations. Understand when to use different approaches—sometimes iterating character by character, sometimes using built-in string methods. Solve problems involving palindromes, anagrams, and string matching.

Practice Interview

Study Questions

Edge Case Identification and Defensive Coding

Before coding, identify potential edge cases: empty inputs, single elements, duplicates, negative numbers, very large values, and boundary conditions. Explicitly code defensive checks. Discuss edge cases with the interviewer to demonstrate thorough analytical thinking. Robust code handles unexpected inputs gracefully rather than crashing.

Practice Interview

Study Questions

Array Manipulation Techniques and Algorithms

Master common array algorithms: two-pointer technique for finding pairs, sliding window for subarray problems, prefix sums for range calculations, and binary search for sorted arrays. Practice in-place modifications and understand when they're appropriate. Solve problems involving rotations, removals, rearrangements, and searches within arrays.

Practice Interview

Study Questions

Onsite Coding Interview 2

45 min5 focus topicstechnical

What to Expect

The second onsite technical round (approximately 45 minutes), this interview focuses on more complex data structures including trees, graphs, and linked lists. The problem is typically medium to medium-hard difficulty and often involves tree traversal algorithms, graph exploration, or linked list manipulation. You'll write code on a whiteboard or Chromebook. This round assesses your understanding of hierarchical and networked data structures, recursive thinking, and ability to implement standard graph/tree algorithms.

Tips & Advice

Draw the data structure before coding to visualize the problem and think through your approach. Recursion is often useful for tree problems—think recursively about how to solve the problem on smaller subtrees. For graph problems, carefully consider whether to use depth-first search (DFS) or breadth-first search (BFS). Clearly define your base cases for recursion before implementing. For linked lists, be careful with pointer manipulation—consider using a temporary node to avoid losing references. Trace through your recursive logic with a small example to verify correctness before claiming your solution works.

Focus Topics

Algorithm Selection and Complexity Trade-offs

For each problem, discuss multiple approaches before implementing. Compare their time and space complexity. Understand when a slightly less efficient algorithm might be better due to simplicity, easier implementation, or reduced space usage. Make informed design decisions about trade-offs.

Practice Interview

Study Questions

Systematic Debugging and Problem-Solving Approach

When stuck, break the problem into smaller pieces and solve incrementally. Trace through your algorithm step-by-step with concrete examples. Identify assumptions you've made and validate them. Use clarifying questions rather than getting stuck silently. When bugs appear, use hand-tracing or print statements to identify the issue.

Practice Interview

Study Questions

Recursion and Backtracking Techniques

Understand recursive function design: defining base cases clearly, making recursive calls with reduced problem size, and combining results. Master backtracking for constraint-based problems like permutations, combinations, and solving puzzles. Recognize when recursion is appropriate versus iteration. Understand implications of recursion depth and stack usage.

Practice Interview

Study Questions

Binary Trees and Tree Traversal Algorithms

Master tree data structures and all traversal methods: inorder, preorder, postorder, and level-order (breadth-first search). Understand binary search tree properties and validation. Practice problems involving tree construction, modification, path finding, and level-based operations. Solve problems about tree balancing, lowest common ancestors, and serialization.

Practice Interview

Study Questions

Graph Representation and Graph Algorithms

Understand different graph representations: adjacency lists and adjacency matrices. Master graph traversal algorithms—depth-first search (DFS) and breadth-first search (BFS). Understand shortest path algorithms, cycle detection, topological sorting, and connected components. Know when to use each approach based on problem requirements.

Practice Interview

Study Questions

Onsite Coding Interview 3

45 min5 focus topicstechnical

What to Expect

The third onsite technical round (approximately 45 minutes), this interview covers a diverse range of topics including hash tables, linked lists, dynamic programming basics, and other algorithmic concepts. The problem is typically medium difficulty with possible challenging elements. You'll write code on a whiteboard or Chromebook. This round assesses your versatility in selecting and implementing the right algorithm or data structure for different problem types, and often serves as your opportunity to demonstrate growth from previous rounds.

Tips & Advice

By the third technical round, apply lessons learned from previous interviews. For hash table problems, think about when hashing is optimal and how to handle collisions. For linked lists, be meticulous with pointer manipulations—consider drawing the list as you make changes. For dynamic programming problems, identify overlapping subproblems and think about memoization to cache results. Maintain the same professional coding standards from earlier rounds. This is your opportunity to demonstrate growth if earlier rounds had rough moments—show you listened to feedback and adapted. Stay composed and methodical even as complexity increases.

Focus Topics

Dynamic Programming Fundamentals and Memoization

Understand the concept of overlapping subproblems and optimal substructure. Practice basic dynamic programming problems: fibonacci, coin change, climbing stairs, and longest increasing subsequence. Understand memoization as a top-down optimization approach. Recognize when a problem can be solved more efficiently with DP.

Practice Interview

Study Questions

Standard Algorithm Implementation

Be able to implement common algorithms from scratch: sorting algorithms (merge sort, quick sort), searching (binary search), and other frequently needed functions. Understand when to use built-in library functions versus implementing from scratch. Explain trade-offs in different implementations.

Practice Interview

Study Questions

Incorporating Feedback and Demonstrating Growth

By round three, interviewers may point out improvements to your approach or coding style. Listen carefully to feedback, understand suggestions, and incorporate them into your solution. Show your willingness to learn and improve based on input. Demonstrate that you value collaborative refinement.

Practice Interview

Study Questions

Linked List Operations and Pointer Manipulation

Master linked list operations: insertion at any position, deletion, reversal, cycle detection, finding kth element from end, and merging lists. Understand pointer manipulation and be careful with null reference handling. Practice problems requiring multiple passes through the list and two-pointer techniques adapted for linked lists.

Practice Interview

Study Questions

Hash Tables and Efficient Lookup Problems

Understand hash table implementation fundamentals, collision handling strategies, and when hash tables provide O(1) average case performance. Master using hash tables for frequency counting, duplicate detection, two-sum type problems, and caching scenarios. Solve problems where hashing enables significant efficiency improvements.

Practice Interview

Study Questions

Onsite Behavioral Interview - Googliness

45 min5 focus topicsbehavioral

What to Expect

This 45-minute behavioral interview assesses cultural fit and alignment with Google's values, referred to as 'Googliness.' The interviewer will ask open-ended questions about your past experiences, how you handle challenges and failures, your collaboration style, learning approach, and whether you share Google's mission to organize the world's information and make it universally accessible. Unlike some companies with formal leadership principles, Google seeks to understand your thinking patterns, emotional intelligence, and intrinsic motivation. For entry-level candidates, the focus is on potential to grow, learning mindset, and collaborative spirit rather than past management experience.

Tips & Advice

Use the STAR method (Situation, Task, Action, Result) to structure answers with specific, concrete examples rather than abstract principles. Prepare 5-6 stories that demonstrate different qualities: successful collaboration, overcoming technical challenges, learning from failure, taking initiative beyond assigned tasks, handling disagreement, and contributing to team success. Research Google's actual products, services, and company mission—understand what they do and why. For entry-level, emphasize your learning ability, curiosity, eagerness for growth, and enthusiasm about contributing to meaningful work. Show you've reflected on how your work connects to something larger than yourself. Be authentic rather than polished—Google values genuine answers. For questions about conflicts, focus on what you learned and how you'd handle similar situations differently. Prepare thoughtful questions showing you've researched the company and thought about your fit.

Focus Topics

Communication and Clear Explanation

Practice explaining technical concepts clearly to non-technical audiences. Show you can listen carefully to questions and provide relevant, focused answers. Demonstrate self-awareness about communication—adjust complexity and depth based on audience. Show you ask clarifying questions rather than making assumptions.

Practice Interview

Study Questions

Inclusion, Diversity, and Ethical Thinking

Show your perspective on building inclusive products and environments. Discuss how you think about different user needs, accessibility considerations, and diverse perspectives. Demonstrate ethical thinking about technology's impact. For entry-level, show understanding that your code affects real users with varying needs and circumstances.

Practice Interview

Study Questions

Learning Mindset and Growth from Failure

For entry-level, this is particularly important. Share examples of learning new technologies independently, recovering gracefully from failures or mistakes, seeking feedback actively, and adapting approaches based on input. Describe challenging situations that pushed you to grow. Show you view setbacks as learning opportunities rather than defeats. Demonstrate excitement about stretching into unfamiliar areas.

Practice Interview

Study Questions

Proactive Problem-Solving and Taking Initiative

Share examples of identifying problems proactively without being told, proposing solutions, taking ownership of challenges, and persisting through obstacles. Discuss how you approach complex problems by breaking them down and exploring multiple approaches. Show intellectual curiosity and your drive to solve hard problems. Demonstrate initiative in learning new technologies or tackling unfamiliar domains.

Practice Interview

Study Questions

Collaboration and Cross-Functional Teamwork

Share specific examples of successfully working with diverse team members including people with different backgrounds, perspectives, and expertise. Describe how you contribute to team success, handle disagreements constructively, build productive relationships, and create inclusive environments. Demonstrate you listen actively to different viewpoints and value diverse perspectives. Show how you've supported teammates in achieving shared goals.

Practice Interview

Study Questions

Frequently Asked Software Engineer Interview Questions

Hashing and Hash Based Data StructuresMediumTechnical

28 practiced

Coding (Python): Given a text s and a pattern p, find all starting indices of p's anagrams in s (sliding-window + hashing). Explain how you maintain character counts efficiently as the window slides and how you detect matches without sorting every window.

Sample Answer

To find all start indices of anagrams of p in s efficiently, use a fixed-size sliding window of length len(p) and maintain character counts with two frequency arrays (or dicts) and a running "match count" that tracks how many characters have matching counts. This avoids sorting each window.

python

from collections import Counter

def find_anagrams(s: str, p: str):
    n, m = len(s), len(p)
    if m > n: 
        return []
    res = []
    p_count = [0]*26
    w_count = [0]*26
    a_ord = ord('a')
    for ch in p:
        p_count[ord(ch)-a_ord] += 1
    for ch in s[:m]:
        w_count[ord(ch)-a_ord] += 1

    matches = sum(1 for i in range(26) if p_count[i] == w_count[i])
    if matches == 26:
        res.append(0)

    for i in range(m, n):
        in_idx = ord(s[i]) - a_ord
        out_idx = ord(s[i-m]) - a_ord

        # update incoming char
        before = (w_count[in_idx] == p_count[in_idx])
        w_count[in_idx] += 1
        after = (w_count[in_idx] == p_count[in_idx])
        if before and not after:
            matches -= 1
        elif not before and after:
            matches += 1

        # update outgoing char
        before = (w_count[out_idx] == p_count[out_idx])
        w_count[out_idx] -= 1
        after = (w_count[out_idx] == p_count[out_idx])
        if before and not after:
            matches -= 1
        elif not before and after:
            matches += 1

        if matches == 26:
            res.append(i - m + 1)

    return res

Key points:- Use fixed 26-length arrays for lowercase letters (O(1) per char update).- Maintain "matches" = number of character indices where counts equal; update in O(1) for each incoming/outgoing char.- No sorting needed; each slide is constant work.

Time Complexity: O(n) where n = len(s). Space Complexity: O(1) (26-size arrays) plus output.

Edge cases:- p longer than s.- Non-lowercase input (use dicts or larger arrays).- Repeated characters handled correctly.

Alternative: Use Counter and compare equality but that costs O(26) per slide; still OK but slightly slower than tracking matches.

Clean Code and Best PracticesMediumTechnical

67 practiced

A legacy module makes it hard to add tests. Explain how you would use Test-Driven Development (TDD) or characterization tests to safely add functionality to legacy code. Include concrete steps, techniques such as seams and dependency injection, and when to refactor vs wrap behavior.

Sample Answer

Start by establishing safety: I’ll add characterization tests to lock current behavior, then introduce seams and DI so I can do TDD for new features. Concrete steps:

1. Safety net — characterization tests- Write end-to-end or unit tests that assert observed behavior (inputs → outputs, side-effects, exceptions). These tests document current behavior and prevent regressions.- Use golden files or snapshots for legacy outputs where appropriate.

2. Create seams without changing behavior- Use the “wrap” approach: add thin adapters around legacy functions/classes so tests can call the wrapper. This minimizes risk.- Example: if a function reads from disk, wrap file I/O behind a read_file(path) seam.

3. Introduce dependency injection incrementally- Replace hard-coded calls with parameters or constructor-injected collaborators. Do this in small commits: - Step A: Add an optional parameter with default of the legacy dependency (non-breaking). - Step B: Pass test doubles (mocks/fakes) in characterizations to drive deterministic behavior.

4. Start TDD for new functionality- Write a failing unit test against the seam-injected dependency.- Implement the smallest change to satisfy the test, run characterization tests to ensure no regressions.- Iterate: add more fine-grained tests, refactor internals while keeping characterization tests green.

5. When to refactor vs wrap- Wrap when: behavior is fragile, risk of regression is high, or external API is unclear — add adapter layers and tests first.- Refactor when: you have solid characterization tests and can make small, reversible refactors; prefer many small refactors with tests after each.- If change is large, prefer “strangler” pattern: route new behavior through new components while leaving legacy code until safe to remove.

Example seam (Python):

python

# seam: configurable data loader (default uses legacy)
class DataLoader:
    def __init__(self, reader=None):
        self.reader = reader or legacy_read_file

    def load(self, path):
        return self.reader(path)

# in tests, inject fake:
def fake_reader(path):
    return "deterministic content"
loader = DataLoader(reader=fake_reader)
assert loader.load("x") == "deterministic content"

Key techniques: small safe commits, characterization tests first, add seams/wrappers, introduce DI with defaults, then TDD new behavior and refactor iteratively. This minimizes risk while allowing safe evolution of legacy code.

Debugging and Recovery Under PressureMediumTechnical

72 practiced

Explain how to instrument logging for faster debugging under pressure: decide on log levels, when to use structured JSON logs, how to attach correlation IDs across services, sampling strategies to reduce volume, and best practices for log queries. Provide an example log schema for a single request including fields you'd log.

Sample Answer

Start with clear goals: make logs actionable under pressure (fast triage, minimal noise, searchable context).

Log levels:- ERROR: user-impacting failures you must act on now.- WARN: unexpected but non-fatal issues; worth alerting if frequent.- INFO: high-level lifecycle events (request start/stop, deployments) — default retention.- DEBUG: verbose internal state useful for reproducing bugs; enable only on demand or via sampling.- TRACE: extremely detailed (use sparingly).

When to use structured JSON:- Always for service logs: JSON fields enable fast queries, parsing, and enrichment (no free-text parsing).- Keep a message string for human readability but rely on fields for queries.

Correlation IDs:- Generate a stable request_id at edge (API gateway, load balancer) and propagate via headers (e.g., X-Request-ID, traceparent).- Attach request_id, parent_id, span_id to every log and to traces/metrics. Fail open: if absent, create one at entry.

Sampling strategies:- Head-based sampling: sample 1/N requests for DEBUG/TRACE payloads.- Tail-based sampling: keep all metadata but only store full traces/logs for anomalous/errorful requests.- Priority sampling: always keep ERRORs and requests with high latency; sample successful low-latency requests.- Preserve percentages per service to avoid cascading gaps.

Best practices for log queries:- Index common query fields (request_id, service, environment, level, user_id, endpoint).- Use time windows + filters; start with request_id then broaden.- Keep structured tags for quick aggregation (error_code, retry_count).- Avoid free-text searches as primary; use them only after narrowing.

Example log schema for one request (JSON):

json

{
  "timestamp":"2025-11-22T14:23:01.123Z",
  "level":"INFO",
  "service":"orders-api",
  "env":"prod",
  "request_id":"f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "trace_id":"00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
  "span_id":"00f067aa0ba902b7",
  "parent_id":null,
  "user_id":"u-12345",
  "client_ip":"203.0.113.5",
  "method":"POST",
  "path":"/v1/orders",
  "status":201,
  "latency_ms":128,
  "error_code":null,
  "message":"Order created",
  "version":"1.4.2",
  "host":"orders-3",
  "tags":{"payment_gateway":"stripe","region":"us-east-1"},
  "sampled":true
}

This schema lets you locate an issue by request_id, correlate across services via trace_id, filter by error/status, and inspect performance via latency_ms.

Array and String ManipulationHardSystem Design

50 practiced

Given a huge string that cannot fit into memory, you need to determine whether it contains a particular pattern substring. Describe algorithms and system-level approaches (external scanning, indexing, Bloom filters, approximate matching) to solve this problem with memory and time trade-offs, and state which you'd choose depending on constraints.

Sample Answer

Requirements and constraints:- Input: a single very large string (stream or stored on disk) that cannot fit in RAM.- Query: does it contain exact pattern P (length m)? Optionally support many different patterns, approximate matches, low latency, or many queries.- Non-functional: memory limit, single-pass vs. pre-processing, false positives allowed?, update frequency.

Approaches

1) Streaming exact-match (single query, one pass)- Use streaming KMP (Knuth–Morris–Pratt) or streaming Rabin-Karp rolling hash: maintain O(m) state, process bytes sequentially. Memory: O(m). Time: O(n). Good when you can read stream once and pattern length is small.

2) External scanning with mmap / chunking (disk-resident)- Map file or read fixed-size overlapping chunks (overlap m-1) and run in-memory efficient search (Boyer-Moore, KMP) per chunk. Parallelize chunks across workers. Trade-off: I/O-bound; need overlap to avoid misses at boundaries.

3) Pre-built full-text index (many queries, exact)- Build suffix array/ suffix automaton/ FM-index (Burrows-Wheeler + rank/select) on disk or compressed; supports sublinear queries. Heavy preprocessing and disk-space; good when many queries and updates are infrequent.

4) Bloom filter / n-gram Bloom filters (fast approximate existence)- Precompute k-gram (e.g., all substrings of length k ≤ m) Bloom filter on the corpus. Query: if any k-gram absent → pattern absent (definitive). If present → possible match (false positive), then verify by targeted scan. Memory/time trade-off: very compact, false positive rate configurable. Good for quick negative answers and reducing I/O.

5) Approximate matching (fuzzy)- Use streaming dynamic programming with banded edit-distance (Ukkonen) or bit-parallel Myers algorithm for small edit distances; O(n * d / wordsize) memory O(1) aside from pattern. Or build q-gram index + verification for many queries.

System architecture (for production)- Ingestion: chunker with m-1 overlap, supports streaming or stored shards.- Worker pool: each worker runs KMP/Boyer-Moore/Myers depending on exact/approximate.- Indexing layer: optional Bloom filter service (serves quick negatives) and full-text index for hot data.- Storage: object store with shards, and persistent index files (FM-index) for frequent queries.- Orchestration: job queue, monitoring, cost-aware scheduling.

Which to choose?- Single one-off query, low memory: streaming KMP/Rabin-Karp.- Large disk file, want parallel speed: chunked scan with overlap + Boyer-Moore.- Many queries, low-latency: build compressed full-text index (FM-index) on disk.- Many queries where most are negatives and memory is tight: n-gram Bloom filter to filter negatives, then verify positives with targeted scan.- Need fuzzy matches: Myers bit-parallel streaming for small edit distance; otherwise q-gram index + verification.

Key trade-offs:- Preprocessing vs query latency: indexes and Bloom filters cost build time/space but reduce per-query I/O.- Memory vs false positives: Bloom filters save RAM at cost of verification work.- Exactness vs speed: streaming exact algorithms give deterministic answer; probabilistic filters speed up negatives.

Practical note: start with streaming KMP + optional Bloom filter to reduce I/O; move to FM-index when query volume justifies preprocessing and storage.

Algorithm Analysis and OptimizationHardTechnical

80 practiced

You're implementing pathfinding on an embedded device with only 256 KB RAM and limited CPU. For tasks like map matching or A*, describe how you would pick algorithms and data structures, and list optimizations such as memory pooling, compact graph encodings, heuristic selection, and buffer reuse to meet latency and memory constraints. Explain trade-offs.

Sample Answer

I’d design for minimal working set first, then trade speed vs memory with selectable modes.

Algorithm / data-structure choices- If graph is small (nodes < ~50k) and edge weights non-negative: A* with an explicit adjacency list in CSR (compressed sparse row) using 16-bit or 24-bit indices. CSR = contiguous arrays (edges, indices, weights) → low overhead and cache-friendly.- If RAM is extremely tight or graph dynamic: IDA* (iterative deepening) uses O(1) extra memory but higher CPU and repeated work—good when memory >> CPU trade is acceptable.- For map-matching: use a lightweight HMM limited to k-best candidates per GPS fix (k=3), represented with small structs and fixed-point coordinates.

Memory & data encoding optimizations- Use fixed-point for coordinates (e.g., 32-bit or 24-bit) to avoid floating point costs.- Delta / quantized coordinate encoding and variable-length edge weight encoding (e.g., 16-bit or 24-bit) to shrink storage.- Pack node flags into bitfields; use uint16_t indices where possible.- Precompute and store a coarse hierarchical graph (multi-level): coarse routing on a tiny graph, refine locally. This reduces A* search space dramatically with modest extra preprocessing.

Runtime-memory management- Single arena / memory pool for all temporary allocations (open list, closed set, neighbor buffers). Reset pool per query to avoid fragmentation.- Use compact open-set: binary heap over indices with an array of positions (index->heapPos) stored as uint16_t. Alternatively use a Fibonacci/bucket queue if weights are small integers.- Store closed set as a bitset or bloom filter + small backpointers table (saves memory when many nodes explored).

Heuristic selection & optimizations- Use admissible, cheap heuristics: Manhattan/octile for grids; straight-line Euclidean in fixed-point for graphs. Precompute sparse landmark distances (ALT) if you can afford a few kB for landmark tables — drastically reduces expansions.- If CPU is very constrained, use lower-quality heuristics to reduce compute (e.g., coarse-grid lookup table) but accept more expansions.

Other practical optimizations- Buffer reuse: one static buffer for path reconstruction (parent indices) and one for neighbor list; avoid heap allocations in hot loop.- Early exit & goal bounding: prune nodes outside a bounding box or maximum detour ratio for map-matching.- Profile-guided tuning: measure typical query size, reserve a fixed budget (e.g., 128 KB) and fall back to IDA*/approximate path when exceeded.- Trade-offs: preprocessing (hierarchies, landmarks) trades ROM/flash and some RAM for faster queries; IDA* trades CPU for memory; quantization reduces precision. Choose based on latency requirement and acceptable path quality.

Example constraint mapping (256 KB RAM)- Reserve 64 KB for stack/OS/other system use → 192 KB for pathfinding.- CSR graph: edges array + index array + weights can be kept in flash and streamed, but keep current node neighborhood and open/closed structures in RAM (e.g., 128 KB arena).- If RAM demand exceeds budget, enable fallback: coarse-routing + local refinement or increase quantization.

This approach keeps memory predictable (pooling, compact encodings), keeps hot data cache-friendly, and gives levers (preprocessing vs CPU, accuracy vs memory) to meet latency constraints on an embedded device.

Data Structures and ComplexityMediumTechnical

68 practiced

Explain how a balanced binary search tree like an AVL tree maintains balance on insertion. Describe single and double rotations with diagrams or pseudocode and analyze why balancing preserves O(log n) height.

Sample Answer

An AVL tree maintains height-balance by tracking a balance factor at each node: balance = height(left) - height(right). After inserting a node using normal BST insertion, you walk back up the path to the root, update heights and balance factors, and rebalance any node whose balance becomes +2 or -2 using rotations.

Single rotations:- Right rotation (for left-left case: balance(node) = +2 and balance(node.left) >= 0)

Ascii before: z / y /x

After right rotate(z): y / \ x z

- Left rotation (right-right case is symmetric).

Double rotations:- Left-Right (balance(z)=+2 and balance(z.left) = -1): first left-rotate(z.left) then right-rotate(z).Ascii before: z / y \ x

After left(y): y and x swap orientation, then right(z) yields balanced subtree.

Pseudocode (simplified):

python

def insert(node, key):
    if not node: return Node(key)
    if key < node.key: node.left = insert(node.left, key)
    else: node.right = insert(node.right, key)
    update_height(node)
    return rebalance(node)

def rebalance(node):
    bf = height(node.left) - height(node.right)
    if bf > 1:
        if height(node.left.left) >= height(node.left.right):
            return rotate_right(node)        # LL -> single right
        else:
            node.left = rotate_left(node.left)  # LR -> double
            return rotate_right(node)
    if bf < -1:
        if height(node.right.right) >= height(node.right.left):
            return rotate_left(node)         # RR -> single left
        else:
            node.right = rotate_right(node.right) # RL -> double
            return rotate_left(node)
    return node

Why this preserves O(log n) height:- Every rotation is a local restructuring that reduces the height of the taller child subtree or moves imbalance down; it preserves inorder order and adjusts heights in O(1). AVL invariants force that for n nodes the tree height h ≤ c·log2(n+1) for constant c (strict bound: h < 1.44·log2(n+2)). Because after each insertion we restore the balance factors to within {-1,0,1}, the tree cannot degenerate into linear height, guaranteeing O(log n) height and thus O(log n) search/insert/delete.

Hashing and Hash Based Data StructuresMediumTechnical

23 practiced

Coding (Python): Given an integer array, return all unique pairs of values that sum to a given target. Each pair should be returned as a tuple with smaller value first; pairs should be unique regardless of original indices. Aim for O(n) expected time using hashing and O(n) extra space.

Sample Answer

Approach:Use a single pass with a hash set to record seen numbers. For each number x, check if target - x exists in seen. If so, form a tuple with smaller-first and add to a result set (to ensure uniqueness regardless of indices or duplicates). This is O(n) expected time and O(n) extra space.

python

def unique_pairs_with_sum(nums, target):
    """
    Return all unique pairs (a, b) with a <= b that sum to target.
    Uses hashing: O(n) expected time, O(n) space.
    """
    seen = set()         # numbers we've seen so far
    pairs = set()        # store pairs as tuples (min, max) to ensure uniqueness

    for x in nums:
        y = target - x
        if y in seen:
            a, b = (x, y) if x <= y else (y, x)
            pairs.add((a, b))
        seen.add(x)

    # convert to sorted list if deterministic order is desired
    return list(pairs)

Key points:- Using a set for seen gives expected O(1) lookups.- Storing pairs in a set of tuples ensures uniqueness even with duplicates or different indices.- We normalize pair order by always storing (min, max).

Time Complexity: O(n) expected (single pass, O(1) average lookup).Space Complexity: O(n) for seen and up to O(n) for pairs in worst case.

Edge cases:- Empty array or single element -> returns empty list.- Multiple duplicate values handled correctly (e.g., [2,2,2], target=4 yields (2,2) once).- Large inputs: hashing avoids quadratic behavior.

Alternative:- Sort + two pointers yields O(n log n) time, O(1) extra space (aside from output), useful when memory is constrained.

Clean Code and Best PracticesMediumTechnical

66 practiced

Choose three code-quality metrics to track across a repository (e.g., cyclomatic complexity, comment density, test coverage). For each metric, explain why it matters, how to interpret trends, and pitfalls in relying on it too heavily.

Debugging and Recovery Under PressureEasyTechnical

80 practiced

Compare using print/log statements versus an interactive debugger when debugging under time pressure. Provide scenarios where a quick print or log is preferable (including production constraints), and scenarios where stepping through with a debugger or using a profiler is necessary. Give best practices for writing effective temporary debug logs.

Array and String ManipulationHardSystem Design

55 practiced

Given two very large sorted arrays that cannot both fit in memory (stored on disk), design an efficient algorithm to find the median of the union of the arrays. Discuss I/O costs, streaming approaches, and how to minimize disk seeks. Provide both algorithm outline and complexity considerations.

Sample Answer

Requirements & constraints:- Two very large sorted arrays A (size n) and B (size m) stored on disk; n and m may be >> memory.- Goal: median of A ∪ B (i.e., kth order statistic where k = (n+m+1)/2).- Minimize I/O (sequential reads preferred), minimize disk seeks, low memory.

High-level approach:1. Use a two-way streaming / external-merge style binary-search on the smaller array (external selection by probing blocks).2. Read arrays in large sequential blocks (e.g., pages) to amortize seek cost.3. Find k-th element by partitioning counts rather than merging all elements.

Algorithm outline (external partitioning):- Let k = (n+m+1)/2.- Binary-search i in [max(0, k-m) .. min(k, n)] representing how many from A in left partition.- For candidate i, set j = k - i (from B).- We need to compare A[i-1] and B[j-1] with A[i] and B[j] to check partition validity: - Condition: A[i-1] <= B[j] and B[j-1] <= A[i] (treat boundaries as ±∞).- To evaluate A[i-1], A[i], B[j-1], B[j] we only need to fetch those elements — fetch their blocks from disk into memory (one block read each).- Binary-search requires O(log min(n,m)) iterations => each iteration reads O(1) blocks from each array (worst 4 blocks). Cache recently read blocks to avoid rereads if probes are near.

I/O & disk-seek optimization:- Use large block size (e.g., 4–64MB) to amortize latency; store index of block offsets so you can seek directly.- Prefetch adjacent blocks when a probe lands near a block boundary to avoid repeated small seeks.- Cache hot blocks (L1 in-memory) for binary search locality; binary search probes move roughly halving the range so accesses are scattered but predictable—use an in-memory index of block minima/maxima to avoid reading full blocks when possible.- If arrays are on SSD or distributed storage, seek penalty is smaller; still prefer sequential scans.

Streaming alternative (merge-scan):- If k is large relative to arrays but sequential I/O cheap, perform single-pass external merge until k-th element: sequentially stream blocks from both arrays, merge elements in memory buffer until count k reached. I/O: read ceil(n/B) + ceil(m/B) blocks (full scan) but only sequential reads (lowest seeks). Best when sequential throughput >> random access latency.

Complexity summary:- Binary-search partition approach: - I/O: O(log min(n,m)) random block reads (O(1) blocks per iter). Total bytes = O(block_size * log min(n,m)). - CPU: O(log min(n,m)). - Memory: O(block_size) for buffers and small metadata.- Merge-stream approach: - I/O: O((n+m)/B) sequential block reads (optimal for throughput). - CPU: O(k) comparisons up to k; Memory: O(B) buffers.

Trade-offs & when to use which:- If random seeks are expensive and sequential throughput is high (HDD), prefer merge-scan (sequential full read).- If arrays are extremely large and you must avoid full scans and random reads are acceptable or data indexed by block min/max, use binary-search partitioning (log-time I/O).- Hybrid: use block-level indices (summary per block: min/max, count) to run binary search on summaries, reducing probes; only read full blocks near final partition.

Edge cases:- Unequal sizes, empty array, duplicates — handled by partition boundary rules and sentinel infinities.

Practical notes:- Maintain a small on-disk index (min/max per block) to enable index-only comparisons most of the time.- Tune block size to storage characteristics; use async prefetch and read-ahead to hide latency.

Practice Software Engineer questions across all topics

Additional Information

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse Software Engineer jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs

Google Software Engineer Entry Level (L3) Interview Preparation Guide

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Learning Mindset and Adaptability

Practice Interview

Study Questions

Motivation and Alignment with Google

Practice Interview

Study Questions

Communication and Interpersonal Skills

Practice Interview

Study Questions

Professional Background and Technical Foundation

Practice Interview

Study Questions

Technical Phone Screen

What to Expect

Tips & Advice

Focus Topics

Clean Code and Clear Communication

Practice Interview

Study Questions

Time and Space Complexity Analysis

Practice Interview

Study Questions

Problem Decomposition and Algorithm Development

Practice Interview

Study Questions

Data Structures Fundamentals and Selection

Practice Interview

Study Questions

Arrays and String Problem-Solving

Practice Interview

Study Questions

Onsite Coding Interview 1

What to Expect

Tips & Advice

Focus Topics

Code Organization and Professional Standards

Practice Interview

Study Questions

Solution Testing and Verification

Practice Interview

Study Questions

String Processing and Character-based Problems

Practice Interview

Study Questions

Edge Case Identification and Defensive Coding

Practice Interview

Study Questions

Array Manipulation Techniques and Algorithms

Practice Interview

Study Questions

Onsite Coding Interview 2

What to Expect

Tips & Advice

Focus Topics

Algorithm Selection and Complexity Trade-offs

Practice Interview

Study Questions

Systematic Debugging and Problem-Solving Approach

Practice Interview

Study Questions

Recursion and Backtracking Techniques

Practice Interview

Study Questions

Binary Trees and Tree Traversal Algorithms

Practice Interview

Study Questions

Graph Representation and Graph Algorithms

Practice Interview

Study Questions

Onsite Coding Interview 3

What to Expect

Tips & Advice

Focus Topics