Infosys Interview Questions and Answers

Answer

InfyTQ has been used by Infosys as a learning and certification platform for engineering students, offering courses and a certification assessment, with strong performance able to route a candidate toward interview opportunities rather than requiring them to go through a general recruitment drive from scratch. The practical value is that it is a route you can start early, in your pre-final year, rather than waiting for a campus drive in your final year. Content has typically covered programming fundamentals in Java or Python, database and SQL, and general computing concepts, with the assessment testing both multiple choice understanding and hands-on coding.

The exact structure, eligibility, and how the certification maps to interview opportunities change across cycles, so check the current details on the platform rather than relying on a senior's experience. What an interviewer is probing if InfyTQ comes up is whether you actually did the work or clicked through videos. Be ready to be asked a technical question directly from the certification syllabus, particularly on SQL and on the language you certified in. A weak answer is naming the certification on your resume and then failing a basic question from its syllabus, which is worse than not listing it at all.

Answer

The assessment is generally built from a quantitative aptitude section, a logical reasoning section, a verbal ability section, and a pseudocode section, with a coding component for many roles and higher tracks. Section counts, question counts, and timings have varied across cycles and across the different entry tracks, so read your admit card rather than a coaching summary. Two structural facts drive strategy.

Sections are usually individually timed, so time saved in one does not carry into another, and you generally cannot return to a closed section. That means the correct approach is per-section pacing, not overall pacing. Set a per-question budget before you start each section and enforce it mechanically.

In quantitative, do a first sweep for everything solvable in under sixty seconds and then return. In verbal, do vocabulary and error-spotting first and reading comprehension last. In pseudocode, read the entire snippet once before answering anything, because rushing to the first line is exactly how you misread a loop bound. The most common way strong candidates fail is not difficulty, it is spending eight minutes on one question and then leaving six easy marks unattempted at the end of the section.

Answer

Infosys has hired freshers into differentiated roles rather than a single band. The standard entry track is commonly the Systems Engineer role, with higher tracks that have included Digital Specialist Engineer, Specialist Programmer, and the Power Programmer route aimed at candidates with stronger coding ability who are placed on deeper engineering work. As broad and frequently reported ranges, the standard track has sat around ₹3.6 LPA, the digital specialist track materially higher in the region of ₹6.5 LPA, and the specialist or power programmer routes considerably higher again, often quoted in the ₹9 to ₹12 LPA region and sometimes above.

Treat every one of those as a range that varies by year, batch, degree, and drive, and never quote a figure in an interview as if it were policy. The routing is driven by assessment performance, particularly the coding component, and by a harder interview for the higher tracks. What a panel is probing if track comes up is whether you are realistic and whether you have prepared for the track you are claiming. A candidate asking for a specialist programmer offer who cannot solve a moderate algorithmic problem is an easy rejection, so pick your track honestly and prepare for it specifically.

Answer

The higher engineering tracks are selected on coding depth rather than on aptitude, and the interview is a different conversation entirely. Instead of being asked to explain the four pillars of OOP, you are asked to solve a problem, defend your complexity, and handle a follow-up that changes the constraints. Preparation should look like a product company preparation rather than a services one: arrays and strings, hashing, two pointers and sliding window, sorting, binary search including on the answer, recursion and backtracking, trees and graphs at a working level, and introductory dynamic programming.

You should be able to state time and space complexity for everything you write without being asked. Beyond algorithms, these tracks probe system thinking, so be able to talk about how you would design a small service, what you would store where, and how you would handle failure. Your project matters more here and it needs to be substantial, ideally something running with real users or real data rather than a coursework submission.

A weak candidate for this route is one who has memorised solutions and cannot handle a modified constraint. A strong one thinks out loud, states the brute force first, then improves it, and is explicit about the tradeoff they are making at each step.

Answer

Marking schemes have varied across cycles and across sections, so read the instruction screen on test day rather than assuming, and note that a scheme can differ between the aptitude sections and the pseudocode section within the same test. Your strategy should be decided before you sit down, not during. If there is no penalty for a wrong answer, leave nothing blank and reserve the final thirty seconds of each section purely to fill in anything unattempted.

If there is a penalty, use elimination discipline, guess only when you have ruled out at least two options, and skip cleanly otherwise. In the pseudocode section specifically, guessing is more dangerous than in aptitude because the distractor options are usually constructed from the exact mistakes a hurried reader makes, an off-by-one on a loop bound, a swapped assignment order, the pre-increment versus post-increment difference. That means a rushed guess is more likely to land on a wrong option than a random one would be. The discipline that saves the most marks across the whole test is separating the decision to skip from the emotion of having already spent time, so set your per-question limit and obey it even when you feel close.

Answer

Verbal covers reading comprehension, sentence correction and error spotting, sentence completion, para jumbles, and vocabulary in context. The easiest marks are lost in three places. Prepositions and articles, because these are learnt by exposure rather than rule and Indian regional English has settled habits the test scores as wrong.

Subject and verb agreement when a clause separates them, for example a sentence where the subject is singular but the nearest noun before the verb is plural. And para jumbles, where candidates try to read all permutations instead of looking for the structural anchors, the opening sentence that introduces without referring back, and the pronoun and connector links that force a pair of sentences to be adjacent. For reading comprehension, read the questions first and then scan, because reading the passage thoroughly first is the single largest time sink in the section.

Beyond the test, spoken English is assessed informally in the HR round and formally in some processes, so do not treat verbal preparation as a paper exercise. Read something in English for fifteen minutes a day and speak for two minutes a day on a random topic, recorded, because fluency under mild pressure is what actually gets assessed later.

Answer

The recurring set is percentages, profit and loss, ratio and proportion, averages and mixtures, time speed and distance including trains and boats, time and work, simple and compound interest, number systems including HCF, LCM, divisibility and remainders, permutation and combination, probability, mensuration, and data interpretation. The section is not testing mathematics, it is testing arithmetic economy under a clock, so the highest-return preparation is a small set of habits rather than a large set of formulas. Learn the fraction equivalents of common percentages so that 12.5 percent immediately becomes one eighth and 16.67 percent becomes one sixth.

