Career & Technology

Stop Optimizing Your Career for Salary

A practical guide to building a long-term technology career by prioritizing learning, difficult problems, experience, skills, and ownership over short-term salary.

Ansh Srivastava••
Stop Optimizing Your Career for Salary

Stop Optimizing Your Career for Salary

There is a career question that almost everyone eventually asks:

"How much will this job pay?"

It is a reasonable question. Money matters. Financial stability matters. Your compensation should reflect the value you create.

But if you are building a career in technology, there is another question that can be far more important in the long run:

"What will I be able to do after spending three years here that I cannot do today?"

That question changes everything.

A ₹20 lakh job can be a great opportunity. A ₹12 lakh job can be a great opportunity. A startup can be a great opportunity. A large technology company can be a great opportunity. An HFT can be a great opportunity.

The number on the offer letter tells you what you are being paid now.

The skills, judgment, relationships, and experience you gain tell you what you can potentially become later.

If your ambition is to build a long and unusually capable career — perhaps moving from startups to large engineering organizations, specialized technical companies, HFTs, or eventually your own companies — then your career should be treated as a compounding asset.

And the most important asset to compound is capability.

The career mistake nobody talks about enough

Early in your career, it is easy to become obsessed with optimization.

You compare:

You calculate the difference in monthly take-home pay.

You read salary reports.

You watch videos about "highest paying tech jobs."

Then you choose the offer with the biggest number.

Sometimes that is exactly the right decision.

But there is a hidden variable that is much harder to measure:

the rate at which you are becoming more capable.

Imagine two engineers starting their careers at roughly the same level.

Engineer A spends three years doing repetitive work in a comfortable environment. Their salary increases every year, but they rarely work on difficult architecture, performance problems, production incidents, or unfamiliar systems.

Engineer B spends three years working with exceptional engineers on difficult problems. They learn distributed systems, databases, observability, infrastructure, performance optimization, testing, architecture, and how real products behave under pressure.

After three years, Engineer A may have earned more money.

But Engineer B may have accumulated a much more valuable professional asset:

the ability to solve problems that are worth a lot of money.

That difference compounds.

Your first job is not your final destination

One of the most damaging ideas in career planning is the belief that your first job determines your entire career.

It doesn't.

Your first job is an environment in which you can acquire experience.

Your second job can be an upgrade.

Your third can be an even bigger upgrade.

You can move between:

Startup → Product Company → Big Tech → HFT → Founder

Or:

Startup → Big Tech → Startup → Founder

Or:

India → Japan → Europe → India

Or something completely different.

There is no universal sequence.

The point is not to follow a predetermined ladder.

The point is to deliberately collect capabilities.

Think of every stage as adding another layer:

University
   ↓
Fundamentals
   ↓
First internship
   ↓
Production engineering
   ↓
Hard technical problems
   ↓
Leadership
   ↓
Business understanding
   ↓
Company building
   ↓
Ownership

The higher you go, the more your opportunities depend on the combination of things you have learned.

Optimize for the learning curve

A useful way to evaluate an opportunity is to ask:

"How steep will my learning curve be here?"

A strong learning environment usually has several characteristics.

1. You work with people better than you

This is one of the fastest ways to improve.

If everyone around you is at approximately your level, you may become comfortable.

If you work with engineers who are significantly better than you, your weaknesses become obvious.

You start noticing:

You don't just learn their code.

You learn how experienced engineers think.

That is difficult to acquire from tutorials.

2. The problems are genuinely difficult

Difficulty is not automatically good.

A badly managed company can give you enormous amounts of stress without giving you useful experience.

The kind of difficulty you want is productive difficulty.

For example:

Problems like these force you to build mental models.

And mental models compound.

The difference between consuming knowledge and earning experience

You can read about distributed systems for six months.

You can watch 100 system-design videos.

You can memorize definitions of:

But then production gives you a problem that does not look like the textbook.

Suddenly you have to decide:

"Where exactly should the cache live?"

"What happens when the cache is stale?"

"What happens when the database fails?"

"How do we know the queue is backing up?"

"What happens if the same request arrives twice?"

That is where knowledge turns into engineering judgment.

Experience is what happens when knowledge meets consequences.

You make a decision.

Something breaks.

You investigate.

You understand why.

You fix it.

You remember the lesson.

The next time you see the same class of problem, you are faster.

That is professional growth.

Why hard problems are worth chasing

If you deliberately choose increasingly difficult problems, something interesting happens.

At first:

"I have no idea how to solve this."

Then:

"I know roughly what area I need to investigate."

Later:

"I've seen this class of problem before."

Eventually:

"I can predict what will break before it breaks."

