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

111–120 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#111

Post by amscanne »

dragonwriter wrote: post #87
amscanne wrote: post #80

Earlier quoted context omitted.

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…

The point there is standardized. If you apply a standardized test, then it becomes feasible to measure and argue the disparate impact.

For all their failings, leetcode-style interviews are probably less culturally-sensitive than standardized IQ tests. They probably do have (unintentional) disparate impact, but this seems like a really hard thing to measure (and possibly correct for).

Re: Green Lumber Fallacy in Software Engineering

#113

Post by xsmasher »

lhorie wrote: post #104
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…

One needs to be especially careful with adapting experience to interview questions. Unlike the candidate, you probably were already immersed in the problem domain for months or years and have good context in what techniques exist and are relevant to the problem domain. One mistake some interviewers make is implicitly assuming that candidates can somehow conjure the same level of context from first principles, or that…

Every time I feel "this would be a good interview question!" it is not. It's usually something juicy that I chewed on for two days. How can I expect a candidate to solve it in 45 minutes?

Re: Green Lumber Fallacy in Software Engineering

#114

Post by dragonwriter »

amscanne wrote: post #111
dragonwriter wrote: post #87

Earlier quoted context omitted.

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

The point there is standardized . If you apply a standardized test, then it becomes feasible to measure and argue the disparate impact. For all their failings, leetcode-style interviews are probably less culturally-sensitive than standardized IQ tests. They probably do have (unintentional) disparate impact, but this seems like a really hard thing to measure (and possibly correct for).

> If you apply a standardized test, then it becomes feasible to measure and argue the disparate impact.

Yes, the existence of readily available statistics may make the unequal impact easier to show.

> For all their failings, leetcode-style interviews are probably less culturally-sensitive than standardized IQ tests.

“Culturally sensitive”, maybe, but they almost certainly have quite large unequal impacts adverse to protected classes (including “age, if over 40”), though the absence of external data raises the cost of proving the unequal impact. Also, certainly less demonstrably predictive of job performance in software development.

> They probably do have (unintentional) disparate impact

Probably, that, as well, but I don't think the age discrimination function largely is unintentional to start with.

Re: Green Lumber Fallacy in Software Engineering

#115

Post by tacostakohashi »

I used have a similar perspective as the author, that the leetcode style questions / data structure / algorithm stuff they ask in interviews but seems to have little to do with day-to-day corporate software development is all a big waste of everyone's time.

I'm not sure I still do, though.

It's true that this stuff rarely comes up and often doesn't matter for most real-world applications... but when it does, it matters a lot. The difference between O(n2), O(n) and O(log n) is huge for big values of n. Being about to go straight to a (nearly) optimal solution, instead of hacking together something, waiting for it to burst a the seams, and then having to fix it... or being able to spot someone else doing that, can save weeks or months of development at a time.

It's a bit like saying it's silly for pilots to have to know what to do in the case of engine failure or stall from memory and regularly practice in a simulator, because that stuff rarely happens and most of the time they're just using autopilot. That's true, it usually doesn't matter, but when it does... it matters a lot.

Re: Green Lumber Fallacy in Software Engineering

#116

Post by vp8989 »

Its shocking to me how people don't get bored of rehashing this same, tired opinion over and over and over again and discussing it with hundreds of comments. There is a blog post like this every other day on the front page of HN and it always generates the exact same discussion.

Re: Green Lumber Fallacy in Software Engineering

#117

Post by anthuswilliams »

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…

Agreed. This idea could only by put forth by someone who has never had to do the work involved in hiring a software engineer.

Re: Green Lumber Fallacy in Software Engineering

#118

Post by YZF »

tacostakohashi wrote: post #115

I used have a similar perspective as the author, that the leetcode style questions / data structure / algorithm stuff they ask in interviews but seems to have little to do with day-to-day corporate software development is all a big waste of everyone's time. I'm not sure I still do, though. It's true that this stuff rarely comes up and often doesn't matter for most real-world applications... but when it does, it matte…

When it comes up do you need to code it up in 20 minutes or is looking the algorithm up in a textbook ok? If all you want to test that sort of knowledge just ask the knowledge question. I don't need to memorize Floyd-Warshal and be able to code it on demand to be able to recognize when it's needed and look it up. I'm sure I remembered it back in school, haven't used it since, but if the day comes I'll look it up...

Re: Green Lumber Fallacy in Software Engineering

#119

Post by dredmorbius »

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…

The increasing prevalence of the acqui-hire seems to me to be one manifestation of this.

Allow a team to come together, demonstrate an ability to work together, to define a project (hopefully one of interest to the acquirer, if not in the output than in the process which develops it), then hire based on proven ability.

Or at least that's one interpretation, and amongst the more charitable, of the practice.

Re: Green Lumber Fallacy in Software Engineering

#120

Post by anthuswilliams »

jcrites wrote: post #103
lhorie wrote: post #89

Earlier quoted context omitted.

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…

> 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 unworkable for anyone who is already employed. What am I going to do: use a week of vacation for this “interview”? (The fact that I’d be paid is immaterial: I lose vacation time. Plus, the more senior you are, the more of your compensation is in equity. W…

The maximum number of stockholders for a private corporation is 2000, and it excludes stock awarded as part of employee grants, so that point is not a factor. But your other points still aptly demonstrate the utter lunacy of this idea.
Post reply on HN