Cognizant Interview Questions and Answers

Answer

GenC is the standard entry programme for freshers, and as of 2026 candidates typically report offers around the ₹4 to ₹4.5 LPA range for it. GenC Next is the higher band programme, positioned for candidates who clear a harder selection funnel, and candidates typically report it around the ₹6.5 to ₹7 LPA range, with a figure close to ₹6.75 LPA quoted most often. Between the two, candidates in particular hiring cycles have also referred to variants such as GenC Pro and GenC Elevate, generally described as sitting above GenC and below or near GenC Next, roughly in the ₹5 to ₹6.5 LPA region.

I would treat every one of those numbers as indicative rather than official. Which programmes actually run, what they are called, and what they pay changes by year, by batch and by whether the drive is on campus or off campus, and Cognizant does not publish a fresher pay scale. What is stable across cycles is the structure: one baseline programme with volume hiring, and at least one premium programme gated behind a harder assessment.

The tactical implication is simple. Find out which programmes your specific drive is running before you prepare, because preparing for GenC and being tested for GenC Next is the most avoidable way to lose a band.

Answer

Candidates consistently describe the GenC Next funnel as materially tougher in three specific ways rather than uniformly harder. First, coding: where the standard track leans on easy to moderate string, array and number logic, the premium track pushes into harder problems, tighter constraints and more emphasis on approach and complexity rather than just a passing submission. Second, interview length and depth: candidates report longer technical rounds, more follow up chains where the panel keeps pulling on one answer, and less tolerance for memorised definitions.

Third, breadth: the premium track puts real weight on full stack awareness and problem solving, so a candidate who can only discuss backend logic and cannot describe how a request reaches it will be capped. It is almost always worth attempting. In most drives the additional stage is optional and clearing it moves you into a higher band, while not clearing it typically leaves the standard track offer intact, though you should confirm that for your specific drive rather than assume it.

The candidates who regret it are the ones who declined the extra round to save two hours and later discovered a batchmate with similar skills is earning noticeably more for the same work. Confirm the fallback rule, then attempt it.

Answer

Decide from two honest inputs: your current coding baseline and your available weeks. If you can comfortably solve easy problems on any practice platform and occasionally clear a moderate one, and you have six weeks or more, target the premium track, because the delta in preparation is concentrated in coding and full stack basics rather than spread across everything. If you are still struggling with basic array and string manipulation, or you have under three weeks, target the standard track and make certain you clear it, because a candidate who overreaches and fails both gates has nothing.

The middle case, meaning a reasonable coder with four to five weeks, should prepare for the premium track but explicitly protect the fundamentals, since the standard track assessment is a subset of what the premium one tests and preparation is not wasted. What people get wrong is deciding by ambition rather than by baseline, then splitting attention across advanced algorithms and neglecting aptitude, which is where they actually get eliminated. Run one honest timed diagnostic before choosing: a mixed aptitude set and two coding problems under a clock. Your score on that decides the track, not how you feel about your own potential.

Answer

They expect coherence across the stack, not expertise in any layer. Concretely: you should be able to describe how a browser request reaches your backend, what a REST endpoint is and what the common HTTP methods and status codes mean, what goes in a request body versus a query parameter versus a header, how JSON is exchanged, and how the backend reaches a database and returns a result. On the frontend side, know what component state is, why the UI re renders when it changes, what happens on a form submit, and how you would show a loading and an error state.

On the connective tissue, know what CORS is and why it bites you locally, what authentication versus authorisation means in an API context, roughly how a token based session works, and why you never store a secret in frontend code. Know what an environment variable is for. If you have deployed anything anywhere, say so, because deployment experience is disproportionately rare among freshers.

The failure mode is a candidate who lists 'React, Node, MongoDB' but cannot say what happens between clicking a button and a row appearing in the database. A weak answer names frameworks; a strong one traces one request end to end through the code you personally wrote.

Answer

The pattern candidates most commonly report is that the premium track assessment is an additional gate layered on top of the standard process, so missing it usually leaves you in consideration for the standard programme rather than removing you from the drive. That said, this is a drive level rule and not a universal policy, and there have been cycles where the tracks were run as separate applications with separate eligibility. Because it varies, ask the question explicitly before you attempt the extra stage: does a miss on this round affect my standard track candidature, yes or no. Recruitment contacts answer that question routinely and it takes one message.

Two practical points follow. First, if the answer is that your standard candidature is unaffected, there is no rational reason to skip the extra round. Second, if the drive is running the tracks as separate applications with different criteria, then you are making a real choice and should decide from your diagnostic score rather than from optimism.

The mistake to avoid is assuming a forum comment describes your drive. Programme structures at large services employers change between hiring cycles more often than candidates expect.

Answer

As of 2026 the process candidates typically describe has four phases. One, registration and eligibility screening, either through a campus drive or the careers portal, where degree, branch, graduation year, aggregate and backlog status are checked before a slot is issued. Two, the online assessment, which is usually a single proctored sitting with sectional timers covering quantitative aptitude, logical reasoning, verbal ability and an automata style coding section where you complete function stubs against hidden test cases.

Some drives add a communication or essay component. Three, the technical interview, covering data structures at a moderate level, object oriented programming, DBMS and normalisation, SQL joins, one language at depth, and a project walkthrough, with full stack questions added for the premium track. Four, the HR round, covering the service agreement, relocation, shift willingness, availability and general fit.

Premium track candidates typically face an extra or extended technical stage. Section counts, timers and cutoffs vary by drive, so treat any fixed number as indicative. If this is asked in the room, the panel is checking whether you researched anything.

