🔥 Juspay — Elimination Round & Hackathon Part B: Ultimate Battle Plan

Your interview could be Elimination only, Hackathon Part B only, or a Combined Final Round.
This document covers everything for all three scenarios. Treat it as your single source of truth.

📌 Table of Contents

1. About the Combined Round Possibility
2. The Single Most Important Thing: "Tree of Space"
3. Elimination Round — Format & What to Expect
4. All DSA Questions Actually Asked in Elimination Round
5. Puzzles Actually Asked
6. OOP / Design Questions Asked
7. Hackathon Part B — What Actually Happens
8. Everything Asked in Hackathon Part B
9. Thread-Safety Deep Dive: Race Conditions You MUST Know
10. CS Fundamentals Topics to Prepare
11. Other Things to Prepare
12. Master Checklist — Everything You Need to Do
13. 2-Day Prep Priority Schedule

📢 About the Combined Round Possibility

[!IMPORTANT] Glassdoor's current process summary for Juspay lists the final stage explicitly as a "Final Combined Round" — Hackathon Part B plus a behavioral interview in one sitting. So a combined Elimination + Part B (or Part B + behavioral) session is a real, documented pattern, not just a possibility — expect the interviewer to pivot between technical deep-dive and softer questions without a clean break.

What this means for you:

• Prepare for BOTH rounds simultaneously
• Be ready for sudden context-switches (from coding to project discussion to OS questions)
• Don't be surprised if you get puzzles + DSA + multithreading all in one sitting

🌳 The Single Most Important Thing: "Tree of Space"

Almost every account — 2021 through 2026 — centers on the same recurring problem. You've already solved it for Part A, but Part B is entirely a deep-dive on it, so know it cold.

The Setup

An M-ary tree of uniquely-named nodes (framed as a "world map"). Three operations, each taking a node name and a user ID:

Lock(X, uid)

Succeeds only if:

• X itself is not locked
• Every ancestor of X is unlocked
• Every descendant of X is unlocked

Unlock(X, uid)

Succeeds only if:

• X is locked
• X was locked by the same uid

UpgradeLock(X, uid)

Lets uid "promote" a lock up to ancestor X. Succeeds only if:

• X has >=1 locked descendant
• All locked descendants belong to the same uid
• X has no locked ancestor
• On success: all descendant locks are released, X becomes locked instead

Complexity Targets (Explicitly Told to Optimize For)

Standard Working Approach

Each node tracks:

• isLocked — boolean flag
• lockedBy — the uid that locked it
• ancestorsLocked counter — number of locked ancestors above this node
• descendantsLocked counter (or a set of locked descendants)

Updated by walking up/down the tree on each operation.

Data Structure Design

Complexity Analysis (Be Ready to Derive Verbally)

🎯 Elimination Round — Format & What to Expect

Format

• Duration: 1-1.5 hours
• Structure: Intro -> 20-45 min project/resume grilling -> 1-2 coding problems, sometimes a puzzle
• Camera/screen-share is often required as an anti-cheating check
• NOT a hackathon — this is a separate 1-on-1 interview

Consistent Theme

[!CAUTION] This round is really testing whether you can explain your Part A solution under cross-questioning. Several interviewers spend the first 30+ minutes re-deriving your Part A time/space complexity and probing why you made specific design choices, before giving you a fresh problem.

What Interviewers Probe About Your Part A

• Walk through your solution line by line
• Why did you choose this data structure over alternatives?
• Derive the exact time complexity of Lock, Unlock, Upgrade
• Derive the space complexity
• What are the edge cases?
• What happens if you receive 10,000 operations in sequence?
• Why is your Upgrade O(k*log_m N) and not O(N)?

📝 All DSA Questions Actually Asked in Elimination Round

[!NOTE] These are real questions reported by candidates from 2022-2026 batches. Starred items appeared in multiple accounts.

Complete List with Solutions Approach

OA-Specific Graph Problems (The "Juspay Trio")

