Hexaware Interview Questions (2026): Real, With Answers

For graduate and entry level hiring it is usually split into an aptitude block and a domain block, sometimes run as one combined session of around 90 questions in 90 minutes. The aptitude side covers quantitative reasoning (percentages, ratios, time and work, time speed and distance), verbal ability (sentence correction, jumbled paragraphs, reading comprehension), and logical reasoning (coding-decoding, seating arrangements, series completion). The domain block is technical MCQs, mostly pseudocode tracing and computer fundamentals questions rather than open ended coding.

Time pressure is the actual test here more than difficulty. Forty eight questions in forty eight minutes across a section leaves under a minute per question, so the candidates who clear it aren't the ones who know the material best, they're the ones who've drilled enough practice sets to answer without stopping to think.

The section leans on time and work, ratio, and profit and loss more than pure algebra, phrased as short word problems you solve in your head rather than on paper. A typical one: a task takes A 12 days alone and B 18 days alone, how long do they take working together. You'd set it up as combined rate 1/12 + 1/18 = 5/36 of the job per day, so the job takes 36/5, or 7.2 days. The test rewards knowing that rate-addition shortcut cold, because deriving it fresh under a 60 second clock is where people lose time.

Sentence correction, paragraph jumbles, and short reading comprehension passages, similar to any campus placement English section. It is not testing literary skill, it is testing whether you can spot a subject verb agreement error or a misplaced modifier fast enough to move on. Candidates who read a lot of formal English day to day (technical documentation, not just chat messages) tend to clear this section without dedicated prep. If English isn't your first working language, this is worth 20 to 30 minutes of dedicated drilling the week before, not the night before.

Candidates consistently describe two easy to moderate problems, not one hard problem, solvable with common logic rather than a specific data structure trick. The catch reported more than once: the online editor doesn't always support Python, so you may be forced into Java or C++ even if Python is your strongest language. Check the language list before the clock starts if you get the option, and if it defaults away from your best language, budget a few extra minutes for syntax you're rustier on.

Walk the string once, tracking which characters you've already seen in a set or a hash map. The first character that's already in that set when you reach it is your answer, and if nothing repeats, return a sentinel like -1 or None.

def first_repeating(s):
  seen = set()
  for ch in s:
    if ch in seen:
      return ch
    seen.add(ch)
  return None

This is O(n) time, O(n) space in the worst case. The wrong instinct is nested loops comparing every pair of characters, which works but turns an O(n) problem into O(n squared) for no reason. Interviewers watching this round care whether you reach for the hash set immediately or only after being nudged.

The question is ambiguous on its face, and the first thing worth doing out loud is asking which reversal: row order flipped, each row's elements flipped, or a full 180 degree rotation. Most interviewers mean reversing each row in place, which for a 3x3 is just swapping the first and third element of every row while the middle element stays put.

def reverse_rows(matrix):
  return [row[::-1] for row in matrix]

If they actually mean a 180 degree rotation, reverse each row and then reverse the order of the rows themselves. Asking the clarifying question first is worth more here than jumping straight to code, since guessing wrong wastes the whole round.

If both arrays are already sorted, the fast path is a direct element by element comparison after confirming they're the same length. No hashing, no extra data structure needed, since sorted order already guarantees that equal multisets line up position by position.

def sorted_arrays_equal(a, b):
  return len(a) == len(b) and all(x == y for x, y in zip(a, b))

The one thing worth saying out loud: if the arrays weren't sorted, you'd need a Counter or a full sort first, and mentioning that distinction unprompted signals you understand why the sorted precondition matters, not just that you can write a loop.

This shows up often enough in Hexaware's fresher rounds that it's worth having both the iterative and recursive version ready, and being able to say why you'd pick one over the other. Iterative is the one you'd actually ship.

def fibonacci(n):
  a, b = 0, 1
  result = []
  for _ in range(n):
    result.append(a)
    a, b = b, a + b
  return result

Plain recursion without memoization is O(2^n) and will visibly slow down past n=35 or so, which is worth mentioning even if the interviewer only asked for 'a' solution. It shows you know the naive recursive version has a real performance ceiling, not just an academic one.

Encapsulation bundles data and the methods that operate on it into one unit and restricts direct access to that data, typically through private fields and public getters and setters. Abstraction hides implementation detail and exposes only what a caller needs to know, an interface or abstract class describing what a method does without describing how. Inheritance lets a class acquire fields and behavior from a parent class. Polymorphism lets the same method call behave differently depending on the actual object it's called on, at compile time through overloading or at runtime through overriding.