A weak answer is 'aptitude test then interview'. A strong one names the automata coding format specifically, because that format catches unprepared candidates.

Answer

The four blocks candidates consistently report are quantitative aptitude, logical reasoning, verbal ability and coding. Quantitative aptitude covers percentages, ratio and proportion, averages, profit and loss, simple and compound interest, time speed and distance, time and work, permutations and combinations, probability, number system and mensuration. Logical reasoning covers series, coding and decoding, blood relations, direction sense, syllogisms, seating arrangement, puzzles and data sufficiency.

Verbal ability covers reading comprehension, sentence correction, error spotting, para jumbles, fill in the blanks and vocabulary in context. Coding is automata style, meaning you complete a given function stub in a browser editor and are scored on hidden test cases rather than on visible output. On weighting, drives commonly apply sectional cutoffs, meaning a strong overall score does not save you from failing one section, so the correct strategy is to be uniformly adequate rather than brilliant in one block and weak in another.

Candidates lose most often on coding, because they practise in an IDE with autocomplete and then face a plain editor, and on logical reasoning puzzles, because those consume time disproportionately. Treat every section as individually survivable rather than as contributions to one total.

Answer

Treat each section as its own paper with its own budget and assume there is no return path, because proctored platforms commonly lock a section once its timer ends. Inside each section, run a two pass sweep: pass one, answer only what you recognise within a few seconds and mark anything requiring work, pass two, return to the marked items with the remaining time. This prevents the standard failure where four minutes on one puzzle costs you eight easy questions at the end.

Set an abandon threshold before the test, for example ninety seconds for aptitude and reasoning, and honour it mechanically rather than by feel. Handle coding differently: read all the given problems first, then start with the one whose statement you fully understand, not the one that looks shortest, because an ambiguous statement burns time in a way a longer clear one does not. Leave a fixed buffer, say five minutes, at the end of the coding block to run your solution against the edge inputs rather than submitting the moment the sample passes.

If negative marking is not announced, never leave a blank. What separates candidates here is having decided all of this before the timer started, rather than improvising while the clock runs.

Answer

It is testing functional business English, not literature. The question types recur predictably: reading comprehension with inference and tone questions, sentence correction, error spotting, para jumbles, fill in the blanks with contextual vocabulary, and synonyms or antonyms in context. The fastest marks come from error spotting and sentence correction, because both respond to a fixed checklist rather than to reading volume.

Run the checklist in the same order every time: subject verb agreement, tense consistency, preposition usage, article usage, pronoun reference and parallel structure. That order catches most planted errors and it protects you from intuition, which is unreliable here because several constructions common in spoken Indian English are marked wrong on these tests, for example 'discuss about', 'return back', 'cope up with' and 'one of the student'. For reading comprehension, read the questions first and then scan for the relevant paragraph, since most questions are locatable rather than holistic.

For para jumbles, identify the opening sentence by elimination, because an opener rarely begins with a pronoun, a connector like 'however', or a reference to something not yet introduced. The approach that wastes time is memorising word lists, which builds recognition without usage and then fails the contextual fill in the blanks it was meant to help with.

Answer

Weeks one and two, build the aptitude base: one hour quantitative, one hour logical reasoning, thirty minutes verbal daily, all timed from day one, because untimed practice hides the only problem that matters. Weeks three and four, coding becomes the centre: one language, forty five to sixty problems covering arrays, strings, hash maps, two pointers, sorting, searching, basic recursion and simple frequency or counting patterns, all written in a plain editor with no autocomplete. Week five, interview surface: object oriented programming with output prediction snippets, DBMS with normalisation and ACID, SQL joins and aggregation, operating systems and networking basics, and full stack fundamentals if you are targeting the premium track.

Week six, integration: two full length timed mocks, a written and rehearsed project walkthrough, and rehearsed answers for the HR questions on service agreement, relocation and shift. Keep aptitude alive across weeks three to six with a twenty minute daily set, because aptitude decays faster than coding. The plan that fails allocates five of six weeks to whichever activity the candidate already enjoys, then meets a puzzle heavy reasoning section or an unrehearsed project question cold.

Answer

The high frequency topics are percentages, ratio and proportion, averages, profit and loss, simple and compound interest, time speed and distance, time and work, mixtures and alligation, number system including HCF, LCM and remainders, permutations and combinations, and probability. Speed comes from three habits rather than from cleverness. First, memorise the tables to twenty, squares to thirty, cubes to fifteen and the common fraction to percentage conversions, because roughly a third of the arithmetic in a typical set is conversion work that you should not be computing.

Second, use the standard shortcuts where they genuinely apply: for time and work, treat the total work as the LCM of the individual times so you work in integer units instead of fractions; for percentage changes, use the successive change formula rather than computing twice; for profit and loss, work in ratios rather than absolute rupees when the question is proportional. Third, and this is the one people skip, practise deciding which questions to leave. In a timed section, an unattempted hard question costs you nothing beyond its own mark, while a half attempted one costs you two other questions. What fails is learning shortcuts without practising selection, so you solve everything correctly and finish sixty percent of the paper.

Answer

The recurring types are number and letter series, coding and decoding, blood relations, direction sense, syllogisms, analogies, odd one out, data sufficiency, seating arrangement and general arrangement puzzles. Sort them by time cost, not by difficulty. Series, coding and decoding, analogies and odd one out are fast, usually under forty five seconds each once you have practised, so attempt them first and bank the marks.

Blood relations and direction sense are fast if you draw, which you should always do, since a two second diagram removes the entire ambiguity. Syllogisms are fast if you use Venn diagrams and slow if you reason verbally, and the specific trap is the word 'possibility' in conclusions, which changes what is provable. Seating arrangement and multi condition puzzles are the expensive ones, often three to six minutes for a set of four or five questions, which is excellent value if you crack the arrangement and a disaster if you do not.

