"Preparing for the technical round" means four different things depending on who is interviewing you, and the single most common reason a capable person fails one is that they prepared thoroughly for a different format.
Someone spends three months grinding data structures problems and then interviews at a services company that asks them to explain normalisation and write a join. Someone else revises framework internals for a startup that hands them a laptop and a broken API. Both prepared. Neither prepared for what happened.
So the first question is not what to study. It is who is asking.
Identify the format before you prepare
Product companies and larger startups — the ones running structured multi-round loops. Expect algorithmic problem solving under time pressure, one system design round from mid-level upwards, and a round on your actual past work. This is the format everything on the internet is written about, which is why people assume it is universal. It is not; it is the minority of Indian hiring by volume.
Services and consulting companies — expect breadth over depth. Core language semantics, SQL, one framework you claimed, a little OOP theory, and questions that check you have genuinely worked on what your resume says. Fewer puzzles, more "explain how this works".
Startups outside the funded tier — expect practical. A take-home, a debugging exercise, a conversation about how you would build the thing they are building. Often the CTO, often one long round, frequently the fastest process you will be in.
Captives and GCCs (an MNC's India engineering centre) — usually a hybrid: one algorithmic round because the global process demands it, plus deep questions on the specific stack the team runs.
You can identify which you are in with two questions to the recruiter, and they will answer:
What do the technical rounds look like — how many, and roughly what does each cover?
Is there a coding round, and is it algorithmic problem solving or working with a codebase?
Ask this. It is not presumptuous, it is the most useful five minutes of your preparation, and a recruiter who cannot answer it has told you something too.
By discipline
Software engineering
If it is an algorithmic loop: arrays, strings, hash maps, two pointers, sorting, binary search, trees, graphs, and basic dynamic programming — roughly in that order of frequency. Depth on the first five beats coverage of all of them. The realistic target is not 500 problems; it is 80 to 120 problems worked properly, meaning you solved it, then re-derived it a week later, and can state the complexity without thinking.
Talk while you solve. A silent candidate who reaches the optimal answer often scores below one who narrates a brute force, states its complexity, notices the repeated work and improves it. The interview is measuring how you think, and silence hides exactly that.
If it is system design (usually from three or four years up): the vocabulary matters more than novelty. Load balancing, caching layers, SQL versus NoSQL and why, sharding, queues and asynchronous processing, idempotency, and the CAP trade-off stated without the slogan. Practise out loud on three or four familiar systems — a URL shortener, a rate limiter, a notification service, whatever your own product does. Start with requirements and scale estimates, not with a box diagram.
Always: your own last two years. The most reliable question in any format is "walk me through something you built and why it was designed that way". People who cannot answer that well fail rounds they should have passed, and it is entirely preventable — write out three of your systems on paper before the interview.
Data and analytics
SQL is the round. Not a component of it — for analyst roles it frequently is the technical interview. Joins including self-joins, group by with having, window functions (row_number, rank, lag, running totals), date handling, and the CTE-versus-subquery choice. Window functions are where most candidates fall over, and they appear constantly.
Then: Excel at a level beyond VLOOKUP — index-match, pivot models, Power Query if you claimed it. One visualisation tool properly, meaning you can discuss the data model behind a Power BI or Tableau report, not just build a chart. Python with pandas for the more technical roles.
And a case discussion: sign-ups dropped 20% last week, how would you investigate. This is testing structure, not statistics. Segment, isolate, check the instrumentation before the theory.
Frontend
Beyond framework syntax: rendering and re-rendering behaviour, state management choices and why, browser fundamentals (event loop, the request lifecycle, what actually blocks paint), accessibility basics, and CSS layout that you can write without a UI library. Expect a live build — a component with a real requirement — and expect to be judged on how you handle the requirement changing halfway.
DevOps, cloud and infrastructure
Linux fundamentals and networking are asked far more than people expect — DNS, TLS, ports, netstat, reading a log. Then one cloud platform properly, CI/CD pipelines you have genuinely configured, containers and orchestration, infrastructure as code, and an incident you were part of, told honestly with what went wrong.
QA and testing
Test design is the differentiator, not tool syntax. Given a feature, how do you decide what to test and what to skip. Boundary and equivalence reasoning, the automation-versus-manual trade-off, flaky test handling, and API testing. Expect to be handed a small feature and asked to enumerate cases.
Non-engineering technical rounds
Finance and accounting roles get accounting standards, closing processes and a practical Excel exercise. Marketing gets funnel maths and a campaign structure. HR gets statutory compliance and a case on a real situation. The principle is unchanged: the interview is about the mechanics of your actual work, and the preparation is being able to explain what you did and why.
How to allocate time when you have two weeks
Preparation is triage. In rough priority:
- Your own resume, defended. Every project and claim on it, with numbers. This is asked in every format, and it is the cheapest thing to fix.
- The one skill named most in the job description. If the posting says SQL four times, that is your first three days.
- The format's core — algorithms, or SQL, or the practical exercise.
- The company's product. Use it. Read what they have published. Twenty minutes here changes the tenor of the whole conversation.
- Everything else.
What is not worth your two weeks: reading a language reference end to end, starting a new framework, or attempting 300 problems and retaining none.
If your preparation time is measured in days rather than weeks, the triage version is in interview preparation that actually moves the needle.
In the room
Restate the problem before you start. Thirty seconds, and it catches misunderstandings that would otherwise cost you the whole round.
Ask about constraints. Input size, edge cases, whether you can assume the data fits in memory. Interviewers deliberately underspecify; asking is the test.
Brute force first, out loud, then improve it. A working answer with a stated complexity is a position to negotiate from. Nothing on the whiteboard is not.
When you are stuck, say what you are stuck on. "I want to avoid the nested loop here, and I'm trying to work out what to store so the second pass isn't needed" invites a hint and is scored as reasoning. Silence for four minutes is scored as nothing.
Do not claim familiarity you do not have. "I haven't used Kafka in production; I know it as a durable log with consumer groups — is that enough to reason about this?" is a good answer. Bluffing is a bad one, and it is transparent.
Handling a question you genuinely cannot answer: say so, then say what you would do about it. "I don't know how the garbage collector handles that. I'd read the GC logs and test it with a small heap." Interviewers are calibrating your honesty as much as your knowledge, and everyone has a limit.
Take-home assignments
Increasingly common, and worth a rule: scope your time and say so. If a take-home says four hours and would take twelve to do fully, do the four honestly and include a short note on what you would add next and why. That note is often read more carefully than the code.
Refuse anything that is plainly production work — a full feature for their live product, unpaid, with a "we'll evaluate it" attached. It happens, and the pattern is close enough to the exploitative postings described in how to spot a fake job posting to be worth naming.
Afterwards
Write down every question you were asked, the same day, while you can still remember them. Two things come out of this: a real syllabus for the next interview, because companies in the same tier ask overlapping questions, and an accurate record of where you actually failed — which is almost never where you think it was.
Then check the non-technical half is not the thing costing you offers. Plenty of people clear every technical round and lose the process afterwards; what goes wrong there is in the HR round, question by question.