Tech Mahindra Interview Questions (2026): Real, With Answers

Set cost price at 100. Marked price is 140. A 25 percent discount off 140 is 35, so the selling price is 105. Profit is 105 minus 100, or 5, which is a 5 percent profit on the original cost.

The trap in this style of question is discounting off the cost price instead of the marked price. Tech Mahindra's aptitude section leans heavily on profit and loss, percentages, and time-and-work problems structured exactly this way, two operations stacked on top of each other so a rushed candidate applies the second percentage to the wrong base.

Pipe A does 1/6 of the tank per hour, pipe B does 1/8 per hour. Together that's 1/6 + 1/8 = 4/24 + 3/24 = 7/24 of the tank per hour. Time to fill the whole tank is the reciprocal, 24/7 hours, which is about 3 hours and 26 minutes.

Look at the differences between consecutive terms: 4, 6, 8, 10. Each gap increases by 2, so the next gap is 12, giving 30 + 12 = 42. Another way to see the same pattern: each term equals n times (n+1), so the sixth term is 6 times 7, which is 42.

The verbal section weights sentence correction and error-spotting more heavily than vocabulary lists, and the most common trap is a subject and verb separated by a long prepositional phrase, where the verb ends up agreeing with the noun closest to it instead of the actual subject. "The list of items on the shelves were checked" is wrong because "list" is singular, "were" should be "was," even though "items" sits right before the verb.

A single pass with a running maximum handles this in O(n) time and O(1) space, no sorting required.

int findMax(int arr[], int n) {
  int maxVal = arr[0];
  for (int i = 1; i < n; i++) {
    if (arr[i] > maxVal) {
      maxVal = arr[i];
    }
  }
  return maxVal;
}

This is reported as one of the actual opening coding problems in Tech Mahindra's written round. It's a warm-up question, but interviewers do watch for whether you handle an empty array or initialize maxVal to 0 instead of the first element, which silently breaks on an all-negative array.

Words separated by single spaces means the word count is the space count plus one, as long as there's no leading, trailing, or doubled whitespace to worry about. The safer, more general approach splits on whitespace and counts non-empty tokens directly, which survives messy input.

def count_words_spaces(sentence):
  spaces = sentence.count(" ")
  words = len([w for w in sentence.split(" ") if w != ""])
  return words, spaces

Peel off digits from the end using modulo 10, build the reversed number by multiplying the running result by 10 and adding the digit, and divide the original by 10 each iteration.

int reverseNumber(int n) {
  int reversed = 0;
  while (n != 0) {
    int digit = n % 10;
    reversed = reversed * 10 + digit;
    n /= 10;
  }
  return reversed;
}

Candidates specifically report being asked to write this one on paper in the live technical round, not on a computer, which is a different skill than typing it into an IDE with autocomplete. Practice writing it by hand at least once before the interview.

One pass, add to one running total if the value is even, the other if it's odd, then subtract at the end.

def even_odd_diff(arr):
  even_sum = sum(x for x in arr if x % 2 == 0)
  odd_sum = sum(x for x in arr if x % 2 != 0)
  return even_sum - odd_sum

Normalize the string first, lowercase it and strip anything that isn't a letter or digit, then compare it against its own reverse.

def is_palindrome(s):
  cleaned = "".join(ch.lower() for ch in s if ch.isalnum())
  return cleaned == cleaned[::-1]

Encapsulation bundles data and the methods that operate on it, hiding internal state behind a public interface, a class exposing getBalance() while keeping the actual balance field private. Abstraction hides implementation complexity behind a simpler interface, a Car class exposing drive() without the caller needing to know how the engine control unit works underneath. Inheritance lets a subclass reuse and extend a parent class's behavior, SavingsAccount extending a base Account class. Polymorphism lets the same method call behave differently depending on the actual runtime type, calling speak() on an Animal reference that's actually a Dog produces a bark, not a generic animal sound.