The distinction interviewers actually probe: abstraction is about hiding complexity in design, polymorphism is about one interface having many implementations in behavior. A remote control is a good abstraction example, you press 'power' without knowing the circuitry. Different remote models responding differently to the same 'power' button press is closer to polymorphism.

A process has its own isolated memory space, its own address space, file handles, and resources, managed independently by the OS. A thread is a unit of execution within a process, and all threads in the same process share that process's memory space and resources. That shared memory is exactly why threads are cheaper to create and switch between than processes, and exactly why concurrent access to shared data between threads needs explicit synchronization, since there's no OS level isolation protecting one thread's view of memory from another's.

A primary key uniquely identifies every row in its own table and can't be null. A foreign key is a column (or set of columns) in one table that references a primary key in another table, enforcing referential integrity, you can't insert a foreign key value that doesn't exist in the referenced table.

A table has exactly one primary key, though that key can be composite, made of more than one column together. A table can have any number of foreign keys, since it can reference several other tables at once, an orders table might have separate foreign keys pointing to customers and to products, for instance.

C is procedural, organized around functions operating on data passed explicitly between them. C++ adds object oriented features, classes bundling data and behavior together, but it also adds a lot beyond OOP specifically: function and operator overloading, templates for generic programming, exception handling with try and catch instead of C's manual error code checking, and references in addition to pointers.

The practical day to day difference shows up in memory and error handling style. C leans on manual malloc and free and return code checking throughout. C++ leans on constructors and destructors (RAII) tying resource cleanup to object lifetime, and exceptions for error propagation instead of threading return codes through every call site.

CHAR is fixed length, the database pads shorter values with trailing spaces up to the declared length and always uses that full amount of storage. VARCHAR is variable length, storing only the actual character count plus a small length prefix, so it uses less space for shorter values.

The difference matters for columns with genuinely consistent length (country codes, fixed format IDs), where CHAR avoids the length prefix overhead and can be marginally faster to compare. For anything with variable length content, names, descriptions, VARCHAR is the practical default, since CHAR would waste space padding every short value out to the max length and, depending on the database engine, comparisons may need trailing space handling that VARCHAR doesn't.

WHERE filters individual rows before any grouping happens. HAVING filters groups after a GROUP BY has already aggregated rows together, and it's the only clause that can reference an aggregate function like COUNT() or SUM() in its condition, since those aggregates don't exist yet at the row level WHERE operates on.

SELECT department, COUNT(*) AS headcount
FROM employees
WHERE status = 'active'
GROUP BY department
HAVING COUNT(*) > 10;

Trying to write COUNT(*) > 10 in a WHERE clause instead of HAVING is a genuinely common error, the database will reject it outright since aggregates aren't computed at the point WHERE filters run.

Candidate reports describe a roughly one hour session on a platform referred to as SpeechX or Mettle, evaluating pronunciation, vocabulary, and grammar specifically, not technical content. It's a genuinely separate hurdle from the technical interview, and more than one reviewer has advised prioritizing this round's prep over further coding practice, since a strong technical answer delivered with unclear pronunciation or grammar errors can still cost you the round.

Yes, treat it as its own prep track rather than assuming strong technical skills carry you through. Practically: read technical articles out loud for ten minutes a day in the week before your interview, describe a recent project verbally to a friend or into a voice recorder without notes, and time yourself answering a prompt in under a minute to build the habit of forming a complete thought quickly rather than trailing off mid sentence.

Keep it structured and short: name, educational background, relevant internships or projects, then the specific technical strengths that connect to the role you're interviewing for. The mistake candidates make here is turning it into a full resume readout instead of a 60 to 90 second narrative that ends by pointing at why this particular role fits what you've built so far.

Answer with a realistic near term trajectory tied to the role, growing technical depth in the stack you'd be working with, moving toward more ownership on a project, rather than naming a specific title or claiming you'll be a manager in two years. HR is checking for reasonable ambition and a sense that you'll stay long enough to be worth training, not asking you to commit to a fixed career plan.

