Mastercard Coding: What to Expect

Most companies grade a coding round on one axis: can you find the right data structure and implement it in time? Mastercard grades on two. The first is ordinary data structures and algorithms. In the live rounds it sits at a comfortable easy-to-medium: reverse a linked list, find a Premium question, build a min stack, merge two arrays in a single loop. The second axis is Java itself, treated as a subject you can be examined on. That's where Mastercard parts ways with a generic loop. Candidates report writing a Streams pipeline and predicting the output of a string-concatenation puzzle. They're asked how a Spring bean is constructed, and which SOLID principle their class design honors. Prepare only the first axis and you'll pass the algorithm and stall on the language.

Take that two-axis shape in before you drill. Mastercard's engineering hiring centers on India, dense in Pune. There's a smaller presence in Gurgaon, Dublin, and the Vancouver "Launch" new-grad program. Across those loops the pattern holds. A DS&A problem proves you can code. Then a run of Java and Spring questions proves you know the platform you claim on your resume. Backend candidates feel the Java axis hardest, because the deep-internals round is aimed at them. This overview walks the whole surface so you can see where your time should go. The two paid lessons in this section, Java and Spring Internals and Coding and SQL, take each axis down to the level you'll be tested at.

The DS&A axis, and why it is bimodal

In the live technical rounds the algorithm bar is deliberately modest. Reported problems cluster around the standard easy-to-medium canon. Get the middle of a linked list and reverse it. Validate an anagram or a palindrome, and find the first unique character. Check valid parentheses across every edge case, and decode an encoded string. Build and then reverse a min stack, merge intervals, swap adjacent elements. Now and then comes a gentle longest-increasing-subsequence variant. Expect some Mastercard-flavored warmups by name: FizzBuzz, printing primes in a range, and converting a number to words in the Indian lakh-and-crore format. The interviewer usually watches cleanliness and communication more than raw difficulty. A knockout screen is trying to weed out people who can't code at all. It isn't hunting for the one person who memorized the hardest problem.

The campus and new-grad online assessment is a different animal, and that's the trap. The OA is typically two problems in sixty minutes, on platforms like HirePro or a HackerRank-style STDIN and STDOUT grader. Its difficulty spikes to genuine hard. Recurring shapes include matrix breadth-first search with greedy simulation, and interval dynamic programming for minimum turns to build a string. Others are a bitmask-DP-plus-Trie counting problem with small N, and graph combinatorics that count edge deletions forming exactly K components. For a student or new grad, the OA is the hardest gate in the whole process. It rewards different prep than the friendly live rounds. Drill interval DP, graph DP, combinatorics, Trie, and matrix BFS before a campus assessment. Don't let the easy live-round reputation lull you.

The Mastercard angle

Match your DS&A prep to your track. The difficulty is bimodal, and preparing for the average fails you at both ends. A lateral or experienced candidate often skips the OA entirely. Their live rounds are satisfied by a clean min stack and a well-explained anagram check, so over-drilling contest hards is wasted motion. What's scarce there is fluent, readable Java and clear narration. A campus candidate faces the opposite. The sixty-minute OA can hand you a hard interval-DP or graph-combinatorics problem cold. No amount of easy-medium practice prepares you for it. Decide which door you're walking through first. Then weight your algorithm practice toward that door, not a generic middle that matches neither.

The Java-language axis, the real differentiator

Mastercard stands apart by treating Java as an examinable subject. It's more than the tool you solve the algorithm in. Four sub-topics recur so often they define the guide. First, Java 8 Streams. Interviewers repeatedly ask for a single generic pipeline. It might group a list into a map, bucket employees into age ranges, or filter and map in one pass. It might count resources per skill, or find a Premium question the functional way. Second, functional interfaces and lambdas. Write your own Predicate or Function, or compute the area of a rectangle through a functional interface you define. Explain when Function fits versus Predicate. Third, output-prediction trivia. Fourth, the collections and object-model questions underneath all of it. You can't fake this fluency in the moment. Rehearse it until it's muscle memory.

// "Group these employees by department into a Map<String, List<Employee>>,
// in one stream pipeline." This exact shape recurs across reports.
Map<String, List<Employee>> byDept = employees.stream()
    .collect(Collectors.groupingBy(Employee::getDepartment));
// The common follow-up: don't collect the whole object, collect a field.
Map<String, List<String>> namesByDept = employees.stream()
    .collect(Collectors.groupingBy(
        Employee::getDepartment,
        Collectors.mapping(Employee::getName, Collectors.toList())));
// And the counting variant: how many per key?
Map<String, Long> countByDept = employees.stream()
    .collect(Collectors.groupingBy(Employee::getDepartment,
                                   Collectors.counting()));

The output-prediction puzzles look like trivia. They probe whether you understand the language's semantics as well as its syntax. The classic is string concatenation with mixed operands. Where the parentheses-free additions sit changes the answer, because integer addition binds left to right until a String appears. Alongside it come the interned-string identity puzzles and the gap between reference equality and value equality. Then the object-model questions. Can you instantiate an abstract class? What are the several ways to create an object? How do static and final interact with construction? None of these are hard once you've thought them through. All of them are easy to miss cold.

