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

131–140 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#131

Post by XorNot »

YZF wrote: post #128
Hermitian909 wrote: post #123

Earlier quoted context omitted.

I do think there's a real place for interview questions where you identify algorithmic opportunities in real world problem scenarios quickly, but you also may be missing some of the incentives for testing the way it's currently tested: Coding floyd-warshal importantly shows that you can code, and generally signals at least one of two things: 1. You studied hard for the interview, you're willing to do difficult and un…

I would say: 1. You're fresh out of school or you have a lot of time on your hands. 2. You memorized some interview preparation book. I do agree that a candidate that has shown some effort preparing for an interview is a positive. Other than that this seems like a silly game. The flip side is the candidate that memorized the book, prepared like it's a test at school, and is useless on the job, can't operate at all ou…

I mean it's also a pretty good filter by age: if you're middle aged, working and have children, then you're not going to really have the time to get through memorising a bunch of leetcode.

Which is handy because Google et al don't really want employees who look at the in-office perks and wonder why they'd be appealing at all if you're just going to go home at the end of the day.

Re: Green Lumber Fallacy in Software Engineering

#132

Post by WalterBright »

jcrites wrote: post #52
compiler-guy wrote: post #7

The test isn't so much about the ability to invert a binary tree (for example), but the ability to problem solve complicated problems where the obvious solution is probably not the best one. In interviewing, it is hard to produce real world problems that don't require a huge amount of context and details of some obscure software stack, so we go with abstract problems which are kind of irrelevant to real work, but the…

This actually seems like a pretty simple problem, to be honest, where the obvious solution is the best one. Inverting a binary tree means reversing the order of the sequence of elements that it represents. Thus inverting a binary tree is simply swapping the left and right edge of every node recursively down the tree. You could do this with a recursive algorithm by modifying the tree in-place or by constructing a new…

> The reason is that programming tasks like this are pretty uncommon to encounter as a professional software engineer.

I'm not so sure. One aspect is even recognizing that the task can be done by a known algorithm. Not knowing the algorithms may make one mistakenly believe that the opportunity to apply algorithms never came up.

> I can’t imagine that you would need to build a binary tree data structure or an algorithm for inverting them

I'm sorry, they are so trivial it takes more work to understand the documentation on the library one than it takes to just do it.

Though personally, if a candidate flunked the binary tree question, but had a very successful project, I'd take a closer look before rejecting him. For one thing, I'd want to have a look at the project's source code. I'd also want to verify he'd actually written the code for that project.

Re: Green Lumber Fallacy in Software Engineering

#133

Post by WalterBright »

tubby12345 wrote: post #130
WalterBright wrote: post #126

Earlier quoted context omitted.

Over and over, I see code written by star professionals that you've heard of, reinventing the bubble sort. I'm guilty of it myself. > 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,…

if i need a toposort in my proprietary task scheduling system, or fisher–yates shuffle in my proprietary ranking system, what do you recommend? this isn't hypothetical - i've had these things come up in the last half at work.

Bubble sort is really bottom of the barrel.

Re: Green Lumber Fallacy in Software Engineering

#134

Post by YZF »

tubby12345 wrote: post #127
YZF wrote: post #118

Earlier quoted context omitted.

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

Quoted post unavailable.

Sorry but this is completely wrong.

Not needing to code Floyd–Warshall on the job is not equal to "high-level apis and glue code". You can totally recognize the opportunity for the correct data structure or algorithm despite not having them all in your head all the time. That's exactly what a good software engineer does.

But if you think you can code up any algorithm in any domain on the fly I'm sure I can find some good interview question for you. I mean there's only like 5 algorithms in the world, right? I'm sure you have at least all the volumes of Knuth memorized... And if not, you must just be writing glue code ;)

Re: Green Lumber Fallacy in Software Engineering

#135

Post by tubby12345 »

WalterBright wrote: post #133
tubby12345 wrote: post #130

Earlier quoted context omitted.

if i need a toposort in my proprietary task scheduling system, or fisher–yates shuffle in my proprietary ranking system, what do you recommend? this isn't hypothetical - i've had these things come up in the last half at work.

