How to Create a 90-Day Software Engineering Placement Plan

Most 90-day placement plans fail not because the topics are wrong, but because the sequencing ignores your semester. You get a list of DSA patterns, a vague instruction to "practice daily," and no answer for what happens when internals land in Week 6. This plan is different: it is built around a realistic 3–4 hour weekday budget, branches at Week 5 based on whether you are targeting service or product companies, and includes a minimum viable fallback for when life interferes. By the end, you will have a week-by-week tracker with measurable checkpoints, not another topic dump.

How many hours a day can a tier-3 engineering student actually study for placements?

Three to four focused hours on weekdays and six to seven on weekends is the realistic ceiling for most students juggling labs, attendance requirements, and commuting. Not eight. Not ten. Plans that assume otherwise collapse by Week 3, and a collapsed plan is worse than a modest one you actually finish.

The weekday split that works for most people: 90 minutes of DSA, 45 minutes of aptitude, and 45 minutes split between project work and one core subject. That is 3 hours of genuine cognitive effort, not 3 hours of having a textbook open. Weekend blocks go deeper — a 2-hour DSA session, a full aptitude mock, and a project push.

Protecting this time is the hard part. Two mechanisms help. First, anchor study to fixed slots — 7–9 PM on weekdays is more defensible than "whenever I'm free," because it becomes a habit rather than a decision. Second, treat attendance-heavy lab weeks as known disruptions and pre-load lighter topics into them. You cannot out-discipline a semester; you can plan around it.

If you want to understand where your baseline sits before committing to a schedule, a placement readiness assessment gives you a starting point rather than a guess.

What should the week-by-week 90-day coding roadmap look like?

The 13 weeks divide into four phases: foundations (Weeks 1–4), pattern depth and project polish (Weeks 5–8), mocks and CS fundamentals (Weeks 9–11), and company-specific prep plus revision (Weeks 12–13). Each phase has a measurable exit condition, so you know whether you are on track rather than hoping.

Weeks 1–4 are about volume and comfort. You are not trying to master dynamic programming; you are building the reflex of reading a problem, identifying the pattern, and writing working code under mild time pressure. If you have not coded seriously before, this phase takes longer, and that is fine — see the non-CS adjustment below.

Weeks 5–8 are where most students plateau, because the problems stop being pattern-recognizable. This is the phase where re-solving problems you got wrong two weeks earlier matters more than solving new ones. It is also where your project should stop being a tutorial clone and start being something you can defend in an interview.

Weeks 9–11 shift from building to performing. Mocks are not optional here. Neither are CS fundamentals — DBMS normalization, OS scheduling, and OOP principles come up in almost every technical round, and they are cheap to revise if you have notes.

Weeks 12–13 are company-specific. If you know the recruiter's pattern — TCS NQT, Infosys, Wipro, or a product company's DSA-heavy loop — you prepare to that pattern rather than to a generic syllabus. For the broader sequencing logic behind this, the full placement preparation timeline explains how this 90-day block fits into a longer placement cycle.

Should you focus on DSA or aptitude first in a 90-day plan?

Run both in parallel from Day 1, but weight them based on your target. Product companies weight DSA depth heavily; service companies weight aptitude and verbal ability alongside basic coding. A 60/25/15 split (DSA/aptitude/core) suits product roles; a 40/40/20 split suits service roles.

Students who wait until Week 9 to start aptitude usually discover that verbal and logical reasoning need more repetition than they expected. Starting aptitude in Week 1 costs you 45 minutes a day and removes a late-stage panic.

The fork happens at Week 5. By then you should know whether your campus pipeline is dominated by service companies, product companies, or both. That determines whether Weeks 5–8 lean into DSA pattern depth or into aptitude speed and accuracy. The trade-offs between the two tracks are covered in detail in service company vs product company preparation.

How many LeetCode problems should you solve in 90 days?

Aim for 150–200 problems: roughly 100 easy, 70–90 medium, and 5–10 hard. The count matters less than the pattern coverage. If you can recognize and implement sliding window, two pointers, hashing, BFS/DFS, and basic DP without hesitation, you have covered the high-frequency set that most freshers' interviews draw from.

Re-solving is where the gains hide. A problem you solved three weeks ago and can no longer solve is a problem you never learned. Build a simple tracker: date solved, pattern, and whether you needed a hint. Revisit anything flagged every two weeks.

Skip low-ROI topics if you are time-constrained. Advanced graph algorithms, segment trees, and heavy combinatorics rarely appear in fresher interviews outside a small set of product companies. If your target list does not include those companies, the hours are better spent on medium-difficulty arrays and strings done cleanly. A structured DSA roadmap for placements helps you prioritize which patterns to lock down first.

How should non-CS branch students adjust the 90-day plan?

Non-CS students follow the same 13 weeks with two adjustments: spend Weeks 1–2 on programming fundamentals and basic DSA if you have not coded seriously, and lean on your branch's quantitative strength to compress aptitude prep. ECE, Mechanical, and Civil students often have stronger quant fundamentals than they realize, which frees up time for DSA.

Pick one project in your domain that still demonstrates software skills — an IoT dashboard with a real backend, a data pipeline for sensor readings, a small simulation tool. The point is not the domain; it is that you can explain the architecture, the trade-offs, and what you built versus what you used. The non-CS to software placement transition covers this in more depth.

What does a project that signals competence actually look like?

One deployed project with a live URL beats five tutorial clones. The signals recruiters look for are simple: a README with an architecture diagram, a clear "what I built vs what I used" section, and a commit history that shows you wrote the code rather than copied it in one dump.

Your project should have a single clear purpose and at least one non-trivial decision you can defend. "I used PostgreSQL instead of MongoDB because the data was relational and I needed joins" is a defensible decision. "I used MongoDB because it's popular" is not. If your project has no such decision, add one — even retrofitting a caching layer or a proper error-handling path gives you something to talk about.

For a broader view of what to put on your profile, see the GitHub portfolio for freshers guide.

How do you handle slippage and backlogs in a 90-day plan?

Build in two buffer weeks — one at Week 7 and one at Week 13 — and switch to a minimum viable plan if you fall more than a week behind. The minimum viable plan is DSA (arrays, strings, hashing, two pointers) plus aptitude mocks. Drop project polish and advanced CS subjects. You can still clear most service-company rounds on this reduced scope.

Falling behind by a week is normal and expected. Falling behind by a month means the original plan was too ambitious, not that you failed. Adjust the scope, not the goal. If you have backlogs, treat clearing them as a parallel track with its own fixed slots — do not let them consume the placement prep entirely, and do not pretend they will clear themselves.

Should you apply off-campus while running this plan?

Yes, from Week 1. Waiting until Week 13 to start applying is the single most common mistake in placement preparation. Off-campus hiring runs on its own calendar, and the pipeline from application to interview often takes weeks. Start early and maintain a tracker sheet.

Your cadence: 5–10 targeted applications per week on LinkedIn, Naukri, and company career pages, plus one referral outreach message per week to alumni or former interns. Referrals do not guarantee anything, but they move your application from a pile to a person. Keep the messages short and specific — what you built, what role you are targeting, and one line on why you are reaching out to them.

Track every application: company, role, date applied, status. Without a tracker, you will lose track of follow-ups and repeat applications, both of which cost you.