Overloading is having multiple methods with the same name but different parameter lists in the same class, resolved at compile time based on the arguments you pass. Overriding is a subclass providing its own implementation of a method that already exists in its parent class, with the same signature, resolved at runtime based on the actual object type.

class Calculator {
  int add(int a, int b) { return a + b; }
  double add(double a, double b) { return a + b; } // overloading
}

class Shape {
  double area() { return 0; }
}
class Circle extends Shape {
  double area() { return 3.14 * radius * radius; } // overriding
}

No to both, directly. An abstract class can have unimplemented abstract methods, so instantiating it directly would leave those methods with no body to call, which the compiler blocks. An interface historically had no implementation at all, though modern Java allows default and static methods on interfaces, and the same rule holds, you can't new up an interface, only a concrete class that implements it.

A constructor initializes an object's state at the moment it's created, and it shares its name with the class and has no return type. If you don't define one yourself, the compiler inserts a default no-argument constructor that does nothing beyond default field initialization, but the moment you write any constructor of your own, that automatic default disappears and you have to provide a no-arg one explicitly if you still need it.

A primary key uniquely identifies a row and can't be null. A foreign key references a primary key in another table, enforcing referential integrity between the two. A candidate key is any column, or set of columns, that could serve as the primary key, a table can have several candidate keys but only one gets chosen as primary. A unique key enforces uniqueness like a primary key but does allow a null value. A composite key is a primary key made of more than one column, used when no single column is unique on its own.

INNER JOIN returns only rows where the join condition matches in both tables. LEFT JOIN returns every row from the left table regardless of a match, filling unmatched columns from the right table with NULL. A self-join is a table joined to itself, using two aliases for the same table, useful for comparisons within one table, finding employees who report to a manager who's also in the same Employee table, for example.

ArrayList is backed by a resizable array, so random access by index is O(1), but inserting or removing from the middle requires shifting every element after it, O(n). LinkedList is backed by a doubly linked list, so insertion and removal at a known position is O(1) once you're there, but getting to that position by index requires walking the list, O(n).

In practice, ArrayList wins the overwhelming majority of real use cases because most code reads far more than it inserts into the middle, and modern CPUs favor ArrayList's contiguous memory layout for cache performance even in scenarios that look favorable for LinkedList on paper.

This question is reported almost verbatim across multiple sources, often framed directly against competitors like Wipro, TCS, or Infosys. A generic answer about "growth opportunities" is what most candidates give, and it's exactly why it doesn't land. A better answer names something specific, a domain Tech Mahindra actually has depth in that matches your background, telecom, automotive, or manufacturing engineering, for instance, and why that specific overlap matters to you, not a rehearsed line about company culture you could paste into any application.

Given how much of Tech Mahindra's business is client-driven service delivery across telecom, automotive, and enterprise IT, this question is really checking flexibility, whether your career expectations match a services company's staffing model, where you're placed on whichever project has an open seat matching your skill set, rather than one you hand-pick. An honest answer here, stating a genuine constraint if you have one, like a location tie or a hard preference, saves both sides time later rather than agreeing to something you'll walk back after joining.

The failure mode here is answering with a disguised strength, "I work too hard" or "I'm a perfectist," which every interviewer has heard a hundred times and reads as evasive. A real weakness, stated plainly, followed by one specific thing you've changed because of it, reads as far more credible. Something like consistently underestimating how long a task will take, and the concrete habit you built to correct for it, padding estimates or breaking work into smaller pieces before committing to a deadline, lands better than a vague platitude.

Compare ROAD to URDG letter by letter. R shifts to U (+3), O shifts to R (+3), A shifts to D (+3), D shifts to G (+3). Every letter simply moves three places forward in the alphabet. Apply the same +3 shift to TABLE: T becomes W, A becomes D, B becomes E, L becomes O, E becomes H, giving WDEOH.

Coding-decoding questions like this show up under the logical reasoning section, alongside blood relations and data sufficiency. The fastest way through them is checking the shift on the first letter, confirming it holds on a second letter, then applying it mechanically rather than re-deriving the pattern for every letter.