Expect a short block of pseudocode, ten to fifteen lines, with loops and conditionals, and you're asked what value a variable holds after it finishes running. Bitwise operations show up disproportionately often relative to how rarely they come up in actual day to day development, right shifts, XOR swaps, masking with AND. If you haven't traced bitwise pseudocode by hand recently, that's the specific gap worth closing before the test, not general programming ability.

x = 5   // 0101
y = 3   // 0011
z = x ^ y // XOR: 0110 = 6
z = z << 1 // left shift: 1100 = 12

You're given a rule that maps letters or words to a coded form, sometimes shown with one worked example, and asked to apply the same rule to a new word. A common variant shifts each letter a fixed number of positions in the alphabet, so 'CAT' encoded with a shift of 2 becomes 'EAV'. Once you spot whether the rule is a shift, a reversal, or a substitution table, the actual decoding is arithmetic, not insight. The trap is assuming the rule from the first letter alone instead of checking it against the full example word.

Yes, and this is the round most Hexaware candidates never get past. It runs as a genuine elimination gate, not a formality before the interviews, which is why campus and off campus threads spend so much time on aptitude prep resources rather than technical prep. Hexaware doesn't publish an exact cutoff score, and it likely varies by hiring cycle and role volume, but the consistent pattern across candidate reports is that a large share of applicants exit here, before any human reviews their resume.

No. Graduate and campus hiring runs the full aptitude plus domain test as an elimination gate, because volume is high and the company needs a fast first filter. Experienced hires, three plus years, applying for a specific Java,.NET, or QA opening typically skip straight to a technical screen with a recruiter or hiring manager, sometimes still with a short online coding assessment attached, but without the full quant and verbal battery. If you're applying laterally and see a full aptitude test in your process, that's the exception, not the norm.

Map each symbol to its value, then walk the string once. The only real logic is the subtractive case: if a symbol's value is smaller than the value immediately to its right, subtract it instead of adding it (IV is 4, not 6). Otherwise you add it.

def roman_to_int(s):
  values = {'I': 1, 'V': 5, 'X': 10, 'L': 50, 'C': 100, 'D': 500, 'M': 1000}
  total = 0
  for i in range(len(s)):
    if i + 1 < len(s) and values[s[i]] < values[s[i + 1]]:
      total -= values[s[i]]
    else:
      total += values[s[i]]
  return total

One pass, constant extra space beyond the lookup table. The subtraction case is the only part people get wrong under time pressure, and it's worth writing a quick mental test case (IX, IV) before you submit.

Do a standard merge, walking both arrays with two pointers and comparing the current elements, but before appending a value to the output, check whether it equals the last value already appended. Since both inputs are sorted, duplicates always end up adjacent in the merged result, so a single 'skip if same as last' check is enough, no separate deduplication pass needed.

def merge_unique(a, b):
  i = j = 0
  result = []
  while i < len(a) or j < len(b):
    if j >= len(b) or (i < len(a) and a[i] <= b[j]):
      val, i = a[i], i + 1
    else:
      val, j = b[j], j + 1
    if not result or result[-1] != val:
      result.append(val)
  return result

Sort the array and multiply the last three elements, which is the simplest correct answer and fine for the size of arrays this round actually uses. The one detail that trips people up: if the array can contain negative numbers, two large negative numbers multiplied together produce a large positive number, so the true maximum product might come from the two smallest (most negative) values times the single largest value, not just the top three.

def max_product_of_three(nums):
  nums.sort()
  return max(nums[-1] * nums[-2] * nums[-3], nums[0] * nums[1] * nums[-1])

If the interviewer explicitly says all values are positive, the two-negatives case doesn't apply and the simple top-three answer is complete. Naming the edge case even when it doesn't apply here is what separates a candidate who understands why from one who memorized the sort-and-multiply trick.

Java doesn't allow a class to extend more than one class, specifically to avoid the diamond problem, ambiguity over which parent's method version wins when two parents define the same method signature. It gets around this by letting a class implement multiple interfaces instead. Since Java 8 added default methods to interfaces, the diamond problem can resurface there too, and Java resolves it by forcing the implementing class to explicitly override the conflicting method if two interfaces provide the same default.

interface A { default void hello() { System.out.println("A"); } }
interface B { default void hello() { System.out.println("B"); } }

class C implements A, B {
  public void hello() {
    A.super.hello(); // must resolve the conflict explicitly
  }
}

