HCLTech Interview Questions (2026): Online Test, Technical & HR Rounds

20% of x = 80, so x = 80 / 0.2 = 400. Then 35% of 400 = 0.35 x 400 = 140.

Percentage problems at HCLTech are straightforward. The catch is candidates who try to compute these without setting up the base value first. Always find the base, then apply the second percentage.

Differences between terms: 4, 6, 8, 10, 12. The differences increase by 2 each time. So the next term is 30 + 12 = 42.

This is a second-difference series. HCLTech reasoning sections lean heavily on these. If the differences aren't constant, look at the differences of the differences before trying anything else.

A structure allocates separate memory for each member: total size is the sum of all member sizes (plus alignment padding). A union allocates shared memory: total size equals the size of its largest member, and all members share that same memory location. Writing to one member of a union overwrites all others.

When to use a union: situations where you need to store one of several types at a time and want to save memory. A common example is a type-tagged variant where a tag field tells you which union member is currently valid.

Pass by value: a copy of the argument is made. The function operates on the copy. Changes inside the function do not affect the original variable. Pass by reference (or pointer in C): the function receives the memory address of the original variable. Changes inside the function do affect the original.

In C, "pass by reference" is implemented by passing a pointer. In C++, actual reference parameters (using &) let you pass by reference without explicit pointer syntax. Java passes primitives by value and object references by value (the reference is copied, not the object).

Overloading: same method name, different parameter list (different number or types of parameters), in the same class. Resolved at compile time. This is compile-time (static) polymorphism.

Overriding: a child class provides its own implementation for a method already defined in the parent class. Same name, same parameter list. Resolved at runtime based on the actual object type. This is runtime (dynamic) polymorphism.

The question almost always appears in the technical MCQ section and then comes up again verbally in the technical interview. Know both the definition and an example for each.

A primary key uniquely identifies each row and cannot be NULL. A table can have only one primary key (though it can span multiple columns as a composite key). A unique key also enforces uniqueness but allows one NULL value (in most RDBMS implementations). A table can have multiple unique keys.

This exact comparison appears on PrepInsta's HCLTech section and came up in at least two on-campus candidate reports from the 2025 cycle. Know both the NULL behavior and the multiplicity rule.

DELETE removes rows one at a time, is a DML statement, gets logged row by row, can take a WHERE clause, and can be rolled back inside a transaction. TRUNCATE removes all rows in one operation, is a DDL statement, is minimally logged, cannot take a WHERE clause, and resets any auto-increment counter. DROP removes the table structure itself, including its schema, indexes, and data.

HCLTech pairs this MCQ with the primary-vs-unique-key question to check whether a candidate actually understands the DDL and DML split, not just the SQL keywords.

A process is an independent program in execution with its own memory space, file handles, and system resources. A thread is a lighter unit of execution that lives inside a process. Multiple threads in the same process share that process's memory (heap and global variables) but each thread keeps its own stack and program counter.

Because threads share memory, switching between them is cheaper than switching between processes, which requires swapping out an entire memory space. That cost difference is usually the follow-up question once you get the definitions right.

TCP is connection-oriented. It runs a handshake before any data moves, and it guarantees delivery and ordering through acknowledgments and retransmission. That reliability comes with overhead, so TCP is used where correctness matters more than speed: HTTP, file transfer, email.

UDP is connectionless. It sends packets without a handshake and without guaranteeing delivery or order, but it has far lower overhead. That makes it the right choice where speed matters more than guaranteed delivery: video streaming, DNS lookups, online gaming.

Encapsulation means bundling data (fields) and methods that operate on that data together inside a class, and controlling access to the data from outside. In Java, you implement it by declaring fields private and providing public getter and setter methods.

public class Employee {
    private String name;   // hidden from outside
    private double salary;

    // Controlled access through methods
    public String getName() {
        return name;
    }

    public void setName(String name) {
        // Can add validation here
        if (name != null && !name.isEmpty()) {
            this.name = name;
        }
    }

    public double getSalary() {
        return salary;
    }

    public void setSalary(double salary) {
        if (salary > 0) {
            this.salary = salary;
        }
    }
}

The point interviewers want you to make: encapsulation isn't just about getters and setters. It's about invariant protection. The setter validates before setting, which means the object's state stays consistent.

