Razorpay Phone Screen Interview: What Gets Tested and How to Pass

You have been grinding LeetCode for two weeks. Kadane's algorithm is burned into your retinas. You can reverse a linked list in your sleep. The Razorpay recruiter email just arrived and you are feeling dangerous.

I regret to inform you: they are going to ask about phantom reads.

Razorpay processes over $150 billion in payments annually. The engineering bar reflects that scale. The phone screen is not a FAANG-style gauntlet, but it tests something most candidates skip entirely in their prep: CS fundamentals, especially databases. Candidates who over-rotate on difficulty are surprised when the interviewer pivots to DBMS after the DSA section. This guide covers what actually gets tested, how it is scored, and what separates the people who advance from the ones who leave wondering what happened.

Who You Are Determines Which Screen You Get

Razorpay runs two different first-round experiences depending on where you are in your career.

Freshers and campus candidates start with a 90-minute online assessment on HackerEarth: 15 multiple-choice questions covering OS, DBMS, OOP, and DSA, plus three coding problems graded easy, medium, hard. The MCQs have different point weights, so guessing on something you don't know costs less than rushing a coding problem. Strong performance earns you the live rounds.

Experienced engineers (1+ years) skip the assessment entirely and go straight to a live technical phone screen: 45 to 60 minutes on a shared Google Doc or CoderPad, one or two DSA problems, and a resume discussion. The person on the other end is a Razorpay engineer. Not a recruiter. Not someone reading from a rubric they barely understand.

Most of this guide covers the experienced-hire screen. That's where the nuance lives.

The Recruiter Call Doesn't Count

Before the technical screen, there's usually a 15-to-20-minute recruiter call. Your background, current CTC, notice period. Answer honestly, be clear on your notice period, ask about the timeline. The actual evaluation starts when you're connected to an engineer. That's the next call. This one is just logistics.

The DSA Section Is Medium. On Purpose.

The phone screen runs one or two DSA problems at LeetCode medium difficulty. No tricks. These are practical problems a backend engineer might actually need to think through.

Patterns that come up most in candidate reports:

Arrays and hashing (two-sum variants, subarray sums, duplicate detection)
Two pointers and sliding window (meeting room scheduling, maximum subarray products)
Sorting-based problems (the stock buy-sell problem appears repeatedly)
Trees and linked lists (occasional, mostly at experienced levels)

Graphs and dynamic programming appear less at this stage. They save those for round two.

A representative pair from a real 2024 screen: find the largest sum contiguous subarray, then a meeting room scheduling problem where you determine the minimum rooms needed given [start, end] intervals. Neither is a hard. Both require clean implementation and a working solution within 25 to 30 minutes.

The optimization conversation is a scored dimension. Starting brute-force O(n²) is fine. Starting brute-force and narrating it clearly is better than jumping to an approach you can't explain. But you are expected to identify the inefficiency and move toward optimal. Here is the failure mode: candidates write the O(n²) solution, it passes the examples, they type return answer, and then they go quiet. The interviewer is waiting. The candidate is not talking. The optimization conversation is happening whether you initiate it or not. It is better to initiate it.

You Practiced Arrays. They Want to Talk About Phantom Reads.

This is where Razorpay diverges from most product companies.

Razorpay actively tests CS fundamentals in the phone screen, especially databases. This makes sense when you think about what the company actually does. The systems that matter most at a payments company involve transactions, consistency, and failure handling. Interviewers want engineers who understand why those things are hard. Not because they are testing trivia. Because you will work on those systems directly.

Topics that come up regularly:

DBMS: SQL queries (joins, aggregations, window functions), ACID properties, indexing strategies, NoSQL vs relational trade-offs. If your resume mentions any database, consider this a standing invitation for follow-up questions.
OS: Process vs thread, context switching, memory basics (stack vs heap). Less common than DBMS, but it appears.
Networking: HTTP vs HTTPS, REST principles, how a request flows through a payment gateway. Usually surfaces as a resume follow-up, not a standalone question.
OOP: Inheritance, polymorphism, when to prefer composition over inheritance. Sometimes framed as a class design problem.

None of this needs expert-level depth at the phone screen stage. "ACID means atomic, consistent, isolated, durable" is table stakes. "Here's why isolation matters in a payment debit flow" is what earns points. The difference is connecting the concept to the domain. Razorpay is a payments company. They want engineers who make that connection without being prompted.

The pattern that trips candidates: they nailed the DSA section, they feel good, the interviewer pivots to "can you explain read committed versus repeatable read," and the candidate realizes they spent two weeks on two-pointers and about forty minutes on databases. This is the gap. Close it before the screen.

