[mmh0000]

Over the years, I've walked from several "live coding" interviews. Arguably though, if you're looking for "social coders" maybe the interview is working as intended?

But for me, it's just not how my brain works. If someone is watching me, I'll be so self-conscious the entire time you'll get a stream of absolute nonsense that makes me look like I learned programming from YouTube last night. So it's not worth the time.

You want some good programming done? I need headphones, loud music, a closed door and a supply of Diet Coke. I'll see you in a few hours.

[AznHisoka]

Yep, if I’m forced to talk through the problem, I’ll force myself to go through various things that you might want to hear, that I wouldn’t do.

Whereas my natural approach would be to take a long shower, workout etc and let my brain wander a bit before digging into it. But that wouldn’t fly during an interview..

[shaneoh]

Ironically this is exactly how I am too. Even at work, if I'm talking through a problem on a presentation or with my boss, I'm much more scatterbrained, and I'll try to dodge those kinds of calls with "Just give me 30 minutes and I'll figure it out." which always goes better for me.

That said, now we're just talking about take home challenges for interviews and you always hear complaints about those too. And shorter, async timed challenges (something like "Here's a few hours to solve this problem, I'll check back in later") are now going to be way more difficult to judge since AI is now ubiquitous.

So I really don't think there's any perfect methodology out there right now. The best I can come up with is to get the candidate in front of you and talk through problems with them. The best barometer I found so far was to set up a small collection of files making up a tiny app and then have candidates debug it with me.

[trinix912]

> The best barometer I found so far was to set up a small collection of files making up a tiny app and then have candidates debug it with me.

This is a great one! I wish more companies tried that.

[joquarky]

I need my default mode network to produce good code, and I don't talk while it's active

[gjulianm]

The interview works as intended because the main priority is to avoid hiring people who will be a negative for the company. Discarding a small number of good candidates is an acceptable tradeoff.

[946789987649]

What do you do if a junior asks for help and it's easiest to code through with them?

[mmh0000]

Well, that's not really the same thing though?

In an interview, the coding challenge is often to produce something new from scratch while being closely monitored by people you don't know, who control your financial future.

When working with a "junior," you'd already be fairly familiar with the code base, build system, and best practices. And with a junior, you're not likely to be solving things that require deep concentration, like never-before-seen problems or architectural work (or screwball interview-tests). And, unlike an interview, if something does require all my focus, it's very easy to defer. Take a break and think about it alone.