Bubble sort is really bottom of the barrel.

what was your point? that it's silly to reinvent the wheel over and over. so i gave you an example of a wheel (two) that often needs to be reinvented.

Re: Green Lumber Fallacy in Software Engineering

#136

Post by WalterBright »

XorNot wrote: post #129
WalterBright wrote: post #126

Earlier quoted context omitted.

Over and over, I see code written by star professionals that you've heard of, reinventing the bubble sort. I'm guilty of it myself. > 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,…

I mean this is also what happens when pilots aren't following their checklists though.

Checklists in an emergency are the same idea as Dealer's Strategy in blackjack. If you've got nothing better, or are under so much stress you can't think, or don't have time to think, do Dealer's Strategy. But sometimes, pilots are needed to recognize when the checklist isn't going to work, and can innovate on the job. That's why we still have pilots on airplanes, as a computer can follow a checklist.

Re: Green Lumber Fallacy in Software Engineering

#137

Post by BurningFrog »

XorNot wrote: post #131
YZF wrote: post #128

Earlier quoted context omitted.

I would say: 1. You're fresh out of school or you have a lot of time on your hands. 2. You memorized some interview preparation book. I do agree that a candidate that has shown some effort preparing for an interview is a positive. Other than that this seems like a silly game. The flip side is the candidate that memorized the book, prepared like it's a test at school, and is useless on the job, can't operate at all ou…

I mean it's also a pretty good filter by age: if you're middle aged, working and have children, then you're not going to really have the time to get through memorising a bunch of leetcode. Which is handy because Google et al don't really want employees who look at the in-office perks and wonder why they'd be appealing at all if you're just going to go home at the end of the day.

If you're a good middle aged engineer, you should have enough former coworkers happy to hire you that you don't need get on the leetcode treadmill.

Re: Green Lumber Fallacy in Software Engineering

#138

Post by tubby12345 »

YZF wrote: post #134
tubby12345 wrote: post #127

Earlier quoted context omitted.

Quoted post unavailable.

Sorry but this is completely wrong. Not needing to code Floyd–Warshall on the job is not equal to "high-level apis and glue code". You can totally recognize the opportunity for the correct data structure or algorithm despite not having them all in your head all the time. That's exactly what a good software engineer does. But if you think you can code up any algorithm in any domain on the fly I'm sure I can find some…

No post body was provided.

Re: Green Lumber Fallacy in Software Engineering

#139

Post by YZF »

tubby12345 wrote: post #130
WalterBright wrote: post #126

Earlier quoted context omitted.

Over and over, I see code written by star professionals that you've heard of, reinventing the bubble sort. I'm guilty of it myself. > 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,…

if i need a toposort in my proprietary task scheduling system, or fisher–yates shuffle in my proprietary ranking system, what do you recommend? this isn't hypothetical - i've had these things come up in the last half at work.

There ya go: https://www.boost.org/doc/libs/1_78_0/libs/graph/doc/topolog...

Re: Green Lumber Fallacy in Software Engineering

#140

Post by majormajor »

tubby12345 wrote: post #124
vp8989 wrote: post #116

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.

I have said this before: it's group therapy for entitled devs that feel they're entitled to oversized salaries just because they have tenure. Young grads accept the process as is. People that are either happy with their comp or comfortable putting in the work do not lament the process - they just accept it and proceed. Only devs that have been doing it a while, whose salaries have plateaued, that either never learned…

From friends and acquaintances in other industries with similar income distributions, "knock out 4-to-6 programming problems in a short amount of time" is one of the least-arbitrary and most accessible ways to jump from one group to the more highly paid one. Not to mention that if you can knock out those problems, you may not even be required to have a degree or other formal credentials.

That's not even getting into how hilariously unrealistic "trial periods", for instance, are. Why am I going to leave a job for just a trial period without any more thorough attempt to check fit before hand? Why would I invest that much time in side work if I'm doing it before quitting, when I could get a FAANG offer instead for single-digit-days-amount of brushing up?

Post reply on HN