Live coding interviews measure stress, not coding skils

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.

You don't know how good you've got it. The hiring process in other industries is much worse.
- Story time?
- for those who this affects, this lands badly

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.

fully agree. we're actually reintroducing live coding interviews into our process because so many candidates made it onsite who then showed that they didn't really know how to code
- The article isn't saying don't check, it's saying that live coding interviews are a bad measure.
You seem to be disagreeing with something that isn't the main point of the article.
That you take those steps doesn't mean candidates aren't stressed, despite your intentions.
- Sorry an interview is stressful to candidates?
Interesting. What do you think happened with those you didn't test? You think they were making stuff up or senior at their job is a far cry from senior at your job?
- Not sure. One seemed either incredibly timid or just way in above his head on simple tasks. I assigned him a bug and had already narrowed it down to a particular return code, in a particular call tree. He could have set 20 breakpoints and found the bug in five minutes. Or put unique error codes and found the bug in ten minutes.
  But weeks later he was still asking questions and eventually just moved on without solving the bug or even finding the cause.
  Maaaybe he would have aced the live coding test, but I doubt it. He just never seemed to "get it" and I think the live test would have reflected it.
  But by "senior" i mean decades of experience. No quibbling about job titles.

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.

Depends on what your requirements are. Some times it's the best way to let a candidate shine, which is usually the goal -- give people as much of an opportunity to impress as you can
- If a requirement is that a developer writes code then I want to see them write code.

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.

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 did stress test interviews for DevOps positions. I explicitly told them that and gave them a task and a time limit. I would watch what they did and there was nothing out of bounds as long as they were solving problems. For example, I would give them an account in cloud provider and then task them with spinning up a k8s cluster with a few basic services and make it scalable, then watch and heckle as they googled around and brought up services. The objective wasn't to complete the task though, it was too see how they approached problem solving. Good times.
- Great example. We do the same but to spin up a single ec2 via terraform. Checking the real familiarity with tools. This immediately filter those who lied about their experience.
Good enough example, although I would've picked dealing with a live incident
- Yeah, that too! When you have some non technical manager breathing down your neck, you might have a hard time not fumbling around even if you normally could resolve the issue in no time.
- That sounds fair. I hate "tests" that involve things you'd never do on the job.

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.

Nah, they measure memorization under stress. Can you recall that tidbit of information to solve the problem the interviewer has given you? If you never have needed to solve a problem like that then you’re shit out of luck, even though solving that problem for the first time (by whomever) definitely didn’t do it under stress in a job interview.
- Some bad interview questions are like that, sure. But they're supposed to be things you are very unlikely to have done before and can reasonably figure out. It's not too hard to come up with simple questions like that. (Though I will grant many people don't seem to bother.)

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.

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

is the point of a question like that not to measure how you perform under stress? the guy who posted it in the screenshot doesn't seem to realise that either though...

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.

People have different levels of "nerves" as others, and it kind of sounds like you may filtering out applicants on an arbitrary metric (how nervous a person may be in an interview). Don't have enough information about your process to say for sure (obviously), but it may be something to think about. Interviews can be very high-stakes for some people (such as "I may become homeless"), and not for others ("my parents are rich"). After hired, it's not necessarily as high-staked, and toy problems aren't what SEs work on day-to-day.
- I'm mostly making sure they didn't completely lie about being able to work in the language and can explain what and they would do, why, and how they respond to feedback. I expect people to be varying levels of nervous and that's fine. I work with people to get them focused and take the edge off as much as possible.
  What I ask for usually is related to what we need to implement, but a more basic chunk of it to, for example, show that the candidate understands concurrency and can use basics in the language to do something with that (which we do frequently).
  For many positions, we do not have homework and this is the only coding we get (kinda depends on role and project).
  As a newer company and still technically a start-up, the boss paying the bills can decide we need to chase something else and he isn't being talked out of it. This can lead to very fast collaborative design and coding of PoCs which can be more intense than the interview. I don't like it but it is what it is. Not everything we do is nice, stable, and long-term.
  I can relate to needing that job; I've been homeless, so I definitely kno the hat that pressure feels like and why nerves alone are never a deciding factor for me.