Juspay's open-ended round evaluates how you think, not what you know. Staying calm and
reasoning out loud beats knowing the answer and panicking when a follow-up catches you off guard.
Open-ended questions — practice these out loud, record yourself
- Your payment service processes 1M transactions per minute. At
10am on Monday it slows to a crawl. How do you find the cause?
↗
click
- A customer says "I was charged but my order didn't go through."
Debug this with me live.
↗ click
- Build a system that sends an SMS exactly once when a user's
balance drops below ₹100 — even if the system crashes mid-send.
↗
click
- How would you make a system highly available if you only have one
database?
↗ click
- Design a webhook delivery system. Merchants register URLs and you
must notify them of payment events — reliably, at scale, with retries.
↗ click
- You're asked to add a new payment method (say, BNPL — Buy Now Pay
Later) to Juspay's existing gateway. Walk me through how you'd architect it.
↗ click
- A new engineer joins and accidentally deploys broken code that
causes 30% of payments to fail. Walk me through how you detect, respond, and recover.
↗ click
- How would you build a system that can replay any payment event
from the last 30 days? Why would you need this?
↗ click
- You need to migrate a live payment database from MySQL to
PostgreSQL with zero downtime. How do you do it?
↗ click
- A merchant complains their settlement (money transferred to
their account) is delayed by 2 hours compared to what the contract says. How do you
investigate and fix it?
↗ click
- Design a system that lets Juspay A/B test two different payment
flows on 5% of traffic each, measure conversion rates, and roll back instantly if something
goes wrong.
↗ click
The "derive it" drill — for when you blank on something
- If you forget why TCP needs a 3-way handshake: reason from "what
problem does it solve?" and derive the mechanism.
↗ click
- If you forget database indexing: start from "scanning 10M rows is
too slow" and build up from there.
↗ click