These circular seating puzzles get solved by fixing one person's position arbitrarily, then placing every other clue relative to that fixed point rather than trying to hold the whole arrangement in your head at once. Draw the circle, number the seats, and place clues in the order that pins down the most people first, usually pairs described as "immediately to the left of" or "opposite," before working through the vaguer clues.

The actual answer depends on the specific clue set given, which varies between test forms. The technique, fix one anchor and build outward, is what's consistent across every version candidates report seeing.

Reading comprehension passages in this section are usually short, 150 to 250 words, and at least one question per passage asks for something implied rather than stated outright. The reliable approach is reading the questions before the passage so you know what to look for, then eliminating answer choices that are true in general but not actually supported by that specific passage, that's the most common wrong-answer trap in this format.

The trick in this one is the threshold, interest only applies to the portion of the principal above 1000, not the whole amount. Subtract 1000 first, floor it at zero so amounts under the threshold contribute nothing, then apply the rate.

def interest_above_threshold(principal, rate=0.20, threshold=1000):
  taxable = max(0, principal - threshold)
  return taxable * rate

This reads like a simple arithmetic problem, but it's really testing whether you read the requirement carefully. A candidate who applies the rate to the full principal gets a compiling, plausible-looking, wrong answer.

Track two running values, the largest seen so far and the second largest, and update both in a single pass depending on where the current element falls relative to each.

def second_largest(arr):
  first = second = float("-inf")
  for x in arr:
    if x > first:
      second = first
      first = x
    elif first > x > second:
      second = x
  return second

Sorting works and gets full marks in a screening test, but naming the O(n) single-pass version unprompted, and explaining why sorting is O(n log n) overkill for this specific question, is the kind of detail that separates candidates in the live technical round rather than the written one.

A hash set tracking characters already seen, checked while building the result in order, does this in one pass.

public static String removeDuplicates(String s) {
  Set<Character> seen = new HashSet<>();
  StringBuilder result = new StringBuilder();
  for (char c : s.toCharArray()) {
    if (seen.add(c)) {
      result.append(c);
    }
  }
  return result.toString();
}

Split on whitespace to get the individual words, then walk the resulting list from the end to the start while building the output, or reverse the list in place first and join it. The point of the "without a built-in reverse" constraint is checking whether you can do the two-pointer swap yourself.

def reverse_words(sentence):
  words = sentence.split()
  left, right = 0, len(words) - 1
  while left < right:
    words[left], words[right] = words[right], words[left]
    left += 1
    right -= 1
  return " ".join(words)

An abstract class can hold state, constructors, and a mix of implemented and abstract methods, but a class can only extend one. An interface historically held only method signatures (plus constants), and a class can implement as many interfaces as it needs. Modern Java has blurred this with default methods on interfaces, but the single-inheritance constraint on classes hasn't changed.

Reach for an abstract class when subclasses genuinely share common state or behavior you don't want to duplicate. Reach for an interface when you're defining a contract, "anything that implements Payable must expose a pay() method", without caring how wildly different the implementing classes are underneath.

Deep inheritance chains are the classic failure mode. Three or four levels deep, a change to a base class ripples unpredictably through every subclass, and a subclass that only needs part of its parent's behavior ends up either overriding methods to do nothing or inheriting behavior that doesn't make sense for it, the textbook Square-extends-Rectangle problem where Square has to override setWidth and setHeight in ways that violate what a caller expects a Rectangle to do.

Composition, giving a class a reference to another object and delegating to it, usually ages better than inheritance for exactly this reason. It's why "favor composition over inheritance" is a real, load-bearing piece of advice and not just a slogan.

A C++ destructor runs deterministically the moment an object goes out of scope or is explicitly deleted, so cleanup, closing a file handle, releasing a lock, happens at a known point in the program. Java's finalize() was meant to run before the garbage collector reclaims an object's memory, but the timing was never guaranteed, the GC might run it late or, in some cases, not at all before the JVM exits, which is exactly why it's deprecated as of Java 9 in favor of explicit try-with-resources and the AutoCloseable interface.

