Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The problems with live coding interviews

garrettdimon.com

Post reply on HN
Print view View original

11–20 of 226 posts

Re: The problems with live coding interviews

#11

Post by decafninja »

kayo_20211030 wrote: post #2

Your experience sounds horrible, and unfortunately those sort of "tests" are just a horrible thing. Generally, do NOT do take-home exercises. That's your time, which has value; the company doing the hiring contributes nothing. At least, in a live-coding exercise both you and they have some skin in the game. As with all tests, good or bad, part of the test is actually doing the test. Often it's less what you know, or…

There's also the issue of scalability.

Grinding leetcode at least scales horizontally to a huge number of companies.

Homework is typically useless outside of the single company you're doing it for.

I generally refuse all takehome assignments unless:

1.) It sounds uniquely interesting and fun to do. 2.) The company is prestigious enough, or pays well enough, that making any effort to try to get the job worth it.

Re: The problems with live coding interviews

#12

Post by darth_avocado »

bennyelv wrote: post #7

A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…

> that is to be able to take a novel problem that they haven't seen before

But with platforms like leetcode and more, the candidates are split into those who have had the time to prepare (and see the problem before) and candidates who can’t put in that time. And most modern interview processes do not give you credit for thinking through it. You only get through if you solve it the right way, and fast. There is no time to “think and solve a novel problem you’ve never seen before”.

Re: The problems with live coding interviews

#13

Post by reidjs »

pavlov wrote: post #10
bennyelv wrote: post #7

A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…

> “take a novel problem that they haven't seen before and break it down” But who does that professionally as a stand-up performance, clock ticking, a judge breathing down your neck who has been equipped with a script that tells him things like “if candidate doesn’t do X within the first ten minutes it’s very bad”? Doing well in that situation depends more on social performance skills than problem-solving skills. You’…

That’s why he says this approach is more likely to produce false negatives than false positives

Re: The problems with live coding interviews

#14

Post by lucisferre »

This presents as a bit of an unintentional strawman against demonstrating any kind of coding during an interview process. Live coding, if earnestly used only as a filter, does not inherently need to focus on speed or performance. It doesn't have to be a hard "galaxy-brain" problem. It doesn't have to have any tricks to it. It can literally be a simple task that one would expect any working software developer to be able to complete without too much fuss.

Whether this is actually the case comes down to the hiring manager.

If the hiring manager decides to optimize for performance in the coding interview then yes everything said here is true. They will typically hire people who can perform well and fast at simple coding test type problems above other any other desirable attributes.

If however, they simply evaluate the ability to work through (at any reasonable pace) a fairly trivial coding task, but make the hiring decision on bulk of the rest of the interview, then it shouldn't be a problem.

The problem is most hiring managers have not been selected for their ability, or even trained, in interviewing. A coding test is easy to set up (or copy from somewhere), administer and evaluate. It is often literally the least they could do.

What this post describes is simply hiring managers who lack interviewing skills. Personally, I would probably want to avoid reporting to such a person.

Re: The problems with live coding interviews

#15

Post by [deleted] »

alpinelogic wrote: post #6

Very on point and I can truly relate to all of this. I'm so frustrated by the whole process that I've started to decline live coding interviews and any take-home exercises that take more than half a day to complete. Although I have over a decade experience in my field, have been a tech-lead at some of the largest corps, contributed to open source, mentored many Engineers, and really enjoy software, this whole experie…

[deleted]

Re: The problems with live coding interviews

#16

Post by Arainach »

Live coding interviews are the future. The risk of false impersonation was low enough for a while to rely solely on virtual screens, but widespread access to and awareness of large language models has made any virtual exercise unsustainably corrupted.

Sure, you can often tell the folks who know nothing when asking them to explain the code, but it's increasingly difficult to tell a great engineer apart from a mediocre one that's cheating, and once you start hiring cheaters the toxic effect to culture sets in fast.

Re: The problems with live coding interviews

#18

Post by codeflo »

bennyelv wrote: post #7

A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…

I’m also most often on the hiring side of this. If novel problem solving is what you’re actually testing, I would agree. But too many interviewers just think they’re testing that, when what they’re actually testing is whether a candidate has seen a certain memorizable trick before.

I’m talking about the “detect a cycle in a linked list” kind of question. If you ever actually need to do that in practice (though I would question the choices that lead up to that), it’s easy enough to google. The hard part in practice is figuring out that your messy practical problem decomposes into an algorithmic question, but that skill is rarely tested in interviews.

Re: The problems with live coding interviews

#19

Post by eesmith »

bennyelv wrote: post #7

A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…

> be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. ... A contrived live coding exercise gives you a strong signal on this

The author suggests take-home coding exercises with "maybe ... a live call to discuss their solution" as giving a stronger signal than a live coding exercise.

The author also suggested to "present them with a complex technical problem that requires architecture-level decisions across various parts of a technology stack, and have them talk through how they would approach it" as a better signal than a live coding interviews.

So even if what you say is true, you aren't presenting a devil's advocate position. Instead, it makes it seem like you think the alternative to live coding is no assessment, which the author very clearly argues is not true.

Re: The problems with live coding interviews

#20

Post by Gunax »

Tl;dr but this debate has been done, a million billion times already.

The author concludes with a decent summary of the issue (ie. Is this the best method among the worst?). But doesn't actually find a better way of doing things.

And in the million forum threads on this issue, no one else has either.

Post reply on HN