Attempt those last, and only after you have swept everything else. Within a puzzle, start from the most restrictive constraint rather than reading conditions in order, because the constraint that fixes a position collapses the search space fastest. What loses marks is attacking the puzzle set first because it appears first on screen.

Answer

The shortcuts worth internalising are the ones that convert a multi step computation into one step and are safe under all inputs. Successive percentage change combines two changes into one so you never compute twice. Total work as the LCM of individual times removes fractions from time and work entirely.

Working in ratio units instead of absolute values keeps profit and loss arithmetic small. Options based elimination on a divisibility or last digit property discards two or three choices before you compute anything. Back substitution from the options is often faster than solving an equation, particularly for age, mixture and number problems.

The shortcuts that cost marks are the ones with hidden conditions. Approximation is dangerous when two options are close together, so check the option spread before you round. Assuming a convenient value such as one hundred is safe for percentage problems where the base cancels and unsafe when the question asks for an absolute quantity.

Averaging speeds directly is simply wrong for a two leg journey where the harmonic mean applies, and it is one of the most reliably planted traps. The rule to carry in is that a shortcut you have not verified on at least ten practice problems is not a shortcut, it is a guess with extra confidence.

SAFE SHORTCUTS WORTH MEMORISING

Successive percentage change (a then b):
  net = a + b + (a * b / 100)
  Example: +20 percent then 10 percent
  = 20 + (10) + (20 * 10 / 100) with b = 10 taken as minus 10
  = 20 - 10 - 2 = +8 percent

Time and work, LCM method:
  A alone 12 days, B alone 18 days
  Total work = LCM(12, 18) = 36 units
  A rate = 3 units/day, B rate = 2 units/day
  Together = 5 units/day => 36 / 5 = 7.2 days

Average speed for equal distances (harmonic, NOT arithmetic):
  avg = (2 * s1 * s2) / (s1 + s2)
  60 and 40 => (2*60*40)/100 = 48, not 50

TRAPS
1. Rounding when two options are within 2 percent of each other.
2. Assuming base = 100 when the answer must be an absolute amount.
3. Arithmetic mean of speeds on an equal distance journey.

Answer

Read the chart or table headers, units and footnotes before reading a single question, because most data interpretation errors are unit errors: values in lakhs read as thousands, a percentage of a subtotal read as a percentage of the total, or a footnote excluding one category. Then scan all questions in the set and classify them. Direct lookups and single ratio questions are cheap and should be answered first.

Questions requiring you to compute several values and compare them are expensive and go last. Questions asking 'which of the following is true' with four sub statements are the most expensive of all, because each option is effectively its own question, so attempt those only if time remains. On computation, approximate aggressively for comparison questions where you only need an ordering, and compute exactly only when the options are close.

Convert repeated denominators once and reuse. Under time pressure the discipline that saves you is finishing the cheap questions across every set before returning to expensive ones anywhere, because marks are equal regardless of effort. What loses marks is solving a set linearly from question one, which guarantees you spend your last minutes on the hardest item in the paper.

Answer

Draw the frame first, physically, with the correct number of positions and the correct orientation, since a circular arrangement facing centre and one facing outward produce opposite left and right, and getting that wrong invalidates every deduction. Then read all conditions once and rank them by restrictiveness rather than applying them in the order given. A condition that fixes an absolute position, for example 'C is at position two', is worth more than a relative condition like 'A is not next to B'.

Apply the absolute ones first, then the strong relative ones such as 'D is immediately to the left of E', which behave as a single fused block you can slide as a unit. Keep negative conditions in a separate list and use them only for elimination, never as a starting point. When you reach a genuine branch, meaning two placements remain equally valid, mark the branch explicitly and pursue one to a contradiction rather than holding both mentally, because holding a branch in your head is where errors enter.

Verify the completed arrangement against every condition, including the ones you already used, before answering, since a set of five questions on a wrong arrangement loses all five. If you have not fixed any position after ninety seconds, the set is not cracking quickly and you should move on.

Answer

In an automata style round you are given a function stub with a fixed name, a fixed signature and a fixed return type, and you fill in only the body. You usually do not write a main function, you do not read from standard input, and you must not print anything, because your return value is compared against expected outputs on hidden test cases. That format catches candidates who have only ever practised on platforms where they parse input themselves, because their instinct is to add input reading and printing, which either breaks compilation or produces spurious output that fails the comparison.

Other differences that matter: the editor is plain, with little or no autocomplete or error highlighting, so syntax you normally get corrected for becomes your problem. Compilation is often on a timer and repeated failed compiles cost you real minutes. Partial scoring is common, meaning a solution that handles the general case but misses one boundary can still earn marks, so a working imperfect solution beats an unfinished elegant one. The preparation implication is direct: practise writing complete, compiling functions in a plain text editor, and practise reading a stub signature carefully, because the parameter order and return type tell you what the problem actually wants.

Answer

This is a representative automata style problem: the brute force is obvious, the intended solution is a small insight, and the hidden tests punish sloppiness. The brute force checks every pair, which is O(n squared) and will exceed the time limit at the upper constraint. The insight is that only remainders matter: a pair sums to a multiple of K exactly when their remainders modulo K add to K or to zero.

So count how many numbers fall into each remainder bucket, then combine bucket r with bucket K minus r. Two buckets need care. Remainder zero pairs only with itself, giving a count of n choose 2 within that bucket, and when K is even, the bucket at K divided by two also pairs only with itself.