Round Robin assigns each process a fixed time slice, the quantum, and cycles through the ready queue giving every process one quantum's worth of CPU time before moving to the next, preempting a process that isn't done when its quantum expires. First Come First Served runs processes strictly in arrival order to completion with no preemption, so one long process can block every process behind it, the convoy effect.

Round Robin trades some efficiency (more context switches, more overhead) for fairness and responsiveness, every process gets CPU time within a bounded wait rather than potentially waiting indefinitely behind a long job. It's the default choice for time sharing systems where interactive response matters more than raw throughput.

Turnaround time is the total time from when a process arrives to when it finishes, completion time minus arrival time. Waiting time is turnaround time minus the process's actual burst (CPU execution) time, in other words, time spent sitting in the ready queue not actually running. Throughput is a system level metric, not a per process one: how many processes complete per unit of time.

They pull against each other under different schedulers. Shortest Job First minimizes average waiting time but can starve long processes indefinitely. Round Robin bounds worst case waiting time at the cost of higher average turnaround time from context switch overhead. A scheduling question worth having ready: no single scheduler optimizes all three at once, which is why real operating systems use hybrid, multilevel feedback queues instead of one pure algorithm.

TCP is connection oriented, guarantees ordered and reliable delivery through acknowledgments and retransmission, and includes flow and congestion control. UDP is connectionless, sends packets ('datagrams') with no delivery guarantee, no ordering guarantee, and no built in retransmission, but with far less overhead per packet.

You'd choose UDP when losing a packet occasionally is cheaper than the latency cost of guaranteeing delivery, live video and voice calls, DNS lookups, and multiplayer game state updates are the standard examples. In each case, a slightly stale or dropped packet is preferable to waiting for TCP's retransmission and reordering machinery to catch up.

Normalization restructures tables to reduce redundancy and avoid update anomalies, splitting data into related tables connected by foreign keys instead of repeating the same information across rows. A classic example: an orders table storing customer name and address directly on every order row. If a customer's address changes, you'd need to update every historical order row, and any inconsistency between rows becomes a data integrity bug.

Moving to 3NF means pulling customer data into its own table keyed by customer ID, and the orders table stores only that ID as a foreign key. Now a customer's address lives in exactly one place, updates are a single row change, and there's no possibility of two orders disagreeing about the same customer's address.

this() calls another constructor in the same class, letting you chain constructor overloads without duplicating initialization logic. super() calls a constructor in the immediate parent class, and Java inserts an implicit super() call automatically if you don't write one, which is why every constructor call chain eventually reaches Object's constructor.

You cannot use both this() and super() in the same constructor, because each must be the very first statement in the constructor body, and only one first statement is possible. If you need parent initialization plus shared logic, the usual pattern is putting the shared logic in a separate helper method called after either this() or super() runs, not trying to squeeze both calls into one constructor.

Yes. A private constructor prevents any code outside the class from instantiating it directly with new, which is exactly the mechanism behind the singleton pattern, a class exposing a static method that returns the one shared instance instead of letting callers create their own. It's also how utility classes with only static methods (a Math-style helper class) prevent pointless instantiation, since there's no meaningful instance state to create.

public class ConfigManager {
  private static final ConfigManager instance = new ConfigManager();
  private ConfigManager() {}
  public static ConfigManager getInstance() {
    return instance;
  }
}

An abstract class can hold constructor logic, instance fields, and a mix of implemented and unimplemented methods, but a class can only extend one abstract class. An interface historically held only method signatures, though since Java 8 it can include default and static methods too, and a class can implement any number of interfaces.

Pick an abstract class when subclasses genuinely share state or common implementation you want inherited once. Pick an interface when you're defining a capability or contract that unrelated classes might all need to satisfy, Comparable and Runnable being the standard library's own examples, since a String and a Thread have nothing in common except both needing to fulfill that one contract.

A regular union declares a named type where all members share the same memory location, only one member holds a valid value at a time, and you access members through a named instance of that union. An anonymous union has no tag name, and its members become directly accessible in the enclosing scope as if they were ordinary variables, without needing to go through a union instance name first.

union Data { int i; float f; } d;
d.i = 5; // named union, access through d

struct Record {
  union { int i; float f; }; // anonymous union
  char name[20];
};
struct Record r;
r.i = 5; // accessed directly, no union instance name needed

Recursion solves a problem by having a function call itself on a smaller version of the same problem until it hits a base case, while iteration solves it with a loop that updates state across repeated passes. Recursion often reads cleaner for problems that are naturally self similar, tree traversal, divide and conquer algorithms, but each call adds a new frame to the call stack.

