Birlasoft Interview Questions (2026): Real, With Answers

There's no trick here beyond staying calm. The assessment is checking whether you can process spoken or written information and reproduce it clearly, which maps to whether you'll be understandable on a client call at 9pm US time with a director on the line. Read at a normal pace, don't rush to sound confident, and paraphrase rather than trying to recite the passage back word for word, since the system is listening for comprehension, not memory.

These are usually short sentences, five to eight words, testing basic subject-verb-object ordering and common prepositional phrases. The failure mode candidates report isn't grammar knowledge, it's nerves under a timer with a microphone recording them. Practice saying full sentences out loud before the call rather than only reading silently, since the muscle you need is verbal, not written.

Common patterns tested are subject-verb agreement across a long clause, misused tenses when describing past project work, and article errors (a versus an versus no article). Since this round often overlaps with how you'll describe your own resume later in the loop, it helps to actually practice narrating your last project out loud in a few tenses beforehand rather than treating this as a disconnected grammar quiz.

Atomicity means a transaction is all-or-nothing, if any step fails the whole thing rolls back, so you never end up with half a transfer applied. Consistency means the database moves from one valid state to another, respecting constraints and triggers, never leaving data that violates a rule the schema is supposed to enforce. Isolation means concurrent transactions don't see each other's uncommitted changes, which is what stops two people from double-booking the same seat. Durability means once a transaction commits, it survives a crash, typically through a write-ahead log that gets replayed on restart.

The property that trips candidates up most is isolation, because most people can recite the definition but can't explain what happens without it. A concrete example: two transactions both read a bank balance of 100, both add 50, both write back 150. Without proper isolation the correct answer of 200 never gets written, and that's the whole reason isolation levels like READ COMMITTED and SERIALIZABLE exist.

An inner join returns only the rows where the join condition matches in both tables, dropping anything that doesn't have a corresponding row on the other side. Given an Employees table and a Departments table joined on department_id, an inner join returns every employee who has a valid, matching department, and silently excludes any employee whose department_id doesn't exist in Departments.

SELECT e.name, d.department_name
FROM Employees e
INNER JOIN Departments d
 ON e.department_id = d.department_id;

Compare that to a left join on the same tables, which keeps every employee row regardless of match and fills department_name with NULL when there's no corresponding department. Interviewers ask this specific pair because it's the fastest way to check whether you actually understand set behavior or just memorized the syntax.

A process has its own isolated memory space, file handles, and address space, so one process crashing generally doesn't take down another. A thread lives inside a process and shares that process's memory and resources with every other thread in it, which makes threads cheaper to create and switch between, but also means a bug in one thread, a bad pointer, a race condition, can corrupt data another thread in the same process is relying on.

The practical consequence people miss: because threads share memory, you need synchronization primitives, locks, semaphores, mutexes, to coordinate access to shared state safely. Processes don't have that problem by default because they can't see each other's memory at all, though that isolation is exactly why inter-process communication (pipes, sockets, shared memory segments) is more expensive to set up than just spawning a thread.

Encapsulation bundles data and the methods that operate on it together, hiding internal state behind a public interface so callers can't reach in and corrupt fields directly. Abstraction exposes only the relevant behavior and hides implementation detail, so a caller can use a Stack without knowing whether it's backed by an array or a linked list underneath. Inheritance lets a class reuse and extend behavior from a parent class instead of duplicating it. Polymorphism lets the same method call behave differently depending on the actual runtime type of the object it's called on.

abstract class Shape {
 abstract double area();
}
class Circle extends Shape {
 double radius;
 Circle(double r) { radius = r; }
 double area() { return Math.PI * radius * radius; }
}
class Square extends Shape {
 double side;
 Square(double s) { side = s; }
 double area() { return side * side; }
}
// same area() call, different behavior per subclass, that's polymorphism

Overloading happens within the same class, multiple methods share a name but differ in parameter type, count, or order, and the compiler picks the right one at compile time based on the arguments you pass. Overriding happens across a parent and child class, the child provides its own implementation of a method the parent already declared, and which version runs is decided at runtime based on the actual object type, not the reference type it's called through.

