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

61–70 of 226 posts

Re: The problems with live coding interviews

#61

Post by kps »

codeflo wrote: post #18
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 woul…

Detecting a cycle in a directed graph is useful (in certain domains I've worked in), but doesn't have a cute trick answer.

[Edit: I in mind ‘Detecting the cycles’ rather than ‘Detecting a cycle’ but wrote the wrong thing. Mea culpa.]

Your actual job will be more like implementing a maximally performant directed graph in safe Rust. (Not really. It won't be that interesting.)

Re: The problems with live coding interviews

#62

Post by RoyGBivCap »

emodendroket wrote: post #51
sjducb wrote: post #5

Earlier quoted context omitted.

That's a great reason to do the take home test. You learn a huge amount about the team by how they react to your code.

Or they just evaluate among themselves and never tell you what they thought beyond thumbs up or thumbs down.

Or just completely drop the ball and never get back to you.

Re: The problems with live coding interviews

#63

Post by emodendroket »

ChrisLTD wrote: post #21
eyear wrote: post #17

Google, Facebook, Amazon use it for a reason. And they are top engineering companies. Period.

If their process for hiring was so spectacular, you'd think they'd have been a little more reluctant to do mass layoffs.

Why? They weren’t laying people off because they were bad at programming. And in fact they were likely hiring so aggressively in the first place in part to keep top engineers away from competitors.

Re: The problems with live coding interviews

#64

Post by michaelt »

ye-olde-sysrq wrote: post #30
rockbruno wrote: post #26

Everyone complains about the state of SWE interviews yet nobody seems to be able to come up with a legit better alternative. Even the author recognises this in the article. This format is popular because it's the best time/effort trade-off for both the company and the candidate. It's massively flawed, but everything else attempted so far turned out to be even worse.

How do other industries do this? Is programming weird because you can just ask someone to prove they know how to use a hammer? And so other industries just have to hire based on work history and/or bias "culture fit" during the interview? And they suffer terribly from people who can talk the talk but not walk the walk? Or is programming weird because there's so much propensity for people to be able to talk but not wa…

> How do other industries do this?

There's lots of other ways, but some of them suck.

Some fields attach a lot of weight to your alma mater, maybe they only hire people who studied law at Yale or Harvard.

Some fields require not just a degree, but also years of study under an industry veteran. Sometimes that also involves hazing like working 70-hour weeks, for some reason.

Some fields require work-sample tests where you show up at a given location and demonstrate your abilities on demand.

Some fields require not only a degree, but also years of working for free in order to break into paid work. And the paid work is far from guaranteed, that free work only pays off for 10% of people.

Some fields don't offer permanent employment, instead hiring people for much shorter periods - so bad hires can just not be rehired for the next project.

Re: The problems with live coding interviews

#65

Post by emodendroket »

decafninja wrote: post #55
emodendroket wrote: post #50

Earlier quoted context omitted.

Completely agreed. Also in my experience the takehomes are even more susceptible to being rejected for absolute bullshit reasons. Someone told me the thing I coded up in less than an hour to solve their problem was “overengineered” so they wouldn’t be moving forward.

Also... I think at 100% of the companies that have given me a homework assignment, it has always been in addition to, not in place of, a standard leetcode whiteboard round.

Same here. Though it’s hard to blame them since some people quite obviously didn’t do the takehomes themselves.

Re: The problems with live coding interviews

#66

Post by jamesgill »

emodendroket wrote: post #46
jamesgill wrote: post #36

The problem with live coding interviews is that they shouldn't exist. Another problem is that we're prone to thinking that being able to do well on tests equates to doing well in life and work--despite a stunning lack of evidence in support it.

So what do you propose? Picking names out of a hat?

We expect too much of 'interviews', so we've built an entire structure around them: 'behavioral' questions, whiteboard exercises, resume keyword scanners, long, tortuous lists of 'qualifications', elaborate processes of multiple interviews, etc.

After many years of sitting on both sides of the table, I've have come down to this: "hire lightly and fire lightly". In practice, this means beyond the (very) basics, hiring is not algorithmic; it's a crapshoot.

Re: The problems with live coding interviews

#67

Post by hnfong »

Gunax wrote: post #20

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.

Of course there are. I've hired a person once because I had known him 20 years ago and he knew his skills were top notch. (And to be clear, we haven't been in touch for many years since.)

But I don't know that many people. Properly conducted live coding is the least worst alternative out there for complete strangers.

Re: The problems with live coding interviews

#68

Post by adamc »

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 used to do this in interviews -- give people problems not because I cared whether they got "the" answer, but because it gives you a chance to see their brain work.

The problem with this is that many, many interviewers do this badly. They think they are looking for someone who gets the right answer. Or they are not good at assessing how other people break down and analyze problems.

It is artificial. All interviews are artificial. This is why everyone would prefer to hire candidates they already know a lot about. But a good interviewer isn't looking for a perfect performance.

Re: The problems with live coding interviews

#69

Post by commandlinefan »

goostavos wrote: post #43
commandlinefan wrote: post #35

Earlier quoted context omitted.

The point that's often overlooked by people who complain about any sort of interviewing process (this one being an example) is: somebody _does_ pass the interview, eventually, or they change the process. The poster here seems to be suggesting that live coding is an impossible hurdle that nobody can overcome, but that's obviously not true - people overcome it and get hired all the time. I've auditioned as a musician i…

>hey just went with somebody better Yeaaaaah, that's not how any of this works. I've done 100+ interviews for MegaCorp. Who ultimately gets hired is ultimately a dice roll no matter how "data driven" we call it. Did you get a good loop? Was one of your interviewers in a bad mood? Did you end up with a hiring manager who "used to code" and now measures everyone against whether or not they use out dated OOP techniques…

> Who ultimately gets hired is ultimately a dice roll

Well, I'm not sure I believe that's universally true (or even particularly common) but even if you're right, what difference does it make? You still have to be good enough not to bomb the interview but then just "hit the tables" often enough to get a lucky roll. That would be the case for any sort of interview process, whether it was live coding, an informal discussion, or tests of strength.

Re: The problems with live coding interviews

#70

Post by kps »

ChrisLTD wrote: post #21
eyear wrote: post #17

Google, Facebook, Amazon use it for a reason. And they are top engineering companies. Period.

If their process for hiring was so spectacular, you'd think they'd have been a little more reluctant to do mass layoffs.

The process for hiring senior management is different!
Post reply on HN