Live coding interviews measure stress, not coding skills

I'm now a successful, self-employed indie developer. One of the main reasons I stuck with indie development through the hard times—the maxim that it takes 5 years to become an overnight success was true for me—was that I became practically unhireable. There are multiple strikes against me: I'm middle age in an industry rife with age discrimination, I don't have a computer science degree, and I experience brain freeze during live coding interviews.

I would note that not all stress is the same. Firefighters rush into burning buildings for a living, and what could be more stressful, yet many of them would panic at the idea of giving a speech to a non-burning roomful of strangers. I have no problem with stress on the job, and I've successfully navigated many work emergencies during my career, but something about strangers standing over my shoulder judging me, determining my financial future by providing or withholding a job, like the sword of Damocles, turns my stomach inside out. And like the article author, I can revisit the coding problems and solve them afterward, as soon as the interview is over. Interviewers must think I'm a fraud who can't code, yet all evidence from my career, now almost 2 decades long, suggests otherwise.

A lot of commenters causally speak of "false negatives" as if they were random, but some people, myself included, are always the false negative. I am consistently filtered out by audition-style interviews. I'm not a stage performer.

I’ve worked in the assessment space for 6 years and have seen many hiring processes, from Fortune 10 companies to startups hiring their first engineers. The range of signal required, "how much time can my engineering team spend with a candidate", and how much candidate experience you can get away with, is huge. I’ve also been a candidate myself and failed many live coding interviews. It made me feel terrible about myself. The last time for a role at Ycombinator (the interviewer was super nice).

When I work on my product, I try to view it through the lens of empowering candidates to show their skills and potential. I encourage our customers to use assessments that somewhat resemble on-the-job skills. I don’t like the phrasing “real work” anymore. An assessment shouldn’t be unpaid labor, it should be a way for candidates to demonstrate that they can do the job and handle future work thrown at them, and for hiring managers to feel confident extending what are often very high salaries in tech.

With AI, unfortunately, short take-homes (what I prefer as a candidate, using my own tools and editor) are becoming harder to maintain as a fair signal due to AI assistance. I’ve seen companies move back to onsite, and competitors deploy all kinds of proctoring and invasive monitoring.

The perfect solution, in my view, would be an assessment where the candidate feels relaxed and able to perform at their best, with their own editor and configuration, knowing that every other candidate in the pool has the same constraints in terms of time and tooling. It’s a tough problem to solve. I think about it daily and have not come up with a solution.

Yes, there's a large cohort of "senior" software engineers who can't actually code. They bullshit their way into jobs until they're fired and then apply for the next one. These are the people you want to filter out with live coding.

But also, someone can fail a live coding interview for reasons other than belonging to that group.

I wrote about this here: https://acjay.com/2023/11/12/everything-all-at-once-inside-a...

There are certainly jobs where you need someone who is cool under intense pressure, where what happens inside an hour matters. That's what these interviews are revealing. But I think this is a tiny minority of dev jobs.

However, I also think when people talk about hiring practices, the elephant in the room is that the true purpose our interview processes have evolved to serve is taking the candidate pool from a lot of people to something that is decidable. We can't fully evaluate 500 candidates, but we can evaluate 5. The process of weeding out 99% is designed to be inexpensive, at the cost of accuracy. The hope is that you'll have one person squeeze through the filters that is a good fit. If that happens, then all the false negatives are tolerable.

But we really, really don't like to admit this. We tell ourselves that we are running interview processes that are predictive of performance when there is actually very little evidence to support that, and plenty of reason to doubt that it's true.

If quality were paramount, I think we'd do hiring completely differently: https://acjay.com/2019/05/16/hiring-developers-is-easy/

Let's say you need someone who can lift 10 kilograms:

- Good interview: "Please lift this 10 kilogram bucket by the handle."

- Not Good interview: "As a proxy for your overall strength, please take off your pants, squat, pick up this 1 kg bucket by clenching the handle with your butt cheeks, and then stand. We know this isn't a real test of your strength, but we want to see how you perform under pressure."

I once went to a job interview with Google. I built one of the first local (Global to the Netherlands) search engines of the Netherlands, but the guy in the cowboy hat at Google asked me to write a binary search with a marker and a whiteboard. I never write with my hand, I always use keyboards. Plus I'm being insulted to write a binary search when I designed and build a search index and retrieval engine.

[I did the binary search but was not happy with the whole process that did not want to even look at what you had actually done before, because that would take away the baseline they wanted].

I guess they must have been looking for cowboys. Tip for interviews, take your cowboy hat, just in case..

Younger engineers trying to find jobs in the industry should consider how much the other parts of the hiring process privilege older engineers regardless of ability. I'm sure many of the people I worked with who lacked basic coding competence twenty years ago still lack competence and are employed right now in jobs that require it, jobs that could go to younger, more capable people except that their resume, their experience, and their ability to say the right-sounding thing don't match up.

