Zensar Interview Questions (2026): Real, With Answers

Most candidates report a two-part test. A technical and aptitude section covering operating systems, C fundamentals, computer organization, networks, plus reasoning topics like analogy, syllogisms, and data interpretation, and a separate coding section with two or three problems pulled from arrays, strings, and basic math, sometimes with a choice of language (C, C++, Java, Python, Node.js). Recent reports put the coding portion at roughly 90 minutes for three problems, with one problem usually being straightforward enough to fully solve and the others partial-credit.

The cutoff candidates describe is somewhere around 75 percent on the aptitude side plus at least one fully passing solution on the coding side. That second bar matters more than it sounds like it should. A partially working solution that compiles and passes some test cases is worth more than a clever approach you didn't finish typing out.

This is one of the most commonly reported opening questions on Zensar's assessment, and the trap is assuming "no built-in functions" also bans basic string-to-array conversion. It doesn't, most languages need you to convert a string to a mutable character array first since strings are usually immutable.

public static String reverse(String s) {
  char[] chars = s.toCharArray();
  int left = 0, right = chars.length - 1;
  while (left < right) {
    char temp = chars[left];
    chars[left] = chars[right];
    chars[right] = temp;
    left++;
    right--;
  }
  return new String(chars);
}

Two pointers closing in from both ends gets you O(n) time and O(1) extra space beyond the output array, which is the answer graders are actually looking for over a recursive version that quietly costs O(n) stack frames.

The naive version rotates one position at a time, k times, which is correct but O(n*k). The version that actually passes the larger test cases on a timed assessment is the three-reversal trick: reverse the whole array, then reverse the first k elements, then reverse the rest.

public static void rotate(int[] nums, int k) {
  k = k % nums.length;
  reverse(nums, 0, nums.length - 1);
  reverse(nums, 0, k - 1);
  reverse(nums, k, nums.length - 1);
}

private static void reverse(int[] nums, int start, int end) {
  while (start < end) {
    int temp = nums[start];
    nums[start] = nums[end];
    nums[end] = temp;
    start++;
    end--;
  }
}

Worth saying out loud in the interview: taking k modulo the array length first, since a k larger than the array length is a common edge case the test suite checks for.

This is a real assessment question reported by a candidate: given something like gourav.mk@gmail.com, produce gourav.mk9, the username with its character count tacked onto the end. The whole problem is just string splitting plus concatenation, but the wording trips people up under time pressure because it doesn't say "split on @" directly.

def username_with_length(email):
  username = email.split("@")[0]
  return f"{username}{len(username)}"

print(username_with_length("gourav.mk@gmail.com")) # gourav.mk9

Read the exact output format twice before submitting on a timed test like this. Graders on these platforms usually do an exact string match, so an extra space or a different case in the output fails a test case that your logic actually got right.

Another reported assessment question: for inputs 20 and 100, the GCD is 20, which in binary is 10100, containing two 1s. The problem chains three small operations together, which is really what it's testing, can you compose simple building blocks correctly under time pressure.

public static int countOnesInGcdBinary(int a, int b) {
  int gcd = gcd(a, b);
  return Integer.bitCount(gcd); // built-in popcount, no manual binary loop needed
}

private static int gcd(int a, int b) {
  return b == 0 ? a : gcd(b, a % b);
}

Knowing that Integer.bitCount (or its equivalent) exists in your language's standard library saves real time here versus manually converting to a binary string and counting characters. Small library knowledge like this is exactly what separates a five-minute solve from a fifteen-minute one on a timed test.

A classic that shows up specifically as "write a data structure for a queue" in Zensar interview reports. The trick is that a stack gives you LIFO order for free, and you need FIFO, so you use one stack for pushing new elements and a second stack to reverse that order when it's time to pop.

class QueueUsingStacks {
  private Deque<Integer> inStack = new ArrayDeque<>();
  private Deque<Integer> outStack = new ArrayDeque<>();

