← Back to Directory

PayPal interview notes, page 7 of 10

Large Enterprises

Most of these PayPal write-ups come from Data Scientists (53), then Software Engineers (22) and Product Managers (10). The most reported rounds are the technical phone screen (60), the system design round (11), the product sense round (9) and the hiring manager screen (3).

91 interview notes · updated Jul 2026

PayPal·Product Manager·Onsite - Product Sense / Strategy

Jun 2026
PayPal PM interview, got a product design question about Venmo. Pretty standard fintech product sense round, nothing too wild.
  • How would you improve Venmo? What features would you build and why?

“I went straight to social features since that's Venmo's whole thing, but halfway through I realized I hadn't talked about monetization at all and the interviewer was clearly waiting for it.”

View Post

PayPal·Software Engineer·Technical Phone Screen

Jun 2026
PayPal technical phone screen for a software engineer role, pretty much a deep dive into Java concurrency. One question, but they really wanted you to go far with it.
  • Is Java's HashMap thread-safe? Walk through how ConcurrentHashMap achieves both thread safety and performance in modern JDKs, including things like lock striping, CAS operations, non-blocking reads, how it handles high collision scenarios, and its resizing behavior. When would you pick one over the other?

“Started fine.”

View Post

PayPal·Data Scientist·Technical Phone Screen

Jun 2026
PayPal data scientist interview with a pandas-heavy coding question. Nothing too exotic but the two-part structure meant you had to get both pieces right, and the second part tripped me up more than I expected.
  • Given a DataFrame of user transactions, write a function that filters out any user who has fewer than 100 transactions in any single calendar month. Then write a second function that computes the average time between consecutive transactions in seconds for each user who survives the filter.

“The first part was fine.”

View Post

PayPal·Data Scientist·Technical Phone Screen

Jun 2026
SQL-heavy technical screen for a Data Scientist role at PayPal. The questions were all about conditional aggregation and filtering, which sounds basic until you're being asked to explain the difference out loud under pressure.
  • Write a SQL query to compute the total amount for rows meeting a specific condition. Compare using SUM with a WHERE filter versus SUM(CASE WHEN ... THEN ... END) for conditional aggregation.
  • Rewrite a SUM with WHERE filter query using CASE WHEN for conditional aggregation instead.
  • In a grouped SQL query, can you place an aggregation condition in the HAVING clause? Does this syntax work in MySQL specifically, and why?

“I knew both approaches but fumbled explaining when you'd actually prefer one over the other.”

View Post

PayPal·Data Scientist·Technical Phone Screen

Jun 2026
PayPal data scientist interview that went deep into fraud risk, cold-start strategy, and adversarial modeling. Pretty involved for what I expected to be a more standard DS screen. Came out of it feeling like I'd half-nailed it and half-winged it.
  • You're given feature summaries for two card transactions (merchant category, amount, velocity, geolocation, device fingerprint, account tenure, historical approval and chargeback rates). Decide whether to approve or decline each one, and justify your reasoning.
  • Design a simple risk strategy for cold-start users: propose concrete rules including velocity checks, geo-velocity, MCC limits, block and allow lists, and step-up authentication. Define thresholds and escalation paths, and discuss the loss-friction trade-off and its expected impact on approval rate, chargeback rate, and false positive rate.
  • Model adversary behavior: what tactics would a fraudster use (card testing, mule addresses, BIN attacks, device spoofing), and how would you detect when they've adapted to your rules? How would you update your detection logic in response?

“I liked this more than I expected to.”

View Post

PayPal·Data Scientist·Technical Phone Screen

