Skip to content
Interview Questions

Paypal Interview Experience 2026

Overview

How PayPal fresher interviews usually run, campus and off-campus. The common process map is OA (MCQs + coding) → technical rounds that attach constraints to DSA → SQL/DBMS/OOP depth → HR. Patterns shift by year and role; treat this as a prep map, not a script.

Eligibility (from student reports): 6.0+ CGPA in 10th, 12th, and graduation. Fresher package ballpark (from student reports): ₹12-18 LPA. Confirm on your offer letter. Practise a second solution before you need it, keep SQL warm, and do not confuse positive interviewer tone with an offer - especially off-campus.

How PayPal differs from peer product loops

  • Constraint follow-ups dominate: no hash map, linear time, or three implementations of the same problem.
  • Fresher reports skip heavy payments system design - SQL, keys, and OOPs matter more than ledger design.
  • Remember your OA submissions - later rounds may walk your Round 1 code live.
  • Off-campus timelines are slow; positive rounds can still end in a late rejection email.

Round-wise process

Round Duration What they test
Online Assessment 90 min Coding (DSA) + sometimes MCQs
Technical Round 1 45-60 min DSA with added constraints (no hash map, linear time, alternate implementations)
Technical Round 2 45-60 min SQL, DBMS keys, OOPs, project discussion
HR / Culture 20-30 min Motivation, integrity, relocation

Real interview experiences

Rewritten from public student write-ups of PayPal’s India campus and off-campus hiring. A correction worth stating up front: fresher write-ups do not describe a payments or ledger system-design round. What they consistently describe is DSA with constraints attached (“do it without a hash map”, “now in linear time”, “now give me three different implementations”), plus SQL, DBMS keys, and OOPs. Interviewers ask for the second and third solution after the first one works.

Experience 1: SDE-1, on-campus (selected)

Source pattern: PayPal on-campus write-up

Round 1 - coding (120 min)

  • Count pairs in an array whose sum is divisible by 60.
  • An optimisation problem on placing houses to minimise distance to non-house positions.
  • Complexity analysis was expected alongside a working solution.

Round 2 - technical

  • Started easy: ASCII values and character frequency, then escalated.
  • Find elements unique to each array - but without hash structures, in linear time, given sorted input.
  • Linked list cycle detection, asked for three different implementations.
  • Concepts: primary keys, natural vs surrogate keys, backtracking vs dynamic programming.

Round 3 - technical (over an hour with round 2)

  • Walk through the round 1 solutions live in a HackerRank workspace - so remember what you submitted.
  • Infix to postfix conversion.
  • A light design discussion: explain how Google search works, using abstract classes and a UML sketch.

Round 4 - HR

  • Scenario-based logic problems that still required code, then behavioural questions on aspirations and leadership.

Result: Selected. The write-up reports 5 offers from that campus (4 full-time, 1 intern).

Takeaways

  • What decided it: Constraint-ready DSA plus remembering OA solutions for the live walkthrough
  • Common fail: One working approach with no alternate when asked for three cycle-detection methods
  • How to practise: Solve each medium two ways; keep SQL key vocabulary ready

Experience 2: Software Engineer summer internship 2023, on-campus (selected)

Source pattern: PayPal summer internship 2023 write-up

  • OA on HackerRank: 6 easy MCQs (aptitude, applied DSA, DBMS) plus 2 medium coding problems. 20 candidates advanced.
  • Technical (~40 min): abstract classes, a string-manipulation coding problem with complexity analysis, SQL injection, and a database query asked first with subqueries and then rewritten using joins. Plus an aptitude puzzle and light networking questions.
  • Managerial / HR: introduction, adaptability, a proud moment and a failure, strengths and weaknesses, what you know about PayPal, and handling disagreement in a team.
  • Result: Selected - 8 interns taken from that drive.

Takeaways

  • What decided it: OA MCQ+coding mix cleared, then SQL rewrite (subquery → join) in technical
  • Common fail: Skipping DBMS/aptitude MCQs because the brand feels “coding-only”
  • How to practise: Daily short SQL rewrite drills alongside one string/DSA medium

Experience 3: SDE summer internship, Rajasthan (selected)

Source pattern: PayPal SDE summer internship write-up

