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

Green Lumber Fallacy in Software Engineering

chrisbehan.ca

Post reply on HN
Print view View original

81–90 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#81

Post by mrkentutbabi »

MarkMarine wrote: post #54
mrkentutbabi wrote: post #42

If I have money for every article that rail against DS&A algorithm.... I don't understand why people hate DS&A so much. Just do it. Get money, jump ship, get more money, it also makes you a better engineer. It gives you better compensation, it helps you, helps everyone, helps your team, your company. It helps avoid wasting time as well on both sides. There is no downside of studying DS&A and Leetcode, if there is, th…

I came here to basically say this. You want the big salary at the fancy company, show me you put in the work to earn it.

The alternative is way way way worse for both the companies and the candidates. While DSA is basically upside for everyone but especially, especially the candidates.

Learn once, use it many times, rack many offers. Its like cheating mode.

Re: Green Lumber Fallacy in Software Engineering

#82

Post by recursive »

tharne wrote: post #69
paxys wrote: post #60

Data structures and algorithms questions are a perfect proxy for (1) is the candidate smart and (2) can the candidate write moderately complex code (arrays, hash maps, pointers, nested loops). 90% of candidates will fail 2, and you will get a good idea of the rest with 1. Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have.

> Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have. If the current leetcode style of interviewing is the best that SV can come up with, despite having some of the best engineers and thinkers in the world and billions of dollars to spend, that's really sad.

Your sadness is not actionable. It will remain status quo until someone thinks of something better, regardless of ambient sadness levels.

Re: Green Lumber Fallacy in Software Engineering

#83

Post by mrkentutbabi »

MattGaiser wrote: post #46
mrkentutbabi wrote: post #42

If I have money for every article that rail against DS&A algorithm.... I don't understand why people hate DS&A so much. Just do it. Get money, jump ship, get more money, it also makes you a better engineer. It gives you better compensation, it helps you, helps everyone, helps your team, your company. It helps avoid wasting time as well on both sides. There is no downside of studying DS&A and Leetcode, if there is, th…

My objection is maintaining an entirely unrelated skillset that I have never encounter in my day to day work. It is a skill that you will lose if you spend a year without interviewing/leetcode practicing. Sure I’ll do it, but you may as well test me on painting famous oil artwork from memory too. > I don't understand why people prefer "here take home questions/work for 5 hours for free" over DS&A interview. The alter…

But I do get to implement these in some my day to day work. Not everyday of course, but every other month there are some problems that I used my DSA knowledge to solve.

Graph problems are pretty common, even in frontend stuff. Often times I have to write my own library.

Re: Green Lumber Fallacy in Software Engineering

#84

Post by CobrastanJorji »

erehweb wrote: post #55

Article says "There’s no better way to see how someone performs at the job than having them actually do the job." and argues for a trial work period. Well sure, except the first part of any job is coming up to speed on the domain, the codebase, who the key people are, etc. So if you want to see how someone really performs, you're going to have to wait a while past that initial period. And that means you're going to h…

For very small companies, hiring someone with the right skills who will work well with the team is a crucial, "this might make or break our company" decision. I've seen a couple of companies who solve this by having the candidate spend a day pairing with someone on a real problem. When this works (whatever's being worked on is small enough to be understandable, the language/platform/domain/tool isn't completely foreign to the candidate, etc), it's a really great signal.

But for very large companies, it's still really bad to hire bad candidates, but it's also important to be efficient. You need multiple opinions on candidates, but the interviewers can't spend a whole day each; it's too expensive. But on the other hand, you have basically an unlimited pool of candidates. So you do whatever's both fast and is unlikely to produce bad "hire" decisions, and supposedly a series of algorithm puzzlers do a good job of being fast and producing a low false positive rate. I'm not sure if that's actually true, but that's the argument. I am sure that the process rejects a huge number of perfectly good programmers, though.

Re: Green Lumber Fallacy in Software Engineering

#85

Post by paxys »

tharne wrote: post #69
paxys wrote: post #60

Data structures and algorithms questions are a perfect proxy for (1) is the candidate smart and (2) can the candidate write moderately complex code (arrays, hash maps, pointers, nested loops). 90% of candidates will fail 2, and you will get a good idea of the rest with 1. Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have.

> Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have. If the current leetcode style of interviewing is the best that SV can come up with, despite having some of the best engineers and thinkers in the world and billions of dollars to spend, that's really sad.