  public void enqueue(int x) {
    inStack.push(x);
  }

  public int dequeue() {
    if (outStack.isEmpty()) {
      while (!inStack.isEmpty()) {
        outStack.push(inStack.pop());
      }
    }
    return outStack.pop();
  }
}

Amortized O(1) per operation, since each element only ever gets moved from inStack to outStack once across its whole lifetime in the queue, even though a single dequeue call can occasionally look like O(n).

Encapsulation, inheritance, polymorphism, and abstraction. The textbook examples (Animal, Dog, Cat) are fine to know but an interviewer usually wants to hear you tie each one to something you actually built, a repository interface that abstracts away whether data comes from Postgres or a cache, a payment processor class hierarchy where a base class defines a common charge method that Stripe and PayPal subclasses implement differently.

Polymorphism is the one candidates most often answer shallowly, reciting method overriding without mentioning that it's specifically runtime polymorphism, decided by the actual object type at execution time, as opposed to overloading, which is compile-time and decided by the method signature alone.

An abstract class can hold state (instance fields) and provide partial implementation alongside abstract methods a subclass must fill in, but a class can only extend one abstract class. An interface historically could only declare method signatures with no state at all, though modern Java lets interfaces carry default method bodies too, and a class can implement any number of interfaces.

The rule of thumb candidates give that actually holds up: pick an abstract class when subclasses share real implementation and some common state, a base Vehicle class with a shared odometer field and a shared startEngine() method. Pick an interface when you're describing a capability multiple unrelated classes can plug into, Comparable, Serializable, a Payable interface that both an Invoice and a Payroll class can implement without sharing any other code.

A process is an independent unit of execution with its own memory space, file handles, and resources, isolated from other processes by the OS. A thread is a unit of execution within a process that shares that process's memory space and resources with every other thread in the same process.