OA

  • Six MCQs (OOP, DBMS, networks) plus one hard string problem using a priority queue; candidate cleared 12/15 test cases and was the sole shortlist from their cohort.

Technical (~3 coding problems)

  • Easy DP grid (~10 min), standard LIS DP, then a hard string/stack problem discussed without full coding.
  • Deep project discussion and a short HR-style close on the same call.

Managerial (weeks later)

  • Brain-teasers and real-life scenarios (DBMS concepts, production debugging ideas).
  • Long React/JavaScript deep-dive tied to resume projects; light discussion on work location.

Result: Selected for summer internship. Takeaway: PayPal campus timelines can stretch weeks between rounds - stay warm on DSA and resume depth.

A counter-example worth reading

An off-campus Software Engineer candidate cleared a technical round (search in a rotated sorted array with an O(log n) requirement; find the unique element with an XOR approach) and an HR round covering projects, teamwork, GitHub contributions, SQL joins and OOPs - felt it went well, and was rejected by email about a month later. PayPal’s off-campus timelines are slow and positive interviewer feedback is not a signal. (off-campus write-up linked under Sources)

What recurs across all three

  • SQL is asked in every account - joins especially, often twice in different forms.
  • Expect follow-up constraints, not follow-up problems. Have a second approach ready before you’re asked.
  • The OA is a mix of MCQs and coding, not pure coding. Do not skip DBMS and aptitude revision.

Pre-interview checklist (PayPal)

  • Confirm OA mix: MCQs + coding vs coding-only from the drive mail
  • Drill DSA with forced second approaches (no hashmap / O(n) / alternate structures)
  • Revise SQL joins, keys, injection, and OOP abstract classes
  • Rehearse walking your OA solutions aloud without notes
  • STAR stories for adaptability, disagreement, and a failure - plus Why PayPal
  • Mentally plan for multi-week gaps between rounds on some campuses

Questions that come up often

Coding / technical

  1. Design an LRU cache. Usually expects HashMap + doubly linked list
  2. Implement a rate limiter. Usually expects sliding window / token bucket
  3. Merge overlapping time intervals. Usually expects sort + sweep
  4. Discussion on cross-border payments and risk checks, bottlenecks, failure modes, simple APIs
  5. Detailed project discussion, architecture, hardest bug, what you would change

HR / behavioural

  1. Why fintech / payments?
  2. A production bug or outage you helped with
  3. An integrity / pressure scenario
  4. Joining timeline

Practical tips for Paypal

  • Clear the screening round first. Timed practice beats last-minute topic hopping.
  • For domain questions, explain cross-border payments in plain language, inputs, outputs, what breaks at scale.
  • OOPs and SQL still open a lot of PayPal panels. Do not skip fundamentals.
  • HR answers should be concrete. One story with a result beats five slogans.
  • If you do not know something, say so and outline how you would find out.

HR interview

After technical rounds, PayPal usually closes with a short HR / hiring-manager conversation: motivation, location, notice period, and a couple of behavioural stories. Prepare those answers on the dedicated page rather than cramming them into this hub.

Sample answers for high-frequency questions

Use these as frames, not scripts - interviewers probe follow-ups.

Q. How do you design an LRU cache, and why HashMap plus doubly linked list?
A. 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?
A. 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?
A. 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?
A. 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?
A. 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.

Tips from successful candidates

Assessment tips

  • Confirm the current PayPal pattern from the drive mail before practising old papers
  • Finish one problem or section fully before starting the next
  • Revise the fundamentals listed in the round table on this page

Interview tips

  • Narrate trade-offs; expect “why” after every answer
  • Only list projects you can defend under follow-ups
  • Prepare 3-4 STAR stories for behavioural prompts

HR tips

  • Know why PayPal, not just why the industry
  • Be clear on location / notice period / higher studies
  • Practise answers on the dedicated HR page

Sources

These links are research inputs we used to map constrained DSA loops, SQL emphasis, and timeline variance - not copied page mirrors. We reorganized reports into process notes, takeaways, and a prep checklist for PayPal.

Cross-check the current drive mail for timings and section mix.

For the company overview, see the PayPal hub. For behavioural frames, use the HR page. For OA drills, see PayPal placement papers.

PayPal hub

HR interview questions

Placement papers

Preparation guide

Similar companies

Google · Amazon · Microsoft · Meta · Capital One · Goldman Sachs