Use the LCM method for time and work rather than fractional rates. Use the successive percentage change formula rather than computing two steps. Back-solve from the options whenever the algebra runs past two lines, because the options are given and one of them is correct.

Memorise squares to thirty and cubes to fifteen. Then track your errors by cause, not by count, splitting them into concept gap, calculation slip, and misread question. Almost every candidate discovers that misreads and slips outnumber genuine concept gaps, and those two are fixed by process changes rather than by more study.

ALLIGATION, faster than two equations

Milk at 40 per litre mixed with water (0) to sell at 32 per litre. Ratio?

  Milk 40            Water 0
         \           /
          Mean 32
         /           \
   32 - 0 = 32     40 - 32 = 8

  Milk : Water = 32 : 8 = 4 : 1

REMAINDER SHORTCUT
Find the remainder of 7^100 divided by 5.
7 mod 5 = 2, so we need 2^100 mod 5.
Powers of 2 mod 5 cycle 2, 4, 3, 1 with period 4.
100 mod 4 = 0, so we take the last of the cycle: remainder is 1.

COMPOUND INTEREST for 2 years, no formula sheet needed
Effective rate = r + r + (r * r / 100)
At 10 percent for 2 years: 10 + 10 + 1 = 21 percent total

Answer

Expect seating arrangements both linear and circular, floor and building puzzles, blood relations, coding and decoding, syllogisms, direction sense, series completion, statement and conclusion, and data sufficiency. Arrangement questions are where most of the time goes and where a method beats intuition decisively. Draw the frame first, whether that is eight chairs in a circle or five floors in a column.

Read every clue and classify it into definite or conditional. Place only definite information on the diagram, and keep conditional clues in a list beside it. Then apply conditionals one at a time, and when a clue creates two possibilities, draw both diagrams rather than trying to hold them in your head, because holding branches mentally is where errors happen.

Most arrangement sets collapse to a single valid diagram after three or four clues, and the remaining questions then take ten seconds each. For circular arrangements, always confirm whether the people are facing the centre or outward before you place anyone, because that single detail flips left and right and is the most common cause of a fully wrong set. For syllogisms, test each conclusion against every valid Venn arrangement, not just the first one you draw.

Answer

Data interpretation is where a section is won or lost because a set carries several questions off one chart, so the setup cost is amortised. Spend the first twenty seconds reading the chart title, the axis units, and the footnote, because the single most common mistake is answering in the wrong unit, computing in lakhs when the chart is in crores, or missing a footnote saying figures are for the first half of the year only. Then scan the questions before computing anything, because typically one or two are direct reads requiring no calculation and should be banked immediately.

For the calculation questions, approximate aggressively. If options are far apart, round to two significant figures and pick, because full precision is wasted effort. Percentage change questions rarely need exact division, an estimate of whether it is above or below twenty percent is usually enough to eliminate three options.

Learn to compute percentage change as difference divided by the original, and always confirm which value the question calls the base, because reversing it is the most common trap. If a set has an unusually heavy calculation in one question, skip that single question and take the rest of the set, since abandoning a whole set for one hard question is a poor trade.

Answer

Puzzles appear in interviews for a different reason than they appear on the test. On the test they are scored on the answer, in the interview they are scored on how you think when you do not know the answer, which is exactly what a delivery job requires. So narrate.

State your understanding of the problem back in your own words and confirm it, because half of all puzzle failures are solving a different problem than the one asked. Ask clarifying questions and state your assumptions out loud, since an interviewer will often correct a wrong assumption and that correction is a gift. Start with a brute force or a simplified version, for example solving it for two people before eight, and say that is what you are doing.

Then improve. If you get stuck, say precisely where you are stuck rather than going silent, because silence is the one behaviour that is scored badly regardless of whether you eventually solve it. If you have seen the puzzle before, say so honestly and offer to explain your reasoning rather than reciting the answer, because being caught reciting a memorised solution to a puzzle you claimed was new is far more damaging than simply not solving it.

Answer

Pseudocode questions present a snippet in a language-neutral notation and ask you to predict the output, identify the error, or state the value of a variable at the end. It fails good coders for a specific reason: writing code and reading unfamiliar code are different skills, and most students have practised only the first. The notation itself adds friction, since it borrows loosely from C-like syntax but is not any one language, so you cannot lean on habits, and the questions are deliberately built around the places where habits mislead.

The recurring traps are consistent. Off-by-one errors in loop bounds, especially loops written with a less-than-or-equal condition. Pre-increment against post-increment, where the value used in an expression differs from the value stored.

Integer division truncating a result you expected to be fractional. Operator precedence, particularly mixing arithmetic with comparison. Pass by value against pass by reference, where a function appears to modify a caller variable but does not, or does.

Array indexing starting from zero when the loop counter starts at one. The method that works is mechanical: build a trace table with one column per variable and one row per iteration, and fill it in. It feels slow for two iterations and then becomes faster than reasoning, and it is essentially error-proof.

Answer

The trap in this family of questions is the combination of a loop bound and an integer division, and candidates who scan rather than trace get it wrong at a very high rate. Work it with a trace table. Write the variable names as columns, then one row per iteration, and fill in the values after each statement executes, not after each line is read.

Two disciplines matter. First, evaluate the loop condition before the body every time rather than assuming the iteration count from the initialiser, because the question is often constructed so that the loop runs one more or one fewer time than it appears to. Second, when integer division appears, write the truncated value in the table immediately rather than carrying a fraction forward mentally, since carrying the fraction and truncating at the end produces a different and wrong answer.

