Wipro Interview Questions (2026): NLTH, Technical & HR Rounds

Let the marked price be M. After 20% discount: M x 0.80 = 480. So M = 480 / 0.80 = Rs. 600.

Percentage problems in the NLTH often layer two steps: discount on marked price, then profit on cost price, or some combination. The mistake most candidates make is confusing marked price with cost price. Read the question slowly even when time-pressed. A 10-second re-read is faster than re-doing a wrong answer.

Speed = distance / time = 150 / 15 = 10 meters per second. Convert to km/hr by multiplying by 18/5: 10 x 18/5 = 36 km/hr.

The conversion factor is where this question actually gets tested, not the division. Candidates who compute 10 m/s correctly sometimes leave it there instead of converting, and lose the mark on a question they'd otherwise gotten right. Memorize both directions: multiply by 18/5 to go from m/s to km/hr, multiply by 5/18 to go the other way.

Subject-verb agreement slips, tense shifting mid-paragraph, and run-on sentences without proper punctuation account for more lost marks in low-scoring WCT essays than any single grammar rule Wipro tests separately in the verbal section.

Tense drift is the one candidates don't notice while writing. An essay opens in present tense ("Technology changes how we work") and slides into past tense by the second paragraph with no reason to shift. Pick one tense for your core argument and hold it, switching only when you're referencing something historical. Reading your own essay back once before submitting catches most of this, and it takes under a minute even with the clock running.

Use a set to track elements seen so far. For each element, check if (target - element) is already in the set. If yes, you found a pair.

def find_pairs(arr, target):
    seen = set()
    pairs = []

    for num in arr:
        complement = target - num
        if complement in seen:
            pairs.append((complement, num))
        seen.add(num)

    return pairs

# Example
arr = [2, 7, 4, 1, 3, 6]
target = 8
print(find_pairs(arr, target))  # For this input: [(1, 7), (2, 6)]

The two-pointer approach works when the array is sorted and you need all pairs without duplicates. The set-based approach handles unsorted arrays in O(n) time. For Wipro's online compiler, test your solution with edge cases like an empty array and a single-element array before submitting.

Compare the string with its reverse, or use two pointers from both ends, moving inward until they cross.

public class Palindrome {
    public static boolean isPalindrome(String s) {
        int left = 0;
        int right = s.length() - 1;

        while (left < right) {
            if (s.charAt(left) != s.charAt(right)) {
                return false;
            }
            left++;
            right--;
        }
        return true;
    }

    public static void main(String[] args) {
        System.out.println(isPalindrome("racecar")); // true
        System.out.println(isPalindrome("wipro"));   // false
    }
}

This is a consistent Wipro coding round problem. The two-pointer approach avoids creating a reversed copy of the string, which matters when you're asked about space complexity. Know both approaches and be ready to state the time and space complexity of each.

One pass: track the largest and second largest simultaneously. Update second largest whenever you find a new largest, or when you find something bigger than the current second-largest but smaller than the largest.

def second_largest(arr):
    if len(arr) < 2:
        return None

    first = second = float('-inf')

    for num in arr:
        if num > first:
            second = first
            first = num
        elif num > second and num != first:
            second = num

    return second if second != float('-inf') else None

print(second_largest([12, 35, 1, 10, 34, 1]))  # Output: 34

The num != first check handles arrays with duplicate maximum values. A candidate who submits a sorting-based approach (O(n log n)) will still get test cases right, but an interviewer watching the coding round may ask about optimization. Know the O(n) version.

An Armstrong number equals the sum of its own digits, each raised to the power of the total digit count. 371 is a classic example: 3^3 + 7^3 + 1^3 = 27 + 343 + 1 = 371.

public class ArmstrongCheck {
    public static boolean isArmstrong(int num) {
        int digitCount = String.valueOf(num).length();
        int original = num;
        int sum = 0;

        while (num > 0) {
            int digit = num % 10;
            sum += Math.pow(digit, digitCount);
            num /= 10;
        }

        return sum == original;
    }

    public static void main(String[] args) {
        System.out.println(isArmstrong(371)); // true
        System.out.println(isArmstrong(200)); // false
    }
}

