Indian Fresher Placement and Coding Interview Preparation

If you are in your final year, or recently graduated, you have probably heard a mix of advice about placements: "just solve 500 problems", "aptitude is everything", "only projects matter", "the process is changing every year". Some of it contradicts the rest. Some of it is simply folklore.

This article tries to be useful and honest. It describes the general shape of fresher hiring in India, explains what each stage tends to test, and gives you concrete, practicable habits for each one. It does not promise a job, it does not claim to know the exact process of any particular company, and it avoids numbers it cannot support, because hiring processes change from year to year.

• The usual stages of fresher hiring, and what each one tests.
• How foundational coding expectations differ from more demanding interviews.
• How to prepare for aptitude rounds and online coding assessments, including a fast-input template.
• How to handle technical interviews: trade-offs, debugging under pressure, and CS fundamentals.
• How to discuss your projects honestly and confidently.
• A checklist for the last week before an interview.

Not every company uses every stage, and the order varies. Here is the general shape.

Treat each as a separate skill and prepare for it separately. A person strong at problem solving can still lose marks in an aptitude test because of time pressure, or in an assessment because of input handling.

Different employers hire for different needs. Very broadly (and with many exceptions), you can think of two ends of a range.

This does not mean the first column is "easy". Writing correct, readable code for a plain problem under time pressure is hard. It means the range of topics and the depth of follow-up tend to differ. If you are unsure which end applies to your target roles, ask your seniors, check the job description, and prepare the core first (tier 1 in the study plan), then extend.

Aptitude sections are about speed and accuracy, on questions that are usually not hard individually. Typical areas:

• Quantitative: percentages, ratios and proportions, averages, profit and loss, time and work, speed and distance, simple and compound interest, number systems, permutations and combinations, probability, data interpretation.
• Logical reasoning: number and letter series, coding and decoding, seating arrangements, blood relations, syllogisms, puzzles.
• Verbal: reading comprehension, grammar, sentence correction, vocabulary.

How to prepare:

1. Little and often. 30 to 45 minutes a day beats a weekend cram. Aptitude skill is built by repetition.
2. Learn the basic formulas and shortcuts once, write them on one page, and review the page regularly.
3. Practise with a timer. Speed is a skill, and it only improves if you practise at speed.
4. Know the test format. Is there negative marking? Can you go back to a question? Is each section separately timed? The best strategy depends on these rules.
5. Skip smartly. If a question is eating more than a minute or two, mark it and move on, unless the rules punish skipping.
6. Review your mistakes. Keep an error log (as in the study plan) of the question types you get wrong.

These skills overlap a little with DSA (for example, probability and combinations connect to counting problems), but they are mostly separate. Do not neglect them: a strong coding round does not help if you are filtered out earlier.

In an online assessment (OA), your code is run against test cases you cannot see. Your answer is judged on correctness and often on speed. The habits that matter most are different from those of a live interview, because no human is watching your reasoning. Only the output counts.

• Constraints first. n up to 10^5 means O(n log n) or better. Look at the value ranges too (overflow). Use the table below.
• Input and output format. Exactly how many test cases, in what layout? Must the output be one line or several? A tiny format slip can fail every test.
• Sample tests. Work them by hand before coding. If your understanding does not match them, you misread something.
• Edge cases the samples hide. Empty input (if allowed), n = 1, all equal values, maximum values, negative numbers, repeated elements.

You saw this table in Problem Solving Fundamentals. Here it is again as a quick lookup. It is a rough guide, since actual speed depends on the platform and language.

If your approach is too slow, you will see time limit exceeded (TLE). Common causes: an O(n^2) loop where O(n) was needed, slow input reading, String concatenation in a loop, or list.remove(0).

Scanner is convenient but slow for large inputs. For big inputs, use BufferedReader with a tokenizer, and collect output in a StringBuilder, printing once. This is a template you can type from memory. The program below reads multiple test cases from a text so that it runs on its own. In a real submission, replace the StringReader with new InputStreamReader(System.in).

