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

111–120 of 226 posts

Re: The problems with live coding interviews

#111

Post by arghnoname »

traverseda wrote: post #82
whoomp12342 wrote: post #81

If I do a live coding challenge, it is absurdly simple and is meant to root out people who have literally no business being in the room. Write a function that takes in a string and returns 1 if the amount of letters in the string is odd. It returns 0 if the amount of letters in the string is even. If you can do this, we are good. I dont need NP hard or whiteboarding or algorithms. I can tell how good you are just by…

I can never remember how modulus works, I use it so infrequently.

Sure, but you probably remember division.

"I can't remember of n % 2 returns 0 or 1 on even, so in place of that I wrote (if ((n/2)* 2 == n) for even, assuming integral division"

Re: The problems with live coding interviews

#112

Post by Freire_Herval »

addaon wrote: post #91
Freire_Herval wrote: post #90

Earlier quoted context omitted.

if you can mutate the graph and mark a node as traversed that's the easiest way. If you can't then save the addresses to a hash set. Both are extra memory but you don't have to deal with "parallel BFS," which honestly is just over complicated imo. With "parallel bfs" comparing "layers" of traversal has runtime cost that effects the big oh so I think the above solution is better overall even though it feels cheap.

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…

I forgot to mention, BFS requires a queue. So if the graph is size N and with one root node and all the rest of the nodes as children that queue will go up to size N. So your solution doesn't actually get away from the memory issue at all.

Re: The problems with live coding interviews

#113

Post by anongraddebt »

emodendroket wrote: post #74
jamesgill wrote: post #66

Earlier quoted context omitted.

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…

Well if I have two openings and five people what way do you think is more fair to choose among them?

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 the best or even second best candidate. If you are a regional telecommunications firm, and hire the 3rd best candidate, the 1st and 2nd candidates will likely get hired in unrelated firms or unrelated regions (especially in the remote work era). And even if this isn’t so, because most everyone is mediocre, the competitiveness of your firm won’t drop appreciably.

Re: The problems with live coding interviews

#114

Post by hnfong »

oceanplexian wrote: post #77
hnfong wrote: post #23

Earlier quoted context omitted.

As for the time limit, it's relative. All things equal , if you can complete the problem in 10 minutes and the company can hire somebody that can complete it in 9, then objectively the other candidate is the stronger one. As for nervousness for being forced to partaking in a stand-up performance, I'd argue that "social performance skills" can work against you, since the more "antisocial" you are, the more you can ign…

> All things equal, if you can complete the problem in 10 minutes and the company can hire somebody that can complete it in 9, then objectively the other candidate is the stronger one. They are stronger in the specific problem space you’re testing for. If your business has a lot of novel coding problems that need to be solved in under 9 minutes, then sure, this is a great measurement. On the other hand, if your busin…

> if your business has a lot of hard problems that take days, weeks, or quarters to solve

I suppose your ideal interview as an interviewer would be to give the candidate a take home task and ask them to spend 2 weeks to work on it?

> If anything it’s a counter signal

Or perhaps give the candidate a task that normally takes 30 minutes, and hire the candidate if they take 60 mins to finish it?

I mean, you do you, but I hope you (and everyone else) can see why I'm not convinced otherwise.

Re: The problems with live coding interviews

#115

Post by eesmith »

pjsg wrote: post #32
eesmith wrote: post #28

Earlier quoted context omitted.

One of the author's points is that the live coding questions are often the types of problems which, in the workplace, might best be done with GPT. "So at that point, do they want to see you muddle through it, or would they rather see that you know to have ChatGPT run through the initial pass and then refactor?" "If a company is evaluating engineers with questions that can be easily answered by AI in seconds, what are…

If a candidate said that they would use ChatGPT to answer the problem, then I'd start to talk to them about the legal issues surrounding that approach. What would they do if the hiring organization forbade the use of ChatGPT for anything? I would hope that all SWE candidates would understand software licensing to some extent and how to behave in a way that would not put the hiring organization in a legally risky posi…

Given your hope, shouldn't you be asking software licensing questions to every candidate? Irrespective of them mentioning ChatGPT? Otherwise, what happens if two months in they start using ChatGPT?

ChatGPT isn't the only legally risky software licensing issue.

A lot of people, including me, will use a search engine to find a solution to a given problem. That solution may be covered by copyright, and subject to a license which is not compatible with the company's business model. Some companies prohibit the use of GPL software. I consulted for one company which required authorization before using any open source software.

So it seems to me you should already be asking people about these sorts of issues.

Re: The problems with live coding interviews

#116

Post by Ancapistani »

I've been on both sides of live coding interviews multiple times. I generally agree with the author, but I don't think any of the issues he brings up are insurmountable.

When I'm the applicant, I make it a point to take control of the narrative by saying something like:

> If it's alright with you, I'd like to approach this as an opportunity to expose how I approach problems in general rather than how I'd solve this specific problem. I'll speak stream-of-consciousness as I go through it so you can get an idea of how I'm thinking about it. Feel free to ask questions if you'd like; I'll rely on you to decide whether it's more important to you that I complete the task or explain my reasoning. I'm happy to switch to pseudo-code or just discuss potential approaches if we run short on time.

