Skip to content

Mastercard Interview Questions and Answers (2026)

Mastercard’s SDE process for its India engineering centers opens with a coding round built to catch edge-case gaps, then layers in Java/CS-fundamentals and payments-adjacent technical rounds before a closing HR round.

Round Duration What they test
Coding Round ~60 min 2 DSA problems (easy-medium), edge-case handling
Technical Interview 1 30-45 min CS fundamentals, DSA
Technical Interview 2 30-45 min Java/OOP, SQL, multithreading, project discussion
HR Round 20-30 min Interpersonal skills, cultural fit

Two problems, individually rated easy-to-medium, run in about an hour. The catch reported consistently across candidates: the core logic is usually straightforward, but solutions are scored hard on edge cases rather than just the happy path.

Common questions

  • Array manipulation problems with a boundary-condition twist (empty input, duplicates, negative values)
  • String manipulation and pattern-matching questions
  • A problem that looks like simple iteration but has an easy-to-miss edge case in the constraints

Focused on core CS fundamentals and DSA, checking whether you understand the concepts behind your code rather than just syntax.

Common questions

  • Explain time/space complexity trade-offs for your coding-round solution
  • Core DSA: arrays, linked lists, stacks/queues, basic tree traversal
  • OS/DBMS fundamentals - process scheduling, indexing, normalization

Goes deeper into practical engineering - Java and OOP concepts, SQL, multithreading - and typically includes a resume/project walkthrough.

Common questions

  • Explain the four pillars of OOP with a class-design example
  • Write a SQL query involving joins or aggregation
  • Multithreading basics - thread safety, synchronization, deadlock conditions
  • Walk through your most complex project: architecture, your specific contribution, hardest bug
  • How would you think about reliability or security in a system you’ve built, given Mastercard runs a global payments network?

Full round-by-round narratives are on the Mastercard interview experience page.

A closing conversation on interpersonal skills, cultural fit, and motivation. Lighter than the technical rounds but not a formality - vague or generic answers stand out.

Common questions

  • Tell me about yourself, and why Mastercard?
  • Walk me through a project where you had to handle an edge case you initially missed
  • Describe a time you worked through a disagreement with a teammate
  • Are you comfortable with the location and notice period Mastercard expects?

Sample answer frameworks for each of these are on the Mastercard HR interview questions page.

Common technical interview questions and answers

Section titled “Common technical interview questions and answers”
Q: Move all zeroes in an array to the end while keeping the order of non-zero elements. What is the optimal approach?

Use a two-pointer scan in a single pass. Keep a write index starting at 0; iterate a read index across the array, and whenever the element is non-zero, copy it to the write index and increment the write index. After the loop, fill positions from the write index to the end with zeroes. That is O(n) time and O(1) extra space with at most n writes. The edge cases Mastercard graders look for are an empty array, an array of all zeroes, an array with no zeroes at all, and preserving relative order - a naive approach that repeatedly shifts elements degrades to O(n squared).

Q: How do you check whether two strings are anagrams?

Sorting both strings and comparing them works and is O(n log n). The better answer is a frequency count: if the alphabet is fixed, use an int array of size 26 (or a hash map for Unicode), increment for each character of the first string, decrement for each character of the second, and confirm every counter is zero. That is O(n) time and O(1) space for a fixed alphabet. Handle the edge cases explicitly - unequal lengths return false immediately, and clarify with the interviewer whether case and whitespace matter.

Q: Explain the four pillars of OOP with a class-design example.

Encapsulation bundles data with the methods that operate on it and hides internal state behind accessors - an Account class keeps balance private and exposes deposit and withdraw so no caller can set a negative balance. Abstraction exposes only what a caller needs: a PaymentMethod interface declares authorize and capture without revealing whether the implementation is a card or a bank transfer. Inheritance lets CardPayment reuse and specialise a base Payment class. Polymorphism lets one reference to Payment dispatch at runtime to CardPayment or WalletPayment, so adding a new payment type needs no change to the calling code.

Q: Write a SQL query to find employees earning more than their department’s average salary.

Use a correlated subquery: SELECT e.name, e.salary FROM employees e WHERE e.salary > (SELECT AVG(s.salary) FROM employees s WHERE s.dept_id = e.dept_id); The inner query recomputes the average for each row’s department. A window-function form is usually faster on large tables: SELECT name, salary FROM (SELECT name, salary, AVG(salary) OVER (PARTITION BY dept_id) AS dept_avg FROM employees) t WHERE salary > dept_avg; The second version scans the table once instead of once per row, which matters as soon as the table is large enough to be interesting.

Q: How does a HashMap work internally in Java?

