2025–2026 ZipHQ Software Engineering OA / Interviews: 31 Experiences (Part 2 :)

Continued from Part 1.

Experiences 1–31

01: Graph pursuit in the first round

Report date: September 2026 · Role: Software Engineer · Stage: Technical screen · Result: Rejected

The interviewer described the core of Maximum Survival Time in a Graph Pursuit: Tom and Jerry moving through an undirected room graph. Each player could move to an adjacent room or stay put, with Jerry moving first. The candidate struggled until the interviewer suggested comparing shortest-path distances from both starting points. Comments debated DFS on trees versus BFS on general graphs and whether cycles changed the reasoning.

02: Ticket cache practical, then an underspecified AI round

Report date: September 2026 · Role: Software Engineer · Stage: Virtual onsite · Result: Rejected

The practical task behind Cache Ticket Alerts for Approval added alert-count caching to ticket approval, rejected a ticket after repeated alerts, and then changed alert severity in a follow-up. A separate AI round asked the candidate to debug a repository and implement a feature, but the report did not preserve the repository, defect, requested behavior, or tests. Later rounds were cancelled.

03: A new screen called “Catch Me If You Can”

Report date: July 2026 · Role: Software Engineer · Stage: Technical screen · Result: Rejected

A recruiter reached out, then the first coding round used a problem the candidate had not seen in earlier Zip posts. The original report only linked the title and said the interviewer eventually explained the solution. Without the rules, input, or examples, the honest takeaway is that Zip can rotate in unseen graph or game problems; assigning it a reconstructed prompt would be guesswork.

04: Debug the LRU cache instead of implementing one

Report date: July 2026 · Role: Backend Software Engineer · Stage: Technical screen · Status: Waitlisted

The candidate received a Java LRU cache backed by an insertion-order LinkedHashMap. A successful get and every put were supposed to refresh recency, while eviction had to remove the least-recently-used item. The supplied code failed to refresh an updated key and removed the newest entry during eviction. The bonus was one failing test per independent bug. This was a normal interview question, not the larger repository practical.

05: Cards first, AST codebase second

Report date: April 2026 · Role: Software Engineer · Stage: Two phone screens · Status: Advanced to VO

The first screen generated every valid card combination under limited card counts; the candidate noted that the finite deck made some combination types safe to hard-code. The second screen dropped the candidate into a multi-file AST/Composition codebase and asked for condition logic plus tests. Reading the repository consumed more time than the feature itself, and the candidate did not finish every part.

06: Vending machine with three staged parts

Report date: March 2026 · Role: Software Engineer · Stage: Technical screen · Result: Passed

Starter code was provided. The candidate implemented bill insertion, product vending, change-making, and related state behavior across three progressive parts. They also had to write their own tests. The interviewer gave hints, and the candidate described the task as manageable rather than algorithmically hard.

07: New-grad BFS with moving parades

Report date: March 2026 · Role: New Grad Software Engineer · Stage: Technical screen · Result: Rejected

Part 1 of Shortest Path Around Moving Parades was ordinary shortest-path BFS from a start to a destination around static barriers, returning a valid path rather than only a distance. Part 2 added directional parades that moved once every two seconds, so the search state needed time as well as position. The candidate also had to prevent infinite search when the destination was permanently enclosed.

08: Senior loop from phone screens through team match

Report date: February 2026 · Role: Senior Software Engineer · Stage: Phone screens + onsite · Result: Passed

The algorithm screen started with dictionary value conversion, then added nested recursion, multiword phrases, and maximizing covered words with trie-like matching. The practical used the Condition/Question codebase. The onsite added Maximum Nonadjacent Sum in a General Tree, order-versus-inventory consistency under timeouts and races, and a director project deep dive covering role, scale, and impact. The candidate reached team match and felt the loop was closer to daily engineering than isolated puzzles.

09: Ninety-minute OA with four progressive questions

Report date: January 2026 · Role: Software Engineer · Stage: OA · Result: Rejected

The OA contained four questions that increased in complexity. The first two felt simple, although the second still consumed meaningful time. Four tests remained failing on the final question, and the rejection arrived two days later. The report did not preserve the problem domains, so it should not be merged with the database OA merely because the format looks similar.

10: House Robber III, but N-ary