Stack: LIFO (Last In, First Out). Operations: push (add to top), pop (remove from top), peek (view top without removing). Real use: function call stack during program execution. When a function calls another, the new frame is pushed; when it returns, the frame is popped. Also: browser back button history, undo functionality in editors.

Queue: FIFO (First In, First Out). Operations: enqueue (add to rear), dequeue (remove from front). Real use: print job queue (first job submitted prints first), CPU scheduling ready queue, message queues in distributed systems like RabbitMQ or Kafka.

A palindrome reads the same forward and backward. Two-pointer approach: compare characters from opposite ends, moving inward until they meet. If any pair doesn't match, it is not a palindrome.

def is_palindrome(s):
    # Normalize: lowercase, remove spaces for real-word palindromes
    s = s.lower().replace(" ", "")
    left, right = 0, len(s) - 1

    while left < right:
        if s[left] != s[right]:
            return False
        left += 1
        right -= 1

    return True

print(is_palindrome("racecar"))   # True
print(is_palindrome("hello"))     # False
print(is_palindrome("A man a plan a canal Panama"))  # True

This is one of the most common coding questions asked on paper or whiteboard during HCLTech's technical round. The interviewer often follows up: "What if the string has spaces and mixed case?" Handle it in your initial normalization step, as shown above.

