Mphasis Interview Questions (2026): Real, With Answers

Candidate reports describe four sections: quantitative aptitude, logical reasoning, verbal ability, and a programming or computer fundamentals section. The programming section is usually the smallest of the four and leans on output-prediction and basic logic rather than open-ended algorithm design, closer to a screening filter than a coding contest.

The practical implication is that a candidate who's rusty on ratios, percentages, and basic reasoning puzzles can fail the test before a recruiter ever looks at their coding ability. Treat the aptitude sections as seriously as the programming one, they carry equal or greater weight in most reports.

Reports point to standard reasoning formats: seating arrangements (linear and circular), syllogisms, blood relations, coded inequalities, and data sufficiency. None of it is Mphasis-specific; it's the same bank of question types used across most Indian IT services assessments run through vendors like AMCAT or a similar platform.

The efficient prep path is timed practice sets rather than memorizing question types in isolation. Most candidates who clear this section report doing 30 to 60 minutes of timed reasoning drills in the week before the test, not deep conceptual study.

Candidate reports are mixed on this, some describe a small negative marking penalty on the aptitude sections, others don't mention one at all, which suggests it may vary by hiring cycle or campus drive rather than being a fixed policy. The safer assumption going in is that guessing carries some risk, so skip questions you're genuinely unsure about rather than blind-guessing across the board.

Walk the array once, comparing each element to the one before it. If any element is smaller than its predecessor, the array isn't sorted, and you can return immediately without scanning the rest.

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

The single-pass, early-exit shape is the whole point of the question. A candidate who writes a full sort first and then compares against the original array technically gets a correct answer, but it signals they didn't reach for the simplest tool available.

Two pointers, one at each end of the string, moving inward and comparing characters. As soon as a mismatch appears, the string isn't a palindrome. This runs in O(1) extra space since it only needs two index variables, no reversed copy of the string.

bool isPalindrome(string s) {
  int left = 0, right = s.length() - 1;
  while (left < right) {
    if (s[left] != s[right]) return false;
    left++;
    right--;
  }
  return true;
}

A stable sort preserves the relative order of elements that compare equal. If two records have the same sort key, a stable sort guarantees they stay in their original relative order after sorting; an unstable one makes no such promise.

Merge sort and insertion sort are stable. Quicksort and heapsort, in their typical implementations, are not. This matters in practice whenever you're sorting by one key but want a secondary, already-established order preserved, sorting a list of orders by date after they were already sorted by customer name, for instance.

Track the highest and second-highest values in a single pass. Whenever a new element beats the current highest, the old highest becomes the new second-highest before the highest gets updated.

int secondHighest(int arr[], int n) {
  int first = INT_MIN, second = INT_MIN;
  for (int i = 0; i < n; i++) {
    if (arr[i] > first) {
      second = first;
      first = arr[i];
    } else if (arr[i] > second && arr[i] != first) {
      second = arr[i];
    }
  }
  return second;
}

The common bug here is not guarding against duplicates of the maximum value inflating the second-highest incorrectly. Interviewers usually push on that case specifically once the basic version works.

extern declares that a variable or function is defined somewhere else, in a different translation unit, without allocating storage for it at the point of declaration. It lets multiple.c files share a single global variable: one file defines it normally, every other file that needs it declares it with extern so the linker resolves all references to the same storage location.

// file1.c
int counter = 0; // definition, allocates storage

// file2.c
extern int counter; // declaration, refers to file1.c's counter
void increment() { counter++; }

Bubble sort or selection sort, both O(n squared), are what most candidates reach for and what interviewers actually expect here, this question is testing whether you can write correct nested-loop logic under pressure, not whether you know an O(n log n) algorithm by heart.

void selectionSort(int arr[], int n) {
  for (int i = 0; i < n - 1; i++) {
    int minIdx = i;
    for (int j = i + 1; j < n; j++) {
      if (arr[j] < arr[minIdx]) minIdx = j;
    }
    swap(arr[i], arr[minIdx]);
  }
}

Primitive types (int, char, float, double, bool) are built into the language, occupy a fixed, known size, and hold a single value directly. Non-primitive types (arrays, structures, classes, pointers) are built from primitives or other non-primitive types and typically hold multiple values or references to other data.

== compares references for objects, whether two variables point to the exact same object in memory, not whether the objects hold equal values..equals() compares content, but only if the class has actually overridden it; without an override, Object's default.equals() falls back to reference comparison too, the same behavior as ==.

String a = new String("hi");
String b = new String("hi");

System.out.println(a == b);   // false, different objects
System.out.println(a.equals(b)); // true, same content

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

