How to Get a Raise or Promotion in Your First Engineering Job

TL;DR - Understand your company's leveling criteria before assuming you are ready for the next level. Most companies have internal documents describing what each level looks like. - Have the explicit "what do I need to do to get to the next level" conversation with your manager. Most engineers never ask directly. - Keep a running record of your impact from day one. Memory is unreliable and performance reviews reward specific evidence. - Timing and framing a raise request matters. Know the cycles, prepare your case, and separate compensation from performance conversations when possible. - If you are told "not yet," ask for a specific timeline and concrete criteria. Vague timelines are not agreements. - Visibility matters as much as output. Doing great work that no one knows about does not advance a career.

The most common mistake junior engineers make about career progression is passive waiting. They assume that if they do good work, the organization will notice and reward them appropriately. Some will. Many will not.

Not because companies are indifferent or malicious, but because performance systems are imperfect, managers are busy, and the engineers who advocate for themselves clearly and specifically tend to get better outcomes than those who do not.

This is uncomfortable for a lot of people. Advocating for yourself feels presumptuous when you are still learning. It can feel like admitting that you care about money or title in a way that seems uncomfortably direct. But the alternative, staying quiet and hoping someone else manages your career for you, consistently produces worse outcomes.

The engineers who get promoted and earn more are, generally, the ones who understand the system, do the work, document the evidence, and make the conversation happen. The first 90 days as a software engineer covers how credibility gets built from the start, which is the foundation everything else in this article assumes.

Understand Your Company's Leveling Criteria

Why this comes first

Before you can have a productive conversation about progression, you need to understand what the company considers "the next level." Without that, the conversation has no shared reference point. You might think you are ready. Your manager might have a completely different picture of what readiness looks like. Both of you might be right about different things.

Leveling criteria exist at most software companies. They describe what each engineering level looks like in terms of scope of work, technical skill, collaboration, communication, and leadership. A junior engineer (L1 or similar) and a mid-level engineer (L2) have different profiles. Understanding specifically what that difference looks like at your company is the starting point.

How to find the documentation

Ask your manager directly. "Do we have a document that describes what each engineering level looks like? I want to understand what the expectations are at the next level."

This is a completely normal question. If your company has an engineering career ladder, your manager should be able to point you to it. Many companies have this information in Notion, Confluence, Google Drive, or an internal wiki.

If your company does not have a formal career ladder (smaller companies often do not), ask your manager to describe informally what they see as the difference between your current level and the next one. Get them to be specific. "Someone at the next level typically owns a project from requirements through deployment without needing as much daily check-in" is useful. "Someone at the next level is more senior" is not.

Read it seriously

Once you have the document, read it as a gap analysis. Where are you now? Where do you need to be? For each area where the next level requires something you are not doing yet, write it down.

You are creating a personal development map. You are not looking for validation or a checklist to game. You are trying to understand what genuine growth toward the next level actually looks like, from your company's perspective.

This also prevents a frustrating situation: engineers who believe they are operating at the next level but have not actually met the criteria as the company defines them. Those conversations are harder for everyone. The gap analysis helps you know honestly where you stand.

Have the Explicit Conversation

Why most engineers never ask

The conversation that accelerates careers more than any other is also the one most engineers avoid: sitting down with your manager and asking directly, "What do I need to do to get to the next level?"

Engineers avoid it for a few reasons. They are afraid the answer will be discouraging. They do not want to seem entitled. They are not sure it is appropriate to bring up this early. They assume the manager will bring it up when the time is right.

All of these fears are understandable. None of them serve you.

Your manager is not going to volunteer a detailed roadmap to your promotion unprompted in most cases. They are managing multiple people, dealing with team priorities, and handling their own work. Explicit conversations happen when you initiate them.

How to have it

Request a one-on-one specifically for this topic, or bring it up at a regular one-on-one after you have been on the team for three to six months. Do not spring it on your manager in a hallway or Slack message.

"I want to talk about my progression and get your perspective on what the path to the next level looks like. Can we use some time in our next one-on-one for that?"

In the conversation, be specific. "I have read through the career ladder and I have a sense of where I am now. I want to understand from your perspective where the gaps are and what working toward the next level should look like for me over the next six to twelve months."

Listen carefully. Take notes. Ask follow-up questions where the answer is vague. If your manager says "you need to take more ownership," ask what ownership looks like specifically at your level. What would an example be? What would they observe that would tell them you are demonstrating that skill?

By the end of the conversation, you want a specific list of skills or behaviors to work on, and ideally some sense of timeline.

Follow up in writing

After the conversation, send a brief email or Slack message summarizing what you heard. "Thanks for the conversation today. My understanding of the key things to work on over the next few months are X, Y, and Z. Does that match your understanding?"

This serves two purposes. It confirms that you understood correctly. And it creates a record. People's memories of conversations drift over time. Having a written summary that both of you can reference means less risk of the goalposts shifting later without explanation.

Document Your Impact

Why memory is not enough

Performance reviews happen quarterly or annually depending on the company. When your manager sits down to write your review, they are relying on their memory and on whatever evidence you surface for them. If the last six months have been a blur of normal sprint work, the review will reflect that. Standout contributions from four months ago are easily forgotten.

The engineers who get the best reviews are not always the ones who did the most work. They are the ones who made it easy for their manager to remember and articulate what they did.

Keep a brag document

A brag document is a running record of your professional contributions. It is for your eyes only (and shared selectively when useful). You add to it regularly, at least weekly or after any significant contribution.