That progression is one of the most valuable things you can build in a technical career.

The objective is not to make your work unnecessarily difficult.

The objective is to gradually increase the complexity of problems you are capable of solving.

A useful personal metric is:

What is the hardest problem I can reliably solve today?

Then work toward making tomorrow's answer harder.

Build things, don't just prepare for interviews

Interview preparation is important.

DSA is important.

Computer science fundamentals are important.

System design is important.

But there is another form of learning that is extremely powerful:

building.

When you build a real product, nobody gives you a neatly defined interview question.

You have to figure out what the problem actually is.

You discover that:

This is why building something like Elvoret can be valuable even before it becomes a large business.

The product itself becomes a learning environment.

You can use it to learn:

frontend → backend → databases → APIs → authentication → infrastructure → code execution → security → monitoring → scaling → product decisions → business

Every new problem becomes another opportunity to increase your capabilities.

The ideal outcome is not merely:

"I built a website."

It is:

"I built something real, encountered real engineering problems, and became a better engineer because I had to solve them."

Your projects should get harder over time

A common student portfolio looks like this:

There is nothing wrong with these projects.

They are useful for learning.

But eventually you should graduate from feature building to problem solving.

Instead of asking:

"What project should I build?"

Ask:

"What difficult problem do I want to understand?"

For example:

Beginner

Build a REST API.

Intermediate

Build an authenticated production-style API with proper validation, testing, logging, and deployment.

Advanced

Build a system that can process asynchronous jobs reliably.

More advanced

Design it to handle failures, retries, idempotency, queues, rate limits, monitoring, and increasing load.

Now you aren't just collecting projects.

You're building engineering judgment.

The value of working at a startup

Startups can be incredibly valuable early in a career because they often expose you to a wide surface area.

You might be responsible for:

You may see how an idea becomes a product.

You may talk directly to users.

You may discover that a technically elegant solution is useless if nobody wants the product.

That teaches something university rarely can:

technology exists to solve problems for people.

However, not every startup is a good learning environment.

A startup that gives you constant chaos, no mentorship, poor engineering practices, and repetitive work is not automatically valuable because it is called a startup.

Evaluate the quality of the problems and people, not the label.

Why a great engineering company can be valuable

Eventually you may want the opposite experience.

A large technology organization can expose you to problems that a small startup simply cannot encounter at the same scale.

You might learn:

This can teach you how systems behave when millions of users, huge datasets, and many engineering teams are involved.

The lesson from a startup might be:

How do we build something from almost nothing?

The lesson from a large company might be:

How do we operate something enormous without everything falling apart?

Both are valuable.

And then there are extreme technical environments

Some people eventually want to work on problems where the technical bar is unusually high.

That could mean:

These environments can teach you things that are difficult to learn elsewhere.

For example, HFT can force you to think deeply about:

You don't need to work in HFT.

But if you are fascinated by difficult technical problems, it can be an interesting part of the map.

The same principle applies:

Choose environments that make you better.

Don't underestimate learning from failure

Some of the most valuable career experiences will not look impressive while they are happening.

You might:

These experiences hurt.

But they also expose gaps.

And gaps are useful because now you know what to improve.

A failure followed by reflection is often worth more than a success you cannot explain.

After something goes wrong, ask:

  1. What happened?
  2. Why did it happen?
  3. What assumption was wrong?
  4. What did I fail to notice?
  5. What would I do differently next time?
  6. What should I learn so this class of failure becomes less likely?

That turns failure into an asset.

The one-step-ahead rule

You don't need to become the best engineer in the world next year.

You don't even need to know exactly where your career will be in ten years.

A much more sustainable goal is:

Be one meaningful step ahead of where you are today.

If you know basic backend today, learn production backend next.

If you can build APIs today, learn how to make them reliable.

If you can solve easy DSA problems today, learn to solve harder ones.

If you understand databases today, learn indexing and query optimization.

If you can build a monolith today, learn why and when systems are split into services.

If you can deploy an application today, learn observability and failure recovery.

If you can build a product today, learn how to get people to use it.

Every step expands your capability.

And after enough steps, the distance becomes enormous.

Don't compare your chapter 2 to someone's chapter 20

Technology careers are especially bad for comparison.

You see someone who:

It is easy to feel behind.

But you usually don't see the years of work that produced that result.

The useful comparison is:

Who were you 12 months ago?

Could you solve problems then that you can solve now?

Could you build what you can build now?

Do you understand systems that used to look impossible?

Can you communicate better?

Can you debug faster?

Can you make better technical decisions?

If yes, you are progressing.

Salary still matters — just don't let it become your compass

This philosophy does not mean:

