The problems with live coding interviews • Hacker News Board

Re: The problems with live coding interviews

#41

Post by viraptor » Tue, Apr 25, 2023, 4:26 PM UTC

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…

> Often it's less what you know, or could do; and more about "can you do the test?"

It really depends on how you create the test and how you review it. You can prepare one where the actual solution is 10 lines of code and anything else is exactly for showing what the candidate knows / could do.

I used something like "read data from CSV, write it to sqlite, treat it like a mature production app, feel free to use placeholders (usage doc goes here), go nuts". Then the test was really about knowing about error recovery, encoding issues, documentation, error reporting, monitoring, ci pipelines, etc. Many badly organised tests don't make the whole concept of a take home test bad.

Re: The problems with live coding interviews

#42

Post by Retric » Tue, Apr 25, 2023, 4:27 PM UTC

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…

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 entertaining an audience.

There might be a correlation between solving trivial problems quickly and being able to figure out a heisenbug from some multithreaded monstrosity, but it’s not strong enough for minor differences in performance to be meaningful.

Re: The problems with live coding interviews

#43

Post by goostavos » Tue, Apr 25, 2023, 4:29 PM UTC

commandlinefan wrote: post #35

lucisferre wrote: post #14

This presents as a bit of an unintentional strawman against demonstrating any kind of coding during an interview process. Live coding, if earnestly used only as a filter, does not inherently need to focus on speed or performance. It doesn't have to be a hard "galaxy-brain" problem. It doesn't have to have any tricks to it. It can literally be a simple task that one would expect any working software developer to be ab…

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 everywhere? Ah crap, did you get Gary? That guy sucks so much. He asks "hard" questions to make himself feel good.

The sausage is what you'd expect if you remember one key thing: it's humans on the other side of the desk. They're finicky and arbitrary ceatures.

Re: The problems with live coding interviews

#44

Post by emodendroket » Tue, Apr 25, 2023, 4:30 PM UTC

alpinelogic wrote: post #6

Very on point and I can truly relate to all of this. I'm so frustrated by the whole process that I've started to decline live coding interviews and any take-home exercises that take more than half a day to complete. Although I have over a decade experience in my field, have been a tech-lead at some of the largest corps, contributed to open source, mentored many Engineers, and really enjoy software, this whole experie…

I don’t really. If it didn’t work the way it did I guess most of my employers would have crumpled up my resume and thrown it in the garbage for not having the right credentials on it but because it is a level playing field for everyone I got some exciting opportunities.

Re: The problems with live coding interviews

#45

Post by garrettdimon » Tue, Apr 25, 2023, 4:30 PM UTC

AlwaysRock wrote: post #38

"Here are reasons why this thing is bad. I don't have a better option." This type of interview related blog post seems to hit the front page every week. Almost everyone agrees that interviewing doesn't feel good and seems overly complicated/difficult/whatever. I hate that interviewing is a skill that has to be developed, in large part, separately from other engineering skills. I also don't really enjoy SQL/Database w…

I don't have a singular, one-size-fits-all better option, but I explicitly included several options that I've seen work well either as the applicant or from the hiring side. I just wasn't going to presume that there's one perfect replacement that will work for every team or role.

Re: The problems with live coding interviews

#46

Post by emodendroket » Tue, Apr 25, 2023, 4:30 PM UTC

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?

Re: The problems with live coding interviews

#47

Post by pugworthy » Tue, Apr 25, 2023, 4:30 PM UTC

commandlinefan wrote: post #35

lucisferre wrote: post #14

This presents as a bit of an unintentional strawman against demonstrating any kind of coding during an interview process. Live coding, if earnestly used only as a filter, does not inherently need to focus on speed or performance. It doesn't have to be a hard "galaxy-brain" problem. It doesn't have to have any tricks to it. It can literally be a simple task that one would expect any working software developer to be ab…

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…

Sometimes someone is passed by the interviewer, which is not the same thing as passing the interview. That is, they just pick someone, who may or may not be the best candidate.

Re: The problems with live coding interviews

#48

Post by emodendroket » Tue, Apr 25, 2023, 4:31 PM UTC

garrettdimon wrote: post #45

AlwaysRock wrote: post #38

"Here are reasons why this thing is bad. I don't have a better option." This type of interview related blog post seems to hit the front page every week. Almost everyone agrees that interviewing doesn't feel good and seems overly complicated/difficult/whatever. I hate that interviewing is a skill that has to be developed, in large part, separately from other engineering skills. I also don't really enjoy SQL/Database w…

I don't have a singular, one-size-fits-all better option, but I explicitly included several options that I've seen work well either as the applicant or from the hiring side. I just wasn't going to presume that there's one perfect replacement that will work for every team or role.

You just listed off a bunch of ideas. A lot of thought and argument went into the current arrangement and you’re just giving us a brainstorm.

Re: The problems with live coding interviews

#49

Post by polalavik » Tue, Apr 25, 2023, 4:32 PM UTC

lucisferre wrote: post #14

This presents as a bit of an unintentional strawman against demonstrating any kind of coding during an interview process. Live coding, if earnestly used only as a filter, does not inherently need to focus on speed or performance. It doesn't have to be a hard "galaxy-brain" problem. It doesn't have to have any tricks to it. It can literally be a simple task that one would expect any working software developer to be ab…

I still feel like interviews are entirely weird for everyone involved. It's not a real reflection of somebody's performance. Perhaps some people cannot work well with someone watching them think. I'm one of those people. I get a lot done at my job, but I need time to mull things over and sit with things in order to come to something that makes sense. Interviews only reward 1 of 2 things: people that are fast, efficient thinkers (this is good) and people that have very good social skills and can convince you of something they are not.

People who cannot perform socially or technically on the spot in a completely unnatural setup are sort of left in the dust. I'm not sure i have a solution other than throwing out technical interviews and actually trusting peoples prior work. I have work in the public (published academic papers, patents) but none of that seems to mean anything in an interview lol. Its only about can you perform right here right now for 1-4 hours.

I've said it on other threads. (1) trust peoples past employment, use background checks or something to make sure they actually worked where they said they have worked (2) look at their body of public work if they have any (3) just hire the people that look good off those two metrics and youll probably end up with a good employe 90% of the time and save countless hours and dollars. I'm almost convinced random choice + team vetting of resumes + a little background check would be just as effective as endless technical interviews.

Re: The problems with live coding interviews

#50

Post by emodendroket » Tue, Apr 25, 2023, 4:34 PM UTC

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.

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.