# How do you talk to someone who treats junior engineers poorly?

**Someone who treats junior engineers poorly** must hear that review tone, public correction, and response to questions are part of engineering performance. Quote specific interactions, explain how they blocked learning or safety, and set a standard for the next review. Protect junior engineers now rather than asking them to become more resilient while a senior person continues the behavior.

        
## Which interactions should you bring?

        
Use direct examples: a review comment that said “did you even test this,” a design meeting where the senior engineer laughed before answering, and two questions left unanswered while similar questions from senior peers received help. Include dates, context, and work impact. Avoid asking junior engineers to produce a large case before you act on behavior you observed.

        
Distinguish a firm technical standard from contempt. Rejecting unsafe code can be necessary. Explaining the failure, required change, and evidence preserves the standard. Mockery, public shaming, and status based dismissal add no engineering value. The conversation should not lower quality expectations; it should require a professional way to enforce them.

        
## How do you open clearly?

        
Say: “I need to discuss how you responded to junior engineers in review and planning. On Sam's change, you wrote ‘did you even test this’ and gave no failing case. In planning, you laughed at Lina's question before explaining the dependency. Both stopped asking you questions. That behavior is not acceptable, and it is affecting review quality and learning.”

        
Then ask for their account. They may describe repeated mistakes, time pressure, or frustration with preparation. Those issues can require action too. They do not justify humiliation. Keep the two topics separate: juniors may need stronger coaching, and the senior engineer must still meet the interaction standard.

        
## What learning cost should you explain?

        
When questions receive contempt, uncertainty goes underground. Junior engineers guess, copy patterns they do not understand, or wait for a safer reviewer. Defects appear later because the earliest chance to correct a model was made socially expensive. Senior engineers then interpret silence as proof that nobody is learning.

        
Public shaming also changes the whole room. Other people become cautious about exposing incomplete thinking. Reviews optimize for avoiding embarrassment rather than finding risk. The cost is not merely hurt feelings. It is weaker technical information, slower growth, and dependence on the person who made questions unsafe.

        
## What review standard should you set?

        
Require comments to name the technical concern, evidence or scenario, and requested change. Critique the code, design, or test rather than the person's competence. For example: “This retry can write the charge twice when the first response times out. Add an idempotency key and a test for that sequence.” The standard is direct and useful.

        
For live questions, require an answer or a respectful route. The engineer can say they need the junior to investigate first, ask what they tried, or schedule a short pairing session. Ignoring a question or using ridicule to end it is not an acceptable efficiency method. Agree which route fits the team's current load.

        
## Which examples distinguish rigor from harm?

        
| Situation | Useful response | Harmful response |
| --- | --- | --- |
| Missing test | Name the failing case | Question competence |
| Basic question | Ask what was tried | Laugh or ignore |
| Unsafe design | Stop and explain risk | Shame in public |
| Repeated gap | Coach with manager | Keep attacking reviews |

        
Use the table as a working agreement, not a script for every comment. The key is that technical directness remains while status attacks disappear. Ask the engineer to rewrite one prior comment into a useful form. This reveals whether the standard is understood before the next real review.

        
## What should the immediate protection plan include?

        
- Stop any current public attack.
- Check privately with the affected engineer.
- Move urgent review to a safe reviewer.
- Hold the senior engineer's 1 on 1 promptly.
- Set the comment and question standard.
- Observe the next two interactions.
- Follow up on a named date.

        
Do not make the junior engineer mediate or attend the corrective conversation unless a suitable repair later calls for it and they freely agree. The manager owns the standard. Ask what support the affected person needs, correct factual work issues separately, and avoid promising details about another employee's consequences.

        
## What if the senior engineer says juniors are too sensitive?

        
Return to work impact and the actual words. “The question stopped, the risky assumption remained, and review moved to another person” is stronger than debating sensitivity. Ask how the comment helped identify the failure. If it did not, require a more effective response. Professional conduct is not optional based on the recipient's tolerance.

        
If they claim the culture has always been blunt, distinguish blunt from contempt. “This change can duplicate charges and cannot merge” is blunt. “Anyone competent would know this” attacks status. A mature engineering culture can hold a hard quality line without using humiliation as proof of seriousness.

        
## How should repair happen?

        
A repair should acknowledge the specific interaction and its effect without demanding forgiveness. The senior engineer might tell the junior that the review comment attacked competence instead of explaining risk, then provide the missing technical explanation. Discuss the repair first so it does not become another exercise in defending intent.

        
Do not use a private apology as the only response to public harm. If the interaction occurred in a review thread, the technical correction and respectful replacement should also be visible there. Protect personal details while restoring the record that future readers will learn from.

        
## What do you check at follow up?

        
Review the next two comments and one live interaction. Look for clear technical concerns, useful requests, and space for questions. Ask affected engineers whether they could understand and act, not whether the senior person seemed nicer. Evidence should show a changed working experience.

        
Recognize improvement precisely, especially if the engineer preserved rigor while changing tone. If public shaming or selective ignoring continues, state that the behavior remains unacceptable and use the appropriate formal process. Junior engineers should not endure repeated experiments while the manager waits for a personality change.

        
## How can you observe change without putting juniors on trial?

        
Use review artifacts and your own presence first. Read the next comments, attend a planning discussion, and notice whether the senior engineer explains risk in a form the recipient can use. Junior engineers should not have to submit repeated emotional reports in order for a manager to enforce a visible standard. Give them a simple private route if another incident occurs, but do not make monitoring their job.

        
When asking about impact, use work questions. Did the reviewer explain the failing scenario? Could the author tell what to change? Was it safe to ask a follow up question? These questions produce evidence and reduce pressure to label the senior person. A junior engineer may still feel uncomfortable answering because of power. Do not interpret silence as proof that the issue vanished.

        
Look at response time and depth as well as wording. A senior engineer can avoid insulting language while continuing to ignore junior work for days, then approve senior peers immediately. Compare similar requests and ask about priority. Selective access can preserve the same status harm under a more polite surface.

        
Create normal structures that reduce dependence on one senior reviewer. Rotate review duty, document domain owners, and hold focused office time for questions. These changes protect learning and reveal whether the engineer can meet the standard in a clear role. They do not replace the individual expectation or excuse retaliation outside the structure.

        
If the engineer makes a sincere repair, do not require the junior person to certify their transformation. Assess behavior over time. The affected person may remain cautious for good reason. Trust often returns more slowly than comment quality changes, and the manager should not pressure anyone to provide emotional closure on a schedule.

        
At the dated check, share the evidence you observed. Name a review where the engineer clearly explained a concurrency risk, or a meeting where they again used ridicule. Keep recognition and correction specific. If behavior improves only when you are present, say that the standard applies in every channel and arrange the next fair observation without covert surveillance.

        
## What should you do if the behavior happens during the meeting?

        
Interrupt the behavior without conducting the entire performance conversation in public. You can say, “Stop. We can challenge the design, but we will not question the author's competence. Please state the technical risk and the change you need.” If the senior engineer cannot reset, move the review to another owner and continue later. This protects the junior engineer and shows the team that the standard is real. Afterward, check privately with the affected person, correct any work confusion, and tell them what immediate process changes will happen. Do not ask them to reassure you that the interruption was enough. Then meet the senior engineer promptly. Quote the words, explain why you intervened, and connect the event to any prior expectation. Listen for context, but do not debate whether public humiliation was deserved. Ask how they could express the same technical concern under the review standard. Set a near check on another interaction. Your public response should be brief and behavioral; your private management should be complete. Managers who wait for the next scheduled 1 on 1 while harm continues in the room teach everyone that dignity is optional when the most skilled person is frustrated.

## What are common questions?

### Does direct feedback require a gentle tone?

No. It requires a clear technical concern and requested change without ridicule, status attacks, or public humiliation.

### Should the junior engineer join the conversation?

Usually no. The manager should enforce the standard and avoid making the affected person carry the correction.

### What if junior work has real quality gaps?

Coach those gaps separately with evidence while still requiring the senior engineer to review professionally.

### Should there be an apology?

A specific repair can help, but it should not replace changed behavior or pressure the recipient to forgive.

### How quickly should you follow up?

Observe the next two relevant reviews or interactions and meet on the date agreed in the first conversation.

Related: [having a difficult conversation with an engineer](https://isilta.com/blog/how-to-have-a-difficult-conversation-with-an-engineer/), [talk to a strong engineer who hurts the team](https://isilta.com/blog/how-to-talk-to-a-high-performer-who-hurts-the-team/), [talk to someone who will not share knowledge](https://isilta.com/blog/how-to-talk-to-someone-who-will-not-share-knowledge/).