The four standard pillars: Encapsulation (data hiding + bundling), Abstraction (hiding implementation details, exposing only what's needed), Inheritance (child class acquires properties and behaviors of parent), Polymorphism (one interface, many implementations).

The "five pillars" version some HCLTech interviewers use adds Association (objects using other objects, including aggregation and composition). The on-campus GET interview from the 2025 GeeksforGeeks experience specifically asked for "five pillars of OOP." If your interviewer says five, add Association as the fifth.

Inheritance lets a child class acquire the properties and methods of a parent class, promoting code reuse. Types:

• Single inheritance: one child, one parent. Supported in Java (classes).
• Multilevel inheritance: A extends B, B extends C. Supported in Java.
• Hierarchical inheritance: multiple children from one parent. Supported in Java.
• Multiple inheritance: one child from multiple parents. Not supported in Java for classes (to avoid the diamond problem), but supported through interfaces.
• Hybrid inheritance: combination of the above. Java supports it through interfaces.

Know why Java doesn't support multiple inheritance for classes: if two parent classes both define the same method, the child class wouldn't know which to inherit. This is the diamond problem.

A JOIN combines rows from two or more tables based on a related column (usually a foreign key relationship).

• INNER JOIN: returns only rows where there is a match in both tables.
• LEFT JOIN (LEFT OUTER JOIN): returns all rows from the left table, plus matched rows from the right. Unmatched right rows are NULL.
• RIGHT JOIN (RIGHT OUTER JOIN): opposite of LEFT JOIN.
• FULL OUTER JOIN: returns all rows from both tables, with NULLs where there is no match.
• CROSS JOIN: returns the Cartesian product of both tables (every combination of rows).

HCLTech SQL questions in the technical round consistently include JOIN types. Know INNER and LEFT JOIN cold, with a one-sentence example for each.

The HR interviewer has already seen your resume. Don't recite it back. Give: a two-sentence academic summary, one project or experience that shows initiative or problem-solving, one thing you want to learn or build at HCLTech specifically, and one personal fact that makes you distinct. Total: 60-90 seconds.

The mistake most freshers make: going into too much technical depth in the HR round. The HR interviewer is not the audience for your database schema explanation. They want to meet you as a person who can communicate professionally.

Avoid: "because HCLTech is a great company with many opportunities." This is the answer 80% of candidates give and it lands nowhere. HCLTech operates across a wide range of technology services including cloud, AI, IoT, and engineering services for clients in 60 countries. Pick one business area that connects to your background.

A version that works: "My project involved building a REST API for IoT sensor data. HCLTech's Engineering and R&D services division does exactly this kind of embedded systems and IoT work at scale for manufacturing clients, which is the domain I want to go deeper in." The specificity shows you actually looked at the company, not just the job posting.

Be honest. HCLTech places GET hires pan-India, including at New Vistas locations (Lucknow, Nagpur, Vijayawada, Madurai) and at major tech hubs (Chennai, Bangalore, Pune, Hyderabad, Noida). The New Vistas and non-metro postings carry a lower CTC (Rs. 3.75 LPA vs Rs. 4.50 LPA).

If you have a genuine constraint, name it calmly and explain your flexibility around it. A clear "I'm flexible across all locations" gets noted positively. The HR interviewer is logging this for onboarding logistics. An honest "I prefer South India but can manage other locations" is better than an overpromise that causes problems at joining.

Claiming you never feel pressure isn't credible and interviewers know it. A better structure: name one real deadline crunch (exam week colliding with a project submission is common and fine to use), state what you cut versus what you protected, and name the actual outcome.

A version that works: "During my final semester, a project submission landed the same week as two backlog exams. I listed every remaining task, dropped the parts of the project that weren't core to the evaluation, and split my study time by exam weight rather than evenly. The project came in with a working core feature set, and I cleared both exams." Specific tradeoffs beat a general claim of staying calm under pressure.

For strengths: pick one and give a concrete example, not an adjective list. "I'm a quick learner" without evidence is a dead answer. "During my project, I had to pick up Docker in three days for deployment. I did it by focusing on just the three commands I needed first and expanding from there" is a strength with evidence.

For weaknesses: pick a real developmental area that isn't core to the job, and name what you're doing about it. "I used to spend too much time on edge cases before shipping anything. I've been timeboxing my initial builds to two hours before reviewing" is the kind of specific, credible answer that works.

Pick a direction: technical track or project lead track. Name a specific skill or domain you want to develop. Connect it to what HCLTech's work would let you learn. Avoid "I want to be a manager" with no pathway, and avoid "I'll see how things go" entirely.

A version that lands: "In three years, I want to have built solid hands-on experience in cloud infrastructure work, ideally in HCLTech's digital transformation projects. After that, I'd want to start leading a small technical workstream. HCLTech's scale means I'd be working with real enterprise environments earlier than most places would give a fresher access to."

HCLTech's GET programme requires a 12-month service agreement from the date of joining. Leaving before the period ends has financial consequences. The HR round is where they confirm your agreement. If you've accepted the offer, say yes clearly and without hesitation. This is not the moment to negotiate terms.

If you have a concern about the bond period, the right time to raise it is before you accept the offer, not in the HR round. A last-minute hesitation in the HR round creates doubt about your intent to join and can affect your offer status.

Always have one or two. Interviewers who don't get a question here often mark it as low interest. Good questions that work at HCLTech HR: "What does the initial project allocation process look like for GET hires?" or "What technology areas are most of the current GET hiring going into?" Bad questions: "What's the salary?" (you know the CTC already) or "What are the growth opportunities?" (too generic).

The Graduate Engineer Trainee (GET) programme is HCLTech's primary fresher hiring track for engineering and science graduates. Eligibility for the 2026 intake: BE/BTech/MCA/MSc from CSE, IT, ECE, EEE, or EI streams; minimum 60% aggregate across 10th, 12th, and graduation (some specific drives specify 70-75%); no active backlogs at the time of the assessment. Graduation year must be within the last 1-2 years depending on the specific drive.

Two CTC slabs for the 2026 GET intake: Rs. 3.75 LPA for postings at HCLTech New Vistas locations (Lucknow, Nagpur, Vijayawada, Madurai) and Rs. 4.50 LPA for all other locations (Chennai, Bangalore, Hyderabad, Pune, Noida, and so on). A 12-month service agreement applies. These figures come from the 2026 hiring cycle job postings verified through fresherjobinfo.in and careerstn.com.

Typically two: Technical Interview and HR Interview. Some campus drives add an HR Screening round between the online assessment and the technical interview, primarily for document verification. That is not a full interview round: it is a paperwork check. So most candidates face either 2 or 3 rounds total after the online assessment, with 2 being the more common structure in the 2025-2026 cycle.

No. The HCLTech online assessment has no negative marking, verified across PrepInsta's HCLTech section and the knoffcampusjobs.com exam pattern guide for 2025. Attempt every question. For the technical MCQ section especially, a reasoned guess on a question you're unsure about is always better than skipping it.

Python is the safest choice for most candidates: the syntax is compact, the standard library handles most string operations in a few lines, and the problems (mostly string manipulation and arrays) map naturally to Python idioms. Java works well too if you're more comfortable with it. The section supports C, Java, and Python. C requires more lines of code for the same logic, which is a time disadvantage in a 20-minute window. Whichever you choose, practice timed coding in that language specifically before the assessment.

No. TechBee is a separate early career programme by HCLTech aimed at Class 12 students (not engineering graduates). TechBee candidates join a 12-month integrated learning programme with a stipend of around Rs. 10,000/month, then convert to a full-time role at Rs. 1.70-2.20 LPA while pursuing higher education (BITS Pilani, IIM Nagpur, and others) in parallel. If you have a BTech degree, you are not in the TechBee pipeline. You should apply through the GET route on HCLTech's careers page or through your institution's placement cell.

Combined rate of A and B = 1/12 + 1/15 = 5/60 + 4/60 = 9/60 = 3/20 per day. Work done in 4 days together = 4 x 3/20 = 12/20 = 3/5. Remaining work = 1 - 3/5 = 2/5. B alone completes 1/15 per day, so time for B to finish 2/5 = (2/5) / (1/15) = (2/5) x 15 = 6 days.

Time-work problems appear in almost every HCLTech aptitude section. The approach is always the same: convert individual rates to fractions of total work per day, add for combined rate, compute work done, and solve for the remainder.

Total ways to pick any 2 balls from 10 = C(10,2) = 45. Ways to pick 2 red balls from the 4 available = C(4,2) = 6. Probability = 6/45 = 2/15.

Probability shows up less often than time-work or percentages in HCLTech's aptitude section, but it is not rare enough to skip. Get comfortable with combinations (nCr) before the test. Most probability questions here reduce to favorable outcomes over total outcomes once you set up the combination correctly.

In C, the order of evaluation of function arguments is unspecified (implementation-defined). Most compilers evaluate right-to-left, making ++x run first (x becomes 6, printed as 6), then x++ (x is 6 at time of evaluation, printed as 6, then becomes 7). So the output on most compilers is: 6 6. However, the correct academic answer is "undefined/unspecified behavior" because modifying and reading a variable between sequence points in the same expression is undefined in C standards before C11.

HCLTech MCQs include these output-prediction questions specifically to see if you know the difference between defined and undefined behavior. "Undefined behavior" is a legitimate and often expected answer on such questions.

Yes, a constructor can be private. The main use case is the Singleton design pattern, where you want exactly one instance of a class. By making the constructor private, external code cannot call new directly. The class exposes a static method (usually getInstance()) that controls instantiation and returns the single existing instance.

public class DatabaseConnection {
    // Single instance held statically
    private static DatabaseConnection instance;

    // Private constructor prevents direct instantiation
    private DatabaseConnection() {
        System.out.println("Connection created");
    }

    // Public factory method controls access
    public static DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }
}