A HashMap keeps an array of buckets. On put, it calls hashCode() on the key, applies an internal spreading function to mix the high bits, and maps the result to a bucket index using the table size, which is always a power of two. Collisions within a bucket are stored in a linked list, and since Java 8 a bucket converts to a balanced tree once it holds eight or more entries, which bounds worst-case lookup at O(log k) instead of O(k). When size exceeds capacity times the load factor (0.75 by default) the table doubles and all entries are rehashed. Keys must implement hashCode and equals consistently, and mutable keys break lookups because the entry ends up in the wrong bucket.

Q: What are the four conditions for deadlock, and how do you avoid it in multithreaded code?

Deadlock requires all four of mutual exclusion, hold-and-wait, no preemption, and circular wait to hold simultaneously. Break any one and deadlock cannot occur. The most practical fix in application code is to remove circular wait by imposing a global lock-ordering rule - every thread that needs both accountA and accountB locks them in a fixed order such as ascending account id. Other options are timed acquisition (tryLock with a timeout so a thread backs off and retries instead of blocking forever), acquiring all locks atomically to remove hold-and-wait, or using lock-free structures such as ConcurrentHashMap and the atomic classes.

Q: What is database normalisation, and what does 3NF actually require?

Normalisation organises a schema to remove redundancy and update anomalies. First normal form requires atomic column values with no repeating groups. Second normal form additionally requires that every non-key column depends on the whole composite primary key, not just part of it. Third normal form additionally removes transitive dependencies - no non-key column may depend on another non-key column, so storing dept_id and dept_name together in an employee table violates 3NF because dept_name depends on dept_id, not on the employee id. In practice reporting and payments read-paths are often deliberately denormalised to avoid multi-way joins on the hot path, trading write-side redundancy for read speed.

Q: What is the difference between a process and a thread, and when would you choose one over the other?

A process is an independent execution unit with its own virtual address space, file descriptors and memory protection; a thread is a unit of execution inside a process that shares the process’s heap and file descriptors while keeping its own stack, registers and program counter. Context switching between threads is cheaper because the memory map does not change. Threads are the right choice when tasks must share large amounts of in-memory state, such as concurrently servicing many authorisation requests against a shared cache; separate processes are safer when isolation matters, because one crashing process cannot corrupt another’s memory. The cost of threads is that shared mutable state needs synchronisation, which introduces race conditions and deadlock risk.

Frequently asked questions about Mastercard interviews

Section titled “Frequently asked questions about Mastercard interviews”
What is the Mastercard interview process for freshers?

Mastercard typically runs 3-4 rounds for campus/SDE hires: 1. Coding Round (around 1 hour) - usually 2 problems, easy to medium DSA (array and string manipulation are common), with heavy emphasis on edge-case handling. 2. Technical Interview 1 - core CS fundamentals and DSA. 3. Technical Interview 2 - Java/OOP, SQL, multithreading, and practical/project discussion. 4. HR Round - interpersonal skills and cultural fit. Some campus drives compress this to a coding round followed by a combined technical + HR interview.

What questions are asked in Mastercard interviews?

Coding rounds favor problems that look simple but hide edge cases - array and string manipulation questions are the most commonly reported pattern. Technical interviews cover DSA, OOP concepts, SQL, and multithreading, plus your resume projects. Because Mastercard operates a global payments network, interviewers sometimes probe how you’d think about reliability, security, or scale in a system-design-adjacent discussion, even at the fresher level.

How many rounds are there in the Mastercard interview?

Most drives run 3-4 rounds: a coding round and one or two technical interviews, followed by an HR round. Some campus processes reduce this to 2 rounds - a coding round plus a combined technical and HR interview.

How should I prepare for Mastercard interviews?

Practice coding problems that require careful edge-case handling rather than just the happy path, since Mastercard’s coding round is known for this - array/string problems are the most common pattern. Revise Java/OOP, SQL, and multithreading basics for the technical rounds, and be ready to discuss your projects in depth. Research Mastercard’s products and payments business so your ‘Why Mastercard’ answer reflects genuine interest rather than a generic response.

What programming languages and topics does Mastercard’s technical round focus on?

Java is the most commonly reported language in Mastercard’s technical interviews, alongside OOP concepts, SQL queries, multithreading, and general data-structure/algorithm questions. Interviewers also cover coding paradigms more broadly (OOP vs functional approaches), so be ready to reason about design choices, not just write working code.

Is Mastercard’s coding round difficult?

The two problems are usually rated easy-to-medium individually, but candidates consistently report that the difficulty is in the edge cases, not the core logic - a solution that looks right on the sample input can still fail on boundary conditions. Budget extra time to test your solution against edge cases before you consider it done.

Looking for placement papers, OA practice, or coding questions?

Section titled “Looking for placement papers, OA practice, or coding questions?”