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

321–330 of 391 posts

Re: In defense of coding interviews

#321

Post by robertlagrant »

lapcat wrote: post #301
dlkf wrote: post #276

Earlier quoted context omitted.

> But the adversarial puzzles and whiteboard programming are not "the job". This is true. They are closer to ”the rare, most intellectually difficult parts of the job.” A hockey player typically spends 70% of each game sitting on the bench; yet this isn’t what is emphasized in tryouts. > Hire for strengths, not to avoid weaknesses. I guess you didn’t read the part of my comment where I wrote: 1. ”Failing to hire a st…

> And if you’re right, then you have a huge opportunity, because this suggests you can disrupt any vertical where the incumbent does the LeetCode thing. Only if you view hiring as the competitive advantage of Google/Microsoft/Apple. But everyone cargo cults the hiring practices of Google/Microsoft/Apple without becoming Google/Microsoft/Apple, which shows that it's not actually some magical unique competitive advanta…

> Only if you view hiring as the competitive advantage of Google/Microsoft/Apple. But everyone cargo cults the hiring practices of Google/Microsoft/Apple without becoming Google/Microsoft/Apple, which shows that it's not actually some magical unique competitive advantage.

You're conflating some things here. Without unpicking it all, the main thing I'd say is that you've only demonstrated that amazing hiring is not sufficient for competitive advantage. You have not demonstrated that it's not necessary.

Re: In defense of coding interviews

#322

Post by robertlagrant »

Jensson wrote: post #201
amitport wrote: post #198

Earlier quoted context omitted.

Scrum does not mean "no freedom" or "no autonomy" it just says lets think about what we're going to do and try to follow a plan for the next week or two. Of course the individual software developer should be the one responsible to forming, adapting, and updating this plan (and it definitely should contain " collaborate with stakeholders, build prototypes and get feedback etc,") (of course, there is some level of 'com…

Sanity check: Would your manager complain if you stopped doing Scrum? If yes then you don't got that much freedom. If no, then I can see it being fine. It can work fine if nobody outside of it depends or uses the Scrum process, but then the company isn't doing Scrum, just the team doing it internally. This lets the team adapt and stop doing Scrum when it no longer fits their problem etc, that is the agile way. My poi…

"You can't stop using scrum without your manager complaining" is not the same as "zero autonomy".

Re: In defense of coding interviews

#323

Post by robertlagrant »

enedil wrote: post #205
arethuza wrote: post #162

Earlier quoted context omitted.

What would you do if a candidate said with a smile "I'm pretty sure it is O(n!)"?

Parent commenter asked for little o, not for big O. So to be safe, better say n^o(n^2).

Hah this is the best comment.

Re: In defense of coding interviews

#324

Post by Izkata »

jsnk wrote: post #73
angarg12 wrote: post #29