An index is a separate data structure, usually a B-tree, that lets the database look up rows matching a condition without scanning the entire table. It speeds up reads dramatically for the columns it covers, at the cost of extra storage and slower writes, every insert, update, or delete now has to also update every index touching that row.

Indexing every column sounds appealing until you notice write-heavy tables slow down noticeably, and most of those indexes never actually get used by the query planner because the columns aren't in WHERE clauses or JOIN conditions often enough to justify the overhead.

IaaS gives you raw compute, storage, and networking, you manage the operating system and everything above it, AWS EC2 is the standard example. PaaS gives you a managed runtime, you deploy code and the platform handles the OS, patching, and scaling, Heroku or AWS Elastic Beanstalk fit here. SaaS gives you a finished application over the internet, you don't manage any infrastructure at all, Google Workspace or Salesforce are typical examples.

The pattern across all three: each layer up trades control for less operational burden. IaaS gives maximum flexibility and maximum responsibility, SaaS gives minimum flexibility and minimum responsibility.

IPv6 operates at the network layer (layer 3), the same layer as IPv4. The core problem it solves is address exhaustion: IPv4's 32-bit address space caps out at roughly 4.3 billion unique addresses, which the internet has already effectively run out of given how many connected devices exist today. IPv6 uses 128-bit addresses, expanding the available address space enormously, along with built-in improvements to header structure and multicast handling.

Functional testing verifies that a system does what it's supposed to do, whether a specific feature or business requirement behaves correctly given a certain input. Non-functional testing verifies how well the system does it, performance under load, security against attack, usability, reliability over time, none of which is captured by "does the login form work with valid credentials."

In an Agile setup, testing happens within the same short iteration (sprint) as development, rather than as a separate phase after the whole feature set is built. That means test cases get written against a feature while it's still being coded, defects surface and get fixed within days rather than weeks, and the test suite grows incrementally sprint over sprint instead of arriving as one large effort at the end of a long release cycle.

Keep it to your relevant technical background, one or two concrete projects that connect to the role you're interviewing for, and why you're interested in this specific opportunity, not a full life story. Interviewers running back-to-back HR rounds are listening for whether you can summarize your own experience clearly and briefly, that's the actual skill being tested here, not the content of the answer itself.

This exact problem shows up in multiple candidate reports for the coding section. The string framing matters, it means you're iterating characters and converting each one back to a digit, not doing repeated modulo-and-divide on an integer.

#include <stdio.h>
#include <string.h>

int sumOfDigits(char *s) {
  int sum = 0;
  for (int i = 0; i < strlen(s); i++) {
    if (s[i] >= '0' && s[i] <= '9') {
      sum += s[i] - '0';
    }
  }
  return sum;
}

int main() {
  char input[100];
  scanf("%s", input);
  printf("%dn", sumOfDigits(input));
  return 0;
}

Watch for the edge cases interviewers actually probe here: a leading sign character, embedded whitespace, or a string that isn't purely numeric. Handling those cleanly is usually worth more than the core loop itself.

The iterative version tracks three pointers, previous, current, and next, and rewires one link per step. The recursive version reverses everything after the head first, then fixes up the current node's link on the way back up the call stack.

struct Node {
  int data;
  Node* next;
};

Node* reverseIterative(Node* head) {
  Node* prev = nullptr;
  Node* curr = head;
  while (curr != nullptr) {
    Node* next = curr->next;
    curr->next = prev;
    prev = curr;
    curr = next;
  }
  return prev;
}

Node* reverseRecursive(Node* head) {
  if (head == nullptr || head->next == nullptr) return head;
  Node* newHead = reverseRecursive(head->next);
  head->next->next = head;
  head->next = nullptr;
  return newHead;
}

The follow-up worth being ready for: what's the space complexity difference. Iterative is O(1) extra space, recursive is O(n) from the call stack, and that distinction is exactly what interviewers are checking when they ask for both versions instead of just one.

Floyd's cycle detection, two pointers moving at different speeds, is the standard answer. If a slow pointer and a fast pointer ever meet, there's a cycle. Finding the start point takes one more step: reset one pointer to the head and advance both at the same speed until they meet again, that meeting point is the cycle's start.

Node* detectCycleStart(Node* head) {
  Node* slow = head;
  Node* fast = head;

  while (fast && fast->next) {
    slow = slow->next;
    fast = fast->next->next;
    if (slow == fast) {
      Node* ptr = head;
      while (ptr != slow) {
        ptr = ptr->next;
        slow = slow->next;
      }
      return ptr;
    }
  }
  return nullptr;
}

