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

171–180 of 226 posts

Re: The problems with live coding interviews

#171

Post by Freire_Herval »

beerpls wrote: post #164
Freire_Herval wrote: post #94

Earlier quoted context omitted.

Here's the problem. If the company offers you 600k salary then the dance is now worth it. The other problem is after lay offs, if all companies ask you to dance then you have no choice. Dance or stay unemployed. Obviously nobody wants to "dance" and nobody would if they had the choice.

So the only thing you can say in response is giving excuses why people must dance? Sometimes you’re desperate and will do things you otherwise wouldn’t. That isn’t and should be thought of as the norm

People don't have to dance. Incentive to dance is very strong though.

Here's the thing, when you look at the behavior of large groups of people the overall incentive is the overall outcome. As an individual you can resist but groups act predictably and follow straightforward patterns.

Think of it like drugs. You going to tell people to stop doing heroin and end the problem forever? No. You gonna tell people to stop dancing and end the problem forever? No.

The only thing that will bend the industry in favor of your idea is software unions. Centralized control can influence individuals to act in cohesion. Without leadership the short term incentive wins.

Re: The problems with live coding interviews

#172

Post by Freire_Herval »

Freire_Herval wrote: post #108
addaon wrote: post #91

Earlier quoted context omitted.

But the whole point of the "cute solution" is to solve with O(1) memory; if you're willing to allow O(n) then the linked list also admits more sane solutions. I'm not sure what you mean by comparing "layers" of traversal. Tortoise and hare is about provide a termination condition in the case that a cycle exists. In the case that there's no cycle, every algorithm must inspect each node, so is O(n). In both the linked…

> But the whole point of the "cute solution" is to solve with O(1) memory; if you're willing to allow O(n) then the linked list also admits more sane solutions. Yeah but the "parallel BFS" solution is actually slower. Overall people sacrifice memory for speed in these algorithm problems. Additionally the input is already O(N) so if you count the input as memory the addition of O(2N) doesn't shift it. If you don't cou…

There's an error in my calculations. Apologies.

The comparison happens at every level and NOT every node so, it's O(N) for traversal then when a layer is completed a comparison occurs at a cost of O(N^2). The amount of times this happens is equal to the height of the tree which can be simplified to logN. So total big O is O(N) + O(N^2 * log2(N)).

This simplifies to O(N^2 * log2(N)) which, while better than O(N^3), is still really bad.

Re: The problems with live coding interviews

#173

Post by throwaway5959 »

jvanderbot wrote: post #153
pavlov wrote: post #10

Earlier quoted context omitted.

> “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’…

Given two candidates who can break down problems, I'd prefer to hire the one who can do it with a gun to their head (metaphorically, of course). Lord knows owners, ceos, board members, managers, and angry co workers would often enough like to put a gun to my head.

I’d suggest not working for people who like to put a gun to your head, euphemism or not.

Re: The problems with live coding interviews

#174

Post by 8note »

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…

The most fun interview question I've answered is "list as many unique ways as you can to detect a cycle in a linked list"

Re: The problems with live coding interviews

#175

Post by 8note »

ravenstine wrote: post #162
throwaway675309 wrote: post #158

Earlier quoted context omitted.

I think we're going to see a pretty large industry shift away from take-home tests given how easily 90% of these tests can be gamed using chat GPT.

I'd think we'd have already seen this with GitHub Copilot. There was an interview I was part of late last year where the candidate had Copilot turned on during the live coding, and he didn't turn it off even after it was obvious that's what he was using. What I was more surprised by is how I thought this was a bigger deal than everyone else. Like, why come up with these elaborate tests when the candidate is just goin…

If they are effective at using it to solve problems, why not?

The real challenge is to your testing mechanism and not the candidate

Re: The problems with live coding interviews

#176

Post by 8note »

emodendroket wrote: post #131
anongraddebt wrote: post #113

Earlier quoted context omitted.

On average, any random company will be filled with solidly average engineers. Which means, because of how numbers work, most of the engineers are neither good nor bad at engineering. They’re just mediocre. Companies need to realize this and come to grips with it. Additionally, this holds as well for the following: beyond a certain skill threshold, a company will not really be any less competitive by failing to hire t…

OK. How does this answer my question, since presumably I would still want to identify at least the mediocrities rather than the complete jokers who have nothing to contribute?

Get them all to roll three 6-sided dice, and pick the one with the largest sum

Re: The problems with live coding interviews

#177

Post by frumper »

viraptor wrote: post #168
frumper wrote: post #163

Earlier quoted context omitted.

When you say make it up on the spot, I'm hearing they can answer questions when you ask. If you ask them to describe how they'd process input and send it to a database they can just as easily tell you what they generally do. If they don't mention any of the things you're looking for, then you have your answer. If they answer some then you can decide to probe about what's missing, or thank them for their time. You hav…

> When you say make it up on the spot, I'm hearing they can answer questions when you ask. Or they have enough surface knowledge to risk an answer that could potentially work. It depends if that's the threshold acceptable to you. > You haven't explained why a take home test is needed for that. We're commenting on the blog post about this very question. Making the initial stage of this test take-home is at least parti…

It sounds like we're now back to mind reading the answer you'd like them to provide based on overly broad questions. That is a poor way to assess whether they know about a topic. Ask them what you'd like to know. You don't have a relationship with them and they aren't familiar with your version of "normal" or "mature" processes.

Re: The problems with live coding interviews

#178

Post by 908B64B197 »

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’…

> If someone says “I’d like to start by taking ten minutes alone in another room and think it out first”, will they get hired? Probably not. It’s not the expected performance even if the solution is fine.

When interviewing I always start with a discussion about the problem. On the whiteboard. I'm explicit with the candidate that this is totally expected.

I'm actually measuring something perhaps more important than the code that will get written later: can this person formulate a plan and have a technical discussion.

Re: The problems with live coding interviews

#179

Post by 8note »

beerpls wrote: post #164
Freire_Herval wrote: post #94

Earlier quoted context omitted.

Here's the problem. If the company offers you 600k salary then the dance is now worth it. The other problem is after lay offs, if all companies ask you to dance then you have no choice. Dance or stay unemployed. Obviously nobody wants to "dance" and nobody would if they had the choice.

So the only thing you can say in response is giving excuses why people must dance? Sometimes you’re desperate and will do things you otherwise wouldn’t. That isn’t and should be thought of as the norm

It's a negotiating term. Ask for more to dance

Re: The problems with live coding interviews

#180

Post by 8note »

jkaving wrote: post #100
RoyGBivCap wrote: post #60

I think reviewing code is a much better method. It's a real skill you'll actually employ. You're coming at the code cold, which is actually a realistic scenario you'll encounter on the job. Your ability to catch bad ideas and prevent them from getting literally codified is a valuable skill. And all of that is worthless if you're in a state where you can see a mistake, but are too afraid to speak up; this gets tested…

I agree, and this is what we have been doing for a while at my current job (I went through the same process, so it's been done for at least 7 years). The candidate would come to the office (when we were still doing in-person interviews) and meet a couple of the developers for a little bit of chatting. They would then be given a couple of printed pages of Java code with a few basic classes representing banking account…

Using whatever tools would be handy.

Throwing it through find bugs is always a good option, and should find something

Post reply on HN