No one knows why they actually failed her on the interview. Have run many interviews, and it is very rarely the case that you fail a candidate for one technical slip up.
I wouldn't believe anyone who said they've never been there. For all the times you're told to trust your gut, there are plenty more times where your gut is just plain wrong and you have to go against it.
Personally, when I'm interviewing I help people get past dumb mistakes. We all make them, and some of the best developers I have worked with are the type to get nervous in interviews, so they become more likely to make them and have a hard time finding them. The "best" interviewee is not always the best developer.
Thankfully the author left the name of the company off. I'd hate for half of a secondhand account like this to cause candidates to avoid interviewing at a company!
But, more importantly, very few candidates fail on a single question. They usually fail on patterns: Poor comprehension of the task at hand, too many snap judgements, or lack of professionalism.
(Another reason, though, is that I've rejected a lot of people who I believe shouldn't be software engineers. It's not my place to tell them they should pick another career, nor do I want to make it easier for them to bluff their way to becoming someone else's headache.)
If you rely on a "not-leaked" interview to filter out bad candidates, it's likely that you may not be conducting an effective interview.
Good interview is about figuring out "what the candidate is good at" not about "gotcha I proved that you're a bad one to filter out". I don't have a set of questions I ask all the candidates. Instead, I based the questions on their experience and projects. It's common that I found out "the candidate is not as good as they claim for this subject", and that's fine. The interviewer can switch the topic and see if the candidate is good at another subject.
Everyone is good at something. The job of the interviewer is to find out that, and whether that fits the business needs. The job of the hiring committee is to decide whether it's worth paying for that compared to other candidates. The only "filtering candidates" job is the recruiter, not the interviewer.
Doctors don't, in general, get asked trick/gotcha questions when they apply for jobs. Neither do lawyers. Neither do other kinds of engineers. Neither do musicians, for that matter.
From long-ago undergrad I remember that there is a data structure called a "red-black tree". Now, I've never had that as an interview question, but I could easily imagine it being one.
Would I be able to answer a cold question on red-black trees? Nope. As I said, that was a long time ago, and I've never had to use one to the best of my knowledge. Would that be a good reason to filter me out? Nope. If I needed to use a red-black tree (or, in general, had a problem where some unusual type of tree might be in order), I'd pull my copies of Knuth, CLR* and Sedgewick off the shelf, look at strengths and weaknesses of the different types of tree, and make a decision.
* mine is old enough that it's just CLR, not CLRS :-)
Will there be leetcode-type questions? Roughly which level? Laptop, or whiteboard? Should I expect to be quizzed on networking? Javascript "gotchas" for crap I reflexively avoid so may have forgotten about? UX principles? Will the questions be general, or specific? Will it be a mix? How much, if any, of the day will be whiteboard stuff, and which part of the day will it be in?
The answers to these, and more, you should provide up front, without being asked, well ahead of time. Your signal will go up, not down, if your candidates have half a clue what to expect, out of the space of all things that might be asked in a software developer interview. Keeping this stuff a mystery and ambushing your candidate at 9AM sharp with data structure whiteboard questions, after they've flown for two hours to get to you, got up early, were on a plane then in a taxi for a while, et c., when they didn't know you were gonna do something like that, is just giving you tons of false negatives. Knock that shit off, you're wasting money and giving people bad days for no reason.
That, or just stop expecting people to "naturally" be able to pull this stuff out of their head and perform for you like a monkey, while in a stressful and semi-adversarial situation that does not resemble collaboration and teamwork in a real job (there's the excuse that "well you have to be able to perform under pressure" but interview pressure has nothing to do with, say, "prod broke and the DB went bye-bye" pressure, so that's bullshit, too). And then communicate that fact—that you're not going to torture them—too, so they don't have to stress out over it.
Then what's the point of the interview?
Considering the amount of incompetent candidates I've had to filter out, that just won't work.
IMO: We need a licensing board to do that for us. It works really well in other industries, where they don't need to test competence in their job interviews.
It's difficult to give an honest answer to this question even if you want to be honest.
There are often so many little reasons that go into a rejection -- different reasons for different interviewers all feeding into an activation function that leads to a rejection or an acceptance (default state depends on team culture and how well you filter out candidates at the top of the funnel).
For most candidates, it's very hard to distill this into actionable criticism.
Edit: For anyone fundraising, this is also why you shouldn't listen too carefully to the reasons that investors give you when they reject your business as an investment.
All of us frequently give inaccurate explanations for our actions or attitudes because people often act on feelings, not on logic. Even when we want to be honest, we often lack the self awareness to know what what we're feeling and why.
On top of that, there are many who don't want to be honest, and will give an answer, any answer, just to make you stop asking and go away.
They might well tell you your skills are lacking when the reality is you remind the recruiter of the guy who ran off with his wife.
Further interaction with the job candidate almost certainly has a negative ROI (return on investment) for the employer.
If you tell the job candidate the honest reasons for rejection then at best you've used (wasted?) some time to tell the candidate this. At worst, the candidate sues.
But there are many other possibilities: The job candidate gets angry at you for telling them a hard-to-swallow truth and causes a scene. The candidate tries to argue or negotiate with you. The candidate accepts the truth and tries to use more of your time to discuss your original criticism and seek further advice.
None of these scenarios are a net positive for the employer.
Edit: I interviewed a year later, wasn't asked about SQL at all, absolutely fumbled my way through some networking questions, and was still hired, so it's clearly very dependent on who's interviewing you and what they ask.
And I retrained on smaller numbers and got that job at that start-up.