Dijkstra's is greedy. At every step it picks the unvisited node with the smallest known distance and finalizes it, never revisiting that decision. That greedy choice works because it operates only on graphs with non-negative edge weights, once a node's shortest distance is finalized under that constraint, no later path through an unvisited node can improve it.

It shares some DP flavor in that it builds on previously solved subproblems (shortest distances to already-visited nodes), but it doesn't explore multiple overlapping subproblems the way a true DP algorithm like Bellman-Ford does, which is why it's classified as greedy rather than DP.

Bellman-Ford correctly handles negative edge weights and can detect negative-weight cycles, both of which break Dijkstra's greedy assumption. It relaxes every edge up to V-1 times (where V is the number of vertices), and a further relaxation that still finds a shorter path on the Vth pass means a negative cycle exists.

The tradeoff is complexity: Bellman-Ford runs in O(V*E) versus Dijkstra's O((V+E) log V) with a priority queue. You reach for Bellman-Ford specifically when the graph might contain negative weights, currency arbitrage detection is the classic real-world example, not as a general-purpose replacement for Dijkstra's.

C and C++ store 2D arrays in row-major order, meaning an entire row is laid out contiguously before the next row begins. Accessing arr[i][j] compiles down to base + (i * numCols + j) * elementSize. FORTRAN, by contrast, uses column-major order.

It matters for performance because iterating row-by-row (outer loop over rows, inner loop over columns) touches memory sequentially and plays well with CPU cache lines. Iterating column-by-column on a row-major array jumps across memory on every access, and on a large matrix that difference in cache behavior can be a measurable slowdown even though both loops do the same number of operations.

Encapsulation is a compile-time construct, access specifiers control which code can touch a member, there's no runtime enforcement once compiled. Inheritance lays out a derived class's memory as the base class's members followed by the derived class's own members, so a derived object can always be treated as a base object by pointer or reference without conversion.

Polymorphism is where the interesting mechanics live. Virtual functions are implemented through a vtable, a hidden array of function pointers that each polymorphic object carries a pointer to. A call through a base class pointer looks up the actual function to run in the vtable at runtime, that indirection is what lets the same call site invoke different overridden implementations depending on the object's real type.

A virtual function has a default implementation in the base class that derived classes can optionally override. A pure virtual function, declared with = 0, has no implementation in the base class at all and forces every concrete derived class to provide one; a class containing even a single pure virtual function becomes abstract and can't be instantiated directly.

class Shape {
public:
  virtual double area() = 0; // pure virtual, makes Shape abstract
  virtual void describe() { cout << "A shape" << endl; } // virtual, has a default
};

A structure allocates separate memory for each member, so the total size is roughly the sum of all members' sizes (plus padding). A union allocates a single block of memory sized to fit its largest member, and all members share that same memory, writing one member overwrites whatever was stored in any other.

Unions show up in real code when memory is tight and only one of several possible interpretations of a value is needed at a time, a variant type in an embedded system, or the low-level implementation of a tagged union pattern where a separate enum field tracks which member is currently valid.

A marker interface has no methods or fields at all, its only purpose is to tag a class so that runtime code (usually via reflection or instanceof checks) can treat it differently. Serializable and Cloneable are the two standard-library examples that come up most often. Implementing Serializable, for instance, doesn't add any behavior directly, it signals to the JVM's serialization machinery that instances of the class are allowed to be serialized.

Static blocks run exactly once, the first time the class is loaded by the JVM, before any constructor runs, even before the first object of that class is created. If you create multiple instances, the static block still only fires once, but the constructor runs every time.

class Demo {
  static {
    System.out.println("static block");
  }
  Demo() {
    System.out.println("constructor");
  }
}

public class Main {
  public static void main(String[] args) {
    new Demo();
    new Demo();
  }
}
// Output:
// static block
// constructor
// constructor

HashMap stores key-value pairs. HashSet stores unique values only, and internally it's backed by a HashMap where every element you add becomes a key mapped to a single shared dummy constant object, that's the entire implementation trick, HashSet is essentially a thin wrapper around HashMap's key set.

Checked exceptions extend Exception (but not RuntimeException) and the compiler forces you to either catch them or declare them in a method's throws clause, IOException is the classic example. Unchecked exceptions extend RuntimeException, NullPointerException or ArrayIndexOutOfBoundsException, and the compiler doesn't require you to handle them at all, they typically signal programming bugs rather than recoverable external conditions.