// File: Main.javaimport java.io.BufferedReader;import java.io.IOException;import java.io.StringReader;import java.util.StringTokenizer;public class Main {    static BufferedReader reader;    static StringTokenizer tokens;    // Returns the next whitespace-separated token, or null at the end of the input.    static String next() throws IOException {        while (tokens == null || !tokens.hasMoreTokens()) {            String line = reader.readLine();            if (line == null) {                return null;            }            tokens = new StringTokenizer(line);        }        return tokens.nextToken();    }    static int nextInt() throws IOException {        return Integer.parseInt(next());    }    static long maxSubarraySum(int[] a) {        long bestEndingHere = a[0];        long best = a[0];        for (int i = 1; i < a.length; i++) {            bestEndingHere = Math.max(a[i], bestEndingHere + a[i]);            best = Math.max(best, bestEndingHere);        }        return best;    }    public static void main(String[] args) throws IOException {        String input = "3\n5\n1 -2 3 4 -1\n1\n-5\n4\n2 2 2 2\n";        reader = new BufferedReader(new StringReader(input));       // in a real submission: new InputStreamReader(System.in)        int testCases = nextInt();        StringBuilder out = new StringBuilder();        for (int t = 0; t < testCases; t++) {            int n = nextInt();            int[] a = new int[n];            for (int i = 0; i < n; i++) {                a[i] = nextInt();            }            out.append(maxSubarraySum(a)).append('\n');        }        System.out.print(out);                                      // one print at the end    }}

7-58

What this template gives you:

• The next() method reads tokens across lines, so it does not matter whether the numbers are on one line or several.
• It returns null at the end of the input, which is useful when the number of test cases is not given.
• Output is built in a StringBuilder and printed once, which is much faster than thousands of println calls.
• The first test case [1, -2, 3, 4, -1] has a best subarray 3, 4 with sum 7. The second is a single negative number, so the answer is -5. The third sums to 8. These come from Kadane's algorithm in Arrays.

• Skim all the questions first. Start with the one you are most sure of, and bank the marks.
• Submit something that works before chasing the perfect solution. If the platform awards partial credit (check the rules), a correct brute force that passes small tests is worth having.
• Do not over-polish. Correct and fast enough is the target.
• Test with your own cases if the platform allows custom input: the smallest input, the largest, and the awkward ones.
• Watch the clock in blocks: if you are 15 minutes over your budget on one question, decide whether to continue or move on.

• I read the constraints and chose a complexity to match.
• I handled every input and output format detail.
• I used long where sums or products can be large.
• I tested the smallest and the largest input.
• I removed all debug prints.
• My class and method names match the platform's requirements.
• I did not leave a slow Scanner for a big input.

A technical interview is usually a conversation with some coding. Typical parts:

1. Introduction and resume. You will be asked to introduce yourself, and then asked about things on your resume. Anything on your resume is fair game.
2. Coding problems. Use the workflow from article 25. Expect some follow-ups.
3. CS fundamentals. Questions on OOP, databases, operating systems and networks.
4. Projects. Covered below.
5. Your questions. Prepare two or three real questions about the work or the team.

For campus interviews, many interviewers like to check basic fundamentals. A reasonable preparation list (check what applies to your target roles):

Write a short summary for each subject, and practise explaining the main ideas in two minutes, aloud. If you cannot explain it simply, you do not yet understand it well enough.

Interviewers often ask "why this and not that?" A good answer names the alternatives and the cost of each. Use this shape: what I chose, what the alternative was, what I gain, what I give up, and when I would choose the other one.

An example, for "check whether two strings are anagrams":

• Sort both and compare: O(n log n) time, simple code, little extra memory.
• Count the characters with an array: O(n) time, O(1) extra space for a fixed alphabet, but assumes lowercase letters.
• Count with a hash map: O(n) time, works for any characters, uses more memory and is slower per step.

