Real, anonymized candidate journeys from recent (2025) PayPal SDE-2 and senior SDE-3 loops — round by round, including what was asked, how the candidate approached it, and the outcome.
One complete journey, start to finish
Round 0 — HackerRank OA
A recruiter found my profile and sent a HackerRank link the same week. It was a standard DSA screen — a couple of problems of the usual kind, arrays and strings, with hidden test cases. I did it on a weeknight after work. I started with the problem that looked simplest, got it passing, then moved to the second one, which needed sorting plus a two-pointer pass. I dry-ran the second solution on the sample once before submitting because off-by-one mistakes are where I usually lose points. Both passed all visible tests. There was nothing about frontend in the screen, even though my profile was full-stack — it was purely coding. I heard back within a few days that I had cleared it, and then the scheduling started. That part turned out to be the slow bit: the first DSA round was set up, moved once, and then finally happened about ten days after the screen.
Round 1 — DSA (Java)
The first live round was an hour on a video call with a shared code editor, and the interviewer asked me to use Java since that was on my resume. He gave me two problems. For the first one I explained the brute-force approach in a sentence, said why it would be too slow, and then wrote the optimized version with a hash map. He asked me to walk through it on a small input, which I did line by line. The second problem was a bit harder and involved recursion; I wrote the recursive version first, then he asked about the time complexity and whether repeated work could be avoided, so I added memoization. Near the end he asked a couple of Java-specific questions about the collections I had used and why I picked them. We finished right on time. It was a fairly standard round — no tricks, just clear communication and clean code.
Round 2 — Coding (Java + SQL)
The second coding round was two days later and was denser than the first. The interviewer had a list and moved through it quickly. First was longest palindromic substring — I wrote the expand-around-center version and explained the O(n²) bound. Then counting subsequences that meet a sum condition, which I did with sorting and two pointers after first describing the slow approach. Then decoding a bracket-encoded string like 3[a2[c]] — I used a stack of previous-string and count pairs and traced it on the example to show accaccacc. Then combination sum with backtracking; she asked how I avoided duplicate combinations and I pointed at the start index. At the end there was a SQL question: write a query joining two tables and grouping to get a per-customer count, and then she asked what changes if I need customers with zero orders, so I switched to a LEFT JOIN. Five questions in one hour was tiring, but I finished them all.
Round 3 — System Design
System design came the following week after one reschedule. The prompt was to design a shopping cart system. I started by asking about scale and whether carts had to survive across devices, and he said yes, assume logged-in users on web and mobile. I drew the tables first — users, carts, cart_items, products — and then the APIs: add item, update quantity, remove item, get cart. Then he asked what happens if the same user taps add on two devices at once. I talked about a version column on the cart row and rejecting stale writes. Next he asked where Redis fits, and I explained caching the assembled cart per user with a short TTL and writing through to the database. Then we went into SQL versus NoSQL for the cart itself, and I said a document per cart is a natural fit but I would keep orders relational. Finally he asked how I would shard and index — shard by user id, index cart_items on cart id. It ended a few minutes over.
Round 4 — Role Specialization / Career Discussion
This round was different from the others — no code, no whiteboard. The interviewer was from the team I was being considered for, and she had my resume open. She asked me to walk through my career from the start: which projects were backend, which were frontend, and how I ended up doing both. I went in order — my first job was mostly Java services, then a product where I owned the React side too, then a role where I did both. She asked which side I enjoyed more and where I wanted to grow, and I answered honestly that I liked owning a feature end to end. Then she asked about one project in detail: why we chose the stack we did, what broke in production and how we fixed it. It was about 45 minutes and felt like a normal conversation. Because my profile covered both areas, she said the team would add a couple of frontend-specific rounds, which is why the loop got longer.
Round 5 — Front-End Technical Deep Dive
The frontend deep dive was scheduled about a week later and was rapid-fire. The interviewer started with promises: how chaining works, what happens to an error thrown inside a then, and the difference between Promise.all and Promise.allSettled. Then React hooks — when useEffect runs, what the dependency array does, and a small example where I had to spot a stale closure. Then array methods: he gave a small data-transformation task and I wrote it with map, filter and reduce in the shared editor. After that came call, apply and bind, with a quick question on what this points to in each case. Then throttling versus debouncing — I explained both and wrote a debounce function. The last stretch was about infrastructure: what a CDN actually does for a frontend build and how CORS works, including preflight requests and which headers matter. It was an hour and I did not get everything perfect, but I could explain the reasoning for each.
Round 6 — Front-End Architecture
The architecture round came right after, a couple of days later. It began with JavaScript fundamentals — the event loop, how microtasks and macrotasks are ordered, closures, and prototypal inheritance — asked as short questions with follow-ups when my answer was vague. Then the interviewer moved to architecture. She described a large frontend application and asked how I would structure it: how to split it into modules, where shared state lives, how to avoid one team's change breaking another's page. I talked about feature-based folders, keeping server state separate from UI state, and lazy loading routes. She asked how I would handle a design system shared across teams and how I would version it. Then a question on performance: what I would measure first on a slow page and how I would cut bundle size. I gave concrete steps — measure, code split, cache. There was no coding; it was all reasoning out loud for about an hour.
Round 7 — System Design + Hiring Manager Fit
The last round was with the hiring manager and was in two parts. It also got rescheduled once, so by then the loop had run for more than a month. First he gave a payment-gateway scenario: a merchant calls us to charge a customer, and I had to talk through the flow. I started with the request coming in, validation, then sending the charge to the processor, then recording the result. He asked what happens if the processor times out and we do not know if the charge went through. I said the request needs an idempotency key so a retry cannot double-charge, and the transaction should be stored in a pending state until we confirm. He asked how the ledger stays consistent with that, and I described writing entries only after confirmation. The second half was fit: why PayPal, how I handle disagreement, what I expect from a manager. It ended warmly. The recruiter called about a week later with the offer.
Key takeaway: Be ready for extra team-specific interviews if your profile spans both frontend and backend, and expect the schedule to run long with several reschedules — flexibility helps. Practice medium-level problems and know core system-design fundamentals like caching and sharding.
More real interview journeys
The first round of each journey below is shown in full; the rest of each candidate's journey — every remaining round, verbatim — is part of the Placement-Ready PYQ Kit.
Round 0 — HackerRank Online Assessment
A recruiter emailed me a HackerRank link a few days after I applied, and I had a week to complete it. I picked a Sunday morning so nothing would interrupt me. The test had a few DSA-focused problems, nothing exotic — an array problem, a string problem and one that needed a hash map. I read all of them once before touching the editor, then started with the one that looked easiest so I would have at least one full score early. I wrote a brute-force first for the second problem, checked it against the sample, and then replaced the inner loop with a hash map lookup. The last problem took the longest because one hidden test kept failing until I handled the empty-input case. I submitted with about fifteen minutes left. The recruiter wrote back three days later saying I had cleared it and asked for my availability for the DS/Algo round.
🔒 3 more rounds — continue this journey in the full kit
Round 0 — HackerRank OA (90 min)
The process started with a 90-minute HackerRank assessment for a frontend-leaning senior role. It had three parts. The first was a string-manipulation DSA problem, which I did first because it was the most familiar — I wrote it with a single pass and a small map and it passed all the visible tests. The second part asked me to implement a JavaScript class with a few methods and some validation; I wrote it plainly, no fancy patterns, and added guards for bad input. The third part was a small React exercise: a cart where you add items, change quantities and see the total. I kept state in one component, wrote the quantity update as a pure function, and made sure removing an item at quantity zero worked. I ran out of time before styling anything, so it looked bare, but it worked. I got the mail to schedule the DSA round about four days later.
🔒 5 more rounds — continue this journey in the full kit