The mistake candidates make under time pressure is hardcoding the power as 3, since 3-digit examples are what everyone practices with. Compute digitCount from the actual number so the same function still works if the test case is a 4-digit or 6-digit input.

A recursive factorial function calls itself with a smaller input each time until it hits the base case (0! = 1), then multiplies the results back up the call stack as each call returns.

#include <stdio.h>

int factorial(int n) {
    if (n == 0) {
        return 1;
    }
    return n * factorial(n - 1);
}

int main() {
    int num = 5;
    printf("Factorial of %d is %d\n", num, factorial(num));
    return 0;
}

Interviewers sometimes ask for the iterative version right after, and whether recursion has any downside here. It does: each call adds a stack frame, so a large enough input risks a stack overflow, well beyond anything the NLTH would actually test. A simple loop avoids that entirely and uses constant space.

Encapsulation: bundling data and methods in a class and restricting direct access to internal state. Abstraction: showing only what's necessary, hiding implementation details behind a public interface. Inheritance: a child class acquires properties and methods from a parent class. Polymorphism: one method or interface behaves differently based on the object or arguments at runtime or compile time.

Wipro interviewers typically ask this first and then pick one pillar to go deeper on. Encapsulation and polymorphism get the most follow-up questions. Prepare a concrete real-world example for each, not just a definition.

Overloading: same method name in the same class, different parameter types or counts. Resolved at compile time. Example: a Calculator class with add(int a, int b) and add(double a, double b).

Overriding: a child class redefines a method inherited from the parent with the same signature. Resolved at runtime through dynamic dispatch. Example: Animal has a speak() method; Dog overrides speak() to return "Woof" instead of the parent's generic response.

The distinction Wipro interviewers specifically test: compile-time vs. runtime resolution. Get that detail in your answer explicitly.

A constructor initializes an object when the new keyword creates it. Same name as the class, no return type, not even void.

Yes, a constructor can be private. This is the Singleton design pattern: a private constructor prevents external code from creating instances directly. The class exposes a static method (getInstance()) that returns the single instance, creating it the first time and returning the existing one on subsequent calls.

public class Singleton {
    private static Singleton instance = null;