"I would use the counting array if the alphabet is small and fixed, because it is fastest and simplest. If the characters can be anything, I would use a map. If the strings are short and I want minimal code, sorting is fine."

Notice that no option is called "best". The right answer depends on constraints, and saying so shows judgement.

Bugs will appear in live coding. What interviewers watch is how you debug, not whether you ever make a mistake. A calm routine:

1. Pause and say what you expected, and what happened. "I expected 7 but got 6."
2. Shrink the input. Find the smallest example that fails.
3. Trace by hand. Walk through the code with that example, writing variable values, as in this course's dry runs.
4. Check your assumptions. Off-by-one? int overflow? An empty case? A variable not updated?
5. Narrow down. Add a print (or reason) to find the first line where reality departs from your expectation.
6. Fix one thing at a time, and re-run your examples.

Talk through this aloud. Calm, systematic debugging is a positive signal. Thrashing (changing things randomly) is a negative one.

• Say what you do know, and where your knowledge ends. "I have not used that, but it sounds like X. Is that right?"
• Reason from first principles. A reasoned wrong answer is better than a confident guess.
• Never bluff about something on your resume. A short "I only used it in a small project, here is what I understood" is respectable.

In the last weeks before interviews, do not learn new topics. Revise patterns. Use your pattern notebook and error log (from the study plan):

• For each pattern, re-solve one problem from memory.
• Re-read the traps you wrote down.
• Practise the first two minutes of each pattern: how do I recognise it?

Projects are where interviews often go deepest, because you are the expert in your own work. Do these things:

• Pick two or three projects and know them thoroughly. Better two you understand than six you cannot explain.
• Know your own contribution. In a team project, say exactly what you built.
• Use a simple structure: the problem, your role, the design (including data structures and why), a challenge you faced and how you solved it, the result, and what you would improve.
• Be ready for "why". Why this database? Why this data structure? Why not the alternative? What is the complexity of this operation? What would break if you had a hundred times more users or data?
• Describe only what you did. Do not claim a technology you only read about. If you copied a tutorial, say so, and say what you changed and learned.
• Show tests and limits. Mentioning what you tested, and honestly naming the limitations, builds trust.
• Make it runnable. A repository with a clear README and a working demo is worth much more than a long resume bullet. The practice tracker from article 26 is an example of a project you can discuss in depth.

Resume bullets should be specific and truthful. For help, see Writing a Resume That Survives the First 10 Seconds.

Many of the hardest-sounding questions here are simple to answer if you have thought about them in advance: "Tell me about yourself", "Why this company?", "Where do you see yourself?", "Tell me about a challenge", and questions about relocation, shifts and expectations. Common HR Interview Questions and How to Answer Them (With Examples) and How to Get Your First Job as a Fresher in India: A Step-by-Step Guide cover them. Prepare short, honest answers and practise them aloud.

• Day 7 to 5: revise your pattern notebook and error log. Re-solve a few problems from memory under a timer.
• Day 4 to 3: one mock interview, with a friend or alone. Revise your CS fundamentals summaries and your two projects.
• Day 2: read the company and role description. Prepare your questions. Check your documents and your setup (internet, laptop, charger, quiet space, the platform).
• Day 1: light revision only. Prepare clothes and travel. Sleep.
• On the day: eat something, arrive early, and breathe. Ask for clarification if you need it, and think aloud.

• Believing one rumour about the "exact" process. It changes. Check current sources.
• Practising only topics you like, and skipping aptitude or fundamentals.
• Ignoring I/O mechanics, then losing marks to input handling or overflow in an OA.
• Copying solutions without being able to explain them. Follow-up questions expose this immediately.
• Overstating the resume. Anything listed can be asked about.
• Not practising speaking. Many capable candidates fail to explain clearly.
• Leaving mock interviews until the last week.
• Panicking after one bad round. Many rounds are independent. Learn from it and continue.
• Neglecting rest and health near the interview date.
• Ignoring other opportunities. Keep applying widely, and do not wait for a single company's result.

