Interview experience
PayPal interview experiences covering Online Assessment, Technical Round 1, Technical Round 2, HR / Culture. Round-wise notes, common questions, and what candidates report clears each stage.
PayPal Interview Questions and Answers (2026)
PayPal is a global digital payments and fintech company founded in 1998, operating in over 200 countries. India engineering hubs in Chennai, Bengaluru, and related sites build payment processing, fraud detection, and platform services. PayPal is a strong campus recruiter for backend and full-stack engineering roles.
Explore: Interview experience · HR interview questions · Overview · Placement papers · Preparation guide
Overview
PayPal’s SDE process for its India engineering centers runs a coding-and-aptitude OA into two technical rounds that get progressively more payments-domain-specific, closing with a culture-fit HR round.
HR interview questions
PayPal HR interview questions with sample answer frameworks - motivation, relocation, STAR stories, and culture-fit prompts.
PayPal interview process at a glance
| Round | Duration | What they test |
|---|---|---|
| Online Assessment | 90 min | Aptitude, technical MCQs, 1-2 DSA coding problems |
| Technical Round 1 | 45-60 min | DSA (LRU cache, rate limiter) + payments-domain discussion |
| Technical Round 2 | 45-60 min | System design (ledger/payments), APIs, failure modes |
| HR / Culture | 20-30 min | Motivation, integrity, relocation |
PayPal online assessment: quick answers
These answers are compiled from public candidate reports and prep guides, not from an official notice, and drives differ. The instruction screen of your own test is the final word.
| Question | Answer |
|---|---|
| How many questions and how long? | Reports conflict. A 2026 SWE-intern report from a tier-2 college describes a 45-minute test with 1 DSA question and 5 basic CS MCQs, the same across India for that hiring program. Other campus reports describe about 6 MCQs plus 1-2 coding problems in 90 minutes, and prep guides quote 90-120 minutes with aptitude, reasoning and 2-3 coding problems. |
| Does it have negative marking? | No public report mentions any. Check the instruction screen, since MCQs are a small part of the score and the coding problem decides most shortlists. |
| Is there a sectional cutoff? | Not published. The MCQs are few and easy in recent reports, so the coding question carries the shortlist. |
| How much is the cutoff? | Not published; shortlists are relative to the batch. Candidate-reported eligibility is about 60% or 6.0+ CGPA across 10th, 12th and degree with no active backlogs. |
| Which platform is it on? | HackerRank in most reports; one prep guide also mentions Mettl. The test is proctored. |
| Is there coding? Which topics? | Yes - 1-2 problems in campus tests, medium in most reports. Reported problems include a greedy string problem solved with a priority queue, counting subarrays, a grid-painting count, and a disjoint-set-union question. Some 2026 Bengaluru lateral OAs set two hard tree and graph problems in 90 minutes. |
| Is SQL tested? | Often in interviews. Several Bengaluru intern candidates were asked to write SQL queries live on HackerRank. |
PayPal interview questions by role
These themes come from candidate reports on Glassdoor, LeetCode Discuss and PrepInsta. They show the level and style, not a fixed list.
| Role | Reported questions and topics |
|---|---|
| SWE intern (hiring program) | A 45-minute technical round with 2 DSA questions on greedy and graph problems, plus a review of CS fundamentals (2026 report). |
| SDE intern (Bengaluru, Chennai) | Check whether two strings are anagrams (hashing, LeetCode easy), then personal projects and live SQL on HackerRank. DSA questions and puzzles in round 1, projects and DSA in round 2, then a technical-plus-managerial round. OOP and DBMS throughout. |
| SDE (campus fresher) | Find the missing number in an array, OOP and DBMS questions, and REST API questions from your resume (2024 Bengaluru campus). ReactJS, networking and two array/stack problems in 30 minutes (2023 Chennai campus). |
| SDE-2 / experienced | Three OA problems on arrays, strings and greedy logic; LRU cache, rate limiter and ledger design in interviews. |
Asked across every role: your projects end to end, SQL, OOP and DBMS basics, and why PayPal and payments.
Online Assessment
A 90-minute test mixing aptitude with technical MCQs and 1-2 DSA coding problems on a platform like HackerRank. Clean, fully-passing solutions beat partial cleverness - shortlist decisions typically arrive within a few days. Campus write-ups often cite 6 easy MCQs (aptitude, applied DSA, DBMS, networks) plus 1-2 medium coding problems; some SDE-2 loops report three OA problems (array/string and greedy-style) on the same timer.
Eligibility (candidate-reported): ~6.0+ CGPA across 10th, 12th, and degree; active backlogs usually disqualify - confirm the placement cell mail for your drive.
Common questions
- Array/string manipulation problems, easy-medium difficulty
- Technical MCQs on OOPs and core CS fundamentals
- One timed coding problem where edge-case handling is scored explicitly
Technical Round 1
Opens with a coding problem, then moves into a domain conversation. Candidates consistently report being asked to design an LRU cache and implement a rate limiter, followed by a discussion connecting the solution to real payments infrastructure.
Common questions
- Design an LRU cache - expected approach: HashMap + doubly linked list, with complexity analysis
- Implement a rate limiter - sliding window or token bucket, and trade-offs between them
- Merge overlapping time intervals - sort, then sweep
- Explain cross-border payments and risk checks in plain language: inputs, outputs, what breaks at scale
- Detailed project discussion: stack choice, hardest bug, what you’d rebuild
Technical Round 2
The more design-heavy round, often framed around ledger or payments-style systems at a fresher-appropriate depth - simple bottleneck stories and clear API/data-flow thinking matter more than distributed-systems jargon.
Common questions
- Design a simplified ledger system: what data you’d store, and how you’d avoid double-processing a transaction
- Walk through the APIs and failure modes for a payments-style system
- How would you detect and handle a duplicate or retried payment request?
- Further project deep-dive with architecture-level questions
Full round-by-round narratives are on the PayPal interview experience page.
HR / Culture round
A closing 20-30 minute conversation on motivation for fintech/payments, integrity under pressure, and logistics. Interviewers want concrete stories with a clear result, not slogans.
Common questions
- Why fintech/payments, and why PayPal specifically?
- Tell me about a production bug or outage you helped resolve
- Describe an integrity or pressure scenario you navigated
- Are you flexible on joining timeline and location?
Sample answer frameworks for each of these are on the PayPal HR interview questions page.
PayPal SWE intern hiring program vs campus SDE drives
PayPal India hires freshers through two routes that look different on paper.
The SWE intern hiring program runs a single short online test across India (one 2026 report: 45 minutes, 1 DSA question and 5 basic CS MCQs), then one or two technical interviews. The campus and lateral SDE drives run a longer HackerRank test (about 90 minutes, MCQs plus 1-2 coding problems), two technical rounds that move into LRU cache, rate limiter and ledger design, and an HR round.
Both lead to software roles at PayPal’s Bengaluru, Chennai and Hyderabad centres. This page covers both; your invite mail tells you which test you are taking.
Common technical interview questions and answers
Q: How do you design an LRU cache, and why HashMap plus doubly linked list?
Keep a hash map from key to node for O(1) lookup, and a doubly linked list ordered with the most-recently-used entry at the head and the least-recently-used at the tail. On get, find the node through the map and move it to the head. On put, insert at the head and, if the size exceeds capacity, unlink the tail node and remove its key from the map. The doubly linked list is essential because unlinking an arbitrary node in O(1) requires both prev and next pointers - a singly linked list would need an O(n) scan to find the predecessor. Both operations are O(1) with O(capacity) space.
Q: Implement a rate limiter. What are the trade-offs between token bucket and sliding window?
Token bucket stores a token count and a last-refill timestamp per client; tokens accrue at a fixed rate up to a burst capacity and each request consumes one, so it allows controlled bursts and needs only two numbers per key - cheap to store in Redis. A fixed-window counter is simplest but permits double the intended rate at a window boundary, since a client can spend its full quota at the end of one window and again at the start of the next. Sliding-window log stores every request timestamp, which is exact but memory-heavy; sliding-window counter interpolates between the previous and current window and is the usual compromise. For distributed enforcement, run the check-and-decrement as an atomic Redis Lua script so concurrent nodes cannot both pass the same last token.
Q: How do you merge overlapping intervals?
Sort the intervals by start time, then sweep left to right holding a current merged interval. For each next interval, if its start is less than or equal to the current interval’s end, extend the current end to the maximum of the two ends; otherwise push the current interval to the result and start a new one from this interval. Sorting dominates at O(n log n) time, with O(n) space for the output or O(1) extra if you merge in place. The edge case interviewers probe is touching intervals such as [1,3] and [3,5] - decide explicitly whether they merge and state your assumption.
Q: How would you design a simplified ledger so a transaction is never double-processed?
Use double-entry accounting: every transfer writes two rows to an append-only ledger_entries table - a debit on one account and a credit on the other - inside a single database transaction, so the sum of all entries always nets to zero and imbalance is immediately detectable. Never update or delete a ledger row; a reversal is a new compensating pair of entries, which preserves the audit trail regulators require. Give the transfer request a client-supplied idempotency key stored under a unique index and inserted in the same transaction as the entries, so a retry hits the constraint violation and returns the original result instead of posting a second pair. Account balances are then either derived by summing entries or kept in a materialised balance row updated in the same transaction.
Q: What is idempotency and how do you make a payment API idempotent?
An idempotent operation produces the same outcome and the same single side effect however many times it is invoked with the same input - critical in payments because a client that times out cannot tell whether the charge succeeded. The standard implementation has the client generate a unique Idempotency-Key (a UUID) per logical operation and send it as a header. The server attempts to insert that key into a uniquely indexed table within the same ACID transaction that performs the charge; if the insert succeeds it processes the payment and stores the serialized response against the key, and if it fails on the unique constraint it returns the stored response. Doing the existence check and the charge as two separate steps reintroduces the race under concurrent retries, so the atomicity of the single transaction is the whole point.
Q: Explain ACID properties and which one matters most for a funds transfer.
Atomicity means a transaction either fully commits or fully rolls back - a debit without its matching credit can never persist. Consistency means the transaction moves the database from one valid state to another, respecting constraints such as a non-negative balance. Isolation means concurrent transactions do not observe each other’s partial state, controlled by isolation levels from READ COMMITTED up to SERIALIZABLE. Durability means once committed, the change survives a crash, guaranteed by the write-ahead log. For a funds transfer atomicity is the headline, but isolation is the subtler risk: at READ COMMITTED two concurrent withdrawals can each read the same balance and both succeed, so you need SELECT ... FOR UPDATE row locking or an optimistic version check.
Q: What happens end to end in a cross-border payment, and what breaks at scale?
The payer’s instruction is authorised and risk-scored, funds are debited in the source currency, an FX rate is quoted and locked for a validity window, the amount is converted, and the beneficiary is credited in the destination currency through a correspondent bank or local scheme, with settlement between institutions happening separately and later than the user-visible confirmation. Compliance screening - sanctions lists, AML rules - sits inline and can hold a payment for review. What breaks at scale is mostly the asynchronous boundaries: downstream schemes have cutoff times and differing settlement windows, FX rates move between quote and settlement, and any leg can time out ambiguously - which is exactly why idempotency keys, reconciliation jobs comparing internal ledger against scheme statements, and explicit compensating reversals matter more than raw throughput.
Q: How would you detect and handle a duplicate or retried payment request?
First line of defence is the idempotency key described above, deduplicating at the API boundary before any money moves. Second, enforce a unique constraint in the database on a natural business key - for example (payer_account, beneficiary_account, amount, client_reference) - so a duplicate that slips past the key layer still cannot post twice. Third, make retries safe by design: use exponential backoff with jitter so a thundering herd does not amplify the problem, and cap retries before routing to a dead-letter queue for manual review. Finally, run a reconciliation job that compares your ledger against the payment processor’s settlement report daily and flags mismatches, because the genuinely dangerous case is a charge that succeeded downstream but whose response never reached you.
Q: How do you approach resolving a production issue under user impact?
Stabilise first: stop bleeding (rollback, feature flag off, or rate-limit the bad path) while preserving logs. Triage in parallel - metrics and traces to find the failing dependency, recent deploys, and whether money or PII is at risk. Communicate a short status to stakeholders on a fixed cadence even when the root cause is unknown. Fix with the smallest safe change, verify in staging or canary, then roll forward. Afterward, write a blameless postmortem with detection gaps and one preventive action (alert, runbook, or automated test). PayPal behavioral rounds often map directly to this sequence.
Q: Sketch a high-level design for a “send money” payment service.
Clients call a REST API with payer, payee, amount, currency, and an idempotency key. An orchestration service validates balances and limits, writes pending ledger entries in one DB transaction, calls the external rail (card, bank, wallet), then marks the transfer captured or failed - never leaving an orphan debit. Async workers handle notifications and settlement files; a reconciliation job compares internal state to processor reports. Scale reads with replicas; keep the write path strongly consistent on the ledger. Non-functional requirements to mention: fraud scoring inline, audit logging, and PCI scope boundaries for card data.
Frequently asked questions about PayPal interviews
Does the PayPal online assessment have negative marking?
No public candidate report mentions negative marking. The PayPal OA is a proctored HackerRank test where a handful of easy CS MCQs sit alongside 1-2 coding problems, and the coding problems decide most shortlists.
What is the PayPal online assessment pattern?
Reports conflict by hiring route. A 2026 SWE-intern hiring-program test was 45 minutes with 1 DSA question and 5 basic CS MCQs; campus SDE drives describe about 6 MCQs plus 1-2 medium coding problems in 90 minutes on HackerRank. Cutoffs are not published.
What is the PayPal interview process for freshers?
PayPal’s SDE/backend process typically runs 3-4 stages: 1. Online Assessment (90 minutes) - aptitude, technical MCQs, and 1-2 DSA coding problems. 2. Technical Interview 1 (45-60 min) - DSA coding (LRU cache, rate limiter style problems) plus backend/payments-domain discussion. 3. Technical Interview 2 (45-60 min) - system design, often payments/ledger flavored. 4. HR/Culture round (20-30 min) - motivation, integrity, relocation. Total duration: roughly 2-3 weeks from application to offer.
What questions are asked in PayPal interviews?
Reported technical questions include designing an LRU cache (HashMap + doubly linked list), implementing a rate limiter (sliding window/token bucket), and merging overlapping time intervals (sort + sweep), alongside deep resume/project walkthroughs. Domain discussion centers on cross-border payments and risk checks - candidates who explain these in plain language (inputs, outputs, what breaks at scale) do better than those reaching for buzzwords. HR rounds check ownership, integrity under pressure, and why fintech.
How many rounds are there in the PayPal interview?
Usually 4 stages: Online Assessment (90 min), Technical Round 1 (45-60 min), Technical Round 2 (45-60 min), HR/Culture (20-30 min). Some drives skip a round or merge HR with managerial. Check that cycle’s college placement email or offer communication.
How should I prepare for PayPal interviews?
Practise timed DSA (arrays, hashing, linked lists - LRU cache and rate-limiter design come up repeatedly), revise OOPs and SQL, and prepare one crisp, defensible project narrative covering your stack choices and hardest bug. Read up on cross-border payments and risk checks so you can discuss the domain in plain language rather than jargon, and use STAR for behavioural answers.
Does PayPal ask system design questions at the fresher level?
Yes, in a lighter form. Technical Round 2 leans into system-design-adjacent discussion - candidates report being asked about ledger design, APIs, and failure modes for a payments-style system - but at a fresher depth: simple bottleneck stories and clear data-flow thinking matter more than distributed-systems jargon.
What is PayPal’s HR round like?
A 20-30 minute conversation on motivation for fintech/payments, integrity under pressure, and logistics. Common questions include ‘why fintech/payments,’ a production bug or outage story, and an integrity/pressure scenario. Keep answers structured - situation, action, result - rather than open-ended narratives.
What PayPal interviewers score
Payments-company loops reward correctness under money constraints. Across OA, coding, and behavioural/HM rounds, panels score:
- Edge-case-complete DSA with stated complexity (arrays, hashing, trees, graphs, DP).
- Reliability thinking when design appears - idempotency, retries, money as integer cents/BigDecimal (not floats), auditability.
- Trust and ownership in behavioural answers - incidents, customer impact, pushing back on risky ships.
Soft fail modes: floating-point money math, solutions that ignore duplicate webhooks, or HR answers with Action but no measurable Result.
Does PayPal care about money precision in coding rounds?
Candidate-facing guides emphasise correctness for payment-like problems: prefer integer cents or decimal types over binary floats, call out idempotent retries, and handle duplicate requests. Even when the prompt looks like a generic DSA question, narrating those invariants is a positive signal.
How to prepare for PayPal interviews
- Loop map: Online Assessment; Technical Round 1; Technical Round 2; HR / Culture. Confirm timings from the drive mail.
- Technical depth: Drill the Q&A section until answers are spoken, not read. Know every resume project cold.
- Experiences: Study round-wise notes on the interview experience page - real prompts beat generic lists.
- HR: Three STAR stories + a specific “Why PayPal?” on the HR page.
A practical PayPal prep plan
Use this as a default four-week loop before a PayPal drive. Adjust to your invite timeline.
- Week 1: Timed aptitude + one easy coding problem a day, plus a one-page cs fundamentals sheet. Open the PayPal previous-year sets on this site and mark which sections ate your time. Write the timing on a sticky note. That number is more useful than a 200-problem LeetCode streak you never timed.
- Week 2: Most PayPal drives fail people on the first timed paper or OA. Do three timed sits this week. After each one, log every miss in a two-column note: topic and why (slow, wrong formula, bad edge case, panic). The next sit should only add problems from that log.
- Week 3: Technical interviews at PayPal usually want a clean project story, one or two CS fundamentals, and (if the process has it) a behavioral or values round. Write STAR stories on paper, not in your head. Practise “Why PayPal?” with one concrete product, lab, or business line - not a slogan.
- Week 4: Two full mocks, then only error-log topics - no new patterns. If you still have energy, redo only the questions you failed in week 2.
10-day crash version: Days 1-4 timed DSA, days 5-7 resume projects + CS fundamentals, days 8-9 mock interviews out loud, day 10 HR STAR stories on the HR page.
Compensation notes
Candidate-reported fresher/early-career packages for PayPal often cite SWE ₹12-18 LPA. Treat forum numbers as ranges, not guarantees - confirm the written offer letter for your team and location.
Sources
Interview process details and sample questions on this site are editorially organized from public candidate reports and hiring write-ups, with round structure, prep notes, and company-specific framing added by our team. For round-by-round stories, see the PayPal interview experience page. For OA papers and coding drills, use PayPal on placementpapers.app. OA quick answers and role-wise questions draw on Glassdoor candidate reviews for PayPal Bengaluru and Chennai (2023-2026), a 2026 SWE-intern report on LeetCode Discuss, PrepInsta’s PayPal interview experience and FACE Prep’s PayPal recruitment pages.
Also prepare for
Guides often searched alongside this page: Stripe interview questions · Visa interview questions · Mastercard interview questions · PhonePe interview questions · Paytm interview questions · Amazon interview questions.