The core states are new, ready, running, waiting or blocked, and terminated. A process moves from new to ready once it's admitted by the scheduler. Ready to running happens when the scheduler dispatches it onto a CPU. Running to waiting happens when the process requests something it has to block on, disk I/O, a lock, user input. Waiting back to ready happens once that event completes. Running back to ready happens on a timer interrupt or a higher-priority process preempting it. Running to terminated happens when the process finishes or is killed.

Swapping moves an entire process out of main memory to disk and back, typically to free up RAM for a higher priority process, and it operates at the whole-process level. Paging breaks a process's memory into fixed-size pages and only moves individual pages between RAM and disk as needed, which is far more granular and is the actual mechanism behind virtual memory on almost every modern OS.

People sometimes conflate the two because both involve moving data to and from disk, but the unit of movement, a whole process versus a page, and the goal, freeing memory for scheduling versus supporting an address space larger than physical RAM, are different problems being solved.

Atomicity means a transaction happens completely or not at all, transferring money between two accounts either debits and credits both, or neither happens, never a partial state where money vanishes. Consistency means a transaction moves the database from one valid state to another, respecting every constraint, a foreign key, a check constraint, so a transfer can't leave a negative balance if that's disallowed. Isolation means concurrent transactions don't see each other's uncommitted changes, so two transfers happening at the same time don't interfere with each other's intermediate state. Durability means once a transaction commits, it survives a crash, the database has written it to persistent storage, not just kept it in memory.

A subquery approach avoids the common mistake of just sorting and taking the second row, which breaks the moment there are duplicate top salaries.

SELECT MAX(salary) AS second_highest
FROM Employee
WHERE salary < (SELECT MAX(salary) FROM Employee);

This handles duplicates correctly, since it's finding the highest value strictly less than the maximum, not relying on row position. The window function version with DENSE_RANK() is the more general answer if the interviewer asks for the Nth highest instead of just the second.

The JVM loads compiled.class bytecode through the class loader, verifies it doesn't violate memory safety or access rules, and then either interprets it directly or hands hot code paths to the Just-In-Time compiler, which compiles frequently executed bytecode down to native machine code at runtime for speed. Memory is managed across distinct regions, the heap for objects, the stack for method call frames and local variables, and metaspace (replacing the old permgen since Java 8) for class metadata, and garbage collection reclaims heap memory automatically instead of requiring manual free calls.

"Write once, run anywhere" is really just a description of the fact that the same bytecode runs on any platform with a compliant JVM. The actual interesting engineering is in the JIT and the garbage collector, not the portability claim itself.

Compile-time polymorphism is resolved by the compiler based on the arguments in the call itself, function overloading and templates are the two common forms. Runtime polymorphism is resolved based on the actual object's type at the moment the call happens, which in C++ requires virtual functions, since C++ doesn't dynamically dispatch by default the way Java does.

class Animal {
public:
  virtual void speak() { cout << "..."; }
};
class Dog : public Animal {
public:
  void speak() override { cout << "Woof"; }
};

Animal* a = new Dog();
a->speak(); // "Woof", resolved at runtime via the vtable

Interviewers report using this exact framing to gauge whether a candidate actually built what's written on the resume or just listed a technology they touched briefly. The strongest answers pick one specific, narrow decision, not "we built a microservices architecture," but "the message queue kept dropping events under load, and here's the specific change we made and why," and can defend the trade-off out loud if pushed on an alternative approach.

A weak answer here isn't usually wrong information, it's vagueness. Naming the actual constraint you were solving for, latency, cost, a specific bug, and the alternative you rejected and why, does more work in thirty seconds than a full architecture diagram would.

