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

181–190 of 226 posts

Re: The problems with live coding interviews

#181

Post by 8note »

emodendroket wrote: post #56
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…

I think that’s not really relevant, in the same way that it doesn’t much matter when they take a football prospect’s running times that someone could go much faster on a bicycle or in a car.

And then your football team will lose to players who are all on bicycle?

Re: The problems with live coding interviews

#182

Post by viraptor »

frumper wrote: post #177
viraptor wrote: post #168

Earlier quoted context omitted.

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

It doesn't matter if they're familiar with my specific concept of a mature app. (Although just reading the job description would cover 90% of it...) There's always going to be a lot of overlap of concepts anyway. The question was broad exactly because there are many good answers.

(FTR, the answers were pretty consistent in what elements they included, so it wasn't confusing for the candidates)

Re: The problems with live coding interviews

#183

Post by vparikh »

proveitdude wrote: post #170
vparikh wrote: post #132

I have been in the software industry for 30 years as of this month. I have never had a gap of longer then 6 months and the shortest time with a company was 4 years 8 months and the longest time was 16 years. I have worked on the following technoclogies. Companies range from on of the Big 3 consulting firms to startups. Here are the technologies I have worked on - C/C++ on Win16/Win32 - Assembly language development w…

> Relational DB (MsSQL, PostGres, MySql), NoSQL db (MonoDB) > At my experience can we just assume that I am a competent coder and talk about the job and how I can contribute ? I mean its almost insulting if you ask me to make a linked list/reverse a binary tree or other such nonsense looking over my shoulder me with a time limit. I might inclined to agree had you not gotten all the names of the databases in your list…

Ha! You are right - I still can't type :)

Re: The problems with live coding interviews

#184

Post by edanm »

frumper wrote: post #133
hnfong wrote: post #114

Earlier quoted context omitted.

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

No, the ideal interview is to ask them questions about what type of problems they've solved before and ask them to walk through what they did. Also, have a conversation with the person to get to know a little bit about what they're looking for in a job/company. It's an interview, not a tryout. Metrics like a 10 minute task, or a 30 minute task is all relative. Do they know they language, the IDE, the operating system…

> No, the ideal interview is to ask them questions about what type of problems they've solved before and ask them to walk through what they did.

This just doesn't work. Lots of people can bullshit very convincingly, and even if they can't produce novel solutions, can very well explain them in a matter that makes you think they for-sure know how to do it.

Hell, I can probably still prove lots of interesting things about set theory in math, as can many other people who studied math - doesn't make me the equivalent of the world-class mathematicians who actually came up with the proof.

Empirically, "talk to someone about what they did" doesn't give me hires that actually know what they're doing.

Re: The problems with live coding interviews

#185

Post by edanm »

vparikh wrote: post #132

I have been in the software industry for 30 years as of this month. I have never had a gap of longer then 6 months and the shortest time with a company was 4 years 8 months and the longest time was 16 years. I have worked on the following technoclogies. Companies range from on of the Big 3 consulting firms to startups. Here are the technologies I have worked on - C/C++ on Win16/Win32 - Assembly language development w…

> At my experience can we just assume that I am a competent coder (maybe not the top 1%, but at least in the top %20) and talk about the job and how I can contribute ? I mean its almost insulting if you ask me to make a linked list/reverse a binary tree or other such nonsense looking over my shoulder me with a time limit.

If there was a way to verify what you say reliably, then of course that would be better. But there isn't, and writing down that list is extremely easy - in fact, half of the CVs I've ever seen look very similar in terms of the length of the list, amount of technologies mentioned, etc. Even for people with far less experience.

There has to be some way to check whether someone actually knows what they're doing. For sure some of the time a strong reference is enough proof. That's why people in the industry a long time with many contacts will often go from job to job without even interviewing anywhere - they just move to places with former colleagues that already know them.

But for a new place that doesn't know you, thinking it's insulting to show what you know is... weird. Is it going to be insulting on day one when you actually have to do the work?

Re: The problems with live coding interviews

#186

Post by hypefi »

fasterik wrote: post #107
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 think there's an analogy here to GRE scores and other standardized tests. With GRE scores you can predict someone's GPA, but you can't necessarily predict their success at doing original research. That's because success as a researcher depends on personality traits that are hard to measure like creativity, independence, self-discipline, perseverance, and passion about a subject. Programming puzzles are the equivale…

"I feel like standardized tests encourage conformity in thinking. By relying on standardized tests, you are selecting for individuals who are primarily motivated by external measures of success and approval. "

Totally agree

Re: The problems with live coding interviews

#187

Post by avnigo »

akvadrako wrote: post #120
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.

If they're not paid and you still wanna do it, make it into an interesting problem you wanna work on and have it be presentable enough to include in your portfolio.

At least, that way you might get something out of it instead of nothing, although I definitely do agree that being paid for it is the only way to solve the skin in the game problem.

Re: The problems with live coding interviews

#188

Post by adave »

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.

What's wrong with hiring for interviewers to be this nihlistic.

Re: The problems with live coding interviews

#189

Post by dumpsterdiver »

ryandvm wrote: post #165
blurbleblurble wrote: post #134

Recently I took a leetcode screening, my first ever, and failed to complete one single question in the allotted time due to a minor panic attack and a sudden loss of focus. The whole time I couldn't help but think about the state of the economy and how "this is it, this is my only chance." Half the time I was fighting with the in-browser IDE and struggling to remember names of JavaScript builtins that usually come ea…

I always bomb the whiteboard coding portion. I've been doing this for over 20 years. I've been a senior engineer since before the iPhone existed. Fortunately, I interview well and can discuss many, many technical concepts deeply. But put me in front of a whiteboard and I couldn't tell you my mom's name.

I imagined you standing in front of a white board, flustered, and then writing "mom" on the board. Made me laugh.

Re: The problems with live coding interviews

#190

Post by d0mine »

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…

> Maybe programming in another few years will just be glorified autocomplete and little more.

It won't. For the same reason code generation from UML diagrams hasn't replaced programmers [1]. Or why business owner/analysts don't write acceptance tests in Gherkin (Given-When-Then).

Though some tasks that programmers had to do manually in the past may be automated (not the first time).

[1]: https://news.ycombinator.com/item?id=26934795

Post reply on HN