Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of coding interviews

biggestfish.substack.com

Post reply on HN
Print view View original

91–100 of 391 posts

Re: In defense of coding interviews

#91

Post by tshaddox »

leeoniya wrote: post #58
vorpalhex wrote: post #27

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?") you should be able to explain why you wrote something the way you did; that's not an absurd ask. perf characteristics of different iteration styles are often significant to the task at hand.

If the choice is relevant to the task, then sure. If it’s an arbitrary choice then the question is meaningless. It’s like asking “why are you wearing a blue shirt?” when you would have asked “why are you wearing a black shirt?” had they been wearing a black shirt.

Re: In defense of coding interviews

#92

Post by Jensson »

Apocryphon wrote: post #80
quacker wrote: post #79

Earlier quoted context omitted.

One thing to realize is that interviews are a two-way street. Do you think you want to work with the interviewers? Do you like the interview process? If the interview process is poor, what other kind of hiring decisions is the company making? Are you going to want to work with the people they end up hiring? You learn a bit about the company during the interview, and if that bit is bad, then move on. If they ask shitt…

The problem is when a significant number of companies all cargo cult the same process- that way you can’t even write them off as a one-off bad place.

A simple test: Do they hire like Google but manage their programmers like a sweatshop (ie Scrum)? Then they are just cargo culting. Companies like Google at least gives its engineers a lot of responsibility and freedom you'd never get in an Agile shop.

Re: In defense of coding interviews

#93

Post by peterhunt »

vorpalhex wrote: post #89
peterhunt wrote: post #82

Earlier quoted context omitted.

What’s the alternative?

You can just ask them to talk about code. You can ask them to compare and contrast some frameworks or languages of their choosing. You can ask them to do design tasks, or just talk about the work the company does and let them ask questions. One of the things I like to do, especially when a candidate is super anxious, is just ask them to talk about a recent project they've done that they like and why they like it.

Isn’t that going to result in a highly biased interview process? I suspect extroverts will do disproportionately better than introverts, and those who are comfortable in technologies the interviewer is not will do worse than those who share a similar technical background.

I also think the skill cap on this sort of question is super low.

(I’d put design questions in a different category though)

Re: In defense of coding interviews

#94

Post by leeoniya »

tshaddox wrote: post #91
leeoniya wrote: post #58

Earlier quoted context omitted.

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?") you should be able to explain why you wrote something the way you did; that's not an absurd ask. perf characteristics of different iteration styles are often significant to the task at hand.

If the choice is relevant to the task, then sure. If it’s an arbitrary choice then the question is meaningless. It’s like asking “why are you wearing a blue shirt?” when you would have asked “why are you wearing a black shirt?” had they been wearing a black shirt.

i'm not claiming that this is a good question for every case. but there are many times where the choice of loop makes a significant difference. asking this question for a task that only requires iterating 3 elements every 1000ms would indeed be quite stupid on the interviewer's part.

it always amuses me when people use these seemingly stupid questions (out of context) to prove how broken tech interviews are. but of course, if your job will be write high perf code, then suddenly they question is incredibly relevant.

to be clear, i agree that there are a lot of stupid questions that get asked which are not relevant to the actual job you'll be doing (exceedingly few SWEs will need to implement a merge sort as part of their job)

Re: In defense of coding interviews

#95

Post by Apocryphon »

nogridbag wrote: post #75
Apocryphon wrote: post #11

Earlier quoted context omitted.

The problem is that these problems are not even whiteboard problems anymore. They’re often strictly timed coding exercises on Coderpad or Karat with actual mock IDEs and REPLs expecting running code under strict expectations. The more casual, flexible, subjective coding interview described by the OP is not the prevalent form of whiteboarding interviews, which has been superseded by the weeder version.

Do you have any suggestions for a simple online coding portal? I know some companies have used a simple Google Doc for this reason, but that seems far from ideal.

Coderpad and Hackerrank are pretty de rigeur

Re: In defense of coding interviews

#96

Post by neilv »

rektide wrote: post #87
neilv wrote: post #61

Earlier quoted context omitted.

> what's more important is how dedicated you are when it comes to reaching a goal. Essentially, they are testing your will power. You know the rules. Can you achieve success and not give up in the middle of the road by skipping, say, Dynamic Programming? That's an interesting theory. And they pick the goal that happens to be best suited to fresh/current undergrads from Stanford who weren't working a draining job to p…

The thing is, the practical field is littered with countless different technologies & endless subjective opinions. We'd need 3,000 different tests to test everyone's practical knowledge, to let them pick between. Oh, you use Go and SolidJS, here's a test for you... and who is going to be able to properly give you a score other than works/doesn't work? This person likes functional style but this person is more OO... t…

The earlier comment suggested that Leetcode was a litmus test for whether someone has will power beyond CS curriculum, and that's what I was responding to. Are you arguing a different motivation?

Re: In defense of coding interviews

#97

Post by vorpalhex »

leeoniya wrote: post #58
vorpalhex wrote: post #27

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?") you should be able to explain why you wrote something the way you did; that's not an absurd ask. perf characteristics of different iteration styles are often significant to the task at hand.

Your problem has gone off the rails if that level of performance difference is important.

Re: In defense of coding interviews

#98

Post by leeoniya »

vorpalhex wrote: post #90
leeoniya wrote: post #81

Earlier quoted context omitted.

> This ridiculously untrue. at least for JS VMs, this is true today. this answer will certainly vary for other languages/runtimes. i profile and optimize a lot of JS/TS code that handles datasets with millions of datapoints at my day job. but you don't need to take my word for it; this claim is not exactly difficult to verify. > Do you just play along or begin to explain how incredibly wrong they are? in this case, i…

It's probably time to move into a faster language if you're getting caught up in language specifics on loop execution.

quite impossible to move into a faster language when it would

1. require a complete rewrite of an existing, massive codebase

2. where the primary task is rendering interactive charts for a React web app

Re: In defense of coding interviews

#99

Post by bryanrasmussen »

vorpalhex wrote: post #86
Apocryphon wrote: post #80

Earlier quoted context omitted.

The problem is when a significant number of companies all cargo cult the same process- that way you can’t even write them off as a one-off bad place.

You can still write off cargo-culting companies who cargo-cult bad processes off. I give you permission.

Every company cargo-cults or should we say - follows best practices or industry wide processes - in something.

No company has thought through every little bit of their system and processes because no company has the time to be completely original, just like no human idea only has ideas that they thought up themselves instead of borrowing a bunch of ideas from school, books, and overheard conversation because they sound right.

Re: In defense of coding interviews

#100

Post by Jensson »

adam_arthur wrote: post #43
vorpalhex wrote: post #33

Earlier quoted context omitted.

How do you actually measure 2x or 10x workload while keeping quality the same? It's _very_ easy to measure how fast it takes a ticket to go from "in progress" to "done" but measuring whether code has bugs, or leads to downtime or is just impossible to parse is a different problem. If you never need code to be readable or documented I can write it quite quickly. If you want something other humans can have a hope of ma…

It's pretty easy to tell when you're managing a team and familiar with the code. You can't quantify it explicitly, but it can be quite clear. In my experience the top 20% of employees do 80% of the work

> In my experience the top 20% of employees do 80% of the work

That would make them 16x as productive compared to the bottom 80% who does 20% of the work. So 10x seems to be roughly the same thing as the 80/20 rule.

Post reply on HN