The wrong options offered are usually exactly the values produced by these two mistakes, which is why guessing here is worse than in aptitude. Practise ten of these with a physical trace table before test day and the section becomes routine. In the interview, if a panel puts a snippet in front of you, narrate the trace out loud rather than staring, because the panel is scoring your method and a visible trace table on paper is strong evidence of method.

SET total = 0
SET i = 1
WHILE i <= 10 DO
    IF i MOD 3 == 0 THEN
        total = total + (i / 2)      // integer division, truncates
    END IF
    i = i + 1
END WHILE
PRINT total

TRACE TABLE (only the iterations that enter the IF)

  i    i MOD 3 == 0    i / 2 (integer)    total
  3    true            1                  1
  6    true            3                  4
  9    true            4                  8

Output: 8

COMMON WRONG ANSWERS AND WHY
  9   -> carried 4.5 for i = 9 instead of truncating to 4
  4   -> stopped at i < 10 instead of i <= 10
  12  -> added i instead of i / 2

Answer

This is the highest-value pseudocode trap because the answer depends entirely on the passing convention the snippet declares, and candidates answer from the habits of whichever language they know rather than from what is written. The rule to internalise is that pass by value copies the argument, so the function operates on a copy and the caller's variable is unchanged, while pass by reference gives the function access to the caller's storage, so changes persist. Questions signal the convention explicitly, often with a keyword such as REF or an ampersand, and the entire question turns on whether you noticed it.

There is a further layer worth knowing because it appears in interviews: in languages like Java and Python, object references are themselves passed by value, which means reassigning the parameter inside the function does not affect the caller, but mutating the object that the reference points to does. That distinction, reassignment versus mutation, is what makes the Java and Python behaviour look inconsistent to beginners, and being able to state it cleanly is a strong signal in a technical round. When you meet this in a pseudocode question, circle the parameter declaration before you trace anything, because that single token decides the answer.

// PASS BY VALUE: the caller's variable is untouched
FUNCTION doubleIt(x)
    x = x * 2
    PRINT x
END FUNCTION

SET a = 5
CALL doubleIt(a)     // prints 10
PRINT a              // prints 5, unchanged


// PASS BY REFERENCE: the caller's variable changes
FUNCTION doubleIt(REF x)
    x = x * 2
END FUNCTION

SET a = 5
CALL doubleIt(a)
PRINT a              // prints 10


// The Java and Python nuance: reference passed by value
// Reassigning the parameter does nothing to the caller
void reassign(List<Integer> list) { list = new ArrayList<>(); }
// Mutating the object the reference points to does affect the caller
void mutate(List<Integer> list)   { list.add(99); }

Answer

Count the number of times the innermost statement executes as a function of the input size, and do not shortcut by counting loop nesting depth, because the depth heuristic is exactly what the question is built to punish. Two nested loops are not automatically O of n squared. If the inner loop runs a fixed number of times regardless of n, the whole thing is linear.

If the inner loop's bound depends on the outer counter, you get a triangular sum which is n times n plus one over two, still O of n squared but a useful thing to be able to derive rather than recognise. If a loop variable is multiplied or divided each iteration rather than incremented, the loop is logarithmic, and a linear outer loop around a logarithmic inner loop gives O of n log n. If a loop's counter is modified inside the body, trace it, because that is a favourite construction.

Also watch for a loop that appears nested but whose inner counter is not reset between outer iterations, which makes the total work linear rather than quadratic, and that is the classic two-pointer or sliding window pattern. State your reasoning in one line, for example the inner statement runs roughly n squared over two times, therefore O of n squared, because in an interview the derivation is what earns the mark.

// A: triangular, O(n^2)
FOR i = 0 TO n-1
    FOR j = i TO n-1
        work()          // runs n(n+1)/2 times

// B: looks nested, is actually O(n) because j never resets
SET j = 0
FOR i = 0 TO n-1
    WHILE j < n AND condition(i, j)
        j = j + 1       // j advances at most n times in total

// C: logarithmic, the counter is divided not decremented
WHILE n > 1
    n = n / 2           // O(log n)

// D: O(n log n)
FOR i = 0 TO n-1
    SET k = n
    WHILE k > 1
        k = k / 2

Answer

Debug-style pseudocode questions plant one error and the error is drawn from a small, predictable pool, so scan for that pool before you trace line by line. Check the loop bounds first, since off-by-one is the most planted error, particularly a loop that should stop at n minus one but runs to n, or the reverse. Check the initialisation, because a maximum tracker initialised to zero instead of to negative infinity or to the first element is the second most common plant and it fails silently on all-negative input.

Check whether an accumulator is reset inside a loop when it should be outside, or outside when it should be inside, which is the classic cause of a running total that is either always zero or wildly too large. Check the comparison operator direction, since a swapped less-than for greater-than yields a plausible but wrong answer. Check for an assignment where a comparison was intended.

Finally check whether the return or print is inside the loop when it should be after it, which produces the right value printed the wrong number of times. Work the pool first and you will find the planted error in about twenty seconds. Only if the pool comes up empty should you build a full trace table, and then trace with the smallest input that could expose a bug, usually an array of two elements.

Answer

The coding component is typically one to three problems in an online editor evaluated against hidden test cases, with C, C plus plus, Java, and Python commonly available. Scoring is usually per test case, so a partial solution beats a blank editor and you should always submit something that compiles. The most avoidable losses are not algorithmic.

First is input and output format: read the sample block character by character and match it exactly, never print a prompt string such as 'Enter a number' because the automated checker treats it as wrong output, and check whether the expected output is space separated or newline separated. Second is not reading the constraints, because the constraints tell you the required complexity, an input size of ten to the power five rules out a nested loop and an input size of a hundred means brute force is fine. Third is integer overflow in C and Java, where a sum of large values silently wraps and the fix is to use long.

Fourth is not handling the trivial edge cases, empty input, one element, all elements equal, and negative numbers. Write the solution, then spend a minute deliberately walking those four cases before submitting, because that minute recovers more marks than any refactoring would.