Report date: December 2025 · Role: Software Engineer · Stage: First technical screen · Status: Not disclosed

The core of Maximum Nonadjacent Sum in a General Tree turned the familiar binary-tree problem into a general tree, and the candidate also had to construct the tree representation. They understood the problem family but could not get the implementation running within the interview. The interviewer was friendly and answered questions about the work.

11: Zip Rummy and the cost of small mistakes

Report date: December 2025 · Role: Software Engineer · Stage: Technical screen · Result: Rejected

In Find All Zip Rummy Melds, the candidate received a 10-card hand from a 36-card deck with ranks 1–9 and four suits. They had to enumerate every same-rank set and every same-suit consecutive run of length at least three, including shorter melds contained in longer ones. The algorithm felt reasonable, but deterministic ordering and small implementation traps made a perfect solution difficult under the time limit.

12: New-grad screen plus a three-round VO

Report date: November 2025 · Role: New Grad Software Engineer · Stage: Full loop · Result: Rejected

The phone screen maximized the number of words covered or saved by shared phrases, with prefix-tree reasoning. The VO combined a Question/Answer/Condition practical, poker runs-and-sets enumeration, and a hiring-manager project deep dive. The candidate completed most of the work but was rejected after the two-day loop.

13: Roots, components, and many-to-many parents

Report date: November 2025 · Role: New Grad Software Engineer · Stage: Technical screen · Status: Waitlisted

The base problem used parent relationships to identify roots and traverse the structure. Follow-ups introduced multiple roots and then many-to-many parent relationships. The public report did not preserve a full callable signature, examples, or output format, so the representation should be clarified before coding.

14: Open the Lock with path reconstruction

Report date: November 2025 · Role: Software Engineer · Stage: Technical screen · Result: Passed

The candidate quickly solved Open the Lock with BFS. The follow-up returned one actual sequence of lock states rather than only the number of turns. The remaining time became an informal conversation, and the next round was described as a practical repository task.

15: Infinite-grid taxi route under a moving blockade

Report date: October 2025 · Role: Software Engineer · Stage: Phone screen · Result: Rejected

Shortest Path Around Moving Parades begins with a taxi moving on an integer grid around static blocked intersections. Part 1 required a shortest direction string and minimum travel time. Part 2 introduced a semi-infinite parade line whose head advanced after every two taxi moves; the taxi could not enter a cell blocked at its arrival time. The candidate spent nearly all available time on Part 1 and did not finish Part 2.

16: Mahjong winning draws

Report date: September 2025 · Role: Software Engineer · Stage: Technical screen · Result: Rejected

Winning Draws for a Mahjong Hand asks for every extra rank that turns 13 ranks from 1 through 9 into a winning 14-tile hand with four three-tile groups and one pair. Groups may be equal-rank triplets or consecutive runs, every tile must be used, and no rank may exceed four physical copies. The author warned that calling it a poker problem hides the real Mahjong decomposition structure.

17: Add one field type to an existing form system

Report date: September 2025 · Role: Software Engineer · Stage: Second phone screen · Result: Rejected

The candidate had already passed a DSA screen. In the practical round, they added one new field type and tests to an existing form repository. Older tests covered existing features. The new feature worked, but the candidate felt the code needed refactoring and only had time to explain that refactor verbally.

18: Full-stack onsite with React, Python, cards, and deep dive

Report date: September 2025 · Role: Full-stack Software Engineer · Stage: Phone + onsite · Result: Rejected

The loop mixed React/Python integration, basic request handling and fetch, a card-hand combination problem, and a project deep dive. Syntax search was allowed, but rusty integration work still cost time. The card task involved a straight plus a pair, although the report no longer preserved a complete contract.

19: Tree-DP recovery after a wrong start

Report date: September 2025 · Role: Software Engineer · Stage: First technical screen · Result: Passed

The candidate initially misunderstood the House Robber III variant, then pivoted after an interviewer hint and passed all tests. Follow-ups asked about a disconnected forest and multiple parents. The candidate credited active clarification and continuous communication for recovering the round.

20: Toronto recruiter screen that moved quickly

Report date: August 2025 · Role: Software Engineer · Stage: Recruiter screen · Result: Passed

The call covered company context, the candidate's background, and the Toronto opportunity. A next-round email arrived within about 30 minutes and described a typical algorithm question. No technical prompt appeared in this report.

