Based on 19 candidate reports from July through September 2026.

Coverage: Airbnb SWE and senior software roles; mostly full-time CodeSignal OAs.

For Jyothi.

The main thing to know is that recent candidates did not describe a normal set of unrelated LeetCode questions. Most received one small system that grew through four levels. Across the 19 reports, at least seven used banking or credit-ledger logic and five used file or cloud-storage logic. The rest covered tasks, workers, recipes, and parcel events.

Candidates mentioned

1. Expect one codebase with four levels. You usually receive an interface, starter code, and unit tests. The next level opens only after the current level passes.

2. The algorithms are not the hardest part. The real challenge is keeping your state correct while adding timestamps, expiration, scheduled events, user limits, history, merging, or backup and restore.

3. Small details matter a lot. Return values, sorting rules, tie-breakers, time intervals, and the order of events caused many failed tests. (candidates said)

4. A perfect score does not guarantee an interview. Several candidates reported finishing everything and still receiving a rejection or no follow-up.

A practical prep formula: do a few full 90-minute progressive problems, keep one clear source of truth for your data, and rerun old tests after every new feature.

The 19 reports

These were not 19 copies of one leaked question. The names changed, but the same engineering pattern kept coming back. Two of the posts were short follow-ups that confirmed an earlier prompt; I kept them because they were independent sittings.

01: Banking, scheduled payments, and account merges

Report date: September 24, 2026 · Result: Not disclosed

The candidate received the Progressive Banking System. Level 1 covered account creation, deposits, and transfers. Level 2 added top-spender ranking. Level 3 added scheduled payments and strict timestamp order. Level 4 merged accounts while keeping balances and transaction history.

The candidate did not finish Level 3 and reported a score of 440. Their main warning was that due payments may need to run before every later operation.

02: Banking with offline and deletable transfers

Report date: September 22, 2026 · Result: Not disclosed

This candidate's Progressive Banking System version asked for user creation, regular transfers, offline transfers, and deleting a pending transfer. The transfer state became much harder from Level 3 onward.

They also warned about the CodeSignal layout: clicking the wrong file could move them into a test or interface file, so it was worth learning the editor before the real attempt.

03: Cloud storage with compression

Report date: September 8, 2026 · Result: Rejected after one week

The In-Memory File System grew through four levels:

1. add, retrieve, and copy files;
2. search files by prefix and suffix;
3. add users with different storage limits;
4. compress and decompress files.

The candidate used Python, finished all four levels in about 40 minutes of a 90-minute test, and received a full score. They later received a rejection. They also said their sitting required the camera.

04: Cloud storage with backup and restore

Report date: August 28, 2026 · Result: Rejected the next day

The Cloud Storage with User Backup and Restore prompt started with file add, delete, and lookup. Level 2 returned the largest files for a prefix, sorting equal sizes by name. Level 3 added users, storage capacity, and user merging. Level 4 added backup and restore, including skipping a restored file when another user already owned that name.

The candidate finished with a full score. Their practical advice was to keep the early data model together, because Level 3 and Level 4 touch almost every earlier operation.

05: Record store with prefix scan and TTL

Report date: August 28, 2026 · Result: Passed

The In-Memory Database was a nested hash-map problem. Each object had fields and values.

• Level 1: set, get, and delete fields and objects.
• Level 2: scan fields by prefix.
• Level 3: add timestamps and TTL, then ignore or clean expired fields.

The candidate described it as detailed but not algorithmically hard. They had 90 minutes and felt the time was reasonable. Their main edge case was making sure a field shorter than the prefix did not match.

06: Full cloud-storage backup prompt

Report date: August 26, 2026 · Result: No follow-up at the time of the post

This report preserved the most complete Cloud Storage with User Backup and Restore prompt: file add/get/delete, top-N file ranking, users with capacity, merging users, taking a snapshot, restoring the latest snapshot, and resolving name conflicts.

The candidate said they earned a full score but had not heard back when they updated the post.

07: Banking system with unit tests

Report date: August 23, 2026 · Status: Waiting

The candidate stressed that the Progressive Banking System was not a group of separate LeetCode questions. It was one codebase with four test-gated levels.

They described the same banking path in detail: balances, outgoing totals and tie-breaking, scheduled-payment state, then account merging and history. Their suggested design was one central account state plus a shared function that processes due payments.

08: Workspace credits and delayed cashback

Report date: August 22, 2026 · Status: Waiting

The Workspace Credit Ledger used workspaces and credits instead of bank accounts.

• Level 1: create workspaces, add credits, and transfer credits.
• Level 2: rank workspaces by credits spent.
• Level 3: spending produced a 2% rebate exactly 24 hours later, with transaction-status lookup.
• Level 4: merge workspaces and answer historical-balance queries.

The candidate did not finish Level 4.

09: Same banking prompt, difficult editor experience

Report date: August 21, 2026 · Result: Not disclosed

This candidate said their question matched the same Progressive Banking System reported on July 31. They did not finish it. Their post focused on the editor: red error marks and broken completion made it harder to type the supplied APIs quickly.

This was a short report, but it independently confirms the repeated banking prompt and the value of trying CodeSignal's practice workspace first.

10: Cloud backup with an admin edge case

Report date: August 20, 2026 · Result: Not disclosed

The candidate saw the Cloud Storage with User Backup and Restore: file operations, top-N files by prefix, users and capacity, merging, then backup and restore. They said the general structure matched other storage reports.

