These sound like very valid issues. It might not be good for every candidate, but having a conversation about the code seems less stressful to me than having th

These sound like very valid issues. It might not be good for every candidate, but having a conversation about the code seems less stressful to me than having the interviewer bring out a whiteboard and essentially say, "Please perform for me!" You say: > One issue was the syntax was so weird compared to the type of code I'm used to writing and reading from others in library code that it was hard for me to comprehend the logic without the benefit of looking it up. From the point of view of an interviewer, that's feedback I'd be interested in. One problem I've seen in some of our code is an engineer using a completely valid but very obscure method of doing something, and then the rest of us having difficulty maintaining it. I would want to hear, "this looks hard to maintain." But I understand that in an interview, it can be difficult to assess what the interviewer wants to hear and that can be nerve-racking. I personally think take-homes are a reasonable compromise, but not everyone does.