I have never gotten an answer to that question. However when I was on the hiring side I did gave that answer multiple times. It was not uncommon for candidates we rejected to ask that question, and I would usually reply with specifics of their interview, we had them do a take home and had an interview going over that and some other topics, here are some examples that I remember (obviously I worded these a lot more politely, and sometimes mentioning that it wasn’t bad on its own, but other candidates were better):

• Your code didn’t have any tests, when asked about it your answer was dismissive towards the concept of TDD.

• There were several security issues with your code, none of which you were able to spot or discuss.

• Your code was illegible, variables and functions had no identifying name and functions had high cyclomatic complexity.

• Your code didn’t do what was asked for the take home, it was missing important parts, so it was impossible to properly evaluate you.

• Your code was excellent, but you couldn’t explain any of it, when asked to guide us through the flows you only read the functions line by line, never describing the flow in a big picture manner, even after several prompts from us.

Some of those might seem stupid, but this was a senior position and we had better candidates, so I tried to point to specific stuff that differentiated the candidate we hired from them.

There are also two special cases I want to point out, once a candidate didn’t had anything bad in it’s code but he was VERY annoying, as in refusing to answer anything, down talking to us for asking obvious questions, etc, luckily he didn’t asked why he wasn’t hired, because the answer would have got to be a generic “not a good fit culturally”. The other was a guy who had a very obvious SQL injection bug in an endpoint, that on its own would not disqualify him, since even senior engineers make mistakes, but we started our talk discussing security and specifically SQL injections, when we got to that endpoint I tried to prompt him to spot it, he didn’t, eventually I outright told him “there’s an SQL injection bug here, can you spot it” and his answer was “no there isn’t”, so I asked him to open his browser and access something like http://localhost:3000/endpoint/wrong and explain to me why he had gotten the answer he did (expecting him to realize that he was putting he table name directly into the SQL without parsing), he came up with an excuse that it was because wrong wasn’t a table and his code was correct and secure, so I built an url that would inject DROP ALL TABLES and asked him to open that and explain the response, he gave the same speech of that’s not a real table so my endpoint is correct, and then I asked him to look at his database now and explain why it was empty. That guy also didn’t ask why he wasn’t hired, but I’ll always remember the interaction, it felt so surreal to tell someone there’s a security flaw here and his answer being “no there isn’t” without even questioning if he was right, that’s not the sort of people you want in your team.