Feedback When Companies Won't Give It: Reconstruction and Self-Diagnosis

The rejection email is two lines long: "Thank you for your time. After careful consideration, we have decided to move forward with other candidates." It says nothing about what happened, and your mind fills the gap with the worst explanation.

Companies often give no detailed feedback; many have policies against it, partly because feedback can be disputed and partly because interviewers are busy. That leaves you with two sources of information: the little you can politely ask for, and your own careful reconstruction. The second is more reliable than it sounds, especially with an AI assistant as a structured second reader.

• How to ask for feedback in a way that sometimes gets a useful answer.
• How to reconstruct an interview while it is fresh.
• How to classify what went wrong, with AI as a second reader.
• How to find patterns across several interviews.
• How to use other candidates' reports to calibrate, and when to let a rejection go.

Ask once, in writing, within a few days, briefly and specifically. A narrow question is easier to answer than "how did I do?":

Subject: Thank you, and one questionHi [Name],Thank you for letting me know, and for the time your team spent with me on the[role] interviews. I understand if it isn't possible, but if you're able to shareone area I should focus on improving, for example whether it was my problem-solvingapproach or my design round, it would help me a lot.Thanks again, and I'd be glad to be considered for future roles.[Name]

What to expect: many companies will not answer, or will send a general line. Smaller companies and startups sometimes give real feedback. Recruiters occasionally say something like "the panel felt your design round needed more depth", which is valuable. Do not argue with any feedback you receive; thank them.

If you are connected to an interviewer, or they invited contact, a short thank-you without any request can leave a good impression for future roles:

Hi [Name], thank you for the interview for [role] last week. I enjoyed workingthrough [problem]; afterwards I realised [one specific improvement]. I hope ourpaths cross again.

Do not ask an interviewer to explain the decision or to reconsider. It puts them in an awkward position.

Within a few hours of each interview, before you know the result, write down:

Company / role / round / date / format:Interviewer's role (if known):Questions or problems, as closely as I remember:1.2.For each: my approach, where I got stuck, what I said, how long it took.Moments of uncertainty (what happened just before?):Questions I could not answer or answered weakly:What went well:The interviewer's reactions: engaged, rushed, sceptical, gave hints?Anything they emphasised or returned to:My own honest rating of this round (1 to 5) and why:

Keep these private. They are for learning, not for publishing questions, which many companies prohibit.

Most interview problems fall into three kinds, and they need different fixes:

An assistant is a useful second reader of your reconstruction, as long as you remember it was not in the room:

Below is my reconstruction of an interview I was rejected after, written a fewhours after it. You were not there, so reason only from what I wrote, and saywhen you are unsure.1. For each question or part, classify the main problem as a knowledge gap,   an execution gap or a communication gap, and quote my notes as evidence.2. What is the most likely reason the round did not go well? Give two   alternatives if the notes are ambiguous.3. What is one thing I did well that I should keep doing?4. What should I practise this week, in priority order?5. Is anything in my notes a sign of a wrong target (role or level), rather than   a skill gap?[paste reconstruction]

Be suspicious of a confident single explanation from very thin notes. Sometimes the honest answer is "unclear".

One reconstruction can mislead. Three or more start to show patterns. Keep them together, for example in a notebook tool or a project in your assistant (article 27), and ask:

Here are my reconstructions of [N] interviews from the last [weeks], each withthe outcome. Using only these notes:1. What weaknesses recur in more than one interview? Quote each instance.2. What strengths recur?3. Do problems cluster in one kind of round (coding, design, behavioral, HR)   or one kind of company?4. If I could change one thing, which would most likely improve results   across these interviews?Say if the sample is too small to tell.

Then compare with your funnel numbers (article 42). If the numbers say "interviews are failing" and the reconstructions say "design rounds keep going badly", you have a precise target.

Interview-experience pages, review sites and forums (article 26) describe what other candidates faced and sometimes what helped or hurt them. Use them to calibrate, not to blame yourself:

• Was the round harder than usual? If reports from the same period describe the same difficulty, the bar may simply have been high.
• What did successful candidates do differently? Look for patterns: "asked lots of clarifying questions", "had a project in our domain".
• Is the role still open? If it was reposted, they may not have found anyone; reapplying later (article 44) is possible.

Some rejections have little to do with your performance:

• The role was filled by an internal candidate or someone further along.
• Budget changed and the role was frozen or closed.
• The team wanted someone with a specific skill or more experience after all.
• Another candidate was simply a better fit on the day.

You often cannot tell which. Diagnose what your notes show; if they show a reasonable performance and nothing clear, record it as "unclear", keep the lessons you have, and move on. Not every rejection has a lesson.

Lavanya has four reconstructions after interview rejections:

1. Product company, coding round. She solved the problem but stated the complexity wrongly and did not test an edge case. Execution and communication.
2. Startup, project discussion. Asked why she chose MongoDB, she said "it's popular". Knowledge and communication: she had not thought through her own decision.
3. Capability centre, technical round. Questions on database normalisation and transactions she could not answer well. Knowledge.
4. Product company, coding round. She went quiet for long stretches while stuck and did not ask for hints. Communication.

The pattern prompt shows two recurring themes: fundamentals of databases (rounds 2 and 3) and communication when stuck (rounds 1 and 4). Her plan: a week revising databases through her own project's schema, writing a decisions file (article 7) and recording two think-aloud mocks a week, using the transcript analysis from article 33.

• Asking for feedback repeatedly, or arguing with it.
• Writing nothing down, so every rejection feels the same.
• Blaming everything on yourself, or on the company.
• Treating one interview as a pattern.
• Letting AI invent a diagnosis from thin notes.
• Publishing interview questions where the company forbids it.

Hi [Name], thank you for letting me know, and for the time your team spent withme. I understand if it isn't possible, but if you could share one area I shouldfocus on improving, it would really help me. Thank you again, and I'd be glad tobe considered for future roles.

• Next: Course-Correct and Keep Going: Reapplying, Resilience and the Weekly Review turns diagnosis into action, and keeps you going.
• For mock interviews to work on what you find, revisit Mock Interviews: AI Voice Practice, Peers and Recordings.
• For learning hard topics with AI, see How to Use AI to Learn a Difficult Technical Subject.