These three appear in nearly every Juspay Online Assessment:

All three operate on a functional graph (each node has at most 1 outgoing edge — represented as an array edge[i] where edge[i] = -1 means no outgoing edge).

Additional LeetCode Problems to Practice

🧩 Puzzles Actually Asked

[!NOTE] Puzzles appear in both Elimination rounds and System interviews. They test logical reasoning.

Repeatedly Asked Puzzles (High Priority)

Weird/Unconventional Questions (Actually Asked!)

• "How does a toilet flush work?" — Siphon mechanism
• "Build a spaceship using Earth's resources"
• "Build a steam engine from 8 components"
• "Logical proof that height of binary tree = log(N) without using mathematical formulas" — At each level the number of nodes doubles, so the number of levels needed to accommodate N nodes is log2(N)
• "Designing a garbage collector for a multi-threaded environment"
• "Managing automated train crossing barricades"
• Encryption/Decryption transformation puzzles

🏗️ OOP / Design Questions Asked

Open-Ended OOP Design Question Pattern

• Interviewers explicitly say there's no fixed right answer
• They're grading your reasoning, not a specific solution
• Think: abstract classes, interfaces, adapter-pattern thinking

Actual Questions Reported

Key Design Patterns to Know

• Adapter Pattern — Convert interface of a class to another (directly asked)
• Strategy Pattern — Swap algorithms at runtime (e.g., different payment methods)
• Observer Pattern — Event notification (e.g., transaction status updates)
• Singleton — Thread-safe singleton (double-checked locking)
• Factory Method — Create objects without specifying exact class

SOLID Principles (Be Ready to Explain Each with Examples)

• S — Single Responsibility Principle
• O — Open/Closed Principle
• L — Liskov Substitution Principle
• I — Interface Segregation Principle
• D — Dependency Inversion Principle

💻 Hackathon Part B — What Actually Happens

[!CAUTION] This is the round people describe as the real gauntlet. Budget for a full day.

Format

• You're assigned a mentor on Slack, sometimes paired with a Google Meet call
• Duration is wildly inconsistent — reports range from ~6 hours to 9am-9pm to spanning two days, with one account describing a 17-hour stretch
• Budget for a full day

The Flow (Step by Step)

The Hard Constraint (CRITICAL)

[!WARNING] No mutex, semaphore, synchronized, atomic built-ins, or condition variables allowed.

One 2026 account said binary semaphores specifically were allowed as a primitive to reason with — so the exact rule seems to vary slightly by interviewer, but "no ready-made concurrency primitives" is the norm.

Some interviewers ask you to build your own mutex from compiler intrinsics (__sync_lock_test_and_set) as a stepping stone, then take even that away.

The Psychological Trap (KNOW THIS!)

[!CAUTION] A recurring interview pattern: The interviewer will present a solution (sometimes your solution, sometimes one they suggest) and tell you it's thread-safe — and the test is whether you push back and find the bug yourself rather than accepting it.

One full transcript showed the interviewer explicitly walking through two interleaving scenarios (step-by-step context-switch traces) to prove a race condition existed in a solution they'd just claimed was safe.

🔍 Everything Asked in Hackathon Part B

Technical Questions You'll Face

OS/CN Questions Asked Toward the End of Part B

⚡ Thread-Safety Deep Dive: Race Conditions You MUST Know

The Two Race Conditions That Come Up Again and Again

Race Condition 1: Two threads locking the same node simultaneously

Why it happens: The check-then-set on the lock flag isn't atomic.
Fix: Use a test-and-set (atomic swap) instead of separate read + write.

Race Condition 2: Two threads locking different but related nodes

Why it happens: Both threads reading and writing the ancestor's shared counter without synchronization.
Fix: Each ancestor node needs its own atomic increment mechanism.

How to Trace Thread Interleavings (Practice This Format)

Approaches to Fix Without Standard Primitives

Approach 1: Spin Lock via Test-and-Set