The traps the hidden tests use are negative numbers, where the modulo operator in C, C plus plus and Java can return a negative remainder so you must normalise it, and the count itself overflowing a 32 bit integer when N is large, since the number of pairs grows quadratically. What the interviewer probes if this is asked live is whether you state the brute force, then improve it, and whether you name the overflow risk without being prompted. A weak answer submits the nested loop and calls it done.

/* Automata gives you the stub. Do not rename it, do not add a main,
   do not print anything, just return the value. */

long long countDivisiblePairs(int arr[], int n, int k) {
    if (k <= 0 || n < 2) return 0;

    long long freq[k];
    for (int r = 0; r < k; r++) freq[r] = 0;

    for (int i = 0; i < n; i++) {
        int r = ((arr[i] % k) + k) % k;   /* normalise negative remainders */
        freq[r]++;
    }

    long long pairs = freq[0] * (freq[0] - 1) / 2;   /* bucket 0 pairs itself */

    for (int r = 1; r <= k / 2; r++) {
        if (r == k - r) {
            pairs += freq[r] * (freq[r] - 1) / 2;    /* k even, middle bucket */
        } else {
            pairs += freq[r] * freq[k - r];
        }
    }
    return pairs;
}

COMPLEXITY: O(n + k) time, O(k) space. Brute force is O(n^2) and times out.

HIDDEN TESTS TARGET
1. Negative values, where a % k can be negative in C, C++ and Java.
2. k = 1, every pair qualifies, answer is n*(n-1)/2.
3. Large n, where the pair count overflows a 32 bit int.
4. n = 0 or n = 1, answer is 0.

Answer

Write in the language you can produce compiling code in without documentation. For most Indian candidates that is C, C plus plus, Java or Python, and Java or Python are usually the safer picks because collection and string handling is less error prone than manual memory work in C. Do not choose a language to look impressive; a shaky C plus plus solution with a pointer mistake scores zero against a plain Java solution that works.

The stub discipline is specific and worth rehearsing. Do not rename the function or change the signature, because the grader calls it by name. Do not add a main function unless the problem explicitly asks for one.

Do not print anything, including debug output you forgot to remove, since stray output is a common cause of a solution that works locally and fails the grader. Return exactly the type declared, and if the return is a collection or an array, confirm whether the problem expects it sorted. Read the parameter order twice, because a signature like solve(int arr[], int n, int k) is passing you the length separately and using arr.length or sizeof will be wrong. Compile early rather than writing the entire body first, because a plain editor gives you no error hints and one missing brace can cost several minutes near the end.

Answer

Debugging style questions give you a function that almost works, and they are scored the same as writing one from scratch but reward a different skill. Resist the urge to rewrite. The intended defect is usually one or two lines, and a rewrite loses the time advantage the format was giving you.

The method: first read the function signature and the problem statement together and state in one sentence what the function is supposed to return, because half of these bugs are the code doing something reasonable that is not what was asked. Second, check the loop bounds, since off by one on a less than versus less than or equal is the single most common planted defect. Third, check the initialisation, because accumulators seeded with zero when they should hold the first element, or minimum trackers seeded with zero when values can be negative, are the second most common.

Fourth, check the condition operators for an inverted comparison or an assignment written where an equality check belongs. Fifth, dry run on the smallest input that could fail, typically an array of length one or an empty input. What fails is scanning for something that 'looks wrong' aesthetically. Planted bugs are deliberately plausible looking, so use the checklist rather than intuition.

Answer

Sample cases show the happy path; hidden cases target the boundaries, so a low score is a diagnosable defect rather than bad luck. Ranked by frequency: unhandled edge inputs, meaning empty input, a single element, all elements identical, all negative values, or the maximum stated N. Integer overflow, where a sum, product or pair count exceeds a 32 bit type and wraps silently instead of erroring.

Time limit exceeded, where a nested loop was acceptable on the sample but not at the stated constraint, which is why you should always read the constraints before choosing an approach. Wrong return shape, meaning returning an unsorted collection where sorted was expected, or returning a count where the problem wanted the elements. Stray printing left in from local debugging, which corrupts the comparison.

Language specific modulo behaviour on negative numbers, which silently produces wrong bucket counts. Uninitialised variables in C and C plus plus, which pass locally by accident and fail on the grader. Build a five item pre submit checklist and run it every time: smallest input, largest input, all identical, all negative, correct return type and shape. Forty seconds of checking recovers more marks than an extra week of new problems.

Answer

Moderate is the honest description. The realistic surface is arrays and strings with confident manipulation, linked lists including reversal, cycle detection and finding the middle, stacks and queues with genuine use cases such as expression evaluation and level order traversal, hash maps and when they beat an array, binary trees with inorder, preorder, postorder and level order traversal, binary search trees with search and insert, recursion with a clearly stated base case, and the common sorting algorithms with their complexities and stability. Big O should be automatic for every operation you name, including the average and worst case difference for a hash map.

Usually out of scope: advanced dynamic programming, graph algorithms beyond basic traversal, segment trees, tries and anything competitive programming flavoured, though premium track panels may push one step further. Where candidates lose marks is articulation, not depth. Being unable to state the complexity of a lookup you just described, or explaining a tree traversal without drawing the tree, reads as memorised rather than understood.

Always take the paper or the whiteboard. A weak answer is a recited optimal solution the candidate cannot justify, or 'I know the concept but I would need to look up the code', which signals you never implemented it.

Answer

Output prediction snippets are a favourite because they separate candidates who memorised the four pillars from candidates who understand dispatch and initialisation order. Two behaviours are being tested here. First, constructor and field initialisation order: when you construct a subclass, the superclass constructor runs before the subclass field initialisers.