Hiring someone to write code without ever seeing them do it is like hiring a guitar player for a band by verifying their MFA in music theory, talking to them about music for an hour, and checking their references. All that is fine, but can they play the guitar? You can acquire everything else, the lingo, the knowledge of music theory, the pros and cons of competing techniques, the familiarity with current and past great performers and performances, without ever putting your hands on the instrument. And some people are built like that. Some people are guitar connoisseurs: they gave up their hopes of playing the instrument long ago, but they're huge fans and nerd out over the art and science of it. If those folks needed to be in a band to have health insurance, and they didn't have to audition, you can bet some of them could talk their way into it.

Finally, when a team interviews someone for a position that requires writing code, they are inevitably making a judgment about whether they think they can do it. If you ask someone to guess without any direct evidence, you're inviting them, almost forcing them, to fill the gap with bias. Do they collect subtle little hints and make fragile deductions like they're Sherlock Holmes? Do they trust their instincts about whether the person in front of them looks and acts like the kind of person who could code? Either one is guaranteed to be rife with bias and problematic preconceptions.

Why?

Purely being a "good programmer" isn't just enough for the job. It's important that we can develop a good working rapport, and communicate.

For example: Someone who's an expert programmer might misinterpret a discussion and build the wrong thing; or someone might be a great programmer but otherwise be impossible to actually conduct a technical discussion.

IE, this is why "Fizzbuz"-style questions work so well: It's not really screening that you're a great programmer, it's screening your ability to have a technical discussion.

I was interested by the author's statement: "Working memory is the most reliable proxy (I know of) for fluid intelligence, your ability to reason, solve novel problems, and think abstractly." and the linked study (https://pubmed.ncbi.nlm.nih.gov/21037165/). My working memory is not so great, but it degrades less under stress.

Question worth considering for hiring managers: do you prefer stress-capable employees, or greater working-memory employees? Is my model a false dichotomy?

There was one company whose process I really appreciated:

- A take-home test, more of a puzzle-style challenge. - The interviewer does a quick review of your submission. - If they like what they see, you're invited to a follow-up session where you explain your code and make a few simple changes to it.

This approach proves that the work is genuinely yours, shows your thought process, and still gives the opportunity to demonstrate live coding on code you're already familiar with.

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".

Now, that doesn't mean that stress management cannot be part of the job: I've worked in the hellish places where an on-call rotation meant at least 4 calls off-hours, and some which needed resolutions in 10 minutes or less from the pagerduty call. Someone with bad stress response is not going to be doing great at that kind of live diagnosing, with possibly many millions for the company on the line. But the number of positions like that, where you are a cross between a developer and an ER doctor are much less common than places that have none of those demands, yet give you a series of leetcode mediums and hards. They might as well be testing for height, or how much you can bench press. It filters, but it does not help.

Yes, we can. Don't do them. But, we have to replace them with something that works. That means none of these poorly constructed take home projects that are almost universally either drastically over scoped, criminally under specified, or both.

- Past: ~8 years in big tech as an IC - Currently: ~4 as CTO a < 10 person startup.

I always hated doing and conducting coding interviews. When I became in charge of the interview process, I swore to myself not to have them.

I had to let go of a person after ~3 weeks in because he just didn't write any code. This was about 1 year post the ChatGPT moment.

He had lots of experience. Great communicator. Culture fit (or so I thought). Etc...

Interviews can provide a signal, but nothing trumps a month of working with someone. If both parties are open to it, a well paid short term contracting gig goes a long way.

Did y'all not have to take a load of exams in high school and college?

I'm sure there are variations between education systems, but by the time I graduated college I'd done at least a hundred high-stakes, time-pressured hour long written tests. All of them substantially more difficult than summing the even entries in a list.

Is this not what everyone experiences, in every education system?

This is something that someone familiar with a language should be able to do as naturally as answering "tell me about yourself" or some other non-coding question. (Personally, way more naturally, nothing makes me more uncomfortable than "tell me about yourself")

I agree that for something more involved, nerves can become more of a factor, certainly any "trick" question, but these seem more like just checking if whatever language is second nature, which it should be, not about algorithms etc.

I won't use live coding questions (usually) because I don't see much value in trying to code under that much stress.