HCLTech technical MCQs and technical interviewers both ask this. Design patterns come up more at HCLTech than at TCS or Infosys for freshers, particularly Singleton and Factory.

Operator overloading lets you redefine what an operator like + or == does when applied to objects of a user-defined type. C++ supports this directly: you can write an operator+ function for a custom Vector or Complex class so that v1 + v2 adds them the way you define.

Java does not support operator overloading for custom types. The one built-in exception is the + operator on String, which Java itself overloads for concatenation, not something a developer can extend to a new class. HCLTech MCQs use this specifically to catch candidates who assume C++ and Java behave the same way here.

This problem was reported by multiple candidates across PrepInsta's HCLTech experience section. The clean approach: count the hashes, then build the output string as the hashes followed by all non-hash characters in original order.

def move_hash_to_front(s):
    hash_count = s.count('#')
    non_hash = [c for c in s if c != '#']
    return '#' * hash_count + ''.join(non_hash)

# Example
print(move_hash_to_front("Move#Hash#to#Front"))
# Output: ###MoveHashtoFront

The two-pass approach (count first, then build) is cleaner and easier to reason about under time pressure than an in-place swap approach. For 20-minute coding windows, clarity beats cleverness.

Run-length encoding. Walk through the string, track the current character and its count, and build output as you go. A character that appears once in a row: some HCLTech variants omit the count for singletons (a instead of a1); others include it. Read the problem statement carefully on exam day.

public class StringCompress {
    public static String compress(String s) {
        if (s == null || s.isEmpty()) return s;

        StringBuilder result = new StringBuilder();
        int count = 1;

        for (int i = 1; i <= s.length(); i++) {
            if (i < s.length() && s.charAt(i) == s.charAt(i - 1)) {
                count++;
            } else {
                result.append(s.charAt(i - 1));
                if (count > 1) result.append(count);
                count = 1;
            }
        }
        return result.toString();
    }

    public static void main(String[] args) {
        System.out.println(compress("abbccccc"));     // ab2c5
        System.out.println(compress("aabbbbeeeeffggg")); // a2b4e4f2g3
    }
}