So if the superclass constructor calls an overridden method, that method runs in the subclass but sees subclass fields still at their default values, which is why x prints as 0 and not 5. This is a genuine production bug pattern, not a puzzle, and the correct guidance is never to call an overridable method from a constructor. Second, static method hiding versus instance method overriding: static methods are bound at compile time to the reference type, while instance methods are dispatched at runtime to the object type.

So through a superclass reference pointing at a subclass object, the static call resolves to the superclass version while the instance call resolves to the subclass version. What the interviewer probes is whether you can explain why, not just state the output. A weak answer guesses the output correctly by pattern matching and then cannot say why the field is zero, which is the entire point of the question.

class Parent {
    Parent() {
        System.out.println("Parent constructor");
        show();                       /* overridable call from a constructor */
    }
    void show()        { System.out.println("Parent show"); }
    static void greet() { System.out.println("Parent greet"); }
}

class Child extends Parent {
    int x = 5;
    Child() {
        System.out.println("Child constructor, x = " + x);
    }
    @Override
    void show()        { System.out.println("Child show, x = " + x); }
    static void greet() { System.out.println("Child greet"); }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        p.greet();
        p.show();
    }
}

OUTPUT
Parent constructor
Child show, x = 0        /* field initialiser has NOT run yet */
Child constructor, x = 5
Parent greet             /* static: bound to the reference type */
Child show, x = 5        /* instance: dispatched to the object type */

WHY
1. super() runs first, so Parent's constructor executes before x = 5.
2. show() is overridden, so it dispatches to Child even during construction.
3. Statics are hidden, not overridden, so p.greet() uses the Parent version.

Answer

First normal form requires atomic values and no repeating groups, so a student table with a skills column holding 'java, sql, aws' violates it, and the fix is a separate student_skills table with one row per skill. Second normal form applies when the key is composite and requires every non key column to depend on the whole key, so an order_items table keyed by order_id plus product_id that also stores product_name violates it, because the name depends only on product_id, and the fix is to move product_name to a products table. Third normal form removes transitive dependencies, where a non key column depends on another non key column, so an employee table storing pincode and also state violates it, because state is determined by pincode rather than by the employee, and the fix is a pincode reference table.

The follow up that separates candidates is denormalisation. You denormalise deliberately when reads dominate: reporting tables, dashboards, analytics warehouses, or a hot lookup that is effectively static. The cost is update anomalies, since the same fact now lives in two places, so a denormalised copy needs a named owner and a refresh path. A weak answer recites the three forms without a single violating table, which is unmistakably memorised, and then cannot explain why anyone would ever break the rules on purpose.

Answer

These two cover the join concepts a panel actually cares about. The first needs a correlated subquery or a window function. The correlated subquery compares each employee's salary to the average of their own department, which reads clearly but re evaluates per row on some engines.

The window function version computes the department average once per partition and is the answer to give if the panel asks about efficiency. The second question is the standard test of whether you understand outer joins: a LEFT JOIN from departments to employees, filtered on the employee key being NULL, returns exactly the departments with no employees. The trap the panel is watching for is placing a filter on the right hand table in the WHERE clause of a LEFT JOIN, for example WHERE e.status = 'ACTIVE', because rows with no matching employee produce a NULL status which fails that predicate, silently converting the outer join into an inner join and making the empty departments vanish.

The condition belongs in the ON clause instead. What the interviewer probes is whether you know the difference between the join types by behaviour rather than by a Venn diagram. A weak answer draws circles and cannot say what happens to NULLs.

/* 1. Employees earning above their own department average, correlated form */
SELECT e.emp_id, e.emp_name, e.dept_id, e.salary
FROM   employees e
WHERE  e.salary > (
         SELECT AVG(e2.salary)
         FROM   employees e2
         WHERE  e2.dept_id = e.dept_id
       );

/* Same thing with a window function, average computed once per partition */
SELECT emp_id, emp_name, dept_id, salary
FROM (
  SELECT emp_id, emp_name, dept_id, salary,
         AVG(salary) OVER (PARTITION BY dept_id) AS dept_avg
  FROM   employees
) t
WHERE salary > dept_avg;

/* 2. Departments with no employees at all */
SELECT d.dept_id, d.dept_name
FROM   departments d
LEFT JOIN employees e ON e.dept_id = d.dept_id
WHERE  e.emp_id IS NULL;

/* 3. The trap: this silently becomes an INNER JOIN and hides empty departments */
/* SELECT d.dept_name, COUNT(e.emp_id)
   FROM departments d
   LEFT JOIN employees e ON e.dept_id = d.dept_id
   WHERE e.status = 'ACTIVE'
   GROUP BY d.dept_name;                                          */

/* Correct version, the right table filter moves into ON */
SELECT d.dept_name, COUNT(e.emp_id) AS active_headcount
FROM   departments d
LEFT JOIN employees e
       ON e.dept_id = d.dept_id
      AND e.status  = 'ACTIVE'
GROUP BY d.dept_name;

Answer

This is the highest leverage answer in the round because most follow up questions are drawn from it. Use four parts and keep it under two minutes before pausing. One, the problem in a single sentence framed as a user need rather than a technology list.

Two, the architecture in three or four sentences: frontend, backend, database, and how data moves between them. Three, your specific contribution in the first person singular, naming the modules you personally wrote, because in a team of four the panel wants your boundary. Four, the hardest problem you hit and how you diagnosed it, which is the part that earns credibility: a query that got slow and how you found it, a race condition on concurrent submissions, a token expiring mid session, a build that worked locally and failed on the server.