Answer

The obvious solution sorts both strings and compares, which is correct and costs O of n log n. The expected improvement is a frequency count, which is O of n time and O of k space where k is the alphabet size, and for lowercase English letters that is a fixed array of twenty six counters, making the space effectively constant. Increment for the first string, decrement for the second, and confirm every counter is zero, which is neater than building two maps and comparing them.

The follow-ups are where the marks actually are, and they are always about the definition. Are the strings case sensitive? Do spaces and punctuation count, which matters for a phrase anagram?

What about Unicode, where a fixed twenty six element array breaks and you need a hash map? What if the strings are enormous and you only need to know whether they could be anagrams, where comparing lengths first short-circuits most cases for free. Ask about case and whitespace before you write a line, because asking is scored.

A weak answer sorts and stops. A strong one gives the counting solution, states both complexities, checks lengths first as a cheap early exit, and raises the Unicode limitation without being prompted.

def is_anagram(a, b):
    if len(a) != len(b):
        return False                  # cheap early exit
    counts = [0] * 26
    for ch in a:
        counts[ord(ch) - ord('a')] += 1
    for ch in b:
        counts[ord(ch) - ord('a')] -= 1
        if counts[ord(ch) - ord('a')] < 0:
            return False              # early exit on the first excess
    return True

# Unicode safe version, once you raise the limitation
from collections import Counter
def is_anagram_unicode(a, b):
    return Counter(a) == Counter(b)

print(is_anagram('listen', 'silent'))   # True
print(is_anagram('aabb', 'abbb'))       # False

Answer

There are three approaches and the interviewer wants to see you move between them, because the comparison is the real question. Sorting and scanning is O of n log n and is the answer nobody wants. The sum formula approach computes n times n plus one over two and subtracts the actual sum, which is O of n time and O of 1 space and is what most candidates give.

The XOR approach XORs all the indices from 1 to n and all the array values together, and everything cancels except the missing number, which is also O of n and O of 1 but carries an important advantage: it cannot overflow. That is the follow-up the interviewer is heading toward. With n around ten to the power five the sum fits comfortably in a 32-bit integer, but with n around ten to the power nine the sum overflows a 32-bit signed integer and produces a wrong answer silently, while XOR is immune.

So the ideal answer is: here is the sum approach, here is why I would prefer XOR when n is large or the language uses fixed-width integers, and here is the sorting approach which I would only use if the array had other properties I needed. Mentioning overflow before being asked is what distinguishes a prepared candidate.

// Sum approach: simple, but the sum can overflow for large n
long expected = (long) n * (n + 1) / 2;   // cast before multiplying
long actual = 0;
for (int v : arr) actual += v;
int missing = (int) (expected - actual);

// XOR approach: no overflow, same complexity
int x = 0;
for (int i = 1; i <= n; i++) x ^= i;
for (int v : arr)            x ^= v;
// x is now the missing number

// Why: a ^ a == 0 and a ^ 0 == a, so every present number cancels itself
// arr = [1, 2, 4, 5], n = 5
// (1^2^3^4^5) ^ (1^2^4^5) = 3

Answer

This question is asked because it separates people who understand grouping from people who have memorised joins. The naive attempt compares each salary against the overall average, which is a different and wrong question, and the second naive attempt puts an aggregate in the WHERE clause, which fails because WHERE evaluates before grouping. There are two correct shapes and you should know both.

The correlated subquery computes the average for the row's own department inside the WHERE clause, which is readable and portable but re-evaluates per row on older engines. The window function version computes the departmental average alongside each row with AVG OVER PARTITION BY, then filters that result in an outer query, and this is generally the better answer on any modern engine because it makes a single pass. Note the reason the window version needs an outer query at all: you cannot filter on a window function in WHERE, since window functions are evaluated after WHERE, which is exactly the kind of execution-order question the panel will ask next. Be ready to state the logical order of a SQL query, FROM, WHERE, GROUP BY, HAVING, window functions, SELECT, ORDER BY, because that single piece of knowledge answers a whole family of interview questions.

-- Correlated subquery: readable, portable
SELECT e.emp_id, e.name, e.dept_id, e.salary
FROM   employee e
WHERE  e.salary > (
         SELECT AVG(salary) FROM employee WHERE dept_id = e.dept_id
       );

-- Window function: single pass, preferred on modern engines
SELECT emp_id, name, dept_id, salary
FROM (
  SELECT emp_id, name, dept_id, salary,
         AVG(salary) OVER (PARTITION BY dept_id) AS dept_avg
  FROM   employee
) t
WHERE salary > dept_avg;

-- Why the outer query is needed: window functions are evaluated after WHERE
-- Logical order: FROM, WHERE, GROUP BY, HAVING, window, SELECT, ORDER BY

Answer

Name one language and commit. This is the panel picking which door to open, and a candidate who answers 'C, C plus plus, Java, Python and some JavaScript' has invited questions in all five and will be assessed on whichever they know worst. Say one, add a grounding sentence about where you used it, and stop talking.

The follow-up sets are predictable per language, so prepare the set rather than the language in general. For Java: OOP, abstract class versus interface, string immutability, the difference between double equals and equals, the collections framework with ArrayList against LinkedList and HashMap against TreeMap, exception handling including checked versus unchecked, and a surface question on threads. For Python: list versus tuple, mutable default arguments, dictionaries, list comprehensions, generators, shallow versus deep copy, and OOP.

For C: pointers, memory allocation, arrays versus pointers, structures, and string functions. Depth in one beats breadth in four every time, because the panel only needs one topic where you cannot go two levels deep to form an impression. If you genuinely use two languages daily, name the primary and mention the second as a single aside without inviting questions on it.

Answer