Classic stack problem. Push open brackets onto the stack. When you see a closing bracket, check whether the top of the stack is the matching open bracket. If it is, pop. If not, the string is invalid. At the end, the stack should be empty.

def is_valid_brackets(s):
    stack = []
    matching = {')': '(', '}': '{', ']': '['}

    for ch in s:
        if ch in '({[':
            stack.append(ch)
        elif ch in ')}]':
            if not stack or stack[-1] != matching[ch]:
                return False
            stack.pop()

    return len(stack) == 0

# Tests
print(is_valid_brackets("()[]{}"))   # True
print(is_valid_brackets("([)]"))     # False
print(is_valid_brackets("{[]}"))     # True

Reported in HCLTech assessments via Unstop and PrepInsta candidate logs from the 2025 cycle. The edge case interviewers check: an empty string (returns True), a single bracket, and interleaved types like ([)].

Two passes solve this cleanly within a 20-minute window. First pass: count how many times each character appears using a hash map. Second pass: walk the string in order and return the first character whose count is exactly 1.

def first_unique_char(s):
    counts = {}
    for ch in s:
        counts[ch] = counts.get(ch, 0) + 1

    for ch in s:
        if counts[ch] == 1:
            return ch
    return None

print(first_unique_char("swiss"))       # w
print(first_unique_char("aabbcc"))      # None
print(first_unique_char("leetcode"))    # l

This fits the string-manipulation pattern that dominates HCLTech's coding section. A single hash map pass to build counts, then a second pass to check them, runs in O(n) time, which beats a nested-loop approach that recomputes counts for every character.

In Java: an abstract class can have concrete and abstract methods, constructors, instance variables, and supports single inheritance. An interface (pre-Java 8) had only abstract methods and constants; from Java 8, interfaces can have default and static methods; from Java 9, private methods too.

When to use which: use an abstract class when related classes share common state or behavior that you want to inherit. Use an interface to define a contract that unrelated classes can implement. The Comparable interface (for sorting) and Serializable (for serialization) are real examples where the classes implementing them share no common parent class beyond Object.

This question came up in the on-campus GeeksforGeeks interview experience for HCLTech GET (2025). The correct answer goes beyond just "abstract class has implementations, interface doesn't" since Java 8 changed that.

Singleton ensures a class has exactly one instance throughout the application's lifetime and provides a global access point to it. Use cases: database connection pool, logging service, configuration manager.

HCLTech freshers are asked this more often than candidates from other MNCs report. The pattern came up in multiple interview experiences across the 2024-2025 cycle. See the code in the technical MCQ section above for the implementation.

Polymorphism means one interface, many implementations: the same method call behaves differently depending on the actual object type at runtime. This is the pillar interviewers most often ask candidates to demonstrate in code rather than just define, since the definition alone doesn't show whether you understand method resolution.

class Animal {
    public void makeSound() {
        System.out.println("Some generic animal sound");
    }
}

class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Bark");
    }
}

class Cat extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Meow");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal[] animals = { new Dog(), new Cat() };
        for (Animal a : animals) {
            a.makeSound();   // Bark, then Meow
        }
    }
}

The array is typed as Animal, but each object calls its own overridden version of makeSound() at runtime. That's runtime polymorphism, and it's the exact follow-up HCLTech interviewers ask right after a candidate recites the four pillars from memory: "okay, show me."

Normalization is the process of organizing a database to reduce data redundancy and improve data integrity by decomposing tables into smaller, well-structured ones.

• 1NF (First Normal Form): each column holds atomic (indivisible) values, no repeating groups, and each row is unique.
• 2NF (Second Normal Form): satisfies 1NF, plus every non-key attribute is fully functionally dependent on the entire primary key (no partial dependency). This matters only when the primary key is composite.
• 3NF (Third Normal Form): satisfies 2NF, plus no transitive dependency: non-key attributes depend only on the primary key, not on other non-key attributes.

The standard bank transfer example works for ACID (see the next question). For normalization, use an orders table: if you store customer_city alongside customer_id in an orders table, customer_city depends on customer_id (not on the order), which creates a transitive dependency in violation of 3NF.

Atomicity: every operation in a transaction succeeds, or none of them do. Consistency: a transaction takes the database from one valid state to another without violating constraints. Isolation: concurrent transactions don't see each other's uncommitted changes, so the end result looks as if the transactions ran one after another. Durability: once a transaction commits, the change survives even if the system crashes immediately after.