The interview follow-up worth being ready for: overloading is resolved statically (compile-time, sometimes called early binding), overriding is resolved dynamically (runtime, late binding, via the virtual method table in languages like Java and C#). That distinction is why you can't achieve polymorphism through overloading alone, you need overriding.

A primary key uniquely identifies each row in a table, can't be null, and a table can have only one. A unique key also enforces uniqueness across a column or column set, but unlike a primary key it can allow a single null value (depending on the database), and a table can have multiple unique keys. A foreign key doesn't enforce uniqueness at all, it enforces referential integrity, requiring that a value in one table actually exists as a key in another table it references.

CREATE TABLE Orders (
 order_id INT PRIMARY KEY,
 order_number VARCHAR(20) UNIQUE,
 customer_id INT,
 FOREIGN KEY (customer_id) REFERENCES Customers(customer_id)
);

The straightforward approach builds a new string by iterating through the input once and skipping any character that matches a vowel, uppercase or lowercase.

public static String removeVowels(String s) {
 StringBuilder sb = new StringBuilder();
 String vowels = "aeiouAEIOU";
 for (char c : s.toCharArray()) {
  if (vowels.indexOf(c) == -1) {
   sb.append(c);
  }
 }
 return sb.toString();
}

This runs in O(n) time and O(n) space for the output string. The follow-up worth anticipating: do it in-place if the language allows mutable strings, or handle a StringBuilder to avoid the O(n^2) cost of repeated string concatenation, which is a common junior-level mistake in Java where strings are immutable.

The cleanest solution uses a set to drop duplicates, since a set enforces uniqueness by definition, then sorts the resulting collection.

public static int[] dedupAndSort(int[] arr) {
 TreeSet<Integer> set = new TreeSet<>();
 for (int n : arr) set.add(n);
 int[] result = new int[set.size()];
 int i = 0;
 for (int n : set) result[i++] = n;
 return result;
}

Using a TreeSet does both steps at once, since it maintains sorted order automatically, which is worth pointing out to the interviewer rather than sorting first and then deduplicating adjacent equal elements as a separate pass. Either approach is O(n log n), dominated by the sort, but showing you know the TreeSet shortcut signals familiarity with the standard library rather than reimplementing everything from scratch.

Two pointers, one starting at the front and one at the back, moving toward each other and comparing characters at each step, is the expected solution.

public static boolean isPalindrome(String s) {
 int left = 0, right = s.length() - 1;
 while (left < right) {
  if (s.charAt(left) != s.charAt(right)) return false;
  left++;
  right--;
 }
 return true;
}

O(n) time, O(1) extra space, no need to build a reversed copy of the string. If the interviewer adds "ignore case and punctuation" as a follow-up, filter and lowercase the string first, or skip non-alphanumeric characters inside the same loop rather than pre-processing separately.

A stack is last-in-first-out, the most recently added element is the first one removed. A queue is first-in-first-out, elements come out in the same order they went in. A call stack is the canonical stack example, when a function returns, control goes back to whoever called it most recently, not the oldest pending caller.

A message queue processing background jobs, sending emails, generating reports, is the canonical queue use case in a backend system: jobs should generally get processed in the order they were submitted, so the first job queued is the first one a worker picks up, which is exactly FIFO behavior.

The safe, honest answer is that the first thirty days are mostly about understanding the existing landscape before touching anything, reading available documentation, going through the current codebase or configuration, and identifying who the actual subject matter experts are on the team for each area, rather than assuming your prior experience at a different client transfers directly.

A stronger answer names a specific first concrete action rather than staying purely abstract, something like shadowing an existing support ticket end to end to understand the team's actual workflow and tooling, or reviewing the last three months of production incidents to understand where the system's actual pain points have been. Interviewers are checking that you won't show up assuming your previous client's setup maps directly onto this one.

This question comes up more at Birlasoft's entry-level and campus interviews than at most Western companies would ask, and it's largely a rapport-building, get-comfortable question rather than a screening filter. Keep it brief and factual, who's in your family and roughly what they do, and move the conversation forward rather than treating it as a trick question with a hidden right answer.

The interviewer is checking for realistic alignment, not ambition for its own sake. An answer that says you plan to deepen expertise in the specific technology or module you're being hired for, and take on more ownership within that area over time, reads as more credible than a vague "grow professionally" answer or one that jumps straight to management ambitions in a technical individual contributor interview.

A generic "great culture and growth opportunities" answer is instantly forgettable, and interviewers hear it dozens of times a week. A better answer references something concrete, the specific client industries Birlasoft works with (manufacturing, BFSI, life sciences), the technology stack you'd actually be working in, or the specific role and project you're interviewing for, tied back to what you're looking for in your next move.

Skipping this or asking only about salary and leave policy reads as disengaged. A question about the actual project or client you'd be staffed on, how the team currently handles code reviews or production support rotation, or what a typical first project assignment looks like for someone joining at your level, signals you're actually thinking about the day-to-day work rather than just the offer letter.

Virtual memory gives every process the illusion of a large, contiguous, private address space, even when physical RAM is smaller and shared across many processes. The OS maps virtual addresses to physical ones through page tables, and pages that aren't currently needed can be swapped out to disk, which lets the system run more processes than would physically fit in RAM at once.

It also solves a security and stability problem beyond capacity: since each process's virtual address space is isolated, one process can't accidentally read or corrupt another process's memory, because the addresses it sees don't correspond to real physical locations without going through the OS's mapping. The tradeoff is a page fault, when a needed page isn't in RAM and has to be pulled back from disk, which is orders of magnitude slower than a normal memory access and is the reason thrashing (excessive paging) tanks performance under memory pressure.

The seven layers, from bottom to top, are physical (raw bits over a medium), data link (framing and MAC addressing on a local segment), network (routing and IP addressing across networks), transport (TCP/UDP, reliable delivery and port numbers), session (managing a connection's lifecycle), presentation (encoding, encryption, compression), and application (the protocol your software actually speaks, HTTP, FTP, DNS).

What actually gets asked in a follow-up: where does a router operate versus a switch. A switch works at layer 2, forwarding frames based on MAC address within a local network. A router works at layer 3, forwarding packets based on IP address across different networks. Getting that distinction right, and being able to place TCP at layer 4 without hesitating, is usually enough to clear this question.

TCP is connection-oriented and guarantees ordered, reliable delivery through acknowledgments and retransmission, at the cost of overhead and latency from the three-way handshake and flow control. UDP is connectionless, sends packets without any delivery guarantee or ordering, and has almost no overhead beyond the packet itself.

Choose TCP for anything where losing or reordering data breaks correctness, a file transfer, a database connection, a REST API call. Choose UDP where a late or dropped packet is worse than a missing one, live video, VoIP, DNS lookups, because retransmitting a video frame after the moment has passed is pointless. The rule of thumb interviewers are checking for: correctness-critical goes TCP, latency-critical and loss-tolerant goes UDP.

Normalization breaks data into smaller related tables to eliminate redundancy and update anomalies, so a customer's address lives in exactly one place instead of being copied into every order row. Denormalization deliberately reintroduces some redundancy, often by pre-joining or duplicating data, to avoid expensive joins at read time.

You denormalize on purpose in reporting and analytics workloads where read speed matters more than write-time consistency risk, a data warehouse star schema is a classic example, storing a customer_name directly on a fact table instead of forcing every report query to join back to the dimension table. The tradeoff you own when you do this: if the customer's name changes, you now have to update it in multiple places, or accept that historical reports show the name as it was at the time of the transaction, which is sometimes exactly what you want.

A clustered index determines the physical storage order of the table's rows, the data itself is sorted and stored according to the index key, which is why a table can have only one clustered index. A non-clustered index is a separate structure that holds the indexed column's values alongside a pointer back to the actual row location, so a table can have many non-clustered indexes without changing how the underlying data is physically stored.

The performance consequence: reading a range of rows through a clustered index is fast because the matching rows are physically adjacent on disk. A non-clustered index lookup that needs columns beyond what's in the index itself has to do an extra "bookmark lookup" back to the actual row, which is why covering indexes (a non-clustered index that includes every column a query needs) exist, to avoid that second hop entirely.

Track the largest and second largest in a single pass, updating both as you go, which avoids the O(n log n) cost of a full sort when all you need is one comparison-based scan.

public static int secondLargest(int[] arr) {
 int largest = Integer.MIN_VALUE, second = Integer.MIN_VALUE;
 for (int n : arr) {
  if (n > largest) {
   second = largest;
   largest = n;
  } else if (n > second && n != largest) {
   second = n;
  }
 }
 return second;
}

The iterative approach walks the list once, flipping each node's next pointer to point backward instead of forward, tracking the previous node as you go.

public static Node reverse(Node head) {
 Node prev = null, curr = head;
 while (curr != null) {
  Node next = curr.next;
  curr.next = prev;
  prev = curr;
  curr = next;
 }
 return prev;
}

Recursively, you reverse the rest of the list first, then fix up the current node's pointers on the way back up the call stack. The tradeoff to mention if asked: the recursive version is O(n) space because of the call stack, versus O(1) for the iterative version, which matters for a list long enough to blow the stack.

Use two pointers, one into each array, always advancing the pointer for whichever array currently has the smaller front element, and appending that element to the result.

public static int[] merge(int[] a, int[] b) {
 int[] result = new int[a.length + b.length];
 int i = 0, j = 0, k = 0;
 while (i < a.length && j < b.length) {
  result[k++] = a[i] <= b[j] ? a[i++] : b[j++];
 }
 while (i < a.length) result[k++] = a[i++];
 while (j < b.length) result[k++] = b[j++];
 return result;
}

This is O(n + m) time and space, and it's the merge step from merge sort in isolation. Interviewers sometimes push further and ask you to merge k sorted arrays, which is the same idea with a min-heap tracking the smallest current front element across all k arrays instead of just two pointers.

Count the frequency of every character in one pass using a hash map, then walk the string a second time in order and return the first character whose count is exactly one.

public static char firstNonRepeating(String s) {
 Map<Character, Integer> counts = new HashMap<>();
 for (char c : s.toCharArray()) counts.merge(c, 1, Integer::sum);
 for (char c : s.toCharArray()) {
  if (counts.get(c) == 1) return c;
 }
 return '