{"id":986,"date":"2026-06-26T03:06:16","date_gmt":"2026-06-26T03:06:16","guid":{"rendered":"https:\/\/lastroundai.com\/blog\/?post_type=iq&#038;p=986"},"modified":"2026-07-19T10:54:09","modified_gmt":"2026-07-19T05:24:09","slug":"paypal","status":"publish","type":"iq","link":"https:\/\/lastroundai.com\/interview-questions\/paypal","title":{"rendered":"PayPal Interview Questions (2026): What They Actually Ask"},"content":{"rendered":"<p>A candidate who went through PayPal&#8217;s virtual onsite in early 2025 described the process as &#8220;more Java than I expected, more payments context than I studied for.&#8221; He&#8217;d prepared the usual LeetCode medium library and felt fine through the coding rounds. The system design round surprised him. The interviewer wasn&#8217;t interested in designing Twitter. She asked him how he&#8217;d guarantee that a retry on a failed charge wouldn&#8217;t debit the user twice. He hadn&#8217;t thought about idempotency at that level before. He didn&#8217;t get the offer.<\/p>\n<p>That gap between general SWE prep and what PayPal actually tests is what this page is about. The process is not as algorithmically punishing as Google or Meta. It sits around a 6.5 out of 10 on pure algorithm difficulty. But it has real domain weight: idempotency, double-entry accounting, distributed transaction consistency, fraud scoring pipelines. Candidates who know those patterns cold have a clear edge over candidates who&#8217;ve only drilled LeetCode. The questions below are drawn from verified candidate reports on Glassdoor, GeeksForGeeks, TechPrep, and community threads from people who went through the loop between 2024 and early 2026.<\/p>\n<div class=\"iq-stats not-prose\"><div class=\"iq-stat\"><span class=\"iq-stat__value\">3-6 weeks<\/span><span class=\"iq-stat__label\">Process<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">4-6<\/span><span class=\"iq-stat__label\">Rounds<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">LC Easy-Medium<\/span><span class=\"iq-stat__label\">Coding<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">Virtual onsite<\/span><span class=\"iq-stat__label\">Format<\/span><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--easy\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"easy\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Easy questions<\/h2><span class=\"iq-dsec__n\">15<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Validate an IPv4 address<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Strings<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Split on &#8216;.&#8217;, verify exactly 4 parts, each part is a valid integer in the range 0 to 255 with no leading zeros (except &#8220;0&#8221; itself). Reject empty parts and parts with non-numeric characters. The edge cases are where candidates lose points: &#8220;01&#8221; has a leading zero and should be invalid; &#8220;256&#8221; exceeds range; &#8220;1.2.3&#8221; has only 3 octets.<\/p>\n<p>Reported from a PayPal technical phone screen. An easy problem where interviewers probe your attention to edge cases. Candidates who run through the happy path and call it done usually get a follow-up that exposes the leading-zero case.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Breadth of a given binary tree (level widths)<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Trees<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>BFS with a queue. At each level, record the queue size before processing, that size is the width of that level. Dequeue all nodes at the current level and enqueue their children. Track the maximum width seen. A more memory-efficient variant uses indexes, representing each node&#8217;s position in a full binary tree to compute width without explicitly tracking all null nodes.<\/p>\n<p>Reported in multiple PayPal phone screen accounts. It shows up as the warm-up problem before the real coding question. The indexed-width variant (using 2*i and 2*i+1 for child positions) comes up as a follow-up when the tree is sparse and naive BFS counts too many nulls.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s the difference between Spring and Spring Boot, and what problems does Boot solve?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Java \/ Framework<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Spring is the framework: dependency injection, AOP, transaction management, data access. Spring Boot is an opinionated layer on top: auto-configuration based on classpath presence, an embedded server (Tomcat by default), starter dependencies that pull in and configure related libraries as a bundle, and an actuator for health and metrics endpoints. Boot eliminates the XML configuration boilerplate that made Spring painful for new projects.<\/p>\n<p>Reported in the managerial round at PayPal SDE II. Follow-up: &#8220;How would you override an auto-configured bean?&#8221; The answer: define a bean of the same type in your application context and annotate it with @Primary, or use @ConditionalOnMissingBean on the auto-configuration class to suppress it entirely.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What is PCI DSS and what does it require from engineers building payment systems?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Fintech \/ Compliance<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>PCI DSS, the Payment Card Industry Data Security Standard, is a set of 12 requirements the card networks impose on anyone who stores, processes, or transmits cardholder data. For an engineer day to day, the practical version is: never log a raw card number, tokenize the card at the point of entry so a reference token replaces the primary account number before it touches most application code, segment the network so only a small, audited scope ever handles real card data, and encrypt cardholder data both at rest and in transit.<\/p>\n<p>The useful interview framing is tokenization first. A candidate who designs a payment flow where the raw card number passes through five internal services before it&#8217;s finally stored has a compliance problem regardless of how well the rest of the distributed system is designed. PayPal, operating as both a processor and a merchant-facing platform, expects candidates in fintech-adjacent rounds to raise tokenization and scope reduction on their own, without the interviewer having to prompt for it.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">If you&#039;re stuck on a hard problem for an extended period, how do you approach it?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>PayPal specifically reports this question on Glassdoor. The answer they&#8217;re listening for: you have a structured approach to un-sticking yourself, not just &#8220;I ask for help.&#8221; A reasonable structure: isolate the assumption you haven&#8217;t tested, build the smallest reproduction of the problem, check your instrumentation before trusting the output, time-box the solo attempt and then escalate with context. &#8220;I was stuck for three hours before Slack-ing the team&#8221; is a weaker answer than &#8220;I time-box at 30 minutes before seeking input, and when I do I lead with what I&#8217;ve already ruled out.&#8221;<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Why PayPal? What specifically about this role or team interests you?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Generic &#8220;fintech is exciting and payments affect everyone&#8221; answers are transparent and don&#8217;t differentiate. The answers that land: you name something specific about PayPal&#8217;s technical trajectory (the migration from monolith to microservices, the Braintree and Venmo platform integration challenges, the scale of operating across 200+ markets), or a specific product feature you&#8217;ve used and thought about technically, or a specific engineering blog post that gave you a concrete question you want to work on. Research the team. Ask the recruiter what the team is building this quarter. Use that.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How long does the PayPal interview process take from application to offer?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Most candidates report 3 to 6 weeks. SDE-level loops tend to close in 3 to 4 weeks when the process moves smoothly. Senior and staff loops are slower, typically 4 to 6 weeks, because team-matching and hiring committee steps add time after the final onsite. The OA is usually sent within a few days of the recruiter screen, and the onsite is typically scheduled within two weeks of passing the technical phone screen.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Is the PayPal OA on HackerRank? What&#039;s the format?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Yes. The OA runs on HackerRank. New-grad reports describe 11 questions in 90 minutes: two coding problems (easy to medium DSA) and nine multiple choice questions covering SQL, JavaScript, Java OOP fundamentals, and basic CS concepts. For experienced hire roles the OA format varies and some loops skip it entirely, going straight to a technical phone screen. Ask your recruiter whether an OA is part of your specific loop.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Do I need to know Java for PayPal interviews?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>For backend and platform roles, Java fluency is strongly recommended. PayPal&#8217;s core systems are Java-heavy, and interviewers for those teams routinely ask Java-specific follow-ups: HashMap internals, CompletableFuture, streams and lambda syntax, Spring Boot configuration. For full-stack or newer services teams, TypeScript and Node are common and you may not face Java questions at all. Confirm with your recruiter what stack the team uses. For the OA and live coding rounds, Python is generally acceptable as the coding language even in Java-heavy teams.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How important is the fintech domain knowledge for PayPal interviews?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>More important than most SWE candidates expect. General coding skill gets you through the OA and the first technical round. The system design round and the role-specialization round actively test payments domain knowledge: idempotency, double-entry accounting, ACID properties in distributed systems, fraud detection pipeline design, PCI DSS at a basic level. Candidates without this context visibly lose ground in the design round even with strong algorithmic skills. Two or three hours reading about idempotency patterns, payment saga flows, and basic fintech architecture will put you ahead of the majority of candidates.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Does PayPal do system design interviews for SDE-1 or new grad roles?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Usually not a full formal system design round. New grad loops focus on coding problems and behavioral questions, with a lighter design or low-level OOP question sometimes appearing in the HM round. At SDE-2 and above, a dedicated system design round is standard. Staff-level loops may include two design rounds, one low-level and one high-level architecture. If you&#8217;re unsure, ask the recruiter what rounds your specific loop includes before you start prepping.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s the best way to prepare for PayPal&#039;s system design round?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Three areas matter most. First, understand idempotency and exactly-once semantics in distributed payment flows. Second, read about double-entry accounting and why append-only ledgers are standard in financial systems. Third, be able to discuss ACID tradeoffs in distributed systems: where strong consistency is non-negotiable (the ledger) and where eventual consistency is acceptable (notification history, analytics). On top of that foundation, the standard system design prep applies: API design, database sharding, caching strategies, failure mode analysis. The Stripe and PayPal engineering blogs both publish technical posts on these topics and are worth an afternoon of reading before your onsite.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What are PayPal&#039;s software engineer levels and how do interview loops differ by level?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>PayPal&#8217;s individual contributor ladder runs roughly SDE1 (new grad or early career), SDE2 (2 to 5 years), Senior SDE, Staff, and Principal, though exact title conventions shift slightly across business units like Braintree and Venmo. SDE1 and SDE2 loops lean on coding and behavioral rounds with a lighter design component. Senior and above add a dedicated system design round, and staff-level loops sometimes split that into two rounds, one low-level and one high-level architecture, plus the extra hiring-committee step that adds time to the process described earlier on this page.<\/p>\n<p>Ask the recruiter directly which level the role is leveled at and which rounds apply before you start prepping. Loop composition gets decided before you&#8217;re scheduled, so an accurate answer here changes what you should spend your remaining time on.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What is the difference between authentication and authorization, and how does each show up in PayPal&#039;s API?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">auth basics<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Authentication answers &#8220;who are you&#8221;, authorization answers &#8220;what are you allowed to do&#8221;. In PayPal&#8217;s API, authentication happens when a client exchanges credentials (client id and secret, or a login flow) for an OAuth 2.0 access token. That token proves the caller&#8217;s identity for every subsequent request. Authorization happens on each call after that: the server checks the scopes attached to the token to decide whether this particular caller can, say, read transaction history versus actually issue a refund.<\/p>\n<p>A junior engineer should be able to tell these apart in the status codes too. A missing, malformed, or expired token gets a 401, because the server can&#8217;t even confirm who&#8217;s calling. A token that&#8217;s perfectly valid but lacks the right scope or permission gets a 403, because the server knows who you are and is refusing the action anyway. Mixing these two up in error handling is a common early mistake, and it makes debugging integration issues much harder for merchants calling the API.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s the difference between a process and a thread?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">process vs thread<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A process is a running program with its own memory space, file descriptors, and OS-allocated resources. A thread is a unit of execution inside a process, and all threads in a process share that same heap and open file handles, but each thread gets its own stack and program counter. Because threads share memory, passing data between them is just reading and writing shared variables, which is fast but requires locks or other synchronization to avoid race conditions. Processes don&#8217;t share memory, so they need explicit mechanisms like sockets, pipes, or shared memory segments to talk to each other.<\/p>\n<p>In a service like a payment API running on the JVM, one process handles many concurrent requests using a thread pool, and those threads share the same connection pool and in-memory caches. Scaling out horizontally means running more processes or containers, each with its own isolated memory, not more threads in one process. It&#8217;s also worth knowing that an unhandled exception in one worker thread can be caught and contained without affecting the rest of the process if the thread pool is set up correctly, whereas something like a native crash or an OutOfMemoryError takes the whole process down, threads and all.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--medium\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"medium\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Medium questions<\/h2><span class=\"iq-dsec__n\">23<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Find all elements appearing more than n\/k times in an array<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Arrays<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Use a Boyer-Moore majority vote variant generalized to k candidates. Maintain at most k-1 candidate-count pairs. On each element, if it&#8217;s an existing candidate increment its count; if there&#8217;s an empty slot add it; otherwise decrement all counts by 1. After the pass, verify each candidate against the full array to confirm it genuinely exceeds n\/k occurrences.<\/p>\n<p>Reported from a PayPal SDE II round in 2024 on GeeksForGeeks. The follow-up was &#8220;what&#8217;s the space complexity and can you reduce it?&#8221; The Boyer-Moore approach runs in O(n) time and O(k) space, which is optimal. Candidates who start with a hash map and frequency count (O(n) space) should be ready to explain why that&#8217;s suboptimal when k is small.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">java<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-java\">\n\nimport java.util.*;\npublic class MajorityElements {\n\n    public static List&lt;Integer&gt; findMajority(int[] nums, int k) {\n\n        Map&lt;Integer, Integer&gt; candidates = new HashMap&lt;&gt;();\n        for (int num : nums) {\n\n            if (candidates.containsKey(num)) {\n\n                candidates.put(num, candidates.get(num) + 1);\n\n            } else if (candidates.size() &lt; k \u2013 1) {\n\n                candidates.put(num, 1);\n\n            } else {\n\n                List&lt;Integer&gt; toRemove = new ArrayList&lt;&gt;();\n\n                for (Map.Entry&lt;Integer, Integer&gt; e : candidates.entrySet()) {\n\n                    if (e.getValue() == 1) toRemove.add(e.getKey());\n\n                    else candidates.put(e.getKey(), e.getValue() \u2013 1);\n\n                }\n\n                toRemove.forEach(candidates::remove);\n\n            }\n\n        }\n        \/\/ Verification pass\n\n        Map&lt;Integer, Integer&gt; counts = new HashMap&lt;&gt;();\n\n        for (int num : nums) counts.merge(num, 1, Integer::sum);\n        List&lt;Integer&gt; result = new ArrayList&lt;&gt;();\n\n        int threshold = nums.length \/ k;\n\n        for (int c : candidates.keySet()) {\n\n            if (counts.getOrDefault(c, 0) &gt; threshold) result.add(c);\n\n        }\n\n        return result;\n\n    }\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Longest palindromic substring<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Dynamic Programming<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Expand around center. For each index i, expand outward checking both odd-length palindromes (center at i) and even-length palindromes (center between i and i+1). Track the longest expansion found. This runs in O(n^2) time and O(1) space, which is the expected answer in interviews. Manacher&#8217;s algorithm achieves O(n) but interviewers rarely expect it unless they ask for the optimal solution explicitly.<\/p>\n<p>Reported in multiple OA write-ups from 2024 to 2025. Candidates who submitted the DP table approach (O(n^2) time and space) were asked in follow-up whether they could reduce space. The expand-around-center approach is the right answer to that question.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Search in a rotated sorted array<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Binary Search<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Modified binary search. At each step determine which half is sorted by comparing the midpoint to the left boundary. If the left half is sorted and the target falls within it, search left. Otherwise search right. One pass, O(log n).<\/p>\n<p>Reported from a PayPal HackerRank OA and a separate phone screen. The standard follow-up: how does this change with duplicates? With duplicates you can&#8217;t determine which half is sorted when nums[left] == nums[mid], so you fall back to incrementing left and decrementing right, which degrades to O(n) in the worst case.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Word search in a 2D grid<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Backtracking<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>DFS with backtracking from each cell that matches the first character. Mark cells as visited in-place (set to a sentinel like &#8216;#&#8217;) before recursing, restore on backtrack. Return true as soon as the full word is matched. Pruning: if the remaining word is longer than remaining unvisited cells, abort early.<\/p>\n<p>Reported in PayPal OA write-ups from 2025. The follow-up sometimes asks: &#8220;what if you need to find all occurrences?&#8221; That changes the logic: instead of returning true on first match, you collect all starting positions and continue searching.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Minimum path sum in a triangle<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Dynamic Programming<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Bottom-up DP starting from the second-to-last row. For each element, it equals its value plus the minimum of the two elements directly below it. After processing all rows from bottom to top, the answer is at the top element. Runs in O(n^2) time and O(n) space if you modify the triangle in place or use a 1D DP array of size n.<\/p>\n<p>Reported from a 2025 PayPal OA. The in-place modification trick, using the triangle itself as the DP table, is the kind of space optimization that interviewers note positively in the OA scoring rubric.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Print a given matrix in spiral order<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Arrays<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Track four shrinking boundaries: top, bottom, left, right. Walk left to right across the top row, top to bottom down the right column, right to left across the bottom row, and bottom to top up the left column, moving each boundary inward by one after its pass. Stop once top exceeds bottom or left exceeds right. The whole traversal runs in O(rows &times; cols) time and needs no extra space beyond the output list.<\/p>\n<p>Reported in PayPal OA write-ups on GeeksForGeeks as the second, harder question after an easier warm-up problem. Most point loss happens at the boundary checks, specifically forgetting to re-check top &lt;= bottom before the final left-moving pass on a single remaining row, which either duplicates a row or walks off the matrix.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">java<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-java\">\n\nimport java.util.*;\npublic class SpiralMatrix {\n\n    public static List&lt;Integer&gt; spiralOrder(int[][] matrix) {\n\n        List&lt;Integer&gt; result = new ArrayList&lt;&gt;();\n\n        if (matrix.length == 0) return result;\n        int top = 0, bottom = matrix.length \u2013 1;\n\n        int left = 0, right = matrix[0].length \u2013 1;\n        while (top &lt;= bottom &amp;&amp; left &lt;= right) {\n\n            for (int c = left; c &lt;= right; c++) result.add(matrix[top][c]);\n\n            top++;\n\n            for (int r = top; r &lt;= bottom; r++) result.add(matrix[r][right]);\n\n            right\u2013;\n\n            if (top &lt;= bottom) {\n\n                for (int c = right; c &gt;= left; c\u2013) result.add(matrix[bottom][c]);\n\n                bottom\u2013;\n\n            }\n\n            if (left &lt;= right) {\n\n                for (int r = bottom; r &gt;= top; r\u2013) result.add(matrix[r][left]);\n\n                left++;\n\n            }\n\n        }\n\n        return result;\n\n    }\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How many rectangles can be formed on an n by n chessboard?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Math \/ Combinatorics<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A rectangle on the grid is fully determined by choosing 2 of the n+1 horizontal grid lines and 2 of the n+1 vertical grid lines. That&#8217;s C(n+1, 2) ways to pick the horizontal pair times C(n+1, 2) for the vertical pair, so the total rectangle count is C(n+1, 2) squared. On a standard 8 by 8 board that&#8217;s 36 squared, 1,296 rectangles. Squares are a separate count: the number of k by k squares on an n by n board is (n &#8211; k + 1) squared, summed over k from 1 to n.<\/p>\n<p>Reported as a PayPal OA and phone screen brainteaser in 2025 candidate write-ups. It&#8217;s less an algorithm problem than a combinatorics identity, and the interviewer is really checking whether you reach for the closed-form choose-2 pattern or start writing a brute-force loop over four coordinates, which works but signals you didn&#8217;t recognize the structure underneath.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Lowest common ancestor in a binary tree using parent pointers<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Trees<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The standard approach with a HashSet: traverse from node p upward to the root, storing each node in a set. Then traverse from node q upward; the first node already in the set is the LCA. This runs in O(h) time and O(h) space where h is the height of the tree.<\/p>\n<p>Reported from the PayPal SDE II round on GeeksForGeeks (2024). The interviewer specifically asked for space optimization. The O(1) space approach: find depths of p and q, bring the deeper node up to the same level, then move both upward in lockstep until they meet.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">java<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-java\">\n\nimport java.util.*;\nclass TreeNode {\n\n    int val;\n\n    TreeNode parent, left, right;\n\n    TreeNode(int val) { this.val = val; }\n\n}\npublic class LCA {\n\n    public TreeNode findLCA(TreeNode p, TreeNode q) {\n\n        Set&lt;TreeNode&gt; visited = new HashSet&lt;&gt;();\n\n        while (p != null) {\n\n            visited.add(p);\n\n            p = p.parent;\n\n        }\n\n        while (q != null) {\n\n            if (visited.contains(q)) return q;\n\n            q = q.parent;\n\n        }\n\n        return null;\n\n    }\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Print the right view of a binary tree<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Trees<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Level order BFS, and at each level the last node dequeued is the one visible from the right side. Track the level size before the inner loop the same way the level-width question above does, and keep only the final node&#8217;s value from each level. A DFS alternative visits the right child before the left child and records a node&#8217;s value only the first time its depth is reached; both approaches run in O(n) time.<\/p>\n<p>Reported from PayPal technical phone screens as a quick follow-up after an easier warm-up tree question. The DFS variant trips up candidates who default to visiting left before right out of habit and have to rewrite the recursion order once the interviewer points it out.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Return the zigzag level order traversal of a binary tree&#039;s values<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Trees<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Standard BFS by level, but alternate the direction the collected values get appended in: left to right on even levels (counting the root as level 0), right to left on odd levels. The simplest implementation runs the normal BFS and reverses every other level&#8217;s list before appending it to the result, rather than trying to traverse in alternating directions during the BFS itself.<\/p>\n<p>Reported in PayPal OA and onsite write-ups as a variant of the plain level order traversal question, distinct from the level-width problem covered above since it asks for the actual node values in alternating order, not just a count per level. A common mistake is reversing every level instead of every other one, so testing against a 4 or 5 level tree before submitting is worth the extra minute.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nfrom collections import deque\ndef zigzag_level_order(root):\n\n    if not root:\n\n        return []\n\n    result, queue, left_to_right = [], deque([root]), True\n\n    while queue:\n\n        level = deque()\n\n        for _ in range(len(queue)):\n\n            node = queue.popleft()\n\n            if left_to_right:\n\n                level.append(node.val)\n\n            else:\n\n                level.appendleft(node.val)\n\n            if node.left:\n\n                queue.append(node.left)\n\n            if node.right:\n\n                queue.append(node.right)\n\n        result.append(list(level))\n\n        left_to_right = not left_to_right\n\n    return result\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Implement an LRU cache with O(1) get and put<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Data Structures<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>HashMap for O(1) key lookup plus a doubly linked list for O(1) recency ordering. The list head holds the most recently used entry; the tail holds the eviction candidate. On get, move the accessed node to the head. On put, if the key exists update and move to head; if new and at capacity evict the tail node and remove its key from the map before inserting.<\/p>\n<p>Reported from a PayPal coding round and the OA. Java candidates are sometimes asked to implement this without using LinkedHashMap even though LinkedHashMap with accessOrder=true does this in three lines. The interviewer wants to see that you understand the mechanism, not just the shortcut.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">java<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-java\">\n\nimport java.util.*;\nclass LRUCache {\n\n    private final int capacity;\n\n    private final Map&lt;Integer, Node&gt; map = new HashMap&lt;&gt;();\n\n    private final Node head = new Node(0, 0);\n\n    private final Node tail = new Node(0, 0);\n    static class Node {\n\n        int key, val;\n\n        Node prev, next;\n\n        Node(int key, int val) { this.key = key; this.val = val; }\n\n    }\n    public LRUCache(int capacity) {\n\n        this.capacity = capacity;\n\n        head.next = tail;\n\n        tail.prev = head;\n\n    }\n    public int get(int key) {\n\n        Node node = map.get(key);\n\n        if (node == null) return -1;\n\n        remove(node);\n\n        insertFront(node);\n\n        return node.val;\n\n    }\n    public void put(int key, int value) {\n\n        Node node = map.get(key);\n\n        if (node != null) { remove(node); node.val = value; insertFront(node); }\n\n        else {\n\n            if (map.size() == capacity) {\n\n                Node lru = tail.prev;\n\n                remove(lru);\n\n                map.remove(lru.key);\n\n            }\n\n            Node newNode = new Node(key, value);\n\n            insertFront(newNode);\n\n            map.put(key, newNode);\n\n        }\n\n    }\n    private void remove(Node n) { n.prev.next = n.next; n.next.prev = n.prev; }\n\n    private void insertFront(Node n) { n.next = head.next; n.prev = head; head.next.prev = n; head.next = n; }\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What is idempotency and why does it matter in payment systems?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Fintech \/ Domain<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>An operation is idempotent if applying it multiple times produces the same result as applying it once. In payments: if a charge request times out and the client retries, an idempotent payment API guarantees that the retry does not create a second charge. Implementation: the client generates a unique idempotency key (UUID) per payment intent and sends it in the request header. The server stores the key with the response on first execution. On retry, the server returns the stored response without re-executing. The key lookup and response store must be atomic to handle concurrent retries.<\/p>\n<p>PayPal&#8217;s public API documentation explicitly requires idempotency keys for payment endpoints. Interviewers consider this basic professional knowledge for any fintech backend role.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Explain ACID properties and where they break down in distributed systems<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Databases<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Atomicity: a transaction either completes fully or not at all. Consistency: data moves from one valid state to another. Isolation: concurrent transactions produce the same result as if they ran serially. Durability: committed transactions survive crashes.<\/p>\n<p>Where they break down: a single RDBMS can give you all four, but distributing a transaction across two databases requires two-phase commit, which has latency cost and is unavailable during coordinator failure. Most distributed payment systems relax isolation (using eventual consistency for non-critical reads) and implement atomicity at the application level via sagas with compensating transactions. The ledger itself, the source of truth for balances, typically runs on a strongly consistent relational database. Downstream systems (analytics, notification history) tolerate eventual consistency.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">HashMap vs. Hashtable in Java, and when does thread safety matter in a payment context?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Java \/ Concurrency<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>HashMap is not synchronized and should not be shared across threads without external locking or use of ConcurrentHashMap. Hashtable is fully synchronized but coarse-grained, every operation locks the whole table. ConcurrentHashMap uses segment-level locking and is the right choice for most concurrent read-heavy workloads.<\/p>\n<p>In payment systems, shared mutable state in-process is usually the wrong design. Correctness comes from the database transaction, not from in-memory synchronization. But caches (idempotency key caches, rate limit counters, session stores) are shared and need thread-safe access. Use ConcurrentHashMap for in-JVM caches, Redis with atomic operations for distributed caches.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How does a circuit breaker pattern work, and when would you use one at PayPal?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Distributed Systems<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A circuit breaker wraps calls to a downstream service and tracks failure rate over a rolling window. In closed state (normal), calls pass through. If failure rate exceeds a threshold, the breaker opens: subsequent calls fail fast without hitting the downstream service, giving it time to recover. After a timeout, the breaker moves to half-open: a probe request goes through. If it succeeds, the breaker closes. If it fails, it opens again.<\/p>\n<p>At PayPal, circuit breakers protect critical payment paths from cascading failures. If the fraud scoring service starts timing out, a circuit breaker allows the payment system to either fail safe (decline the transaction) or degrade gracefully (approve below a risk threshold with extra logging) rather than holding connections open and causing the payment service itself to back up. Reported as a PayPal SDE II system design question.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Complex SQL: find the second highest transaction amount per user<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">SQL<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Use a window function. RANK() or DENSE_RANK() partitioned by user_id and ordered by amount descending. Then filter where the rank equals 2. With DENSE_RANK(), ties in the first position still yield rank 2 for the next distinct amount. With RANK(), tied first entries jump straight to rank 3, which may produce no rank-2 result for tied users.<\/p>\n<p>PayPal uses SQL more than most tech companies of its size. The technical deep-dive round for data-adjacent roles, and sometimes for backend roles, includes multi-table join questions, window functions, and transaction schema design. Candidates who haven&#8217;t touched SQL beyond simple selects are sometimes caught off guard.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\n\u2014 Second-highest transaction amount per user\n\nSELECT user_id, amount\n\nFROM (\n\n    SELECT\n\n        user_id,\n\n        amount,\n\n        DENSE_RANK() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rnk\n\n    FROM transactions\n\n) ranked\n\nWHERE rnk = 2;\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">When would you use optimistic locking versus pessimistic locking in a payments system?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Databases \/ Concurrency<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Optimistic locking assumes conflicts are rare. Read a row along with its version number, and let the write succeed only if the version hasn&#8217;t changed since the read, a compare-and-swap at the database level, retrying on conflict. Pessimistic locking takes the lock up front (SELECT &#8230; FOR UPDATE) and blocks every other writer until the transaction commits. Optimistic locking scales better under low contention because it never holds a lock across a network round trip. Pessimistic locking wins when contention is high or a transaction needs several dependent reads before deciding whether to write at all, since a retry storm under heavy contention can waste more work than a short block would have cost.<\/p>\n<p>Per-account balance updates are the classic contention point in a payments system, two withdrawals racing against the same account at the same instant. PayPal&#8217;s ledger design leans toward serializing writes per account through a single shard owner rather than relying purely on optimistic retries, because a failed optimistic write on a balance check has to re-validate a business rule (sufficient funds) before retrying, not just blindly resubmit the same write.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about the biggest mistake you made in your most recent job and how you handled it.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Structure: name the specific mistake, the actual impact (a number is better than &#8220;significant&#8221;), what you did to contain it, what the root cause turned out to be (not the symptom), and what structural change you made so it wouldn&#8217;t happen again. &#8220;I added more testing&#8221; is not a structural change. &#8220;We added a required database migration review step to the deploy checklist and I wrote the runbook&#8221; is.<\/p>\n<p>PayPal interviewers reported on Glassdoor push on the root cause component most consistently. Candidates who stop at &#8220;I fixed the bug and wrote a test&#8221; are asked: &#8220;But why did the bug get through in the first place?&#8221; Have a level-two answer ready.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Describe a time you disagreed with management about a process or technical decision.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Pick a story where you had specific evidence, raised it through a professional channel, and either changed the decision or understood why you were overruled. Avoid stories where you were right and management was stubbornly wrong and the project failed. Interviewers read that as a lack of professional judgment about when to push and when to commit.<\/p>\n<p>The stronger story shape: you disagreed, you presented data or a prototype to back your position, the decision went against you, and you found a way to address your concern within the chosen direction anyway, and in retrospect the decision was reasonable even if you&#8217;d have made a different call. That story shows judgment, not just confidence.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Give an example of adapting quickly to a significant change in requirements or technology.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Be specific about the timeline and what made it hard. The easier version of this story, &#8220;we switched frameworks and I read the docs,&#8221; doesn&#8217;t land well. The harder version names what you had to give up (certainty, code you&#8217;d already written, an approach you&#8217;d advocated for), describes how you got oriented fast, and shows a concrete outcome. If you changed course mid-sprint and still shipped on time, say the specific date and what you delivered.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about a successful cross-team project and your specific role.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>PayPal is large enough that most high-impact work crosses team boundaries. Interviewers want to know whether you lead by authority or by influence. Stories where you called a meeting and issued tasks are weaker than stories where you aligned stakeholders by identifying the shared goal, unblocked a dependency, or built the shared tooling that made collaboration easier. Name the teams, describe the communication mechanism you used, and be specific about what would have broken down without your contribution.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about a time you had to make progress despite ambiguous or incomplete requirements.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Name the actual decision you made without waiting for full clarity, what information you did have at the time, and how you checked that your direction was reasonable before committing further, a quick prototype, an early stakeholder check-in, a scoped experiment. Skip the version where the ambiguity happened to resolve itself in your favor. Interviewers are listening for a repeatable process for reducing ambiguity, not a story where things just worked out.<\/p>\n<p>PayPal&#8217;s hiring manager round specifically asks about handling ambiguity, per multiple candidate reports, since cross-team platform work rarely starts with a complete spec. The stronger answers describe checking in early and often rather than disappearing for two weeks to build what you assumed was the right thing.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Describe a time you had to convince a peer team to change direction without having authority over them.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The shape that lands: you brought data or a working prototype instead of an opinion, you framed the ask around the other team&#8217;s incentives rather than your own, and you left room for them to adjust the approach instead of demanding your exact solution. Stories where you escalated straight to a manager read as a lack of peer-level influence, not a strength.<\/p>\n<p>This maps to PayPal&#8217;s stated Collaboration value and often shows up disguised as a more generic prompt, &#8220;tell me about a time you worked cross-functionally&#8221; is frequently this question in a different wrapper. Name the other team specifically and the concrete change that resulted from your side of the conversation.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--hard\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"hard\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Hard questions<\/h2><span class=\"iq-dsec__n\">5<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design PayPal&#039;s payment processing system handling 50 million transactions per day<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Start with requirements: functional (initiate payment, check status, refund, currency conversion), non-functional (high availability, strong consistency for the ledger, exactly-once processing, audit trail for regulators). Fifty million daily transactions is roughly 580 TPS average, with peak bursts significantly higher, design for 5,000 to 10,000 TPS peak.<\/p>\n<p>Core architecture: API gateway for auth and rate limiting, payment orchestration service that breaks the payment into discrete steps (authorization, settlement, ledger update), a double-entry accounting ledger stored in a strongly consistent relational database (Postgres with read replicas for reporting), and an async event bus (Kafka) for downstream consumers like notifications and fraud scoring. Idempotency keys stored in Redis with a TTL ensure retries don&#8217;t execute twice. The ledger uses append-only writes: you never update a row, you write a new debit and credit entry. This makes the audit trail automatic and simplifies rollback.<\/p>\n<p>Failure modes the interviewer will probe: what happens if the payment orchestrator crashes after debiting the sender but before crediting the receiver? Saga pattern with compensating transactions, or two-phase commit if the databases support it. Two-phase commit has higher latency but stronger guarantees. PayPal&#8217;s internal architecture (as disclosed in engineering blog posts from 2022 to 2024) uses distributed sagas with explicit compensation logic for cross-service consistency.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\n# Idempotency key handler (simplified)\n\nimport redis\n\nimport json\nr = redis.Redis(host=\u2019localhost\u2019, port=6379, db=0)\n\nIDEMPOTENCY_TTL = 86400  # 24 hours\ndef process_payment_idempotent(idempotency_key: str, payment_data: dict) -&gt; dict:\n\n    cached = r.get(f\u201didem:{idempotency_key}\u201d)\n\n    if cached:\n\n        return json.loads(cached)  # return stored result, do not re-execute\n    result = execute_payment(payment_data)  # actual payment logic\n    # Store with TTL; NX ensures only the first write wins (atomic)\n\n    r.set(f\u201didem:{idempotency_key}\u201d, json.dumps(result), ex=IDEMPOTENCY_TTL, nx=True)\n\n    return result\ndef execute_payment(payment_data: dict) -&gt; dict:\n\n    # debit sender, credit receiver, write ledger entries\n\n    # returns {\u201ctransaction_id\u201d: \u2026, \u201cstatus\u201d: \u201cCOMPLETED\u201d, \u2026}\n\n    pass\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Kafka only guarantees at-least-once delivery. How would you get effectively-once processing of payment events on the consumer side?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">kafka processing<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>True exactly-once across a distributed system without a global two-phase commit isn&#8217;t really achievable, so the practical goal is effectively-once from the consumer&#8217;s point of view: duplicates can still arrive, but processing them a second time has no visible effect. The standard way to get there is to record that an event has been handled in the same database transaction as the side effect it triggers, usually with a unique constraint on an event id or a composite key like payment_id plus event_type. If the consumer crashes after committing the side effect but before committing the Kafka offset, it reprocesses that message on restart, and the unique constraint turns the second write into a harmless no-op instead of a duplicate.<\/p>\n<p>On the producer side, enabling the idempotent producer stops duplicate writes to the topic itself caused by retries after a network blip, and transactional producers let you atomically consume from one topic and produce to another as part of the same commit, which matters for chained flows like &#8220;payment authorized&#8221; triggering &#8220;settlement requested.&#8221;<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">properties<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-properties\">\n\nenable.idempotence=true\n\nacks=all\n\nmax.in.flight.requests.per.connection=5\n<\/code><\/pre><\/div><\/p>\n<p>The gotcha most people get wrong is ordering: committing the Kafka offset before the downstream write is durable is a classic at-most-once bug that can silently drop a payment event on a crash. Committing the side effect first and the offset second is safer, but it means every consumer has to tolerate reprocessing its last uncommitted batch on restart, which is exactly what the unique-constraint pattern above is for.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">sql<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-sql\">\n\nINSERT INTO events_processed (event_id, payment_id, processed_at)\n\nVALUES ($1, $2, now())\n\nON CONFLICT (event_id) DO NOTHING;\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A refund needs to touch the ledger, an external bank transfer, and the notification service. How would you coordinate that without a two-phase commit?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">saga pattern<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Two-phase commit doesn&#8217;t hold up well across services owned by different teams with their own databases, the coordinator becomes a single point of failure and it locks resources across a network call, which isn&#8217;t workable at PayPal&#8217;s throughput. I&#8217;d model the refund as a Saga: a sequence of local transactions, each with a matching compensating transaction, coordinated either by a central orchestrator or through choreographed events. Step one reserves the refund amount in the ledger and marks it pending. Step two calls the bank or card network to actually move the money. Step three, on success, finalizes the ledger entry and emits a &#8220;refund completed&#8221; event that the notification service consumes.<\/p>\n<p>If step two fails, the compensating action reverses step one with an explicit reversal entry, never a silent delete, and a &#8220;refund failed&#8221; event goes out instead. The orchestrator has to persist which step a given saga is on, so that if the orchestrator itself crashes mid-refund, a recovery process can pick up from the last known step rather than leaving the refund stuck. The hardest part is making the compensating actions themselves idempotent and safe to run even when you&#8217;re not fully certain the original step completed, because &#8220;no response yet&#8221; from the bank and &#8220;confirmed failure&#8221; are different states, and you can&#8217;t safely compensate a step you don&#8217;t know actually ran.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A customer says they were charged twice for a single $50 checkout. How would you investigate?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">double charge debug<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>First I&#8217;d separate what the customer perceives from what actually happened in PayPal&#8217;s ledger, because a very common cause is the bank showing a pending authorization hold and a separate posted charge on the statement, which looks like two charges but is one transaction settling normally. I&#8217;d pull the transaction id from the ticket and check whether there are genuinely two distinct ledger entries with the same amount and merchant close together in time, or just one transaction the bank is displaying oddly.<\/p>\n<p>If there really are two entries, I&#8217;d look at the client retry path next. Did the checkout page fire a second call because the submit button wasn&#8217;t disabled after the first click, did the client time out and retry the request without an idempotency key, or was an idempotency key present but not actually enforced atomically on the server. I&#8217;d check the logs for two requests with the same idempotency key or client-generated request id in a short window, and I&#8217;d check whether the server&#8217;s idempotency check was a proper unique constraint versus a select-then-insert, since the latter is a classic race that only surfaces under load. Once the root cause is confirmed, the fix is enforcing the idempotency key with a database constraint, disabling the client&#8217;s submit button on click, or both, plus an immediate refund and a reversal entry for the duplicate charge.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A Java payment service throws OutOfMemoryError under peak traffic but runs fine at low load. How would you debug it?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">jvm memory leak<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>First I&#8217;d confirm it&#8217;s an actual leak and not just an undersized heap for peak load, since bursty payment traffic can look identical to a leak until you watch it across a few cycles. If heap usage after each full GC keeps climbing cycle over cycle instead of settling back to a stable baseline, that&#8217;s a real leak rather than a capacity problem.<\/p>\n<p>Once confirmed, I&#8217;d capture a heap dump under load and load it into a tool like Eclipse MAT to check the dominator tree, specifically which object type is retaining the most memory and what&#8217;s keeping it reachable from a GC root.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bash<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bash\">\n\njmap -dump:live,format=b,file=heap.bin &lt;pid&gt;\n<\/code><\/pre><\/div><\/p>\n<p>In payment services, the usual suspects are an unbounded in-memory cache of transaction state with no eviction, a ThreadLocal set per request that never gets cleared and so accumulates on threads that live forever in a pool, event listeners registered on a long-lived bus that are never deregistered when a request finishes, or an HTTP client that isn&#8217;t pooled correctly and keeps accumulating open sockets and their buffers. Once I find the retaining object, I&#8217;d correlate it with a recent deploy, since a service that was stable before almost always traces the leak to one of the last few releases, and I&#8217;d confirm the fix under a load test that mimics real peak traffic before shipping it wider. A flat heap graph over a few hours at replicated peak load is the only real proof, a quick smoke test won&#8217;t catch it.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--scenario\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"scenario\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Real-time scenario questions<\/h2><span class=\"iq-dsec__n\">9<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a stack that supports push, pop, top, and retrieving the minimum element in O(1)<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Data Structures<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Keep two stacks in lockstep. The main stack holds every pushed value normally. The min stack pushes a new value only when it&#8217;s less than or equal to the current minimum, so its top is always the running minimum. On pop, pop from both stacks if the popped value matches the min stack&#8217;s top; otherwise pop only the main stack. getMin becomes a single peek at the min stack&#8217;s top.<\/p>\n<p>Reported as a live coding warm-up before the harder LRU cache question in several PayPal onsite loops. The follow-up worth preparing: how would you do this with O(1) extra space instead of a second stack? Store the difference between each pushed value and the current minimum instead of the raw value, and reconstruct the minimum algebraically on pop. It works but reads far less clearly, and most interviewers are satisfied once you can explain the tradeoff out loud.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">java<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-java\">\n\nimport java.util.*;\nclass MinStack {\n\n    private final Deque&lt;Integer&gt; stack = new ArrayDeque&lt;&gt;();\n\n    private final Deque&lt;Integer&gt; minStack = new ArrayDeque&lt;&gt;();\n    public void push(int val) {\n\n        stack.push(val);\n\n        if (minStack.isEmpty() || val &lt;= minStack.peek()) {\n\n            minStack.push(val);\n\n        }\n\n    }\n    public void pop() {\n\n        int val = stack.pop();\n\n        if (val == minStack.peek()) {\n\n            minStack.pop();\n\n        }\n\n    }\n    public int top() { return stack.peek(); }\n\n    public int getMin() { return minStack.peek(); }\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a RESTful web service for a payment CRUD resource<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">OOP \/ API Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Define resources: POST \/payments to initiate, GET \/payments\/{id} for status, PATCH \/payments\/{id} for updates (limited fields), POST \/payments\/{id}\/refunds for refunds as a sub-resource. Return 201 with a Location header on creation, 200 with the current state on retrieval, 202 Accepted for async operations where the final state isn&#8217;t yet known.<\/p>\n<p>Reported from the managerial round at PayPal SDE II. The interviewer specifically asked about idempotency at the API layer. The answer: the client sends a unique idempotency key in the request header (X-Idempotency-Key), the server stores the key with the response, and subsequent requests with the same key return the cached response rather than executing again. This prevents double charges on network retries.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a notification system for payment events at scale<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Payment events (completed, failed, refunded) publish to Kafka. Notification service consumes, determines preferred channel per user (push, email, SMS), and dispatches. The hard problem: exactly-once delivery is impossible at this layer. Design for at-least-once with deduplication on the consumer side. Each notification has a unique event ID; consumers check a Redis set of sent event IDs before dispatching and mark as sent after. TTL on the Redis set prevents unbounded growth.<\/p>\n<p>Channel-specific concerns: push notifications have low latency but require APNs\/FCM integration and handle device token staleness (tokens expire; the system needs to update or drop dead tokens). Email delivery is asynchronous; use SendGrid or SES with webhook callbacks for delivery status. SMS is the most reliable but most expensive. Priority ordering: push first, email fallback, SMS only for high-value events or explicit user preference.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a rate limiter for PayPal&#039;s public payment API<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Token bucket per API key. Each key gets a bucket with a fixed capacity that refills at a steady rate; a request consumes one token, and a request with no tokens available gets rejected with a 429 and a Retry-After header. The bucket state has to live somewhere every API gateway instance can read and write atomically. A plain in-process counter per instance would let the effective limit multiply by however many gateway nodes happen to be running.<\/p>\n<p>Redis is the usual answer: store the token count and last-refill timestamp per key, and update both atomically inside a Lua script so a burst of concurrent requests can&#8217;t all read stale token counts and all get approved. Sliding window counters, tracking request timestamps in short slices over the last minute, avoid the token bucket&#8217;s tendency to allow a full burst right at the boundary between two fixed windows. PayPal interviewers sometimes ask specifically why a naive fixed-window counter under-protects against burst traffic at the window edge.<\/p>\n<p>Reported at the system design round for backend and platform roles, usually as a shorter, more contained design problem compared to the full payment processing or fraud detection prompts. It pairs naturally with the idempotency discussion covered earlier on this page, since a client that gets rate-limited and retries needs the same idempotency-key handling to avoid a duplicate charge once it&#8217;s allowed through.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nimport time\n\nimport redis\nr = redis.Redis(host=\u2019localhost\u2019, port=6379, db=0)\ndef allow_request(api_key: str, capacity: int = 100, refill_per_sec: float = 10.0) -&gt; bool:\n\n    now = time.time()\n\n    bucket_key = f\u201dratelimit:{api_key}\u201d\n    # Lua script keeps read-refill-write atomic across gateway instances\n\n    script = \u201c\u201d\u201d\n\n    local tokens = tonumber(redis.call(\u2018HGET\u2019, KEYS[1], \u2018tokens\u2019) or ARGV[1])\n\n    local last = tonumber(redis.call(\u2018HGET\u2019, KEYS[1], \u2018last\u2019) or ARGV[3])\n\n    local elapsed = ARGV[3] \u2013 last\n\n    tokens = math.min(tonumber(ARGV[1]), tokens + elapsed * tonumber(ARGV[2]))\n\n    local allowed = 0\n\n    if tokens &gt;= 1 then\n\n        tokens = tokens \u2013 1\n\n        allowed = 1\n\n    end\n\n    redis.call(\u2018HSET\u2019, KEYS[1], \u2018tokens\u2019, tokens, \u2018last\u2019, ARGV[3])\n\n    redis.call(\u2018EXPIRE\u2019, KEYS[1], 3600)\n\n    return allowed\n\n    \u201c\u201d\u201d\n\n    result = r.eval(script, 1, bucket_key, capacity, refill_per_sec, now)\n\n    return result == 1\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a webhook delivery system so merchants get notified when a payment&#039;s status changes<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Use the transactional outbox pattern: when a payment&#8217;s status changes, write the resulting webhook event to an outbox table in the same database transaction as the state change itself, so the event can never get lost between &#8220;the payment updated&#8221; and &#8220;the notification got queued.&#8221; A separate worker pool polls the outbox (or consumes a change-data-capture stream off it) and delivers each event via an HTTP POST to the merchant&#8217;s registered endpoint, signed with an HMAC so the merchant can verify the payload actually came from PayPal and wasn&#8217;t spoofed.<\/p>\n<p>Delivery isn&#8217;t guaranteed to succeed on the first attempt, a merchant&#8217;s endpoint might be down for a deploy. Retry with exponential backoff and jitter, move an event to a dead-letter queue after a fixed number of attempts, and give merchants a dashboard showing delivery history with a manual replay button. This is a different problem from the internal user notification system covered above: merchants need signature verification, a much longer retry window (days rather than minutes), and an audit trail they can inspect themselves.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How would you design a real-time fraud detection system for PayPal transactions?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Three stages: feature computation, scoring, and action. Feature computation runs at two speeds: real-time features (user&#8217;s transaction frequency in the last 5 minutes, device fingerprint match, IP geolocation) computed in the hot path using Redis counters and a feature store; batch features (30-day spending patterns, merchant risk scores) precomputed and stored in a low-latency key-value store. Scoring: a rules engine handles obvious cases (transaction from a new country followed by a large transaction 10 minutes later), an ML model handles ambiguous patterns. The rules engine runs in microseconds; the ML model budget is roughly 50 to 80ms for a sub-100ms total latency target.<\/p>\n<p>Action layer: approved, declined, or sent to step-up authentication (OTP, 3D Secure). Human review queue for high-value ambiguous cases. All decisions, including approved ones, write to an audit log that feeds back into the ML training pipeline. Graph-based analysis (identifying fraud rings where multiple accounts share a device or IP) runs as a background job, not in the real-time path, because graph traversal at PayPal&#8217;s scale cannot fit in a sub-100ms budget.<\/p>\n<p>PayPal operates across 200+ countries and 25 currencies. Interviewers at this company will ask about geographic data residency: transaction data for EU users must stay in EU regions under GDPR. Design your data sharding around user geography, not hash-based partitioning, if compliance is a first-class requirement.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a digital wallet system supporting multi-currency balances<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Data model: one ledger account per currency per user. Never store a single balance field; store a running ledger of credit and debit entries and compute the balance as the sum. This is the double-entry accounting model. It handles rollbacks naturally: a failed transaction produces a compensating credit entry that reverses the debit, and the audit trail is preserved.<\/p>\n<p>Currency conversion: fetch exchange rates from a rate service (cache with short TTL, 1 to 5 minutes, since rates move). Apply conversion at transaction time, lock in the rate, write it to the ledger entry as a field. Never recompute historical rates. For holding multi-currency balances, the user has a balance per currency; conversion from wallet A to wallet B is two ledger entries plus an exchange rate record.<\/p>\n<p>Concurrency: two users sending to the same recipient simultaneously. Use optimistic locking (check-and-increment with versioning) or serialize through a single account&#8217;s write path. At PayPal&#8217;s scale, per-account serialization via consistent hashing to a single shard owner is a common pattern.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a chargeback and dispute resolution workflow for PayPal transactions<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design \/ Fintech<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Model the dispute as its own state machine, separate from the original transaction: opened, evidence_submitted, under_review, resolved_merchant, resolved_buyer, closed. Every transition writes an immutable event to an append-only dispute log, the same pattern as the primary ledger covered earlier, rather than overwriting a mutable status field. That matters because a chargeback decision can itself get reversed on appeal (a &#8220;second presentment&#8221; in card network terms), and an append-only log turns that reversal into just another event instead of a data-integrity problem.<\/p>\n<p>Funds handling: hold the disputed amount in a reserve ledger entry instead of reversing the original transaction immediately. The original transaction stays intact for audit purposes; the reserve entry moves once the dispute resolves. The workflow also has to track the card network&#8217;s own SLA clock, roughly 7 to 45 days depending on the dispute reason code, which means a scheduled job checking for approaching deadlines and escalating, not just a reactive system waiting on network webhooks.<\/p>\n<p>This shows up more at senior and staff PayPal loops than at SDE2, since it touches regulatory reporting (Regulation E in the US covers electronic funds transfer disputes) as much as it touches distributed systems. Interviewers want the double-entry, append-only instinct applied consistently, not a special-cased mutable dispute table bolted onto an otherwise immutable ledger.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How would you design an internal ledger system that enforces double-entry bookkeeping correctness for every PayPal transaction?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">ledger design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Every money movement, a payment, a refund, a fee, a currency conversion, has to post at least two ledger entries: a debit on one account and a matching credit on another, and the entries in a transaction must always net to zero. The foundation is an append-only ledger table that is never updated or deleted in place, only reversed with a new offsetting entry, plus an application-level invariant (or database constraint) that rejects any transaction where debits don&#8217;t equal credits before it commits. I&#8217;d write all entries for one transaction inside a single database transaction where possible, and use a Saga with compensating entries when the write spans multiple services, so a partial posting never sits half-written.<\/p>\n<p>Balances shouldn&#8217;t be recomputed by summing every historical entry on every read, that gets expensive fast at PayPal&#8217;s volume, so I&#8217;d maintain a running balance per account as a materialized value updated incrementally with each posting, then reconcile it against the raw ledger sum in a nightly batch job. That job is the real safety net: it flags any account, or the ledger as a whole, where debits and credits don&#8217;t sum to zero, because a bug anywhere in the pipeline silently breaks money conservation and you want to catch a one-cent discrepancy before it becomes a systemic one. Idempotency keys tied to the originating external event (a card network callback, a webhook retry) stop the same real-world event from posting duplicate entries when it&#8217;s redelivered.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-callout iq-callout--insight not-prose\"><div class=\"iq-callout__title\">What we&#039;ve seen across PayPal loops<\/div><div class=\"iq-callout__body\"><\/p>\n<p>Across PayPal interview preparation sessions on LastRoundAI, the most common gap isn&#8217;t algorithm difficulty. It&#8217;s payments domain blindness. Candidates who can solve any medium LeetCode problem in 20 minutes still stumble when the system design interviewer asks: &#8220;Your payment API call times out after 200ms. The client retries. How do you guarantee the user isn&#8217;t charged twice?&#8221; The answer requires idempotency key handling at the API layer, stored server-side with an atomic write. Candidates who haven&#8217;t thought about this before the interview describe database-level deduplication, which has a race condition window, or say &#8220;we&#8217;d check the database,&#8221; which doesn&#8217;t explain how the check is atomic.<\/p>\n<p>The second consistent pattern: PayPal behavioral rounds go deeper on technical mistakes than most companies. &#8220;Tell me about the biggest mistake you made at your last job&#8221; is followed by &#8220;what was the root cause?&#8221; and &#8220;what did you change structurally afterward?&#8221; Candidates who give a surface-level incident description and then say &#8220;I learned to test more carefully&#8221; don&#8217;t get follow-up offers. The candidates who do well treat the mistake story with the same detail they&#8217;d bring to an incident postmortem.<\/p>\n<p><\/div><\/div>\n<p><script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"FAQPage\",\n  \"mainEntity\": [\n    {\n      \"@type\": \"Question\",\n      \"name\": \"How long does the PayPal interview process take from application to offer?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Most candidates report 3 to 6 weeks. SDE-level loops tend to close in 3 to 4 weeks. Senior and staff loops are slower, typically 4 to 6 weeks, due to team-matching and hiring committee steps after the final onsite.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Is the PayPal OA on HackerRank? What's the format?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Yes. The OA runs on HackerRank. New-grad reports describe 11 questions in 90 minutes: two coding problems (easy to medium DSA) and nine multiple choice questions covering SQL, JavaScript, Java OOP fundamentals, and basic CS concepts. Some experienced hire loops skip the OA entirely.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Do I need to know Java for PayPal interviews?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"For backend and platform roles, Java fluency is strongly recommended. PayPal's core systems are Java-heavy and interviewers ask Java-specific follow-ups: HashMap internals, CompletableFuture, streams and lambda syntax, Spring Boot configuration. For full-stack or newer services teams, TypeScript and Node are common. Python is generally acceptable as the coding language in live rounds.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"How important is fintech domain knowledge for PayPal interviews?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"More important than most SWE candidates expect. The system design round actively tests payments domain knowledge: idempotency, double-entry accounting, ACID properties in distributed systems, fraud detection pipeline design, and PCI DSS at a basic level. Two or three hours reading about idempotency patterns and payment saga flows will put you ahead of the majority of candidates.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Does PayPal do system design interviews for SDE-1 or new grad roles?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Usually not a full formal system design round. New grad loops focus on coding problems and behavioral questions. At SDE-2 and above, a dedicated system design round is standard. Ask your recruiter what rounds your specific loop includes.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"What's the best way to prepare for PayPal's system design round?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Three areas matter most: idempotency and exactly-once semantics in distributed payment flows, double-entry accounting and append-only ledger patterns, and ACID tradeoffs in distributed systems. On top of that, standard system design prep applies: API design, database sharding, caching strategies, and failure mode analysis.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"What are PayPal's software engineer levels and how do interview loops differ by level?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"The ladder runs roughly SDE1, SDE2 (2 to 5 years), Senior SDE, Staff, and Principal, with slight naming differences across business units like Braintree and Venmo. SDE1 and SDE2 loops focus on coding and behavioral rounds. Senior and above add a dedicated system design round, and staff-level loops sometimes split that into a low-level and a high-level design round. Ask the recruiter which level applies before you start prepping.\"\n      }\n    }\n  ]\n}\n<\/script><\/p>\n<div class=\"iq-cta not-prose\"><div class=\"iq-cta__inner\"><div class=\"iq-cta__text\"><div class=\"iq-cta__kicker\">Practice, don't just read<\/div><div class=\"iq-cta__title\">Rehearse a real PayPal interview, live<\/div><p class=\"iq-cta__body\">LastRoundAI runs a realistic mock PayPal interview and gives you real-time guidance on the exact questions above.<\/p><\/div><div class=\"iq-cta__actions\"><a class=\"iq-cta__btn\" href=\"https:\/\/lastroundai.com\/products\/mock-interviews\">Start a mock interview<\/a><a class=\"iq-cta__link\" href=\"https:\/\/lastroundai.com\/products\/company-insights\">See company insights &rarr;<\/a><\/div><\/div><\/div>\n<div class=\"iq-related not-prose\"><div class=\"iq-related__title\">Related interview guides<\/div><div class=\"iq-related__grid\"><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/stripe\"><span class=\"iq-rel__t\">Stripe Interview Questions for Software Engineers (2026)<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/amazon-sde-2\"><span class=\"iq-rel__t\">Amazon SDE-2 Interview Questions (2026): What They Actually Ask<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/google-l4\"><span class=\"iq-rel__t\">Google L4 Interview Questions (2026): What They Actually Ask<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/meta-e5\"><span class=\"iq-rel__t\">Meta E5 Interview Questions (2026): What They Actually Ask<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/system-design\"><span class=\"iq-rel__t\">System Design Interview Questions (2026): Must-Know Q&#038;A<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><\/div><\/div>\n<div class=\"iq-sources not-prose\"><div class=\"iq-sources__title\">Sources &amp; further reading<\/div><ul class=\"iq-sources__list\"><li><a href=\"https:\/\/www.geeksforgeeks.org\/paypal-interview-experience-for-sde-ii\/\" target=\"_blank\" rel=\"nofollow noopener\">GeeksForGeeks PayPal SDE II Interview Experience<\/a><\/li><li><a href=\"https:\/\/www.geeksforgeeks.org\/paypal-interview-experience-for-swe\/\" target=\"_blank\" rel=\"nofollow noopener\">GeeksForGeeks PayPal SWE Interview Experience<\/a><\/li><li><a href=\"https:\/\/www.techprep.app\/blog\/paypal-interview-process\" target=\"_blank\" rel=\"nofollow noopener\">TechPrep PayPal Interview Process 2026<\/a><\/li><li><a href=\"https:\/\/www.systemdesignhandbook.com\/guides\/paypal-system-design-interview\/\" target=\"_blank\" rel=\"nofollow noopener\">System Design Handbook PayPal Guide<\/a><\/li><li><a href=\"https:\/\/www.glassdoor.com\/Interview\/PayPal-Software-Engineer-Interview-Questions-EI_IE9848.0,6_KO7,24.htm\" target=\"_blank\" rel=\"nofollow noopener\">Glassdoor PayPal Software Engineer Interviews<\/a><\/li><li><a href=\"https:\/\/prepfully.com\/interview-guides\/paypal-software-engineer\" target=\"_blank\" rel=\"nofollow noopener\">Prepfully PayPal SWE Interview Guide<\/a><\/li><li><a href=\"https:\/\/algo.monster\/interview-guides\/paypal\" target=\"_blank\" rel=\"nofollow noopener\">AlgoMonster PayPal Interview Guide<\/a><\/li><\/ul><\/div>\n","protected":false},"excerpt":{"rendered":"<p>A candidate who went through PayPal&#8217;s virtual onsite in early 2025 described the process as &#8220;more Java than I expected, more payments context than I studied for.&#8221; He&#8217;d prepared the usual LeetCode medium library and felt fine through the coding rounds. The system design round surprised him. The interviewer wasn&#8217;t interested in designing Twitter. She&#8230;<\/p>\n","protected":false},"author":5,"featured_media":1727,"comment_status":"open","ping_status":"closed","template":"","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"tags":[],"class_list":["post-986","iq","type-iq","status-publish","has-post-thumbnail","hentry"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>PayPal Interview Questions (2026) | LastRoundAI<\/title>\n<meta name=\"description\" content=\"Real PayPal interview questions for 2026: coding, system design, fintech domain, and behavioral. Verified from Glassdoor and GeeksForGeeks reports.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/lastroundai.com\/interview-questions\/paypal\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"PayPal Interview Questions (2026) | LastRoundAI\" \/>\n<meta property=\"og:description\" content=\"Real PayPal interview questions for 2026: coding, system design, fintech domain, and behavioral. Verified from Glassdoor and GeeksForGeeks reports.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/lastroundai.com\/interview-questions\/paypal\" \/>\n<meta property=\"og:site_name\" content=\"LastRound AI\" \/>\n<meta property=\"article:modified_time\" content=\"2026-07-19T05:24:09+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-paypal-og.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"630\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/paypal\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/paypal\",\"name\":\"PayPal Interview Questions (2026) | LastRoundAI\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/paypal#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/paypal#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-paypal-og.png\",\"datePublished\":\"2026-06-26T03:06:16+00:00\",\"dateModified\":\"2026-07-19T05:24:09+00:00\",\"description\":\"Real PayPal interview questions for 2026: coding, system design, fintech domain, and behavioral. Verified from Glassdoor and GeeksForGeeks reports.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/paypal#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/paypal\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/paypal#primaryimage\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-paypal-og.png\",\"contentUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-paypal-og.png\",\"width\":1200,\"height\":630,\"caption\":\"PayPal interview questions \u2014 LastRoundAI\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/paypal#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/lastroundai.com\\\/blog\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Interview Questions\",\"item\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"PayPal Interview Questions (2026): What They Actually Ask\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/\",\"name\":\"LastRound AI\",\"description\":\"Interview Assistant prep, tech careers and AI tools\",\"publisher\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#organization\",\"name\":\"LastRound AI\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png\",\"contentUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png\",\"width\":400,\"height\":400,\"caption\":\"LastRound AI\"},\"image\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"PayPal Interview Questions (2026) | LastRoundAI","description":"Real PayPal interview questions for 2026: coding, system design, fintech domain, and behavioral. Verified from Glassdoor and GeeksForGeeks reports.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/lastroundai.com\/interview-questions\/paypal","og_locale":"en_US","og_type":"article","og_title":"PayPal Interview Questions (2026) | LastRoundAI","og_description":"Real PayPal interview questions for 2026: coding, system design, fintech domain, and behavioral. Verified from Glassdoor and GeeksForGeeks reports.","og_url":"https:\/\/lastroundai.com\/interview-questions\/paypal","og_site_name":"LastRound AI","article_modified_time":"2026-07-19T05:24:09+00:00","og_image":[{"width":1200,"height":630,"url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-paypal-og.png","type":"image\/png"}],"twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/lastroundai.com\/interview-questions\/paypal","url":"https:\/\/lastroundai.com\/interview-questions\/paypal","name":"PayPal Interview Questions (2026) | LastRoundAI","isPartOf":{"@id":"https:\/\/lastroundai.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/lastroundai.com\/interview-questions\/paypal#primaryimage"},"image":{"@id":"https:\/\/lastroundai.com\/interview-questions\/paypal#primaryimage"},"thumbnailUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-paypal-og.png","datePublished":"2026-06-26T03:06:16+00:00","dateModified":"2026-07-19T05:24:09+00:00","description":"Real PayPal interview questions for 2026: coding, system design, fintech domain, and behavioral. Verified from Glassdoor and GeeksForGeeks reports.","breadcrumb":{"@id":"https:\/\/lastroundai.com\/interview-questions\/paypal#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/lastroundai.com\/interview-questions\/paypal"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lastroundai.com\/interview-questions\/paypal#primaryimage","url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-paypal-og.png","contentUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-paypal-og.png","width":1200,"height":630,"caption":"PayPal interview questions \u2014 LastRoundAI"},{"@type":"BreadcrumbList","@id":"https:\/\/lastroundai.com\/interview-questions\/paypal#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/lastroundai.com\/blog"},{"@type":"ListItem","position":2,"name":"Interview Questions","item":"https:\/\/lastroundai.com\/interview-questions"},{"@type":"ListItem","position":3,"name":"PayPal Interview Questions (2026): What They Actually Ask"}]},{"@type":"WebSite","@id":"https:\/\/lastroundai.com\/blog\/#website","url":"https:\/\/lastroundai.com\/blog\/","name":"LastRound AI","description":"Interview Assistant prep, tech careers and AI tools","publisher":{"@id":"https:\/\/lastroundai.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/lastroundai.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/lastroundai.com\/blog\/#organization","name":"LastRound AI","url":"https:\/\/lastroundai.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lastroundai.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/06\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png","contentUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/06\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png","width":400,"height":400,"caption":"LastRound AI"},"image":{"@id":"https:\/\/lastroundai.com\/blog\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/986","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq"}],"about":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/types\/iq"}],"author":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/comments?post=986"}],"version-history":[{"count":4,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/986\/revisions"}],"predecessor-version":[{"id":1847,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/986\/revisions\/1847"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/media\/1727"}],"wp:attachment":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/media?parent=986"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/tags?post=986"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}