Live data from Hacker News

In defense of coding interviews

biggestfish.substack.com

341–350 of 391 posts

Re: In defense of coding interviews

#341
post #338
post #331

Earlier quoted context omitted.

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…

It's difficult to agree or disagree with this comment, because it's so vague. For example, "on the whole they don't do well at delivering software, and have a reputation as terrible places to do software work." Are we supposed to just accept this claim without question? I have no idea which companies you're talking about. And I'm not sure that Apple and Amazon for example don't have reputations as terrible places to do software work, but again I'm not entirely clear on what you mean by that.

Moreover, "good software" is also highly subjective and subject to dispute. I feel that the software coming from Apple and Google has gone downhill in the past decade. Are we to explain that by hiring?

The financial numbers are indisputable for Apple, Microsoft, Google, Amazon, and Facebook. (Not sure the term FAANG even makes sense anymore.) But something like "reputation" is another matter entirely.

Re: In defense of coding interviews

#342
post #331
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 only a handful of monopolists in the world (by definition)

I don't think that's right. If a small town only has one gas station, and the next closest is 100 miles away, isn't that gas station owner a monopolist?

Re: In defense of coding interviews

#343

Earlier quoted context omitted.

Interview technical folks at a FAANG and I don't asking leetcode questions. It isn't a SWE role but people should be SWE material. I do ask them to * read code * extend some working code with a new feature * parse some semi-structured text into a data structure Programming interviews suck for everyone, even the interviewer. I feel absolutely horrible when someone locks up, or fails really hard. The questions I ask ar…

> I had one person start crying they put so much pressure on themselves, I had to take a two week break from interviewing after that. Because you asked them question out of syllabus. Was the person informed that the interview wouldn't involve Leetcode? The person spent months prepping Leetcode just to get into BigTech and then you come out of woodwork with your "special" interviewing material. Imagine prepping for a…

This wasn't a Leetcode question. I understand where you are coming from, but it isn't that.

This had to do with the pressure one puts on themselves for a job a BigTech company.

Re: In defense of coding interviews

#344
post #249

Earlier quoted context omitted.

The second sentence may be true but the former isn't. People who break down and cry in interviews are rare but if they do it, they are best avoided and it was good that the interview revealed this. You cannot have that happening on the job but if they can't handle being asked to program something whilst up against a time limit or being watched, they're going to have breakdowns in other situations too.

I've written at length about this before, so I'll just give a link instead of repeating the whole screed, but it's a misconception to equate interview anxiety with job anxiety. They're distinct and not necessarily correlated. https://news.ycombinator.com/item?id=31377459

Thanks for taking the time to write that. I agree. Interviewing is a horrible crap shoot and would say even cruel by construction.

Re: In defense of coding interviews

#345

Earlier quoted context omitted.

It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of experience are not too good at coding.

Many people with genuine 10 years of experience do not care for stupid leetcode question they could obviously solve given some quiet and time. The idea that everything boils down to answering some intro to programming questions quickly is absurd.

Years of experience are not created equal. There are far fewer who can actually solve them but don’t want to than those who just can’t. If you spent the last 10 years just ossifying then you might be great in your current role but realistically you’re terrible at building new things.

Re: In defense of coding interviews

#346
post #261

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

> Do coding interviews work in the actual world in which we live in?" No, fundamentally not. I look forward to seeing you disrupt every major tech company in the world via your superior hiring strategy. > EVEN IF THE CANDIDATE CAN IN FACT PROGRAM JUST FINE. You don’t seem to have thought very hard about what employers are optimising for. Everyone realises that programming interviews produce lots of false negatives. E…

> You don’t seem to have thought very hard about what employers are optimising for.

Have you ever seen a hiring process that's simply not effective?

The undercurrent of this irks me a bit. It assumes a kind of omniscience on part of the employer, and enough time for them to develop a good interview process. I think this is really hard to do.

