Fourteen Questions Worth Answering Before You Change Jobs

The short answer: questions to ask before changing jobs

The most useful questions to ask before changing jobs are not about the new company. They are about you: why you want to leave, whether the reason will survive a good week, and what you actually need next. Most job changes are decided in a bad week and executed within a fortnight. Sometimes that is exactly right. Often it produces a lateral move into a different set of problems, discovered around month four, when you have spent your credibility at the old place and have none yet at the new one.

The move was not wrong so much as unexamined. I have seen this many times while mentoring engineers, from juniors at software houses in Lahore and Karachi to seniors working remotely for companies abroad, and the pattern is the same everywhere.

So here are fourteen questions worth answering before you change jobs, covering the whole arc: deciding whether to go, choosing what to go to, not being talked into or out of it, and leaving in a way you will still be glad about in five years.

Should I change my job? Decide the why first

Before the questions, a quick diagnostic. Most reasons for leaving fall into one of a few buckets, and each has a different best first move.

Managers matter more than almost anything else in how a job feels. Gallup's research on the state of the American manager found managers account for at least 70% of the variance in employee engagement across business units. If the problem is one person, the answer might be a different team rather than a different company.

Deciding whether to change jobs at all

1. Would I still want to leave after a good week?

Decide from a flat mood, not this one. Give it a few weeks and see whether the feeling survives a good sprint. Frustration is a poor navigator: it reliably tells you what to move away from and says nothing about where to go. Write down the reason in one sentence, then look at it again in a month.

2. Have I asked for the next thing here first?

If you have run out of things to learn but your manager likes you, ask for the next challenge before you look outside. An internal move to a different team or problem is usually faster, cheaper and lower risk than an external one, and a surprising number of people leave without ever asking. Ask specifically, and treat a vague answer as an answer. If growth is the issue, how to get promoted from junior to mid level developer is worth reading before you decide.

3. Is this a pay problem the market can fix?

Internal raises are bounded by bands and by what you were hired at. That is not unfairness so much as arithmetic, and it is the single most common legitimate reason to move. Before deciding, find out what the market actually pays for your skills. Data sites like levels.fyi help for global companies; for local ones, ask peers you trust what they were offered. I cover the negotiation side in how to negotiate salary when switching developer jobs.

4. Is the team getting better, or just promising to?

If the team is broken and leadership says it is changing, judge the trend, not the promise. Ask what has measurably improved in the last six months. Organisations genuinely fixing something can point to what already changed; organisations that are not will describe a plan. If the core issue is your manager, read how to deal with a toxic manager as a developer first.

When to switch jobs as a software engineer, and how often

People ask me about the "two year rule" constantly. It is worth questioning in both directions. Leaving every twelve to eighteen months means you rarely see the consequences of your own technical decisions, which is where a lot of real learning happens. Staying eight years in one place can quietly narrow what you can prove you have done. Neither is a rule, and both patterns get noticed.

For context, the US Bureau of Labor Statistics reported in September 2026 that median tenure with a current employer was 4.1 years in January 2026, and 3.0 years for workers aged 25 to 34. Tech tends to move faster than that, but the point stands: short stints are normal early on, and a run of very short ones needs a story. My longer answer is in how often should a developer switch jobs.

Choosing the next job properly

5. Have I interviewed them back?

An offer produces excitement, which is exactly when you should ask the hard questions. Why is this role open? What happened to the last person in it? What did the team ship in the past six months, and what got cancelled? How are decisions made when two senior engineers disagree? The answers, and how comfortable they are with the questions, tell you more than any careers page.

6. Do I know what my first ninety days look like?

Ask directly. Concrete answers mean someone has thought about why the role exists. Vagueness this early rarely resolves after you join; it usually becomes your problem to solve while also being new. Once you do join, the first 90 days in a new developer job has a plan.

7. What scope sits behind the title?

A title bump at a smaller company can be real growth or just a label. Titles are not comparable across companies, and everyone involved knows it. What matters is what you will own, who you will work with and learn from, and whether the work is a size you have not handled before.

8. What kind of company do I need next?

Startups against large companies, or service companies against product companies: neither is better in general. Early stage teams teach breadth, speed and comfort with ambiguity. Large companies teach scale, rigour and how software survives many hands. Service companies expose you to many stacks and clients; product companies let you live with one system for years. Pick the one that fills the gap in what you can currently do. If you are thinking about that specific move, read how to switch from a service based to a product based company, and browse the companies library to see who builds what.

9. How remote is the remote role, really?

Ask where the last three hires sit, not what the policy says. One remote person on a team that shares an office is a structurally different job from a fully distributed team. For remote roles that pay in foreign currency, check the contract type, payment method and working hours overlap too. More in remote jobs for software engineers in Pakistan.

Not being talked into it, or out of it

10. If they counteroffer, will the real reason change?

