360 Feedback Questions for Software Engineers

Most 360 feedback templates were written for a generic “employee.” They ask whether someone “demonstrates strong communication skills” and “aligns with company values.” Hand that to a backend engineer and ask them to review a teammate, and you’ll get back three sentences of nothing.

Engineering feedback needs engineering questions. A senior engineer’s real impact shows up in code review turnaround, in how they behave at 2am during an incident, in whether the junior on their team is getting better — not in an abstract score for “teamwork.”

Below is a question bank built for engineering teams. Take what’s useful, ignore the rest. If you only read one section, read what makes a question actually work — a good question does more for the quality of your feedback than any tool will.

How to use this

Three rules before you copy anything:

Ask 4–6 questions. Not fifteen. Every extra question lowers the quality of the answers to the ones that mattered. Reviewers have a fixed budget of effort, and a long form spends it on fatigue. Six thoughtful answers beat fifteen shrugs.

Match the question to the reviewer. A peer on the same team, a cross-team stakeholder, and a direct report have seen completely different slices of the same person. Asking all three the same generic question wastes the thing that makes 360 feedback valuable — the different angles. Use the by-relationship section.

Ask for behaviour, not verdicts. “Is Dana a strong engineer?” invites a rating. “When Dana disagreed with a technical decision recently, what did they do?” invites a story. Stories are what the person can actually act on.

Questions by dimension

Technical craft and delivery

What’s one thing this person did in the last few months that raised the technical quality of what we ship?
Think of a recent piece of work they delivered. What made it good — or what would have made it better?
How do they handle complexity? Do they simplify problems, or do their solutions tend to add moving parts?
When they estimate work, how close does reality land? What happens when they’re going to miss?
What kind of technical work do you trust them with without checking? What kind would you want a second pair of eyes on?
Do their pull requests tend to land cleanly, or do they generate a lot of back-and-forth? Why do you think that is?

Code review and collaboration

What’s it like to have your code reviewed by them? Be specific.
What’s it like to review their code?
When they leave feedback you disagree with, how does that conversation go?
Do they unblock people, or do things sit in their queue? Give an example either way.
Is there anything about how they work with the team you’d want them to keep doing? Anything you’d want them to stop?

Communication

Can they explain a technical decision to someone who isn’t close to it? Where have you seen that work well or badly?
When something goes wrong or slips, how and when do you hear about it?
In design discussions, do they make the conversation sharper or noisier?
How do they handle disagreement — with peers, and with people more senior than them?
What’s one thing they could change about how they communicate that would make your job easier?

Incident response and reliability

What are they like under incident load? Calm, sharp, panicked, absent?
Do they leave systems easier or harder to operate than they found them?
Have they done anything in the last six months that made on-call less painful for someone else?
When they own a postmortem, does the team actually learn something from it?
Would you want them in the room during a serious outage? Why?

Mentoring and growing others

Has this person made someone else on the team better? What did that look like concretely?
Do more junior engineers seek them out? What happens when they do?
Do they share context and knowledge, or does it stay in their head?
When they explain something, do people leave understanding it — or just doing what they were told?

Ownership and initiative

Describe something they took on that nobody asked them to.
When they hit a wall, what do they do?
Do they follow work through to the end, including the unglamorous parts — migrations, cleanup, docs, rollout?
Is there anything they’ve been avoiding that you think they should own?

Cross-team influence

How do they show up in conversations with other teams?
Have they changed the direction of something outside their immediate scope? How?
Do other teams find them easy to work with? What would those teams say if I asked them?
Do they represent our team well — or create friction we then have to clean up?

Questions by level

The same question means different things at different levels. Calibrate.

Junior engineer (0–2 years)

Focus on trajectory, absorption, and whether they’re building good habits. Not impact.

What have you seen them get noticeably better at in the last few months?
Do they ask for help at the right time — or too early, or far too late?
How do they respond to code review feedback?
What’s one habit they’ve formed that will serve them well? One that won’t?
Are they picking up context about the system, or just completing tickets?

Mid-level engineer

Focus on reliability and independence. Can you hand them a problem and stop worrying about it?

How much scoping do they need before they can run with a problem?
What kind of task can you hand them and forget about? Where does that stop being true?
Do they surface risks early, or do problems tend to appear late?
Are they starting to improve things around them, or only completing what’s assigned?
What would need to be true for them to operate at the next level?

Senior engineer

Focus on multiplier effects. A senior engineer who only ships their own code is underperforming the title.

Beyond their own output, how has this person made the team better?
What technical decisions have they influenced, and were those decisions good ones?
Do they raise the standard of engineering around them, or just meet it themselves?
When they push back on a decision, is it worth listening to? Give an example.
Who on this team has grown because of them?
Where do they still operate as an individual contributor when they should be operating as a force multiplier?

Staff engineer and above

Focus on leverage, judgment, and problems nobody assigned.

What problem did this person identify that the rest of us had missed?
Where have they made a bet that turned out to be right? Where have they been wrong, and how did they handle it?
Do they pick the important problems, or the interesting ones?
How do they influence without authority — and does it work?
Are they creating clarity for other engineers, or complexity?
What are they spending time on that someone two levels down could do?

Tech lead

Two hats. Ask about both, separately.

Does the team know what they’re meant to be doing and why? Whose doing is that?
How do they handle the tension between shipping and doing it properly?
Do they still write enough code to stay credible — or too much to lead?
When priorities change, how does that reach the team?
Do they shield the team from noise, or transmit it?

Questions by who is answering

For peers on the same team

Peers see the day-to-day. Ask about texture.

What’s it actually like to work alongside them?
When did they help you recently? When did they slow you down?
What do they do that you wish more people on the team did?
If you could change one thing about how they work, what would it be?