Split the 9 balls into three groups of 3. Weigh two of the groups against each other. If they balance, the heavier ball is in the third, untouched group. If one side is heavier, it's in that group. Either way, you now know which group of 3 contains the heavy ball, using only one weighing.

Take that group of 3, weigh any two of them against each other. If they balance, the third ball is the heavy one. If one side is heavier, that's the ball. Two weighings total, and the technique, splitting into thirds rather than halves, is the general pattern for this whole family of "find the odd one out with a balance scale" puzzles.

Vertical scaling means adding more resources, CPU, RAM, to a single machine. Horizontal scaling means adding more machines and distributing load across them. Vertical scaling has a hard ceiling, there's a biggest instance you can rent, and it usually requires downtime to resize. Horizontal scaling has no such practical ceiling and can often happen without downtime if the system is already built to run behind a load balancer.

For a sudden, temporary traffic spike, horizontal scaling with auto-scaling rules is almost always the right call, since it can react in minutes and scale back down once the spike passes, whereas resizing a single vertical instance usually means an interruption at exactly the moment you can least afford one.

Round-robin sends each new request to the next server in a fixed rotation, regardless of how busy any server currently is. It's simple and works fine when every server has roughly equal capacity and requests take roughly the same amount of time to process. Least-connections instead sends each new request to whichever server currently has the fewest active connections, which handles uneven request durations better, a server stuck processing a few slow requests won't keep getting piled on just because it's next in the rotation.

Round-robin is the right default for a fleet of identical servers handling short, uniform requests. Least-connections earns its extra bookkeeping cost once request duration varies a lot, long-running uploads mixed with quick API calls, where a naive rotation would let one server end up overloaded purely by bad luck.

This one is designed to see whether you're actually paying attention to what's different about the company, not just interviewing everywhere and taking whichever offer lands first. The honest, defensible answer names a real factor, project domain, the specific team or technology stack you'd be placed on, growth path, and doesn't pretend the other companies are worse across the board. Interviewers can tell the difference between a genuine preference and a rehearsed answer that would apply equally well to any of the four companies named in the question.

A concrete story beats a general principle every time here. Name the actual decision, why you disagreed, and specifically what you did, raised it privately, brought data, escalated it, or decided it wasn't worth the fight and moved on, and be honest about the outcome even if it wasn't a clean win. Interviewers are listening for whether you can disagree professionally without either staying silent out of conflict avoidance or becoming combative, both of which are common failure patterns they've clearly heard before.

The diamond problem shows up when a class inherits from two parent classes that both inherit from the same grandparent class. If both parents override a method from that grandparent differently, the compiler has no unambiguous way to decide which version the child class should get, both paths are equally valid. C++ allows multiple inheritance directly and resolves the ambiguity through virtual inheritance, which ensures only one shared copy of the grandparent's members exists instead of two conflicting ones. Java sidesteps the whole problem by disallowing multiple inheritance of classes entirely, a class can only extend one parent, though it can implement multiple interfaces, and Java 8's default methods handle the equivalent ambiguity by forcing the implementing class to explicitly override a method if two interfaces both provide a default for it.

Normalization organizes tables to eliminate redundant data and dependency anomalies, splitting data into related tables and enforcing relationships through foreign keys instead of repeating the same values across rows. Third normal form, no non-key column depending on another non-key column, is the practical target most schemas aim for.

Yes, over-normalizing hurts real performance. A query that needs data spread across six normalized tables requires six joins to reassemble it, and each join costs real query planning and execution time at scale. That's exactly why reporting and analytics systems deliberately denormalize, pre-joining or duplicating data into wider tables, trading some redundancy for read speed, because those systems are read-heavy and don't carry the same write-consistency risk that justifies normalization in a transactional system.

An index is a separate, ordered data structure, usually a B-tree, built on one or more columns that lets the database find matching rows without scanning the entire table row by row. A query filtering or sorting on an indexed column can jump almost directly to the relevant rows instead of a full table scan, which matters enormously once a table has millions of rows.

