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

121–130 of 226 posts

Re: The problems with live coding interviews

#121

Post by hnfong »

tomjakubowski wrote: post #76
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…

a single example of a one minute difference in solving a problem that takes ~10 minutes is noise

Yes, so given that all things are equal, are you going to hire the slower person then?

Or are you going to, as I mentioned in sibling comments, give them a take home task that takes two weeks to complete, just to be sure?

Re: The problems with live coding interviews

#122

Post by Ancapistani »

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'd argue the point of the exercise isn't to implement an O(1) solution, but to verify that the applicant understands how the logic they're writing actually executes, and is capable of minimizing complexity.

Whether they arrive at an O(1) solution doesn't matter a bit to me. Most of the time, I don't even care if they phrase it in big-O notation - or have even heard the term!

Given the choice between someone who completed the exercise with an O(1) solution in half the allotted time and someone who never wrote a single line of valid code, I'll choose the person who is able to articulate the problem and potential solutions best every time.

It's far easier to search the web and find a "cute solution" than it is to learn how to think about and communicate complexity.

Re: The problems with live coding interviews

#123

Post by hnfong »

Ancapistani wrote: post #119
Retric wrote: post #42

Earlier quoted context omitted.

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…

I'd even argue it's a prerequisite.

If one doesn't even know how to complete well-defined tasks reasonably quickly, I can't imagine how they would be able to break down complex tasks to these smaller, well-defined tasks, and accurately estimate the expected effort needed.

This sounds almost Dilbert-esque. It seems like a lot of people here want to be a pointy-haired boss (or pointy-haired tech lead)!

Re: The problems with live coding interviews

#124

Post by hnfong »

robin_reala wrote: post #37
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…

They’re only objectively the strong candidate if that’s the sole thing the company values. It’s unusual for that to be the case.

With the "all things equal" qualifier, it's sufficient that completing the task faster is a positive signal rather than a negative one.

I mean, this is very elementary.

Re: The problems with live coding interviews

#125

Post by hnfong »

crooked-v wrote: post #75
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…

> then objectively the other candidate is the stronger one ...if the job is to complete abstract problems in live coding interviews, sure.

By your logic, there's no point in doing any interviews at all, because it is nobody's job exactly to sit as a candidate in an interview session.

Is that your point? Because I'm getting tired repeating the point about take home tasks in the sibling comments by now.

Re: The problems with live coding interviews

#126

Post by robomartin »

Software development is not a performance art (like playing the piano). Putting someone in that kind of a situation is, well, sorry, as dumb as can be.

What's important is how people approach computational problem solving, not if they can write a solution in 1 to 45 minutes. Really, who cares?

One of my go-to examples is trying to work from home. Which is great, yet has its challenges. We have three German Shepherds. They are lovely. However, when a delivery arrives or the gardeners are out nearby, well, it's mayhem for a few minutes. I've come to understand that I should just take a coffee break when that happens. I can't even do mid-level math, much less focus on a difficult CS problem during those moments. And it takes a good 30 minutes before my head can be back on task.

Stop treating software development like performing art or athletes having to perform in the heat of a game. That is not what we do. At all.

Re: The problems with live coding interviews

#127

Post by eesmith »

emodendroket wrote: post #97
eesmith wrote: post #93

Earlier quoted context omitted.

I'm pretty sure I heard the same point made 20 years ago against using IDEs, with their auto-complete and tool-tips and style feedback. And 40 years ago in the debate over letting kids use a calculator in school instead of calculating by hand. A footballer follows a very constrained set of rules. If the footballer were allowed to use a car then 1) it would be easy to score a point, 2) the field would be ruined, and 3…

We’re not talking about whether you should use them at work; we’re talking about whether it makes sense to have an evaluation where you don’t use them. Closed-book exams are similar. There’s no real-world situation where you wouldn’t be allowed to refer to whatever materials you like, but the evaluation uses somewhat unnatural circumstances to gauge how well you’ve assimilated the material in a limited amount of time…

"It makes sense" leads us back to the linked-to essay, which argues that live coding a solution to "arbitrary and unrelated topics like creating a script to handle scores for bowling or something equally irrelevant" do not make sense as a way to

If the evaluation doesn't make sense, then the conditions placed on the evaluation don't really matter.

Similarly, "assimilated the material" only makes sense if the live coding interview really does cover "the material". To use your analogy, measuring a football prospect’s cycling times aren't that good of a test of football playing skills. I mean, yes, there's some overlap, but there are more useful ways.

And one of the example tests was "handle scores for bowling", which is far from most work-related issues.

"consistent process that’s fair for everyone."

The author addressed this idea at several points, including "Any belief that a live coding interview is a consistently reliable way to make an objective assessment represents willful ignorance at best."

Picking a name out of a hat containing potential employee names is also consistent and fair.

Just because it's easy to measure doesn't mean it's an effective predictor.

Re: The problems with live coding interviews

#128

Post by spacemanspiff01 »

hnfong wrote: post #114
oceanplexian wrote: post #77

Earlier quoted context omitted.

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

If they pay me at contract rates double my current salary, and in my particular case my current IP assignment clause/the problem/ law makes it ok. Sure, pay me money to do something like what you guys need done.

Probably most useful if it's a contribution to open source.

Re: The problems with live coding interviews

#129

Post by emodendroket »

eesmith wrote: post #127
emodendroket wrote: post #97

Earlier quoted context omitted.

We’re not talking about whether you should use them at work; we’re talking about whether it makes sense to have an evaluation where you don’t use them. Closed-book exams are similar. There’s no real-world situation where you wouldn’t be allowed to refer to whatever materials you like, but the evaluation uses somewhat unnatural circumstances to gauge how well you’ve assimilated the material in a limited amount of time…

"It makes sense" leads us back to the linked-to essay, which argues that live coding a solution to "arbitrary and unrelated topics like creating a script to handle scores for bowling or something equally irrelevant" do not make sense as a way to If the evaluation doesn't make sense, then the conditions placed on the evaluation don't really matter. Similarly, "assimilated the material" only makes sense if the live cod…

I suppose I fundamentally do not agree that the skills are unrelated. I think they are the same skills, but applied to a much smaller problem that fits in 45 minutes. The author does not make any case that the smorgasbord of alternatives he offers are any better. And none of this has to do with your “well I can just Google a well-known problem like this in real life so it doesn’t matter” argument.

Re: The problems with live coding interviews

#130

Post by Retric »

hnfong wrote: post #123
Ancapistani wrote: post #119

Earlier quoted context omitted.

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

I'd even argue it's a prerequisite. If one doesn't even know how to complete well-defined tasks reasonably quickly, I can't imagine how they would be able to break down complex tasks to these smaller, well-defined tasks, and accurately estimate the expected effort needed. This sounds almost Dilbert-esque. It seems like a lot of people here want to be a pointy-haired boss (or pointy-haired tech lead)!

Coming up with your own tasks means understanding the problem implicitly. Solving other peoples trivial problems means searching for the interviewer’s hidden gotchas and unspoken requirements.

Ie if someone asks you to find the median value of an array the number of elements and how to handle nulls isn’t obvious, but when you want the median value in an array the context is clear.

Post reply on HN