A technical interview is not a quiz on everything you ever studied. It is three or four rounds, each testing one thing. This guide names what each round tests, gives a seven-day plan, and shows how to talk through a problem you cannot fully solve.
Do three things, in this order. Know every line of your own resume well enough to be questioned on it for ten minutes. Revise the fundamentals of your role, not the whole syllabus. Then practice solving problems out loud, because the technical round grades how you think, not only whether you finish. A week is enough if you spend it on those three and nothing else.
The rest of this guide goes round by round: what the online test, the technical round, the techno-managerial round and the HR round each look for, a day-by-day plan, and the mistakes that lose technical interviews even when the candidate knows the answer.
Key takeaways
Most companies run some version of the same four rounds. Knowing which one you are in tells you what to prepare and how to answer.
A timed screen: aptitude questions, multiple-choice fundamentals, or two or three coding problems in a browser editor. It tests whether you can produce a working answer under a clock. Nobody is watching how you think here, so a correct brute-force answer beats an elegant unfinished one.
A person, usually an engineer from the team. They ask about your projects, then fundamentals of your stack, then one or two problems solved on a shared screen or a whiteboard. This round tests depth on what you claim to know and whether you can reason when you are stuck.
A senior engineer or the hiring manager. For freshers this is a harder version of round one. For experienced candidates it is often design: "how would you build X", trade-offs, what breaks at scale. It tests judgement, not recall.
A manager who is also technical. Half the questions are about your projects, ownership and decisions; half are about how you work with people, deadlines and unclear requirements. It tests whether they can put you on a team tomorrow. More on this below.
Fit, salary, notice period, why this company. Do not relax here; offers are lost in this round too.
The first ten minutes of almost every technical round come from your resume. Every skill you listed is a question. Every project is five questions. So before you open a textbook, go through your resume line by line and ask, for each item: can I talk about this for two minutes without notes?
For every project, be ready with five answers:
Remove anything you cannot defend. A skill you used once in a tutorial is a trap on the page; an honest, shorter list is safer. Check the match with the free resume vs job description tool and prepare the questions the posting itself suggests with the questions from a job description tool. Both run in your browser and upload nothing.
Do not revise the whole degree. Revise the fundamentals of the role you applied for, and go one level deeper than the definition: for every concept, one example and one "when would you not use it".
Arrays, strings, hash maps, linked lists, stacks and queues, trees, basic graphs. Sorting and searching, and their time complexity. OOP ideas with a real example each. SQL joins and indexes. How a request travels from a browser to a server and back. The software engineer question bank has the questions in the order they are usually asked.
Everything above, plus: REST and status codes, authentication versus authorisation, database design and normalisation, indexes and why a query is slow, caching, queues, and what happens when two requests hit the same row at once.
How JavaScript actually runs: the event loop, closures, promises and async. The DOM and how the browser renders a page. CSS layout: flex and grid, and the box model. Your framework's rendering model and state. Performance basics: what makes a page slow and how you would find out.
SQL until it is boring: joins, group by, window functions, subqueries, and finding the duplicate row. Descriptive statistics with examples. One spreadsheet or notebook tool well. And the ability to explain a chart in one plain sentence.
Linux basics you can type from memory, networking to the level of DNS, ports and TLS, containers and what an image really is, a CI/CD pipeline you can draw, and what you look at first when a service is down.
Company-specific patterns live in the questions by company and role hub. Read the one for your company after the fundamentals, not instead of them.
The person on the other side of the screen is deciding whether they could work with you on a hard problem. A silent five minutes followed by a perfect answer scores lower than a running commentary that reaches a working answer. Practice this exact routine until it is automatic:
Say: "Let me make sure I have it: [restate the problem]. Can the input be empty, and how large can it get?"
Then: Baseline: the straightforward way is [approach], which is [slow because]. Better: if I use [structure], the [slow step] becomes [faster step]. Code: narrate as you type. Test: "let me trace it with [small example]". Complexity: "this is [time] and [space]."
Practice with a few problems a day, always out loud, timer on. Solving quietly on a laptop trains the wrong skill. When you are stuck for real, the what to say when you do not know the answer guide has the exact phrases.
This round is run by an engineering manager or a senior lead. It sits between the technical rounds and HR, and candidates often walk in thinking the hard part is over. It is not. The manager is deciding whether to put you on their team, and they ask a mix that no other round asks.
Use the STAR shape for anything that starts with "tell me about a time": situation in one line, task, what you did, result. Give the decision and the reason, not the whole history. Say "I" for the parts you did and "we" for the parts the team did; managers notice when the two are blurred. And have one honest story of something that went wrong and what you changed after it.
Two to three hours a day. If you have less time, keep days one, three, five and seven.
Prepare with this guide, so the answers are yours. In the live video interview, ClapAssist listens on your own computer, reads your resume, and shows the shape of an answer: one sentence to say first, then the points. Press Enter and it also reads what is on your screen, so a question about a shared problem gets an answer about that problem. It stays out of screen shares and recordings, and the interviewer never sees it. See how it works or what the free plan includes.
Outside pages that back the advice above, opened and checked on the date shown.
ClapAssist is a small desktop app for Mac and Windows. It listens to your video interview on your own computer and shows an answer written from your resume, one short sentence to say first and then the points. It never joins the call and stays out of screen shares and recordings.
A week of two to three hours a day is enough if you spend it on your resume, your role's fundamentals and out-loud problem practice. Cramming the whole syllabus in that week is what does not work.
Your projects first, then the fundamentals of your role, then one or two problems solved live. Senior candidates also get design questions. The exact set depends on the company; see the company and role question hubs.
A round with an engineering manager that mixes technical questions about your projects with questions about ownership, trade-offs, deadlines and teamwork. Answer with the decision and the reason, and use STAR for the stories.
Know your final-year project in depth, revise the fundamentals of your branch, and practice a few coding problems a day out loud. Interviewers expect less breadth from a fresher, not less depth on what you claim.
Yes, once, plainly, then show how you would find out or reason towards it. A bluff is found on the next question. "I am not sure, but my guess would be…" is the phrase.
Both, out loud. The online test is on a computer; the technical round may be a shared editor or a whiteboard. Narrating while you write is the skill that transfers between the two.
It listens to the call and, when you press Enter, reads your screen, then suggests the shape of an answer. It is a prompt, not a substitute for understanding; you still have to explain the approach in your own words.
Prepare the answers yourself, then let ClapAssist hold the shape for you in the live call.