The cost is real and often glossed over in interviews: every index has to be updated on every insert, update, and delete to that column, so a table with heavy write traffic and five indexes pays that maintenance cost five times per write. Indexes also consume disk space of their own. The right call is indexing columns that are actually filtered or joined on frequently, not indexing every column defensively, which is a mistake candidates who've only used indexes in a tutorial context tend to make.

RequestDispatcher.forward() happens entirely on the server, the original request and response objects are handed to another resource, the browser's URL bar never changes, and any request attributes you set are still available to the target resource. sendRedirect() sends an HTTP 302 back to the browser telling it to make a brand new request to a different URL, so the browser's address bar updates and the original request object, along with anything you attached to it, is gone.

The practical rule: forward when you're staying within the same logical request, handing off to a JSP to render a response. Redirect when you genuinely want the client to land on a new, bookmarkable URL, the classic post-form-submission redirect to avoid a duplicate submission on page refresh.

The container loads the servlet class, instantiates it once, and calls init() a single time before the servlet handles any request. Every incoming request is then handled by calling service() on that same shared instance, which dispatches to doGet() or doPost() depending on the HTTP method, meaning a single servlet instance typically serves many concurrent requests on separate threads. destroy() is called once, when the container shuts the servlet down, giving it a chance to release resources.

The detail that trips candidates up is that one instance handles many requests concurrently, so any mutable instance field on a servlet is a shared, thread-unsafe piece of state unless you deliberately synchronize access to it. Storing per-request data as an instance field instead of a local variable is a real, recurring bug in production Java web apps.

The contract between the two methods requires that equal objects produce equal hash codes. If you override equals() to compare by value but leave the default Object.hashCode(), which is based on identity, two logically equal objects will hash to different buckets, and a HashMap will fail to find an existing key even though equals() would say it matches. The lookup silently behaves as if the key were never inserted.

class Point {
  int x, y;
  Point(int x, int y) { this.x = x; this.y = y; }

  @Override
  public boolean equals(Object o) {
    if (!(o instanceof Point)) return false;
    Point p = (Point) o;
    return this.x == p.x && this.y == p.y;
  }
  // missing hashCode() override here breaks HashMap/HashSet usage
}

An object becomes eligible for garbage collection once nothing in the live object graph, starting from GC roots like local variables, static fields, and active thread stacks, holds a reference to it anymore. The collector doesn't run on a fixed schedule tied to when an object goes out of scope, it runs when the JVM decides memory pressure warrants it, which is why relying on finalize() for deterministic cleanup timing never worked reliably.

The classic way to accidentally prevent collection is an unintended long-lived reference, a static collection that keeps growing and never removes old entries, or a listener registered on a long-lived object that never gets unregistered. Both keep the referenced objects reachable from a GC root indefinitely, which is a memory leak in a garbage-collected language, something a lot of candidates assume can't happen in Java until they've actually debugged one.

CAP theorem says a distributed data system can only guarantee two of consistency, availability, and partition tolerance at the same time, and since real networks do experience partitions, the practical choice is between consistency and availability whenever a partition actually occurs. Cassandra is tunable per query, but by default it's built to favor availability and partition tolerance, AP, accepting eventual rather than immediate consistency across replicas, which is a deliberate trade-off for systems that need to stay up and responsive even when part of the cluster can't currently talk to the rest.

Microservices buy you independent deployability, per-service scaling, and the ability to let different teams own different services without stepping on each other's release cadence. What they cost you is real: network calls where you used to have a function call, meaning new failure modes, timeouts, partial failures, distributed tracing you now need just to debug a single user request. Data consistency across services requires patterns like sagas instead of a single database transaction, which is genuinely harder to reason about correctly.

A monolith is often the right answer for a small team or an early-stage product, not a compromise, a deliberate choice, because you get transactional consistency, one deployment pipeline, and no network hop between components for free. Plenty of companies that eventually split into microservices did so because a specific, measured scaling or team-ownership problem showed up, not because microservices are categorically better.