Prepare the standard follow ups: why this database, what breaks at ten thousand users, how did you test it, what would you rebuild differently. The panel is probing whether you built it or watched it get built. A weak answer is 'we made a web app using React, Node and MongoDB with login and CRUD', which is a stack list with no ownership and gives the panel nothing to dig into except your fundamentals, which is exactly where they will go next.

Answer

Start from the resources rather than from the code. The nouns are students, courses, sessions and attendance records. Then the endpoints follow naturally: GET on a collection to list, GET on an identifier to fetch one, POST to create, PUT or PATCH to update, DELETE to remove, with plural nouns in the path and no verbs, so POST to /sessions/{id}/attendance rather than /markAttendance.

Say what each returns: 200 for a successful read, 201 with the created resource for a successful create, 400 for a validation failure, 401 when unauthenticated, 403 when authenticated but not permitted, 404 when missing, 409 on a duplicate, 500 for a server fault. Cover the cross cutting concerns because that is what separates a designed API from a listed one: authentication with a token, authorisation so a student cannot mark another student present, validation on every input, pagination on list endpoints so the response does not grow unbounded, idempotency so a double submitted attendance mark does not create two rows, and a consistent error body shape. Then say how the data model backs it and where the unique constraint lives, since a database level unique constraint on student plus session is what actually prevents duplicates when the application check races. A weak answer lists CRUD endpoints and stops before authorisation and duplicates, which are the interesting parts.

Answer

Name the language you have written the most code in, not the one that sounds strongest. If you say Java, expect object oriented concepts, abstract class versus interface, collections including ArrayList versus LinkedList and how HashMap works at a basic level, checked versus unchecked exceptions, string immutability and the string pool, static versus instance members, and the equals and hashCode contract. If you say Python, expect list versus tuple versus set versus dictionary, mutability and why a mutable default argument is a trap, list comprehensions, shallow versus deep copy, decorators and generators at a light level, and exception handling.

If you say C or C plus plus, expect pointers, dynamic memory, structures, and object oriented concepts in the C plus plus case. The interviewer is testing depth in one place, so declaring four languages simply invites them to probe your weakest. A weak answer is 'I know Java, Python, C, C plus plus and JavaScript', which almost always ends in a question you cannot answer.

A strong answer is 'Java is my primary language, I use Python for scripting', which sets the scope and still shows range. Prepare six or seven core answers deeply in one language rather than twenty shallow ones across four.

Answer

Conceptual depth, with the ability to give an example. On operating systems: process versus thread and why threads share memory, context switching and why it costs, scheduling algorithms at a naming level, deadlock with its four necessary conditions and one prevention approach, mutex versus semaphore, virtual memory and paging, and the difference between concurrency and parallelism. Be ready for 'what is a race condition' with a concrete example, because that is the one they ask when they want to know if you have actually hit it.

On networking: the OSI and TCP/IP layers and what sits at each, TCP versus UDP with a use case for each, the three way handshake, DNS resolution, DHCP, HTTP versus HTTPS and what TLS adds, common status codes, common ports, and the difference between a router, a switch and a hub. If you can also explain what happens between typing a URL and a page rendering, you have covered most of what any panel will ask. The depth expected is a clear explanation, not implementation detail. A weak answer defines a thread as 'a small process' or describes HTTPS as 'HTTP with security' without mentioning certificates or encryption in transit, and both are easy for a panel to catch with one follow up.

Answer

Take Java as the example. A try block contains the risky code, catch blocks handle specific exception types in order from most specific to most general, and finally runs regardless of whether an exception occurred, which makes it the right place for cleanup, although try with resources is the modern way to close streams and connections automatically. Checked exceptions must be declared or handled at compile time and represent recoverable conditions such as a missing file, while unchecked exceptions extend RuntimeException and usually represent programming defects such as a null dereference or a bad index.

Custom exceptions are created by extending Exception or RuntimeException, and they are worth mentioning because they show you have written more than exercises. The things you should say you would never do: catch Exception broadly and swallow it with an empty block, which destroys the evidence and turns a crash into a silent wrong result, catch and log without either rethrowing or genuinely handling, use exceptions for ordinary control flow, and return from a finally block, which discards any exception in flight. In Python the equivalents are try, except, else and finally, with bare except being the anti pattern. A weak answer recites the syntax and cannot name a single thing that is wrong to do, which is what the second half of the question is for.

Answer

They are scoring three things: whether you can structure a spoken answer, whether your story leads logically to this role, and whether you sound easy to work with. They are not asking for a chronological biography. Use four parts across roughly ninety seconds: who you are academically now, one thing you built with a concrete detail, one strength evidenced by a behaviour rather than asserted as an adjective, and why this role follows from the first three.

Specificity is what makes it memorable, so 'an attendance portal used by 300 students in my department' beats 'various projects', and 'I ran a fifteen minute stand up every morning, which is why we shipped two weeks early' beats 'I have good leadership skills'. On the why Cognizant part, avoid interchangeable praise about being a global leader, which every candidate says and which tells them nothing. Name something specific to services delivery: exposure to multiple clients and domains early, the structured programme path, and the technology breadth.

Then stop talking. Rambling past two minutes is the most common failure, because the panel disengages and you lose control of the conversation. A weak answer recites school, marks and hobbies with no link to the work, delivered flatly, and it costs you the momentum for the whole round.

SAMPLE ANSWER