    // Private constructor
    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Wipro Technical panels occasionally ask about design patterns. Singleton is the one most commonly mentioned in fresher rounds. If you know it, bring it up here. If not, a clean answer about what private constructors prevent is sufficient.

Exception handling separates error-recovery code from the normal flow of a program so a runtime problem doesn't crash the whole application. The try block wraps code that might fail. The catch block catches a specific exception type and handles it. The finally block runs regardless of whether an exception was thrown, which makes it the natural place to close a file or a database connection.

try {
    int result = 10 / 0;
} catch (ArithmeticException e) {
    System.out.println("Cannot divide by zero: " + e.getMessage());
} finally {
    System.out.println("This runs no matter what.");
}

A follow-up Wipro interviewers sometimes ask: does finally still run if the try block has a return statement? Yes, it runs before the method actually hands control back, with one exception. A System.exit() call inside try skips finally entirely.

== compares references for objects, meaning it checks whether two variables point to the same memory location, and compares actual values for primitives. .equals() compares content and can be overridden to define what "equal" means for a custom class.

The classic gotcha: two String objects created with new String("wipro") fail an == check even with identical content, because they're separate objects in memory. Two string literals often pass == because Java's string pool reuses the same literal instead of creating a new object each time. That inconsistency is exactly why this question keeps getting asked. Default to .equals() for content comparison and save == for reference checks or primitives.

Arrays: fixed size (usually), contiguous memory, O(1) random access by index, O(n) insertion/deletion in the middle (because elements shift).

Linked lists: dynamic size, non-contiguous memory (nodes connected by pointers), O(n) access by index (traverse from head), O(1) insertion/deletion at a known node (just rewire pointers).

When to prefer which: array when you need fast access by index and size is predictable; linked list when you insert/delete frequently and don't need random access. Wipro panels often ask this with a follow-up: "which would you use to implement a queue?" The answer: linked list is cleaner for queue implementation when you don't know the max size in advance.

Primary key: uniquely identifies each row; cannot be NULL; only one per table. It creates a clustered index by default in most RDBMS.

Unique key: also enforces uniqueness, but allows NULL (one NULL per column in most databases); a table can have multiple unique keys. Use unique key when you need to enforce uniqueness on a non-primary column, like an email address in a users table.

DELETE removes rows one at a time and accepts a WHERE clause, so you control exactly which rows go. It logs each row individually, which means it can be rolled back, and it runs slower on a large table because of that logging. TRUNCATE clears every row in one operation, barely touches the log, and resets any auto-increment column, making it far faster, but it won't take a WHERE clause. DROP goes further still and removes the table itself: schema, indexes, constraints, and data together.

Wipro panels sometimes frame this as a scenario instead of asking for definitions directly: "you need to clear test data from a table before a deployment but keep the table structure and any triggers on it." The answer is TRUNCATE only if you don't need WHERE and don't need row-level triggers to fire. Otherwise it's DELETE, even though it's the slower option.

TCP (Transmission Control Protocol): connection-oriented. Establishes a three-way handshake before data transfer. Guarantees delivery, ordering, and error checking. Slower due to overhead. Used for HTTP, email, file transfer.

UDP (User Datagram Protocol): connectionless. No handshake. No delivery guarantee or ordering. Faster because no acknowledgment cycle. Used for video streaming, DNS, VoIP, online gaming where speed matters more than perfect delivery.

Virtual memory extends the apparent amount of available RAM by using disk storage as an overflow area. The OS uses paging to move inactive memory pages to disk (swap space) and bring them back when needed.

Why it matters: programs can use more memory than physically installed RAM. Multiple programs can run simultaneously without each needing to fit entirely in physical memory. The application programmer works with virtual addresses; the OS and MMU (Memory Management Unit) translate to physical addresses transparently.

The tradeoff: page faults, where a program accesses a page that was swapped to disk, cause noticeable slowdowns. Heavy use of virtual memory (thrashing) can make a system nearly unresponsive.

Keep this to 90 seconds. Cover three things: your academic background (brief, one sentence), a project or internship where you built something real (two sentences, specific), and why you're interested in IT services as a career at this point. Don't recite your resume. The interviewer has it in front of them.

One thing that works: end with a sentence that connects your background to Wipro specifically. "I focused on database work in my project, and Wipro's work in enterprise data and cloud transformation is the kind of environment I want to develop in." Specific beats generic in every HR room.

Avoid: "because Wipro is a great company with many opportunities." Every HR interviewer has heard that answer 40 times today.

Wipro-specific facts you can reference: Wipro serves over 200 of the Fortune 500 companies in 2025. It operates across cloud, cybersecurity, AI/ML, and engineering services. Wipro has an active ESG commitment, including a goal of reaching net-zero emissions by 2040. Wipro's learning and development programs (Wipro Academy of Software Excellence, or WASE, for eligible candidates) are actual differentiators worth mentioning.

Connect one of those to your background. "I'm interested in Wipro's cloud services practice because my final year project involved AWS deployment" beats any generic answer.

Name one concrete thing from your background that maps directly to what the role needs. "I'm hardworking and a team player" tells the interviewer nothing they haven't heard from a dozen other candidates that same week.

A structure that works better: pick one specific project outcome, connect it to something Wipro actually does, and close with a real reason you want the role. "I built and debugged a full REST API for my final year project, including the database layer, which is close to the kind of work Wipro's engineering teams handle for enterprise clients. I'd rather start contributing to real project work than spend a long ramp-up figuring out the basics." A specific claim is harder to wave off, and it's also easier for you to defend if the interviewer asks a follow-up question about it.

Be honest. Wipro places freshers across centers in Bengaluru, Hyderabad, Pune, Chennai, and several other cities depending on project needs. Many projects serving US or European clients run on IST evenings and nights to align with client working hours.

If you can commit, say so clearly. If you have a genuine constraint, state it calmly and briefly without over-explaining. A calm "I can manage rotational shifts; I'd prefer Bengaluru or Pune but I'm open to other locations" is more trusted than a blanket "anywhere, anytime" that reads as desperation.

For strengths: name one, support it with a specific example from your project or academics. "I'm a fast learner" is too generic. "I picked up Selenium for our testing phase in about a week with no prior experience" is specific and verifiable.

For weaknesses: don't say "I work too hard" or "I'm a perfectionist." Name an actual developmental area that isn't critical for the role, and name the specific step you're taking to address it. "I used to struggle with explaining technical concepts to non-technical teammates. I've been working on this by writing short summaries of our technical decisions in plain English during team projects. It's gotten noticeably easier." Specificity makes it credible.

Wipro requires freshers to sign a service bond, typically one year from the date of joining. Leaving before the bond period ends attracts a financial penalty stated in the agreement. The amount varies by batch and track but is in the range of Rs. 75,000 to Rs. 1,00,000 based on reported experiences from 2024-2025 joiners.

If you've accepted the offer, answer yes clearly. The HR round is not the time to negotiate bond terms. If the bond length is a genuine concern, that conversation needs to happen before you accept the offer letter, not in the middle of the HR round.

Name a direction, not just a title. A version that works: "I want to develop strong technical depth in cloud or data engineering over the first two to three years, then move toward leading a small workstream on a larger project. Wipro's scale means I'd be working on real enterprise infrastructure from the beginning, which accelerates that kind of growth significantly."

What doesn't work: "I want to be a manager in five years" with no pathway, or "I'll see what happens." Wipro HR interviewers are checking whether you have some direction, not whether you've planned your career to the month.

Always ask at least one question. Candidates who say "no, I'm good" leave on a flat note. Good questions to ask: "What does the first 90 days look like for a fresher joining this team?", "Which technologies will I be working with initially?", or "How does Wipro's internal learning program work for freshers in the Project Engineer role?"

Avoid asking about salary or benefits in the HR round unless the interviewer brings it up. That conversation belongs at the offer stage.

NLTH stands for National Level Test for Hiring. It replaced the older Elite NTH (National Talent Hunt) branding in recent hiring cycles. The structure is similar: aptitude, written communication, coding, followed by interviews. The NLTH now includes a Voice Assessment component in some batches (reading aloud, picture description, topic response) that was not consistently present in the older format. The track names have also evolved: Wipro now uses Regular, Velocity, Turbo, and Elite to differentiate CTC and role type.

No. The coding round (two problems, 60 minutes) is part of the assessment for Elite and Turbo tracks. Regular and Velocity tracks do not include a coding section in the NLTH. However, all tracks that proceed to a Technical interview will include some form of programming question in that interview, even if it's verbal or on paper rather than on a compiler.

WILP stands for Work Integrated Learning Program. It's a separate Wipro program where your employer (Wipro in this case) sponsors you to complete a postgraduate degree from BITS Pilani or a similar institution while working full-time. It's structured for candidates who join Wipro and then get selected into WILP, not as a direct campus hiring channel for fresh graduates. Freshers interested in a postgraduate degree funded by their employer should research WILP after joining, not as their primary application route.

Based on candidate reports from the 2024-2025 hiring cycle, the full process from NLTH to offer letter typically takes 4-10 weeks. The NLTH to interview shortlist phase takes 2-4 weeks. Interviews (Technical and HR) are often held on the same day or across two consecutive days. The offer letter after successful interviews has taken anywhere from 1 week to 6 weeks depending on batch and track. Wipro's HR team communicates primarily through the career portal and registered email, so keep both active and check them regularly.

Python is the most practical choice under time pressure for most candidates. The syntax is compact, the standard library handles most string and array tasks cleanly, and there's no need to manage types or brackets at the level Java or C++ requires. That said, if you have strong Java or C++ experience and your patterns are muscle memory, stick with what you know. Switching languages under a 60-minute clock is a worse risk than a slightly more verbose syntax. The compiler supports C, C++, Java, and Python.

The service bond Wipro asks freshers to sign is typically one year from the date of joining. Based on candidate-reported experiences from the 2024-2025 batch, the penalty for leaving before the bond period ends ranges from Rs. 75,000 to Rs. 1,00,000 depending on the track and the specific terms in your offer letter. This is stated explicitly in the bond document you sign at joining. If you have concerns about it, read the offer letter carefully before signing. Asking the HR interviewer to waive or reduce the bond during the HR round has not been reported to succeed.

WILP interviews happen after you're already on Wipro's payroll, so there's no aptitude test and no coding round attached to it. The conversation centers on your current project, why you want a specific postgraduate program (usually through BITS Pilani), and whether your manager has signed off on the time commitment alongside your regular work.

Where an NLTH panel drills your final year project and DSA basics, a WILP panel is checking whether you can realistically carry a full course load on top of an active Wipro project, and whether you picked the program for a specific reason rather than a general "I want to upskill." Candidates who can name the exact specialization they're targeting, and tie it to what they're already doing on their project, come across noticeably stronger than candidates with a vague answer about career growth.

Rate of filling = 1/12 per hour. Rate of emptying = 1/18 per hour. Net rate = 1/12 - 1/18 = 3/36 - 2/36 = 1/36 per hour. Time to fill = 36 hours.

Pipes and cisterns problems show up in almost every Wipro NLTH batch. The key: treat filling as positive rate and emptying as negative rate, then subtract. Don't try to memorize formulas for special cases. A rate-based approach handles every variation.

Amount = P x (1 + r/100)^n = 8000 x (1.1)^2 = 8000 x 1.21 = Rs. 9,680. Compound interest = 9,680 - 8,000 = Rs. 1,680.

For a 2-year problem specifically, there's a shortcut worth memorizing: CI = P x [(1 + r/100)^2 - 1]. Plug the numbers in directly instead of computing the amount first and subtracting after. It's a small shortcut, but across a 48-question aptitude section every 15-20 seconds saved adds up.

The girl's mother has only one daughter, and the girl herself is that daughter. So "my mother's only daughter" is just a roundabout way of saying "me." The boy, being that daughter's son, is the girl's own son.

This variant catches people because the answer loops back to the speaker, and it feels wrong to conclude someone is describing themselves in the third person. Whenever a blood relation question uses "only son" or "only daughter," check first whether that phrase could point back to the speaker before assuming it names someone else. That one check resolves most of the trickier questions in this set.

An abstract class can have both concrete and abstract methods. It can carry instance variables. A class can extend only one abstract class. Use it when related classes share some common implementation you want to inherit directly.

An interface (in Java pre-Java 8) could only hold abstract methods. A class can implement multiple interfaces. From Java 8, interfaces support default and static methods. Use interfaces to define contracts that unrelated classes can implement, like Comparable or Serializable.

The practical answer: if you need shared code, use abstract class. If you need a contract across unrelated types, use interface.

Merge sort divides the array in half, recursively sorts each half, then merges them. Guaranteed O(n log n) in all cases. Requires O(n) extra space for the temporary array during merge.

Quick sort picks a pivot, partitions elements less than the pivot to the left and greater to the right, then recursively sorts each partition. Average O(n log n), but degrades to O(n²) when the pivot is always the smallest or largest element (already-sorted arrays with naive pivot selection). Sorts in place: O(log n) space for the recursion stack.

"Which is better" has no absolute answer, which is what Wipro actually wants you to say. Merge sort for linked lists and when stability matters. Quick sort for arrays in practice, with random pivot to avoid worst-case. Tell the interviewer the tradeoff instead of naming a winner.

Floyd's cycle detection algorithm: use two pointers, slow moves one step at a time, fast moves two steps. If they meet, there's a cycle. If fast reaches null, there's no cycle.

#include <stdio.h>
#include <stdlib.h>

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

int hasCycle(struct Node* head) {
    struct Node* slow = head;
    struct Node* fast = head;

    while (fast != NULL && fast->next != NULL) {
        slow = slow->next;
        fast = fast->next->next;

        if (slow == fast) {
            return 1; // cycle detected
        }
    }
    return 0; // no cycle
}

This problem shows up in Wipro Technical rounds for candidates who listed C or DSA on their resume. The key detail interviewers want: why does fast moving at 2x speed guarantee they meet inside the cycle (not overshoot)? Because at each step, fast gains one position on slow, so it will eventually catch up within the cycle length.

Normalization removes data redundancy by organizing data into well-structured tables with clear dependencies.

• 1NF: no repeating groups; every column holds atomic (indivisible) values; each row is unique.
• 2NF: satisfies 1NF, plus no partial dependencies. Every non-key attribute depends on the whole primary key, not just part of it. This only matters when the primary key is composite.
• 3NF: satisfies 2NF, plus no transitive dependencies. Non-key attributes must depend on the primary key directly, not on other non-key attributes. Example: if a table stores StudentID, DeptID, and DeptName, and DeptName depends on DeptID (not on StudentID), that's a transitive dependency. Move DeptName to a Department table.

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

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

This is one of the most consistently reported SQL questions in Wipro Technical rounds across multiple candidate experiences from 2024-2025. Know both approaches. The subquery version works everywhere; the LIMIT/OFFSET version is cleaner to write under time pressure. The follow-up question Wipro panels ask: "what happens if the salary column has NULL values?" Answer: MAX() ignores NULLs, so the subquery approach handles it correctly without modification.

INNER JOIN: returns only rows where the join condition is matched in both tables. Rows without a match in either table are excluded.

LEFT JOIN (LEFT OUTER JOIN): returns all rows from the left table plus matched rows from the right table. Where no match exists in the right table, NULLs fill in for the right table's columns.

FULL OUTER JOIN: returns all rows from both tables. NULLs fill in where no match exists on either side. Not supported natively in MySQL; emulated with a UNION of LEFT and RIGHT joins.

The follow-up Wipro often uses: "if you have 5 rows in table A and 3 matched rows in table B, how many rows does a LEFT JOIN return?" Answer: 5. All of table A, with NULLs for the 2 unmatched rows. This is the test of whether you actually understand the behavior, not just the name.

ACID stands for Atomicity, Consistency, Isolation, and Durability, the four guarantees a transaction system provides so data stays reliable even when something fails mid-operation.

• Atomicity: a transaction either completes in full or not at all. A bank transfer that debits one account and then fails before crediting the other gets rolled back entirely.
• Consistency: a transaction moves the database from one valid state to another without breaking any constraint or rule.
• Isolation: two transactions running at the same time don't see each other's half-finished changes.
• Durability: once a transaction commits, the change survives even a crash immediately afterward.

Most candidates reach for the bank transfer example to explain atomicity and stop there. Have a second example ready, like an e-commerce order that deducts inventory and creates a shipment record together, in case the interviewer asks you to walk through all four properties using the same scenario.

A deadlock happens when two or more processes are each waiting on a resource the other one holds, and neither can move forward. Four conditions have to hold at the same time for it to occur: mutual exclusion (a resource can only be held by one process at once), hold and wait (a process holds one resource while waiting on another), no preemption (a resource can't be forcibly taken away), and circular wait (a closed chain of processes each waiting on the next one in the chain).

Break any single one of the four and the deadlock can't happen, which is the entire basis for how an OS prevents it. Wipro's Technical panel rarely expects a named algorithm like Banker's algorithm from a fresher unless OS is listed as a strength on the resume, but knowing the four conditions cold covers almost everything asked on this topic at the fresher level.

Wipro interviewers follow a specific pattern here. They listen for about 90 seconds, pick one technology you mention, and drill it. If you say "we used MySQL," the next question is "explain normalization" or "write a query for X." If you say "we built a REST API," it becomes "what's the difference between GET and POST?" or "how did you handle authentication?"

Structure your answer this way: the problem your project addressed (one sentence), the tech stack you chose and why (two to three technologies, brief justification), your specific contribution (not what the team did), and one concrete challenge you solved. The "specific contribution" part is where most freshers lose points. Wipro interviewers ask "what did you personally build?" and candidates who can't answer that clearly lose credibility on every claim they made before it.

Good structure: name the specific problem (one sentence, not "it was complex"), what you tried first that didn't work, what eventually worked, and what you'd do differently now. The "what you'd do differently" part is optional but makes an answer memorable. It signals technical maturity rather than just problem-solving.

Vague answers like "we faced many challenges but overcame them as a team" read as someone who didn't actually build anything. The interviewer is testing both whether you worked on the project and whether you can think critically about technical problems.

The producer-consumer problem is about coordinating threads that produce data with threads that consume it, using a shared buffer, without either side stepping on the other or busy-waiting and burning CPU.

With plain wait/notify you need a synchronized block around the shared buffer. The producer checks if the buffer is full inside a while loop, never an if, because of spurious wakeups, and calls wait() when it is. After adding an item it calls notifyAll() to wake any waiting consumers. The consumer does the mirror image: wait while empty, take an item, then notifyAll() to wake producers. Using notify() instead of notifyAll() when there are multiple producers and consumers is a classic bug, since the wrong thread can get woken up and the rest hang forever.

In practice almost nobody hand-rolls wait/notify in production code anymore. You reach for java.util.concurrent.BlockingQueue, ArrayBlockingQueue or LinkedBlockingQueue. put() and take() already block internally with correct signaling, so you get the same guarantees without writing your own synchronized/wait/notify logic. The tradeoff is control: BlockingQueue gives you a fixed FIFO blocking policy, while a hand-rolled version lets you customize backpressure, batching, or priority ordering. Outside a very specific requirement, BlockingQueue is the right call, since it has been tested against these exact race conditions for years.

When you call put(key, value), Java first computes key.hashCode(), then runs it through an internal spreading function (in Java 8+, h ^ (h >>> 16)) so poor hashCode implementations are less likely to cluster into the same buckets. That spread hash is masked against table.length - 1 to get the bucket index, which only works cleanly because the table length is always a power of two.

If the bucket is empty, the new node goes there directly. If it's occupied, HashMap walks the chain at that bucket comparing hashCode first, then equals(), to check whether the key already exists, in which case it replaces the value. Otherwise the new entry is appended to the chain. This is why a correct equals()/hashCode() contract matters: if two equal objects return different hashCodes, they land in different buckets and you effectively create duplicate entries you can never retrieve consistently.

Since Java 8, if a single bucket's chain grows past 8 entries and the table has at least 64 buckets, that chain converts from a linked list into a red-black tree, turning worst-case lookup from O(n) to O(log n) for that bucket. This mainly protects against pathological cases like hash flooding, where an attacker crafts many keys that all hash to the same bucket.

Resizing happens once the number of entries exceeds capacity times loadFactor (default 0.75). The table doubles in size and every existing entry gets rehashed into the new table, an O(n) operation. If you know roughly how many entries you'll store, initializing the HashMap with that capacity upfront avoids repeated resize-and-rehash cycles under load.

Once you split into separate services with separate databases, you lose the ability to wrap both operations in a single local transaction, so you can't rely on ACID guarantees across the boundary. Two-phase commit exists but is rarely practical here: it needs a coordinator, it holds locks across both databases while waiting on the slower participant, and if the coordinator crashes mid-commit you can end up with resources stuck in an in-doubt state. Most teams avoid 2PC for that reason, especially when Payment is calling out to an external gateway that doesn't support distributed transactions at all.

The pattern that actually works here is the saga. The Order service creates the order in a pending state and publishes an event to the Payment service. Payment attempts the charge and publishes either a success or failure event. If it succeeds, Order transitions to confirmed. If it fails, Order runs a compensating action, cancelling the order, rather than trying to undo a transaction that never committed together in the first place.

The tricky part isn't the happy path, it's designing the compensating transactions and making the whole thing idempotent. If Payment's success event gets delivered twice because of a retry, Order needs to recognize it already confirmed that order and no-op the second delivery, usually by keying off an idempotency key or an event ID it has already seen. You also need to think about what consistent means during the window between order creation and payment confirmation. That's usually where you introduce a visible processing state to the user rather than pretending the whole operation is atomic.

First I'd want the exact OOM message, since different flavors point to different problems. 'Java heap space' means the heap itself is exhausted. 'GC overhead limit exceeded' means the JVM is spending nearly all its time collecting and reclaiming almost nothing, which usually points to a slow leak rather than a sudden spike. 'Metaspace' points at class loading, often from dynamic proxies or a class loader leak in an app that repeatedly redeploys or generates classes at runtime.

Assuming it's heap space, the first thing I want is a heap dump, ideally captured automatically on OOM using -XX:+HeapDumpOnOutOfMemoryError so there's no need to reproduce it live. If the service is still up and can tolerate a brief pause, jmap -dump or jcmd GC.heap_dump gets one too. I'd load that dump into Eclipse MAT and check the dominator tree, specifically the leak suspects report, which sorts objects by retained size, meaning how much memory would actually be freed if that object were collected.

Common culprits I've actually seen in production: a static Map or List used as a cache with no eviction policy, growing forever as new keys come in; a listener or callback registered on a long-lived object such as a Spring bean that never gets unregistered when short-lived request objects are created, pinning those objects in memory; and ThreadLocal values that never get removed after a thread returns to a pool, especially in Tomcat's thread pool where threads are reused indefinitely and hold onto whatever was left in ThreadLocal storage from the previous request.

Alongside the heap dump, I'd pull GC logs from before the crash (-Xlog:gc*) and check whether the old generation climbs steadily across each cycle without dropping back to baseline. A sawtooth pattern that never resets is the clearest sign of a genuine leak versus a workload that has simply grown past the current heap sizing.

An LRU cache needs O(1) lookup and O(1) eviction of the least recently used entry. The standard approach combines a hash map for O(1) key lookup with a doubly linked list that tracks recency order. Each node in the list holds the key, value, and pointers to its previous and next node. The map stores key to node references so you can jump straight to any node without walking the list.

On get, look up the node in the map, move it to the front of the list (most recently used), and return its value. On put, if the key exists, update the value and move the node to the front. If it's a new key and the cache is at capacity, remove the node at the tail (least recently used), delete it from the map, then insert the new node at the front and add it to the map.

class LRUCache {
    class Node { int key, value; Node prev, next; }
    private final int capacity;
    private final Map<Integer, Node> map = new HashMap<>();
    private final Node head = new Node(), tail = new Node();

    LRUCache(int capacity) {
        this.capacity = capacity;
        head.next = tail;
        tail.prev = head;
    }

    private void remove(Node n) {
        n.prev.next = n.next;
        n.next.prev = n.prev;
    }

    private void addFront(Node n) {
        n.next = head.next;
        n.prev = head;
        head.next.prev = n;
        head.next = n;
    }

    public int get(int key) {
        if (!map.containsKey(key)) return -1;
        Node n = map.get(key);
        remove(n);
        addFront(n);
        return n.value;
    }

    public void put(int key, int value) {
        if (map.containsKey(key)) {
            Node n = map.get(key);
            n.value = value;
            remove(n);
            addFront(n);
            return;
        }
        if (map.size() == capacity) {
            Node lru = tail.prev;
            remove(lru);
            map.remove(lru.key);
        }
        Node n = new Node();
        n.key = key;
        n.value = value;
        addFront(n);
        map.put(key, n);
    }
}

In Java you can also get away with a LinkedHashMap by overriding removeEldestEntry, but interviewers usually want to see that you understand the underlying data structure rather than relying on a library shortcut.

There are a few standard algorithms and the right one depends on how strict the limit needs to be and whether the API runs on a single instance or a distributed fleet.

Fixed window counter is the simplest: keep a counter per user keyed by the current minute, increment on each request, reject once it hits 100, reset when the minute rolls over. It's cheap but has a boundary problem: a user can send 100 requests in the last second of one window and another 100 in the first second of the next, giving them 200 requests in a two-second span.

Sliding window log or sliding window counter fixes that by tracking timestamps, or weighting the previous window's count, so the limit is enforced over any rolling 60-second period rather than a calendar-aligned minute. Token bucket is what I'd actually reach for in most APIs: each user has a bucket that refills at a fixed rate, say 100 tokens per minute, up to a max capacity, and each request consumes one token. It allows short bursts up to the bucket size while still enforcing the average rate, which matches how real client traffic behaves.

For a single server, an in-memory structure with a scheduled refill works fine. For a distributed API behind multiple instances, the counter state needs to live somewhere shared, typically Redis, using INCR with an expiring key for fixed window, or a Lua script for atomic token bucket updates so two servers don't race on the same user's count. You also want to decide what happens at the limit: return 429 with a Retry-After header rather than silently dropping requests, so well-behaved clients can back off correctly.