The 90 days it actually takes to move from TCS-shaped work to a product company

A friend of mine at Cognizant spent four months applying to product companies before a single recruiter called back. His resume said “maintained legacy billing module, resolved production tickets, ensured SLA compliance.” True, all of it. Also completely invisible to anyone screening for ownership. He rewrote three lines and the callback rate changed within two weeks. Nothing about his actual work history changed. Only the words did.

That’s the real story behind the service based to product based switch, more often than the DSA-gap story everyone leads with. This is a 90-day plan, broken into what actually blocks people, roughly in the order it bites.

Block one: the resume, the first wall in the service based to product based move

Service company resumes describe activity. Product company resumes describe impact and decisions. “Resolved 40 production tickets a month” says you were reactive. “Reduced ticket volume 22 percent by rewriting the retry logic in the payment reconciliation job” says you found a cause and fixed it. Same person, same three months of work, completely different signal.

Days 1 through 10: go through every bullet on your resume and ask one question per line: did I decide something, or did I execute something someone else decided? If it’s the latter, either rewrite it around the smallest decision you did make, or cut it. A shorter resume with four strong lines beats a full page of maintenance work.

This is uncomfortable because a lot of TCS, Infosys, Wipro, Accenture and Cognizant work genuinely is maintenance, and pretending otherwise invites a follow-up question you can’t answer in the interview. The honest move is finding the sliver of ownership inside the maintenance, not inventing one.

Before-and-after: rewriting the actual bullets

A rough rule that’s worked for people we’ve talked to going through the service based to product based transition: for every ticket-closing line, find one line where you changed a process, however minor. Wrote a script that automated a manual step. Flagged a recurring bug pattern to your lead before it became an incident. Suggested a monitoring alert that didn’t exist. None of these sound like Silicon Valley war stories, and that’s fine. Product recruiters have read thousands of resumes; they recognize a real, small decision faster than they recognize inflated language dressed up to sound like one.

Here’s what that rewrite looks like on an actual bullet, not just in theory. Before: “Handled production support for the billing module, resolved tickets raised by client team, ensured timely closure as per SLA.” That line is true, common, and says nothing about you specifically. After: “Cut recurring billing-module tickets by identifying that 60 percent of them traced to one unhandled currency-rounding edge case; fixed it and wrote the regression test that would have caught it.” Same underlying work, told as a decision instead of a chore.

Second example, same idea. Before: “Performed regular database maintenance activities including backup verification and index rebuilding as per schedule.” After: “Rebuilt a query index that was silently degrading a nightly batch job, cutting its runtime enough that the team stopped manually restarting it every morning.” Notice neither rewrite invents a scale that wasn’t there. Both just name the cause you found and the effect of fixing it, which is exactly the shape a product-company screener is scanning for.

Block two: no system design exposure, because nobody asked you to design anything

Service company engineers often work several layers below where architectural decisions get made. You’re implementing a spec, not writing one. Product interviews assume the opposite: that you’ve reasoned about trade-offs, not just followed them.

Days 11 through 45 is the longest block, and it should be. Two things happen in parallel here. First, you study system design from first principles, not from memorized diagrams: read about consistency models, caching layers, and queue-based decoupling until you can explain why a system needs them, not just that it has them. Second, and more useful, and probably the more valuable half of these five weeks, you go find the one design decision buried in your own work history. Even a service company engineer usually made at least one real call: which index to add, whether to batch or stream a job, how to handle a retry storm. Build your system design story around that, however small it feels.

Our system design interview guide is a reasonable starting map if you’ve never touched the topic before. Expect to spend more hours here than on any other block; unlike DSA, there’s no shortcut list that covers system design the way Blind 75 covers coding, and most people underestimate that going in.

Block three: the DSA gap, which is real but overrated as the main blocker

Yes, product companies test data structures and algorithms harder than most service companies do internally. But I think the DSA gap gets blamed for switches that actually failed for resume or communication reasons. Engineers spend 60 days grinding LeetCode and zero days rewriting their resume, then wonder why the interviews they do land go nowhere.