21: Recruiter said “move forward,” then rejected

Report date: August 2025 · Role: Software Engineer · Stage: Recruiter screen · Result: Rejected

The recruiter asked for the candidate's journey, work history, promotion history, and motivation but did little follow-up. The candidate asked about the process and believed they were advancing, then received a rejection the following day. This report is useful as process evidence, not technical-question evidence.

22: Practical passed, tree round sank the onsite

Report dates: July–August 2025 · Role: Software Engineer · Stage: Practical + onsite · Result: Rejected

The same candidate described the application in two posts. In the practical, they extended Question, Answer, Condition, and ConditionalCheck models, added a question type and new comparison, wrote tests, and then discussed combining many questions with AND/OR logic. They used Python, while another batch's email specified Java. The later technical round matched the core of Maximum Nonadjacent Sum in a General Tree; the candidate rewrote a flawed solution but still received negative execution feedback. The hiring-manager deep dive felt strong, making the technical miss more visible.

23: Block roots and paths

Report date: August 2025 · Role: Software Engineer · Stage: Technical screen · Status: Waitlisted

Blocks were represented as strings or JSON with an ID and optional parent ID. The base task found all root IDs. The follow-up produced paths from roots through the structure. The report did not settle whether a missing parent was null, absent, or another sentinel.

24: Cloud-storage OA

Report date: July 2025 · Role: Backend Software Engineer · Stage: OA · Status: Waitlisted

The 90-minute exercise unlocked four levels in order. Level 1 added, inspected, and deleted files. Level 2 ranked the largest files under a prefix. Level 3 introduced users, storage capacities, per-user file creation, and user merging. Level 4 backed up and restored one user's file state. The source used screenshots, so exact signatures were not equally legible, but the state progression was clear.

25: Database OA stopped after Level 3

Report date: July 2025 · Role: Backend Software Engineer · Stage: OA · Result: Rejected

The candidate completed basic field operations, filtered scans, and TTL expiration but did not finish historical look-back queries. A 750/1000 score was not enough to advance. In-Memory Database with TTL and Historical Queries preserves the full four-level progression and makes the version-history trap explicit.

26: Passed phone screen, but the post only says “same as before”

Report date: July 2025 · Role: Software Engineer · Stage: Technical screen · Result: Passed

The candidate said the question was an earlier forum problem and useful as a warm-up, but did not identify which one. It should remain process evidence rather than being assigned to a popular Zip question by guesswork.

27: Dictionary conversion with three follow-ups

Report date: July 2025 · Role: Software Engineer · Stage: Technical screen · Result: Passed

The base task validated and converted dictionary values. Follow-up 1 recursed into nested dictionaries. Follow-up 2 memoized identical expensive conversions. Follow-up 3 reused converted tokens or phrases inside longer strings while reducing converter calls. The candidate lost time on an all-substrings idea and did not finish the final optimization cleanly.

28: Another Open the Lock occurrence

Report date: May 2025 · Role: Software Engineer · Stage: Technical round · Result: Rejected

A recruiter contacted the candidate through LinkedIn. The coding problem used a starting combination, blocked states, and target 0202, matching Open the Lock. The public report did not preserve a distinct follow-up.

29: Furthest Building plus a trace of every decision

Report date: March 2025 · Role: Software Engineer · Stage: Technical screen · Result: Passed

The base task was Furthest Building with Sandbags and Ropes. The follow-up required the concrete resource choice at each climb, not only the furthest index. The linked practice covers the base result; add path/resource reconstruction to match the interview follow-up.

30: AST practical plus tree DP in the VO

Report date: March 2025 · Role: Software Engineer · Stage: Virtual onsite · Result: Rejected

One round used a Zip-owned AST codebase. The candidate had not encountered the term before and could not reconstruct the exact functions afterward. The algorithm round matched Maximum Nonadjacent Sum in a General Tree, with a follow-up across multiple roots.

31: Furthest Building as a recurring warm-up

Report date: March 2025 · Role: Software Engineer · Stage: Technical screen · Result: Passed

The candidate recognized the heap pattern from Furthest Building with Sandbags and Ropes and described the base round as straightforward. The follow-up again asked for the exact bricks-versus-ladder assignment across the chosen route, confirming that path reconstruction was not a one-off detail.