Interview experience
Paytm interview experiences covering Online Assessment, Technical Round 1, Technical Round 2, HR / Culture. Round-wise notes, common questions, and what candidates report clears each stage.
Explore: Interview experience · HR interview questions · Overview · Placement papers · Preparation guide
Paytm’s fresher loop is a tight 4-stage process where the technical rounds consistently pull DSA problems (LRU cache, rate limiters) into a payments-domain conversation - wallet transactions, UPI flows, idempotent APIs - rather than testing DSA and domain knowledge separately.
Interview experience
Paytm interview experiences covering Online Assessment, Technical Round 1, Technical Round 2, HR / Culture. Round-wise notes, common questions, and what candidates report clears each stage.
HR interview questions
Paytm HR interview questions with sample answer frameworks - motivation, relocation, STAR stories, and culture-fit prompts.
| Round | Duration | What they test |
|---|---|---|
| Online Assessment | 90 min | Coding (DSA) + sometimes MCQs |
| Technical Round 1 | 45-60 min | DSA + backend / payments concepts |
| Technical Round 2 | 45-60 min | System design (payments / ledger) |
| HR / Culture | 20-30 min | Motivation, integrity, relocation |
These answers are compiled from public candidate reports and prep guides, not from an official notice, and drives differ. The instruction screen of your own test is the final word.
| Question | Answer |
|---|---|
| How many questions and how long? | It varies by role. Recent SDE intern + FTE (2025) reports describe 3 medium coding problems plus 2 SQL queries. Code360 intern reports describe 2 problems mixing SQL and DSA in 120 minutes (January 2025) and 3 SQL queries plus 2 DSA questions in 90 minutes (August 2024, off-campus). A 2024 on-campus DevOps intern test had 5 questions in 60 minutes: 3 SQL, 1 Java OOP class-completion question and 1 medium array DSA problem. Older SDE-1 campus OAs set 2 DSA problems (a string and a graph problem). |
| Does it have negative marking? | No public report mentions any. The test is mostly coding and SQL, scored on test cases. |
| Is there a sectional cutoff? | Not published. Some drives add a separate aptitude or MCQ round; One97’s fresher process notes say there are sometimes two online rounds. |
| How much is the cutoff? | Not published, and the funnel is steep. In one BIT Mesra SDE-1 drive, 25 students cleared the OA, 10 cleared technical round 1 and 5 reached HR. Eligibility in reported drives: 7.0+ CGPA with 70% throughout (SDE-1, CSE/IT), or 60% in 10th/12th and 7 CGPA (DevOps intern, CSE/IT/ECE); no backlogs. |
| Which platform is it on? | Not published for fresher tests, and the 2024-2025 intern reports we found do not name a platform. A 2025 experienced-hire (Senior SWE) report names HackerRank. Use the platform in your invite. |
| Is SQL tested? | Yes, often. SQL queries appear in the OA itself in recent intern and DevOps tests, and again in interviews (joins, GROUP BY, indexes). |
| Which languages can I use? | C, C++, Java or Python for the DSA questions in reported tests. |
These themes come from candidate reports on GfG and Glassdoor. They show the level and style, not a fixed list.
| Role | Reported questions and topics |
|---|---|
| SDE-1 (campus) | Find all anagrams in a string, basic OS and data structure questions, then a hard Trie problem in round 2. Reverse a linked list, first non-repeating character, LCA in a BST, Kadane’s algorithm. |
| SDE intern + FTE | Three medium DSA problems and SQL in the OA (December 2024 report: second-highest salary, duplicate emails, orders whose user_id is missing from Users; other 2024 reports: next permutation, product of array except self), then LRU cache, rate limiter, OOP (overloading vs overriding) and UPI or wallet flows in interviews. |
| DevOps intern (campus) | Basics of AWS services, Git branching and Git vs GitHub, Linux commands, what CI/CD and DevOps mean, plus two array and string DSA questions (2024 Noida report). |
| Backend / SDE-1 lateral | LLD for a hotel-booking system (availability, cancellation, double-booking prevention), idempotent payment APIs and wallet ledger design. |
Asked across every role: your projects and internship with the challenges you faced, why Paytm, and your strengths and weaknesses. Some panels add puzzles.
A 90-minute timed coding test, usually on HackerRank or a similar platform (some off-campus drives report CoCubes). Clean, fully-passing solutions beat partially-clever ones - the shortlist bar rewards correctness and completion over elegance. Recent SDE Intern + FTE (2025) accounts describe three medium coding problems plus two SQL queries in one sitting; older campus OAs often stick to two story-style graph/string problems in 60–70 minutes.
Common questions
Opens with a DSA coding problem on a shared IDE, Google Docs, or Google Sheets - then moves into backend and payments-domain concepts. Candidates consistently report reverse linked list, first non-repeating character, LCA in a BST, and OOP (overloading vs overriding) alongside wallet/UPI explanations and a detailed project walkthrough.
Common questions
System-design focused, usually scoped around payment or ledger-style systems rather than a generic prompt - idempotency, failure modes, and data consistency come up even at fresher depth. Some SDE-1 and lateral loops add LLD: design a hotel or hotel-booking system (entities, availability search, cancellation, double-booking prevention, idempotent booking APIs). Campus round-two reports also include Kadane’s algorithm (max subarray sum), tree views, and ACID / index follow-ups after live coding.
Common questions
Round-by-round narratives are on the Paytm interview experience page.
A closing 20-30 minute conversation on motivation, integrity, and logistics. Concrete answers with a clear result outperform generic slogans here.
Common questions
Sample answer frameworks for each of these are on the Paytm HR interview questions page.
The company that runs Paytm’s engineering drives is One97 Communications Ltd, so offer letters and some job posts say One97 rather than Paytm. Its fresher role titles include SDE, backend engineer, DevOps engineer and Assistant System Engineer.
Paytm Payments Bank Ltd (PPBL) is a separate company: One97 holds 49% and founder Vijay Shekhar Sharma holds 51%, so it is an associate, not a subsidiary. On 31 January 2024 the RBI barred PPBL from taking fresh deposits, credit transactions or top-ups, citing persistent non-compliance; on 16 February 2024 it extended the deadline from 29 February to 15 March 2024, after which PPBL could not offer fund transfers or UPI, though customers can still withdraw balances. On 1 February 2024 One97 said it would stop working with PPBL and move its nodal accounts to other banks.
Paytm Money Ltd (the investing and broking app) is a wholly owned subsidiary of One97, as a September 2026 report on One97’s investment in it confirms.
Neither PPBL nor Paytm Money is the employer for the SDE loop on this page. Check the legal entity on your offer letter. This page covers One97’s software hiring.
Pair a hash map from key to node with a doubly linked list kept in recency order, most-recently-used at the head. get() looks the node up through the map in O(1) and moves it to the head; put() inserts at the head and, when size exceeds capacity, unlinks the tail node and deletes its key from the map. The list must be doubly linked because removing an arbitrary node in constant time needs a prev pointer - with a singly linked list you would scan O(n) to find the predecessor. Space is O(capacity). A common follow-up is thread safety: guard the structure with a lock, or use a concurrent design with per-segment locking.
Token bucket keeps a token count and last-refill timestamp per key, refilling at a fixed rate up to a burst capacity - it permits controlled bursts, which suits real API traffic, and stores only two numbers per client. A fixed-window counter is simplest but allows up to twice the intended rate across a window boundary. A sliding-window log is exact but stores every timestamp, so memory grows with traffic; a sliding-window counter blends the previous and current window and is usually the right compromise. In a distributed setup, state lives in Redis and the check-and-decrement must run as an atomic Lua script or INCR-with-expiry, otherwise two application nodes can both approve the same last token.
Sort intervals by start time, then sweep left to right keeping a current merged interval. If the next interval starts at or before the current end, extend the current end to the max of the two ends; otherwise emit the current interval and begin a new one. Time is O(n log n), dominated by the sort, with O(n) output space. Clarify up front whether touching intervals such as [1,3] and [3,5] should merge - interviewers deliberately leave that ambiguous to see whether you ask.
Idempotent means repeating the same request produces the same result and only one charge - necessary because a client that times out cannot tell whether the payment went through. The client sends a unique Idempotency-Key (a UUID) per logical payment; the server inserts that key into a uniquely indexed table inside the same database transaction that debits the wallet and writes the ledger entries. If the insert succeeds, process and store the response against the key; if it violates the unique constraint, return the previously stored response rather than charging again. Splitting the existence check and the charge into two separate statements reopens the race window, so the atomicity of the single transaction is what actually provides the guarantee.
The payer opens a UPI app, which resolves the payee’s VPA (the name-at-bank handle) to an account through the NPCI switch, then authenticates the payer with their UPI PIN, which is validated by the payer’s issuing bank rather than the app. NPCI routes a debit request to the payer’s bank (the remitter) and a credit request to the payee’s bank (the beneficiary), acting as the central switch and settlement layer between them. The user sees near-instant confirmation while interbank settlement happens in batch cycles behind the scenes. The failure mode that matters in interviews is the deemed-approved or pending case, where the debit succeeded but the credit response is unknown - resolved by reconciliation against NPCI files and an automatic reversal if the credit never lands, which is exactly why the whole flow is built around unique transaction references.
Atomicity means the transaction commits fully or not at all, so a debit cannot persist without its matching credit. Consistency means constraints such as a non-negative wallet balance hold before and after. Isolation means concurrent transactions do not see each other’s uncommitted state, tunable from READ COMMITTED through SERIALIZABLE. Durability means a committed transaction survives a crash via the write-ahead log. For wallet debits, isolation is the subtle trap: under READ COMMITTED two concurrent withdrawals can each read the same balance of 100, each judge a withdrawal of 80 valid, and both commit - so you need SELECT ... FOR UPDATE to lock the row, or an optimistic check with a version column and a retry.
Encapsulation bundles state with the methods that act on it and hides internals - a Wallet class exposes debit() and credit() but never a public balance setter, so no caller can corrupt the balance. Abstraction exposes only the essential contract: a PaymentGateway interface declares charge() without revealing which acquirer is behind it. Inheritance lets a subtype extend a base type, as when UpiTransaction extends Transaction. Polymorphism lets one reference type invoke many implementations, so iterating a list of Transaction objects dispatches to the right settle() at runtime. Answer with the example attached to each pillar - reciting the four words alone reads as memorised.
Aggregate with GROUP BY and filter the aggregate with HAVING, not WHERE: SELECT user_id, SUM(amount) AS total FROM transactions WHERE status = 'SUCCESS' AND created_at >= date_trunc('month', CURRENT_DATE) GROUP BY user_id HAVING SUM(amount) > 10000 ORDER BY total DESC; The key points interviewers look for are filtering on status so failed and pending attempts are not counted, using HAVING for the post-aggregation condition since WHERE is evaluated before grouping, and writing the date filter as a range against created_at so an index on (user_id, created_at) can be used - wrapping created_at in a function such as MONTH(created_at) would prevent the index from being used.
Three pointers: prev = null, curr = head. Each step saves curr.next, sets curr.next = prev, advances prev and curr. When curr is null, prev is the new head. Time O(n), space O(1). Mention recursion as O(n) stack space if asked. Paytm 2025 intern+FTE reports explicitly asked for working C++ on a shared IDE with complexity explained aloud.
Walk from the root: if both targets are smaller, go left; if both larger, go right; otherwise the current node is the LCA (first split). O(h) time, O(1) extra space. Contrast with a general binary tree, where you need a post-order recursion or parent pointers. Clarify whether nodes are guaranteed to exist - interviewers use that to test edge-case thinking.
Track currentBest and globalBest while scanning: currentBest = max(nums[i], currentBest + nums[i]); globalBest = max(globalBest, currentBest). O(n) time, O(1) space. Mention all-negative arrays (globalBest should still pick the least negative element) and ask whether empty subarrays are allowed.
Two-pass frequency map (or array of size 26 if lowercase English only): first pass counts, second pass returns the first index with count 1. O(n) time. Single-pass variant uses a LinkedHashMap to preserve insertion order. Paytm panels often follow with space/time trade-offs for Unicode input.
A clustered index defines the physical row order on disk - one per table (often the primary key). A non-clustered index is a separate structure with keys pointing to row locators; you can have many per table. Lookups on non-clustered indexes may require key lookups back to the clustered data. Interviewers tie this to payment tables: index (user_id, created_at) for monthly spend queries without wrapping created_at in functions.
BFS explores level by level with a queue - use for shortest path in unweighted graphs, level-order trees, and multi-source spread (Rotting Oranges style). DFS goes deep first with a stack/recursion - use for cycle detection, topological sort, connected components, and tree paths. State time O(V+E) for adjacency lists and mention stack depth limits on huge trees.
Entities: Hotel, RoomType, Room, Reservation, User. Core operations: search availability by date range, hold slot (optional TTL), confirm booking, cancel with policy. Prevent double booking with a DB unique constraint on (room_id, check_in, check_out) or transactional check-then-insert inside SERIALIZABLE/row locks. Use idempotency keys on confirm API so mobile retries do not create duplicate reservations. Mention indexes on (hotel_id, date) for search - a common Paytm-adjacent LLD prompt in SDE-1 reports when fintech design is not the focus.
No public candidate report mentions negative marking. The Paytm OA is mostly coding and SQL - for example 3 medium coding problems plus 2 SQL queries in recent SDE intern + FTE drives - scored on test cases passed.
Yes, often. Recent SDE intern + FTE tests included 2 SQL queries alongside 3 coding problems, and a 2024 DevOps intern test had 3 SQL questions out of 5. Interviews follow up on joins, GROUP BY and indexes.
Paytm’s SDE/Backend Engineer process for freshers typically runs 4 stages: 1. Online Assessment (90 min) - DSA coding, sometimes with MCQs. 2. Technical Round 1 (45-60 min) - DSA plus backend/payments-domain concepts. 3. Technical Round 2 (45-60 min) - system design, often framed around payments or ledger systems. 4. HR/Culture (20-30 min) - motivation, integrity, relocation. Timeline is usually 2-4 weeks from application to offer for campus drives.
Common coding questions include designing an LRU cache (HashMap + doubly linked list), implementing a rate limiter (sliding window or token bucket), and merging overlapping time intervals (sort + sweep). Technical rounds also probe domain concepts specific to Paytm’s business - wallet transactions, UPI flows, and idempotent payment APIs - in plain-language terms rather than buzzwords. HR rounds ask why fintech/payments, and about a production bug or outage you helped with.
Usually 4 stages: an Online Assessment, two Technical Rounds (DSA+domain, then system design), and an HR/Culture round. Some drives merge HR into the second technical round instead of running it separately - confirm the exact structure from your placement cell.
Technical Round 1 (45-60 min) mixes a DSA coding problem with backend/payments-domain discussion - candidates report being asked to design an LRU cache or a rate limiter, followed by a plain-language discussion of wallet transactions or UPI flows. Technical Round 2 shifts to system design, often centered on payment/ledger-style systems (idempotency, failure modes, data consistency). Both rounds also include a detailed project discussion covering stack choices and the hardest bug you’ve debugged.
Clear the OA with clean, fully-passing solutions rather than partial cleverness - timed practice beats last-minute topic-hopping. Revise OOPs and SQL, since fundamentals questions open a lot of Paytm panels. For domain questions, be ready to explain wallet transactions or UPI flows in plain language (inputs, outputs, what breaks at scale) rather than reciting buzzwords. Prepare one detailed project story (architecture, hardest bug, what you’d rebuild) and concrete HR answers - one story with a clear result beats several vague claims.
The common ones are coding before clarifying constraints, treating the HR round as a formality, and reaching for system-design jargon without a simple, concrete bottleneck story. Candidate reports consistently note that a coherent explanation of wallet-transaction trade-offs beats a high CGPA paired with weak communication.
Fintech campus and lateral SDE loops commonly run OA → DSA/Java rounds → LLD or payments design → managerial/HR. Interviewers score:
Soft fail modes: design talk that never mentions double-charge prevention, or treating HR as a CTC-only chat after clearing technicals.
Beyond DSA, public backend write-ups mention wallet/UPI-style LLD, concurrency and isolation levels, Redis caching, and failure handling so transfers are not double-applied. Practise explaining idempotent APIs and ledger consistency in plain language even if your loop stays coding-heavy.
Use this as a default four-week loop before a Paytm drive. Adjust to your invite timeline.
10-day crash version: Days 1-4 timed DSA, days 5-7 resume projects + CS fundamentals, days 8-9 mock interviews out loud, day 10 HR STAR stories on the HR page.
Candidate-reported fresher/early-career packages for Paytm often cite ₹16-22 LPA SDE-1 band. Treat forum numbers as ranges, not guarantees - confirm the written offer letter for your team and location.
Interview process details and sample questions on this site are editorially organized from public candidate reports and hiring write-ups, with round structure, prep notes, and company-specific framing added by our team. For round-by-round stories, see the Paytm interview experience page. For OA papers and coding drills, use Paytm on placementpapers.app. OA quick answers and role-wise questions draw on GfG’s Paytm interview experiences (SDE-1 on-campus, DevOps intern on-campus 2024), GfG’s One97 recruitment process page, placementpreparation.io’s Paytm interview-experience post (2025 SDE intern + FTE and Senior SWE) and Naukri Code360 Paytm intern snippets (2024-2025) seen via search. The entity section draws on TechCrunch (31 January 2024) and Business Today (16 February 2024) on the RBI action against Paytm Payments Bank, and Angel One (September 2026) on Paytm Money.
Guides often searched alongside this page: PhonePe interview questions · Razorpay interview questions · PayPal interview questions · Groww interview questions · CRED interview questions · Amazon interview questions.