Panels have heard the animal and shape examples thousands of times and they signal recitation. Anchor each concept in something you built. Encapsulation is bundling data with the methods that act on it and restricting direct access, so a class in your project holds its fields private and exposes only operations that keep the object valid, which means no caller can leave it half-updated.

Abstraction is exposing what without how, so an interface for sending notifications lets callers work without knowing whether it goes by email or SMS. Inheritance is specialising a base type, and you should immediately add that inheritance is overused and composition is usually the safer default, because volunteering that caveat is the fastest way to signal that you have written real code rather than exam answers. Polymorphism is one interface with many implementations, resolved at compile time by overloading or at runtime by overriding, and you should be able to write both on request.

Expect the follow-up chain: give an example of runtime polymorphism from your own code, what is method hiding, can you override a static method, why is multiple inheritance of classes disallowed in Java and how do default methods in interfaces complicate that. Prepare two levels past the definition for each concept.

Answer

Strings are immutable because immutability makes them safe to share, and sharing is exactly what the JVM does through the string pool, where identical literals point at one object. Immutability also makes strings safe to use as hash map keys, since a key whose hash could change after insertion would become unreachable, and it makes them thread safe without synchronisation, and it prevents a security problem where a file path or connection string could be mutated after a permission check. Those four reasons are the complete answer and giving all four separates you immediately.

The double equals versus equals question follows directly: double equals compares references, meaning whether two variables point at the same object, while equals as overridden in String compares character content. This produces the classic result where two identical literals compare true with double equals because both come from the pool, while a string built with new or by concatenation at runtime compares false even though the content is identical. Always compare string content with equals. Two follow-ups are near certain: the difference between String, StringBuilder and StringBuffer, where StringBuilder is mutable and unsynchronised and StringBuffer is mutable and synchronised, and why concatenating strings inside a loop is a performance problem, which is because each concatenation creates a new object.

String a = "infosys";
String b = "infosys";
String c = new String("infosys");
String d = "info" + "sys";          // resolved at compile time
String part = "info";
String e = part + "sys";             // built at runtime

System.out.println(a == b);          // true,  same pooled object
System.out.println(a == c);          // false, new object on the heap
System.out.println(a == d);          // true,  compile-time constant
System.out.println(a == e);          // false, runtime concatenation
System.out.println(a.equals(e));     // true,  content comparison

// Why loop concatenation is a problem: a new String each iteration
String s = "";
for (int i = 0; i < 10000; i++) s += i;        // O(n^2) work

StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10000; i++) sb.append(i);  // O(n), mutable buffer

Answer

Work an actual table rather than defining the forms, because the definitions are what everyone recites and the panel is looking for someone who can apply them. First normal form requires atomic values with no repeating groups, so a column containing a comma separated list of subjects violates it and those become separate rows. Second normal form applies only when the primary key is composite and requires every non-key attribute to depend on the entire key, so in a table keyed on student and course, the student's name depends on only the student half and belongs in a student table.

Third normal form removes transitive dependency, where one non-key attribute determines another, so if a table holds both department id and department head, the head belongs with the department. Then give the part that most candidates miss: normalisation is a tradeoff, not a virtue. It reduces update anomalies and redundancy, but it adds joins, and in read-heavy reporting or analytics workloads you deliberately denormalise, pre-joining or storing computed aggregates because read speed matters more than storage. Naming that tradeoff, along with an example such as a reporting table that duplicates a customer name to avoid a join on every dashboard query, is what turns a recited answer into a demonstrated one.

-- Violates 1NF: repeating group in one cell
-- student_id | name | subjects
-- 101        | Asha | maths, physics

-- 1NF: one row per student and subject
CREATE TABLE enrolment (
  student_id INT,
  course_id  INT,
  PRIMARY KEY (student_id, course_id)
);

-- Violates 2NF: student_name depends on only part of the composite key
-- enrolment(student_id, course_id, student_name, course_fee)

CREATE TABLE student (student_id INT PRIMARY KEY, student_name VARCHAR(80), dept_id INT);
CREATE TABLE course  (course_id  INT PRIMARY KEY, course_fee  DECIMAL(10,2));

-- Violates 3NF: dept_head depends on dept_id, a non-key attribute
CREATE TABLE department (dept_id INT PRIMARY KEY, dept_head VARCHAR(80));

Answer

GROUP BY collapses rows into one row per distinct combination of the grouped columns, and every column in the SELECT list must either be in the GROUP BY or be wrapped in an aggregate function, which is the rule most candidates violate and then cannot explain. HAVING filters those groups after aggregation, which is why an aggregate can appear in HAVING but not in WHERE. The execution order is the key to everything here: FROM, then WHERE, then GROUP BY, then HAVING, then SELECT, then ORDER BY.

Once you can state that order you can answer a whole family of questions without memorising them, including why a SELECT alias is usually not usable in WHERE, why a filter on a plain column belongs in WHERE and not HAVING, and why putting a row filter in HAVING makes the database aggregate rows it will then throw away, which is a real performance cost on a large table. Two behaviours to know precisely because they come up as trick questions: COUNT star counts rows including those with NULLs, while COUNT of a specific column skips NULLs in that column, and aggregate functions such as AVG and SUM ignore NULLs entirely rather than treating them as zero, which means an average over a column with missing values is computed over a smaller denominator than you might expect.

-- Filter rows first, then aggregate, then filter the groups
SELECT dept_id,
       COUNT(*)      AS headcount,
       COUNT(bonus)  AS with_bonus,     -- skips NULL bonus values
       AVG(salary)   AS avg_salary
FROM   employee
WHERE  status = 'active'                -- row filter, before grouping
GROUP BY dept_id
HAVING COUNT(*) > 5                     -- group filter, after aggregation
ORDER BY avg_salary DESC;

-- Wrong: aggregate in WHERE
-- WHERE COUNT(*) > 5      -> error, WHERE runs before GROUP BY

-- Wrong: unaggregated column not in GROUP BY
-- SELECT dept_id, name, COUNT(*) FROM employee GROUP BY dept_id;

