HackTheRounds Interview Experiences

SIG Software Engineer Interview Experience (2026) - CodeSignal OA with Drone Delivery & Password Splicing, Offer

Susquehanna SIG 2026 SDE CodeSignal OA walkthrough: cumulative visits target, drone delivery simulation, distribution center circular scheduling, password fragm

By Anonymous · 2026-03-22

Background

Just cleared Susquehanna International Group's 2026 SDE CodeSignal OA and wanted to write the breakdown while the question flavors are still sharp. SIG's OA has a reputation for looking familiar but biting harder than expected once you start coding. My sense after finishing is that reputation is earned: every problem had a twist that rewarded pattern recognition plus careful edge-case thinking, and the first two warm-ups are designed to burn time from candidates who do not notice the simple shortcut. I am a CS senior with two summer internships in backend and one in a smaller prop shop, so my baseline for trading-flavored problems was already calibrated.

This question is coming soon to HackTheRounds.

Timeline

Application: early March via the careers portal
OA invite: 8 days later, 5-day window
OA attempted: 2 days before the window closed
Next-round invite: 11 business days later
Total so far: ~4 weeks

OA Format (CodeSignal, 70 min)

Four coding problems. The first two are warm-ups. The third and fourth are the real differentiators. Python and C++ both supported. I used Python. SIG's grader is hidden-test heavy, so partial credit is common and finishing all four is not required to advance.

Problem 1: First Day Cumulative Visits Hit Target

Problem: Given a non-negative integer array visits representing daily visitor counts, return the earliest day index i such that the cumulative sum from day 0 through day i is at least a given target . Return -1 if the cumulative total never reaches target . Example: visits = [300, 200, 100, 200, 500], target = 700 returns 3 .

Straight linear scan with a running sum. Track an accumulator, iterate, return the first index where the accumulator hits or exceeds target . O(n) time, O(1) space. The only trap is the return-minus-one sentinel when the total never reaches target, which the grader will probe with a case where sum(visits) < target .

This is a pure fluency check. SIG wants to see that you default to the cleanest structure. Do not reach for prefix arrays, do not reach for binary search, just iterate.

This question is coming soon to HackTheRounds.

Problem 2: Drone Delivery System

Problem: You are designing a drone-based linear delivery system running from position 0 to some target on a number line. There are charging stations at sorted positions along the line. A drone can fly up to 10 units on a full charge. The delivery protocol: walk from your current position to the nearest charging station ahead, then launch a drone to cover up to 10 units, then walk resumes from the drone's landing point. Compute the total walking distance required to reach target .

Greedy simulation. Sort the stations, initialize current position to zero. Repeat: find the next station at or after the current position. If the next station is within reach or the station launch point plus 10 already covers target , calculate the walking distance to that station, advance current position to station plus 10, add the walking leg to the total. If there is no station ahead, walk directly to target . Stop when current position is at or past target .

Complexity is O(n log n) from the sort or O(n) if stations are given pre-sorted. The edge case to handle: what if a drone launch overshoots target ? You still only pay the walking distance up to the station, not past. Also: what if two stations are within 10 units of each other? The drone lands between them, so the walk from the landing point to the next station is non-zero.

This question is coming soon to HackTheRounds.

Problem 3: Distribution Center Package Handling

Problem: You manage N distribution centers, each with a capacity cap on packages processed before maintenance. Given a daily log of events that are either "PACKAGE" (a new package arrives) or "CLOSURE" (the next closure index marks a center as permanently closed), assign each package to the first open center with remaining capacity, cycling from a pointer that advances each time a center fills. If all open centers are filled, reset their remaining capacity to the original cap. When a center closes, no new packages land there. Return the center index that handled the most packages, tiebreaking on the larger index.