"I am a final year Computer Science student in Coimbatore, graduating this year with around 79 percent. The thing I am most proud of is an attendance and internal marks portal I built with Java Spring Boot and MySQL that my department has been using since last semester, about 300 students and 14 faculty. I wrote the backend and the reporting module myself. If I had to name one strength it would be follow through: on that project I ran a fifteen minute stand up with my three teammates every morning, which is why we had a working version two weeks before the deadline while most groups were still integrating. I am applying to Cognizant because I want to see several clients and domains early rather than one product, and because the GenC programme gives me a structured path into that instead of figuring it out alone."

WHY THIS WORKS
- Ninety seconds, four parts, lands on why this employer.
- Specific numbers make it impossible to confuse with another candidate.
- Evidences the strength with a behaviour instead of claiming an adjective.
- Leaves obvious hooks, so the panel's next question is one you prepared.

Answer

HR is testing two things at once: whether you will sign, and whether you have read what you are signing. The wrong reactions are both extremes. Refusing or negotiating in the room reads as a candidate who will not join, and blank agreement without a single question reads as someone who signs documents without reading them, which is a genuine concern for a client facing role.

The right response is a clear yes followed by two or three specific clarifying questions asked calmly: what is the stated minimum service period, is any amount recoverable if I resign before it ends and how is it calculated, and what notice period applies during and after probation. Ask for those in writing or confirm you will find them in the annexure. Terms differ by role, drive and year, and large Indian services employers have used a mix of instruments across cycles, including a minimum service period, a training cost recovery clause, or only a notice obligation, so do not walk in assuming a number you read on a forum.

If a specific clause genuinely does not work for you, that conversation belongs with the recruitment contact after you have the document, not in the HR round. A weak answer is 'how much is the bond', which frames the whole thing as a penalty rather than a term.

SAMPLE ANSWER

"Yes, I am comfortable with it. I have read that a service agreement is part of the programme and I am joining with the intention of building a few years here, so a minimum service period is not a problem for me. I would just want to be clear on three things when I get the document: the exact duration of the service period, whether any amount is recoverable if I were to leave before it ends and how that is calculated, and what notice period applies during probation and after confirmation. I would rather ask those now and sign with full clarity than raise them later."

WHY THIS WORKS
- Commits first, then asks, so the answer never reads as hesitation.
- Ties the commitment to intent to stay, which is what HR is screening for.
- The three questions are specific and reasonable, showing diligence not distrust.
- Frames the agreement as a term to understand, not a penalty to escape.

Answer

HR is scoring deployability, meaning whether you can be staffed anywhere without a constraint someone has to manage. Delivery centres operate in Chennai, Hyderabad, Pune, Coimbatore, Bengaluru, Kolkata, Kochi, Gurugram and Mumbai, and client coverage across North American and European time zones means some projects run shifted hours. The answer that scores is an unqualified yes with one short line of supporting context, not a yes with attached conditions.

Do not say 'I would prefer Chennai but I can adjust', because 'prefer' is what gets recorded and it converts you from flexible to constrained in one word. Do not negotiate location in the HR round; staffing happens at allocation, and this is neither the stage nor the person. If you genuinely have a constraint, for example a medical dependency at home, state it once, plainly, and immediately follow it with what you can do, rather than concealing it and creating a problem at allocation time.

If you are truly location bound, apply to drives for that location rather than trying to negotiate a general offer. A weak answer is a conditional yes with a list attached, which is the single most common self inflicted wound in the HR round for freshers who are otherwise strong.

SAMPLE ANSWER

"Yes to both. I am open to any of the delivery locations, and I have already discussed relocation at home, so it is a settled decision rather than something I would need to reconsider after the offer. On shifts, I understand that covering US and European client hours means the working window changes by project, and I am fine with that. In my final semester I was starting internship calls at eight in the morning and doing lab work till late, so I have already run an irregular schedule and I know what it takes to stay consistent through it."

WHY THIS WORKS
- Unqualified yes on both, which is exactly what deployability means.
- States that the family conversation already happened, removing the real risk.
- Backs the flexibility with a lived example instead of a promise.
- Never uses the word prefer, which is the word that gets written down.

Answer

This is scored on whether you can disagree without damaging a working relationship, which is the whole job in a delivery team. Use a four part structure: the situation in one line, the specific disagreement in technical or factual terms, what you did, and the outcome including what you learned. Three rules make or break it.

Choose a disagreement about the work, not about a person's character or effort, because a story about a teammate who did nothing reads as blame regardless of how carefully you phrase it. Show that you sought information rather than won an argument, for example by testing both approaches, checking the requirement, or asking the person who owned the decision. And include the possibility that you were partly wrong, because a candidate who was right in every story they tell is not credible.

The outcome does not have to be that your view prevailed; a stronger ending is often that you adopted their approach after evidence, and the project was better for it. A weak answer is either 'I have never had a disagreement', which is not believable and closes the conversation, or a story where the candidate is entirely right and everyone else is difficult, which tells HR exactly what they will be dealing with.

SAMPLE ANSWER

"In our final year project, my teammate wanted to store the attendance records as one document per class per day, and I wanted a normalised table with one row per student per session. We went back and forth for a couple of days and it was slowing everyone down. So I suggested we stop arguing and test it: we each built our version of the reporting query on a sample of a semester's data. Mine was simpler for the per student report the department actually wanted, but his was noticeably faster for the daily class view, which was the screen faculty used most. We ended up keeping the normalised tables and adding a small pre computed daily summary, which was closer to his idea than mine. What I took from it is that I had been arguing from a principle and he had been arguing from the actual usage, and the usage should have been where we started."

WHY THIS WORKS
- The disagreement is about the work, never about the person.
- Resolves it with evidence rather than by winning the argument.
- The candidate is partly wrong, which is what makes it credible.
- Ends on a transferable lesson, not on being vindicated.

