How to Prepare for a Software Engineering Internship Interview: A 90-Day Plan

How to prepare for an internship interview in 90 days: a week-by-week SDE intern preparation plan covering DSA, CS fundamentals, projects and mocks.

By InternHack Team · 2026-09-29 · 9 min read · Interview Prep

This plan is for second and third year CS students in India who want a software engineering internship and are not sure where to start. It splits about 13 weeks into a sequence you can follow on 2 to 3 focused hours a day, with a clear output for each week. If you have less time, keep the order and stretch the weeks.

Before you start: what internship interviews actually test

Most SDE intern processes have three parts: an online assessment (usually 2 to 3 coding problems, sometimes with MCQs), one or two technical interviews, and sometimes an HR conversation. Interviewers know you have little work experience, so they test three things: can you solve a medium-level problem while explaining your thinking, do you understand core CS basics, and can you talk honestly about something you built.

That means the plan needs five tracks running in parallel: DSA, one language in depth, CS fundamentals, projects, and communication. Applying is a sixth track that many students start too late.

Pick one programming language now and stay with it. Python, Java and C++ are all acceptable. Switching in week 6 wastes time.

The 13-week plan at a glance

The sections below explain each block.

Weeks 1 to 2: language depth and the first patterns

In week 1, learn your language properly. For Python that means lists, dicts, sets, heaps via heapq, sorting with keys, and slicing costs. For Java it means ArrayList, HashMap, PriorityQueue, StringBuilder, and how equality and hashing work. For C++ it means the STL containers, iterators, and when vector beats everything else.

At the same time, learn to reason about complexity. If Big O still feels vague, read our guide on Big O notation with interview examples before you go further, because every later problem depends on it.

If you need a structured path, DSA foundations covers the basics in order, and the DSA section has practice problems grouped by topic.

Week 2 is arrays, strings and hash maps. These make up a large share of intern-level questions. Focus on a few recurring ideas:

• Counting with a dictionary or frequency array
• Using a set for O(1) membership checks
• Sorting first, then scanning
• Two-sum style "store what I have seen" lookups

Solve 15 problems and, for each, write one line naming the pattern. That habit of naming patterns is what makes later problems feel familiar.

Weeks 3 to 5: core patterns

Week 3 covers two pointers, sliding window and prefix sums. These turn many O(n²) brute force answers into O(n). When you see "longest substring", "subarray with sum", or "sorted array and a target", check these first.

Week 4 is linked lists, stacks and queues. Practise reversing a list, detecting a cycle, merging two sorted lists, matching brackets with a stack, and the monotonic stack idea for "next greater element". Draw pointers on paper. Most linked list bugs are pointer bugs you can see on a sketch.

Week 5 is recursion, backtracking and binary search. Start with subsets and permutations to get comfortable with the choose, explore, undo structure. Then do binary search on sorted arrays and on answers ("find the minimum capacity such that..."). Binary search on the answer space is a favourite in online assessments.

A rule for all three weeks: spend at most 25 to 30 minutes stuck on a new problem. Then read the hint or the solution, close it, and re-implement from memory the next day. Reading solutions is fine. Never reproducing them is the trap.

Weeks 6 to 7: trees, graphs and a first look at DP

Trees come first because recursion on trees is the most common interview skill. Cover traversals (inorder, preorder, level order), height, diameter, lowest common ancestor, and validating a BST. Learn both the recursive and iterative versions of at least one traversal.

Week 7 covers graphs: BFS and DFS on adjacency lists and grids, connected components, cycle detection, topological sort, and shortest path in unweighted graphs. Add heaps for "top K" problems.

Then spend a few days on introductory DP: climbing stairs, house robber, coin change, longest common subsequence. Do not aim for hard DP. An intern candidate who can define a state and a recurrence for a simple problem is already ahead of most.

By the end of week 7 you should have roughly 100 to 120 problems solved with understanding. That is approximate and quality matters more than count. If a topic still feels shaky, repeat it during weeks 12 and 13.

Weeks 8 to 9: CS fundamentals

Interviewers usually ask CS fundamentals in the technical round, often as follow-ups to your resume. Keep it targeted rather than reading full textbooks.

Operating systems (week 8). Processes vs threads, context switching, scheduling algorithms, deadlock and its four conditions, mutex vs semaphore, paging and virtual memory. Our operating systems interview guide lists the questions that come up most.

DBMS (week 8). Keys, normalisation up to 3NF, ACID properties, transactions and isolation levels, indexing and why it speeds reads but slows writes.

Computer networks (week 9). The OSI and TCP/IP layers, what happens when you type a URL in a browser, TCP vs UDP, HTTP vs HTTPS, DNS. See the computer networks interview guide.