Approach 2: Per-Node Integer Flag with Atomic Increment

Approach 3: Peterson's Algorithm (If ALL atomics are banned)

Key Concepts to Explain (Practice Verbally)

• Contention — what happens when many threads try to lock nearby nodes
• Fine-grained vs Coarse-grained locking — trade-offs (more locks = more parallelism but more overhead)
• Lock-free programming — CAS (Compare-And-Swap) operations
• Why naive mutex kills concurrency — if you lock the entire tree, only one thread can operate at a time
• Siblings should not block each other — operations on independent subtrees must proceed in parallel
• Lock ordering — always acquire locks in same order to prevent deadlocks (e.g., always leaf-to-root or root-to-leaf)
• ABA problem — a thread reads value A, another changes it to B then back to A, first thread thinks nothing changed

📚 CS Fundamentals Topics to Prepare

Operating Systems (Deep Dive)

Computer Networks

Database Fundamentals

Encryption & Security

🔧 Other Things to Prepare

Resume & Project Defense (30+ min of cross-questioning is common!)

For EVERY project on your resume, prepare:

• Problem Statement — What problem does it solve?
• Architecture — High-level diagram, components, how they interact
• Tech Stack — Why you chose each technology, what alternatives you considered
• Your Contribution — What specifically YOU built
• Challenges — Hardest technical challenge and how you solved it
• Scale — How many users/requests/data?
• Trade-offs — What design trade-offs and why?
• What Would You Change — If you rebuilt it, what differently?
• Measurable Impact — Reduced latency by X%, throughput by Y%

Cross-questioning patterns to expect:

• "Why did you use X instead of Y?"
• "What happens if this component fails?"
• "How would you scale this to 10x users?"
• "What's the time complexity of your critical path?"
• "How would you make this thread-safe?"

Behavioral / HR Questions

• Why Juspay? (Research: payment infrastructure, 300M+ transactions/day, works with Amazon/Flipkart/Google)
• Describe a production bug you resolved
• A time you disagreed with a technical decision
• Your debugging approach under time pressure
• Long-term career goals
• Why payment infrastructure aligns with your career

Communication Strategy During Interview

• Think out loud — let the interviewer see your thought process
• Start with brute force, then optimize — show progression
• Clarify constraints before coding (input size, edge cases, performance expectations)
• Dry run your solution step by step
• Explicitly state time and space complexity after every solution
• Don't accept "this is thread-safe" at face value — always verify

Mental Endurance

• Some rounds last 8-12 hours — build stamina
• Practice solving problems for long stretches
• Stay calm when stuck — ask for hints politely
• Don't panic if you get unexpected questions

✅ Master Checklist — Everything You Need to Do

🔴 Priority 1: Tree of Space (Do This FIRST)

• Re-implement Tree of Space from scratch, cold, in whatever language you'll use — including Upgrade, which people forget to re-practice
• Be able to build the M-ary tree from array input using level-order (BFS with queue)
• Derive complexity verbally — Lock: O(log_m N), Unlock: O(log_m N), Upgrade: O(k*log_m N)
• Explain WHY each complexity is what it is (height of M-ary tree, ancestor walk, descendant iteration)
• Write out, in words, exactly where the race conditions are in your own lock() and why — before anyone asks
• Practice explaining a race condition via a manual thread-interleaving trace on paper — this is asked constantly
• Implement thread-safe version without mutex/semaphore — using test-and-set or CAS
• Practice the "push back" scenario — if someone tells you a solution is thread-safe, find the bug
• Handle edge cases: locking a node with locked descendants, upgrade when some descendants locked by different uids, interleaved lock/unlock/upgrade, empty tree, single node tree

🔴 Priority 2: DSA Problems