Jun 2026
PayPal DS interview that was basically a full experiment design case study for their fraud/ATO team. Dense, technical, and they expected you to actually run the numbers live, not just talk about them conceptually. Walked away feeling like I'd taken a stats exam.
  • For a new real-time account takeover rule that blocks high-risk transfers, how would you choose the randomization unit for an A/B test, and how would you handle spillover given that recipients can overlap across users?
  • Compute the minimum per-arm sample size to detect a 20% relative reduction in fraud rate using a two-sample proportion Z-test, then inflate it using the design effect formula with the given ICC and cluster size.
  • Translate the detectable effect into an expected weekly net dollar impact, accounting for both fraud losses prevented and the cost of incorrectly blocking legitimate transfers.
  • Define the primary, secondary, and guardrail metrics for this experiment, including precise denominators and how you'd slice results across user segments.
  • Propose a ramp plan and stopping rules using a group sequential design, and describe how you'd monitor for drift after the rule goes to full production.

“This is where I spent the most time and probably lost some points early.”

View Post

PayPal·Machine Learning Engineer·Onsite - System Design / Architecture

Jun 2026
PayPal ML engineer interview focused entirely on a deep system design problem around fraud detection. One question but it covered a lot of ground, and I left feeling like I only scratched the surface on a few parts.
  • Design a complete fraud detection system from scratch, covering how you'd label training data given that fraud confirmations are delayed and rare, how you'd handle extreme class imbalance, what features you'd use (behavioral, graph-based, device signals, merchant patterns), what models you'd pick and why, how you'd serve predictions in real time with latency constraints, how you'd set decision thresholds given the precision/recall tradeoff, what metrics you'd evaluate on, and how you'd monitor for drift and adversarial adaptation over time.

“This was basically a 45-minute design marathon in one prompt.”

View Post

PayPal·Data Scientist·Technical Phone Screen

Jun 2026
Got a product DS case for PayPal, though the question itself was very Uber Eats flavored. It was a full end-to-end experiment design case covering goal setting, metrics, experiment design, risks, and a decision framework. Dense question, not a lot of time to breathe.
  • Uber Eats is thinking about adding an optional donation feature at checkout. As the DS owner, walk through your full evaluation plan: goals and hypotheses, metrics, experiment design, risks, and how you'd make the launch decision.

“This is a beast of a question.”

View Post

PayPal·Data Scientist·Technical Phone Screen

Jun 2026
PayPal data science interview centered on a single meaty scenario about contact syncing as a growth metric. The whole thing was one multi-part question that kept branching, which I wasn't totally prepared for.
  • How would you make the '% of users with contacts synced' metric compelling and meaningful to non-technical stakeholders?
  • Walk through a framework for setting a realistic 2025 target for this metric.
  • In an A/B test, the contact syncing metric goes up but your core business metric doesn't move. How do you investigate and respond?
  • If running an A/B test isn't feasible, what causal inference methods would you use to estimate the impact of contact syncing on business outcomes?

“I went straight to connecting it to retention and activation, which felt right, but I fumbled explaining why it matters more than raw counts.”

View Post

PayPal·Data Scientist·Technical Phone Screen

Jun 2026
Got a product case for a Data Scientist role that was way more end-to-end than I expected. It covered everything from product intuition to experiment design to quasi-experimental fallbacks, and I definitely ran out of steam toward the end.
  • Instacart is partnering with a grocery store to launch a smart cart that shows both the current store's prices and prices from nearby stores on the Instacart app. Is this a good product idea? Walk through your reasoning, what objective it serves, and the key risks.
  • Propose testable hypotheses for how the smart cart could affect the business, including both positive effects and potential negatives like cannibalization of the partner store, choice overload, or price perception issues.
  • Define a measurement plan with a primary success metric, a few diagnostic metrics, and guardrail metrics. Be explicit about attribution windows and whether you're measuring at the trip level or the user level.
  • Design an A/B test to measure causal impact. Cover your unit of randomization and why, how you'd handle interference or spillovers in a shared physical store environment, instrumentation needs, power and MDE considerations, and key threats to validity.
  • If a clean randomized experiment isn't feasible, what quasi-experimental approach would you use and what assumptions would you need to validate?

“I liked this part actually.”

View Post