Silicon valley seems to be doing just fine with this system in place. If there is a better process, let's formalize and test it. Here's a hint - large companies have spent millions/billions of dollars over the years doing just that, and this is what the results show.

Re: Green Lumber Fallacy in Software Engineering

#86

Post by AnimalMuppet »

wiseowise wrote: post #72
AnimalMuppet wrote: post #39

Earlier quoted context omitted.

The material is irrelevant , at least for most software engineers. (For a FAANG, not so much. But for most places? Irrelevant.) I understand the time-space tradeoffs of the various STL collections, and the Java collections. In 35 years, that's been all I have needed. (And, if it does come up, why spend months memorizing what I can spend minutes googleing?) I am not a huge outlier. Interview for what you need. Anythin…

You're making it sound like only FAANGs operate on such a scale.

I didn't mean to do so. But I would say that the large majority of software engineers work on stuff that doesn't operate at that scale.

[Edit: Or perhaps I should say that far more companies interview as if they operated at that scale than actually operate there.]

Re: Green Lumber Fallacy in Software Engineering

#87

Post by dragonwriter »

amscanne wrote: post #80
tharne wrote: post #69

Earlier quoted context omitted.

> Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have. If the current leetcode style of interviewing is the best that SV can come up with, despite having some of the best engineers and thinkers in the world and billions of dollars to spend, that's really sad.

Why is this sad? Standardized IQ tests are notoriously difficult to get right and may be legally questionable (Griggs v. Duke Power Co.). At some point you have to accept that there is no ideal way to interview, and that there are fundamental time/precision/recall trade offs. Big tech optimizes for low time and high precision, which means you certainly will end up with low recall (false negatives). I’m sure there are…

> Standardized IQ tests are notoriously difficult to get right and may be legally questionable (Griggs v. Duke Power Co.).

Griggs applies to any hiring criteria or practice that has a negative impact on a protected class compared to people outside the class (given the set of protected classes, this is essentially any hiring criteria or practice) without sufficient evidence of probative value on job performance. It is neither limited to things very much like IQ tests, nor are IQ tests any harder to justify than any other element of a hiring process.

Re: Green Lumber Fallacy in Software Engineering

#88

Post by burnished »

caethan wrote: post #49

I've heard bitching about some of the interview questions our team asks before, but here's the thing: each of those questions is about a problem our team actually had to solve before, reformulated into an interview-style question. Yes, we've had to use Hamming distances, worry about the scaling (N log N vs N^2) of particular solutions, use error-correcting codes, interesting data structures and all of that. Is that m…

Is your team hiring? Sounds like fun.

Re: Green Lumber Fallacy in Software Engineering

#89

Post by lhorie »

erehweb wrote: post #55

Article says "There’s no better way to see how someone performs at the job than having them actually do the job." and argues for a trial work period. Well sure, except the first part of any job is coming up to speed on the domain, the codebase, who the key people are, etc. So if you want to see how someone really performs, you're going to have to wait a while past that initial period. And that means you're going to h…

Yeah, that is one of those claims that sound nice in theory but kinda come crashing down when rubber meets the road.

Companies do in fact engage in a process of getting someone in and doing an actual job, they're called internships. The problem is that these arrangements typically involve someone dedicating some non-trivial amount of their time to "babysitting" (not necessarily in the literal sense, but in the sense that a newbie doesn't have historical context or familiarity with processes and workflows, even if they are by all other measures bright individuals w/ actual experience under their belts). Either you spend inordinate amounts of time setting up and maintaining a contrived bubble where a candidate can operate cleanly for a very short period of time, or you're looking at very long evaluation times (requiring a week or more of time from a candidate, who generally already is gainfully employed).

It's also worth pointing out that this process is incredibly expensive. One hour of time from a full time employee doesn't really cost anything more than the few minutes lost to context switching (ie. not really that much worse than the person going out to buy a coffee). Literally setting up a paid one week period for a senior level candidate would cost, optimistically, a few hundred dollars for evaluating a single candidate. It's completely unworkable in a large company that conducts dozens of interviews or more per week.

Re: Green Lumber Fallacy in Software Engineering

#90

Post by mavelikara »

> I’ve never heard of an ex ICPC competitor go on to build a great piece of software, yet I’m certain every ex-ICPC competitor would outperform the best software creators on interview-style questions.

Are there any great pieces of software written by ex-ICP champions?

Post reply on HN