"Money doesn't matter."

It does.

You need enough compensation for a sustainable life.

You should negotiate.

You should avoid companies that exploit you.

You should understand your market value.

And sometimes the higher-paying opportunity is also the better learning opportunity.

The point is simply that salary is one variable, not the entire objective function.

A useful career decision might look like:

Learning × Problem Difficulty × People × Ownership × Optionality × Compensation

The exact formula doesn't matter.

The idea does.

A job that pays slightly more but teaches you almost nothing may have a lower long-term value than a job that dramatically increases your capabilities.

Think in decades, not months

If you are 20 or 21, it is tempting to think:

"I need to maximize my salary immediately."

But a technical career can last decades.

Imagine spending your twenties becoming unusually good at:

Then imagine combining those skills with:

The compounding can become enormous.

Your first salary is a tiny part of that story.

Your capability stack is much more important.

The founder advantage

Eventually, if you want to build companies, your previous engineering experience becomes more valuable.

A founder who has never built software may struggle to understand technical trade-offs.

A founder who has spent years building production systems can ask better questions.

They understand:

But technical knowledge alone isn't enough.

You also need to learn:

sales, marketing, finance, hiring, operations, strategy, and customer development.

That is why entrepreneurship can be such a powerful later stage of a career.

It forces you to connect disciplines that are usually learned separately.

Your career can be a collection of experiences

You don't necessarily need one company to give you everything.

One place might teach you:

speed.

Another:

scale.

Another:

technical depth.

Another:

leadership.

Another:

business.

Another:

international experience.

Another:

ownership.

You can deliberately collect these experiences.

That is a much more interesting career strategy than trying to find one perfect employer.

A practical framework for choosing your next opportunity

Before accepting an opportunity, score it on these questions:

Technical growth

Will I become substantially better technically?

People

Will I work with people I can learn from?

Problem difficulty

Are the problems difficult enough to stretch me?

Ownership

Will I actually own meaningful work?

Exposure

Will I understand how the system/product/business works beyond my tiny task?

Optionality

Will this experience open better opportunities later?

Compensation

Is the compensation fair and sustainable?

Interest

Do I actually find the work interesting?

That last one matters more than people think.

You are going to spend thousands of hours working.

If you genuinely enjoy difficult problems, that is a competitive advantage.

What this means for a student

If you're still in university, you have a tremendous advantage:

time.

You can experiment before your career becomes heavily constrained.

Use that time.

Learn DSA.

Build systems.

Build products.

Contribute to open source.

Try internships.

Work at startups.

Read engineering blogs.

Study operating systems.

Learn databases.

Build with AI.

Learn another language if it opens a market you care about.

Try things that scare you.

And most importantly:

finish things.

A finished difficult project teaches more than ten abandoned ideas.

Don't build a résumé. Build evidence.

This is one of the biggest changes in how I would approach a modern software engineering career.

Instead of asking:

"How can I make my résumé look impressive?"

Ask:

"What evidence can I create that I can do difficult things?"

Evidence can be:

Then your résumé becomes a compressed representation of reality.

You don't need to convince people that you're capable.

You can show them.

The ultimate career advantage is optionality

The most valuable person isn't necessarily the person with the highest salary at 22.

It may be the person who has accumulated so many capabilities that they can choose what to do next.

Imagine having the ability to:

That is career optionality.

And optionality comes from capability.

So what should you optimize for?

Not salary.

Not titles.

Not prestige.

Not résumé keywords.

Optimize for compounding.

Choose experiences that make you:

smarter → more technical → more independent → more capable → more valuable → more trusted → more capable of creating things yourself.

Then use that capability to take on harder problems.

Then use the harder problems to become even better.

Repeat that for years.

Eventually, the question changes.

You stop asking:

"How do I get a good job?"

And start asking:

"What is the hardest and most interesting problem I can work on next?"

That is a very different career.

And for someone who wants to eventually build companies, work on elite technical systems, explore different industries and countries, and keep learning throughout their life, that may be the better game to play.

A simple rule to remember

At the end of every year, ask yourself three questions:

What can I build now that I couldn't build a year ago?

What problems can I solve now that used to intimidate me?

What kind of person and engineer have I become?

If the answers are meaningfully different from last year, you're winning.

Not because your salary went up.

Not because your title changed.

But because your capabilities compounded.

And once capability compounds for long enough, opportunities, money, ownership, and influence tend to become consequences rather than the thing you were chasing in the first place.

Don't optimize your career for the biggest number you can earn today. Optimize it for becoming the person capable of creating something much bigger tomorrow.

Latest Articles

Fresh tutorials, guides, and developer resources to help you become a better software engineer.