Airtel Payments Bank Software Engineer Interview Guide

The 60-second brief

Airtel Payments Bank operates in digital banking in India. Candidates describe the Software Engineer role as touching secure payment systems and data analytics features, alongside product managers and UX designers, with performance, data security and regulatory standards as recurring concerns. As candidates describe it, the role calls for Java, Python or C#, Spring Boot and SQL or NoSQL databases, with cloud platforms, DevOps and Agile as extras. Reported duties include shipping and maintaining applications, code review, improving team processes and tooling, and mentoring junior engineers.

This guide is for software engineers preparing for the Airtel Payments Bank Software Engineer loop, a role candidates describe as asking for roughly 2-5 years of development experience. It covers the three reported stages, question-by-question guidance for every reported technical, design, scenario, coding and behavioral question, the Java and Spring Boot details worth having ready, and a seven-day plan that turns those questions into practice sessions.

Candidates report three rounds over about 3-5 weeks: an Initial Screening, Technical Interviews with coding assessments, and an HR Round, the last conversation, where cultural fit and any offer come up.

Focus areas

• Data Structures
• Java
• Algorithms

Overview

The reported questions fall into five groups. Core concepts: HTTP versus HTTPS, object-oriented principles, query optimization, error handling and unit testing. System design: a URL shortener, a caching layer, a microservices architecture, high availability for a banking application, and SQL versus NoSQL. Scenarios: finding duplicates in a large dataset, diagnosing performance problems, debugging a production incident, absorbing a traffic spike and protecting user data. Coding: reversing a linked list, binary search, two-sum, the longest substring without repeating characters, and a dynamic-programming problem such as Fibonacci. Behavioral: a hard project, competing deadlines, a difficult teammate, staying current, and why this company.

The coding problems are well-known classics, so the preparation is execution rather than discovery: write each one in a single clean pass, handle the empty and single-element inputs, state time and space complexity, and be ready for the standard variant (reverse in groups of k, first occurrence in binary search, three-sum, at most k distinct characters, coin change). Practise them in Java if you can, since Java is in the reported topic list: know HashMap behaviour, integer overflow in mid-point and sum calculations, and why BigDecimal rather than double holds money.

One reported design question is set in a banking application; for it and for the security and debugging questions, prepare the money-movement mechanics below. Prepare idempotency keys so a retried debit cannot post twice, a double-entry ledger with an audit trail, strong consistency for balances, encryption and tokenization of sensitive fields, and a rollback-first incident response. The same mechanics serve the high-availability, security, debugging, traffic-spike and microservices questions, so building them once pays off across five questions.

With 2-5 years of experience in the reported requirements, expect to explain your own projects in depth: which Spring Boot features you used, how you chose a database, how you handled errors and tests. Prepare two projects you can walk through from requirement to production, with the trade-offs you personally made, because the error-handling, unit-testing and challenging-project questions all draw on that material.

The Airtel Payments Bank interview process

Candidates describe the order as Initial Screening, then Technical Interviews with coding assessments, then an HR Round, with about 3-5 weeks from start to finish.

Initial Screening

Candidates report an initial screening that gauges suitability for the role; no format, question set or interviewer is reported for it. Treat it as the point where your background is matched against the requirements candidates describe: 2-5 years of development, Java, Python or C#, Spring Boot, and SQL and NoSQL databases, with cloud, DevOps and Agile as extras. Open with a short walkthrough of your most recent project that names the stack and your own part in it, and have a specific reason for applying to this company rather than any bank.

What to demonstrate

• Suitability for the role, the only purpose candidates report for this stage
• Where your experience lines up with the requirements candidates describe: languages, Spring Boot, databases and years of experience

How to prepare