I think you're generally right. And a lot of the time, employers are empathetic, pragmatic, self-aware and really are doing us a favor when they deny us. Some take into account I-O psychology stuff, too.

I (and others probably) are eager to hear what companies you feel do a good job at hiring.

> Everyone realises that programming interviews produce lots of false negatives.

Let's assume a bad scenario. A company can disregard evidence of competency, like having a portfolio, to basically have a rolling, year round tech Olympiad. To them, it's about fronting as a strong candidate in events, even at the expense of being good at the role.

You can be a pro at pole vault or discus throwing, but a poor carpenter. But there's a mentality out there - with some - that a strong, fit candidate can handle any technical challenge.

Can a chemist be a great chef? I bet, I also bet some could overthink and/or overengineer preparing a simple meal. Does the interview process do anything to check for soft skills, like curiosity, simplicity, etc? Hopefully.

> The goal is minimizing false positives. Failing to hire a strong candidate carries a much lower cost than hiring someone who can’t do the job.

I think some companies - not all - can create a "squid game" contest out of candidates. Worse, I feel candidates can unduly suffer and be humiliated in these cases.

The company gets a superb interviewer, who is no doubt a very intelligent person, but not necessarily one that can adapt to technical reality, contingencies, ambiguities, etc. Some interview processes end up focusing on theoretical and rote knowledge, not integration and synthesis, when they deeply need that. Turnover happens.

But we're back to the beginning, did the company: 1. really know what they needed for that position, 2. interview process check for that? My guess is when you wrote that you were assuming situations where both were true?

Re: In defense of coding interviews

#347
post #330

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.

If it takes months of practice, probably one didn't learn very much in programming classes. But you'll learn a heck of a lot with those months of practice, and that'll pay off handsomely with that $250,000 offer.

Re: In defense of coding interviews

#348

Earlier quoted context omitted.

You have a task to implement a new product feature and it takes you 1 week instead of 1 day. In an interview context, I've seen cases where somebody fully understands the logic underlying the solution, yet it takes them 30m to write it, while another person can do it in 5m or less. Essentially how long it takes to translate from mental understanding to working code

> Essentially how long it takes to translate from mental understanding to working cod Congrats, you just invented whiteboard interview.

Whiteboard interview has nothing to do with coding proficiency. Writing pseudo code of an algorithm by hand does not tell you much at all about how proficient somebody is as a coder.

Coding is the act of writing code, not ideating an algorithmic solution. Its almost completely orthogonal to computer science problem solving.

The principles of high quality code (from a design perspective) are also completely orthogonal to runtime complexity of an algorithm.

Re: In defense of coding interviews

#349
post #160

Earlier quoted context omitted.

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

I appreciate the reference.

But, I don't think those are vultures. They are bald eagles. I'm not sure if owls scavenge, but I do know they primarily hunt. Eagles both hunt and scavenge. Vultures primarily scavenge.

Re: In defense of coding interviews

#350
post #295

Earlier quoted context omitted.

>If you give your job candidates a discrete math problem orders more difficult than the usual ticket, you minimize the risk of hiring someone who can’t do the job. You're also maximizing the odds they will get bored and feel baited. With all due respect, you could have picked a better example to illustrate your point. This is exactly why you can't make such bold claims. You're looking at this from one perspective wit…

> You're also maximizing the odds they will get bored and feel baited. I like this point. This is an especially big problem in my area (data science), in which people think they are being hired to do deep representation learning, and are subsequently mortified to learn that the job is principally about transpiling ”product manager” to ”SQL”. The cure is to be up front with job candidates. Tell them the job involves n…

> I believe you want to optimize for the hardest day rather than the average day.

I think this is a huge mistake. I work in data science, and nearly universally my colleagues are motivated by opportunities to learn. If you're testing for the very rare day, so that your employee has the right answer in their front pocket when that happens they are never going to feel challenged, feel like they're growing, and they're going to jump ship.

I think you're doing snobby filtering, and it's not to your benefit.

Post reply on HN