A counteroffer brings immediate relief, which is the moment to be careful. If money was genuinely the only issue, accepting can be right. If the reason was the work, the manager or the trajectory, you have accepted money to stay in the same situation, and you may be having this conversation again with less leverage. You will see confident statistics about how many people who accept counteroffers leave within a year; I have not found a solid source for the popular figures, so decide on your own reasons rather than on a number.

11. What is the equity actually worth?

A large headline equity number deserves arithmetic, not excitement. Ask for the number of shares or options, the strike price, the vesting schedule and whether there is a cliff, what happens to unvested and vested equity if you leave, and how long you would have to exercise options after leaving. Then think honestly about the odds of the outcome that makes it valuable. Treat early stage equity as a lottery ticket with a long expiry, and value the salary as if the equity were zero. Grokking Tech Salary Negotiations covers how to discuss equity and total compensation without awkwardness.

Leaving in a way you will not regret

12. Can I resign in two warm sentences?

Keep the resignation short and kind. The exit conversation is not where anything gets fixed, and a list of everything that was wrong buys you nothing except a worse reference. Say thank you, give the date, be pleasant. That is the whole script. If there is feedback worth giving, an exit interview or a later conversation is a better place for it.

13. Have I written down what only I know?

The three things only you know how to fix, the reason that odd workaround exists, who to call when the nightly job fails. Writing this down before you go is one of the few genuinely generous acts available at the end, and it costs an afternoon. It also makes your notice period a period people remember well. The industry is smaller than it looks, and your future manager or a colleague you would like to hire is somewhere in that building.

14. Will I keep these relationships after I leave?

Your network is the most durable professional asset you have, and it is built almost entirely from people you actually worked with. Referrals, offers and the good jobs that are never advertised come through this channel for the rest of your career. The research agrees that referrals matter: a study across nine large firms published in the Quarterly Journal of Economics found referred applicants were more likely to be hired and, once hired, substantially less likely to quit. Keep in touch with the people you respected.

One more question people ask too late

What would have to be true for you to stay? Answering it honestly either produces a request worth making to your manager, or makes it clear that it is genuinely time to go. Either result is better than leaving on momentum.

Questions to ask before changing jobs: a quick checklist

• Reason: written down in one sentence, and still true after a good week.
• Internal options: asked for, with a clear answer.
• Market: pay and demand checked for your actual skills.
• Offer: in writing, including scope, first ninety days and equity terms.
• Team: you have spoken to at least one future peer, not only managers.
• Remote: you know where the team actually sits.
• Counteroffer: you have decided in advance what would, and would not, change your mind.
• Exit: handover notes planned, resignation kept short and warm.

If you do decide to move, the mechanics of the search are in how to apply for software engineering jobs and a job search is a pipeline, not a performance. Interviewing while employed means answering "why are you leaving?" well, and behavioural rounds are where that comes up; Grokking Modern Behavioral Interview is a structured way to prepare those stories.

The short version

Decide in a flat mood, not a bad week. Ask internally before you look externally. Accept that the market sets pay. Judge trends over promises. Interview them back, hard, about the last person and the last six months. Look at scope, not titles. Know how remote the remote job is. Value equity as a lottery ticket. Be wary of counteroffers when money was not the real problem. Leave short, warm and useful, and keep the people.

A job change is one of the few career decisions with genuinely large effects on the next several years. It deserves considerably more thought than most people give it, and considerably less drama.

Learn it on Sefism

• Career growth roadmap and the career growth cheat sheet
• Job search roadmap
• How often should a developer switch jobs
• What changes in your first two years as an engineer
• Grokking Tech Salary Negotiations
• Companies library to research where you might go next

FAQ

How do I know if it is time to change jobs?

If the reason survives a few good weeks, you have already asked for what you need internally, and the answer was no or vague, it is probably time. One bad month on its own is rarely enough.

How often should a software engineer switch jobs?

There is no fixed rule. Staying long enough to see the results of your own decisions is valuable, and staying too long can narrow your experience. A pattern of very short stints needs a clear explanation.

Should I accept a counteroffer?

Only if money was genuinely the only reason you were leaving. If the problem was the work, the manager or your growth, a counteroffer usually leaves that unchanged.

What should I ask before accepting a job offer?

Why the role is open, what happened to the last person in it, what the first ninety days look like, what the team shipped recently, where the team sits, and the full compensation terms in writing.

How do I resign from a job professionally?

Tell your manager first, in person or on a call, keep it short and thankful, confirm your last day, and follow up in writing. Spend the notice period handing over well.

Ask your own question

If your situation is different from the ones above, the career questions library has honest answers to the questions students and engineers ask me most.

Want a learning roadmap built around you, written answers to your own questions and a place to discuss your FYP? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.

Stay in touch

• LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
• X (Twitter): short practical thoughts on engineering and careers.
• Instagram: quick tips and a more personal side.
• Sefism Discord: meet other students and engineers working through the same job market and share what is working.
• Sefism on YouTube: walkthroughs and talks.