The shortlist mail arrives on a Monday. Technical interview on the Monday after next. You open the folder of notes from your third-year DSA course, then a YouTube playlist called "Complete Interview Preparation", then a LeetCode account with eleven solved problems. Two weeks. You feel both that it is not enough time and that you have no idea how to spend it.
By Wednesday you have watched four hours of videos on topics you already knew and solved nothing aloud. This is the usual way a two-week runway gets wasted, and it is avoidable.
The short answer
Two weeks is enough to change how a fresher's technical interview goes, provided the time is spent on the skills the interview actually tests rather than on the comfortable ones. Interviews test whether you can explain your own project, reason through a problem while someone watches, communicate clearly, and stay useful when you do not know something. Re-reading notes trains none of that. So the plan below is weighted toward active practice: saying things aloud, solving problems under a clock, and getting feedback, with revision used only to close specific gaps you have found.
It assumes about two hours on weekdays and a longer block at the weekend. Adjust the hours, not the order.
Before day one: pick the target
Decide what kind of interview you are preparing for, because it changes the middle of the plan. A service company campus drive usually means fundamentals, your project, and perhaps a simple coding question, with the heavy coding already done in the online test. A product company or startup means one or two proper coding rounds on data structures, a detailed project discussion, and occasionally a simplified design question. A frontend role weights the framework and the browser; a backend or Java role weights OOP, databases and APIs. If the job posting is vague, assume fundamentals plus everything on your resume.
Days 1 and 2: audit your resume and your projects
Start with the material every interviewer will definitely ask about: you. Go through the resume line by line. For each technology you have listed, write the three follow-up questions you would least like to get, and answer them from your own experience rather than from a definition. For each project, explain the architecture aloud from memory: where a request enters, where login is checked, how data reaches the screen, what broke, what you would change now, and, for a group project, exactly which parts were yours.
If you cannot defend a line, remove it or relabel it honestly as "familiar with" or "learning". A shorter resume you can back up beats a longer one that leads the interviewer to your weakest topic. There is a full article on this in Your resume says you know React. Can you prove it?
End day two by writing a ninety-second introduction that names the two or three technologies you are strongest in and the one project you most want to be asked about.
Day 3: find out where you actually are
Before drilling anything, get a baseline. Do one full practice interview under realistic conditions, with no preparation beyond the last two days: a friend who is working, a senior, or a structured practice round. You want the number and the transcript, not coaching yet.
Then read the transcript, or your notes if it was a friend. Mark every place an answer trailed off, turned into a definition instead of a decision, or was a guess. That list, not a generic syllabus, is what the next week targets.
Days 4 to 7: core data structures, always out loud
For most fresher coding rounds the live problem is built on a small set of structures: arrays and strings, hash maps, stacks and queues, linked lists, trees, and sometimes basic graphs and recursion. Topic-wise lists such as GeeksforGeeks' top 100 show the same clusters again and again; depth on these beats breadth across everything you were taught.
For each structure, make sure you can state the time complexity of the common operations without hesitating; the Big-O cheat sheet is the standard one-page reference. Then solve two or three representative problems per structure: Two Sum for hash maps, Valid Parentheses for stacks, reversing a linked list, level-order traversal for trees, counting islands for grids. The article on data structures you must know walks through the list.
The rule for these four days is that every problem is solved aloud, with a timer running. Restate the problem. State assumptions. Describe the approach in one sentence before writing anything. Narrate as you code. Name edge cases before anyone asks. It feels artificial for about two days and then it becomes how you work, which is the point. Problem sets on LeetCode or curated lists such as NeetCode are fine sources; the source matters far less than the talking.
Day 8: system design basics, only if the role needs them
Full system design rounds are rare for freshers; Design Gurus' summary matches most people's experience, which is that entry-level candidates see design only in simplified form and mostly at product companies. If your target company does ask, spend one day on a framework, not on memorising architectures: clarify requirements, estimate scale roughly, draw the simplest design, find the first bottleneck, name the trade-off. Practise it on a URL shortener and a simple news feed, twenty minutes each, aloud. The System Design Primer is the most used free reference, and Ace your system design interview walks the framework step by step.
If there is no design round, use this day for a second pass at whichever data structure went worst.
Day 9: behavioural stories
Prepare five or six real stories from your projects, internships or college: a hard bug, a disagreement in a group project, a deadline you missed, something you learned fast, a decision you would reverse. Structure each so a listener can follow it, situation, your task, what you did, what changed, and practise telling each in under two minutes. The STAR method article covers the structure. Behavioural questions are short in most technical rounds but they are assessed, and they often arrive at the end when you are tired, or in a separate HR round the same week.
Day 10: one round with a working engineer
By now the basics are fluent. This is the day to get feedback that a script cannot give: the habits you cannot hear in yourself, the answer that was correct and unconvincing, the follow-up you dodged without noticing. A mock interview with an engineer who has interviewed developers is the most valuable single hour in the plan, because real interviews never tell you why you were rejected and this one will.
If you do not know anyone who can do this properly, a structured platform fills the gap. On 99Interview a live mock interview with a working engineer runs forty minutes in the track you choose, from DSA to backend, and comes back with written feedback area by area; the AI interviewer rounds, which are cheaper and start immediately, are the right tool for the repetition days on either side of it. Both are described on the pricing page.
Read the feedback the same evening and turn it into a list of no more than three specific things to change.
Days 11 to 13: targeted repetition
Go back to cheap, frequent practice, now aimed at those three things. One round a day, one thing to fix per round, transcript read each time. Keep solving one problem aloud a day so the coding muscle stays warm, but the focus is the specific habits the engineer named. This is where the improvement compounds. There is more on sequencing the two kinds of practice in AI vs human mock interviews.
Day 14: rest, and one dry run
The day before, learn nothing new. Re-read your introduction and your stories once. If it steadies you, do one short practice round as a warm-up, then stop. Sleep matters more than one more problem, and the interviewer will notice tiredness before they notice one missing algorithm.
What this plan will and will not do
It will not make you a different engineer in fourteen days. Nothing does. It will make you far better at showing the engineer you already are: fluent about your own work, structured under a clock, honest and useful at the edge of what you know, and calm about the shape of the hour because you have been through it several times. That is most of what a fresher's interview measures, and it is the part almost nobody practises.
Frequently asked questions
Is two weeks enough to prepare for a technical interview?
Enough to improve how you perform, yes, if the time goes on active practice rather than re-reading. It is not enough to learn data structures from scratch, so if you have never studied them, spend the two weeks on fundamentals and your project and accept that the coding round may be hard.
What should a fresher study for a technical interview?
Your own project first, in depth. Then the core data structures and their complexities, OOP concepts and SQL basics if they are on your resume, and five or six behavioural stories. Everything else is secondary.
How many hours a day should I prepare?
Two focused hours on weekdays and a longer block at the weekend is realistic alongside college or a job. More hours of passive video watching do not help; more hours of solving problems aloud do, up to the point where you are too tired to think.
How do I prepare for a technical interview with no experience?
Your college projects are your experience. Understand one of them completely, be able to explain every decision in it, and be honest about what was guided. Interviewers hiring freshers expect small projects; they do not expect you to be unable to explain your own.
Should I do mock interviews or solve more problems?
Both, in that order of priority once you can solve basic problems. Solving problems silently trains knowledge. Mock interviews train the explaining, which is what most freshers fail on.
What should I do the day before the interview?
Very little. Review your introduction and stories, do one light warm-up if it helps, sleep properly. New material learned the night before is rarely usable under pressure.
Start tonight
Do days one and two now, even if you have less than two weeks. Open your resume, pick the technology you are least sure about, and write the three follow-up questions you would least like to be asked about it.
Two weeks from now you will be sitting across from someone with your resume open. Which line on it are you not yet ready to defend?