OOP (week 9). Encapsulation, inheritance, polymorphism, abstraction, and the difference between abstract classes and interfaces. Be ready with a small real example for each. The OOP interview page is a good checklist, and Java users should also look at the Java interview questions.

SQL (week 9). Joins, GROUP BY with HAVING, subqueries, window functions at a basic level. Practise by writing queries rather than reading them, using the SQL playground. Our post on SQL interview questions and patterns shows the types that repeat.

For each subject, do this: write a one-page summary in your own words, then answer 30 questions out loud without notes. Speaking the answer exposes gaps that reading hides.

Week 10: projects that survive questioning

One good project beats four weak ones. Choose a project that you can explain end to end: why you picked the stack, how the data is modelled, what went wrong, and what you would change.

Checklist for a project that holds up in an interview:

• A public GitHub repository with a real README: what it does, how to run it, a screenshot
• Deployed somewhere so the link works
• At least one non-trivial decision you can defend, such as an index you added, caching, auth, or handling of a race condition
• Some tests, even a few

Expect questions like "why did you use this database?" and "what happens if two users do this at the same time?". If you cannot answer, that is your study list for the week. If you want open-source contributions to strengthen this section, start from the open source page.

Week 11: resume and applications

Your resume should fit one page, list projects with measurable outcomes where you honestly have them, and avoid tables, images and multi-column layouts that applicant tracking systems parse badly. Run it through the ATS score checker and read our guide to an ATS-friendly resume for freshers.

Then start applying, and do not wait until you feel ready. Browse internships and external jobs, and keep a simple spreadsheet with company, role, date applied, and status. Aim for volume in the first round, since response rates for freshers are low everywhere. Ask seniors and alumni for referrals. A short, specific message with your resume attached works better than a generic request.

Week 12: mock interviews

Do at least four mocks this week, ideally with a friend or senior who will be blunt. A mock should follow the real format: 45 minutes, one or two problems, talking through your approach out loud, and 10 minutes of fundamentals or project questions.

During the coding part, follow the same routine every time:

1. Repeat the problem in your own words and ask about constraints.
2. Give a brute force answer and its complexity.
3. Improve it, and say why the better version works.
4. Code cleanly, then dry-run on a small example.
5. Test edge cases: empty input, one element, duplicates.

Also prepare for the non-coding part. Write short stories for "tell me about yourself", "a project you are proud of" and "a time you faced a conflict or failure". Use the structure in our STAR method guide and skim the behavioral interview page.

Week 13: revision, gaps and follow-through

Use week 13 to fix what the mocks exposed. Redo the five problems you found hardest without looking at solutions. Revisit the two fundamentals topics you answered worst. Keep applying, because a few weeks of interview outcomes will start arriving by now.

For a broader map of what to learn and in which order, the roadmaps section and the interview prep hub can fill any gaps you notice.

Common mistakes in intern prep

• Solving without reviewing. Two hundred problems done once teach less than eighty problems reviewed twice.
• Only doing DSA. Many interviews spend half the time on fundamentals and projects.
• Hiding in tutorials. Watching solutions feels like progress but does not build the skill of getting unstuck.
• Applying late. Many internship cycles open months before start dates, so applications should begin around week 8 to 11 at the latest.
• Silent coding. Interviewers cannot give you credit for thoughts you do not say.

If you fall behind, cut breadth, not consistency. It is better to finish a smaller plan than to abandon a large one.

FAQ

How do I prepare for an internship interview with no experience?

Treat projects and fundamentals as your experience. Build one solid project, learn the standard DSA patterns, and revise OS, DBMS, networks and OOP basics. Interviewers for intern roles expect potential and clear thinking, not industry history.

How many DSA problems should I solve before applying?

There is no fixed number. Around 100 to 150 well-understood problems across arrays, strings, hashing, trees, graphs and basic DP is a reasonable target for most intern-level interviews. Understanding the pattern behind each problem matters more than the total.

Is 90 days enough for SDE intern preparation?

For most students who already know one language and basic programming, yes, if you study consistently for two to three hours a day. If you are starting from zero, stretch the plan to 120 days and spend the extra time in the first two weeks.

Which programming language should I use for the interview?

Use the language you know best among Python, Java or C++. Python is quickest to write in an interview, while C++ and Java are common in competitive programming and campus tests. Consistency matters more than the choice.

When should I start applying for internships?

Start once your resume is ready and you have solved your first 50 to 60 problems, around week 8 to 11 of this plan. Continue preparing while applications are in progress, because responses and interview dates come with little notice.