-- NULL behaviour: AVG over 4 rows where one salary is NULL divides by 3

Answer

Expect arrays, strings, stacks, queues, linked lists, hash tables, and trees at a conceptual level, with sorting and searching complexities. The depth is usually explain and give a use case rather than implement from scratch, though you should be able to write a stack or a reversal on paper. The stack versus queue question is really asking whether you can map a data structure to a problem shape.

Stacks are last in first out and you choose one whenever the most recent thing must be handled first: undo functionality, function call management, balanced bracket checking, expression evaluation, and depth first traversal. Queues are first in first out and you choose one whenever fairness or arrival order matters: print jobs, request handling, breadth first traversal, and any producer and consumer buffer. The strongest way to answer is to give one concrete problem for each and say why the other structure would give the wrong answer.

For example, checking balanced brackets with a queue is impossible because you need the most recently opened bracket, not the first. Expect the follow-ups: how would you implement a queue using two stacks, what is a circular queue and why does it exist, and what is a priority queue and where would you use it, since those three are asked constantly.

Answer

This carries more weight than any other question in the technical round because it is the only part where you choose the material, and the panel uses it to check whether the project is genuinely yours. Structure it in four beats and keep it under ninety seconds before pausing. What problem it solved and for whom.

What you personally built, saying I for your parts and being honest about how the team split the work. The stack and one design decision, including the alternative you rejected and why you rejected it. One thing that went wrong and how you fixed it, because a project with no problems was not built.

Then stop and let them ask. Every technology you name is an invitation, so never mention a framework you cannot answer three questions about. If there is a database, expect to be asked to draw your schema and justify a table.

If you consumed an API, expect to be asked what happens when it fails. If you claim machine learning, expect questions on your dataset size, your split, and your evaluation metric, and be ready to say why accuracy was or was not appropriate. A weak answer is a feature tour. A strong one is a sequence of decisions you can defend, with numbers attached wherever numbers exist.

Answer

Lists are mutable and tuples are immutable is the opening line, and by itself it is not an answer. The consequences are what matter: tuples are hashable so they can be dictionary keys and set members while lists cannot, tuples are slightly lighter, and using a tuple communicates that a collection is not meant to change. The follow-up that separates candidates is the mutable default argument, where a default value is evaluated once at function definition time rather than on each call, so a list default accumulates across calls and produces a bug that is very hard for a beginner to diagnose.

The fix is to default to None and construct inside the function. Expect the neighbours too: shallow versus deep copy, where slicing a nested list copies only the outer list so the inner lists remain shared, the difference between is and double equals where is compares identity and double equals compares value, and why small integers appear to break that rule because of interning. Then dictionaries and their methods, list comprehensions, generators versus lists where the answer is memory since a generator yields lazily, decorators at a surface level, and how Python handles OOP including self and dunder methods. Prepare demonstrations rather than definitions, because three lines of code answers this family faster than a paragraph.

# Mutable default argument, evaluated once at definition
def collect(item, bucket=[]):
    bucket.append(item)
    return bucket

print(collect('a'))     # ['a']
print(collect('b'))     # ['a', 'b']   <- surprising

def collect_fixed(item, bucket=None):
    bucket = [] if bucket is None else bucket
    bucket.append(item)
    return bucket

# Tuples are hashable, lists are not
seen = {(1, 2), (3, 4)}          # fine
# seen = {[1, 2]}                # TypeError: unhashable type: 'list'

# Shallow copy shares the inner objects
import copy
outer = [[1, 2], [3, 4]]
shallow = outer[:]
deep = copy.deepcopy(outer)
shallow[0].append(9)
print(outer)   # [[1, 2, 9], [3, 4]]
print(deep)    # [[1, 2], [3, 4]]

# Generator: constant memory, list: all in memory at once
squares_gen = (x * x for x in range(10**6))

Answer

Breadth over depth, with one clear sentence and one concrete example per topic. On operating systems: process versus thread, where the useful distinction is that threads share an address space and processes do not, which is why threads are cheap and why they need synchronisation. Deadlock and its four necessary conditions with how you break one.

Virtual memory and paging conceptually, plus thrashing. CPU scheduling with at least round robin and first come first served, and the idea of starvation. Semaphore versus mutex, where a mutex has ownership and a semaphore is a counter.

On networking: the OSI layers with a protocol named for each, TCP versus UDP where the honest answer is reliability and ordering against latency and overhead, with file transfer and live video as the respective examples. What happens when you type a URL and press enter, answered as a chain from DNS resolution through the TCP handshake, TLS negotiation, HTTP request, server response, and rendering, which is the most asked networking question in Indian interviews. HTTP status code families and what a 4xx versus a 5xx tells you about who is at fault.

IP addressing, subnetting at a basic level, and what DNS actually does. A weak answer is a definition with no example attached, since the panel is sampling whether concepts are connected to anything real.

Answer

It is asked because you will join a delivery team running a defined process within weeks, and the panel wants to know whether you will understand the vocabulary in your first sprint planning meeting. Cover the life cycle phases, requirement gathering, analysis, design, implementation, testing, deployment, and maintenance, then contrast the two dominant models. Waterfall is sequential with a full specification up front, works when requirements are stable and regulatory sign-off matters, and fails when requirements change because change is expensive late.

Agile is iterative, delivering working software in short cycles with continuous feedback, and it trades predictability of scope for adaptability. For Agile specifics know the Scrum vocabulary and be able to define each briefly: sprint, usually two weeks, backlog, user story with acceptance criteria, story points as a relative estimate rather than hours, daily stand-up and its three questions, sprint review and sprint retrospective, and the roles of product owner, scrum master, and development team. Also know what a definition of done is and why it exists.

If you have used any of this in a college project, say so concretely, because a candidate who says 'we ran two-week sprints and kept a backlog on Trello' is far more credible than one reciting the Agile manifesto. Do not claim to have been a scrum master in a college project.