Days 20 through 60, overlapping with system design prep: aim for consistent, not exhaustive. Thirty well-understood problems beat 150 pattern-matched ones. The Blind 75 or a similarly curated list is enough for most mid-level product interviews. If you’re already six months into a grind and still bombing interviews, the problem probably isn’t volume. It’s more likely the two blocks above: a resume that undersells you, or an explanation style that reads flat under pressure.

Block four: the notice period, which nobody plans around until it’s too late

This one is structural, not skill-based, and it costs candidates offers directly, and it’s the block people plan for last even though it starts mattering from day one of the search. A 90-day notice period is the services-sector default once you are a few years in, and most product companies run 30 to 60 days. An HR reference I checked on 6 September 2026 describes the 90-day norm the same way, though I have not found a primary survey that puts a trustworthy percentage on how widespread it is. A hiring manager with an open headcount and a 30-day expectation does not always wait three months for you.

Days 60 onward: know your exact notice period before you’re in a final round, not after an offer lands. Some services companies allow notice buyout for a fee; find out yours in advance rather than negotiating it under pressure during an offer call. If buyout isn’t feasible, say so early and let the hiring manager decide whether they can wait. Being upfront costs you nothing. Discovering it during background verification costs you the offer.

Check your appraisal cycle too, while you’re at it. Resigning three weeks before a bonus payout or a hike letter is a small, avoidable mistake that a surprising number of engineers make anyway, usually because they’re focused on the new offer and forget the old company still owes them something.

What the first loop actually tests that service-company work doesn’t

The format itself is a shock the first time through. A typical product-company loop for a mid-level engineer runs one or two coding rounds, one system design round, one behavioral round, and sometimes a bar-raiser or hiring-manager round that can override the rest. Service-company interviews, by contrast, often skip system design entirely for anyone below a lead title, because the work itself never required designing a system from scratch.

That mismatch shows up fastest in the design round. You’re handed an ambiguous prompt, something like “design a URL shortener” or “design a notification service,” and asked to drive the conversation yourself: pick the entities, pick the trade-offs, defend a choice when the interviewer pushes back. Nobody hands you a spec. If your service-company role consisted of implementing specs someone else wrote, this is the first time you’re being asked to write one out loud, under a clock, in front of a stranger grading you.

The behavioral round is a smaller but real gap too. Product companies tend to probe for a specific decision you made and its consequence, not a description of your role. “Tell me about a time you disagreed with a technical decision” assumes you were in a position to disagree with one. If your day-to-day gave you little room to push back on architecture, you’ll need to reach further back, even into a smaller decision, to have a real answer rather than a generic one about teamwork.

Communication, the block that’s hardest to schedule

Product interviews lean harder on you narrating your thinking out loud, not just arriving at a correct answer. This is genuinely a different skill from writing correct code quietly, and it’s the one most prep plans skip because it doesn’t fit into a checklist. Practicing out loud, even alone, closes more of the gap than another week of silent LeetCode does. If you can, run a few mock rounds where someone actually interrupts you mid-thought, because that’s what a real interviewer does and silent practice never simulates it. Engineers coming from a service based to product based background often default to silence when stuck, since raising a hand mid-task wasn’t rewarded in a ticket queue. Interviewers read that silence as low confidence even when the underlying reasoning is fine.

An opinion that might be wrong

I think most engineers over-invest in DSA and under-invest in resume rewriting, in something like a 4-to-1 ratio when it should be closer to even. The market data backs the ownership angle more than the grind angle: the US Bureau of Labor Statistics put the median software developer wage at $135,980 in May 2025, with 10 percent employment growth projected through 2035, which tells you demand exists. What decides who captures that demand isn’t raw coding ability at the margin. It’s whether a recruiter reading your resume for six seconds sees a decision-maker or a ticket-closer. I could be wrong about the ratio. I don’t have a controlled study, just a lot of resumes that got rewritten and then got callbacks. Take it as an informed guess, not a fact.

Ninety days is tight but real, if you run the blocks in parallel instead of finishing one before starting the next. Most people fail the switch by doing them in series, spending all 90 days on DSA and discovering on day 91 that their resume still reads like a support ticket log. If your practice loop needs a second set of eyes before the real thing, our resume rewrite guide is the place to start, not the algorithms.