So I do agree with most here that you shouldn't care one way or another about getting feedback and the author seems to be overreacting somewhat, I do want to share that for each of my last 3 rejections from startups, I did receive politely worded feedback as to why I was rejected. So again, while I do agree that the author is overreacting in the sense that it's not helpful to emotionally react this way, I don't think his expectations are necessarily out of line - it's possible to treat candidates better and the more candidates expect to be treated well, the better the industry will be.

On top of this, the criticism regarding how the author is self-unaware (I don't entirely disagree) seems especially misguided because often how self-unaware people become self-aware is through constructive feedback. With that in mind, since the author seems to be here, the one piece of feedback I have is that:

"I sent over some different code, it was a 5 line code change that halved the average response time of an API."

I don't know if the author was at this point interested in the job or not (if this was a joke, please disregard) but some clever 5-liner is extremely unlikely to impress anyone looking for a senior engineer and is impossible to evaluate in isolation. Also most of the work involved in "halving the response time" - again, assuming a reasonably complex system - is identifying where the bottleneck is, not writing the simple fix to address the issue that was discovered. You're expected to write substantially more code than that even in a 30-minute technical screen. When people are looking for code samples (again for a senior engineer), they are looking to see the ability to design and organize larger chunks of a system, make trade-offs between different architectures and ability maintain good code hygiene over a larger sample and so on - providing a 5-liner raises more questions than it answers.