Security Engineer, Platform Interview Experience at PayPal – 2026

This HackerEarth assessment has two coding problems in 75 minutes, matching PayPal's standard qualification-round format. The first problem asks to identify whether a given number's digits, when rearranged, could form a number divisible by a target value - a solid approach checks digit-sum divisibility rules where applicable and falls back to a bounded permutation check for the general case, with the time-complexity tradeoff flagged explicitly. The second problem is a scheduling-style task: given a list of tasks each with a duration and a deadline, determine the maximum number that could be completed without missing any deadline, best solved with a greedy approach sorting by deadline and tracking cumulative time used.

This round focuses strictly on an optimal solution rather than accepting a brute-force answer, consistent with what other candidates describe as PayPal's problem-solving round style. Given a stream of failed-login events tagged with user ID and timestamp, candidates are asked to implement a function flagging any user with more than five failed attempts within a rolling ten-minute window, since that pattern is a real fraud-detection signal PayPal's systems rely on. An initial solution recomputing the window on every event is a common starting point; the expected optimization moves to a per-user deque of timestamps, evicting stale entries lazily rather than scanning the full event history each time.

This is a debugging-style round: candidates are given a partially working implementation of a token-bucket rate limiter with a subtle bug (the bucket refill calculation uses integer division, silently truncating fractional token accumulation on every refill and causing the effective rate to drift below the intended limit over time). The task is to trace through the logic methodically rather than rewrite from scratch, and interviewers specifically want to see how the bug is isolated - a good approach adds print statements at the refill step first, notices the token count isn't matching expected values after several cycles, and traces it back to the truncation.

Candidates are asked to design an access-control and audit system for internal services handling sensitive payment data, where every access to a customer's financial record must be logged, attributable to a specific service identity, and reviewable after the fact. A strong approach proposes short-lived, scoped credentials issued per request rather than long-lived service accounts, an immutable audit log written to append-only storage separate from the primary datastore so a compromised service can't tamper with its own access history, and anomaly detection on the audit stream itself to flag unusual access patterns (a service suddenly reading far more records than its historical baseline). Interviewers typically push on what happens if the credential-issuing service itself is compromised; a well-reasoned answer discusses the tradeoff of a hardware-backed root of trust versus accepting that layer as a smaller, more heavily monitored blast radius rather than claiming it could be made unbreakable.

This behavioral round is grounded in real shipped work rather than generic responsibilities, matching PayPal's reported style. Candidates are asked to describe a specific security incident they responded to, with interviewers pressing for measurable outcomes - not just what happened, but what changed afterward (a new detection rule, a reduced mean-time-to-detect, a specific access pattern that got locked down) and how the candidate would know if that change actually worked, not just that it felt like the right response at the time.