How to Switch Jobs with 1–3 Years of Experience in India

Two years into your first job is often the best leverage you will have early in your career. You are no longer a fresher competing with lakhs of graduates. You have shipped real code, sat through production incidents and worked inside a team. But you are also not senior enough to be hired on reputation. The bar sits in between, and most people get it wrong in one of two ways: they prepare as if for campus placement (pure DSA, no story about their work), or as if for a senior role (system design videos, weak fundamentals).

This guide is for engineers in India with roughly 1–3 years of experience, whether you are at TCS, Infosys, Accenture or another service company, a small startup, or a product company that has stopped teaching you anything. It covers what you will be tested on, which level to aim for, how to present experience you may think is unimpressive, a 12-week plan, and how to handle notice periods and money.

Is It the Right Time to Switch? A Quick Decision Check

Switching at around 2 years is normal in Indian tech and nobody will hold it against you. Switching for the wrong reason can still set you back. Run through this table honestly.

If most of your answers are in the left column, start preparing now. Preparing costs you nothing even if you decide to stay, and having a competing offer is the strongest lever you have in your current company too.

What Interviewers Actually Expect at 1–3 Years of Experience

At this level, interviewers are mostly answering one question: "Can this person take a well-defined task, write correct and maintainable code, and grow into owning a component within a year?" Here is how that breaks down by round. Formats vary by company, so confirm the loop with your recruiter.

The gap between 2 YOE and fresher expectations

• Production awareness. You should be able to talk about logging, monitoring, a deployment pipeline, how a bug reached production and how it was caught. Freshers get a pass on this; you don't.
• Code quality. In DSA rounds, interviewers notice whether you write helper functions, meaningful names and a few test cases without being asked.
• Fundamentals behind your stack. If your resume says Spring Boot, expect questions about how dependency injection works, transactions and connection pools. If it says React, expect the rendering model and state management. The Spring Boot and React/JavaScript question banks are good checklists.
• Database basics, done properly. Indexes, joins, transactions and isolation levels come up a lot, because most of your actual work touches a database.

Which Level to Target: SDE-1 or SDE-2?

Level names differ by company, but the rough mapping below is commonly reported. Treat it as a starting point and confirm with the recruiter, since levelling is decided from your interview performance, not only your years.

My advice: at under 2.5 years, apply for SDE-1 at the best companies you can reach. A down-level at a top company with strong engineers usually compounds faster than an inflated title at a weak one, and promotion from SDE-1 to SDE-2 at a good company typically takes 1.5–3 years (see how to get promoted from SDE-1 to SDE-2). At 3+ years, apply for SDE-2 where you can show real ownership and can handle a design round, and accept SDE-1 offers only where the compensation and team clearly justify it.

Positioning: Turning "I Fixed Tickets" into a Strong Profile

Most engineers with two years at a service company or a small team undersell themselves. The work was real; it just needs translating into the language product companies hire on: problem → your decision → measurable outcome.

Rewrite bullets around decisions

Use numbers you can defend. Approximate is fine ("~40 minutes") as long as you can explain how you measured it. Interviewers will ask, and an invented number falls apart under a single follow-up. The full method is in the resume guide for product companies.

Mining "boring" work for stories

Ask yourself these questions about the last two years and write down every answer:

• What was the hardest bug I found, and how did I narrow it down?
• What did I automate that someone else used to do by hand?
• When did I disagree with a design or estimate, and what happened?
• What did I learn about the system that the documentation didn't cover?
• Which incident or outage did I take part in, and what changed afterwards?

Each answer becomes a resume bullet, a behavioural story and a starting point for the project deep-dive round, which is covered in depth in how to explain your projects in an interview.

If your work genuinely has no engineering depth

Sometimes the honest answer is that you were in L1 support, manual testing, or on the bench for a year. In that case, build one serious project in the stack of the jobs you want (for example a backend service with auth, a database, caching, tests and deployment) and present it as what it is. A real, well-reasoned side project is credible at 1–2 YOE. Ten tutorial clones are not. See side projects that impress product-company interviewers.

The 12-Week Prep Plan for a Working Engineer

This assumes about 12–15 hours a week: around 1.5 hours on weekdays and 4 hours on each weekend day. With an interview already scheduled, compress the DSA part into the 30-day coding plan.

Two points matter more than the exact topics. First, apply from week 5–6. Hiring pipelines take 3–6 weeks from application to final round, so the early interviews arrive just as you become ready, and the first one or two act as real-world mocks. Second, schedule your dream companies last. Warm up on companies you would be happy with but are not desperate for.

Getting Interviews When You Are Not Yet "Experienced"

At 1–3 YOE, how you get in matters. Roughly in order of conversion:

1. Referrals. A referral from an engineer at the company moves your resume to a human reviewer much faster. Message people with a specific job ID, your resume and three lines on why you fit. Templates are in how to get referrals.
2. Recruiter inbound via LinkedIn and Naukri. Keep your headline as "Software Engineer | Java, Spring Boot, AWS | 2 YOE"-style keywords, set "open to work" visible to recruiters only, and update your Naukri profile regularly; recruiters filter on recency.
3. Direct applications on company career pages soon after a role is posted.
4. Hiring drives and hackathons run by product companies and GCCs, which often fast-track OA-qualified candidates to final rounds.

Track every application in a sheet with company, date, source, stage and next action. At this stage, most people lose offers to disorganisation: forgotten follow-ups, two final rounds on the same day, an OA link that expired.

The Questions Only Early-Career Switchers Get (With Sample Answers)

"Why are you leaving after just two years?"

"I've learned a lot at my current company. I joined as a fresher and now own the reconciliation service for one client. But the work there is mostly maintaining existing modules, and I want to build and own backend systems end to end at product scale. That's why this role on your payments platform team appeals to me. Over the last six months I've been building toward it by learning how Kafka-based event pipelines work and applying it in a small project."

Why it works: it is forward-looking, specific to the role, shows initiative, and doesn't criticise anyone.

"Why should we hire you over a fresher, or someone with five years?"

Talk about what two years have given you that a fresher lacks (production experience, working in a team codebase, debugging real incidents), along with the speed of someone early in their career. Give one concrete example of each.

"What is your current CTC and expected CTC?"

Know your exact breakdown: fixed, variable, joining bonus, stocks. If the company asks for your expectation, give a researched range based on the role rather than a percentage of your current pay. This matters a lot when your current pay is low. The scripts are in how to answer salary expectations.

"Tell me about a mistake you made."

Engineers with two years always have a real one: a migration without a rollback plan, a missing null check that broke a batch, a deploy on a Friday. Pick a real mistake with a clear lesson and a change you made afterwards. "I'm a perfectionist" fails this question every time.

Notice Periods, Appraisal Cycles and Timing the Move

In India, timing is part of the strategy. Many service companies commonly have notice periods of 60–90 days, while product companies and startups more often have 30–60 days. Check your appointment letter, since the actual number is whatever you signed.

Interview while employed; resign after the offer

Larger product companies and GCCs are used to 60–90 day notice periods and will usually wait for good candidates. Some startups need people within 30 days and will pass, which is a real but limited cost. Resigning first to "become immediately available" removes your negotiating leverage and your income, and puts you under time pressure. It is only worth considering if you have several months of savings and recruiters keep rejecting you specifically for the notice period.

Shortening the notice period

• Early release: ask your manager after a clean handover plan. Many companies agree to partial early release, especially if you are not on a critical project.
• Leave adjustment: some employers allow unused earned leave to be set off against the notice period. Check your policy.
• Buyout: paying basic salary for the unserved days. Some new employers reimburse this; ask before you accept the offer, not afterwards.

Details and email templates are in the notice period negotiation guide.

Appraisal and bonus timing

If your annual appraisal or variable payout is 4–8 weeks away, it is often worth timing your resignation after it lands. Your new offer is usually anchored on your current compensation, so a fresh hike helps the negotiation too. Also check joining-bonus clawbacks (commonly prorated if you leave within 12 months) and any training bond from your campus offer.

Hike Expectations at 1–3 YOE

These are approximate ranges commonly reported on public sources such as AmbitionBox, Glassdoor and levels.fyi, and in community discussions. They vary a lot with skills, company, city and negotiation. Use them to sanity-check an offer, not as a promise.

For what an SDE-1 or SDE-2 actually earns at different company tiers, see SDE-1 to principal salaries in India. For how hikes are calculated and justified, the companion post on salary hikes on a job switch goes deeper. One rule from both: compare fixed to fixed. A ₹22 LPA "CTC" with ₹4 LPA variable, a ₹2 LPA one-time joining bonus and ₹3 LPA of stocks vesting over four years is a very different offer from ₹22 LPA fixed.

Common Scenarios and What to Do

"I'm at TCS/Infosys/Wipro on a support project"

Your DSA and project story will carry most of the weight. Build one solid backend project, follow a product-company prep plan (the 90-day roadmap for service-to-product switchers was written for this), and aim for SDE-1 at mid-size product companies and GCCs first. Then go for the top tier.

"I'm at a startup with broad but shallow experience"

You have more ownership stories than most, but probably weaker fundamentals and DSA. Spend more prep on DSA and core CS, and present your breadth as end-to-end ownership: "I built the notification service, set up its CI and was on call for it."

"I'm at a product company and want a bigger brand"

Your experience translates directly. The bar is DSA plus the depth of your project discussion. Lean into design and scale questions about your own systems; you are well placed to aim for SDE-2 around 3 years.

"I switched once already within a year"

Make this switch count for 2–3 years. Be more selective about the team, and ask about attrition and project stability in the final rounds. A clear story ("I left X after 10 months because the product was shut down") is fine; three unexplained short stints are not.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.