What to record: tickets you completed, particularly ones that were complex or high-impact. Problems you solved. Code reviews you gave that were genuinely helpful. Process improvements you suggested that got adopted. Documentation you wrote. Bugs you caught before they hit production. Times you unblocked a teammate.

Also record skills you developed. New parts of the codebase you learned. Technologies you picked up. Situations where you were more independent than you would have been three months ago.

The format does not matter. A Google Doc with dated bullet points works fine. The discipline of writing it down weekly is what matters.

When performance review time comes, you have a full record. You can share relevant highlights with your manager as input for your review. You can use them in a raise conversation. You can use them if you ever need to negotiate salary at this company or a future one.

Quantify where you can

"Fixed several bugs" is less useful than "Resolved the performance bug that was causing 3-second load times on the checkout page, which the team had open for two months."

"Wrote some documentation" is less useful than "Documented the authentication system in the internal wiki so the team no longer had to ask how session management works."

You do not need to fabricate numbers or claim more impact than you had. You do need to be specific. Specific contributions are memorable and credible. Vague contributions are not.

Timing and Framing a Raise Request

When to ask

Most companies have defined performance cycles where raises and promotions are decided. Find out when those cycles are. Ask your manager or HR if needed. The decision about your compensation is often made before the formal review conversation happens, which means you need to make your case before the cycle closes.

Working backward: if performance reviews happen in November, the discussions and recommendations are often happening in October. You want to have had the substantive conversation about your contribution and your expectations by September.

Asking for a raise outside of a formal cycle is harder but not impossible. If you have taken on significantly more responsibility, delivered a high-impact project, or been operating clearly above your current level for several months, you can request a conversation outside of the formal cycle. Frame it as "I want to discuss my compensation given what has changed in my role over the past few months" rather than "I want a raise."

Framing the conversation

The strongest raise conversations are rooted in evidence and framed in terms of value, not personal need.

"I have been here for twelve months and I have taken on X, Y, and Z since I started. I believe I am operating at the next level and would like to discuss my compensation accordingly."

Not: "I need more money because my rent went up."

The first framing puts the conversation in a professional context. It is about your contribution and your market value. The second framing puts the burden on your employer to solve your personal financial problem, which is not their job in a formal compensation conversation.

Come with your brag document. Come with an understanding of market rates for your level and location. Use salary databases and recruiter conversations to understand what engineers at your level typically earn. That data supports your case.

What to do if you are told "not yet"

"Not yet" is only useful if it comes with specifics. If your manager says you are not ready for a promotion yet, ask:

What specifically do I need to demonstrate? What would you need to see from me over the next six months? Can we agree on a timeline for revisiting this?

If the answer is vague, push gently for clarity. "I want to make sure we are aligned on what the path looks like so I can work toward it directly. Can you help me get specific about what the criteria are?"

A vague "keep doing what you're doing and we'll revisit" is not an agreement. It is a deferral. Agreeing on specific criteria and a timeline turns it into something you can actually work toward.

Also pay attention to whether the obstacles are within your control. If the answer is "the budget is frozen" or "there is a company-wide promotion hold," that is different from "you have gaps to close." The first is a constraints problem. The second is a development problem. They require different responses.

The Visibility Problem

Doing great work that nobody knows about

This is uncomfortable but true: in most organizations, visibility matters alongside output. An engineer who does excellent work that only they and their direct manager are aware of will progress more slowly than an engineer who does equally good work in visible ways.

This is not about self-promotion for its own sake. It is about understanding that organizations make decisions about people based on what they know about them. If the senior engineers, the staff engineers, and the engineering manager beyond your direct manager do not know what you have contributed, they cannot advocate for you.

How to build visibility without being annoying

Write clear PR descriptions and tickets. Your name is on them, and people read them.

Contribute in engineering discussions, architecture reviews, or team channels when you have something substantive to say. Not for the sake of being seen, but because engaging with the team's technical decisions is part of being a professional engineer.

Share things you learned. If you spent a week understanding a complex system and can write a two-page internal doc explaining it, do that. Share it with the team. This is genuinely useful and it also signals your growth.

If you solved a hard problem, mention it in your next standup or in a team channel. "I finally figured out that production issue. The root cause was X. I've documented it in the wiki if it's useful for anyone." That is not bragging. That is communication.

The first 90 days as a software engineer covers how to build relationships and establish credibility in a new role, which is the foundation for visibility.

When a raise is not coming and will not come

Sometimes the answer is genuinely that the company cannot or will not pay you what you are worth, regardless of your performance. Budget constraints, organizational politics, a manager who does not advocate for their team, or a company that underpays all junior engineers and does not change that behavior.

If you have done the work, had the conversations, documented your impact, and the path forward is unclear or the timeline keeps extending without explanation, that is information. The decision about what to do with that information is yours. But having done this process means you can make that decision clearly rather than wondering whether you tried everything.

Knowing when to change jobs as a junior engineer covers how to evaluate whether staying or leaving makes more sense given your circumstances.

The Summary

Getting a raise or promotion is not magic. It follows a process.

Understand the criteria. Have the explicit conversation. Document your impact from day one. Make your case at the right time with evidence. Build visibility as a natural part of doing your work. And if the answer is "not yet," ask for specifics.

None of this is comfortable at first. Most of it becomes more natural over time. The engineers who build this habit early compound their career growth in ways that the ones who wait to be discovered simply do not.

For the salary data and negotiation strategy you need to support a raise conversation, salary negotiation for your first engineering job has the full framework.

If you want structured support navigating your first engineering role and building toward a promotion, here's how the Globally Scoped program works.