Give and Get Useful Feedback as You Learn

Why most feedback fails

When you ask for feedback—"Does this look okay?" or "Is this good?"—you'll usually get one of three useless responses:

1. Vague praise. "That's great! I like it." (You learned nothing about what specifically worked.)
2. Vague criticism. "It could be better." (You don't know what to improve.)
3. Off-topic commentary. Someone focuses on a detail that doesn't matter instead of the thing you actually care about.

The problem is that you asked a vague question, so you got a vague answer. Most feedback fails not because people are unwilling to help, but because they don't know what you're asking for.

Good feedback—the kind that actually accelerates your learning—requires that you ask specific questions and that your feedback-giver knows what they're looking for.

How to ask for feedback that you'll actually use

Rule 1: Ask about one specific thing, not everything.

Bad: "Can you review my code?" Good: "I'm worried the performance could be better. Can you look at this loop and tell me if you see any bottlenecks?"

Bad: "What do you think of my project?" Good: "I'm unsure if my explanation is clear. Can you read my README and tell me if a technical person new to the domain would understand what problem I solved and why it matters?"

Bad: "Is this dataset good?" Good: "I'm concerned about class imbalance in my dataset. I have 10,000 positive examples and 200 negative examples. Will this hurt model performance? Can you suggest a mitigation?"

The specificity matters because it tells your feedback-giver exactly where to focus. They don't have to guess what matters to you.

Rule 2: State your success criterion before asking.

This prevents the feedback-giver from evaluating you on criteria you don't care about.

Example: "My goal for this classifier is high precision (I'd rather miss some spam than flag legitimate emails). Can you look at the confusion matrix and tell me if my precision is acceptable, and if not, what I could do to improve it?"

Now the feedback-giver knows: don't praise me for overall accuracy. Look at precision. Are false positives acceptable? That's what I'm optimizing for.

Without this, they might tell you "Your accuracy is 95%" and you'd be like "Great, but I don't care about accuracy; I care about false positives," and you've wasted everyone's time.

Rule 3: Make the thing easy to evaluate.

If you ask for feedback, do the work to make evaluation easy. Don't say "I've been working on LLM optimization, can you review?" Instead, give a concrete artifact:

• A link to a GitHub branch with a specific test case in the PR description.
• A 5-minute recorded demo of the tool with timestamps for the sections you want feedback on.
• A document with a specific section highlighted: "Focus on this methodology section. Is the approach clear?"

The easier you make evaluation, the better feedback you'll get.

Rule 4: Ask for one thing at a time, not a list.

Bad: "Can you tell me if my code is readable, performant, correct, and well-tested?" Good: "Can you tell me if my code is readable? Specifically, look at this complex function and tell me if a colleague could understand what it does in under 5 minutes without asking me questions."

When you ask for multiple things, you're putting the feedback-giver in a position to prioritize. Let them focus on one dimension. You can ask for a second round on a different dimension later.

Feedback request template

Use this template when asking for feedback:

# Feedback Request: [Project/Code/Document name]

## Context
I'm working on [brief description of project/goal].

## What I'm asking for feedback on
Specifically, I want feedback on: [ONE specific aspect]

## Why this matters to me
My goal is: [Your success criterion. What are you optimizing for?]

## What to look at
Please review: [Specific artifact: link to code, document section, demo, etc.]

## Success criterion
I'll consider the feedback useful if it helps me: [Be specific. E.g., "understand whether my explanation is clear to someone new to the domain"]

## Timeline
I have time to act on feedback this week. Please reply by [date/time].

## Thank you!

Comparison table: bad vs. good feedback requests

| Bad request | Why it fails | Good request | Why it works | |---|---|---|---| | "Does this look good?" | No target; vague praise expected | "I'm worried this explanation assumes too much domain knowledge. Can you read the 'Approach' section and tell me if a beginner would understand it?" | Target is clear; success criterion is measurable | | "Can you review my model?" | Too broad; reviewer doesn't know what to prioritize | "I'm concerned about overfitting. Can you look at the learning curves and tell me if the gap between train and test loss suggests overfitting?" | Specific dimension; easy to verify | | "What do you think?" | Invites opinion, not feedback | "My goal is latency <100ms. Can you run the enclosed code and measure the end-to-end latency? Is it acceptable?" | Measurable; actionable | | "Is this good enough for a job interview?" | Too vague; depends on interviewer | "I'm interviewing at Company X for Role Y. Can you do a mock case study interview with me and tell me: (a) Did my approach make sense? (b) Did I ask clarifying questions? (c) Was my communication clear?" | Specific scenario; clear evaluation rubric |

How to give feedback that's actually useful

Now flip it. Someone asks you for feedback. How do you give feedback that helps them learn, not just makes them feel bad or good?

Good feedback has three parts:

Part 1: What I see (observation)

Describe what you observe, without judgment.

Good: "In the code, there are three different ways you're computing the embedding distance. In one place you use dot product, in another you use Euclidean distance, and in a third you use cosine similarity."

Bad: "Your code is inconsistent." (Too vague.) Bad: "You don't know what you're doing." (Judgment, not observation.)

Your job is to be a mirror. The person might not have realized they did the same thing three different ways.

Part 2: Why it might matter (context)

Connect your observation to the person's stated goal.

They said: "My goal is to ensure the search quality is consistent."

You say: "You mentioned consistency as a goal. The fact that you're using three different distance metrics might affect consistency—the model might return different results depending on which path in the code it takes. That could be intentional, but I wanted to flag it."

Don't assume the inconsistency is bad. But connect it to their goal so they can make an informed decision.

Part 3: A question, not a command (agency)

End with a question that puts the decision back in their hands.

Good: "Given that your goal is consistency, would it make sense to use the same distance metric everywhere?"

Bad: "You should use the same distance metric everywhere."

The difference is subtle but important. A question leaves agency with the person receiving feedback. They can think through the trade-offs and decide. A command feels prescriptive and can make people defensive.

Example: giving and receiving feedback on a project

Person A presents their learning project to Person B:

A: "I built a small recommendation system for internal documents. My goal was to understand how retrieval quality affects usefulness. I'm worried that my evaluation methodology might not capture whether the recommendations are actually useful to someone. Can you read the evaluation section of my README and tell me if you think my approach makes sense?"

(Notice: A stated a clear goal, a specific worry, and asked about a specific section.)

Person B reads and gives feedback:

B (Part 1 - Observation): "In your evaluation, you collected feedback from three engineers who scored the recommendations on a 1-5 scale. You then averaged the scores."

B (Part 2 - Context): "Your goal is to understand whether the recommendations are useful. Averaging scores gives you an overall number, but I'm not sure it tells you whether it's useful or just how much people liked it on average."

B (Part 3 - Question): "What would it look like if someone said a recommendation was useful to them? Is a 4 out of 5 useful? Is a 3? Would it help to ask the engineers whether they'd actually adopt each recommendation, or would they have preferred a different result?"

(Notice: B described what they saw, connected it to A's goal, and asked a question instead of prescribing a solution.)

Person A reflects:

A might think: "Oh, I see. I averaged the scores, but I never asked whether the recommendations were actually useful, just how much the engineers liked them on a scale. That's different. Maybe next time I should ask: 'Would you adopt this recommendation?' instead of just scoring."

The feedback was useful because it was specific, connected to the goal, and framed as a question.

Building a feedback routine

Don't wait for feedback only when you're done with a project. Get feedback throughout.

Week 1: Share your problem statement and approach with a colleague. Ask: "Does this problem make sense? Are you missing anything I should consider?"

Week 2-3: Share intermediate artifacts (code, analysis, experiment results). Ask specific questions: "I'm unsure if this design choice will scale. Does this look right to you?"

Week 4: Share your final artifact and ask for feedback on the thing you're least confident about.

The earlier you get feedback, the more time you have to adjust. Also, getting early feedback prevents you from going down the wrong path for weeks and then having to backtrack.

Structuring a peer review or mentorship session

| Phase | Duration | What happens | Feedback-giver's role | |---|---|---|---| | Introduction | 2 min | Receiver explains context and what feedback they want | Listen; clarify what they're asking for | | Presentation | 5-10 min | Receiver walks through their work (code, results, thinking) | Take notes; ask clarifying questions (don't interrupt) | | Feedback | 10-15 min | Feedback-giver gives observations, context, questions (structure: see section on how to give feedback) | Be specific; tie to receiver's stated goal | | Discussion | 5 min | Receiver reflects; they may defend choices or agree to change | Give receiver space to think; don't prescribe solutions | | Action | 2 min | Receiver says what they'll do next | Confirm: "Does this feel doable?" |

For the person giving feedback: If a colleague shares early work, treat it as a work-in-progress. You're not evaluating a final product; you're helping someone think through a problem. Be encouraging about the direction, but specific about questions and concerns.

For the person receiving feedback: During the feedback phase, your job is to listen, take notes, and resist the urge to defend. Save the "but actually..." for later when you've had time to reflect.

Feedback exchange checklist

Before asking for or giving feedback, use this checklist:

# Feedback Exchange Checklist

## Asking for Feedback

- [ ] I've identified ONE specific thing I want feedback on.
- [ ] I can write my success criterion in one sentence.
- [ ] I've prepared a concrete artifact (code, doc, demo, link) to review.
- [ ] I've estimated how long review will take the person.
- [ ] I've asked someone I respect, not just whoever is available.
- [ ] I've given them a deadline so they know when feedback is needed.

## Giving Feedback

- [ ] I understand what the receiver is asking for (I asked clarifying questions).
- [ ] I've read/reviewed the artifact carefully (not skimmed).
- [ ] I'm ready to give feedback using the three-part structure: observation, context, question.
- [ ] I'm prepared to spend the time they're asking for (and not more).
- [ ] I'm aware of my own biases (do I dislike this approach just because it's different from mine?).

## After Exchange

- [ ] I took notes on what was said.
- [ ] I identified one or two concrete actions I'll take.
- [ ] I followed up with the feedback-giver to let them know what I did with the feedback.

Practice: one week of specific feedback

This week:

1. Ask for one specific piece of feedback. Think of a project you're working on. Identify one thing you're unsure about. Use the template above. Ask someone: "Can you look at [specific thing] and tell me if [specific criterion] is met?" (Not "does this look good?")

2. Give one piece of feedback. If a colleague shares work with you, give feedback using the three-part structure: observation, context (tied to their goal), question.

3. Follow up. After the other person acts on your feedback (or decides not to), ask them: "Did this feedback help you? What could I have said differently?"

After one week, notice: Did the feedback you asked for help you? Was the feedback you gave useful to them? Iterate on the structure. Most people find that specific feedback, given and received frequently, compounds faster learning than waiting to get feedback at the end of a long project.

Challenge: Do this three times before your next interview or major project deadline. Track whether the quality of your work improved. (It should.)

Common mistake

Do not use feedback as a way to feel good about yourself. "I shared my code and someone said it was great!" is validation, not feedback. It doesn't teach you anything. Real feedback might sting a little because it points out something you didn't see. That sting is often a sign that the feedback is useful.

Also, do not give feedback that centers on you instead of the work. Bad: "I wouldn't have done it that way." Good: "You mentioned your goal was speed. This implementation is thorough, but I wonder if you could achieve the same correctness with fewer steps." Tie your feedback to their stated goal, not your personal preference.