Sometimes it's not a good idea to give too much feedback, if any at all.
I used to automatically provide feedback of why a candidate did not pass the interview, then I had a few sour encounters where the candidate just did not react professionally. For example, one candidate bemoaned the emphasis on CS fundamentals in our interview. In that case, the candidate was coming in from a mostly front-end webdev background, but our tech stack extends far below the typical webdev "full stack", where knowledge of OS/Networking/Compiler fundamentals is helpful in everyday design decisions. As a small team, we bias towards generalists for now, so while the person might be a great fit for his skillset in another organization, it just wasn't a great fit for us at that time. I tried to explain this, but I received a wall of text complaint email back. I had taken an hour out of my day to write immediate and specific feedback about his interview, and all I got was pushback. This is probably why HR stands between engineers and candidates.
For some reason your "I had taken an hour out of my day" comment really bothers me.
The guy you interviewed probably spent ~4 hours preparing for the interview and then all of the time in the actual interview.
Let's say he takes 7 hours out of his life to interview for your place. The least he deserves is a legit reason why he was declined because your company still benefits from not hiring him. You get to refine your interview process based on real feedback.
The interviewee's time is just as valuable as yours. A wall of text complaint sounds pretty good. There's probably a lot of good feedback in there unless it happened to be filled with insults and other garbage in which case you should have been able to figure this out quickly and then not replied.
If you give a reason, there's a small chance that you may have to defend that reason legally. Therefore, it's best to not give a specific reason. It's harsh, but protection of the business is more of a priority than potentially hurting someone's feelings by not giving a reason.
It's true. Sometimes giving your reasoning about things just leads to the other person trying to point out why your reasons are wrong. Rather than taking it as information they can use to improve their chances with other jobs, it's like they think it's an argument that, if they could win it, would lead to them being hired anyway.
> Sometimes it's not a good idea to give too much feedback, if any at all.
Sure. But a form letter from the HR person saying you are not a good fit is way better than your application has been rejected blah blah blah. Tech, especially Data Science is a small fucking place. Making enemies is incredibly bad. I know that I would go out of my way to strongly recommend that any of my friends who are ever rarely in the job market to not look at that company, or the tech lead.
Also, to look at it from other point of you. I once interviewed at another startup where the guy gave me cold harsh feedback as to why I was not the right fit. I still respect him for doing that. It was not the right fit for me. But, I would heartily recommend the place to anyone else who I think would be the right fit.
I used to automatically provide feedback of why a candidate did not pass the interview, then I had a few sour encounters where the candidate just did not react professionally. For example, one candidate bemoaned the emphasis on CS fundamentals in our interview. In that case, the candidate was coming in from a mostly front-end webdev background, but our tech stack extends far below the typical webdev "full stack", where knowledge of OS/Networking/Compiler fundamentals is helpful in everyday design decisions. As a small team, we bias towards generalists for now, so while the person might be a great fit for his skillset in another organization, it just wasn't a great fit for us at that time. I tried to explain this, but I received a wall of text complaint email back. I had taken an hour out of my day to write immediate and specific feedback about his interview, and all I got was pushback. This is probably why HR stands between engineers and candidates.