• Solve Open the Lock (LeetCode 752) — explain brute force -> BFS -> complexity
• Solve Basic Calculator (LeetCode 224)
• Solve Highest Score with Tie-Break — HashMap + replay
• Solve Job Scheduling / Minimize Max Load — Greedy + Min-Heap
• Solve Maximum Weight Node (Juspay OA classic)
• Solve Nearest Meeting Cell (Juspay OA classic)
• Solve Largest Sum Cycle (Juspay OA classic)
• Solve Word Ladder (LeetCode 127)
• Solve LRU Cache (LeetCode 146)
• Practice prefix sum / range query problems
• Practice hashing + backtracking combination problems

🔴 Priority 3: Thread-Safety & Concurrency Concepts

• Understand and explain race conditions with examples
• Know how to build a mutex from scratch using __sync_lock_test_and_set
• Know Peterson's Algorithm (if ALL hardware atomics are banned)
• Understand CAS (Compare-And-Swap) — how it works, ABA problem
• Practice tracing thread interleavings on paper for at least 3 scenarios
• Explain fine-grained vs coarse-grained locking with trade-offs
• Explain lock ordering to prevent deadlocks
• Know volatile keyword — why reads/writes must go to main memory
• Know memory ordering — why instruction reordering matters

🟡 Priority 4: CS Fundamentals

• OS: Process vs Thread, Context Switching, Deadlocks (4 conditions + prevention), Scheduling algorithms, Virtual Memory, Paging
• CN: DNS resolution + record types, TCP 3-way handshake, HTTP status codes, SSL/TLS handshake, Certificate validation
• Idempotency: What it is, why critical in payments, how to implement
• How HashMap works internally (hash function, buckets, collisions, Java 8 red-black tree)

🟡 Priority 5: OOP & Design

• SOLID principles — explain each with a real example
• Adapter pattern — converting one class interface to another (actually asked!)
• Strategy pattern, Observer pattern, Singleton (thread-safe)
• Practice: "How would you model payment methods using OOP?"

🟢 Priority 6: Puzzles

• Solve: Odd weight egg / balance scale (divide into thirds)
• Solve: Two people meet within an hour, each waits 10 min (geometric probability)
• Solve: Burning rope problem (45 minutes)
• Solve: Egg drop problem
• Review: 25 horses puzzle, Monty Hall, Birthday paradox

🟢 Priority 7: Resume

• Skim your resume for anything you'd struggle to defend for 20+ minutes straight
• For each project: prepare problem/architecture/tech-stack/contribution/challenges/scale/trade-offs answers
• Practice answering "Why Juspay?" — payment infrastructure, scale, tech challenges

📅 2-Day Prep Priority Schedule

Day 1 — Foundation Day

Day 2 — Polish Day

🧠 Quick-Reference: Things to Say Out Loud During Interview

When Explaining Tree of Space Complexity

"The height of an M-ary tree with N nodes is log base M of N. Lock and Unlock walk from the node to the root, which is O(height) = O(log_m N). Upgrade additionally iterates over k locked descendants, each of which requires its own ancestor walk, giving O(k * log_m N)."

When Naming Race Conditions

"There are two key race conditions. First, the check-then-set on isLocked isn't atomic — two threads can both read false and both set true. Second, when two threads lock different nodes sharing a common ancestor, both try to update the ancestor's descendantsLocked counter simultaneously, causing a lost update."

When Asked "Is This Thread-Safe?"

"Let me trace through a specific interleaving to verify. Suppose Thread A is at step X and a context switch happens..."

When Asked About Approach Without Mutex

"I would use a test-and-set spin lock at the per-node level. Each node has an integer flag. A thread atomically swaps it to 1 — if the previous value was 0, it acquired the lock. If 1, another thread holds it, and we spin. This gives mutual exclusion without library primitives."

[!TIP] The #1 thing that separates selected candidates from rejected ones in Part B: Being able to name the race conditions yourself before the interviewer points them out, and being able to trace thread interleavings on demand.

Last updated: August 29, 2026
Sources: Real interview experiences from GeeksforGeeks, LeetCode Discuss, Glassdoor, Medium, Unstop — 2022 through 2026 batches