The real problem shows up when recursion depth scales with input size and there's no tail call optimization applied (which most compilers, including Java's and most C++ compilers by default, don't reliably guarantee). A recursive function walking a list of ten thousand elements can blow the call stack with a stack overflow, where the equivalent loop handles the same input with constant stack space. That's the concrete reason to convert deep recursion to iteration in production code, not just style preference.

A subquery that excludes the maximum and then takes the max of what's left is the cleanest portable version, since it works the same way across MySQL, Postgres, and SQL Server without depending on a database-specific pagination clause.

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

Worth mentioning unprompted: this returns nothing if there's a tie for the highest salary and no distinct second value exists, and it silently breaks if you need the Nth highest for arbitrary N. For that generalized case, DENSE_RANK() over a window is the right tool, and naming that alternative shows you know LIMIT isn't the only path even in databases that support it.

INNER JOIN returns only rows where the join condition matches in both tables. LEFT JOIN returns every row from the left table regardless of whether a match exists in the right table, filling in NULLs for the right table's columns when there's no match.

Concretely: joining a customers table to an orders table on customer ID, INNER JOIN only returns customers who have placed at least one order. LEFT JOIN (customers as the left table) returns every customer, including ones who've never ordered, with NULL in every order column for those rows. If a report needs to show 'customers with zero orders' as a category, INNER JOIN would silently drop them from the results entirely, which is the exact bug this distinction causes when someone picks the wrong join.

An index is a separate data structure, usually a B-tree, that the database maintains alongside a table to let it look up rows by a column's value without scanning every row. It speeds up SELECT queries filtering or sorting on the indexed column, often turning an O(n) full table scan into an O(log n) lookup.

The tradeoff is on writes, not reads. Every INSERT, UPDATE, or DELETE now has to update every index on that table too, not just the table data itself, so a table with many indexes gets noticeably slower to write to even though it stays fast to read from. Indexing every column 'just in case' is a common junior mistake, the right approach is indexing columns that are actually filtered or joined on frequently, not columns picked defensively.

Based on what candidates report the round measures, clarity matters more than accent itself, whether a listener can understand each word without straining, not whether you sound like a specific regional or native accent. Practically that means enunciating word endings fully, not dropping the final consonant sound, keeping a steady pace instead of rushing, and pausing between sentences rather than running them together.

The most direct prep for this isn't accent training, it's reading a paragraph out loud daily and recording yourself, then listening back for where you slurred a word or sped up unconsciously under time pressure, since that's exactly what happens live in the actual assessment too.

Expect a mix of reading a passage aloud, describing a picture or short scenario in your own words, and answering a spoken prompt with a few complete sentences, the kind of tasks used in standard spoken English proficiency assessments. The grammar being scored is basic correctness, subject verb agreement, correct tense, complete sentences, not advanced vocabulary or idiom use.

Answer briefly and comfortably, a sentence or two on family background if you're asked directly, then pivot the answer back toward your own professional story, education, career motivation, why you're pursuing this specific role. It's not meant to be an interrogation, it's a warm up question meant to see how you handle an open ended, slightly informal prompt without freezing or over sharing.

If it feels intrusive, a polite short answer followed by redirecting to your professional background is completely reasonable, and no interviewer is scoring you on how much personal detail you volunteer.

Answer with two or three specific, concrete things, a project, a skill, a piece of coursework or work experience, that map directly onto what the job description actually asks for, rather than a general 'I'm a hard worker' claim. Specificity is what reads as confident without reading as arrogant, since you're pointing at evidence rather than asserting a trait about yourself.

Weak version: 'I'm a fast learner and a team player.' Stronger version: 'I built and deployed a small Java web app during my final semester that used the same Spring Boot stack this team runs, and I debugged a production issue in a summer internship that required reading unfamiliar code under a deadline, which is close to what this role asks for day to day.'

Pick something real but not disqualifying for the specific role, and pair it with a concrete step you've actually taken to work on it, not a vague intention. 'I used to underestimate how long testing would take on a feature, so I started blocking dedicated test time into my project plan up front instead of treating it as an afterthought' reads as self aware. 'I'm a perfectionist' (a disguised-strength weakness) reads as rehearsed, and interviewers hear that particular answer constantly.