The practical distinction: checked exceptions are meant for things a caller can reasonably be expected to plan for and recover from, a file not existing, a network call failing. Unchecked exceptions are meant for things that indicate a bug, and forcing every caller to catch them everywhere would just clutter code without adding real safety.

This exact prompt shows up repeatedly in candidate reports. DENSE_RANK handles duplicate salary values correctly, ranking equal salaries the same and not skipping the next rank number, which plain LIMIT or TOP wouldn't do if multiple employees share the 5th highest salary.

SELECT salary FROM (
  SELECT DISTINCT salary,
      DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
  FROM employees
) ranked
WHERE rnk <= 5;

If the interviewer specifically wants exactly 5 rows regardless of ties, a simple SELECT DISTINCT salary FROM employees ORDER BY salary DESC LIMIT 5 is the more direct answer, but the DENSE_RANK version is the one that correctly answers "top 5 distinct salary levels" when duplicates exist.

An entity is a single, specific real-world object, one particular employee row. An entity type is the category or template that describes a class of entities and their attributes, the Employee table's schema itself. An entity set is the actual collection of all entities of a given type that currently exist in the database, all the rows currently in the Employee table at a given moment.

A checkpoint is a point in time where the database writes all its in-memory, modified (dirty) pages to disk and records that this happened in the transaction log. It exists to bound recovery time after a crash, without checkpoints, recovery would have to replay every transaction since the database started; with them, recovery only needs to replay transactions since the most recent checkpoint.

Atomicity means a transaction either fully completes or has no effect at all. Consistency means a transaction moves the database from one valid state to another, respecting all constraints. Isolation means concurrent transactions don't see each other's uncommitted intermediate state. Durability means once committed, a transaction's changes survive a crash.

A concrete isolation violation: two concurrent transactions both read an account balance of 1000, both add 100, and both write back 1100, when the correct final balance after two separate additions should be 1200. Proper isolation, using row-level locking or an appropriate isolation level, prevents the second transaction from reading the balance until the first one's write has committed.

DataReader is a forward-only, read-only stream that pulls one row at a time directly from the database connection, staying connected the whole time. It's fast and lightweight for scenarios where you just need to read through results once, top to bottom, without going back.

DataSet loads the entire result into an in-memory, disconnected representation that you can navigate in any order, modify, and even reconnect later to push changes back. It costs more memory and is slower to populate, but it's the right choice when you need to work with data offline from the connection, cache it, or bind it to multiple UI controls that each need independent access to the same rows.

Scalability is the capacity of a system to handle increased load by adding resources, and it can be planned and manual, provisioning bigger servers ahead of an expected traffic spike. Elasticity is scalability that happens automatically and dynamically in response to real-time demand, resources get added when load rises and removed again when it drops, without a human intervening each time.

A system can be scalable without being elastic, you can manually resize a server to handle more load, that's scaling, but if it doesn't shrink back down automatically once load drops, it isn't elastic.

A Virtual Private Cloud is an isolated, logically separated network within a cloud provider's infrastructure, where you control the IP address range, subnets, route tables, and security groups. It matters because it lets you keep resources like databases off the public internet entirely, reachable only from within the VPC or through a controlled gateway, which meaningfully reduces the attack surface compared to giving every resource a public IP by default.

A load balancer distributes incoming traffic across multiple existing servers so no single server gets overwhelmed. Auto-scaling changes how many servers exist in the first place, based on load metrics like CPU usage or request count. They work together: auto-scaling adds or removes instances behind the load balancer, and the load balancer keeps spreading traffic evenly across whatever set of instances currently exists, including newly added ones.

TCP is connection-oriented, it establishes a handshake, guarantees ordered delivery, and retransmits lost packets, at the cost of overhead and latency. UDP is connectionless, it fires packets with no delivery guarantee and no ordering, but with far less overhead.

A resource-constrained IoT device sending frequent small sensor readings often prefers a lightweight protocol like CoAP or MQTT, both of which are typically built on top of UDP or a lightweight TCP variant, because retransmitting every dropped temperature reading matters far less than conserving battery and bandwidth. A firmware update pushed to that same device, by contrast, needs the reliability guarantees of TCP, a corrupted or incomplete firmware image is a much bigger problem than a corrupted sensor reading.

Backend testing covers the entire server-side logic, application servers, APIs, business rule enforcement, not just the database. Database testing narrows specifically to the data layer, schema integrity, data validity, stored procedure correctness, and whether queries return accurate results against the expected schema.

They overlap heavily in practice because most backend bugs eventually trace back to a database issue, a query returning stale data, a missing constraint letting invalid data in, but database testing is the more specialized subset focused purely on data correctness rather than the full request-response cycle.