23-1 -2 -345 -10 6 7

Scanner in = new Scanner(System.in);int n = in.nextInt();int sum = 0;String result = "";for (int i = 0; i < n; i++) {    int x = in.nextInt();    sum += x;    result += x + " ";}System.out.println(result);System.out.println(sum);

// File: Main.javaimport java.io.BufferedReader;import java.io.IOException;import java.io.StringReader;import java.util.StringTokenizer;public class Main {    static BufferedReader reader;    static StringTokenizer tokens;    static String next() throws IOException {        while (tokens == null || !tokens.hasMoreTokens()) {            String line = reader.readLine();            if (line == null) {                return null;            }            tokens = new StringTokenizer(line);        }        return tokens.nextToken();    }    public static void main(String[] args) throws IOException {        reader = new BufferedReader(new StringReader("2\n3\n-1 -2 -3\n4\n5 -10 6 7\n"));        int cases = Integer.parseInt(next());        for (int t = 0; t < cases; t++) {            int n = Integer.parseInt(next());            long best = Long.MIN_VALUE;            long current = 0;            for (int i = 0; i < n; i++) {                int x = Integer.parseInt(next());                current = Math.max(x, current + x);                best = Math.max(best, current);            }            System.out.println(best);        }    }}

-113

// File: Main.javaimport java.io.BufferedReader;import java.io.IOException;import java.io.StringReader;public class Main {    public static void main(String[] args) throws IOException {        String input = "1 2 3\n\n10 -4\n7\n";                 // in a real submission: System.in        BufferedReader reader = new BufferedReader(new StringReader(input));        String line;        int lineNumber = 0;        while ((line = reader.readLine()) != null) {            lineNumber++;            line = line.trim();            if (line.isEmpty()) {                System.out.println("line " + lineNumber + ": (blank)");                continue;            }            long sum = 0;            for (String token : line.split("\\s+")) {                sum += Long.parseLong(token);            }            System.out.println("line " + lineNumber + ": " + sum);        }    }}

line 1: 6line 2: (blank)line 3: 6line 4: 7

// File: Main.javaimport java.io.BufferedReader;import java.io.IOException;import java.io.StringReader;import java.util.StringTokenizer;public class Main {    public static void main(String[] args) throws IOException {        String input = "3\n2000000000 2000000000 2000000000\n";        int[] values = {2_000_000_000, 2_000_000_000, 2_000_000_000};        int buggySum = 0;        for (int v : values) {            buggySum += v;                                  // overflows int        }        System.out.println("int sum:  " + buggySum);        BufferedReader reader = new BufferedReader(new StringReader(input));        int n = Integer.parseInt(reader.readLine().trim());        StringTokenizer tokens = new StringTokenizer(reader.readLine());        long sum = 0;        StringBuilder line = new StringBuilder();        for (int i = 0; i < n; i++) {            int x = Integer.parseInt(tokens.nextToken());            sum += x;            if (i > 0) {                line.append(' ');                           // a separator, so no trailing space            }            line.append(x);        }        System.out.println("[" + line + "]");        System.out.println("long sum: " + sum);    }}

int sum:  1705032704[2000000000 2000000000 2000000000]long sum: 6000000000

• You have reached the end of the course. Use Your 12-Week DSA Study and Revision Plan to organise your revision, and return to individual articles whenever a topic feels weak. The dry runs and exercises are meant to be repeated.
• Next steps beyond this course: more practice problems on your own, system design basics if your target roles ask for them, and strengthening one or two projects. Software Interview Preparation: A 6-Week Plan That Actually Works covers some of those next to DSA, and Writing a Resume That Survives the First 10 Seconds helps you present your work.
• Practice habit: every week, do one timed problem, one mock explanation of a project or fundamentals topic, and one review of your error log. That small routine, repeated, is what builds interview readiness.