Your Resume Said You Designed the Schema. Time to Draw It.

Most phone screens at other companies glance at your resume and move on. Razorpay engineers ask real follow-up questions, and they know when you are hand-waving.

The pattern candidates report: the interviewer picks one project and drills for 10 to 15 minutes. Database on the resume? They ask about the schema. APIs? They ask about failure handling. Any concurrency? They ask how you thought about locking.

This is the trap you set for yourself. Every impressive-sounding bullet on your resume is an invitation for a follow-up. If it says "designed the database schema," expect to draw one. If it says "built a high-throughput API," expect to discuss where the bottleneck was and how you found it.

Prepare two projects cold. Know the architecture, the data model, the failure modes, and the one thing you would change if you built it again. If you can't answer a question about your own work, that's a red flag that's hard to recover from mid-screen.

How They Actually Score You

Problem-solving process. Do you ask a clarifying question before coding? Do you walk through an example? Jumping straight to the keyboard without framing the problem is a yellow flag. How to ask clarifying questions in a coding interview covers the specific moves that matter.

Code quality. Variable names matter on a shared doc. Edge cases matter. A solution that handles nulls and empty inputs signals a professional. One that crashes on an empty array does not.

Optimization instinct. Can you identify the bottleneck in your own solution? You don't need to derive optimal from scratch in 30 seconds. You do need to say "this is O(n²) because of the nested loop, and I think a hash map brings it to O(n)."

CS fundamentals depth. For a payments company, surface-level answers on DBMS or concurrency signal a domain gap. The engineers who advance connect theory to practice without being prompted.

Two Weeks Is Enough If You Are Focused

Week 1: DSA patterns. Solve 25 to 30 LeetCode mediums across the patterns most common at Razorpay: arrays and hashing, two pointers, sliding window, intervals, and basic trees. Don't grind easies and don't touch hards yet. The phone screen is medium difficulty, and there's a real difference between knowing a pattern and recognizing it under pressure when someone is watching you type. DSA for backend engineers covers the specific families that appear for roles like this.

Week 2: CS fundamentals and resume. Two days on DBMS: write SQL queries from scratch, review transaction isolation levels, know when indexes help and when they hurt. Two days on your resume projects: prepare for "what was hard," "what would you change," and "how did you handle failure." One day running timed sessions where you solve two mediums back to back in 50 minutes while talking through your reasoning out loud.

That last step is where most candidates have the gap. The phone screen is evaluated by a person who can hear your reasoning. Solving problems silently in your head is a completely different skill from narrating your approach live. They feel nothing alike. Platforms like SpaceComplexity let you run voice-based mock interviews with rubric feedback, so the first time you explain your thinking under pressure is not the actual interview.

The Mistakes That Get You Screened Out

Starting to code before framing the problem. The interviewer expects at least one clarifying question. "Can the array have duplicates?" or "Should I handle negative numbers?" shows you think before you build. Silence followed by typing signals the opposite. It tells the interviewer you are the kind of engineer who deploys first and reads the spec later.

Producing brute force and stopping. The optimization conversation is scored. Solve it in O(n²) and say "I think this is correct," and you left half the credit on the table. The interviewer is not going to volunteer that you missed something. They will just note it and move on.

Bluffing on resume projects. Interviewers know when you are stretching. If your resume says "designed the database schema," expect to draw one. If you can't, say what you did contribute. Honesty recovers better than exposure. Being caught bluffing on your own resume is very hard to come back from.

Surface-level DBMS answers. "ACID means the database doesn't lose data" will not pass when the interviewer asks about isolation levels. Know what read committed means. Know why phantom reads happen. For a fintech company, database knowledge signals domain fit, not just general CS competence. It is one of the clearest ways to show you understand the problem space.

Going silent when stuck. If the problem isn't clicking, say what you know. "I think this looks like a two-pointer problem because the input is sorted. Let me try a small example and see." The interviewer can redirect if you are close. They cannot help if you are quiet. Going silent is the only mistake you genuinely cannot recover from, because there is nothing to work with. There is just silence.

What Comes Next

Pass the phone screen and you can expect a second technical round (more DSA, more CS depth), a machine coding round (design a small in-memory system: Splitwise, a logger, a job scheduler), a system design round, and a hiring manager conversation. The full process from application to offer typically runs two to four weeks.

For the complete breakdown of every round, the Razorpay software engineer interview guide covers the full loop. For communication strategy inside live coding, technical interview communication covers the behaviors that separate strong hires from rejected candidates who had correct code.