Recently, I accompanied my classmates to finish brushing ZipRecruiter 2026 New Grad OA, this set of questions can be said to be representative of the "moderately easy but very test details".
The questions do not roll in algorithms, but center on design and implementation skills - especially class design, interface consistency, and boundary conditions for updating data structures. It is divided into four Levels, each of which builds on the previous one, with smooth difficulty but lots of pitfalls.
Level 1 - Basic CRUD
Problem.
Implement an in-memory database that supports three operations. set, get, and delete.
Each key represents a dictionary, and each field name within it must be unique.
Example.
set("user1", "name", "Alice")
get("user1", "name") -> "Alice"
delete("user1", "name") -> True
Idea:
This level is a warm-up question, testing basic data structure manipulation. It can be done directly with nested dict Realization:
db[key][field] = value
Operational Logic:
set(): initialized if key does not exist;get(): Returns not foundNone.;delete(): Returns True for successful deletion, otherwise False.
Although the topic is simple, the details must be clean, such as key You can't just throw an exception when it doesn't exist.
Level 2 - Scanning & Prefix Filtering
Problem.
Extend the database to support field scanning and prefix-based filtering.
scan(key)→ Return all fields under the given key, sorted lexicographically.scan_by_prefix(key, prefix)→ Return only fields that start with the given prefix.
Output format.
["field1(value1)","field2(value2)"]
Idea:
This level tests traversal, filtering and output formatting capabilities.
This can be implemented using Python's list derivation style:
fields = sorted(db[key].items())
res = [f"{f}({v})" for f, v in fields if f.startswith(prefix)]
Attention:
- Returns if key does not exist
[]rather thanNone.; - The output order should be dictionary-ordered;
- Prefix matching is case sensitive.
There's not much of an algorithm for this level, but a single wrongly formatted bracket will result in a fail.
Level 3 - TTL Management
Problem.
Add timestamp and TTL (Time To Live) to each field.
A field becomes invalid when timestamp >= start + ttl.
The database must auto-clean expired fields before each operation.
Example.
set_at_with_ttl("user1", "session", "abc", start=100, ttl=10)
get_at("user1", "session", timestamp=105) -> "abc"
get_at("user1", "session", timestamp=111) -> None # expired
Idea:
This level is the key to the entire OA suite, looking at time-state synchronization.
The data structure can be designed like this:
db[key][field] = {"val": v, "start": t, "ttl": ttl}
Achieving focus:
- The cleanup function: Clear expired fields before each operation;
- get_at(): Determines if the field is still valid;
- delete_at(): Cleanup logic is also called before deletion.
TTL is a source of "dynamism" for the entire system, and many people tend to overlook the need for cleanup during delete operations, leading to inconsistent test results.
Level 4 - Backup & Restore
Problem.
Implement backup and restore functionality for the database.
backup(t)→ Save the current state at timeT.restore(t_backup, t_now)→ Restore the database to a previous state, but TTL must recalculate based ont_now.
Idea:
This is the most systematically designed level, focusing on state replication and time offset adjustment.
Snapshot mechanism:
snapshots[t] = deepcopy(db)
snapshots[t] = deepcopy(db)
Recovery Logic:
Rebuilds the current db from a snapshot;
Recalculate the TTL remaining time;
Perform cleanup on fields that have expired.
The biggest pitfall is that the TTL can not be directly copied, must be dynamically adjusted according to the recovery time t_now, otherwise there will be "expired field resurrection" bug.
Overall impression
ZipRecruiter This OA is very layered:
- From basic CRUD to system-level Backup;
- Each level simulates a core module from a real project;
- It is not difficult, but the realization must be "clean".
It's one of those questions where you can clearly feel an improvement in your code design skills after doing it.
It's more like a "mini-system design" exercise than a pure brush-up.
Recommendations and review
If you prepare similar OA (e.g. ZipRecruiter, Robinhood, DoorDash, Dropbox), it is recommended:
- Practice class design + state update questions;
- Familiar with temporal logic and TTL-type cache;
- Keep the code structure clean and the interfaces consistent;
- The output and boundary conditions should meet the strict requirements of the test.
This type of OA is more interested in your "code engineering sense" - stable, logical and error-free boundaries are a win.
Programhelp - No trace of remote assistance, so that you can efficiently through the OA
In this ZipRecruiter OA, many students reflected that the questions are not difficult in terms of logic, but there are too many implementation details, and the debug session is very easy to get stuck in time. Especially in questions like TTL management and Backup recovery, timeout or logic will be missed if you are not careful.
Our team will provide no-latency voice assistance + on-line real-time thought prompts to help trainees quickly sort out the implementation structure and edge cases when they are stuck, so that they don't need to struggle on their own.
All operations are done locally to you, seamlessly, securely, and without leaving any trace of collaboration, while also training clear thinking about code organization.
Over the past few months, we have worked with students on a variety of projects including ZipRecruiter, Dropbox, DoorDash, Meta Infra, Stripe The average pass rate for system-implemented OA, including etc., far exceeds that of self-practice.
If you're also about to brush up on your OA, or aren't sure if your realization details are solid, you can learn about our Remote Practice Assist program -- simulating the pace of a full-fledged exam, with live voice guidance, all at once.