The bank transfer example makes all four concrete at once. Debiting account A and crediting account B must both happen or neither happens (atomicity). The total money in the system before and after must match (consistency). Two transfers touching the same account at the same time can't corrupt each other's balance (isolation). Once the transfer is confirmed, it holds even through a crash a second later (durability).

HCLTech interviewers ask this right after normalization, using the same bank transfer scenario, to check whether a candidate can apply the concept to a scenario rather than just list the four letters.

A deadlock occurs when two or more transactions are each waiting for a lock held by the other, so none can proceed. Classic example: Transaction A holds a lock on Table 1 and requests a lock on Table 2; Transaction B holds a lock on Table 2 and requests a lock on Table 1. Both wait forever.

Prevention strategies: lock ordering (always acquire locks in the same sequence), timeout (abort transactions that wait too long), deadlock detection (detect cycles in the wait-for graph and roll back one transaction). Most production RDBMS systems use a combination of timeout and detection.

This question appeared in the HCLTech technical round documented on hitbullseye.com and is consistent with what on-campus candidates have reported for the 2025 cycle.

Three common approaches. The subquery approach is the one most interviewers accept and can follow without a deep SQL background:

-- Approach 1: subquery (works in all SQL dialects)
SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

-- Approach 2: LIMIT with DISTINCT (MySQL, PostgreSQL)
SELECT DISTINCT salary
FROM employees
ORDER BY salary DESC
LIMIT 1 OFFSET 1;

-- Approach 3: window function (SQL Server, PostgreSQL, MySQL 8+)
SELECT salary AS second_highest
FROM (
    SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
    FROM employees
) ranked
WHERE rnk = 2
LIMIT 1;

The DENSE_RANK approach handles ties correctly: if two employees share the top salary, DENSE_RANK still gives rank 2 to the next distinct value. Know which approach your interviewer can follow, and explain the trade-off between them.

Don't summarize the abstract from your project report. The interviewer wants: what problem you solved, what stack you used, what you specifically built (not what the team built), and one technical challenge you hit.

What HCLTech interviewers do: they let you speak for two minutes, then pick one specific term you used and ask "what is that exactly?" If you mention REST API, they'll ask about HTTP methods. If you mention MongoDB, they'll ask why you chose it over a relational DB. If you say React, they'll ask about virtual DOM or component lifecycle. Prepare your project the same way you'd prepare for a quiz: for every technology you mention, know one follow-up question and its answer.

Hoisting is JavaScript's default behavior of moving variable and function declarations to the top of their scope before code execution. Function declarations are hoisted completely (both the declaration and definition). var declarations are hoisted but not initialized (value is undefined until the assignment line runs). let and const are hoisted but not initialized and accessing them before declaration throws a ReferenceError (the temporal dead zone).

This came up verbatim in the on-campus HCLTech GET interview experience posted on GeeksforGeeks (2025). Candidates with web/JS projects should know hoisting, closures, and the event loop at a conceptual level.

Use a real situation, preferably from your final year project or college team. The structure that works: briefly state the disagreement, describe the specific action you took (not "we talked it out" but "I asked to meet separately after class to understand their concern"), state what changed, and what you learned.

The interviewer isn't looking for a story where you were 100% right. They want to see that you addressed the conflict directly rather than avoiding it, and that you came out with the relationship intact. Answers where the conflict "just resolved itself" are the ones that don't land.

