I have done the entry interview as well. For example have had very good conversations with managers who were applying for senior IC roles. They then go and fail the tech interview basic "can you do write and execute a python hello world script from the command line".
It reminds me a professor who recently told me, regarding ChatGPT use in university: "we're receiving every week applications from foreign students written in perfect German, then when we schedule a call for an interview with the potential scholar, they're incapable to speak either German or English."
I'm personally done with frontend/UI development roles where the interviews expect you to "brush up on CS fundamentals" or "prep", and then they ask nothing about "here, make this UI", as if it's some side thing. And if you didn't "prepare" for their leetcode crap, they act like you are some huge liar/faker who's somehow been coasting for 15 years.
On other hand I wouldn't say it would be unreasonable for UI people to setup some basic UI or like that could be done fast. And then do some edits there. Even if it is just copying some toy project. Then again I am not sure what is the current state of fronte-end and how much crap you need to do basic UI.
but i also think that that's why live coding can work really well with simple problems like fizzbizz, create a list of fibonaccis, etc. these are simple-ass problems that any coder can churn out in their sleep. if the stress of an interview prevents you from solving something like this... you probably need some more practice coding until something like this becomes easy enough to do under stress.
https://leetcode.com/problems/longest-substring-without-repe...
Totally different IMO.
I'm more curious than anything else for my own sake to know things people might ask. But its interesting how extremely simple things can be complicated if you haven't done them before. Like if someone asks about a relatively simple regex example in python it'd be easy to get if you just were working on a regex but you could get tripped up if it had been a while since working on one. You could say the same thing about working with datetimes. At least this is the type of thing that throws me off in an interview, maybe I'm not a great candidate though.
If people do not have local setup, I just have them write out in text editor and walk through the steps. Maybe not 75% fail rate, but more like 50% of people fail this step in the tech round.
It seems like the suggestion is to put them somewhere private to perform the task rather than asking them to do it in a public setting.
I do personally let people pass the tech if they have good open source work (a good tech blog, legit python repo's, not just trivial homework stuff they did in school). So few of people have that though.
What if this is just a (labor-saving) tweak to on-site live coding interviews. You've already reserved the room. The status quo is that a member of technical staff is in the room with the candidate for the duration of their interview. The low-cost alteration is, after you explain the task and make sure it's clear, you leave them alone in there for the remainder of the period. Perhaps the interviewer gets a few small work tasks done while waiting outside.
I think the only unfortunate thing is that when you're in the room trying to talk to them about their solution as they write it, sometimes you can have a helpful discussion, which may involve probing or leading questions, which sometimes give you some signal -- but these also make it much more difficult to compare across candidates, so perhaps we should be ok letting go of that opportunity.
It seems unavoidable to know how to run a script if you've done it within say a month. Now not remembering the if __name__ == __main__ thing is more forgivable.
It is even less tricky than you are thinking. I literally just want them to know you need to put in a `hw.py` file `print("hello world")`, and then run from the command line `python hw.py`.
The reasons for failure are myriad (I suppose you could say it is they do not understand, but I legit try, regularly spend 10-20 minutes on just this for the ones who have problems, I am not being tricky). A few are people who do not know file systems (save their `.py` file in a wrong location), a few I think just do work in environments like served jupyter notebooks so don't have any relevant software dev experience (don't know how to execute python directly or write code in a .py file), some I am pretty sure are just liars on their expertise (have a few that just leave interview when asked this question).