How do you give constructive feedback to a teammate whose work isn't meeting expectations?
Fast recall
Quick revision
Core answer
Your interpersonal skills and whether you can maintain quality standards through direct feedback without either avoiding necessary conversations or damaging relationships with harsh criticism.
Either saying you'd never criticize anyone which suggests you'll let quality problems slide to avoid discomfort, or describing blunt confrontation without tact which shows you'll damage team morale trying to maintain standards.
Mention that you'd also ask what support they need like clearer requirements, better tooling, architecture guidance, or code examples, showing you recognize struggles might stem from missing resources rather than lack of effort or ability.
Interview-ready guide
Interview answer
I'd start by reaching out privately, maybe in a direct message or asking if we could have a quick one-on-one, because public criticism feels humiliating even when it's factually correct.
I'd focus on specific things I observed in their code rather than vague statements.
For example, instead of saying their code is messy, I'd point to a particular method and say this function has three nested loops that's causing timeouts on larger datasets. Then I'd explain the concrete impact, like this is blocking the feature from going to production or it's making code reviews take much longer because it's hard to follow the logic.
Before assuming they were careless, I'd ask context questions like were the performance requirements clear in the ticket, or did you have examples of how we handle similar cases elsewhere. A lot of times when someone's work isn't meeting expectations, it's not because they don't care but because they had unclear requirements, were working with unfamiliar tech, or didn't know where to find guidance.
I'd frame it as let's work together to get this where it needs to be rather than you did this wrong. I might offer to pair program on the refactor or point them to similar code in our codebase as an example.
If it's a pattern I'm seeing repeatedly, like they keep writing N plus one queries, I'd also share a resource or explain the underlying concept so they can apply it going forward. The goal is improving the work while maintaining the relationship and their confidence, because demoralized teammates shut down and stop learning.
How do you give constructive feedback to a teammate whose work isn't meeting expectations
Direct Answer
I'd give feedback privately rather than in public channels to avoid embarrassing them, focus on specific code issues or behaviors I observed rather than attacking their character or ability, explain the concrete impact on project quality or team velocity, and ask questions first to understand their context like whether they had unclear requirements or were blocked. I'd frame it as working together to improve the output, not criticizing them personally, and offer to help with code examples or pair programming.
Code Example
// Teammate's code in pull request:
public List<Order> findOrdersByCustomer(Long customerId) {
var allOrders = orderRepository.findAll(); // Loads entire table
return allOrders.stream()
.filter(o -> o.getCustomerId().equals(customerId))
.collect(Collectors.toList());
}
// WRONG feedback (public, personal attack):
// "This code is terrible. Did you even think about performance?"
// RIGHT feedback (private message, specific, collaborative):
// "Hey, I noticed this method loads all orders into memory then filters.
// For large datasets that'll cause performance issues and potential OOM errors.
// Were you aware we can push the filter to the database layer?
// Here's how we could refactor it:"
public List<Order> findOrdersByCustomer(Long customerId) {
// Query filters at database, returns only matching rows
return orderRepository.findByCustomerId(customerId);
}
// Follow-up in message:
// "This reduces memory usage and is much faster because the database
// indexes customer_id. Want to pair on updating the other similar methods?
// I can show you how to write the custom query if the method name
// convention doesn't cover your use case."
Common Mistakes & Pitfalls
- Public criticism: Posting critical feedback in team channels or meetings instead of private messages makes people defensive and humiliated even if your technical points are valid, destroying psychological safety.
- Personal attacks: Saying someone's code is sloppy or they don't care about quality attacks character rather than addressing specific technical issues, making them shut down rather than learn.
- No context questions: Assuming the person was careless or incompetent rather than asking if they had unclear requirements, were blocked, or lacked examples means you miss the real root cause and offer unhelpful feedback.
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.