// What prints? Evaluation runs left to right.
String a = 21 + "abc" + 49 + 14;   // 21 turns to text at "abc" -> "21abc4914"
String b = 21 + 49 + "abc" + 14;   // 21 + 49 add as ints first -> "70abc14"
// Identity vs equality, the other favorite:
String s1 = "pay";
String s2 = "pay";               // same interned pool entry
String s3 = new String("pay");   // fresh object on the heap
boolean x = (s1 == s2);          // true, same reference
boolean y = (s1 == s3);          // false, different reference
boolean z = s1.equals(s3);       // true, same value

For backend roles the Java axis extends into a heavily weighted oral round on Spring Boot internals. The Technical SME or Tech Lead earns the "deep" reputation here. Expect the bean lifecycle and bean scopes, and dependency injection and its forms. Expect how @Transactional works under the hood, and what happens on a nested-transaction rollback. Then aspect-oriented programming with @Around and @Aspect, and the reflection Spring leans on. Add auto-configuration, global exception handling through @ControllerAdvice, and the Spring Security filter chain with a JWT flow and @PreAuthorize. None of it is asked as toy definitions. The interviewer wants the mechanism. What proxies get created? When does the container call what? Why doesn't a self-invoked @Transactional method open a new transaction? The next lesson, Java and Spring Internals, is built around these mechanisms.

SQL and the JOIN battery

SQL shows up most often inside the SME round. That's on-brand for a company whose business is moving and reconciling transaction records. The core ask is the four JOIN types, written out, not described: an inner join, both outer joins, and the full join. Say clearly which rows survive each. Around that sit the practical queries that separate ORM users from people who understand the database. Total amount per customer. The customers who've placed no orders at all. Paginating results with LIMIT and OFFSET. The deeper follow-ups probe why a query is slow and how you'd speed it up. They cover clustered versus non-clustered indexes, the ACID properties, and transaction isolation levels and the phantom-read anomaly. Normalization up to fourth normal form comes up too. Treat SQL as a first-class round.

SOLID and design-pattern low-level design

Object-oriented design is close to universal in the loop, usually in the Hiring Manager or Managerial round. It's graded on whether your class design reflects SOLID and a working command of the common patterns. The recurring prompts are concrete. Design a car system using patterns. Model a bank account class that can create, deposit, withdraw, and transfer, then return the top-K accounts by activity. Design an elevator that starts single-user and grows to multi-user. Or explain a design pattern you've used in production and why. Interface segregation and aggregation versus composition come up by name. So do the Singleton, Factory, Builder, Observer, and Template patterns. The evaluator checks whether you reach for the right abstraction under a moving requirement. Name the principle or pattern as you apply it, and let the requirement change without your design collapsing.

The Mastercard angle

Payments is a natural flavor for the design questions. Prepare the generic craft first. The brand tempts you to over-index on payment-network specifics. The system-design section does cover on-brand prompts like a distributed payment system and idempotent transaction handling. The coding loop's low-level design, though, is mostly ordinary OOP: cars, elevators, bank-account classes, top-K activity. Disciplined SOLID reasoning and pattern fluency you could apply in any domain clear the bar. Layer the payments angle on top as color. Build the general design muscle, then dress it in Mastercard's world where the prompt invites it.

How it is graded, and how to route yourself

The India loop is the most common path. It runs a recruiter screen, then an elimination-style technical screening. Then come three same-day loop rounds, often labeled Technical SME, Bar Raiser, and Hiring Manager, and a closing HR call. Yes, Mastercard uses the "Bar Raiser" label for real. It's a code-pairing, debugging, behavioral, and resume round, not Amazon folklore borrowed by mistake. Each round is described as a knockout, so consistency across the day beats a single brilliant answer. Behavioral competency is scored in every round. The cultural keyword to have a genuine answer for is the Decency Quotient, Mastercard's own shorthand for empathy and ethics. Read it as a culture theme woven through the day, not a formal per-question rubric.

Route your prep by role and region. A campus or new-grad candidate should treat the hard online assessment as the primary gate. Drill interval DP, graph DP, and Trie problems before anything else. A lateral backend engineer should treat the Java-and-Spring-internals oral as the primary gate. The live algorithm bar is friendly, and offers are won and lost on language depth. Full-stack candidates carry the same Java backend plus an Angular or React layer. SDET candidates swap some algorithm depth for Java trivia plus a test framework like Selenium or RestAssured. One structural note trips people up. Mastercard's India ladder is inverted, so a lower number is more senior. L9 is the entry Software Engineer I and L7 is the Senior Software Engineer. Confirm your target level early. The design and internals weight climbs steeply with it.

The lessons in this section

This section splits the coding surface along the two axes that decide your prep. Start with the axis that matches your track. Backend candidates should read both, because the loop tests each.

Common questions