Answer

Ninety seconds, four beats, and no autobiography. The panel already has your resume, so they are not collecting facts, they are assessing spoken fluency, structure, and confidence, and they are choosing what to ask next. That last point is why this question is an opportunity rather than a formality: whatever you emphasise is what they will probe, so lead them to your strongest ground.

Beat one, who you are academically in a single line. Beat two, your strongest technical area named specifically, one language and one domain. Beat three, one project or internship with a concrete result, ideally with a number in it, and this is the thread you want pulled.

Beat four, why you are here, connecting what you have done to the role. Failures that cost candidates: starting with birthplace and family, listing every subject studied, running past three minutes, and delivering something so obviously memorised that it sounds flat. Practise until fluent but stop short of word perfect, because a recited answer invites an interruption designed to knock you off script.

Nothing in this answer should be undefendable, since every noun in it is a potential question. Close with a clear full stop rather than trailing into silence.

SAMPLE ANSWER, about 90 seconds

"I am Sneha Iyer, a final year Computer Science student at RV College of
Engineering, graduating in 2026 with 8.4 CGPA.

My strongest area is Java, along with SQL and database design. I have also
worked with Spring Boot for the backend of my main project.

That project is a hostel complaint management system that is actually running
for about 600 students in my college. I owned the backend and the database.
The interesting problem was that complaints were being duplicated when
students submitted twice, so I added an idempotency check on the request and
the duplicate rate went to almost zero.

I am interested in Infosys because I want a structured start where I learn how
large systems are actually built and maintained, rather than only how they are
written."

WHY THIS WORKS
- Four beats, under 90 seconds, no family history and no subject list
- The project beat carries a real problem, a real fix, and a real user base
- Every claim invites a question the candidate can answer
- The closing reason is about the work, not about the brand or the salary

Answer

The panel assumes you applied broadly and will not be offended by it, so do not perform exclusivity. What they are testing is whether you know anything specific or are reciting a template that would fit any employer. Generic praise about being a large IT company with good learning opportunities is what most candidates say and it registers as nothing.

Build the answer from three specific things. Something about the work: the range of domains and clients means the problem types vary across your career in a way a single-product company cannot offer. Something about your own path: what you want your first two years to look like and why a structured training and delivery environment suits that better than being the only engineer in a small team.

And something you actually researched, whether that is the training programme, a business unit, a technology area, or a publicly discussed initiative. If asked directly whether you have other offers or applications, answer honestly and say what would make you choose this one, because honesty scores better than a transparently false claim and panels are practised at spotting the latter. Avoid anything that sounds like you are choosing the company for stability alone, since that reads as low ambition even when it is true.

Answer

This is a filter, not conversation, and hesitation here rejects candidates who cleared every technical round. Delivery centres are spread across Bengaluru, Mysuru, Pune, Hyderabad, Chennai, Bhubaneswar, Chandigarh, Nagpur, Thiruvananthapuram, and more, and allocation follows project demand rather than preference. Answer yes without qualification first, then add substance in one sentence: you have discussed it at home, there is no constraint, and you have a preference only if a choice exists.

On technology, understand that a meaningful share of fresher allocation goes to maintenance, production support, testing, and older stacks, and those projects are real skilled work that funds the business. Say yes and give a genuine reason rather than a compliant one, for example that support work teaches you how a system behaves in production under real load, which greenfield work does not. Then name your interest area once as a longer-term aspiration and ask how internal movement works, which reads as planning rather than resistance.

On shifts, if a project runs to a client time zone, say yes and mention that you have thought about transport and sleep, which makes it credible. Never give a false yes on any of the three, because the cost of discovering it lands on your team within weeks.

Answer

For strengths, name one, not three, and prove it with an incident rather than an adjective. Saying you are a hard worker is unverifiable and therefore worthless. Saying that you are persistent with debugging, and that during your project you spent two days isolating an intermittent failure that turned out to be a race condition in your update logic, is a claim with evidence attached.

Pick a strength that is actually relevant to the job, and if you have a number, use it. For weaknesses, the failure modes are well known to every HR panel: the disguised strength such as being a perfectionist or caring too much, the fatal weakness such as struggling to meet deadlines, and the non-answer such as saying you have none. What works is a real, moderate, non-fatal weakness plus the specific mechanism you use to manage it, and evidence that the mechanism is working.

For instance, that you tend to keep working on a problem alone for too long before asking for help, that you now set a rule of asking after forty five minutes of no progress, and that this changed how your last project went. What is being scored is self-awareness and whether you act on feedback, not the weakness itself. Never name a weakness that is a core requirement of the role.

SAMPLE ANSWER, weakness

"My weakness is that I used to stay on a problem alone for too long before
asking anyone. In my third semester project I lost nearly two days on a
database connection issue that my teammate solved in ten minutes once I
finally showed him.

After that I made a rule for myself. If I have made no progress in forty five
minutes, I write down what I have tried and I ask. In my final year project I
actually used it, and the two blockers I hit took hours instead of days.

I still have to consciously apply the rule, it is not automatic yet."

WHY THIS WORKS
- A real weakness, not a disguised strength
- A specific incident, so it is credible rather than invented
- A concrete mechanism and evidence it worked
- The honest closing line makes the whole answer more believable

Answer

One sentence of fact, one of reason, one of what you did with the time, then the current status. Keep it short, because the length of your explanation signals how you feel about it, and a two-minute defence of a one-year gap sounds like concealment even when nothing is being concealed. Eligibility rules on gaps and backlogs vary by drive and are stated in the job posting, and it is common for offers to require all backlogs cleared before joining, so know your own status precisely to the semester and never round it in your favour.

Background verification checks academic records directly, and a discrepancy found later is treated far more seriously than the gap itself, so accuracy protects you. For a preparation gap, name what you were preparing for and be honest if it did not work out, then say what you learnt and what you did alongside. For a health or family reason, one factual sentence is sufficient and you owe no medical detail.