Circular-array simulation with a shutdown mask. I kept a pointer indexing into centers, remaining-capacity array, handled-count array, and a boolean open-or-closed flag per center. On a PACKAGE event, walk forward from the pointer until I find a center that is open with positive remaining capacity, decrement that center's capacity, increment its handled count, advance the pointer. If the walk completes a full loop without finding an eligible center, reset every open center's remaining capacity to the original and continue the walk.

The subtle case: the reset applies only to still-open centers, not to the closed ones. I almost reset all of them on my first draft and would have double-counted. Hidden tests almost certainly probe the interaction between closures and resets.

Complexity is O(number of events N) in the worst case because of the walking, which was fine for the stated constraints. A more careful implementation with a circular doubly-linked list of "open and non-empty" centers is O(log N) per event amortized, but I did not have time to refactor into that.

This question is coming soon to HackTheRounds.

Problem 4: Password Fragment Splicing

Problem: Given an array fragments of positive integers representing password pieces, and a target accessCode , count the number of ways to splice exactly two fragments (in order) into the string representation of accessCode . Splicing is string concatenation, not addition. Fragment positions in the array are distinct, but duplicate values exist. Example: fragments = [1, 212, 12, 12], accessCode = 1212 has multiple valid splits.

Convert everything to strings, bucket fragments by string value in a hashmap from string to count. For each prefix split accessCode[:i] + accessCode[i:] , count how many fragments equal the prefix and how many equal the suffix. If prefix equals suffix (same string), the number of ordered pairs is count (count - 1) since position matters and you cannot reuse the same slot. Otherwise it is count prefix count suffix . Sum across all split positions.

The tricky case is when accessCode has length one, which has no two-piece split, so the answer is zero. Another trap: when the prefix and suffix are distinct strings but one of them is not in the fragment map at all, the count is zero for that split, and a buggy implementation can mistakenly count one. I kept the hashmap-lookup default at zero explicitly to avoid this.

Complexity is O(L n) where L is the length of accessCode and n is the number of fragments, from a single hashmap build plus a linear scan over splits.

This question is coming soon to HackTheRounds.

Result

Moved to the next round. The recruiter said the grader split was strongly weighted toward problems 3 and 4. SIG does not share individual-problem scores, but they implied the advancement cutoff sits below the "all four perfect" bar. I left problem 3 with one suspected hidden-test failure and still cleared.

Tips

Do not speed-run problems 1 and 2. They look like warm-ups, and they are, but SIG grades them strictly and hidden tests target the sentinel return and the drone-overshoots-target edge. Spend five minutes each, verify outputs on scratch inputs, then move on.
On problem 3, separate "closed" and "empty" as two different states. Closed means no packages ever, empty means reset on the next full loop. Mixing these two into a single boolean is the most common bug. Keep a `closed[i]` and a `remaining[i]`, and never touch `closed[i]` during a reset.
On problem 4, use ordered-pair arithmetic for duplicates. When prefix equals suffix as a string, the pair count is `n * (n - 1)` (not `n * n` and not `C(n, 2)`), because positions are distinct and order matters. Getting this wrong on a case with multiple duplicate fragments is the single most common Problem 4 failure.
Drill monotonic stack and probability expectations before the OA. SIG's pool rotates slightly each cycle, but the core difficulty ceiling comes from monotonic stacks and expected-value arithmetic. If you cannot write either of those cold, you will not solve problem 3 or problem 4 on a worse draw than I got.
Practice on CodeSignal specifically. SIG uses the CodeSignal platform. The UI has no autocomplete, the test-runner formats differ from LeetCode, and the timed-session pressure is different from grinding LeetCode at your own pace. Do two CodeSignal mocks before the real OA.
Structure your time as 10-10-25-25. Problems 1 and 2 should eat 10 minutes each. Problems 3 and 4 deserve 25 minutes each. If you are still on problem 2 at the 20-minute mark, you are out of position. Move on and come back.

SIG's OA punishes candidates who try to outthink the easy problems and rewards candidates who treat every problem with the same care. Clean linear scans beat clever one-liners. Read each constraint before coding.