Continued from Part 2 of this three-part roundup. This final section covers firsthand reports 29–42, then turns the full evidence set into a preparation order.

Coverage in this part: Google SWE/SDE Intern and PhD SWE Intern; live technical screens and virtual onsites; reports from January through March 2026.

Detailed candidate timelines, continued

29: A standard 45-minute screen with two graph-array staples

Report date: January 19, 2026 · Role: SWE Intern · Result: No offer

The candidate described a short introduction and resume discussion, followed by live LeetCode work and time for questions. The named tasks were Two Sum and Number of Connected Components in an Undirected Graph. The format was ordinary; the expectation was still to explain and implement under a 45-minute clock.

30: Research conversation, graph reachability, and sampling

Report date: January 27, 2026 · Role: PhD SWE Intern · Result: Passed to team matching

One interviewer spent roughly 20 minutes discussing the candidate's research before coding. The first preserved task, Directed Graph Reachability Queries, built relationship adjacency lists and used BFS, followed by several extensions. The second was remembered only as an applied sampling program; Reservoir Sampling With Recorded Draws is therefore openly labeled as a reconstruction.

The candidate later spoke with two teams and matched with an Ads AI group working on reinforcement-learning research.

31: Cyclic-day servers and delete-one pivot logic

Report date: February 1, 2026 · Role: SWE Intern · Level: Master's · Result: No offer

Round one asked Minimum Servers for Cyclic Daily Tasks: tasks start within a 24-hour cycle and may cross midnight. Round two asked Pivot Index After Exactly One Removal. The candidate solved the first smoothly, but reached only brute force plus a verbal optimization on the second.

32: Meeting rooms plus an unidentified recursion/DP string task

Report date: February 2, 2026 · Role: SDE Intern · Level: Master's

Two back-to-back rounds contained no behavioral questions. One task was described as Meeting Rooms II. The other was only identified as string processing solvable with recursion or DP, so Minimum Dictionary Segments is clearly marked as a reconstructed practice version rather than the exact interview question.

33: Binary search, hashing, and two pointers

Report date: February 2, 2026 · Role: Software Engineer Intern · Location: Bucharest · Result: No offer

The candidate had two back-to-back 45-minute DSA interviews around LeetCode medium difficulty. One round used binary search and explicitly named Find Minimum in a Rotated Sorted Array; the other used hashing and two pointers but did not preserve a full task.

34: Two hybrid questions rather than textbook copies

Report date: February 6, 2026 · Role: PhD SWE Intern

The first round combined the recognizable ideas behind Top K Frequent Elements and K Closest Points in Top K Frequent Closest Points. The second became Closest-Timestamp Key-Value Queries, combining a time-based key-value store with nearest-timestamp lookup. The candidate used straightforward approaches and discussed complexity and possible improvements with the interviewers.

35: A second candidate settles an edge case

Report date: February 7, 2026 · Role: Software Engineer Intern · Result: No offer

This independent report restated Maximum Subarray Sum With Equal Endpoints precisely and confirmed that i <= j, so a single-element subarray is legal. That detail matters for all-negative arrays and corrected an ambiguity in the earlier report.

36: PhD loop with an interviewer-authored grid problem

Report date: February 8, 2026 · Role: PhD SWE Intern

The second of two back-to-back interviews was identified and confirmed as Find the Safest Path in a Grid. The first problem remained hidden. The author emphasized that the questions did not feel copied directly from LeetCode, even when a familiar underlying problem could later be recognized.

37: House Robber reconstruction and simultaneous-time propagation

Report date: February 14, 2026 · Role: PhD SWE Intern · Format: Two 45-minute rounds

1. House Robber With Selected Indices, which extends the usual score-only problem by returning one optimal index set.
2. Find All People With the Secret, where meetings sharing a timestamp must be processed as a group.

The candidate completed the first, but got stuck on equal-time grouping in the second and discussed union-find or graph traversal after asking for a hint.

38: Directed-cycle detection after an OA

Report date: February 17, 2026 · Role: SWE Intern · Location: Hyderabad · Result: No offer

The process consisted of an OA and two Google Meet technical rounds. The preserved question, Course Schedule Cycle Detection, used directed-cycle detection to decide whether a course schedule is valid. The candidate highlighted code clarity, efficiency, edge cases, and optimization—not just reaching a yes/no answer.

39: FIFO matching with partial fills

Report date: February 18, 2026 · Role: SWE Intern · Location: Boston office · Result: No offer

FizzBuzz FIFO Market Matching processed prioritized Fizz and Buzz offers. Opposite types matched FIFO, partial quantities carried forward, and repeated participant pairs had to be aggregated in the output. This is a state-machine question disguised as a playful market story; careful bookkeeping matters more than an exotic algorithm.

40: Maximize the retained k digits

Report date: February 2026 · Role: SWE Intern

The candidate received Largest K-Digit Subsequence, a stack/greedy variation of Remove K Digits: retain the largest possible subsequence of exactly k digits while preserving relative order. The central invariant is a decreasing stack with enough remaining digits to fill the answer.

41: Streams, distinctness, and weighted random output

Report date: February 28, 2026 · Role: PhD SWE Intern

