Note: I don’t know the extent to which this post's advice will help others but I’m confident it can help some people (hence why I wrote this post), I see no downsides to following it (let me know if I'm wrong), and my advice stems from my experience of being an interviewee in 30+ interviews with 10+ tech companies in Fall 2019 when I was looking for a software engineering new grad role.
I read a blog post on a software engineer's experience going through software engineering interviews where the author says the following:
Next was a self driving car company. I got a response almost immediately after submitting my application and set up an initial code screen. The interviewer answered in a huff and with a very thick accent asked me to code up a very involved image filtration algorithm. I wrote it and asked for feedback. “This looks very good!”, he said. I got a canned rejection email the day after. Then came an analytics company that asked me to do a take home challenge. The challenge was a three sentence blurb. I did the best job I could on it and wrote a very involved multithreaded image processing system. I got a polite no from the recruiter and when I pressed for feedback I was told that my implementation was “too inefficient”.
Soon after, I saw this relevant LinkedIn post:
Some people are having trouble getting feedback from recruiters and interviewers so this is a post on how I got technical feedback from most interviewers when I was looking for a software engineering new grad role in Fall 2019. The following advice only applies to interviews where you're solving a problem in front of the interviewer (like in a typical coding interview). The advice in this post can only help you get technical feedback (i.e. not feedback on your soft skills [1]).
Don't ask for feedback after your interview
Before we talk about how to get feedback from your interview, we need to understand why the conventional approach, where you ask a recruiter for feedback after an interview, rarely works.
Recruiters are too busy to send rejection emails with feedback tailored to every rejected applicant. So they usually send generic rejection emails and the process of sending out rejection emails is at least somewhat automated via their company's applicant tracking system (ATS) like Greenhouse, Lever, Taleo, SmartRecruiters, and more.
Some companies' legal teams/departments advise against giving out any feedback to applicants because it's seen as a legal risk [2]. If an applicant gets rejected without knowing why, then they have little cause to file a charge of discrimination against the company.
The odds of getting feedback from a recruiter after your interview(s) are low, so let's talk about what you should do instead.
Ask for feedback before the interview ends
A software engineering interview at a tech company usually involves solving a technical challenge and verbally explaining your thought process to an interviewer. Then, before the interview ends, the interviewer will typically set aside a few minutes for you to ask any questions you may have about the company or role. The transition between the technical problem and your-time-to-ask-questions period is where you should ask for feedback.
After you solve an interviewer's technical challenge, and after your interviewer has indicated that time is up for that portion of the interview, ask your interviewer:
"What would you have done differently?"
The worst-case response is your interviewer declines to answer that (in my experience, this occasionally happens). The best-case scenario is the interviewer takes note that you're proactive about growing, walks you through the optimal solution to your problem, and explains any trade-offs made in the optimal solution. In my experience, an interviewer will usually speak to at least one of the following:
- A very brief overview of the optimal solution (like a one-sentence summary).
- The good part(s) of your solution.
- Where your solution could use some improvement.
- An alternative approach of similar time/space complexity.
- Something good you said that stuck with the interviewer.
Here are a few examples of times when I asked an interviewer, "what would you have done differently?" (WWHYDD):
- After I solved a technical challenge that required implementing rudimentary search suggestions where the suggestions are a function of a list of product names and what a user has typed in an input box, I asked WWYHDD and the interviewer responded to my question with another question: "Have you heard of prefix trees?". I said no and they told me to look it up after the interview. I didn't get an offer but I looked up prefix trees (i.e. tries) and learned what I could've done better.
- After solving a technical challenge and asking WWHYDD, the interviewer wrote the code for an alternative solution on the whiteboard and said it was more optimal than my solution. Seeing that I was puzzled, the interviewer proceeded to walk through an example but then they realized it didn't work on some cases (the interviewer may have needed to make slight changes for it to work or maybe they misremembered a part of the true optimal solution). The interviewer changed their mind, cleaned the whiteboard, and said my solution seems optimal. Since I asked WWHYDD, the interviewer went from thinking my solution could be much better to thinking it's probably optimal. I got an offer.
- In response to WWYHDD, an interviewer walked me through the most optimal solution to their technical question [3]. It was significantly better than my solution so I didn't get the offer but I learned something! Two weeks later, another company asked me the same question [4]. I was well-prepared.
The WWHYDD question works because it's clear you're looking for feedback on your solution to the interviewer's technical challenge and WWHYDD is an open-ended question so the interviewer can share whatever they're allowed to share. If you ask a narrow question such as "what's the optimal solution?", then the interviewer could respond with "Oh I can't speak to that" and say nothing more.
Caveats and when to avoid
Depending on the context of the interview and what dialogue has already been exchanged, you may have to use additional words before or after the WWHYDD question. For example, if the interviewer says, "Alright, good job working through that problem but we're just about out of time and I want to give you the last ten minutes to ask any questions you may have about my work or the company", then you could respond with, "Before I ask you questions about the company and your work, what would you have done differently? Gesture at the work on the whiteboard." Use your best judgment on the phrasing of WWHYDD.
If there's very little time for you to ask questions to the interviewer then consider using that time to ask questions about the company instead of WWHYDD. If you get an offer you'll be more informed about the company which can help you decide whether to accept the offer.
Try it out
Before the end of your next software engineering interview, consider asking your interviewer, "what would you have done differently?". Note that there's more to an interview than just your technical skills (i.e. your soft skills matter too) and your interviewer will probably respond to the WWYHDD question with technical feedback only.
I think asking WWYHDD can work in any interview that involves demonstrating some sort of problem-solving. Try this out and let me know if the question helps you get feedback!
(Also, feel free to share feedback on this piece of writing. What would you have worded differently?)
Thank you to Tim Nguyen for reviewing this post and providing feedback.
[1] You can get feedback on your soft skills by doing a one-on-one mock interview with a friend (and let them know you're looking for feedback on your soft skills too). Treat it like a real interview.
[2] See https://www.thebalancecareers.com/must-employers-tell-applicants-why-they-weren-t-hired-1919151 and https://resumeinsider.net/blog/why-dont-recruiters-give-feedback
[3] It was the LRU Cache problem.
[4] I told the interviewer I had already seen their question in a previous interview but they wanted me to solve the same question anyways. This has happened in other interviews too.