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

181–190 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#181

Post by capitalsigma »

jerf wrote: post #28
kokanator wrote: post #13

The post arrives at the wrong conclusion. DSA style problems are good if used correctly. Give a candidate a good challenge, preferably with some requirements that can have different interpretations, ask them questions, help them and collaborate with them. The analysis of the whole exercise should be your hiring determination not whether the problem was actually solved. Did the candidate: - stick with the problem? - a…

What is unique about "DSA style problems" that makes it that only through them you can see if they stuck with the problem, asked meaningful questions, etc.? Why not ask them real questions about the real sorts of things they're going to do, and through those see if they stuck with the problem, asked meaningful questions, etc.? DSA problems don't bring anything to the table here, because it's trivial to substitute the…

Most of the substitutes you might want to pick are specific to a particular domain (webdev, for example). If you run a big company, you want to give a generic interview that gives you signal on a candidate's fit with a wide variety of teams that touch many domains. So you abstract away the domain-specific parts of the task until you have something that is broad enough to apply to many subdomains... and now you're doing DSA interviews, because DSA is exactly the bits of coding that are generic, abstract, and applicable to many domains.

Re: Green Lumber Fallacy in Software Engineering

#183

Post by eternityforest »

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…

Knowing that O(n2) is a problem and that an O(n) algorithm exists matters. But why do they have to know how to write that O(n) themselves?

It's a quick easy test of understanding, but why not ask "How would you speed this up" and show them some O(n2) code?

Re: Green Lumber Fallacy in Software Engineering

#184

Post by eternityforest »

tubby12345 wrote: post #142
YZF wrote: post #139

Earlier quoted context omitted.

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

Quoted post unavailable.

If you're doing things in C++ you're already doing very specialized stuff, nobody can advise without actually knowing the app well. Especially if you have an app that rubs in all those different situations.

But... boost seems pretty common. Everyone seems to complain about it, but if it replaces a whole pile of hand written things, it looks like it could really bring some consistency to a project. I've never done serious C++ outside of embedded though, so I don't have Boost experience.

In a dynamic language like JS, you'd search for "Graph theory algorithms library" and probably find one with ten million downloads, investigate the maintainer a bit, and use it.

Re: Green Lumber Fallacy in Software Engineering

#185

Post by joshuamorton »

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.

This is such a funny thing to read, because I see new L6 and 7 tech managers hired (above me) all the time. They're often middle aged people with kids. They don't bemoan this stuff (and yes, while they have fewer of them, they still need to solve a whiteboard problem or two to get hired)

Re: Green Lumber Fallacy in Software Engineering

#186

Post by lordnacho »

tubby12345 wrote: post #177
lordnacho wrote: post #174

Earlier quoted context omitted.

How did you get the interview? They must get a lot of junk applications, what did you write to make them actually look at you instead of direct to trash, and then decide to interview?

easiest way to shortcircuit the process is to reach out to someone through linked in and ask for a referral. if you're really who you claim to be in your profile here then you shouldn't have any trouble getting an interview.

Well I'm not looking for myself. Was wondering if it's the case that they'll interview any CS grad?

Re: Green Lumber Fallacy in Software Engineering

#187

Post by YZF »

random314 wrote: post #153
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...

I have worked with engineers who treated their work as glueing together various services to get the results required. They were absolutely shit engineers, whose approach to building services for massive scale were simply 1. Glue together whatever services are available and seem to make sense. 2. Throw increasing amounts of traffic at it and check what fails 3. Try to patch around failure point 4. blame the service pr…

You're missing the point. What you're describing has nothing to do with memorizing data structures and algorithms. Having those guys memorize those won't make them better engineers, right?

Sounds you understand locking and distributed locks. Cool. Your next project is a video encoder. Write an arithmetic coder in a 20 minute interview? Motion detection? Your next project is a chess engine. Write minimax with alpha-beta cutoff in an interview? Your next project is public key cryptography ... A distributed k/v database... Can you write a bloom filter for me in an interview? Gradient descent in some machine learning application?

If you're such a great software engineer, which likely you are, you should be able to do all the above (at least somewhat), by doing your research, and writing code.

I'm not saying hire bad engineers. I'm saying the game is silly. Sure, a good engineer (and people that aren't so good) can play the game. Also not arguing with the person that said if your goal is to get paid better and you want that job then play the game. Doesn't make it less silly.

Re: Green Lumber Fallacy in Software Engineering

#188

Post by disgruntledphd2 »

osigurdson wrote: post #31
disgruntledphd2 wrote: post #14

Earlier quoted context omitted.

If we're going to use Meta for the acronym, then for God's sake can we call them MANGA? More generally, the absurd success of most of Big Tech has not come from better technology but extremely high margins facilitated by software. Apart from the core ranking/ads problem that M and G solve, most of it doesn't need to be that complicated. I would venture that lots of the cool technology stuff is designed to keep engine…

According to Jim Cramer (who came up with the FAANG acronym), we should now be using MAMAA (Meta, Apple, Microsoft, Amazon and Alphabet). https://finance.yahoo.com/news/not-faang-mamaa-jim-cramer-16...

I kinda agree with that, but MANGA is such a great acronym that I'd like to keep it.

Re: Green Lumber Fallacy in Software Engineering

#189

Post by TulliusCicero »

vanusa wrote: post #159
TulliusCicero wrote: post #155

Earlier quoted context omitted.

> Problems like designing "the most popular package manager on macOS", for example? Yes, those fall through the gaps, but people with that kind of extremely strong, publicly viewable history are much more the exception than the norm.

Does have to be not just "strong" -- but "extremely strong" evidence? Not to split hairs - but it does seem to be a peculiar choice of words, there. I just don't see why the DSA filter has come to be considered so golden that one's ability to not just demonstrate some baseline capacity for this skillset, but to positively master a sequence of concocted performative rituals around it (specifically: reciting these algo…

> Not to split hairs - but it does seem to be a peculiar choice of words, there.

Perhaps not; I think the "publicly viewable" part is going to the sticking point, most of the time. Most people don't have significant/impressive side projects that they can show off to prospective employers, their work is at prior companies.

Anyway, I can see why DSA interviews are popular. IIRC studies show IQ tests and work sample tests are two of the most effective interviewing techniques, and algorithmic whiteboard coding splits the difference between the two, and does so in a way that's relatively platform/stack-agnostic. Especially useful since IQ tests themselves are of dubious legality.

Re: Green Lumber Fallacy in Software Engineering

#190

Post by mehrdada »

aeronaute wrote: post #106
paxys wrote: post #85

Earlier quoted context omitted.

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.

I bet they have spent a lot of money on it. How about those folks at Google that, when they were unknowingly reviewing their own packets from when they originally interviewed, decided that they wouldn't even hire themselves? Google also found that interview performance isn't a good predictor of on-the-job performance. Sorry, but it's hard to take this style of interview seriously after hearing about these things.

> Google also found that interview performance isn't a good predictor of on-the-job performance.

People repeat things like this without really understanding statistics and priors and what that assertion really means. Assuming that statement is true, it applies only to Googlers who have been hired by the hiring process, i.e. if you are beyond the cutoff threshold of the interview process, the ranking within that subset is not determined by the interview performance. That in no way implies that among all the interviewees, including the rejects, the job performance would not have been correlated with their interview performance, had they been hired, hypothetically.

Post reply on HN