In this case, it played out as a wrote it - I offered some solutions to the problem and thought about different ways to solve it, then implemented the one I thought was best on the whiteboard. About halfway through he asked me why I wasn't implementing the best version, so I thought some more about it and couldn't come up with an in-place solution (which is very hard to find in an interview setting), so I continued down the same line when he wouldn't give me any help. After the interview his feedback to the manager (which I received because this was through a referral) was that he expected me to have this algorithm memorized and he gave me a "Strong No Hire" because I couldn't give the best solution.

Its worth noting that I received offers from over 50% of companies I interviewed at and I certainly am not bad at coding - this was just a particularly bad interviewer using a very bad problem. With this company, I actually told them I wouldn't accept an offer even if they did give me one because the interview was so bad.

You had a hint that there was an in place solution and a set of pointers. I mean the only real question here is how many spots you need to look ahead...

I understand that whiteboard can be frustrating and hard, but it sounds like your interview was the exact kind of interview people try to make

It really depends what type of candidate you are looking for and what sort of job it is. One of the often overlooked roles of a hiring manager is understanding the signals coming in from the interviewers, weighing the results properly against other information, and making sure that the interviews actually gave information which can correlate to on the job performance.

In the past when I've been the hiring manager, I've had inexperienced interviewers ask my candidates questions like this for all kinds of positions - when you look at who does well in other interviews and gets an offer (and performs well), it basically never correlated at all to performance in whiteboard-only CS-focused interviews.

In this case I was interviewing for a full-stack senior position where there would almost certainly be zero systems-level coding, so the interview should have been a throwaway at best.

The point is that interviewers should not be looking for a "specific" answer. They should be looking for how well a candidate matches the expectations of the position. Asking for specific algorithm implementations is objectively bad interview practice.

So, it sounds like the candidate was interviewing for a senior engineering position and was given a problem to reverse a linked list in place. This is an entirely reasonable constraint and something that you would expect someone in a senior position to be able to do.

Space constraints do come up frequently and being able to reason about them is important.

I still maintain that asking for specific answers is a bad interview practice. It's a sign of a poor interviewer, not necessarily a bad candidate. It could be both in this case, but I'm talking about it at a more meta/higher level. IMO, it is objectively BAD interview practice being described here.

Sounds like you dodged a bullet in that case :)