Answer

For experienced candidates the aptitude gate typically disappears and the process compresses into a screening call, one or two technical rounds and a managerial or HR discussion, often within a couple of weeks when a client position is open. The content changes more than the shape. Instead of textbook data structures, panels probe what you actually shipped: the architecture you worked in, the specific modules you owned, the production incidents you handled and how you diagnosed them, your role in code review and release, and how you work with a client or a product owner.

Expect depth in your declared stack rather than breadth, and expect at least one design flavoured question at the level appropriate to your years. Three lateral specific things get weighted heavily. Notice period, because open positions are often time sensitive and a ninety day notice can genuinely cost you a role.

Compensation expectations, which will be asked directly and early. And reason for leaving, where the answer needs to be about scope and growth rather than about a manager or a company you dislike. A weak lateral answer describes the team's project without ever isolating what you personally did, which panels read as either a small contribution or a rehearsed resume rather than lived experience.

Answer

Answer with three facts in a fixed order: the contractual notice, whether your current employer permits buyout and up to how many days, and the earliest realistic joining date that follows from those two. Precision matters, because 'around two to three months' reads as uncertainty about your own contract and slows the offer. Raise buyout support as a question rather than an assumption, since reimbursement policies vary by role, band and drive and are not guaranteed.

On the counter offer question, HR is testing offer stability, because a candidate who accepts and then withdraws costs the recruiter a completed pipeline and a client a slot. Answer it directly: say you have already thought about it, state your reason for moving in terms a counter offer cannot fix, meaning scope, domain exposure or technology direction rather than money, and then commit explicitly. Do not say 'it depends on what they offer', which is honest and immediately tells HR you are using this process as leverage.

Also be ready for the reverse: if your current employer has a long notice and the position is urgent, offer what you can control, such as resigning immediately on offer acceptance and pursuing buyout in parallel. A weak answer is a vague date plus a hedged commitment, and both slow everything down.

SAMPLE ANSWER

"My contractual notice is 60 days from the date I resign. My current employer allows buyout for up to 30 of those days, so the earliest realistic joining date is roughly 30 to 35 days from an offer, and I will confirm the exact recoverable amount with my HR in the same week. On a counter offer, I have already thought that through. I am moving because I want enterprise scale delivery work and direct client exposure, and my current employer cannot give me that whatever they revise on salary. So no, I would not accept one, and I would give you a firm resignation date rather than leaving you waiting."

WHY THIS WORKS
- Exact numbers, so recruiting can plan an onboarding date immediately.
- Raises buyout as a question rather than assuming reimbursement.
- Frames the move around scope, which no counter offer can match.
- Commits explicitly, which is the entire point of the counter offer question.

Answer

Answer in three moves. First, state your current fixed and variable components separately and accurately, because the offer will be built off fixed pay and an inflated number surfaces during document verification. Second, give a range rather than a point, anchored to market data for your skill, years and city, and place your genuine target in the lower half of the range so you have room without appearing to negotiate against yourself.

Third, add the sentence that makes the range credible: that you are looking at the whole package including role scope, learning and stability, not only the number. If asked for a percentage, a hike expectation is normally discussed as a band rather than a single figure, and the honest framing is to say what would make the move worthwhile given the notice period and transition cost you are absorbing. Two mistakes to avoid.

Refusing to answer entirely, which stalls the process and rarely helps a lateral candidate. And quoting a number well outside the band for your experience in that location, which does not get negotiated down, it usually just ends the conversation. If you have a competing offer, you may mention that one exists without naming figures. A weak answer is 'as per company standards', which sounds accommodating and simply hands the anchoring to the other side.

Answer

Background verification for an IT services role in India typically covers identity and address, education meaning degree and marksheets verified with the institution or through an agency, employment history meaning dates, designation and reason for leaving verified with previous employers, and often a criminal record check. It is usually run by a third party agency and can happen before or shortly after joining depending on the drive. Keep one folder, physical and scanned, containing multiple resume copies, all semester or year wise marksheets, tenth and twelfth marksheets and certificates, the degree or provisional certificate, a government photo identity such as Aadhaar or a passport, PAN card, passport size photographs, and any internship or training certificates you have claimed.

Laterals add offer letters, relieving letters and recent payslips from each employer plus the latest Form 16. The rule that matters more than the checklist is disclosure timing. Declare a gap, a cleared arrear, a shut down employer or an ongoing matter before the check begins, not after a flag is raised, because a discrepancy discovered by an agency is treated far more seriously than the same fact declared voluntarily. Missing or inconsistent documents are one of the most common causes of onboarding delay, and unlike assessment results it is entirely within your control.

Answer

Large services firms hire against forecast demand, so the gap between an offer letter and a confirmed date of joining can run from a few weeks to several months, and in slower demand cycles candidates across the industry have seen extended waits. Treat it as a managed period. Stay in contact through the official channel only, meaning your recruitment contact or the candidate portal, at a reasonable cadence such as once every three or four weeks, because pressure does not advance an allocation while a professional check in keeps you visible.

Complete every onboarding formality the moment it is requested, since incomplete documentation is a genuine and entirely self inflicted cause of delay. Use any pre joining learning material or certification path offered, because it is visible, useful and occasionally influences allocation. Most importantly, do not stop applying elsewhere until you hold a written date of joining.

Holding one undated offer as your only plan is the single mistake that costs candidates a year. If you do accept something else in the meantime, decline formally and politely rather than disappearing, because services HR teams keep records and you may well apply again later. A deferred date is a demand cycle outcome, not a verdict on your performance.