For backlogs, give the number, the subject, why it happened, and the current cleared or expected date. What the panel is scoring is composure with an uncomfortable fact, and candidates lose more marks to a defensive tone than to the fact itself.

Answer

Have two ready and make them about the work. Saying no is noted and reads as either low interest or as not having thought about the job as something you will actually do day to day. Good options: what does the first six months look like for someone joining in this role, how does project allocation work after training and how much input does a new joiner have, what does the training programme cover and how is it assessed, what would a strong first year look like from your side, and how does internal movement between technologies work later.

Each of those signals that you are thinking about doing well rather than about getting in. Avoid raising salary in a technical or managerial round, since HR owns that conversation and raising it early reads as transactional. Avoid asking anything answered on the company website, because it demonstrates you did not look.

Avoid opening with leave policy, work from home, or appraisal timing, not because those are illegitimate but because as your first question they announce what you are optimising for. Then actually listen to the answer and respond to it, since a candidate who asks a question and shows no interest in the reply looks like they were ticking a box.

Answer

New joiners typically go through a structured foundation programme, historically centred on the Mysuru campus, covering programming fundamentals, a technology stream, database work, and professional and communication skills, running over a period of weeks with periodic assessments. Two things surprise people. It is genuinely demanding, with a full daily schedule, regular tests, and a pace set by the trainer rather than by you, and it is residential in the campus model, which is a significant lifestyle change for many joiners.

Performance matters beyond the certificate: training results commonly influence which stream and which project you are allocated to, so the difference between coasting and engaging shows up in the work you spend your first two years doing. The failure pattern is predictable and avoidable. Candidates who have just cleared a competitive selection process treat the first three weeks as a break, fall behind on assignments, and then find the assessment genuinely hard.

Treat it as your job from day one, complete assignments the day they are set rather than in weekend catch-ups, and use the trainers heavily because they are far more accessible than senior people on a project will be later. Ask about the retake and remediation policy at the start rather than after you need it.

Answer

Policies vary by year and by programme, so what follows is the general shape rather than a rule. A single failed assessment is usually recoverable, typically through a retake, additional support, or an extended training period, and it is not by itself career ending. Repeated failure is more serious and has, in various cycles across the Indian IT services sector, led to extended training, reassignment to a different stream, and in some cases termination of employment, which is why treating training casually is a genuine risk rather than a scare story.

The practical guidance is preventive rather than remedial. Track your own understanding weekly rather than waiting for the assessment to tell you, because the gap between feeling fine and being fine is where people get caught. If you are struggling with a topic, raise it with your trainer early, since support requested proactively is routine and support requested after a failure looks different on your record.

Form a study group, because the training cohort is the single best peer network you will have and people who study alone through it do measurably worse. If you do fail, do not go quiet. Approach your trainer immediately, ask exactly what the remediation path is, and follow it precisely, because how you respond to the failure is itself observed.

Answer

Indian IT services employers commonly attach a service agreement to fresher offers, committing you to remain for a stated period after joining or after completing training, with a stated liability if you leave early. Terms differ by year, track, and role, so the only document that matters is the one you are personally asked to sign, not what a senior from another batch describes. Before signing, get clarity in writing on: the exact duration and whether the clock starts at your date of joining or at completion of training, the exact amount payable and whether it reduces on a pro rata basis as you serve, what triggers the liability including whether resignation during training is treated differently, what happens if the company terminates you rather than you resigning, whether any original academic documents are to be submitted and the process for retrieving them, and the notice period, which is a separate obligation from the service agreement.

Ask by email so the answer is on record. Being asked in an interview whether you are comfortable with a service agreement is entirely routine, and saying yes while adding that you would like to read the terms is professional and will not be held against you. Never sign a document you have not read on the assumption that everyone signs it.

Answer

Fresher offers are made against a demand forecast and onboarding happens when project demand and training capacity align, so a gap of several months between offer letter and joining date is common in Indian IT services, and it has run considerably longer in weak demand cycles. That is normal and not by itself a sign that your offer is at risk, but you should plan your finances and your other applications realistically. During the wait, keep your registered email active and check spam, respond to every communication quickly since non-response is one of the few things that genuinely endangers an offer, and complete any pre-onboarding learning assigned to you because completion is frequently tracked.

On background verification, it is usually run by a third-party agency covering identity, address, education, prior employment, and often a criminal record check. Candidates worry about the wrong things: verification rarely fails because of a modest CGPA or an honestly declared gap, it fails on discrepancies, mismatched employment dates, an inflated job title, a salary figure your payslips do not support, an omitted short stint, or a certificate from an institute that cannot verify it. Declare everything, keep your documents in one folder, and if you know of a genuine discrepancy, disclose it proactively, because a disclosed issue is manageable and a discovered one usually is not.

Answer

Lateral hiring is demand driven rather than pool driven, and that changes the whole shape. There is usually no aptitude test and no pseudocode section. You are interviewed against a specific open position on a specific account, so the technical round goes deep on the exact stack named in the job description rather than on general fundamentals, and your last two years of work matter far more than your degree or your college.

Expect one or two technical rounds, a round with the manager who owns the requirement, and an HR round covering compensation and notice period. Prepare differently: rehearse a five-minute walkthrough of your current project including its architecture and why decisions were made, be precise about what you personally owned rather than what your team delivered, and bring numbers, team size, release cadence, ticket volume, or a measurable improvement you contributed to. Commercially, notice period is a live issue, so if you are serving ninety days raise buyout early rather than at offer stage, because whether it is supported varies by requirement and urgency.

Be exact about your current fixed CTC because payslips are verified. The weakest lateral candidates describe everything in the plural and cannot separate their contribution from their team's. The strongest have numbers and can defend individual ownership under questioning.