For direct reports (upward feedback)

Upward feedback dies without anonymity — a report will not tell you their manager is bad at delegating if their name is attached. Say clearly, before they answer, who will see the response.

Do you know what’s expected of you? If not, where’s the gap?
When you bring them a problem, what happens?
Do you get feedback often enough to act on it, or does it arrive all at once at review time?
Do they remove obstacles for you, or add them?
What’s one thing they could do differently that would make your work better?
Is there anything you’ve wanted to say to them and haven’t?

For cross-team stakeholders

They see reliability, communication, and follow-through — not code quality. Don’t ask them about code quality.

When you needed something from them, how did that go?
Do commitments they make to you hold?
Is it easy to get a clear answer from them?
What do you wish they understood about how your team works?

For managers reviewing their own report

What have they achieved that they’re not getting enough credit for?
Where do you see them in a year, and what’s in the way?
What’s the one behaviour that, if it changed, would unlock the most for them?

Self-review

Cheap to include, and the gap between self-perception and everyone else’s perception is often the single most useful signal in the whole cycle.

What are you proudest of since the last cycle?
What would you do differently?
Where do you think you’re stronger than people realise? Where might you be weaker?
What do you want to be doing more of?

What makes a 360 question actually work

Four things separate a question that gets you a paragraph worth reading from one that gets you “meets expectations.”

It asks for a specific instance, not a general trait.

❌ Does this person communicate effectively? ✅ Think of a time they had to explain something technical to a non-technical audience. How did it go?

It’s answerable by the person you’re asking. Don’t ask a product manager about someone’s test coverage. Don’t ask a junior engineer to assess a staff engineer’s architectural judgment. People asked questions they can’t answer will invent an answer rather than skip it.

It makes it easy to say something critical. Most reviewers default to positive — not because everything is fine, but because criticism feels risky and vague praise is safe. Give them a licensed door:

✅ What’s one thing they could change that would make your work easier? ✅ Where do they still have room to grow? ✅ What’s something you’ve wanted to say and haven’t?

It’s open, not scored. A 1–5 scale tells you a number. It doesn’t tell you what to do on Monday. Ratings feel rigorous and mostly aren’t — they compress the useful part of the answer away and give everyone a 4.

Questions to avoid

“Rate this person’s overall performance, 1–5.” You’ll get a 4. You’ll always get a 4.
“Is there anything else you’d like to add?” as the only open question. It’s a shrug in question form.
“Would you want to work with this person again?” Nobody says no in a system with their name on it.
Anything asking about personality rather than behaviour. “Is she a team player?” is not actionable. “When the team was under pressure last quarter, what did she do?” is.
Questions that presuppose the answer. “How well does he mentor junior engineers?” assumes he does.

How anonymity changes the answers

This is the part most teams get wrong, and it silently determines whether your whole cycle is worth anything.

If a reviewer isn’t sure who will see their answer, they write for the worst-case reader. That means safe, positive, useless. The single highest-leverage thing you can do to improve feedback quality is to tell every reviewer, before they type a word, exactly who will see their response and in what form.

There are three honest settings, and you should pick one deliberately per request:

Named — the reviewee sees who said it. Good for peer praise and for feedback that needs a follow-up conversation.
Confidential — the manager sees the author; the reviewee doesn’t. A reasonable middle ground for most peer feedback.
Anonymous — nobody sees the author, including you. The only setting that works reliably for upward feedback.

The rule that matters: whatever you promise, keep. Anonymity that leaks once is anonymity that’s gone forever, on that team, permanently. If you can’t guarantee it, don’t promise it — ask a different question instead.

How many questions, and how often

Per reviewer: 4–6. Aim for a form that takes 10–15 minutes to fill in thoughtfully. Anything longer and the last answers will be worse than the first.

Per reviewee: 4–6 reviewers. Fewer than three and anonymity is theatre — everyone can guess who said what. More than six and you’re taxing the same helpful people every cycle. Watch the load: the person everyone wants feedback from is the person drowning in feedback requests.

Cadence: every six months for a full round, with lightweight check-ins for new joiners at 30 and 90 days. Annual-only means feedback arrives too late to be useful and too close to compensation to be honest.

Frequently asked questions

How many questions should a 360 review have?

Four to six per reviewer. Response quality drops sharply beyond that — reviewers have a limited budget of effort, and long forms spend it on fatigue rather than insight.

Should 360 feedback be anonymous?

Upward feedback from direct reports should be. Peer feedback works well as confidential (manager sees the author, the reviewee doesn’t). What matters most is that reviewers know the setting before they write, and that the promise is never broken.

How many reviewers should each person have?

Four to six. Below three, anonymity isn’t real — the reviewee can identify authors by process of elimination.

Should 360 feedback be tied to compensation?

Ideally not, or not directly. Once feedback determines pay, reviewers manage the outcome rather than describe reality. Use 360 feedback for development, and treat it as one input to calibration rather than the calculation itself.

How often should we run 360 reviews?

Twice a year is a good default, plus a light check-in for new joiners in their first 90 days. Annual-only cycles produce feedback that’s too stale to act on.

Run your next cycle without the spreadsheet

You now have the questions. The hard part is everything after: picking the right reviewers, promising anonymity and actually honouring it, chasing the four people who haven’t replied, and keeping a record you can find again in six months when you’re building a promotion case.

Kandorly does that part. Pick the person, pick the reviewers, send — automatic nudges go out on your behalf, confidentiality is set per request and guaranteed, and every cycle is saved and searchable. Built for engineering managers, GDPR compliant, data stays in the EU.

Your first cycle is free — three reviews, no card required.