I can appreciate the author’s reservations around take-home assignments given how easy it is to cheat, but why not as an interviewer simply protect against that

I can appreciate the author’s reservations around take-home assignments given how easy it is to cheat, but why not as an interviewer simply protect against that by asking the interviewee to detail certain aspects of their implementation on a follow-up call? Whenever I submit a project for review, I’m prepared to answer questions about why I did X, why I used this tool/library/approach versus some other tool/library/approach, and what I could do to improve the implementation further. On the latter subject, I’ll raise that discussion even before being asked. If your applicant panics on questions like this — or is obviously clearly making shit up on the spot — there’s your indicator to reject. If you ask me to implement a B-tree, I’ll describe what a B-tree is and tell you I don’t off-hand remember how to do it or what an ideal approach would be in a given language. I’d tell you that I’d research it a bit before diving face-first into it. Which is what almost everyone would do in real-world contexts anyway.