Regression testing re-runs previously passing test cases after a code change to confirm nothing that used to work has broken. It's the textbook case for automation because the same tests run repeatedly, unchanged, release after release, exactly the kind of repetitive work automation pays off on fastest.

Manual regression still makes sense for exploratory areas where the UI or workflow changed enough that an automated script written against the old version would need rewriting anyway, in that situation, automating first and testing manually second is often faster than automating a test suite that's about to be obsolete.

An implicit wait applies globally to the entire driver session, telling it to poll for an element for up to a set timeout before throwing a not-found error, on every single element lookup in the script. An explicit wait applies to one specific condition at one specific point in the script, wait until this particular element becomes clickable, for instance, and it's the more precise, recommended tool because it avoids padding every single lookup with a wait that most of them don't need.

The weak answer talks about the company in generic terms, brand name, stability, growth. The stronger answer connects something specific, the kind of client work, the technology stack, the team or business unit you'd be joining, to something concrete in your own background or goals. If you genuinely don't know much about the specific unit you're interviewing for, say so honestly and ask a clarifying question rather than reciting a generic paragraph you'd give any employer.

Give one specific, real example rather than a general philosophy. Walk through the actual situation, what made the deadline tight, what you personally did (not what "the team" did), and what the outcome was. An interviewer who's heard the generic "I stay calm and prioritize" answer a hundred times is listening for the specific decision you made under pressure, that's the differentiator.

Focus the story on what you did to resolve it, not on cataloguing what was wrong with the other person. A story that ends with "and eventually we found a way to split the work that played to both our strengths" lands better than one that ends with "and I was right and they were wrong," even if that's genuinely how it played out. The question is testing collaboration instinct, not who was at fault.

This is the circular-arrangement elimination problem, essentially the Josephus problem, that shows up in reports of the coding round. The clean approach uses a circular data structure, a queue where you rotate and pop, or a linked list, rather than repeatedly recomputing indices with modulo arithmetic on a static array.

#include <queue>
using namespace std;

int lastPersonStanding(int n, int k) {
  queue<int> q;
  for (int i = 1; i <= n; i++) q.push(i);

  while (q.size() > 1) {
    for (int i = 1; i < k; i++) {
      q.push(q.front());
      q.pop();
    }
    q.pop(); // eliminate the kth person
  }
  return q.front();
}

If you know the closed-form recurrence for the Josephus problem, mentioning it as an O(n) alternative to the O(n*k) simulation is a strong signal, but the simulation is the answer most interviewers actually expect a candidate to produce on a whiteboard.

The compiler generates a default copy constructor that does a shallow, member-by-member copy. For a raw pointer member, that copies the pointer's address, not the data it points to, so two objects end up pointing at the same heap allocation. When both objects go out of scope, both destructors try to free the same memory, which causes a double-free and undefined behavior, or one object frees the memory while the other still references it, a classic dangling-pointer bug.

class Buffer {
  int* data;
public:
  Buffer(int size) { data = new int[size]; }
  ~Buffer() { delete[] data; } // double-free risk without a proper copy constructor
  // Missing: Buffer(const Buffer& other) { data = new int[...]; copy contents; }
};

The fix is the rule of three (or rule of five in modern C++): if a class needs a custom destructor, it almost certainly needs a custom copy constructor and copy assignment operator too, doing a deep copy of whatever the pointer owns.

A singleton restricts a class to exactly one instance for the lifetime of the application, typically used for a shared resource like a configuration manager or connection pool. The naive implementation with a plain if-null-then-create check breaks under concurrent access, two threads can both pass the null check before either finishes constructing the instance.

public class ConfigManager {
  private static volatile ConfigManager instance;

  private ConfigManager() {}

  public static ConfigManager getInstance() {
    if (instance == null) {
      synchronized (ConfigManager.class) {
        if (instance == null) {
          instance = new ConfigManager();
        }
      }
    }
    return instance;
  }
}

This is the double-checked locking pattern, the volatile keyword is not optional here, without it a thread could observe a partially-constructed object due to instruction reordering. The alternative that sidesteps the whole problem is an enum-based singleton, which the JVM guarantees is thread-safe and instantiated exactly once by design.

This question is looking for judgment under genuine ambiguity, not just a hard technical problem you eventually solved. A strong answer describes a situation with a real tradeoff, no clean right answer, competing priorities, incomplete information, walks through how you weighed the options, and is honest about the outcome even if it wasn't perfect. Candidates who pick a "tough decision" that was actually straightforward once you look closely tend to undersell themselves here; pick the one that genuinely kept you up at night.