But I will ask hard questions to see how well a candidate communicates in a stressful situation (which I think is a far more valuable indicator of their brain's "default" mode in stress). I want a candidate that talks honestly about stuff -- especially the stuff they don't understand -- even in a stressful situation. Sometimes stress can bring out the asshole in somebody -- and that's an immediate red flag.

Which is funnily something opensource doesn't suffer from. You just have to prove identity to the commits you signed in previous contributions, so the problem of proving technical skills in the opensource community is replaced by the effort of building trust.

The answer therefore could be to replace technical interviews by sending out assignments to candidates to have them contribute to opensource and come back with results. This has the upside for candidates that if multiple companies do such assignments they only have to contribute once to be eligible for multiple hiring processes.

Everybody wins.

For example, for the senior frontend engineer, I think we went with "create a real-time comments panel using SSE that works in multiple browser tabs", and created a ready-made git repository with a dev server that includes the SSE endpoint. That way, they only had to focus on the actual task.

Now I thought that was nice because it should be very easy to solve for someone with a bit experience, but we get lots of opportunities to discuss their choices and the technology. It's hard to confidently bullshit an answer to if you think server-sent events or web sockets are superior, and why. So from everything we tried so far, this format gave me the most accurate impression of someone yet.

What's the alternative? Take home problems come with their own problems, and select for people with no family and lots of time. Going by general vibe alone also works, kind of. But we're going to work together, so having something that at least faintly resembles work is kind of useful.

The leetcode type problems are useless however, fully agree on that. But a trivial loop with conditional, perhaps iterating over a list of lines shouldn't be that bad, especially if you get help with the syntax.

Being a senior engineer means having confronted a shitload of different minutia type problems from network stuff, compiler bugs, language nuances, threading nuances, etc. and having spent time figuring each one out. Not that senior engineers can reiterate all that minutia off the top of their head, but it gives them a good intuition for how to solve problems when they hit them making them significantly more productive than junior devs that have to figure them out from scratch.

I don't understand what's so hard about this, testing algorithmic knowledge tests if the individual studies and implements algorithms. It's very simple. And yes, people have stress reactions in test type settings (I don't for paper tests in school but apparently I do for live coding mostly because I don't know how to implement different algs).

Stress during interviews is insane. Once I was at the tail end of solving an interview problem but it came down to multiplying 9 * 3 and my brain wouldn't fucking do it (apparently I can't fucking multiply).

Thing is, I reckon those candidates aren't a good fit anyways. The biggest mistake I see engineers who join startups make is that they pursue excessively sophisticated solutions, with robustness that does not justify the added complexity. I'm sure these candidates are smart, but they're not good fits for the high-velocity, simplicity-obsessed technical environment of a product-play startup.

At least reading this post has helped me regain some of that lost self-esteem. Thanks for sharing it. <3

That said, does anyone have a good alternative? If somebody has open-source work and portfolios, there's a great window into their work, but that's probably an unfair expectation.

a related thing here is that I've long believed that remote work positively impacted my career for precisely this reason.

It's not a puzzle, it's not a trick question. It's simply a matter of 1) can you do the job and 2) do you get along with the team.

The last interview I did, we had the candidate build a game of marbles in Unity. None of us knew the rules, so it turned into a collaborative process between the candidate and our engineers. We learned that the candidate can think on his feet and fluently adapt his program to requirements as they manifest. Plus it was just a lot of fun. He was one of our best hires, too.

Who are these self-important employers?? I mean, outside of Ops and live incident response, are there really that many software engineer roles that require someone to perform well under pressure? It seems a false and egotistic narrative. If you need a software builder to perform under pressure then you've got systemic issues of a type not solved with software. You need better management or better work practices.

Should it be that way? No. Was it that way? Yes.

To date, I've never gone on to regret hiring someone who blitzed the in person coding exercise.

2 years ago given a coding assessment "Roman Numeral Conversion". Was given a set of test cases. I got near the solution. I think if I had another 5-10 minutes I would have solved it fine. Sat down that evening with the same test cases and did it from scratch in 20 minutes.

5 years ago, I didn't get a job because I while I did well technically. The reason for the rejection was that I appeared "stressed" while being assessed. What do they expect?

10 years ago. I walked out of an interview essentially after about 10 minutes. The interviewer(s) interrupted me the moment I started writing any code, constantly interrupting my train of thought. I think it was intentionally done to irritate me. I've had companies play these stupid games in interviews before.

Most people, even the good ones, show a little hesitance when starting. Which isn't really necessary, most people do fine. I'm not trying to get them to fail, I'm trying to get them to succeed. I want to see if they're smart and understand the problem and the direction of a solution. Not if they miss any semicolons or don't recall some arcane data structure.

She was one of the best hires I made. Coding interviews can also measure attitude and confidence.

I didn’t need the job that bad.

I’ve worked on one man projects that were hard realtime C image analysis (Fourier, calc, stats), large data science eval projects, devops stuff. CS degree and used it for published research.

I also had a five rounds of interviews a MANGA corp. Didn’t bother with the second because I didn’t have two months to waste.

Went hired gun and never looked back. Homey network uber alles, I make 10% less but I call all the shots, and am way healthier.

It will probably get worse before it gets better out there, between RTO and whatever LinkedIn is doing to CEOs.

Except humans can do well at live coding. Especially for trivial cases like the start of the article (sum . filter even). Yes, companies are looking to hire humans as opposed to ChatGPT, but they are looking to hire a subset of humans. Just being human is not good enough. Failing this test might not provide a reliable signal, but passing it does. If you are getting stressed over simple question or existing stress is impairing your thinking enough to not answer simple questions that seems like an issue to me.

A good employer takes care of their worker even if they have problems, but they also want to weed out as much of them before hiring. The value of worker is not revealed when they are at their best. Fragile workers with anxiety perform well only small amount of time.

Live interviews are generally excellent at revealing how individuals perform when placed outside their comfort zone. If you perform well in a live interview, be it for coding or any other skill, you are likely to perform even better reality.