Article

A tech internship at a company like Amazon, Google, or a fast-growing Indian unicorn is one of the highest-leverage things you can land as a student. It often converts into a pre-placement offer (PPO), and you learn more in eight weeks than in a full semester. But the bar is real, and the process rewards preparation over raw talent. Here is how the hiring pipeline actually works and how to prepare for each stage without wasting months.

Understand the pipeline before you prepare

Most top companies use a remarkably similar funnel. Knowing it lets you prepare for the right thing at the right time.

• Online assessment (OA): A timed test on HackerRank, HackerEarth, Codility, or an in-house platform. Usually 2-3 DSA problems, plus MCQs on CS fundamentals or debugging at some companies. Amazon intern OAs often also include behavioural/work-style questions. This is a filter: clear the threshold, move on.
• Technical interviews: One to three live problem-solving rounds, 45-60 minutes each, on a shared editor like CoderPad or a Google Doc. You code, discuss complexity, and often get grilled on CS fundamentals — OOP, DBMS, OS, networks — especially at Indian product companies.
• Behavioural / hiring-manager round: Questions about how you work, your past projects, conflicts, and failures. At Amazon this is explicitly built around Leadership Principles. Freshers underestimate this round; it decides close calls.

For campus roles, an OA plus one or two interviews is common. Off-campus and referral funnels — which matter enormously in India — can add rounds. A referral from someone already at the company does not skip the interviews, but it dramatically raises your chance of getting the OA in the first place. So ask seniors and alumni early.

Prepare DSA the smart way

Data structures and algorithms decide the OA and the technical rounds. The mistake most students make is grinding hundreds of random problems. Do this instead.

• Master patterns, not problem count. Arrays and strings, two pointers, sliding window, hashing, binary search (including on the answer), recursion and backtracking, trees and BSTs, graphs (BFS/DFS, topological sort), heaps, and dynamic programming. Roughly 12-15 patterns cover the vast majority of interview questions.
• Solve, then articulate. After each problem, state the pattern, the time and space complexity, and one edge case out loud. If you cannot explain why it works, you have not learned it.
• Use a structured list. Curated sets like the Striver SDE Sheet, NeetCode 150, or Blind 75 beat solving randomly. Aim for depth: 150-250 well-understood problems beats 600 half-remembered ones.
• Time yourself. OAs are under pressure. Practise writing clean, compiling code in 25-30 minutes.
• Revise. Redo problems you failed after a week. Retention, not first-attempt success, is what shows up in the interview.

Codeforces or CodeChef contests build speed and confidence, but you do not need a high rating to get an internship. Interview-style practice matters more than competitive-programming glory.

Make your resume and projects send the right signals

Recruiters spend seconds per resume. Every line should signal competence.

• Two or three real projects beat ten toy ones. A full-stack app you deployed, an ML model with measured accuracy, or an open-source contribution that got merged says more than a pile of tutorial clones.
• Quantify impact. "Reduced API latency 40%," "handled 5k requests/min," "improved accuracy from 82% to 91%." Numbers make claims believable.
• Show it is live and yours. Link a GitHub repo with a clean README, and a deployed demo if you can. Interviewers do click.
• One page, reverse-chronological, no photo. List languages honestly — if it is on your resume, you can be grilled on it.

A common winning signal is contributing to open source or building something people actually use. It demonstrates initiative, which is exactly what behavioural rounds probe for.

Amazon's Leadership Principles and the STAR method

Amazon interviews — and many Indian companies that copied the format — are built around Leadership Principles (LPs) like Customer Obsession, Ownership, Bias for Action, Dive Deep, and Learn and Be Curious. Interviewers ask for specific stories from your past and take structured notes.

Answer with STAR:

• Situation: Briefly set the context.
• Task: What was your specific responsibility?
• Action: What you did — say "I," not "we." This is the bulk of the answer.
• Result: The outcome, quantified where possible, plus what you learned.

Prepare 6-8 stories from your projects, hackathons, teamwork, and failures, and map each to two or three LPs. One honest "tell me about a time you failed" story, told with a real lesson, often lands better than a humblebrag. Avoid vague, hypothetical answers — they want a real incident with details.

How to think out loud

In a live technical round, silence is your enemy. The interviewer is evaluating how you think, not just whether you reach the answer.

• Restate the problem and confirm constraints — input size, data types, edge cases. This alone signals maturity.
• Start with the brute force, then optimise. Say "the naive approach is O(n²); I think we can do better with a hash map." Narrate the trade-off.
• Talk before you type, then type cleanly. Walk through your plan, get a nod, then implement.
• Dry-run on an example. Trace your code on a small input to catch bugs before the interviewer does.
• Ask, do not assume. Clarifying questions are a plus, not a weakness.

If you get stuck, say what you are considering. Interviewers routinely give hints — but only if they can hear your reasoning.

Common mistakes that quietly cost offers

• Memorising solutions. Interviewers change constraints; pattern understanding survives, memorisation does not.
• Ignoring the behavioural round. Strong coders get rejected for thin, generic stories.
• Going silent when stuck. It reads as an inability to collaborate.
• Not testing your code. Submitting buggy code you never traced is a red flag.
• Lying on the resume. One deep-dive question exposes it, and it ends the interview.
• Neglecting CS fundamentals. Indian product companies love OS, DBMS, and OOP questions.

A realistic prep timeline

If you have three to four months before the season:

• Weeks 1-6: Core DSA patterns, 8-10 focused problems each, revising as you go. Firm up one strong project.
• Weeks 7-10: Harder problems (DP, graphs), timed OA-style practice, and CS fundamentals revision. Polish your resume and start building a referral pipeline.
• Weeks 11-14: Mock interviews (with peers or platforms like Pramp), STAR stories written and rehearsed, and full-length timed tests.

If you only have four weeks, compress: prioritise the highest-frequency patterns (arrays, strings, hashing, trees, two pointers, basic DP), do 3-4 mocks, and prepare four solid STAR stories. Consistency — two focused hours daily — beats weekend cramming every time. Start before you feel ready; the interview itself teaches you what to fix.