Juspay's reported process is unusual: a graph-heavy online test, then a multi-hour hackathon on one problem that is first solved and then made concurrent, followed by long technical and founder conversations. Only one readable page gives an interview date (a June 2021 campus drive); the others are undated, and one mentions remote hiring because of the pandemic. No recent SDE-2/3 detail was readable.
Reported by candidates and, where we found one, the company itself. Each round shows how well it is reported. Processes change by team, level and year.
1
Online coding test
Online assessmentAbout 1.5 hours (intern report)
One report
Timed online test with three graph-based problems in both reports (two easier and one medium-hard in the SDE-1 report, medium-hard in the intern report). In the SDE-1 report it is the first filter before the hackathon.
graph algorithms
Varies: Reports are SDE-1 (about 1 year experience) and intern/campus; senior-level OA format not found.
What can be asked in a online assessment round
A timed test on a coding platform, taken alone. Usually two or three coding problems, sometimes with multiple-choice questions on CS basics, aptitude or SQL.
Array and string problems that need a hash map, two pointers or a sliding window
Read the constraints first, because they point to the technique. If n is 100,000, an O(n^2) scan will time out, so look for a hash map, two pointers on a sorted array, or a window that moves forward only. Sketch the brute force, find the repeated work, then remove it. For two-sum style pairs you might say: I store each value's index as I scan, so the complement lookup is O(1) and the whole pass is O(n).
Greedy and sorting problems with a catch in the constraints
Greedy problems hide behind a sort. Ask what ordering makes the locally best choice safe, then try to argue why swapping two adjacent choices never helps. Interval scheduling is the classic case: sort by end time and take every interval that starts after the last chosen one. Check the catch in the constraints, such as overflow, ties or equal values, and test a tiny case by hand before submitting.
A medium dynamic programming or graph-on-a-grid problem
Decide whether the problem is a graph walk or a recurrence. On a grid, a shortest path with equal step cost is breadth-first search from the start, with a visited set so each cell is processed once, giving O(rows x cols). For dynamic programming, define the state in one sentence, write the transition, set the base cases, then see if only the previous row is needed to save space.
Start from the table that holds the thing being counted, join the others on their keys, filter rows with WHERE, group, then filter groups with HAVING. Remember that WHERE runs before grouping and HAVING after. Use LEFT JOIN when rows with no match must still appear, and COUNT of a column rather than star when nulls matter. Example: customers with more than three orders is GROUP BY customer_id HAVING COUNT(*) > 3.
Multiple-choice questions on OOP, operating systems, databases and networks
These reward quick, accurate recall rather than long reasoning, so revise the short list of definitions that recur. Know the difference between a process and a thread, the four ACID properties, what an index trades for faster reads, TCP against UDP, and the four pillars of OOP. Eliminate two wrong options first, then choose. Do not spend more than a minute on any single question, and flag it to return to if time remains.
Remote. One problem that is mainly algorithmic with a low-level-design flavour. The candidate discusses an approach with a panel of five, then codes it on a shared editor (codeshare). About 20 candidates nationwide were picked, and a founder gave an orientation.
problem decomposition
low-level design
working code under time
Varies: The intern report instead has a 3-hour HackerEarth challenge called Tree of Space, whose problem is not described.
Practise for this round
ReportedExtend a working hackathon solution to be thread-safe and scalable Part B reuses the Part A problem and adds concurrency requirements.Candidate write-up ↗
Reported prompts have no written answer yet. Read the linked page for context.
What can be asked in a machine coding round
You build a small working system in your own editor in 60 to 120 minutes, then walk through it. Clean entities, extensibility, a runnable demo and tests matter more than clever algorithms.
Parking lot, library or inventory system with several entity types
Spend the first ten minutes on requirements and entities, not code. For a parking lot you might list Vehicle, Slot, Ticket and Lot, with slot types as an enum and the allocation rule hidden behind an interface so a nearest-slot strategy can be swapped. Keep the code runnable early, write a small demo in main, and add a few tests. Say what you would add with more time, such as pricing rules.
Splitwise-style expense sharing, a wallet or a ledger
The core of expense sharing is a balance ledger: for each pair or each user, store the net amount owed. An expense has a payer, an amount and a split type such as equal, exact or percent, handled by a split strategy per type. Validate that exact splits sum to the total and handle rounding explicitly. To simplify debts, compute each person's net balance and match the largest creditor with the largest debtor.
Snake and ladder, tic-tac-toe, chess or another game engine
Model the board, players, dice or moves, and a game controller that owns the turn loop, with rules kept out of the board class. For tic-tac-toe, keep counters per row, column and both diagonals, so a win check is O(1) per move instead of scanning the grid. For snake and ladder, store jumps in a map from square to destination. Make board size and number of players configurable rather than hard coded.
An in-memory cache, key-value store, rate limiter or job scheduler
Start with the public interface and the invariants. For a rate limiter, a token bucket stores tokens and a last refill time per key, refills lazily on each call and allows the request if a token remains. For an LRU or key-value store, say the data structure and the complexity. For a scheduler, a priority queue ordered by run time with a worker that waits for the earliest job.
Elevator, vending machine or ATM as a state machine
Draw the states and transitions before coding. An elevator is idle, moving up, moving down or doors open, and each event such as a button press or arrival is handled by the current state. A vending machine moves through idle, has money, dispensing and out of stock. Implement it with a state interface or an enum and a transition table, so invalid actions are rejected in one place instead of with scattered if statements.
Follow-ups: add a new rule without rewriting, make it concurrent, add persistence
Show that your design bends without a rewrite. For a new rule, say you add a new class that implements the existing interface and register it, leaving old code unchanged. For concurrency, name the shared state and protect it with a lock per resource, or atomic operations, keeping check-and-update in one critical section. For persistence, put a repository interface in front of storage so an in-memory version can be replaced by a database.
The same problem is extended for concurrency and scalability. Candidate proposes approaches, discusses with interviewers, then codes the chosen one in a shared editor.
multithreading concepts
scalability
extending existing code
Practise for this round
ReportedExtend a working hackathon solution to be thread-safe and scalable Part B reuses the Part A problem and adds concurrency requirements.Candidate write-up ↗
Reported prompts have no written answer yet. Read the linked page for context.
What can be asked in a machine coding round
You build a small working system in your own editor in 60 to 120 minutes, then walk through it. Clean entities, extensibility, a runnable demo and tests matter more than clever algorithms.
Parking lot, library or inventory system with several entity types
Spend the first ten minutes on requirements and entities, not code. For a parking lot you might list Vehicle, Slot, Ticket and Lot, with slot types as an enum and the allocation rule hidden behind an interface so a nearest-slot strategy can be swapped. Keep the code runnable early, write a small demo in main, and add a few tests. Say what you would add with more time, such as pricing rules.
Splitwise-style expense sharing, a wallet or a ledger
The core of expense sharing is a balance ledger: for each pair or each user, store the net amount owed. An expense has a payer, an amount and a split type such as equal, exact or percent, handled by a split strategy per type. Validate that exact splits sum to the total and handle rounding explicitly. To simplify debts, compute each person's net balance and match the largest creditor with the largest debtor.
Snake and ladder, tic-tac-toe, chess or another game engine
Model the board, players, dice or moves, and a game controller that owns the turn loop, with rules kept out of the board class. For tic-tac-toe, keep counters per row, column and both diagonals, so a win check is O(1) per move instead of scanning the grid. For snake and ladder, store jumps in a map from square to destination. Make board size and number of players configurable rather than hard coded.
An in-memory cache, key-value store, rate limiter or job scheduler
Start with the public interface and the invariants. For a rate limiter, a token bucket stores tokens and a last refill time per key, refills lazily on each call and allows the request if a token remains. For an LRU or key-value store, say the data structure and the complexity. For a scheduler, a priority queue ordered by run time with a worker that waits for the earliest job.
Elevator, vending machine or ATM as a state machine
Draw the states and transitions before coding. An elevator is idle, moving up, moving down or doors open, and each event such as a button press or arrival is handled by the current state. A vending machine moves through idle, has money, dispensing and out of stock. Implement it with a state interface or an enum and a transition table, so invalid actions are rejected in one place instead of with scattered if statements.
Follow-ups: add a new rule without rewriting, make it concurrent, add persistence
Show that your design bends without a rewrite. For a new rule, say you add a new class that implements the existing interface and register it, leaving old code unchanged. For concurrency, name the shared state and protect it with a lock per resource, or atomic operations, keeping check-and-update in one critical section. For persistence, put a repository interface in front of storage so an in-memory version can be replaced by a database.
Data structures and algorithmsAbout 2 hours (SDE-1 report)
One report
Two interviewers, held shortly after the hackathon. Covers your projects, an open-ended requirements-to-code problem that became a dynamic programming task, a second algorithm problem with brute force to optimal, and deep networking questions.
project depth
dynamic programming
brute-force to optimal reasoning
computer networks
Varies: Campus intern live coding was 1 hour with tree problems and a take-home puzzle set.
ReportedLowest common ancestor in a binary tree Asked in a one-hour live coding round, June 2021 campus drive.Candidate write-up ↗
ReportedLargest cycle problem (statement not given) One of four problems in the 1.5-hour online assessment; the page gives only the title.Candidate write-up ↗
ReportedMinimum coins needed to make a given amount Listed among the assignment questions at the start of the technical and managerial interview, alongside puzzles.Candidate write-up ↗
ReportedMinimum removals to reduce a string to the target word 'Juspay' String question in the second online test; exact wording not given.Candidate write-up ↗
Reported prompts have no written answer yet. Read the linked page for context.
What can be asked in a data structures and algorithms round
A live coding round of 45 to 60 minutes with one or two problems. You are judged on how you clarify, reason, code, test and state the complexity, not on the answer alone.
Arrays, strings and hashing: pairs, windows, frequency counts, prefix sums
Name the pattern from the shape of the question. Pairs with a target use a hash map of seen values. A contiguous range with a condition uses a sliding window that grows on the right and shrinks on the left, so each element enters and leaves once, giving O(n). Range sums over many queries use a prefix sum array so each query is O(1) after O(n) setup. Count characters with a fixed-size array or map.
Linked lists, stacks and queues, including design-a-structure problems such as an LRU cache
For an LRU cache, combine a hash map from key to node with a doubly linked list ordered by recency. Get moves the node to the front, put inserts at the front, and when over capacity you remove the tail node and its map entry. Both operations are O(1), and you say why: the map finds the node, the list reorders it without a scan. For stacks, mention a monotonic stack for next greater element.
Trees and BSTs, graphs (BFS, DFS, topological sort, shortest paths) and grids
Decide the traversal from what is asked. Level by level or shortest path in an unweighted graph is BFS with a queue. Exploring all paths, components or cycles is DFS. A dependency order is topological sort: Kahn's algorithm repeatedly removes nodes with in-degree zero, and leftover nodes mean a cycle. Weighted shortest path with non-negative edges is Dijkstra with a heap, O((V + E) log V). On a BST, an in-order walk is sorted.
Heaps and top-K, intervals, binary search on the answer
For the K largest items keep a min-heap of size K: push each element and pop the smallest when the heap exceeds K, so the cost is O(n log K) and memory is O(K). For intervals, sort by start, then merge by comparing the next start with the current end. For binary search on the answer, define a yes or no check that is monotonic, such as can ship within D days, and search the capacity range.
Dynamic programming from one dimension up to knapsack and string DP
Define the state in a sentence, write the recurrence, fix the base cases, and decide the order of filling. Start with the recursive version with memoisation, then convert to a table. For 0/1 knapsack, dp[w] is the best value at capacity w, and in the one dimensional form you loop capacity downward so each item is used once. For string problems such as edit distance, the state is a pair of prefix lengths.
Follow-ups: optimise space, handle streaming input, make it thread-safe
Treat follow-ups as a chance to show depth, and answer in the same calm order each time. To save space, ask which previous rows or values the recurrence actually reads and keep only those. For streaming input, say what summary you can keep, such as a heap of size K or a running count. For thread safety, name the shared state, guard it with a lock, and keep the critical section short.
Stretched over about a day; the candidate mentions a recruiter call to schedule and a Slack connection for the solution. Starts with background and likes and dislikes, then in-depth system questions and a problem statement the candidate worked out by the next morning, agreed an approach on, and coded. Later topics included projects and five-year plans.
system design depth
problem approach discussion
long-term goals and fit
Varies: Reported by one SDE-1 candidate only; not known whether it applies at other levels.
What can be asked in a system design round
A 45 to 60 minute discussion of how to build a system at scale: requirements, numbers, APIs, data model, components, bottlenecks and trade-offs.
Short links, chat, news feed, notifications, search, rate limiting
Use one repeatable path: clarify scope and scale, estimate load, define the API, sketch the data model, draw the main components, then probe bottlenecks. For short links, store a mapping from a generated short id to the long url, generate ids with a counter encoded in base 62, cache hot links, and note reads far outnumber writes. For chat, mention persistent connections and a store ordered per conversation.
Payments, wallets and ledgers where money must never be lost or doubled
Money systems put correctness before speed. Use a double-entry ledger where entries are append-only and every transfer writes a debit and an equal credit in one transaction. Protect against doubled charges with an idempotency key stored with the result, so a retry returns the original outcome. For lost updates use a database transaction, and reconcile with the payment provider's records on a schedule.
Ride matching, maps and anything with live location
Split the problem into location ingestion, a geospatial index and matching. Drivers send updates every few seconds to a write-optimised store, often in memory, keyed by a grid cell such as a geohash or S2 cell. To find nearby drivers, query the rider's cell and its neighbours, then rank by distance and estimated time. Say how you handle a stale location and a driver who accepts two rides.
File storage and sync, video streaming and content delivery
For file sync, split files into chunks, hash each chunk and upload only chunks the server lacks, so a small edit transfers a small amount. Keep metadata in a database and chunks in object storage. For video, upload the original, transcode into several resolutions, store segments and serve them through a content delivery network with adaptive bitrate streaming, so the player switches quality as bandwidth changes.
Treat each as a tool with a cost. A cache cuts read latency but adds staleness and invalidation. Sharding spreads write load but makes cross-shard queries hard. Replication gives availability and read scale but introduces lag. Queues smooth spikes and decouple services but require idempotent consumers. For failures, name timeouts, retries with backoff and a fallback. State what you give up whenever you choose.
Estimates are there to choose a design, so finish each one with a decision. Use round numbers: a day has about 100,000 seconds, so 10 million requests a day is roughly 100 per second on average, with a peak of a few times that. Multiply object size by count for storage, and compare against one machine's capacity. If one database handles the load, say so and avoid sharding.
The closing conversation: motivation, expectations, notice period, compensation and how the offer is structured. Prepared answers and a clear number help here.
Current and expected compensation, and how to answer without boxing yourself in
Be honest and avoid giving a single number too early. Share your current pay only if you are comfortable, and make clear what is fixed and what is variable. For expectations, say you are flexible for the right role, and offer a researched range based on level and market. If pushed, state a figure you can justify. Never state a number you cannot support, because offers are often checked.
Give the facts exactly as they are in your contract. State the notice period, whether early release or a buy-out is truly possible, and the earliest honest joining date. Do not promise a date your employer has not agreed to. For relocation, say whether you can move, how soon, and whether you would need support. Clear, early information helps the recruiter plan and shows you are reliable.
Keep it positive and forward looking. Talk about what you want more of, such as larger scale, ownership or a stronger team, rather than criticising your current employer. The listener checks that you will not leave this job for the same reason. Opening line: I have learned a lot in the current role, and I now want to work on problems at a bigger scale.
Levels, equity and how the offer is built
Ask for the structure rather than only the total. Find out the level and title, base salary, bonus and whether it is guaranteed, equity amount, vesting schedule and cliff, joining bonus and any clawback. Compare offers on a yearly total with the same assumptions. If equity is in a private company, ask how it is valued and what happens on leaving. Asking calmly is normal and expected.
Intern-route challenge over Slack with an assigned buddy: API-testing challenges in Postman, then writing test cases for an automated refund scenario. A final interview with two interviewers followed, covering the Postman test cases, college projects and a backend question.
API testing
test-case design
payments scenarios
learning an unfamiliar tool quickly
Varies: Reported on the intern/fresher route only.
What can be asked in a take-home or practical task round
A small program or service to build on your own time, reviewed for correctness, clarity, tests and how you explain your choices.
Fetch data over HTTP, process a file and produce a report
Read the brief twice and list what is required and what is optional. Fetch with a timeout and handle failures and bad status codes, stream or read a large file in a way that fits memory, and parse defensively. Keep the report format exactly as requested. Separate fetching, processing and output into small functions so they can be tested, and note your assumptions in the README.
A small API or CLI with a README, tests and sensible error handling
Keep the scope small and the quality high. A clear README should explain how to install, run and test it, and list the decisions you made. Validate input, return helpful errors and use consistent status codes or exit codes. Add tests for the main path and two or three edge cases. A tidy small project is better than a half-finished large one.
Be ready to list your shortcuts yourself, and say what you would do with more time. For example, there is no pagination, the input is fully read into memory, and there are no integration tests, and each shortcut has a reason. This shows judgement rather than weakness. Know every line of your code and be ready to change it live.
The hiring manager, behavioural and offer conversations. Candidate reports shape the themes; the answers and frames are written for this site, so use them as a structure and bring your own stories.
Maximize Value CreationCreate value from very little and do more with less.
Take big, courageous movesReduce risk, build a cushion, then go for outcomes that are many times larger.
Unify: bring order to chaosBring order to messy problems by going back to fundamentals and first principles.
Open up: bring creativity to break rigidityDiversify and experiment, and challenge assumptions and rules that no longer hold.
Enable people to create 10X magicEmpower people to find their potential and commit to doing the right thing.
Focus on software and design platformsBuild on software and design platforms and blocks, since digital product design is still early.
Tenets for 10X: ReliabilityRoot-cause reviews done with rigour, and shared ownership of production reliability with collaborative incident response.
Themes candidates report being probed
Life story, likes and dislikes
In-depth systems questions
Project discussion and where you will be in five years
A problem solved overnight and discussed asynchronously
Core computer science depth
Whether you use AI in day-to-day work
Questions to rehearse
Tell me about your background, and what you like and dislike about the work you do.One report
What is being checked. A candidate reports a founder conversation that started with background, likes and dislikes, so the listener is checking motivation and taste before moving to depth.
How to frame it. Tell the story in under two minutes with a clear thread, and be specific about what energises you and what drains you. Honest dislikes should not disqualify you for this role. An opening you can adapt: 'I came to this work through [path], and what keeps me interested is [specific kind of problem].'
If you were given a hard problem to solve overnight and then had to discuss your solution in writing, how would you approach it?One report
What is being checked. A candidate describes an overnight problem whose solution was discussed over chat, which tests independent problem solving and clear written explanation.
How to frame it. Describe how you would clarify the requirement, work in small checkable steps, write down assumptions and present the solution so someone else can challenge it. An opening you can adapt: 'I would start by restating the problem in writing, then solve a simple case, then generalise, and I would send my assumptions with the answer.'
Where do you see yourself in five years?One report
What is being checked. It is reported in the founder conversation, so the listener is checking whether your direction is consistent with building depth in a product company.
How to frame it. Describe the kind of problems and the depth you want to have, not a title. Connect it to something you are already doing, and keep it flexible. An opening you can adapt: 'In five years I want to be someone who understands [domain] deeply enough to [capability], and I am working on that by [habit].'
Walk me through one of your projects, including the decisions you would revisit.One report
What is being checked. Project discussion is reported in the founder conversation, and the reliability and first-principles values suggest depth and honesty about trade-offs will matter.
How to frame it. Explain the problem, your design, the reasoning from first principles and one decision you would change with hindsight. Expect follow-ups on any detail. An opening you can adapt: 'The core problem was [problem]; I chose [approach] because [reason], and with what I know now I would change [part].'
Do you use AI tools in your daily work, and how do you decide when to trust their output?One report
What is being checked. An intern reports being asked whether they use AI daily; the listener is checking honest tool use and whether you verify results rather than paste them.
How to frame it. Say what you use it for, what you never delegate, and how you verify output through tests, reading and small experiments. Be honest rather than performing enthusiasm or avoidance. An opening you can adapt: 'I use it for [tasks], but I check the result by [method], and I do not use it for [task] because [reason].'
Tell me about a time you delivered strong results with very limited time or resources.Prep guides
What is being checked. The company's own page frames value creation as doing more with less, so the listener may want evidence that you work well under constraints.
How to frame it. Describe the constraint, what you chose not to build, how you reused existing pieces and the outcome. Show judgement, not just effort. An opening you can adapt: 'We had only [constraint], so I reused [existing thing] and skipped [feature], which still delivered [result].'
Tell me about a production incident you were part of: how the team responded and what you learned from the root-cause review.Prep guides
What is being checked. The page describes rigorous root-cause review and shared ownership of production, so this checks whether you treat incidents as team learning rather than blame.
How to frame it. Cover the timeline, your role, how responsibility was shared, the root cause (not only the trigger) and the change that came from the review. An opening you can adapt: 'The trigger was [event], but the root cause was [deeper cause], and the review led us to [change].'
The SDE-1 candidate describes the final HR round as a formality after which they were told an offer would be rolled out. This is one undated account and should not be read as the usual pattern.
No compensation or notice-period conversation is reported. As general advice, ask for the full pay breakdown in writing, confirm the notice period and buy-out, and ask about level and band before you name a figure.
What we could not verify. All first-hand reports are undated pages from an SDE-1 and an intern, with no experienced-hire manager, compensation or notice-period account. The value names follow the company's own Juspay Formula and reliability tenets, shortened where the headings are long, and the page also lists a seventh formula point that is not covered here.
What we could not verify. Could not read LeetCode, Naukri Code360 or Glassdoor pages (403), so 2025-2026 candidate reports (including a 7-round Glassdoor description and LeetCode hackathon write-ups) are not citable. Of the GeeksforGeeks pages, only one gives an interview date (June 2021); the SDE-1 and first intern pages show only a last-updated date, and the SDE-1 page says the process was remote because of the pandemic. No SDE-2/SDE-3 specific process, no durations for most rounds, no timeline in weeks, and no GitHub company list were found. The hackathon tree-locking problem is only named via a link on the page; its rules were not read on a fetched page.