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

71–80 of 226 posts

Re: The problems with live coding interviews

#71

Post by kps »

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…

That could be interesting. I had a co-worker (at a different company, while on an open-source project) whom I highly respected because of his excellent code reviews. I think it would have to be done with an established build chain (e.g. formatters, linters, CI) so as not to degenerate into trivia and bikeshedding. I think it would be most interesting (assuming a good interviewer) if the approach under review were actually somewhat defensible.

Re: The problems with live coding interviews

#72

Post by flimsypremise »

I keep seeing people claim that no one offers alternatives to live coding in interviews, but not only does the author provide an alternative (take home coding test/project), there are obviously many alternatives to live coding. I've been working in this industry for over two decades, and I've interviewed more candidates than I can count. I can assess a candidate with a 20 minute conversation, because a candidate's understanding of the context and theory of how and why things are done the way they are determine how good they are at the job. Ask them what happens when you visit a website. The amount of detail they go into, and what details they focus on, will tell you an enormous amount about them. Ask them whether they prefer an OO or functional approach to organizing code. The good candidates will have thorough, well-thought out opinions, and you're handing the bad candidates enough rope to hang themselves.

Of course, in order to be able to assess the answers to these questions in an effective way, you need to be able to very knowledgeable yourself, and that's the real root of the problem here.

Re: The problems with live coding interviews

#73

Post by whynotminot »

decafninja wrote: post #11
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.

Why would you be interviewing at all if the criteria for (2) isn’t met? Unless you’re just trying to get interview practice or keeping them as a safety option.

Re: The problems with live coding interviews

#74

Post by emodendroket »

jamesgill wrote: post #66
emodendroket wrote: post #46

Earlier quoted context omitted.

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…

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

Re: The problems with live coding interviews

#75

Post by crooked-v »

hnfong wrote: post #23
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’…

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.

Re: The problems with live coding interviews

#76

Post by tomjakubowski »

hnfong wrote: post #23
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’…

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

Re: The problems with live coding interviews

#77

Post by oceanplexian »

hnfong wrote: post #23
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’…

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 business has a lot of hard problems that take days, weeks, or quarters to solve, measuring someone’s ability to solve a 9 minute problem is a terrible metric. If anything it’s a counter signal, since it tends to select for candidates that optimize short term thinking over long term planning and problem solving.

Re: The problems with live coding interviews

#79

Post by addaon »

kps wrote: post #61
codeflo wrote: post #18

Earlier quoted context omitted.

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.)

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

Doesn't the standard cute trick answer for a linked list (tortoise and hare) work fine? Do two parallel breadth-first traversals of the graph starting at the root node, one at twice the speed of the other. (If there's multiple root nodes, introduce a unique super-root that points to the roots.) If there's at least one cyclic path, both iterations will enter the same cyclic path because iteration order is the same, at which point it reduces to the linked list problem.

Re: The problems with live coding interviews

#80

Post by yobbo »

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…

A fair point; the only reason the questions are asked is because they have known answers. And unless the questions are trivial, their answers are essentially little tricks. Some candidates have already seen the answer, others have not.

But, testing if the candidate has seen a problem before may be a proxy for something meaningful.

Post reply on HN