• Write a short summary of your latest project naming the language, framework, database and one technical decision you made, and practise saying it clearly.
• Make a two-column list of the reported requirements (Java/Python/C#, Spring Boot, SQL/NoSQL, AWS or Azure, DevOps, Agile) and a concrete piece of evidence from your work for each.
• Prepare your answer to why Airtel Payments Bank specifically, tied to payments, security or regulated systems you have built.
• Have notice period, location constraints and availability ready, and ask what the technical stage consists of.

Technical Interviews

Candidates report technical interviews that include coding assessments; the topics reported for the role are data structures, algorithms, Java, coding problem solving and system design. How many interviews this stage contains, and which question comes up in which, is not reported, so prepare every reported question type here: the five coding problems as working code, the core concepts as crisp explanations with an example from your work, and the design and scenario questions as structured walkthroughs. For coding, say the brute force, then the target complexity, then write the code and run one example through it by hand, including an edge case.

What to demonstrate

• Working code for data-structure and algorithm problems, since coding assessments are the reported format
• Java and core engineering knowledge: HTTP/HTTPS, OOP, databases, error handling, testing
• System design reasoning, which appears in the reported topic list

How to prepare

• Code linked-list reversal, binary search, two-sum, longest substring without repeating characters and Fibonacci (memoized, bottom-up and O(1) space) in Java without autocomplete, with a test case for each edge case.
• Whiteboard the URL shortener and a cache-aside caching layer end to end: requirements, API, key generation, storage, cache, invalidation and failure modes.
• Write a one-page banking reliability sheet: idempotency keys, double-entry ledger, replication and failover, encryption and tokenization, rate limiting.
• Rehearse aloud the HTTPS handshake, the four OOP principles with a Java example, and an EXPLAIN-driven query tuning sequence.

HR Round

Candidates report the HR Round as the last conversation, where cultural fit and any offer come up. Nothing further about its format is reported. Because cultural fit is the reported subject, stories about teamwork, prioritisation, conflict and your motivation for this company are the material to have ready, each with your own decision and a measurable outcome. For the offer part, it is sensible advice to arrive with your expectations, notice period and start date settled, and with the questions you want answered about the team before you accept.

What to demonstrate

• Cultural fit, as candidates report for this stage
• Offer discussion, as candidates report for this stage

How to prepare

• Write five STAR stories (hard project, competing deadlines, difficult teammate, learning a new technology, a production incident) with the action in first person singular and a number in each result.
• Write a why-this-company answer that links digital banking and payments work to something you have built, and that would not fit a different employer unchanged.
• Settle your expected compensation range, notice period and earliest start date before the call.
• List three questions about the team: what it owns, how releases and on-call work, and where the role sits between product and engineering.

Where candidates lose points

Binary search that loops forever or skips the target because the interval convention is mixed (lo < hi with hi = mid - 1), or computes (lo + hi) / 2 in Java.

Pick one convention, closed [lo, hi] with lo <= hi or half-open [lo, hi) with lo < hi, and keep every update consistent with it. Use lo + (hi - lo) / 2. Before saying you are done, trace a one-element array and a target larger than every element.

Two-sum or the longest-substring window coded from memory with a silent bug: inserting into the map before checking, or moving the window's left edge backwards on input like 'abba'.

For each of the five reported coding problems, write the solution and then a short list of inputs that break the common wrong versions: [3, 3] for two-sum, 'abba' and the empty string for the sliding window, an empty and a one-node list for reversal, n = 93 for Fibonacci in a long. Run them by hand in practice.

Answering the banking design questions as if it were a social app: retrying a timed-out debit without an idempotency key, or accepting eventual consistency for balances.

For high availability, traffic spikes, microservices and production debugging, say explicitly how a retry is made safe (idempotency keys), where strong consistency is required (the ledger and balances), how failover avoids losing committed transactions, and how affected transactions are reconciled afterwards.

A URL shortener or caching answer that lists components (load balancer, Redis, database) without explaining key generation, invalidation or what happens when the cache fails.

Carry a fixed structure into each design answer: requirements and read/write ratio, API, data model, the core mechanism (base62 ids, cache-aside with delete-after-commit), then failure modes such as collisions, stampedes and the cache going down, and a trade-off you chose such as 301 versus 302.

Behavioral answers told as 'we did' with no individual decision, and a why-this-company answer that would fit any bank.

Write the five reported behavioral stories in first person singular, each with a decision you made, an alternative you rejected and a measured result. Base the company answer on digital banking and payments work in India and connect it to something you have actually built.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Iterative solution with three pointers: prev = null, curr = head; loop while curr != null: next = curr.next; curr.next = prev; prev = curr; curr = next; return prev as the new head.
2. Complexity: O(n) time and O(1) extra space; each node's pointer is flipped exactly once.
3. Mention the recursive version (reverse the rest, then head.next.next = head; head.next = null) and its cost: O(n) call-stack space, which can overflow on a very long list in Java.
4. Walk through edge cases out loud: empty list returns null, a single node returns itself, and a two-node list to confirm the old head's next becomes null.

Follow-up

• Reverse the list in groups of k nodes, leaving a final group shorter than k as it is.
• Reverse only the nodes between positions m and n in one pass.
• Use reversal to check whether a linked list is a palindrome in O(1) extra space.

Implement a binary search algorithm.

Medium · Coding / Algorithms

Approach

1. State the precondition: the array is sorted. Use lo = 0, hi = n - 1, loop while lo <= hi, and compute mid = lo + (hi - lo) / 2, because (lo + hi) / 2 can overflow int in Java.
2. Compare: if arr[mid] equals the target return mid; if smaller, lo = mid + 1; otherwise hi = mid - 1; return -1 when the loop ends. O(log n) time, O(1) space.
3. Keep the loop invariant consistent: with a closed interval [lo, hi] use lo <= hi and mid plus or minus 1; with a half-open [lo, hi) use lo < hi and hi = mid. Mixing the two causes infinite loops or skipped elements.
4. Test the edges: empty array, single element, target below the minimum or above the maximum, and duplicates (plain binary search returns any matching index, not the first).

Follow-up

• Return the first occurrence of the target when there are duplicates.
• Search in a sorted array that has been rotated at an unknown pivot.
• Use binary search on the answer, for example the minimum capacity needed to ship packages within D days.

Explain and code a solution for the "two-sum" problem.

Medium · Coding / Algorithms

Approach

1. Confirm the contract: return the indices of two different elements that sum to the target, exactly one answer, negatives allowed. The brute force checks every pair in O(n^2).
2. One-pass hash map from value to index: for each i, compute complement = target - nums[i]; if the map contains it, return [map.get(complement), i]; otherwise put nums[i] -> i. O(n) time, O(n) space.
3. Check before inserting, so an element is never paired with itself, and [3, 3] with target 6 still returns both indices.
4. Alternative: sort and use two pointers in O(n log n) time with less extra memory, but sorting loses the original indices unless you sort (value, index) pairs. In Java, watch for int overflow when adding large values.

Follow-up

• Return every unique pair that sums to the target, without duplicates.
• Extend it to three-sum in O(n^2).
• Numbers arrive as a stream: design add(number) and find(value) and discuss which operation you make fast.

How would you find the longest substring without repeating characters?

Medium · Coding / Algorithms

Approach

1. Sliding window over the string with a map from character to its last seen index (or an int array of size 128 for ASCII).
2. For each right index: if the character was seen at or after left, move left = max(left, lastIndex + 1); record the new last index; update best = max(best, right - left + 1).
3. The max() matters: without it a character seen before the window, as in 'abba', moves left backwards and gives a wrong length.
4. Complexity: O(n) time, O(min(n, alphabet size)) space. Edge cases: empty string returns 0, all identical characters return 1, all distinct return n. Track the start index too if the substring itself is asked for.

Follow-up

• Find the longest substring with at most k distinct characters.
• How does the solution change for Unicode text rather than ASCII?
• Return the substring itself, and the first one if several share the maximum length.

Solve a problem involving dynamic programming, such as the Fibonacci sequence.

Medium · Coding / Algorithms

Approach

1. Start from naive recursion fib(n) = fib(n-1) + fib(n-2), and show why it is exponential: the same subproblems are recomputed repeatedly.
2. Memoization (top-down with a cache) and tabulation (bottom-up array) both give O(n) time and O(n) space; since each value needs only the previous two, keep two variables for O(1) space.
3. Mention matrix exponentiation or fast doubling for O(log n) when n is huge, and overflow: a Java long overflows after F(92), so use BigInteger or compute modulo 1,000,000,007.
4. Generalise the method out loud: define the state, the transition and the base cases, then pick the evaluation order. The same steps solve climbing stairs, house robber and coin change.

Follow-up

• Solve coin change: the minimum number of coins to make an amount, or -1 if impossible.
• Compute F(n) mod 1,000,000,007 for n up to 10^18.
• Count the ways to climb n stairs taking 1, 2 or 3 steps at a time.

Describe the process you would use to optimize a database query.

Medium · Technical / Domain Questions

Approach

1. Start from evidence: find the slow query from the slow-query log or APM, note how often it runs, and get the real plan with EXPLAIN ANALYZE rather than guessing.
2. Read the plan for the usual culprits: full table scans on large tables, row estimates far from actual rows (stale statistics, fixed by ANALYZE), nested loops over big inputs, and sorts or hashes spilling to disk.
3. Fix access paths: add a composite index with equality columns first and the range or sort column last (for example (user_id, created_at) for a user's transactions in a date range), or a covering index so the table is not touched.
4. Make predicates index-friendly: no functions or implicit casts on indexed columns, no LIKE pattern starting with %, keyset pagination instead of large OFFSET, select only needed columns, and remove ORM N+1 query loops.
5. Weigh the cost: every index slows inserts and updates, which matters on a write-heavy transactions table; then re-measure with the same plan and production-like data to confirm the gain.

Follow-up

• Which index would serve SELECT * FROM transactions WHERE user_id = ? AND created_at BETWEEN ? AND ? ORDER BY created_at DESC, and why that column order?
• The index exists but the planner ignores it. What are the possible reasons?
• How would you verify the improvement in production without risking the live database?

Discuss the trade-offs between SQL and NoSQL databases.

Medium · System Design / Architecture

Approach

1. Relational databases give a fixed schema, joins, ACID transactions and strong consistency, which fits accounts, ledgers and anything where a debit and a credit must commit together.
2. NoSQL is several families: key-value (sessions, caches), document (flexible profiles), wide-column (high-volume time series, event logs) and graph. They scale out horizontally and absorb high write rates, usually with weaker or tunable consistency.
3. Name the costs on each side: relational scaling beyond one primary needs read replicas, partitioning or sharding; NoSQL pushes joins and cross-record integrity into the application, and you design the schema around known query patterns.
4. Decide from access patterns, not fashion, and say that using both is normal: a relational ledger for transactions, a key-value store for sessions or rate-limit counters, a wide-column or document store for activity history.

Follow-up

• How would you scale a relational transactions table once one primary is not enough?
• Design a NoSQL schema to fetch a user's last 50 transactions quickly. What is the partition key and the sort key?
• Can you get multi-record transactions in a NoSQL store, and at what cost?

What are the key differences between HTTP and HTTPS?

Medium · Technical / Domain Questions

Approach

1. Define it in one line: HTTPS is HTTP carried over TLS, on port 443 instead of 80; the HTTP messages are identical, the transport underneath is encrypted and authenticated.
2. Walk the TLS handshake: client hello with supported ciphers, server certificate chain validated against trusted CAs and the hostname, ephemeral key exchange (ECDHE, giving forward secrecy), then symmetric encryption (for example AES-GCM) for the session.
3. Name the three guarantees: confidentiality (no eavesdropping), integrity (tampering is detected), and server authentication (you are talking to the real host). Plain HTTP gives none, so credentials and session cookies are readable on the network.
4. Cover the costs and hardening: handshake latency (TLS 1.3 needs one round trip, resumption can cut it), certificate issuance and rotation, HSTS to block downgrade to HTTP, and mutual TLS when both sides of a service call must prove identity.
5. Close with what TLS does not protect: data at rest, the server's own logs, and metadata such as IP addresses and the hostname in SNI.

Follow-up

• What happens when the server's certificate has expired or does not match the hostname?
• How would you secure service-to-service calls inside a banking backend: mutual TLS, API keys or signed tokens?
• Why does TLS use asymmetric cryptography only for the key exchange and symmetric encryption for the data?

Can you explain the concept of Object-Oriented Programming and its principles?

Medium · Technical / Domain Questions

Approach

1. Define OOP as modelling a system as objects that hold state and expose behaviour, then give the four principles each with a Java example rather than a dictionary definition.
2. Encapsulation: an Account class keeps balance private and exposes debit(amount), which rejects a negative amount or an overdraft, so the invariant cannot be broken from outside. Abstraction: callers use a PaymentMethod interface without knowing the implementation.
3. Inheritance and polymorphism: CardPayment and WalletPayment implement PaymentMethod.pay(); the caller invokes pay() and the runtime type decides (overriding is runtime polymorphism, overloading is compile-time).
4. Add the judgement: prefer composition over deep inheritance hierarchies, respect Liskov substitution (a subclass must not weaken the parent's guarantees), and mention SOLID briefly as how the principles are applied in practice.

Follow-up

• When would you use an abstract class instead of an interface in Java, given default methods since Java 8?
• Give an example where inheritance caused a problem and composition fixed it.
• What is the contract between equals() and hashCode(), and what breaks in a HashMap if you violate it?

What is the significance of unit testing in software development?

Medium · Technical / Domain Questions

Approach

1. Define a unit test as a fast, deterministic test of one unit (a class or function) with its external dependencies replaced, and place it at the base of the test pyramid under integration and end-to-end tests.
2. Say what it buys: regressions caught before merge, freedom to refactor, and executable documentation of business rules. Give an example such as a fee calculator tested at zero, at the slab boundary and at the maximum amount, using BigDecimal rounding.
3. Describe the tooling and technique: JUnit 5 with Mockito, arrange-act-assert, mocks only for collaborators like repositories or HTTP clients, injected Clock for time-dependent code, and tests that run in CI on every pull request.
4. Give the limits: unit tests cannot prove the SQL or the wiring is right (that is integration testing), and coverage is a signal for untested code, not a goal in itself.

Follow-up

• How would you unit test code that depends on the current date and time?
• Where do you test that a repository query returns the right rows: unit or integration test, and with what database?
• A test fails one run in twenty. How do you find the cause?

How would you design a URL shortening service?

Medium · System Design / Architecture

Approach

1. Fix requirements: create a short code for a long URL, redirect on lookup, optional custom alias and expiry, click counts. Note it is read-heavy, so the redirect path drives the design.
2. Key generation: base62-encode a unique numeric id (from a database sequence or ranges of ids handed to each app server), or hash the URL and take a prefix with a collision check, or random codes with a uniqueness check. Seven base62 characters give about 3.5 trillion codes.
3. Storage: a table keyed by short code holding the long URL, owner, created and expiry times; every redirect is a primary-key lookup, so either a relational store or a key-value store works. Put hot codes in Redis and in front of that a CDN.
4. Redirect semantics: 301 is cached by browsers and saves load but hides repeat clicks; 302 keeps every click visible for analytics. Send click events to a queue and aggregate them asynchronously so analytics never slows the redirect.
5. Cover abuse and failure: rate limit creation per user, scan target URLs for malware, return 404 for expired codes, and keep redirects working from cache if the write path is down.

Follow-up

• Sequential ids make codes guessable. How would you prevent enumeration?
• Should the same long URL always get the same short code? What does each answer cost?
• How do you expire links and decide whether to reuse their codes?

Explain how you would implement a caching mechanism for a web application.

Medium · System Design / Architecture

Approach

1. Decide where to cache: browser and CDN for static and public responses, an in-process cache (for example Caffeine) for small, rarely changing data, and a distributed cache such as Redis when several app instances must share entries.
2. Pick the pattern: cache-aside (read from cache, on miss load from the database and populate) is the default; write-through keeps the cache updated on every write; write-behind trades durability for write speed and rarely suits financial data.
3. Plan invalidation: TTLs as a safety net, delete the key after the database commit on writes, or version keys. Use LRU or LFU eviction and track hit ratio and memory.
4. Handle the failure modes: cache stampede on a hot key expiring (request coalescing, a short lock, jittered TTLs), lookups for keys that do not exist (cache the negative result briefly or use a Bloom filter), and the cache being down (fall back to the database behind a rate limit).
5. State what not to cache, or cache very carefully: account balances and anything that must be read-your-writes consistent; cache reference data, user profiles and configuration instead.

Follow-up

• A writer updates the database while a reader repopulates the cache with the old value. How does a stale entry get in, and how do you prevent it?
• Redis goes down at peak traffic. What happens to your database, and what do you do about it?
• With ten app instances each holding an in-process cache, how do you invalidate an entry everywhere?

Describe the architecture of a microservices-based application.

Medium · System Design / Architecture

Approach

1. Describe services split by business capability (accounts, payments, notifications, KYC, reporting), each owning its own data store and deployed independently, for example as Spring Boot applications in containers.
2. Show the request path: clients go through an API gateway that handles authentication, rate limiting and routing; services find each other through service discovery and load balancing; synchronous calls use REST or gRPC, and events go over a message broker.
3. Handle cross-service consistency without distributed transactions: a saga with compensating actions (reverse a debit if the credit fails) and the transactional outbox pattern so a database write and its event are never out of step.
4. Cover operations: distributed tracing with a correlation id, centralised logs and metrics, timeouts, retries, circuit breakers and bulkheads so one slow service does not take down its callers.
5. Give the trade-off against a monolith: independent scaling and deployment versus network latency, partial failures and operational overhead; a small team may be better served by a modular monolith.

Follow-up

• A transfer must debit in one service and credit in another. Walk through the saga, including what happens when the credit fails.
• How would you split an existing monolith, and which service would you extract first?
• One downstream service becomes slow. How do you stop the slowdown from spreading to every caller?

What considerations would you make for ensuring high availability in a banking application?

Medium · System Design / Architecture

Approach

1. Set targets first: an availability SLO, and RPO and RTO per data type. For the ledger the RPO should be zero (no committed transaction may be lost), which shapes the database choice.
2. Remove single points of failure: stateless app instances behind a load balancer across availability zones, health checks that take bad instances out, rolling or blue-green deployments, and no shared local state.
3. Database: synchronous replication (or a quorum-based store) for the ledger so a failover loses nothing, automated failover with fencing to prevent split brain, asynchronous read replicas for statements and reports, and backups with regular restore drills.
4. Make retries safe: idempotency keys on every money-moving request, so a client retrying across a failover cannot post twice, and reconciliation jobs that catch anything left half-done.
5. Degrade gracefully: when a dependency fails, keep payments and balance checks up while switching off statements or offers; for balances choose consistency over availability and say so explicitly.

Follow-up

• The primary database fails in the middle of a transfer. What does the customer see, and what state is the ledger in?
• Active-active or active-passive across regions for a payments ledger: which would you choose and why?
• How would you prove your failover works before a real outage tests it?

Given a large dataset, how would you approach finding duplicate entries?

Medium · Problem-Solving / Case Studies

Approach

1. Define duplicate first: exact match on a key, match after normalisation (trimmed, lower-cased, formatted phone numbers), or fuzzy match. The definition changes the whole solution.
2. If it fits in memory: a HashSet of keys gives O(n) time and O(n) space; sorting and comparing neighbours gives O(n log n) time with little extra memory.
3. If it does not fit: hash-partition the records into k files by hash(key) mod k so all copies of a key land in the same file, then dedupe each file in memory; or run an external sort. On a cluster this is a groupBy in Spark or MapReduce.
4. In SQL: GROUP BY key HAVING COUNT(*) > 1 to find them, or ROW_NUMBER() OVER (PARTITION BY key ORDER BY created_at) and delete rows numbered above 1 to keep the earliest.
5. Mention approximation: a Bloom filter screens keys with little memory but has false positives, so confirm candidates with an exact check.

Follow-up

• Delete the duplicates but keep the earliest record of each. Write the SQL.
• Duplicates arrive in a live stream of payment events. How do you drop them?
• How would you find near-duplicate customer records with slightly different spellings?

If a system is experiencing performance issues, what steps would you take to diagnose the problem?

Medium · Problem-Solving / Case Studies

Approach

1. Pin down the symptom: which metric (p50 or p99 latency, throughput, error rate), which endpoints, since when, and whether it lines up with a deploy, a config change or a traffic change.
2. Check resources systematically with the USE method (utilisation, saturation, errors for CPU, memory, disk, network) and services with RED (rate, errors, duration).
3. Follow a slow request through distributed traces to the slow span, then drill in: slow-query log and EXPLAIN for the database, connection-pool wait times, latency of external dependencies.
4. For a Java service, check GC logs for long pauses, take thread dumps to find threads blocked on locks or pools, and look at heap growth for leaks.
5. Fix one thing, re-measure with the same metric, and add an alert or dashboard so the regression is caught earlier next time.

Follow-up

• p99 latency is high but p50 is normal. What does that suggest?
• CPU is low but latency is high. Where do you look?
• Memory grows steadily until the service crashes. How do you find the leak?

What strategy would you implement to handle a sudden spike in user traffic?

Medium · Problem-Solving / Case Studies

Approach

1. Separate planned spikes (a salary day, a sale, a campaign: load test, then pre-scale) from unplanned ones (scale out reactively and shed load).
2. Scale the stateless tier horizontally with autoscaling, keeping in mind instances take time to start; absorb reads with caches and a CDN; move non-urgent writes such as notifications onto a queue processed asynchronously.
3. Protect the core: rate limiting per user and per client with a token bucket, load shedding with 429 or 503 before the database is overwhelmed, bounded connection pools, and read replicas for read traffic.
4. Degrade gracefully: keep payments and balance checks working while switching off statements, recommendations or analytics, and put circuit breakers on slow dependencies.
5. Afterwards, check whether the spike was genuine or abusive (bots, credential stuffing) and adjust the edge protection.

Follow-up

• Implement a token-bucket rate limiter. What state does it keep per client?
• Autoscaling reacts too slowly for the spike. What do you do?
• How do you tell a real traffic spike from an attack?

How would you ensure the security of user data in your applications?

Medium · Problem-Solving / Case Studies

Approach

1. Classify the data first (credentials, identity documents, card numbers, transaction history), since protection follows sensitivity and regulation.
2. In transit: TLS everywhere, including internal calls. At rest: encrypted storage with keys in a KMS or HSM and rotation; field-level encryption or tokenization for the most sensitive fields; passwords hashed with bcrypt or Argon2 and a salt, never encrypted or plain-hashed.
3. Access: strong authentication, least-privilege authorisation, and an ownership check on every object fetched by id so a user cannot read another user's transaction by changing the id in the URL.
4. Application security: parameterised queries against SQL injection, output encoding against XSS, input validation, secrets in a vault rather than in code or config, dependency vulnerability scanning.
5. Operations: mask personal data in logs, keep audit trails of who accessed what, retain data only as long as required, and have an incident response plan for a breach.

Follow-up

• What is the difference between hashing, encrypting and tokenizing, and which would you use for passwords, card numbers and email addresses?
• How do you stop a logged-in user from reading someone else's data by editing an id in the request?
• A developer committed an API key to the repository. What do you do?

Describe how you would approach debugging a critical issue in production.

Medium · Problem-Solving / Case Studies

Approach

1. Mitigate before diagnosing: gauge impact (how many users, is money affected), open an incident channel, communicate status, and roll back or turn off a feature flag if the issue lines up with a recent change.
2. Collect evidence: error logs filtered by correlation id, metrics around the start time, traces of failing requests, and the list of deploys, config and infrastructure changes in that window.
3. Form one hypothesis at a time and test it safely: read-only queries, reproducing in staging with production-like data, or extra logging behind a flag, never experiments on live transactions.
4. For payments, identify every affected transaction, reconcile against the ledger and the partner's records, and correct through audited compensating entries rather than editing rows by hand.
5. Finish with a fix plus a test that reproduces the bug, then a blameless postmortem with owners and dates for each follow-up action.

Follow-up

• You cannot reproduce it locally. What next?
• Rollback is impossible because a schema migration already ran. What do you do?
• How do you find every customer affected and make sure each one is made whole?

Suggested practice checklist

Each day covers one cluster of this guide's reported questions: coding first, since coding assessments are the format candidates name for the technical stage, then core concepts, databases and security, design, reliability scenarios, and finally the HR stage.

Day 1 — Pointer and search fundamentals in Java

• Write linked-list reversal iteratively and recursively in Java without an IDE, then trace an empty list, one node and three nodes by hand.
• Write binary search with the closed-interval convention, then a first-occurrence version with the half-open convention, and test both on duplicates and out-of-range targets.
• Solve the reverse-in-groups-of-k and rotated-array variants as follow-up practice.

Deliverable: Four Java files (two reversals, two binary searches) plus the two variant solutions, each with an edge-case test list.

Day 2 — Hashing, sliding windows, dynamic programming and dedup

• Write two-sum with a one-pass HashMap and the sorted two-pointer alternative; test [3, 3] with target 6.
• Write longest substring without repeating characters with a last-index map, and test 'abba', '' and 'bbbb'.
• Write Fibonacci four ways (naive, memoized, tabulated, two variables), then coin change using the same state-transition-base steps.
• Outline the large-dataset duplicate answer: HashSet, sort, hash-partitioning to disk, and the ROW_NUMBER() SQL that keeps the earliest row.

Deliverable: Working Java solutions for two-sum, the sliding window, four Fibonacci versions and coin change, plus a one-page dedup outline with the SQL written out.

Day 3 — Core concepts out loud

• Explain the HTTPS handshake from client hello to symmetric encryption aloud, and list what TLS does not protect.
• Build a small Java example (Account, PaymentMethod interface, two implementations) that shows all four OOP principles.
• Write one Spring Boot @ControllerAdvice error handler and two JUnit 5 tests with Mockito for a fee calculator, including a boundary case and an injected Clock.

Deliverable: A recorded HTTPS explanation, the OOP example code, and a working error handler with its unit tests.

Day 4 — Databases and data security

• Take a slow query on a transactions-style table, run EXPLAIN ANALYZE before and after adding a (user_id, created_at) index, and note the plan change.
• Write a SQL versus NoSQL comparison table for a ledger, a session store and a transaction-history feed, with the partition and sort keys for the NoSQL case.
• List the security controls for user data, from TLS and KMS-held keys to bcrypt, tokenization, object-ownership checks and log masking, with one sentence each on why.

Deliverable: Before-and-after query plans, a three-row database choice table, and a one-page data security checklist.

Day 5 — System design: URL shortener and caching

• Whiteboard the URL shortener end to end: requirements, API, base62 key generation, storage, Redis and CDN, the 301 versus 302 choice, async analytics.
• Whiteboard a cache-aside layer for a web application with TTLs, delete-after-commit invalidation, stampede protection and the Redis-down fallback.
• Answer each design's three follow-ups aloud, especially guessable codes and the stale-write race.

Deliverable: Two design diagrams with written notes on trade-offs and failure modes, and spoken answers to six follow-ups.

Day 6 — Reliability scenarios for a banking system

• Write the high-availability answer for a banking application: RPO and RTO, multi-zone app tier, synchronous ledger replication, fenced failover, idempotency keys, graceful degradation.
• Sketch a microservices transfer flow with a saga, compensating actions and the outbox pattern, plus gateway, tracing and circuit breakers.
• Write step-by-step runbooks for a performance regression (USE/RED, traces, GC logs, thread dumps) and a production incident (mitigate, evidence, reconcile, postmortem).
• Outline the traffic-spike response: autoscaling, caching, queues, token-bucket rate limiting and load shedding.

Deliverable: An HA answer sheet, a saga diagram, two incident runbooks and a traffic-spike outline.

Day 7 — Behavioral stories and the HR stage

• Write five STAR stories, for the challenging-project, multiple-deadlines, difficult-teammate and keeping-current questions plus a production incident you owned, in first person singular with a measured result each.
• Write a why-Airtel-Payments-Bank answer tied to payments work you have done, then say it aloud and cut anything that would fit another employer.
• Settle compensation expectations, notice period and start date, and write three questions about the team for the HR Round.

Deliverable: Five rehearsed STAR stories, a company-specific motivation answer, and a one-page sheet of your expectations, notice period, start date and team questions.

Behavioural preparation

Candidates report an HR Round as the last stage, where cultural fit and any offer come up, and the reported behavioral questions cover a hard project, competing deadlines, a difficult teammate, staying current with technology and your reason for choosing this company. Each answer needs a decision you made yourself, the trade-off behind it and a result you can measure.

How do you handle error management in your applications?

Medium · Technical / Domain Questions

Approach

1. Classify errors first: invalid input (return a 4xx with a clear message), expected business failures such as insufficient balance (a typed result or domain exception), transient infrastructure failures such as timeouts (retry or fail gracefully), and bugs (fail loudly and alert).
2. In Java and Spring Boot: never swallow exceptions, wrap them with context when rethrowing, and map them centrally with @ControllerAdvice to one consistent error response with an error code and a correlation id.
3. Retry only idempotent operations, with exponential backoff and jitter, and guard money-moving calls with an idempotency key so a retry after a timeout cannot debit twice; add timeouts and a circuit breaker on every remote call.
4. Log with structure and a correlation id, never log card numbers, passwords or tokens, and alert on error-rate changes rather than single errors.
5. Anchor the answer in one real example from your work: the failure, how your handling contained it, and what you changed afterwards.

Follow-up

• A call to debit an account times out. Did the debit happen, and how does your code find out safely?
• Checked or unchecked exceptions for business failures in Java: which do you use and why?
• What exactly do you put in an error log line, and what do you deliberately leave out?

Describe a challenging project you worked on. What was your role, and how did you overcome obstacles?

Medium · Behavioral / Leadership

Approach

1. Choose a project where you owned a technical decision and the difficulty was real: a migration, a performance problem, a hard deadline, an unclear requirement. Avoid a story where your part was small.
2. Use STAR with most of the time on Action: what you decided, the alternatives you rejected and why, and how you handled the obstacle, whether technical (a failing approach) or human (a blocked dependency).
3. Speak in first person singular for your actions and be explicit about what the team did versus what you did; a story told entirely as 'the team did' hides your role, and the question asks for your role.
4. End with a measured result (latency, error rate, delivery date, money or time saved) and one lesson you now apply.

Follow-up

• What would you do differently if you started that project again?
• How did you know your change caused the improvement rather than something else?
• Who disagreed with your approach, and how did you resolve it?

How do you prioritize tasks when you have multiple deadlines?

Medium · Behavioral / Leadership

Approach

1. Give your method, then prove it with one real example: rank work by impact and urgency, separate hard deadlines (regulatory, customer commitments) from soft ones, and do the blocking dependencies first.
2. Show the trade-off explicitly: what you deprioritised, who you told, and when. Telling a stakeholder early that something will slip is a strong behaviour to show.
3. Use a concrete conflict, for example a production defect arriving during a feature deadline, and say how you split, delegated or renegotiated scope.
4. Avoid answers that amount to working longer hours; they describe effort, not prioritisation.

Follow-up

• Two senior stakeholders each say their task is the top priority. What do you do?
• Tell me about a time your prioritisation was wrong. How did you notice and recover?
• How do you track what you have deferred so it does not get lost?

Can you provide an example of a time you had to work with a difficult team member?

Medium · Behavioral / Leadership

Approach

1. Describe the behaviour and its effect on the work (missed reviews, blocking decisions, dismissive comments), not the person's character.
2. Show the steps you took in order: a private conversation to understand their side and constraints, a shared goal you agreed on, a concrete working agreement, and follow-up; escalation only after that failed.
3. Include what you changed in your own behaviour; it shows self-awareness.
4. Finish with the outcome for the work and the relationship. A story where you win and the colleague is shown as the problem reads poorly.

Follow-up

• What if the conversation had not changed anything? When would you involve your manager?
• Looking back, what part of the friction was caused by you?
• How do you give critical code-review feedback to someone who takes it badly?

How do you keep up with new technologies and trends in software development?

Medium · Behavioral / Leadership

Approach

1. Name your actual sources briefly (release notes for Java and Spring Boot, engineering blogs, conference talks, source code of libraries you use), then move quickly to evidence.
2. Give one example where you evaluated something new with a time-boxed spike or benchmark and adopted it, for example Java records, virtual threads in Java 21, or a Spring Boot upgrade, and the result it produced.
3. Give one example where you evaluated something and decided not to adopt it, with the reason; it shows judgement rather than enthusiasm for novelty.
4. Connect it to the role: security patches and dependency updates matter more in a banking codebase, so mention how you track vulnerabilities in your dependencies.

Follow-up

• What is the most recent technology you learned, and what did you build with it?
• How would you convince your team to adopt a new library or framework?
• How do you decide something new is mature enough for a production financial system?

Why do you want to work for Airtel Payments Bank specifically?

Medium · Behavioral / Leadership

Approach

1. Tie your answer to facts you can state: Airtel Payments Bank operates in digital banking in India, and candidates describe the role as touching payment systems under security and regulatory constraints. Read the company's own public material on its products before the interview.
2. Connect it to your experience: a transactional system, payment integration, Java and Spring Boot work, or security work you have done, and what you want to learn next that this role offers.
3. Make it specific enough that it would not work for another bank or a generic product company; mention the kind of problems (reliability of money movement, scale of users, compliance) that draw you.
4. Avoid leading with compensation, location or the brand name alone.

Follow-up

• What do you know about the company's products and who uses them?
• Why a payments bank rather than a larger traditional bank or a fintech startup?
• Where do you see yourself after two years in this role?