A hash table maps a key to a bucket index using a hash function, and collisions happen when two different keys land on the same bucket. The two standard fixes are chaining, where each bucket holds a linked list (or small tree, as Java's HashMap does once a bucket exceeds 8 entries) of all colliding entries, and open addressing, where a colliding key is placed in the next available slot using a probing sequence like linear, quadratic, or double hashing. Chaining degrades more gracefully under load but costs extra memory for pointers; open addressing is more cache friendly but performance collapses once the table gets close to full, so implementations resize well before that.

Degradation to O(n) usually traces back to one of three causes: a poor hash function that clusters keys into a small number of buckets, a load factor that's crept past the resize threshold because the initial capacity was never sized for the expected data volume, or, in Java specifically, keys whose hashCode() is broken or inconsistent with equals(), which defeats bucket distribution entirely. To diagnose it in production I'd instrument bucket occupancy (many hash map implementations expose this, or you can reflectively inspect it in a heap dump), check for a spike in average chain length, and look at whether one particular key type dominates the map. The fix is almost always either a better hash function, pre-sizing the map with the expected capacity, or switching to a structure like a TreeMap if the access pattern needs ordering guarantees a hash table can't give you anyway.

The JVM heap is split into a young generation (further divided into Eden and two survivor spaces) and an old generation. Most objects die young, so new allocations go into Eden, and a minor GC copies surviving objects between the survivor spaces, incrementing an age counter on each object. Once an object survives enough minor collections it gets promoted to the old generation, which is collected less frequently by a major or full GC because scanning it is more expensive. This generational split exists purely because empirical data shows object lifetimes are bimodal: either very short-lived or long-lived, so it's wasteful to scan the whole heap every time.

A memory leak in Java doesn't mean unreachable memory that never gets freed, it means memory that's still reachable but no longer actually needed by the application, so the GC correctly leaves it alone. Classic causes: static collections that keep growing (a static Map used as a cache with no eviction policy), listener or callback registrations that are never deregistered, ThreadLocal values that outlive the logical operation they were scoped to (very common in thread-pooled web servers where the thread itself never dies), and inner classes holding an implicit reference to their outer class after the outer object should have been discarded. To find one, I'd take a heap dump under load with jmap or trigger one via -XX:+HeapDumpOnOutOfMemoryError, then open it in Eclipse MAT and look at the dominator tree for the object that's retaining the most memory through its reference chain, not just what has the largest instance count.

A B-tree index stores the indexed column's values in sorted order across a balanced tree of fixed-size pages, with each internal node holding pointers to child pages covering a range of values, and the leaf nodes holding either the actual row (a clustered index) or a pointer back to the row's location (a non-clustered index). Because the tree is balanced and each node fans out to many children, a lookup on a table with millions of rows only needs a handful of page reads to walk from root to leaf, which is why an indexed WHERE clause turns an O(n) table scan into something close to O(log n). Range queries and ORDER BY on the indexed column are cheap for the same reason: adjacent leaf pages are linked, so the engine can walk sideways through the sorted leaves instead of re-scanning.

Indexes stop paying off in a few concrete situations. If a column has low cardinality, like a boolean or a status flag with three values, the optimizer often correctly decides a full table scan is cheaper than jumping between an index and the table (a "bookmark lookup") for a large fraction of rows, so it ignores the index anyway. Every additional index also adds write overhead, because an INSERT, UPDATE, or DELETE has to update every index on that table, not just the table itself, so tables with heavy write volume and many indexes can see write latency climb noticeably. And a composite index only helps a query if it uses a leftmost prefix of the indexed columns in the right order, and if it's used with a function or type coercion on the column, like WHERE YEAR(created_at) = 2026 instead of a direct range comparison, the engine usually can't use the index at all and falls back to a scan. Before adding an index, the right move is to run EXPLAIN or EXPLAIN ANALYZE and confirm the planner actually picks it up and the estimated row count matches reality.

First step is reproducing or at least capturing the state at the moment it happens, because deadlocks are timing-dependent and rarely reproducible on demand. In Java I'd take a thread dump (jstack, or a heap+thread dump via kill -3 on the process) right when the app hangs; the JVM's own deadlock detector will usually print "Found one Java-level deadlock" along with the two threads, the locks each one holds, and the lock each one is waiting for. From there you trace back through the code to find the two lock acquisition orders: thread A grabs lock1 then waits on lock2, while thread B has already grabbed lock2 and is waiting on lock1. That circular wait, combined with mutual exclusion, hold-and-wait, and no preemption, is the textbook Coffman conditions for deadlock, and breaking any one of the four prevents it.

In practice the fix that's easiest to enforce across a codebase is breaking hold-and-wait or circular-wait by imposing a strict, global lock ordering: if every code path that needs both lock1 and lock2 always acquires them in the same order (say, always by object ID or always alphabetically by lock name), a circular wait becomes structurally impossible. Where a fixed order isn't practical, using tryLock with a timeout instead of a blocking acquire lets a thread back off, release what it's holding, and retry rather than wait forever, though that trades deadlock for the possibility of livelock if not tuned carefully. I'd also flag this in code review going forward: any method that acquires more than one lock is a deadlock candidate and needs its acquisition order documented, not just left to whoever wrote it that day.