Who this is for
- · Engineers switching into product-based companies
- · Mid track: ~2–6 years, coding round is the main risk
- · Senior track: design, ownership stories, confident mediums
- · People who can give ~2 hours on weekdays consistently
Free · Shareable · Mid & Senior tracks
A mentor-style plan for engineers leaving service or captive setups and walking into product loops. DSA, LLD, HLD, stories, and resume work, with exit bars and a redo habit. Mid and Senior tracks. Not locked to one employer.
Mid (~2–6 YOE): more coding volume, solid LLD/HLD coverage.
90
Days
13
Weeks
16
HLD systems
9
LLD systems
11
Mock days
Deepak Mishra · The Desi Architect
Software Architect · 12+ years · non-CS background
How you will work
Five minutes after you close the laptop. Write what broke your flow, the pattern name, and the one sentence you wish you had said. That notebook becomes your real study guide.
Anything you could not solve clean goes on a list and returns in a few days, then again after two weeks. First-time green checkmarks lie.
From week 3, talk while you code and design. If you cannot explain it to an empty chair, you cannot explain it to a panel.
A day counts when the exit line is true for your level. Watching a solution video is not the same as being interview-ready.
Start warm outreach while you are still in the design phase. Waiting for a perfect day 90 is how you peak with an empty calendar.
End every HLD practice with one blunt sentence: what did I give up by choosing this? If you cannot answer, the design is not finished.
The 90-day journey
Tap a phase to open the week that starts it. Progress is saved in this browser only.
Day by day
One week at a time. About 2–2.5 focused hours on weekdays if you stay consistent. Exit criteria change with Mid / Senior.
Week 1 · Days 1-7
Tools, honesty about baseline, resume v0, and the first DSA patterns.
Pick language, LeetCode account, a simple notes doc, and a redo list. No fancy system yet.
Exit bar · mid
Tools ready. One sample journal entry written.
Most people skip setup and then lose every failed problem forever. The ledger is the whole point.
Rewrite 5 bullets around impact, not tasks. Numbers wherever you have them.
Exit bar · mid
Every kept bullet has a number or a clear outcome.
Recruiters skim. Task lists die. Impact lives.
Refresh complexity. Arrays and basic iteration without looking at notes.
Exit bar · mid
Explain O(n) vs O(n log n) on both solutions aloud.
Interviews start dying when people mumble complexity.
Frequency maps and set membership. This pattern pays rent for months.
Exit bar · mid
Solve Two Sum in under 15 minutes without hints.
Service-company code hides maps behind ORM. Product interviews do not.
Opposite ends, same direction, and the invariant you hold while moving.
Exit bar · mid
State the invariant for Container With Most Water in one sentence.
Abstraction, encapsulation, polymorphism, composition over inheritance, with code you already wrote.
Exit bar · mid
Explain composition vs inheritance with one real example.
LLD rounds fail on fuzzy OOP more than fancy patterns.
What interviewers grade in an HLD round. Not a tool shopping list.
Exit bar · mid
List the 5 parts of a clean HLD answer from memory.
People design Netflix on day 1 and cannot clarify requirements. Fix that first.
Read the free lesson →Week exit bar · mid
Journal exists, resume bullets have numbers, Two Sum and hashing feel automatic.
Design reps that pay rent
Not a scraped spreadsheet. A short list I keep sending mentees back to. Use it with the week stage. Problem names are industry standard. The coaching lines are mine.
Warm-up system. I care that you pick IDs deliberately and do not invent a Kafka cluster for redirects.
Algorithms on one box are easy. The real grill is multi-node fairness when money or login APIs get hammered.
Fan-out is the decision. Celebrity users break naive write fan-out. Ranking is not "we will use ML later."
Delivery states and group fan-out under flaky mobile networks. Receipts matter more than drawing a pretty WebSocket.
Separate upload/encode from watch. For India, rehearse the "whole country pressed play" spike, not only average QPS.
Chunk large files, keep metadata separate from blobs, and own the conflict story when two devices edit offline.
Push, SMS, email with retries that do not double-spam. Quiet hours and preferences are requirements, not polish.
Keystroke latency budget. Trie or prefix index is half the story. Cache and ranking make it feel product-ready.
What happens when a node dies mid-sale. Eviction, rebalance, and who still serves stale data.
Partition + replicate, then defend CAP like an adult. Brand names without access patterns will not save you.
Say the ordering promise you can keep, not the one on the marketing page. At-least-once plus idempotent consumers is the honest default.
Double charge is the failure that ends careers in this domain. Idempotency keys, ledgers, and webhook chaos first.
Moving supply on a map. Naive lat-long queries die. Match latency and ETA honesty get poked hard.
Three parties, rain, and late riders. Dispatch and tracking matter more than a pretty restaurant catalog.
IRCTC tatkal energy: hold the seat, take payment, avoid oversell when two people click the same berth.
Who fires the cron when half the fleet is dead. Workers must be safe to run twice.
If pricing is a giant if-else, rewrite it. Spot types and Strategy should fall out of the requirements naturally.
State machine first, clever scheduling second. Be ready to swap SCAN for something dumber under time pressure.
If you can cold-code only one LLD, make it this. Hash map plus doubly linked list, true O(1), no cheating with library magic in the interview.
Split rules and debt simplification without one god class that knows everyone's balance sheet.
Extensibility test. Levels, appenders, formatters. Singleton is allowed only if you can defend the test pain.
Illegal transitions should be impossible in the model, not handled with random boolean flags.
Piece behaviour belongs on types, not a 400-line switch. Validation and undo stories separate seniors.
Matching as an interface, trip lifecycle as states, pricing as Strategy. Location is a first-class idea.
Seat hold races in object design. Same muscle as tatkal, smaller canvas.
LLD toolkit
I do not want you memorising 23 GoF names. I want you recognising when Strategy saves a parking-lot pricing mess, and when a race condition will sink your "working" LLD in the last ten minutes.
When: You truly need one shared instance with controlled access.
Example: Logger or process-wide config.
Easy global state. Tests and hidden coupling suffer.
When: Callers should not hardcode concrete types.
Example: Payment method objects, vehicle types in parking lot.
Extra indirection. Worth it when types grow.
When: Object construction has many optional steps.
Example: Complex HTTP request or query object.
Verbose for tiny objects. Great for fat ones.
When: Many listeners need the same event.
Example: Ride status updates, UI-ish notifications in LLD.
Order and fan-out complexity. Memory leaks if you forget unsubscribe.
When: Algorithm should swap without rewriting callers.
Example: Pricing, discounts, elevator scheduling.
More classes. Beats giant switch statements.
When: You need undo, queueing, or audit of actions.
Example: Chess moves, ATM operations.
Indirection cost. Pays off with history requirements.
When: Behaviour changes sharply by lifecycle state.
Example: Elevator, vending machine, order flow.
Class count rises. Illegal transitions become explicit.
When: Add behaviour without subclass explosion.
Example: Middleware-style wrappers, stream-like layering.
Stacking can get hard to debug.
When: Tree part-whole hierarchy with uniform operations.
Example: File system directories and files.
Awkward if leaves and composites differ too much.
When: A request may be handled by one of several handlers.
Example: Log levels, auth middleware pipeline.
Can hide who actually handled the request.
Race conditions
Start with a broken story, not a definition. Two threads, shared seat count, one oversold ticket.
Locks and monitors
Name the critical section. Locking the whole parking lot for a ticket print is how systems feel frozen.
Deadlock
Four conditions, but interviews usually trip you on lock ordering between two resources you "obviously" needed.
ReadWriteLock
Useful when reads dominate, like cache gets. Say when writer starvation becomes the new problem.
Thread pools
Unbounded pools are a quiet production bomb. Size with a reason tied to downstream capacity.
Producer-consumer
Bounded queue forces backpressure. If the queue can grow forever, you only delayed the outage.
Atomics and volatile
Visibility is not the same as atomic read-modify-write. Counter++ still lies under races.
Thread-safe LLD
Apply it to Parking Lot gates or LRU get/put. If you cannot say what is locked, the design is incomplete.
Make a Singleton safe under concurrent first access, then tell me when you would refuse to use one.
Double-checked locking is a side quest. Testability is the main quest.
Build producer-consumer with a hard limit on queue size.
I want to hear who blocks, and what the UI or API does while blocked.
LRU cache, many readers, occasional writers. Keep it correct.
Compare one big lock vs read-write lock without cargo-culting either.
Multi-gate parking lot. Two cars arrive at once for the last spot.
Spot assignment is the race. Ticket printing usually is not.
Connection pool: borrow and return under load.
Empty pool policy: wait, fail fast, or grow? Defend one.
Heavy practice lives in week 6 (days 36–37) and LLD mock days.
HLD building blocks
Sharding
Horizontal scale vs cross-shard queries and rebalancing.
Message queue
Decoupling vs eventual processing and ordering limits.
API gateway
One entry policy point vs concentration of failure.
Stories that sound like you
Product companies still grade how you talk about conflict, failure, and ownership. Draft 6–8 real stories from your career, not movie scripts. Week 12 is for tightening delivery, not inventing a past.
Walk me through a technical disagreement you had with someone senior to you.
I listen for whether you argued the system, not the person. Bring one metric or incident, and say what you changed after the call.
Talk about a release or migration that did not go the way you planned.
Skip the blame slide. Name your part, the user impact, and the concrete guardrail you put in place next time. Service-company war stories work if the learning is real.
When did you have to choose with incomplete data, and what did you bet on?
Product rounds care about the bet and the rollback plan. Lucky outcomes without a decision process sound thin.
Tell me about work you pulled that was not in your JD, just to unblock shipping.
Ownership is not "I worked weekends." It is "I saw a hole, I owned it, here is the result." Numbers help.
Two deadlines, one engineer (you). How did you decide what slipped?
Give me your priority rule in one line. If the answer is only "I worked late," the story is not ready.
What is the hardest feedback you got on your engineering work?
Show the before and after. "I write better docs now" is weak. "I changed how I open design reviews" is stronger.
Why move out of your current setup into a product engineering role?
Stay future-facing. Scope, ownership, and craft. Never turn this into a rant about your current manager or billing model.
What kind of problems do you want to own in the next few years?
Map it to this team's systems. "I want to be an architect" without a domain is a red flag in senior loops.
How have you grown someone junior or unblocked a stuck teammate?
Senior signals live here. Mentoring is not a training calendar invite. Show one person, one skill, one outcome.
Name a design choice from your past that you would reverse today.
This is growth without drama. Explain the old constraint, the cost you paid, and what you know now. Do not trash your old team.
Same plan, different spice
A PhonePe-style loop and a Hotstar-style loop both ask "system design," but they probe different scars. Over-index on the flavours you are targeting. Style names only. Not affiliated with any employer.
Money paths forgive less than feeds. Idempotency, ledgers, retries, and "what if the webhook fires twice" matter more than fancy diagrams.
Lean harder on weeks 8-10 and the payment design day.
Think Big Billion Days pressure: inventory truth, search under load, cart races, and checkout when everyone hits buy together.
Stampede day, booking day, and cart-style LLD in the bank.
Moving supply, ETA lies, and three-sided matching (user, merchant or driver, ops). Geo is not a nice-to-have footnote.
Pair the mini LLD matching day with the geo HLD day.
India-Pakistan match on Hotstar is the mental model. CDN, encoding cost, and what breaks when a whole country presses play.
Streaming design day plus cache and CDN weeks.
Multi-tenant thinking, file sync, job schedulers, chat for work, and messaging buses. Reliability and operability get probed hard.
Chat, scheduler, storage, and queue days in the HLD block.
Fan-out choices, ranking honesty, notifications that do not spam, and chat that still works on bad networks.
Feed, chat, autocomplete, and notification days in week 9-ish.
Quick answers
A free day-by-day plan from The Desi Architect covering DSA, low-level design, high-level system design, behavioral stories, and resume work for engineers switching into product-based companies. It includes Mid and Senior tracks with exit criteria.
Yes. The full 90-day plan, problem bank, patterns guide, and domain flavours are free to use and share at desiarchitect.com/roadmap/90-day-plan. Optional paid cohort and learning paths are linked for people who want feedback.
Engineers moving from service, captive, or non-product backgrounds into product engineering roles. Mid track suits about 2 to 6 years experience. Senior track suits about 8 to 15 years with more design and storytelling emphasis.
Yes. The plan interleaves coding practice with object design and system design, plus mocks and behavioral prep so you do not study one round and forget the others.
No. It is generic for product-based companies. Domain flavours (payments, marketplace, ride-hail, streaming, enterprise, social) help you over-prep the systems your targets usually probe.
From the mentor desk
Keep a simple redo ledger. The problems that beat you once will beat you again in the loop if you never return to them. I have watched strong engineers blank on a pattern they "solved" three months ago and never re-opened.
From week 3, talk while you design. Mute coding heroes die in HLD. Interviewers grade the explanation path, not only the final boxes.
Book three uncomfortable mocks before you call yourself ready: one DSA, one LLD, one HLD. Friends who are nice to you do not count as feedback.
Say the trade-off out loud before they ask. "I picked this and I gave up that." That sentence alone separates mid from senior in a lot of rooms I have sat in.
Pick two domain flavours and over-prep them. UPI-style money paths and Hotstar-style spikes need different instincts than a generic CRUD service.
Protect sleep. Two honest hours after office for three months beats a heroic weekend binge and a foggy Monday OA.
Open applications while you are still in the HLD phase, not on day 90. Pipelines are slow. Peaking alone with zero calls is a planning failure, not bad luck.
Go deeper
This roadmap is free and yours to share. If you want live teaching, structured lessons, or a personal mock, here is what I run.
Weekly live sessions, mock interviews, and a mentor checking your designs. Not another playlist you abandon at week three.
See the cohortSelf-paced lessons covering the HLD spine of this roadmap, with quizzes and progress tracking.
RAG, agents, evaluation, cost. Useful when your target companies ship AI features (see optional day 89).
Resume review, mock interview, or a personal plan cut from this roadmap to your targets.
Book on Topmate