When I'm the interviewer, I open with pretty much the same thing. My goal is to put the applicant at ease (to the extent that I can) and make it clear what I'm trying to get out of the session:

> First, let me say that it doesn't matter to me if you complete the exercise or not. At this stage of the interview process I'm confident that you're more than capable of solving the problem, so lets use this as an opportunity to get to know each other and see if the way we think about logic is compatible. I'd love it if you could point out things you'd change, but don't worry about trying to 'finish' or end up with production-ready code. It's just a means to an end.

Re: The problems with live coding interviews

#117

Post by hnfong »

kuhzaam wrote: post #57
hnfong wrote: post #23

Earlier quoted context omitted.

As for the time limit, it's relative. All things equal , if you can complete the problem in 10 minutes and the company can hire somebody that can complete it in 9, then objectively the other candidate is the stronger one. As for nervousness for being forced to partaking in a stand-up performance, I'd argue that "social performance skills" can work against you, since the more "antisocial" you are, the more you can ign…

What are the "all things equal" here, though? I would tend to disagree that someone who can complete the coding challenge faster is the objectively better candidate. Especially if we are talking about leet coding, where there are people who study their asses off and memorize the common leet code problems. Or maybe the coding challenge isn't leet code, but just so happens to be something that the candidate has done be…

You people are so bent on arguing the unarguable that the arguments are so unnecessarily argumentative.

The interviewer and the hiring company does not have a God's eye view of the candidate and must work within the limitations of the hiring process. The best one can do (without resorting to metaphysical processes) is to make a decision that has the highest expected value (or highest chance of hiring a good candidate).

The fact that there could be a candidate that lucked out because they were prepared for the specific set of questions you asked is not specific to live coding problems. You could have asked them anything and they could have lucked out and just happened to be prepared for the answer you were expecting.

That said, I can tell you for certain that if given a task that the average candidate takes 10 minutes, and a candidate completes it in half a day, you're looking at a 0.1x developer right there. That's by definition.

Re: The problems with live coding interviews

#118

Post by hnfong »

Retric wrote: post #42
hnfong wrote: post #23

Earlier quoted context omitted.

As for the time limit, it's relative. All things equal , if you can complete the problem in 10 minutes and the company can hire somebody that can complete it in 9, then objectively the other candidate is the stronger one. As for nervousness for being forced to partaking in a stand-up performance, I'd argue that "social performance skills" can work against you, since the more "antisocial" you are, the more you can ign…

Normal interviews are mostly a scripted performance where people largely regurgitate answers to predictable questions. So the issue isn’t that it’s a stand up performance it’s that you need to split your attention between the performance and solving some trivial problem. Becoming really good at programming requires being able to focus on an actually difficult problem not work through a simplified example while entert…

> Normal interviews are mostly a scripted performance where people largely regurgitate answers to predictable questions.

Ah, so you prefer being asked "where do you see yourself in 5 years?", and regurgitating the text generated by ChatGPT instead?

Alternatively, as I replied in the sibling thread, do you prefer to be handed a difficult take home task that is expected to take 2 weeks to complete?

I think I can live with the first, but I'd be insane to work 80 hours on a task just for a small chance to get a job.

Re: The problems with live coding interviews

#119

Post by Ancapistani »

Retric wrote: post #42
hnfong wrote: post #23

Earlier quoted context omitted.

As for the time limit, it's relative. All things equal , if you can complete the problem in 10 minutes and the company can hire somebody that can complete it in 9, then objectively the other candidate is the stronger one. As for nervousness for being forced to partaking in a stand-up performance, I'd argue that "social performance skills" can work against you, since the more "antisocial" you are, the more you can ign…

Normal interviews are mostly a scripted performance where people largely regurgitate answers to predictable questions. So the issue isn’t that it’s a stand up performance it’s that you need to split your attention between the performance and solving some trivial problem. Becoming really good at programming requires being able to focus on an actually difficult problem not work through a simplified example while entert…

> Becoming really good at programming requires being able to focus on an actually difficult problem not work through a simplified example while entertaining an audience

There are multiple ways to "become really good at programming".

A company of any size needs people who can churn through well-defined problems quickly, and most live coding tests are relatively well-suited to selecting for that. They also need people who do other things well:

* tackle large, ill-defined problems, alone or in a small team * identify, triage, and (if necessary) solve problems as they emerge * refactor existing implementations that have outgrown their initial architecture * identify trends and estimate when they will lead to scaling issues in the future * communicate complex problems to people without the necessary context * break down complex solutions into discrete, well-defined steps that can be tracked to completion

They also need people who can accurately estimate how long all of the above will take... unfortunately, as we all know, such people do not exist.

If you're hiring someone to churn through well-defined problems, live coding interviews are likely a good fit out of the box. If you're hiring someone to reinforce a weakness in your organization's ability to do any of the other things above, live coding exercises are at best a loose framework that we're all familiar with to try to get at whether or not they have those skills.

Re: The problems with live coding interviews

#120

Post by akvadrako »

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…

Take home tests are often paid and those are the only ones I will do anymore after being burned a few times.

That solves the skin in the game problem.

Post reply on HN