Making people write code on paper is just ridiculous - way outside of testing and checking reality - and your reasoning of
>"because it shows that they know how to think about code"
means nothing at worst, and at best indicates you'll only be happy to work with people who are replicas of yourself.
Take home is the way to go, unless the position is some sort of public exhibitionist analogue developer position.
The least I think you can do is move from paper to machine, and inform them they should bring their own machine, or offer them use of one with many envs preconfigured.
The problem with take home interviews is that it could take one candidate an hour, and another every evening for a week.
Ideally the interviewer shouldn't be concerned about absolute code correctness, such as syntax or argument position, and should be interested more in how you're able to solve the problem, which should be a novel, yet simple task that doesn't require studying up on 200 level algorithms.
You want to hire developers (for permanent full time roles, at least) who have a good conceptual grasp of programming and logic, rather than their particular knowledge of a language or framework, or their ability to search on stackoverflow and run their code through a linter.
The worst interview problem I've been given was to write an AngularJS directive, I think literally to simply take an attribute and display it. I can't remember at the best of times the syntactical oddities of AngularJS, let alone when writing with pen and paper in an interview with no resources.
One of the better problems I was given was around parsing XML, from memory validating that opening tags matched closing tags, while allowing for self-closing tagsI remember the problem specifically didn't include any more complex facets of XML. Another was to reverse a string in-place ("hello world" -> "dlrow olleh"), and then to modify the algorithm to reverse the words but keep them in place ("hello world" -> "olleh dlrow"). Obviously in the real world you'd just use built in methods, but it's a problem that should be solvable without digging up your old lecture notes.
I've always felt comfortable writing code (or at least psuedocode) with a pen, but I think it's unfair to require a candidate to solve the problem on paper or whiteboard if they feel more comfortable typing on a computer instead, all that achieves is disadvantaging otherwise capable candidates who for one reason or another can't write code with a pen and paper. As long as they aren't googling "how to reverse a string in place", it immaterial what writing tool they use. If they feel more comfortable using a brush and papyrus, or carving a runestone, then that should be perfectly acceptable too (provided they bring their own writing material).
This varies a lot. I had a take-home for a data engineer role which just asked to get and parse an xml and post a cleaned, limited json of the data. Took ~1hr. Perfect for an initial threshold.
>"because it shows that they know how to think about code"
means nothing at worst, and at best indicates you'll only be happy to work with people who are replicas of yourself.
Take home is the way to go, unless the position is some sort of public exhibitionist analogue developer position.
The least I think you can do is move from paper to machine, and inform them they should bring their own machine, or offer them use of one with many envs preconfigured.