I'm sorry, but as an interviewer I'll never not have some form of live coding. Some people just don't know how to code. I don't mean that in some elitist, gate keepy way. I mean some people lie on resumes. If I used Excel every day (like I was an accountant) I would not take someone's word that they know how to use Excel, I'd want to see them do it.

I am fully aware that problems are harder under stress. I advocate for genuinely easy problems in coding challenges. I don't like brain teasers. I don't really even care if you finish the problem. So long as I can tell that you know how to make a computer do things you tell it in code, know how to ask questions about a problem, and make progress towards solving it -- I'm happy.

At an old job I made the mistake of not conducting a coding session of some form and we hired someone who I genuinely believe didn't know how to program. They'd ask for help on tasks very often and I'd try to guide them in the right way, but once we paired up, they just wouldn't ever type anything. After me becoming more and more clued into something being wrong and seeing no progress I finally mentioned it to my manager. I don't think he ever got fired, just shuffled around.

If you give live coding tests you're a moron. Here's why. Not all but many of us coders are autistic or highly functional autistic and our brain shuts down in high stress social situations with someone watching over you. Plus whiteboarding when I never fucking whiteboard anything. But get us alone in a room with a task and we'll whip your ass.

My last boss pulled this on me. I almost didn't get the job. Then I told him to assign me any project as homework. Overnight I produced a program that blew them all away. Got hired.

We do this crazy thing called "pair programming" and "collaboration" periodically at work. It's cute you want to claim live coding in interviews is some horror that should never have been imagined. The rest of us will enjoy having jobs.

I give live coding tests generally based on the level they claim to be at in the language. It doesn't have to be perfect as I'm more concerned with why they're doing a thing. I usually pick something fairly basic with some edge cases just to see if they mention it.

As opposed to homework, it also proves that you can at least basically work in the language in question (I've had a couple of people who got to my round but seemed to know almost nothing about a language they claimed a lot of experience in (like declaring variables and struct members wrong... seriously). We also caught someone that didn't seem to have done the homework themselves.

If the candidate makes mistakes or gives an imperfect solution, I try to gently guide them to where we need to be. I ask them to explain why they made decisions they did, any edge cases, and how to improve performance or scale it. I expect them to ask questions when something is vague (and usually something in my problem can be interpreted one or two ways for this reason) because these are things they will encounter working with stakeholders and other engineers. If they can't do that live and on-the-fly, they're probably not for us. I fully expect nerves to be a factor and account for that; we're all nervous in interviews.

I disagree. I give live coding tests. I very much don’t want the candidate to be stressed. I provide a written and verbal description of the (simple) problem, and provide unit tests. And I talk them through it if they run into problems, but try to give them space to work it out.

I’m not sadistic. I want to see if they can write code.

The few times I skipped the live test because of practical reasons or they were “too senior” I absolutely regretted it.

I can see how this could be unfair, but working as a dev sometimes does require you to be on top of things in a high stress atmosphere. For example, what if you're proposing an excellent technical solution in a meeting but some jaded older engineer is hard to convince? If you can't outline your thinking in that scenario, your solution could be discarded just because someone was louder than you. As someone who used to have performance anxiety, I believe it's generally something you can and should practice for. On the other hand, if there really isn't a need for this type of skill, it totally makes sense to avoid creating interview environments where you are filtering candidates based on it.

I think asking one simple coding question during a live interview is a great way to eliminate candidates that have obviously lied on their CVs. Nothing fancy, just a simple problem that everyone should know. But asking leet-code medium or hard problems make no sense.

Our industry has no idea how to hire people. Our interview processes are almost designed to filter out obviously bad candidates while accepting that some good candidates will fail, too. Getting a specifically good candidate is almost luck.

Remember this if you're bummed about a string of rejections.

In my first interview they put me in a room with a PC with Borland C and a copy of K&R and a sheet with a simple problem to solve and some extra enhancements if I had time. They said they would be back in half an hour and left me to it. That I passed fine.

Some twenty-ish years later I was asked to write a C function to reverse a string on a white board and I failed because I'd misformatted the for loop. I don't think it was because I've become a worse C coder in the intervening years.

When I'm actually coding I'm sat with my editor configured Just So with completion, compilation and unit tests at my finger tips. My favourite coding music blasting my speakers and a handy browser window for looking up anything in unsure of. This is my most productive setting and expecting the same performance in a stressful interview setting is foolish in my opinion.

Working through problems on a white board can work well but you are looking for the problem solving approach, not an encyclopedic knowledge of regex syntax. Those same problems get immeasurably harder when explained over a phone call.

My personal preference when evaluating candidates ability to code is reading their actual production code, the break down of commits, the commit messages and the sort of unit tests they add with a feature. The interview is more focused on their soft skills, what about the work excites them and what they are looking to get out of the role.

IMO this is not a helpful way to put it. They measure skill under stress. Stress may have a large effect on skill level for some people but highly unlikely that it's so large that performance is completely random.

my current company does live code design challenges instead of straigt codong exercises. seems to work well