Their final two failing tests involved backup and restore for the built-in admin user. That is a useful reminder that system users may follow different capacity rules while still needing the same backup behavior.

11: In-memory file system with user capacity

Report date: August 18, 2026 · Result: Not disclosed

This In-Memory File System version included file add and copy, prefix-and-suffix search, users with capacity, and compression/decompression.

The candidate finished Level 3 but ran out of time on Level 4. Their design had to track file owner, stored size, original size, and consumed capacity. They noted that a Level 3 change could break copy behavior written in Level 2.

12: Repeated banking variant with platform errors

Report date: August 18, 2026 · Result: Failed

The candidate said their prompt used a different story but almost the same operations as the published Progressive Banking System. They found the problem itself manageable, but the assessment page repeatedly showed errors and felt hard to navigate.

The post did not preserve the full interfaces, so it supports the repeat pattern and platform advice, not a new exact question.

13: A second Working Hours Register sighting

Report date: August 17, 2026 · Status: Waiting

This was a short independent report that pointed to the July 26 Worker Management with Full-Shift Double Pay as the same prompt. It did not add new rules, but it confirms that the worker-hours question appeared more than once.

14: Task management with quotas and overdue work

Report date: August 7, 2026 · Result: Not disclosed

The Task Management System was one of the most detailed reports.

• Level 1: create, update, and read tasks with sequential IDs.
• Level 2: search by case-sensitive name substring and sort by priority, then creation order.
• Level 3: add users, quotas, assignments, finish times, and automatic expiration.
• Level 4: complete an active assignment and list assignments that expired unfinished.

The important design change was to stop deleting expired assignments. Level 4 still needed them for overdue history, so an append-only assignment list with status flags worked better.

15: Banking system with historical balance

Report date: July 31, 2026 · Result: Not disclosed

In the Progressive Banking System, the candidate implemented account creation, deposits, transfers, top spenders, scheduled payments, cancellation, account merging, and balance-at-time queries.

They finished most of Level 4 but had a few tests failing when time ran out. Their main fix was a shared settlement function called before earlier operations so scheduled payments could affect balances and spending totals correctly.

16: Recipe management system

Report date: July 29, 2026 · Result: Rejected on August 5

The Recipe Management System used a different shell from the banking and storage pool.

• Level 1: recipe CRUD with case-insensitive unique names.
• Level 2: search by ingredient and list recipes with exact sorting rules.
• Level 3: add users and let valid users edit recipes while keeping name uniqueness.

The candidate passed two levels, wrote Level 3, but still had failing tests and never unlocked Level 4. They said debugging took too much of the clock.

17: Parcel event tracking from assessment images

Report date: July 27, 2026 · Result: Not disclosed

The candidate shared assessment images for Parcel Event Tracking, a progressive parcel system.

Level 1 recorded event counts per parcel, read a count, and removed an event. Level 2 ranked parcels by event count. Level 3 added courier assignment and courier-specific events. Level 4 added undoing courier changes and courier sign-out.

Only Level 1's exact rules were fully visible, so the later levels should be treated as a roadmap rather than a complete prompt.

18: Working Hours Register

Report date: July 26, 2026 · Result: Not disclosed

This was a 90-minute, four-level Worker Management with Full-Shift Double Pay system.

1. Add workers, record entry and exit, and total completed work time.
2. Return the top workers by completed time.
3. Apply promotions on a future entry and calculate salary using the rate attached to each work session.
4. Double the pay only when a full shift fell inside an approved bonus period.

The candidate confirmed that an interface and sample-style tests were provided.

19: Progressive task database for a senior role

Report date: July 21, 2026 · Result: Not disclosed

The original post described a four-level Task Management System and said time was very tight. A candidate in the same thread supplied a richer version they received:

• task CRUD;
• sorting by priority and timestamp;
• users with assignment quotas and task expiration;
• historical lookup of assigned-task counts.

The linked practice page covers the same task family, but this report adds multi-user assignment and historical assigned-count behavior that the current page does not fully cover. Several people in the thread reported finishing only two or three levels. The clearest lesson was to reuse earlier methods and check old behavior whenever a later level failed.

1. Read time rules twice. Check whether an interval includes its ending timestamp and whether scheduled work happens before or after the current request.

2. Keep old tests green. After every new level, rerun earlier tests. A Level 3 change often breaks Level 1 or Level 2.

3. Match the exact output. A correct idea can still fail because of ordering, capitalization, spacing, or the wrong empty value.

4. Do not chase unnecessary optimization. Recent prompts often accepted a direct scan and sort. Correct state and correct behavior matter more.

What repeated often enough to prioritize

Tier 1: Practice until automatic

1. Four-level stateful programs built on hash maps or small domain objects.
2. Adding a new feature without breaking earlier tests.
3. Exact sorting, tie-breaking, return values, and failure behavior.

Tier 2: Be ready to handle carefully

1. Scheduled events, TTL, expiration, and half-open time intervals.
2. Ownership, capacity, merging, backup, restore, and historical queries.
3. A single helper for rules that must run before many operations.

Tier 3: Useful differentiators

1. Finishing Level 4 without rewriting the whole design.
2. Staying calm when the editor or autocomplete behaves badly.
3. Knowing when a direct scan and sort is enough instead of building an unnecessary complex solution.

Good luck on your assessment! 🫶