How to Work Effectively with a Senior Engineer

TL;DR

Senior engineers want you to show initiative, communicate proactively, and not create surprises. Those three things cover most of what earns their trust.
Don't demand their time. Get good at asking well, batching questions, and not requiring hand-holding on things you can figure out yourself.
You can disagree with a senior engineer. The key is how you raise it: with evidence, without ego, and by separating technical disagreement from personal territory.
Consistent behavior over months matters more than any single interaction. Reputation builds slowly.
Asking for feedback is not a weakness. Senior engineers respect people who want to get better.

The relationship you build with senior engineers in your first year will shape your trajectory more than almost anything else. Not because they control your fate, but because they control the quality of your feedback, the complexity of the work you get assigned, and how your name comes up when growth opportunities are discussed.

Most junior engineers handle this relationship either too passively (hoping senior engineers will notice their work) or too eagerly (treating every senior engineer as a mentor who owes them time). Neither approach works well.

This article covers what senior engineers actually want from junior teammates, how to earn their trust and attention, how to handle disagreement, and how to get more out of these relationships without being a burden.

What Senior Engineers Actually Want From Juniors

Senior engineers are usually busy with problems that require a lot of context. They're not primarily thinking about mentoring junior engineers. They're thinking about architecture decisions, production incidents, technical debt, and their own deadlines.

What makes a junior engineer valuable to a senior is not brilliance. It's reliability. Specifically:

Initiative. Doing the obvious thing without being asked. If you find a bug while working on something adjacent, fix it or flag it. If a ticket is vague, ask a clarifying question before starting rather than building the wrong thing. If a test is failing in CI and it's in your area, investigate it. Senior engineers value people who move work forward without constant prompting.

Communication. Keeping people informed. If you're stuck and blocking something, say so early. If you're going to miss a deadline, surface it before it becomes a surprise. If you find out something relevant to a decision someone else is making, share it. Over-communication is almost never a real problem in engineering. Under-communication causes incidents, missed deadlines, and duplicated work.

Not creating unpleasant surprises. This is a variation of the above, but it deserves its own emphasis. Senior engineers who work closely with juniors cite "finding out something went wrong after it already affected something else" as one of the most frustrating experiences. If you broke something, say so. If you made a change you weren't sure about, flag it in your PR. If you deployed something that's behaving unexpectedly, surface it immediately.

These are the behaviors that build trust. They don't require technical brilliance. They require consistency.

How to Get Feedback Without Being Demanding

One of the most valuable things a senior engineer can give you is direct feedback about your work. Most of them won't give it unless you ask.

This isn't because they don't care. It's because giving good feedback takes time and attention, and most people don't make explicit time for it unless it's required. If you want feedback, you have to ask for it, and you have to make it easy to give.

A few approaches that work:

Ask about specific things, not general impressions. "Do you have any thoughts on how I approached the caching layer in that PR?" is a better question than "What do you think of my work?" Specific questions get specific answers. General questions get polite non-answers.

Ask after code review. Code review is already a context where the senior engineer is looking at your work. After a review cycle closes, it's reasonable to ask: "Is there anything you noticed about this PR that you didn't comment on but would be worth me thinking about?" This signals that you want real feedback, not just approved PRs.

Ask in your 1:1. If you have a regular 1:1 with a senior engineer or tech lead, use part of that time to ask about your progress. "What's one thing I could do differently that would make me more effective?" is a low-pressure question that often yields genuinely useful information.

Receive feedback well. This is the part that determines whether you keep getting feedback. If you ask for feedback and then get defensive or make excuses, the senior engineer will stop giving you honest answers. Acknowledge what they said, ask a follow-up question if it's unclear, and then go do something about it. More on receiving feedback in how to handle code review feedback.

How to Handle Disagreement with a More Experienced Engineer

You will occasionally disagree with a senior engineer's technical decision. Sometimes you'll be wrong. Sometimes you'll be right. What matters more than who's right is how you engage.

The instinct many junior engineers have is to either defer without voicing the concern (avoiding conflict) or to push back too hard in a way that feels like they're trying to prove something (overcompensating for insecurity). Both create problems.

The approach that works is direct but evidence-based.

If you have a concern about a technical decision, raise it specifically. "I was thinking about the approach we landed on for the cache invalidation. I'm a little worried about edge case X. Have you already thought through that, or would it be worth exploring?" That's a reasonable question that doesn't challenge the decision directly, but opens a door to discussing the tradeoff.

If the senior engineer explains their reasoning and you still have a concern, you can say so once more. "That makes sense for the common case. I'm still a bit worried about X. Is it worth adding a test for that scenario, even if we think it's unlikely?" You've raised it, you've explained why, and you've offered a concrete suggestion.

Then let it go. If the senior engineer makes a call and you've raised your concern, the decision is theirs to make. You can note your disagreement in the PR comments or in writing so there's a record. But continuing to relitigate a decision someone more experienced has made isn't productive and will damage your reputation over time.