The practical consequence worth naming: because threads share memory, communication between them is cheap (just read a shared variable) but dangerous (two threads can corrupt shared state if they're not synchronized). Communication between processes has to go through the OS, pipes, sockets, shared memory segments, which is slower but keeps one process's crash from directly corrupting another's memory.

Four layers, not seven the way OSI has it: Application (HTTP, DNS, FTP, the protocols your code actually calls), Transport (TCP for reliable ordered delivery, UDP for speed over reliability), Internet (IP addressing and routing packets between networks), and Network Access (getting frames onto the physical wire or wireless medium).

The follow-up interviewers usually ask is TCP versus UDP specifically: TCP does a three-way handshake, guarantees ordered delivery, and retransmits lost packets, which costs latency. UDP fires packets with no handshake and no delivery guarantee, which is why it's the right choice for video calls and live game state where a dropped, stale packet is worse than a missing one.

Reported specifically as a database question in Zensar's technical rounds, phrased as "without LIMIT/OFFSET" to force you toward a subquery or window function instead of the shortcut.

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

This subquery approach also generalizes cleanly if the interviewer asks for the third highest next, since you just nest one more level of "less than the max of everything above this."

A direct follow-up to the second-highest question in the same round, per candidate reports. The window function version scales cleanly to "nth highest" without nesting subqueries three deep.

SELECT DISTINCT salary
FROM (
 SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
 FROM Employee
) ranked
WHERE rnk = 3;

DENSE_RANK matters over plain RANK here, if two employees are tied for the highest salary, RANK skips a number for the next rank and can silently give you the wrong "third highest." DENSE_RANK doesn't leave gaps.

HashMap allows null keys and values and isn't thread-safe, fine for single-threaded code or code you fully control the concurrency of yourself. Hashtable is thread-safe but synchronizes the entire map on every operation, which serializes access even when two threads are touching completely unrelated keys, and it doesn't allow null keys or values.

ConcurrentHashMap is the one you actually want for shared mutable state across threads in modern Java. It segments locking internally so that operations on different keys can proceed in parallel instead of blocking each other, which is why it's the default recommendation over Hashtable in essentially every production codebase written since Java 5.

Reported as an opening question in nearly every Zensar technical round. The trap candidates fall into is describing what the project did instead of what they specifically did on it, especially on team projects where it's tempting to say "we built" for everything.

A stronger structure: the problem the project solved, the specific piece you owned, one technical decision you made and why, and one thing that went wrong that you had to fix. That last part matters more than people expect, an interviewer learns far more from how you describe a bug you caused and fixed than from a clean success story.

The "why Zensar" half is the part candidates skip, giving a generic "great company culture" answer that could apply to any employer. Zensar is a services and consulting company working across BFSI, retail, and manufacturing clients, so a stronger answer connects something specific, exposure to a particular industry vertical, the scale of client engagements, a technology stack you want more hands-on time with, to what the company actually does.

Keep the self-introduction itself under two minutes and structured: current role or education, one or two relevant projects, then a bridge into why this specific opportunity. Longer than that and the interviewer starts checking their notes instead of listening.

The brute force is a nested loop, O(n squared), and it will pass small test cases but time out on the larger hidden ones that these assessments usually include. The expected answer uses a hash set to check for the complement in one pass.

public static List<int[]> findPairs(int[] nums, int target) {
  List<int[]> result = new ArrayList<>();
  Set<Integer> seen = new HashSet<>();
  for (int num : nums) {
    int complement = target - num;
    if (seen.contains(complement)) {
      result.add(new int[]{complement, num});
    }
    seen.add(num);
  }
  return result;
}

Say the complexity out loud unprompted, O(n) time, O(n) space, trading memory for speed. Assessments and live interviewers both reward candidates who name the tradeoff instead of waiting to be asked.

Reported directly from a Java developer loop at Zensar. The Stream version is what the interviewer is actually listening for, since the question is really testing Stream API fluency, not the underlying algorithm.

public static List<String> findDuplicateWords(String sentence) {
  return Arrays.stream(sentence.toLowerCase().split("s+"))
   .collect(Collectors.groupingBy(w -> w, Collectors.counting()))
   .entrySet().stream()
   .filter(e -> e.getValue() > 1)
   .map(Map.Entry::getKey)
   .collect(Collectors.toList());
}

Collectors.groupingBy paired with Collectors.counting() is the combination worth knowing cold. It's a two-line answer to "count occurrences of X" that a lot of candidates reinvent with a manual HashMap loop instead, which works but reads as less fluent to an interviewer who uses Streams daily.

The naive approach sorts descending and takes index 1, which works but is O(n log n) when the actual answer only needs a single pass.

public static int secondHighest(int[] salaries) {
  int highest = Integer.MIN_VALUE, second = Integer.MIN_VALUE;
  for (int s : salaries) {
    if (s > highest) {
      second = highest;
      highest = s;
    } else if (s > second && s < highest) {
      second = s;
    }
  }
  return second;
}

Watch the duplicate-value edge case out loud: if the highest salary appears twice, the second variable should not just become the same value again. That's the exact bug interviewers plant test inputs to catch.

Standard, but still asked as a warm-up before harder stack questions in Zensar's technical rounds according to candidate reports. Use a stack, push opening brackets, and on a closing bracket check it matches the top of the stack.

public static boolean isBalanced(String s) {
  Deque<Character> stack = new ArrayDeque<>();
  Map<Character, Character> pairs = Map.of(')', '(', ']', '[', '}', '{');
  for (char c : s.toCharArray()) {
    if (pairs.containsValue(c)) {
      stack.push(c);
    } else if (pairs.containsKey(c)) {
      if (stack.isEmpty() || stack.pop() != pairs.get(c)) return false;
    }
  }
  return stack.isEmpty();
}

Don't forget the final check after the loop ends. A string like "(((" never triggers a mismatch inside the loop, it only fails because the stack isn't empty at the end.

Sorting solves it in O(n log n) and is an acceptable answer to open with, but the follow-up an interviewer usually asks is whether you can do better. A min-heap of size k gets you O(n log k), which matters once the array is large and k is small.

public static int findKthLargest(int[] nums, int k) {
  PriorityQueue<Integer> minHeap = new PriorityQueue<>();
  for (int num : nums) {
    minHeap.offer(num);
    if (minHeap.size() > k) {
      minHeap.poll();
    }
  }
  return minHeap.peek();
}

The heap only ever holds k elements at a time, so its root is always the smallest of the current top-k candidates, which is exactly the kth largest once you've processed the whole array.

Mutual exclusion (a resource can only be held by one process at a time), hold and wait (a process holds a resource while waiting for another), no preemption (a resource can't be forcibly taken away), and circular wait (a cycle of processes each waiting on the next). All four have to be true simultaneously for deadlock to occur.

Breaking a deadlock in practice usually means removing circular wait, since the other three are often intrinsic to the resource type. A common real-world pattern is lock ordering: if every thread in your codebase always acquires lock A before lock B, never the reverse, a circular wait can't form because there's no path back to a lock you're already holding.

Normalization removes redundant data and the update anomalies that come with it, the same customer address stored in ten different order rows means ten places to fix a typo. First normal form removes repeating groups, second removes partial dependencies on a composite key, third removes transitive dependencies, non-key columns depending on other non-key columns instead of the key directly.

In practice, most production schemas stop at third normal form and then deliberately denormalize specific tables for read performance, a reporting table that duplicates a customer's name and region alongside every order row so a dashboard query doesn't need three joins. Knowing when to break the rule on purpose is a stronger answer than reciting all five normal forms from memory.

Most relational databases implement an index as a B-tree, a balanced tree structure that lets the database jump directly to the row matching a WHERE clause in roughly O(log n) comparisons instead of scanning every row in the table. Without an index, a lookup on a million-row table means reading up to a million rows; with one, it means a handful of tree traversals.

The cost is on the write side. Every insert, update, or delete has to update every index on that table, not just the table itself, so a table with five indexes pays that overhead five times over on every write. That's why you index columns you filter and join on often, and avoid indexing columns you rarely query by, or columns on a table that gets written far more often than it's read.

Virtual memory gives every process the illusion of a large, contiguous, private address space, even though physical RAM is smaller and shared across processes. The OS maps virtual addresses to physical ones through a page table, and pages that aren't currently needed can be swapped out to disk.

A page fault happens when a process accesses a virtual address whose page isn't currently loaded into physical memory. The CPU traps into the OS, the OS finds or fetches the page (from disk if it was swapped out, or a fresh zeroed page if it's the first access), updates the page table, and resumes the process, which has no idea any of this happened.

Atomicity, consistency, isolation, durability. Atomicity means a multi-step transaction either fully commits or fully rolls back, a failed bank transfer shouldn't debit one account without crediting the other. Consistency means a transaction only moves the database from one valid state to another, respecting constraints like foreign keys and check constraints.

Isolation means concurrent transactions don't see each other's uncommitted changes, violated when one transaction reads a row another transaction is mid-update on (a dirty read). Durability means once a transaction commits, it survives a crash immediately after, typically guaranteed by writing to a transaction log on disk before acknowledging the commit.

DELETE removes rows one at a time, can take a WHERE clause, fires row-level triggers, and can be rolled back inside a transaction since it's logged row by row. TRUNCATE removes all rows at once, can't take a WHERE clause, doesn't fire row-level triggers, and is much faster because it deallocates whole data pages instead of logging individual row deletions.

DROP removes the entire table structure along with its data, indexes, and constraints, there's nothing left to query afterward. A candidate answer that only covers DELETE vs TRUNCATE and forgets DROP is incomplete, since interviewers usually ask this as a three-way comparison specifically to see if you remember the table gets destroyed entirely in the third case.

INNER JOIN returns only rows with matches in both tables. LEFT JOIN returns every row from the left table plus matching rows from the right, filling in NULL where there's no match. RIGHT JOIN is the mirror image. FULL OUTER JOIN returns every row from both tables, matched where possible and NULL-filled elsewhere.

SELECT o.order_id, c.customer_name
FROM Orders o
LEFT JOIN Customers c ON o.customer_id = c.customer_id;
-- returns every order, even ones where the customer record was deleted

The example worth having ready is exactly this one, orders where the customer record might be missing. It's a real, common scenario that shows you understand LEFT JOIN's practical use, not just its definition.

A function must return a value and can be used directly inside a SELECT statement or a WHERE clause, but it can't modify database state (no INSERT, UPDATE, DELETE) in most database engines, and it can't manage its own transactions. A stored procedure can perform DML operations, manage transactions with explicit COMMIT and ROLLBACK, and doesn't have to return anything, though it can output multiple values through OUT parameters.

The practical rule of thumb: reach for a function when you need a reusable calculation inline in a query, a stored procedure when you need to run a multi-step operation that changes data and needs its own transaction boundary.

Comparable is implemented by the class itself and defines its single, natural ordering through compareTo, an Employee class implementing Comparable to sort by employee ID by default. Comparator is a separate object that defines an ordering external to the class, letting you sort the same objects multiple different ways without touching the class itself.

class Employee implements Comparable<Employee> {
  int id;
  String name;

  public int compareTo(Employee other) {
    return Integer.compare(this.id, other.id); // natural order: by id
  }
}

Comparator<Employee> byName = (a, b) -> a.name.compareTo(b.name);
employees.sort(byName); // alternate order, no change to Employee class

Reach for Comparator whenever you need more than one sort order for the same type, or when the class is one you don't own and can't add Comparable to.

Before Java 8, adding a new method to a widely-implemented interface broke every class that implemented it, since Java required every implementing class to provide every method. Default methods let an interface provide a body for a method, so existing implementations keep compiling even after a new method is added to the interface.

interface PaymentProcessor {
  void charge(double amount);

  default void refund(double amount) {
    throw new UnsupportedOperationException("Refunds not supported");
  }
}

Static methods on an interface serve a different, smaller purpose, utility methods related to the interface that don't belong to any specific instance, like the factory methods List.of() and Comparator.comparing() add directly onto their interfaces instead of living in a separate utility class.

map transforms each element one-to-one, so if the transformation itself produces a stream or a list, you end up with a stream of streams, a nested structure you then have to unwrap yourself. flatMap transforms each element and flattens the result into a single stream, one level deep, in the same step.

List<List<Integer>> nested = List.of(List.of(1, 2), List.of(3, 4));

// map keeps the nesting: Stream<List<Integer>>
nested.stream().map(list -> list).forEach(System.out::println);

// flatMap flattens it: Stream<Integer>
List<Integer> flat = nested.stream()
 .flatMap(List::stream)
 .collect(Collectors.toList()); // [1, 2, 3, 4]

The tell that you need flatMap instead of map: your mapping function's own return type is already a stream or a collection, and you don't actually want a collection of collections in the final result.

Singleton, the default, creates exactly one instance per Spring container and shares it everywhere it's injected. Prototype creates a new instance every time it's requested. Request and session scopes, in a web application, tie a bean's lifetime to a single HTTP request or a user's session respectively.

The bug candidates walk into: injecting a prototype-scoped bean that holds mutable state into a singleton-scoped bean without realizing Spring only resolves that injection once, at singleton creation time, not on every use. The result is one shared prototype instance behaving exactly like a singleton, which defeats the whole point of choosing prototype scope. A scoped proxy fixes this, but you have to know to ask for one.

Idempotent means calling the operation multiple times with the same input produces the same end state as calling it once, no extra side effects on the second, third, or hundredth call. PUT is defined by the HTTP spec as idempotent because it's meant to fully replace a resource at a known URL, sending the exact same PUT twice leaves the resource in the exact same final state either way.

This matters in practice for retries. A client that times out waiting for a PUT response and retries, not knowing whether the first request actually succeeded, can safely retry without worrying about double-processing. POST doesn't carry that guarantee, which is exactly why retrying a timed-out POST to a payment endpoint is dangerous, it can create a second charge, and why idempotency keys exist for POST endpoints that need retry safety anyway.

A checked exception, anything extending Exception but not RuntimeException, must be either caught or declared in a method's throws clause, or the code won't compile. An unchecked exception, extending RuntimeException, has no such requirement, a method can throw one without ever mentioning it in its signature.

public void readConfig(String path) throws IOException { // checked, must declare
  Files.readAllLines(Path.of(path));
}

public void divide(int a, int b) { // unchecked, no declaration needed
  if (b == 0) throw new IllegalArgumentException("divisor cannot be zero");
}

The design guidance most teams actually follow: use checked exceptions for conditions a caller can reasonably recover from, a missing file, a network timeout, and unchecked exceptions for programmer errors that indicate a bug, an invalid argument, a null that should never have been null. Overusing checked exceptions on APIs where callers can't do anything but log and rethrow is a common complaint about older Java codebases.

Reported specifically as a Java developer interview question at Zensar. The answer surprises people who expect a NullPointerException. String concatenation with the + operator calls String.valueOf() on each operand, and String.valueOf(null) for an Object reference returns the literal string "null", not an exception.

String name = null;
System.out.println("Name: " + name); // prints "Name: null", no exception

String result = name.concat("!"); // this DOES throw NullPointerException

The distinction worth making clearly: the + operator is safe with null because it goes through String.valueOf, but calling a method directly on a null reference, name.concat(), name.length(), always throws. Candidates who blur that line usually haven't actually hit the bug in production yet.

Reported as a real question in a Zensar Java developer loop, phrased around HashSet behavior with duplicate custom objects. By default, no, it doesn't. Object's default equals() checks reference identity, are these the literal same object in memory, not field-by-field value equality, so two separately constructed Employee objects with identical field values are treated as distinct.

class Employee {
  int id;
  String name;
  // without overriding equals() and hashCode(), two Employees
  // with id=1, name="Asha" are NOT duplicates in a HashSet

  @Override
  public boolean equals(Object o) {
    if (!(o instanceof Employee other)) return false;
    return id == other.id && Objects.equals(name, other.name);
  }

  @Override
  public int hashCode() {
    return Objects.hash(id, name);
  }
}

The part candidates most often get wrong: overriding equals() alone without also overriding hashCode() consistently. HashSet uses hashCode() first to find the right bucket, and only calls equals() to compare objects that land in the same bucket, so a mismatched hashCode silently defeats your equals() logic even though it looks correct on paper.

Reported directly as a common HR question at Zensar. The failure mode is the fake weakness, "I work too hard" or "I'm too much of a perfectionist," which every experienced HR interviewer has heard a hundred times and immediately discounts.

A real answer names something specific and shows one concrete action taken against it, not a vague intention. "I used to underestimate how long integration work takes because I only scoped the happy path, so I've started explicitly listing edge cases and dependency risks before giving an estimate" is a weakness that's actually believable and shows self-awareness translating into a changed behavior, not just an admission.

This shows up specifically in Zensar candidate reports, more directly than at most product companies, because Zensar's delivery model staffs specific client accounts out of specific locations, and shift alignment with a client's time zone is a real operational constraint, not small talk.

Answer this one honestly and specifically rather than defaulting to "I'm flexible with everything," which reads as either evasive or unprepared. If you do have a genuine constraint, a location tie, a shift you can't work, say so plainly. Recruiters would rather know upfront than have an offer fall apart at the background-check stage.

Reported as the closing question in Zensar's HR round, and treating it as optional is a missed opportunity, not a neutral choice. Asking nothing reads as low genuine interest in the role rather than as politeness.

Questions that land well at a services company specifically: which client account or project you'd likely be staffed on initially, how project rotations work if the current account winds down, and what the actual onboarding and training period looks like before you're billed to a client. Those questions signal you understand how a services company operates, which is a different signal than the generic "what's the culture like" question most candidates default to.

Candidate reports describe this exact scenario, "questions on integration and deployment," phrased around real production troubleshooting rather than textbook debugging. Start with what's actually observable: logs and error rates first, to characterize whether it's truly intermittent or correlated with something, load, a specific endpoint, a downstream dependency.

From there: check whether the errors cluster around a deploy (rollback candidate), a traffic spike (capacity or connection pool exhaustion), or a downstream service (timeout misconfiguration, a dependency that itself degraded). The answer an interviewer wants isn't a specific root cause, since there isn't enough information in the question to name one, it's a methodical narrowing process instead of guessing at a fix before you've looked at any evidence.

This comes up in Zensar's more senior developer loops where the discussion moves past basic array and string problems into something closer to real system components. The combination that gets you O(1) on both operations is a hash map for lookups plus a doubly linked list for eviction order.

class LRUCache {
  private final int capacity;
  private final LinkedHashMap<Integer, Integer> map;

  public LRUCache(int capacity) {
    this.capacity = capacity;
    this.map = new LinkedHashMap<>(capacity, 0.75f, true) {
      protected boolean removeEldestEntry(Map.Entry<Integer, Integer> eldest) {
        return size() > LRUCache.this.capacity;
      }
    };
  }

  public int get(int key) {
    return map.getOrDefault(key, -1);
  }

  public void put(int key, int value) {
    map.put(key, value);
  }
}

Java's LinkedHashMap with access-order mode is a legitimate shortcut in an interview if you can explain what it's doing underneath, a hash map for O(1) lookup plus a linked list tracking recency. If the interviewer wants you to build it from scratch without that class, they'll usually say so up front.

The brute force checks every substring, O(n cubed) once you include the uniqueness check. The sliding window version tracks a window of unique characters and shrinks it from the left the moment a duplicate shows up.

public static int lengthOfLongestSubstring(String s) {
  Map<Character, Integer> lastSeen = new HashMap<>();
  int maxLen = 0, start = 0;
  for (int end = 0; end < s.length(); end++) {
    char c = s.charAt(end);
    if (lastSeen.containsKey(c) && lastSeen.get(c) >= start) {
      start = lastSeen.get(c) + 1;
    }
    lastSeen.put(c, end);
    maxLen = Math.max(maxLen, end - start + 1);
  }
  return maxLen;
}

The detail that trips people up is the "lastSeen.get(c) >= start" check. Without it, a character that appeared before the current window started incorrectly shrinks the window even though it's no longer inside it.

The counter++ operation looks atomic but isn't, it's actually a read, an increment, and a write, three separate steps. Two threads can both read the same value before either writes back, and one increment gets silently lost.

class Counter {
  private final AtomicInteger count = new AtomicInteger(0);

  public void increment() {
    count.incrementAndGet(); // atomic, no lost updates
  }
}

An AtomicInteger uses a compare-and-swap instruction at the hardware level, so the read-modify-write happens as one indivisible step instead of three separate ones a second thread could interleave with. A synchronized block or a plain lock also fixes the bug, but costs more under contention since it blocks other threads entirely instead of just retrying a CAS operation.

Reported directly in a Zensar technical specialist interview. InnoDB supports transactions (COMMIT/ROLLBACK), foreign key constraints, and row-level locking, which lets multiple transactions modify different rows of the same table concurrently. MyISAM has no transaction support, no foreign keys, and locks at the table level, meaning one write blocks every other operation on that table until it finishes.

InnoDB has been the MySQL default since version 5.5 specifically because most production applications need transactional integrity more than they need MyISAM's slightly faster raw read speed on tables with almost no writes. The only scenario where MyISAM still makes sense is a read-heavy, rarely-written table where you're confident you'll never need a transaction or a foreign key constraint against it.

A record is a compiler-level feature that generates a constructor, accessors, equals, hashCode, and toString from a fixed list of fields, and every field is implicitly final, so a record is immutable by construction. Lombok's @Data generates similar boilerplate through annotation processing, but by default it also generates mutable setters, which means a Lombok @Data class isn't immutable unless you separately add @Value or manually drop the setters.

public record Point(int x, int y) {}
// constructor, x(), y(), equals, hashCode, toString all generated,
// and there's no way to reassign x or y after construction

The other real difference is that records are a language feature with no external dependency and no annotation processing step, while Lombok requires a build plugin and, in some IDEs, extra setup to get the generated methods to show up correctly during editing. For a genuinely immutable data carrier, a record is the more modern, dependency-free choice.

CQRS, command query responsibility segregation, splits the models used to write data (commands) from the models used to read data (queries), sometimes backed by entirely separate data stores optimized for each side, a normalized write store and a denormalized, query-optimized read store kept in sync through events.

For most CRUD-heavy enterprise applications, the honest answer is no, not fully. Full CQRS with separate read and write stores adds real operational complexity, eventual consistency between the two sides, more moving infrastructure, that only pays off when read and write patterns genuinely diverge at scale, high-volume reporting dashboards against a system with heavy, complex writes, for instance. A lighter version, separate DTOs for reads versus writes against the same database, gets most teams the readability benefit without the operational cost, and it's the version worth proposing unless the scale genuinely justifies the full pattern.

It can't be overridden, that's the entire point of marking it final, the JVM guarantees the exact implementation in the parent class runs no matter what subclass you're actually holding a reference to. It absolutely can be overloaded, since overloading is about a different method signature entirely, not the same signature with a different body.

class Base {
  public final void save() { System.out.println("Base save"); }
}

class Derived extends Base {
  // public void save() {} // compile error, cannot override a final method

  public void save(String note) { // fine, this overloads, doesn't override
    System.out.println("Saving with note: " + note);
  }
}

Interviewers usually push on why you'd mark a method final at all. The honest answer: it's rarer than most textbooks imply, mostly reserved for security-sensitive or invariant-critical methods where a subclass silently changing behavior would break a guarantee the rest of the codebase depends on.

The weak version of this answer ends with "I was right and they eventually agreed." The stronger version shows you actually engaged with the other side's reasoning before the disagreement resolved, and that the resolution mechanism was something repeatable, a quick spike to test both approaches, a check against an existing team convention, escalating to a tie-breaker only after genuinely trying to reach agreement directly.

What interviewers are actually screening for here is whether you'll be workable inside a team that doesn't always agree with you, which is a bigger predictor of success at a delivery-focused company than raw technical skill is. A candidate who can't describe ever being wrong in a disagreement is a bigger flag than one who describes losing an argument gracefully.

The instinct is to list generic strengths, "hardworking," "quick learner," that every other candidate in the room is also claiming. What actually differentiates an answer is specificity tied to evidence, naming one thing you've built or fixed that required exactly the skill the role needs, not a personality trait but a demonstrated outcome.

It also helps to be honest about what you don't know yet rather than overselling. "I haven't worked with your specific client's stack before, but I picked up React from scratch on my last project in about three weeks and shipped a feature with it" is a more credible answer than pretending you're already an expert in something the job posting mentions and you've never touched.

Generic answers about "staying calm" don't hold up to a follow-up question, and interviewers at a services company usually do follow up, since deadline pressure on a client engagement is a routine part of the job, not a rare crisis. A concrete answer names one real deadline crunch, what you actually deprioritized to hit it, and how you communicated that tradeoff to whoever needed to know.

The detail that separates a strong answer from a vague one is the communication part specifically. Working long hours silently until a deadline passes or fails is a different skill from flagging early that a deadline is at risk and proposing a scope cut before it becomes a surprise to a client or a project manager. Zensar, like most delivery-model companies, is screening for the second skill more than the first.