Before we criticize the current interview format and propose alternatives, we need to understand how we got here first. This is my understanding of what happened (I wasn't there for most of this!). Leetcode-style interviews became popular in the mid 00s, primarily because they were used by hot tech companies of the time. The thing to understand is that at that time, the idea of asking people to write code during an i…

This is probably the best take in the entire comment section. I see whole bunch of people complaining about Leetcode (LC) style coding questions, but I don't really see any alternative that is as good as LC. LC interviews solve all the following criteria better than other interview formats in aggregate. - Objectivity: can you evaluate candidates as objectively as possible as opposed to subjectivity? - Scalability: ca…

> 1. Take home assignments.

> Meritocratic: good

I'd go with "iffy": because of the "take home" part there's no guarantee it's the candidate that did the work. This can probably be determined with a follow-up conversation during the in-person part, but without such an addition I don't see this format as "good" on this metric.

Re: In defense of coding interviews

#325

Post by dagmx »

ldjkfkdsjnv wrote: post #317
dagmx wrote: post #291

Earlier quoted context omitted.

It's not a boolean can/cannot code. It's a cannot code at the level expected of the seniority. I interview tons of software engineering candidates (pre pandemic it was at least one or two a week). At least half of my senior candidates fail basic phone screener questions. These are questions that reflect something they'd be doing day to day in the role, but also are incredibly standard in our field. The issue in most…

I think actually whats happening is some people are just not good at interviewing on the spot. And people are looking for gotchas in these interviews, "He didnt know how to use breadth first search?!?!?!", when the senior engineers daily life is probably more like a surgeon operating on a highly convoluted large scale code base full of business logic.

That may be true for some other interviews, but like I said, I ask questions based on what we'd be doing day to day. I don't care about CS theory jargon or language gotchas.

Again, at least half of software engineers I talk to for the screening round are not strong developers for the reasons I mentioned above.

Re: In defense of coding interviews

#326

Post by lapcat »

robertlagrant wrote: post #321
lapcat wrote: post #301

Earlier quoted context omitted.

> And if you’re right, then you have a huge opportunity, because this suggests you can disrupt any vertical where the incumbent does the LeetCode thing. Only if you view hiring as the competitive advantage of Google/Microsoft/Apple. But everyone cargo cults the hiring practices of Google/Microsoft/Apple without becoming Google/Microsoft/Apple, which shows that it's not actually some magical unique competitive advanta…

> Only if you view hiring as the competitive advantage of Google/Microsoft/Apple. But everyone cargo cults the hiring practices of Google/Microsoft/Apple without becoming Google/Microsoft/Apple, which shows that it's not actually some magical unique competitive advantage. You're conflating some things here. Without unpicking it all, the main thing I'd say is that you've only demonstrated that amazing hiring is not su…

I wouldn't describe it as "amazing" hiring. I'd describe it as assembly line hiring. The results are amazing: Google/Microsoft/Apple are 3 out of the 4 largest companies in the world by market cap. And there's a hiring process — though I doubt the process has remained exactly the same from company founding to present. The question is how much if any the specific hiring process contributes to the results.

I'd say there's a big difference between a company finding engineers and engineers throwing themselves at a company. The latter is what often occurs with BigCos. They have a big pool of candidates throwing themselves at the company, and the company gets to pick whomever they like from the pool. How much credit to due to the company for picking? Whereas I think you'd give a company more credit for going out and specifically recruiting/poaching one person they want, even if that person wasn't applying for a job with them.

Re: In defense of coding interviews

#327

Post by ajross »

ubik_ wrote: post #289
ajross wrote: post #271

Earlier quoted context omitted.

> "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. See, that's just not right. I mean, we all agree there's a hard problem to solve here, right? The world is populated by engineers of widely varying skill levels. It just is. So how do you detect them? Well, the ability to bang out a correct solution on a whiteboard is a verifiably correct way to do that. It may not be optima…

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 clear working example: a company with a uniform hiring process involving some other technique which has a track record of product development as robust as all the existing leaders. And I don't see one. Calling them monopolies or cargo cults seems to be filling in for evidence, and I don't see that as persuasive.

Re: In defense of coding interviews

#328

Post by robertlagrant »

lapcat wrote: post #294
kansface wrote: post #281

Earlier quoted context omitted.

Have you ever worked with a really bad hire? Someone totally incompetent at doing the job? In my personal experience, that person completely tanks the productivity and moral of the entire team. I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that). Bad hires are disastrous.

> In my personal experience, that person completely tanks the productivity and moral of the entire team. A bad manager completely tanks the productivity and morale of the entire team too. And you can't fire your boss, you can only quit your job. > I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that). Not sure how it's r…

You're answering in a vacuum. The previous poster is saying that just hiring easily with a view to firing if they're bad is destructive. Talking about managers is irrelevant to this. It's not one or the other.

Re: In defense of coding interviews

#329

Post by robertlagrant »

lapcat wrote: post #326
robertlagrant wrote: post #321

Earlier quoted context omitted.

> Only if you view hiring as the competitive advantage of Google/Microsoft/Apple. But everyone cargo cults the hiring practices of Google/Microsoft/Apple without becoming Google/Microsoft/Apple, which shows that it's not actually some magical unique competitive advantage. You're conflating some things here. Without unpicking it all, the main thing I'd say is that you've only demonstrated that amazing hiring is not su…

I wouldn't describe it as "amazing" hiring. I'd describe it as assembly line hiring. The results are amazing: Google/Microsoft/Apple are 3 out of the 4 largest companies in the world by market cap. And there's a hiring process — though I doubt the process has remained exactly the same from company founding to present. The question is how much if any the specific hiring process contributes to the results. I'd say ther…

> How much credit to due to the company for picking?

Lots. Firstly for becoming a place people want to work. Secondly for sifting through all of those people.

Re: In defense of coding interviews

#330

Post by s1k3 »

WalterBright wrote: post #68

If you're augering for a $250,000 job, and the gate is a leetcode interview, just spend a couple weeks prepping for it. It'll be the biggest bang for the buck effort you'll ever make.

It takes months of practice to go through all the material for a FAANG interview. The recruiters even tell you as such.
Post reply on HN