There is one exception: if you believe a decision creates a serious risk (security, data loss, significant production instability), escalate appropriately. That's not the same as having a design preference. Use judgment.

The other side of this: senior engineers are sometimes wrong. They're not oracles. If you try something they were skeptical of and it works, or you find evidence that contradicts their assumption, bring it to them without an "I told you so." Just share the information. Senior engineers who are worth learning from will update based on evidence.

What Senior Engineers Find Frustrating

It's worth being explicit about this, because some of the things that frustrate senior engineers aren't obvious.

Asking questions before trying. If you ask a question that 10 minutes of searching the codebase would have answered, that registers. Do the basic work before asking. More on how to ask questions at work.

Vague status updates. "I'm still working on it" tells a senior engineer nothing about whether there's a risk or when to expect something. "I finished the data model, the API endpoints are done, I'm stuck on the frontend integration and might need help there" is useful.

Repeating the same mistakes. Everyone makes mistakes, especially early in their career. Making a mistake once is learning. Making the same mistake three times suggests you're not retaining what you're learning. If something went wrong, understand why before moving on.

Not flagging when you're stuck. Spending two days stuck on something without telling anyone and then surfacing it as a deadline risk is a pattern that erodes trust quickly. Senior engineers would rather spend 20 minutes helping you get unstuck than find out the problem was there all along.

Being defensive during code review. Code review is one of the primary mechanisms by which senior engineers share their knowledge. If the junior engineer on the receiving end gets defensive or dismissive, it stops being a useful teaching opportunity for both sides.

What Senior Engineers Find Encouraging

The flip side is worth naming too, because these behaviors are often underestimated by junior engineers.

Showing up prepared. Coming to a meeting or a conversation having thought about the topic. Coming to code review having already re-read your own diff and caught the obvious things. Coming to a discussion having written down what you know and what you don't.

Taking ownership of small things. Noticing that the team wiki has outdated setup instructions and fixing them. Keeping your own tickets updated. Closing loops. These behaviors signal that you're thinking about the team's work, not just your own tickets.

Asking good questions. A well-formed technical question is pleasant to answer. It signals that you've thought about the problem. Senior engineers often notice the quality of someone's questions as an indicator of how they're developing.

Improving over time. The most encouraging thing to a senior engineer mentoring a junior is watching the junior apply feedback over multiple PRs. If you got feedback about how you handle error cases in one PR, and your next PR handles error cases more carefully, that's noticed.

Being honest about what you don't know. Senior engineers have limited patience for junior engineers who pretend to understand things they don't and then produce work that shows they were confused. Saying "I'm not sure I fully understand the tradeoff here, can you explain it?" is respected.

How to Signal You're Ready for More Responsibility

At some point in your first year, you'll want more interesting work, more ownership, or more autonomy. The way to get these things is not to ask for them directly. It's to demonstrate that you're ready.

Concretely, this means:

Shipping what you say you'll ship, on the timeline you commit to. Reliability is the entry fee for more responsibility.

Handling the work you have at a high standard, including the boring parts. Engineers who do the tedious work well (clear commit messages, good test coverage, tidy PR descriptions) get trusted with more important work. Engineers who cut corners on the basics don't.

Proposing things, not just doing things. If you see a problem that no one is solving, write a short proposal. "I noticed our test suite doesn't cover the payment flows well. I'd like to spend two days adding coverage there. Here's what I'd prioritize." This shows you're thinking beyond your assigned tickets.

Having conversations about growth directly when the time is right. After three to four months, it's reasonable to ask your manager or tech lead: "What would I need to demonstrate to take on a more complex feature end to end?" This is a direct question about what the bar looks like. It's reasonable to ask, and it signals that you're thinking about your trajectory.

The path from junior to taking on bigger work is mostly a track record of small things done consistently well. There's usually no single moment. It accumulates.

Making the Relationship Sustainable

The best working relationships between junior and senior engineers are ones where both people feel the exchange is worth it. Senior engineers give time and attention. Junior engineers should give back by using that time well.

This means: preparing for conversations before having them, not needing the same thing explained twice, being a person whose work the senior engineer can trust to be solid, and making it easy to work with you.

You can't force a mentoring relationship. Some senior engineers are naturally inclined to invest in junior teammates; others aren't. But you can position yourself to get value from any working relationship by being easy to communicate with, reliable, and genuinely curious about the work.

When you're navigating your first 90 days on a new team, the senior engineers you interact with are forming their first impressions. The behaviors described here are most valuable when you establish them early, because reputation is much easier to build than to rebuild.

As you develop the ability to handle feedback well, that skill will shape not just your relationship with senior engineers but your code review experience overall. For a detailed look at that, see how to handle code review feedback.

If you want structured support building the professional skills that make these relationships go well from the start, here's how the Globally Scoped program works.