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

331–340 of 391 posts

Re: In defense of coding interviews

#331

Post by lapcat »

ajross wrote: post #327
ubik_ wrote: post #289

Earlier quoted context omitted.

And yet correlation is not causation. And a survivor bias is probably in play here. There are so many more factors contributing to the quality of FAANG work and their performance as businesses. Hell, most of them due to their monopoly-like status could easily use any hiring technique and still rake in tons of $$$. To me the streamlined / cargo cult hiring process seems much more a symptoms of the bureaucratization of…

> And yet correlation is not causation Well... yeah. To pedantically elaborate that, clearly the hypothesis is that the measured traits (doing well on a coding interview and doing well at coding) are co-causal, and that measuring one (which is comparatively cheap to do) is a useful proxy for measuring the other (extremely expensive!). That's a really compelling hypothesis. The counter point requires, to my eyes, a cl…

What do you mean by "robust"? There are only a handful of monopolists in the world (by definition), so in that respect no other comparable companies exist.

But there are plenty of smaller companies who do well for themselves, relatively speaking, without cargo culting on BigCo hiring. And there are plenty of companies who cargo cult on BigCo hiring but who have not become a market leader. In fact there are graveyards full of failed startups who cargo culted BigCo hiring. So the hiring process doesn't clearly explain the financial results of the BigCos.

Re: In defense of coding interviews

#332

Post by bryanrasmussen »

vorpalhex wrote: post #314
Tronno wrote: post #305

Earlier quoted context omitted.

You have personally used at least one tool, language, or framework without reading its code or understanding it beyond a surface level. You've done this because some text on some website claims it gets the job done. And you probably do this every day (e.g. your OS, your phone, your microwave). People cargo cult because there isn't enough time to exhaustively research every topic from scratch. Civilization exists beca…

I'm going to put the definition of cargo culting here since we seem to have lost it: > Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Some examples are adding unnecessary comments to self-explanatory code, overzealous adherence to the conventions of a programming paradigm, or adding deletion cod…

several points, I agree installing an app is not cargo culting, however following the same interview process as many other companies do is not 'cargo cult programming' while I would agree it is cargo culting of a sort.

the problem really is that results for interview process does not seem to reliably add up to anything, there are no reasons behind any interview methodology in the traditional cargo culting sense because there is no interview methodology really founded on reason, it's mumbo jumbo all the way down.

But back to my original point some posts up, everybody has at some point taken something on faith as a best practice that works without understanding why.

Some examples where cargo cult programming are concerned are adding unnecessary comments to self-explanatory code - but how about also one I've had requesting the removal of explanatory comments from code because the code should explain itself (comment was something like, have done it this way instead of what might seem like the more reasonable way ..example code.. because of a bug in Safari that means X happens, etc. etc, if you want to removal or change to better method please check that Safari works now and this place actually wanted it removed because they preferred not to have comments in code!)