Know roughly what Hexaware does (IT services and consulting, with a strong presence in BPO and digital transformation work for enterprise clients), and be ready to say something specific about why the role you applied for interests you, not just why the company as a whole seems reputable. HR rounds routinely ask some version of 'why do you want to work here,' and a generic answer about company size or brand recognition reads noticeably weaker than one tied to the specific technology or team you'd be joining.

Trace it exactly like the machine would, line by line, keeping a running note of every variable's value in the margin rather than reading the code top to bottom and guessing. Candidate reports mention exactly this format for a Hexaware technical round: debug or predict the output of a small snippet, not write new code from scratch. The failure mode is skimming the code, forming an intuition about what it 'should' do, and then reverse engineering an explanation to match that intuition instead of actually tracing execution.

Say the trace out loud as you go. If there's an off by one error or an operator precedence trap (a common one in C-family snippets is assuming && and || have equal precedence when they don't), narrating each step is what surfaces it, not staring at the whole block at once.

This is a reported quirk of Hexaware's assessment tooling specifically, Python support has been inconsistent across problems in the same test session, forcing a switch to Java or C++ mid-round. The practical move is to keep your logic language agnostic in your head first, pseudocode the algorithm before committing to syntax, so a forced language switch costs you translation time, not thinking time.

Concretely: know how to write a basic loop, a hash map lookup, and a sort call in at least Java and one C-family language well enough to do it from memory, even if your daily job is entirely Python or JavaScript. The problems themselves are easy to moderate, so the actual risk isn't the algorithm, it's losing ten minutes to remembering Java's HashMap syntax under time pressure.

A client sends a SYN packet with an initial sequence number, the server responds with SYN-ACK (acknowledging the client's sequence number and sending its own), and the client responds with ACK confirming the server's sequence number. Only after this exchange do both sides start sending actual data.

Two steps wouldn't be enough because TCP is a full duplex protocol, both sides need to agree on both directions' initial sequence numbers, not just one. If it stopped after SYN-ACK, the server would have no confirmation that its own sequence number reached the client, and a delayed or duplicated SYN from a previous, already closed connection could get mistaken for a new connection request. The third ACK is what closes that ambiguity.

A trigger fires automatically inside the database whenever a specified event happens, an insert, update, or delete on a given table, without the application needing to remember to call it. A common real use: an audit_log table that automatically records who changed a row and when, fired by an AFTER UPDATE trigger on the source table, so the logging can't be skipped even if some application code path forgets to call a logging function.

The difference from an app level call after an insert is enforcement. A stored procedure called manually after an insert depends on every single code path that does inserts remembering to call it, a new microservice, an ad hoc data fix script, a different team's batch job. A trigger is enforced at the database level regardless of which application or script performed the insert, which is exactly why triggers matter for audit and compliance requirements and are riskier to lean on for ordinary business logic, since they're invisible from the application code reading it.

These come from 16 bit segmented memory architectures. A near pointer only addresses within the current segment (16 bits), a far pointer holds a segment plus offset (32 bits) letting it address outside the current segment but without automatically adjusting the segment part on overflow, and a huge pointer is also segment plus offset but normalizes the segment on pointer arithmetic so it doesn't wrap around incorrectly.

Practically, they're legacy DOS and early Windows memory model concepts and don't apply to any modern 32 or 64 bit flat memory system, where a pointer just addresses the full space directly. Hexaware asking this is testing whether your C fundamentals go back to first principles, not whether you'll ever write segmented memory code on the job. It's fair to say plainly that this is legacy knowledge if asked, rather than pretending it's still commonly used.

A self join joins a table to itself, treated as if it were two separate tables through table aliases, used when rows in a table have a relationship to other rows in that same table. The classic example is an employees table with a manager_id column that references another row's employee_id in the same table.

SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.employee_id;

LEFT JOIN here (not INNER JOIN) matters for the same reason it mattered above, a CEO or top level employee with no manager should still show up in the results with a NULL manager column, not get silently excluded from the report.

Draw from a group project, internship, or club setting rather than claiming you have no example at all. Structure the answer around what the disagreement actually was, what you specifically did (not what 'the team' did collectively), and what the outcome was, briefly. Interviewers evaluating fresh graduates aren't expecting a boardroom level conflict story, they're checking whether you can describe a real interpersonal situation concretely instead of answering in abstractions like 'I always try to communicate well.'