The first family became Select First or Last K Stream Words, progressing from a list to a stream and then to distinct words in a stream. The second became Frequency-Weighted Next-Word Sampling: build successor frequencies from training sequences, sample in proportion to observed counts, and discuss what to do when one word has many possible successors.

This report is a good model for progressive follow-ups: the base data structure stays recognizable while memory, order, and scale change.

42: Every long subsequence must be a word

Report date: February 28, 2026 · Role: SWE Intern · Level: Bachelor's · Location: Shanghai

The first question, All Long Subsequences Are Dictionary Words, asked whether every subsequence of length at least three is a valid English word. The follow-up allowed each subsequence to be rearranged before checking the dictionary and therefore required character-frequency reasoning. The source used an abstract English dictionary; the practice version supplies a finite dictionary so the task is executable.

What repeated often enough to prioritize

Tier 1: Practice until automatic

1. Graph traversal and connected components. Be able to choose among BFS, DFS, DSU, topological sorting, and shortest path from the contract—not from a keyword. Practice ordinary graphs, grids, and equal-timestamp subgraphs.
2. Hash-map invariants. Several tasks become simple only after rewriting a relation or defining the correct key: equal value-offset pairs, distinct contacts, word frequencies, tag matching, timestamped values, and first-unique events.
3. Heaps and ordered state. Prepare k-th largest, top-k ranking, interval/resource allocation, FIFO matching, and active-job tracking. Know what must be removed lazily and what must remain stable under ties.
4. One-dimensional DP and greedy reconstruction. House Robber, digit subsequences, parity-run states, array modification, and interval allocation all reward a small, explicit state definition.
5. Complexity plus a manual dry run. Multiple candidates solved the core idea but lost time or confidence on implementation, edge cases, or an incorrect dry-run variable. Rehearse the final five minutes, not only the first thirty.

Tier 2: Be ready to explain deeply

1. Why your data structure matches the update pattern. Explain why a heap, deque, map, sorted order, or DSU supports the required operations and what changes under streaming or memory limits.
2. Boundary semantics. Ask whether intervals are closed or half-open, whether positions must be contiguous, whether duplicate values are distinct items, how ties break, and whether time wraps across midnight.
3. From brute force to the invariant. Several interviews accepted a brute-force starting point, then expected a clear route to the optimized solution. State what repeated work you are eliminating.
4. Recovering from ambiguity. The reports include long stories, interviewer-authored variants, and examples that were occasionally inconsistent. Restate the contract, test it against the sample, and surface contradictions politely.
5. Coding without execution. Practice in a plain document. Trace indexes, heap contents, recursion bases, and output order aloud because the compiler will not rescue an unclear invariant.

Tier 3: Higher-level differentiators

1. Model follow-ups as controlled contract changes. Return selected indices instead of only a score, support a stream instead of a list, handle limited memory, group simultaneous events, or add weighted sampling without rewriting everything.
2. Separate algorithmic correctness from product behavior. Currency arbitrage, market matching, caller activity, and calendar layout all ask what an apparently real system should do in edge cases.
3. For PhD candidates, bridge research and implementation. Be ready to explain your work plainly, then switch quickly into ordinary coding. Research fit may matter later in team matching, but it did not replace the technical bar in these reports.
4. Treat team matching as its own conversation. Prepare concise project stories, technical interests, location constraints, and questions about the host team's work. Passing coding was necessary, but several accounts show it was not always the final step.

Final checklist

OA

☐ Solve two medium problems back-to-back under a 60–90 minute total clock.

☐ Recheck whether an operation affects arbitrary elements or one contiguous range.

☐ Test modulo arithmetic, duplicate values, impossible cases, and the smallest valid input.

Graphs and trees

☐ Implement BFS, iterative and recursive DFS, DSU, topological sort, and Dijkstra without an IDE.

☐ Explain cycle-state coloring, disconnected components, simultaneous-event grouping, and grid-neighbor rules.

☐ Practice one tree DP and one tree transformation where output structure—not only a number—matters.

Arrays, strings, and DP

☐ Derive hash keys from an equation instead of comparing every pair.

☐ Practice monotonic stacks, binary search on the answer, interval sweeps, prefix sums, and reconstruction from DP choices.

☐ State duplicate handling, stable ordering, tie rules, and whether empty or singleton selections are legal.

Heaps, streams, and scheduling

☐ Maintain top-k, k-th largest, first-unique, timestamp lookup, and active intervals under updates.

☐ Explain memory-limited alternatives such as sorting, two pointers, batching, or external state.

☐ Dry-run partial fills, carry-over quantities, midnight wraparound, and equal start/end timestamps.

Interview execution

☐ Spend the first minutes clarifying the contract and creating one ordinary plus one adversarial example.

☐ Say the brute-force complexity before optimizing, then name the repeated work your invariant removes.

☐ Leave five minutes for a manual trace, null/empty cases, overflow, and a concise complexity summary.

☐ Prepare a two-minute project explanation and, for PhD roles, one plain-language research summary.

This series starts with Part 1, which covers the scope, four OA reports, and experiences 05–12. Part 2 continues with experiences 13–28. Across all three parts, each of the 59 FastPrep practice links appears beside the report that produced it.

Sources are from anywher useful interview info can be found oneline. Happy prep!