Or how about this one which I am old enough to have done: putting your script tags in the head of the document because this was a best practice (before async and defer attributes, I'm talking 1999-2000 here)

Hell many of the best practices around CSS usage have depending on the year been the exact opposite of some other earlier best practice. And many frontend developers do it because they don't have the time or evidently the inclination to really learn CSS.

Hey, many best practices regarding CSS at various times are based around the fact that frontend developers don't want to learn to use it.

Now you might say those are not really examples of cargo culting, but I think they are somewhat close - if you are using a naming convention to avoid learning how something works then you don't really know why you are using the naming convention because the purpose of that convention is to keep you from that knowledge.

anyway getting off track here, I just think that saying you are not going to work at a place that has cargo culted its interview process does not tell you anything about the overall quality of the place, because everyone has cargo culted something, just like many fine developers when setting up their React projects have said oh, everyone uses Webpack we'll do that as our build process - they know they need a build, but why Webpack? They don't really know (me neither, every time I've ever encountered Webpack I've always ended up wondering why!? Generally the answer is because that's what the tutorials had, everyone used it, they didn't give any thought, but now we're stuck with it)

Re: In defense of coding interviews

#333

Post by wiseowise »

tombert wrote: post #13

I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting. I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.

Sorry you have to go through peasant ropes, your highness.

Re: In defense of coding interviews

#334

Post by IshKebab »

dccoolgai wrote: post #26

If I have my Jr. Dev a hard problem to work on and they said "breathe over my shoulder for 30 minutes and I'll have the answer for you" I would be having a serious corrective chat with them at our next meeting. No one works that way. Coding interviews are 10 percent about coding and 90 anxiety management... Which to be clear is important, but let's be honest about what we're filtering for in these things.

If interviews make you so anxious you can't think then you just have to practice more (I mean do more actual interviews). What's your alternative?

Best I can think of is take home tests but I wouldn't want to rely entirely on that, and they have their own problems too.

Re: In defense of coding interviews

#335

Post by IshKebab »

tombert wrote: post #13

I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting. I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.

Yeah I can see why it seems insulting but have you ever interviewed a lot of people.

When I started interviewing I started off by jumping into what I considered to be not insulting questions, but I very quickly learnt how awkward that can be if the candidate just had no clue.

Now I start with for loops and preface it with "apologies if this seems too simple" or something like that.

You would be surprised how many people can't do a simple for loop. I mean really simple.

Re: In defense of coding interviews

#336

Post by mihaitodor »

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…

This! Thank you for writing it. And let’s not forget about the wasted nights ruminating about the poor performance and putting up with people who get their dopamine when they are given authority over a peer. Most developers don’t study psychology and don’t have the ability or interest of creating a safe space for conducting the kind of interviews that their employer demands.

Re: In defense of coding interviews

#337

Post by mihaitodor »

vletal wrote: post #160
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…

I've just interviewed for Google and Meta. In total I went through 8 individual coding interviews. With an exception of one, which was a bit too much like a puzzle, I think the assignments were completely fair examples of what I might experience on daily basis. Not at all tailored to people doing competition style programming, which was what I expected after being exposed to HN for years. I have to say I enjoyed both…

This comment reminds me of a comic with two vultures who question Mr. Mouse’s claims about the Owl being a predator. It’s not like he ever bothered them. See here: https://twitter.com/nathanwpyle/status/999294987195035649

Re: In defense of coding interviews

#338

Post by ajross »

lapcat wrote: post #331
ajross wrote: post #327

Earlier quoted context omitted.

> And yet correlation is not causation Well... yeah. To pedantically elaborate that, clearly the hypothesis is that the measured traits (doing well on a coding interview and doing well at coding) are co-causal, and that measuring one (which is comparatively cheap to do) is a useful proxy for measuring the other (extremely expensive!). That's a really compelling hypothesis. The counter point requires, to my eyes, a cl…

What do you mean by "robust"? There are only a handful of monopolists in the world (by definition), so in that respect no other comparable companies exist. But there are plenty of smaller companies who do well for themselves, relatively speaking, without cargo culting on BigCo hiring. And there are plenty of companies who cargo cult on BigCo hiring but who have not become a market leader. In fact there are graveyards…

There are plenty of large companies with established hiring practices and standardized interview schemes out there that don't do FAANG-style coding interviews, though. And on the whole they don't do well at delivering software, and have a reputation as terrible places to do software work.

And on the other side: are there major employers who implement rigorous coding interviews who... don't have a history of producing good software? I really can't think of any.

That's my point: the evidence is really stacked in favor of the FAANG scheme. So pointing to a handful of small outfits doesn't really sway my impression; those are just expected outliers. I've worked at smaller companies with terrible hiring success, FWIW; they ended up successful because of a few lucky hires.

Re: In defense of coding interviews

#339

Post by dlkf »

rsanek wrote: post #308
dlkf wrote: post #282

Earlier quoted context omitted.

> For such a bold claim, one would expect evidence to be readily available. The only way to provide this evidence would be to to conduct an RCT in which you hire some percentage of people who fail the test as a control group. The nascent psychologist in me loves this idea, but it seems unethical, and presumably this is why nobody does it. But I disagree that we need ”evidence.” It’s flat out obvious. If you give your…

> conduct an RCT in which you hire some percentage of people who fail the test as a control group You might enjoy Work Rules by Laszlo Bock. They actually did do this at Google to validate their interview approach.

Lo and behold, they still do coding interviews. Who would have guessed that people who answer difficult questions correctly would outperform people who don’t.

In all seriousness, thank you for bringing this up - it’s an interesting story and I will probably look into it. But I also think it’s pretty obvious that coding interviews work extremely well, and any discussion of ”how can we create a procedure that is better for everyone” that doesn’t acknowledge this is hopeless.

Re: In defense of coding interviews

#340

Post by koonsolo »

ipaddr wrote: post #306
koonsolo wrote: post #180

Earlier quoted context omitted.

Do you think they are looking for a job because they were fired somewhere else? Or do you think companies never fire people? We already fired plenty of people that we hired. So yes, our hiring process is not perfect. But if you're a JavaScript developer and can't explain the difference between var, let and const, I'm not going to hire you. If you claim these people are great developers, you are free to hire them. Let…

Those are different skill sets. Someone may know and know how to properly use var, let and const according to standards and current trends. They may understand it deeply. But that doesn't mean that they can explain it to you. The question changes to: is what you are testing the actual skill you need? Are you hiring a teacher who is going to explain var,let,const as part of their job or are you hiring someone who need…

> that doesn't mean that they can explain it to you.

I'm sorry what? I don't expect them to teach me, I just want them to tell the difference. By the way, the ones that can't say: "they told me to always use let". I'll send them to you :D. Best of luck.

> I've never seen a senior developer fired for poor coding.

I've seen plenty. If a junior dev needs to help you out of trouble every time, you know there is something wrong.

Some people just reach their limit very soon, and can hide away in some comppanies. Probaly companies where you seem to work. Other companies probably just have a higher bar, no disrespect meant.

Post reply on HN