Green Lumber Fallacy in Software Engineering • Hacker News Board

Re: Green Lumber Fallacy in Software Engineering

#211

Post by trollytroll69 » Fri, Jan 14, 2022, 1:24 PM UTC

tubby12345 wrote: post #147

YZF wrote: post #146

Earlier quoted context omitted.

I don't think anyone is saying never implement an algorithm. There's a time and place. I've seen code bases where these algorithms had ten different implementations, some of the with subtle bugs, some of them with some performance issues. Your code will also need to be maintained down the line. There's more to software engineering than writing toposort. Obviously(?) my Boost proposal was made in jest. Anyways, maybe…

>I just hope I'm not the one that has to maintain it down the road... i'm good at what i do - my implementations are clean. they got that way (surprise surprise) as a side-effect of me implementing many times.

every one says this, yet I've had on multiple occasions debug terrible implementations of lists/stacks. someone's lying

Re: Green Lumber Fallacy in Software Engineering

#212

Post by bluGill » Fri, Jan 14, 2022, 2:00 PM UTC

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…

The meaningful question for most DSA problems "does my standard library already have an an algorithm for this?", if no the proper follow up is "okay, I need to head to my library for a few hours to research if there is a known answer that I can copy - will I be given time to propose the addition of the algorithm to my languages standard library so nobody else needs to do this again?" I don't want someone write an algorithm in a couple hours, I want someone to write the one implementation that is correct.

Now sometimes there are compromises in algorithms (I can think of 3 different nlogn sorting algorithms and I think I've forgotten a dozen more) and so the company has a propitiatory library that has an implementation with different compromises. They should have benchmarks and pros and cons written down (ad ideally be open source) so that anytime someone asks about the algorithm they can point out why they have their own and possibly contribute it to the standard library if everyone agrees to a different compromise.

These days that vast majority of the simple algorithms have already been written. I might need someone to design a more complex algorithm, but they either takes months of thought, or are just a sequence of simple algorithms.

Re: Green Lumber Fallacy in Software Engineering

#213

Post by vanusa » Fri, Jan 14, 2022, 2:15 PM UTC

TulliusCicero wrote: post #189

vanusa wrote: post #159

Earlier quoted context omitted.

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

Yeah, that's what I see it as -- in part as a quick stand-in for a higher-end IQ test (or whatever of one wants to call "innate" intellectual ability). As well a way for the company to signal that of course they're all of very high innate intelligence themselves, and they know how to test you for it, too (by asking you to do what amounts to a few carefully rehearsed parlor tricks).

And lastly, as a cathartic bonding ritual: "You went in on this high-pressure, slightly (or sometimes very) humiliating performance rite with us together and it looks like you've passed! Or at least it seems now you do not have completely damaged DNA. Now we are ready to forgive and accept each other as equals, or some approximation thereof."

Re: Green Lumber Fallacy in Software Engineering

#214

Post by jerf » Fri, Jan 14, 2022, 2:59 PM UTC

capitalsigma wrote: post #181

jerf wrote: post #28

Earlier quoted context omitted.

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

Just is in programming, if you've abstracted away to the point that you're no longer even doing the task you started with, you've failed.

I don't care that you really really want a solution to P = NP; you can't have it. If you try to force it, you will pay the consequences.

I don't care that you really really want a single standardized interview for what is essentially several dozen distinct positions, even if they all "use computers". You can't have it. If you try to force it, you will pay the consequences.

If you suggested that companies should have completely standardized interviews for salespeople, lawyers, and executives, all because they "talk to people", you'd be laughed at. Change it to "talking to computers" and they lose the thread.

Re: Green Lumber Fallacy in Software Engineering

#215

Post by mylons » Fri, Jan 14, 2022, 4:37 PM UTC

tubby12345 wrote: post #138

YZF wrote: post #134

Earlier quoted context omitted.

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…

Quoted post unavailable.

you’re the kind of nerd sniper that gets off on this kind of interview style. it’s a well established phenomenon that LC style interviews do little than to fan the flames of the ego for the interviewer.

Re: Green Lumber Fallacy in Software Engineering

#216

Post by jcrites » Fri, Jan 14, 2022, 4:40 PM UTC

WalterBright wrote: post #132

jcrites wrote: post #52

Earlier quoted context omitted.

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

They are trivial to implement, but not desirable if you want your project to integrate with the company's existing codebase and be able to draw on a large base of preexisting algorithms.

A company like Google/Facebook(Meta)/Amazon doesn't want many redundant copies of binary tree implementations per language in their code base. In general they'd want one implementation with a suite of algorithms that can operate on it.

Maybe if your implementation is very specific to the task at hand it might make sense; otherwise I'd expect to use a binary tree via something like a sorted container interface. For example, in Java, something like java.util.TreeMap [1], which I understand is implemented as a binary tree.

Unless you were building a compiler or data store or something very specific and optimized, I see the need for building one as unlikely.

[1] https://docs.oracle.com/javase/7/docs/api/java/util/TreeMap....

Re: Green Lumber Fallacy in Software Engineering

#217

Post by jcrites » Fri, Jan 14, 2022, 4:43 PM UTC

anthuswilliams wrote: post #120

jcrites wrote: post #103

Earlier quoted context omitted.

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

Thanks for the information. I was not aware that employee compensation was exempt from that limitation.

I couldn't in practice see small companies choosing to go through the hassle of issuing stock to candidates for a week's worth of work though. It would be a lot of legal hassle for a process that's problematic for both sides.

Plus, you might end up with the problem of people interviewing at every hot startup that does a "1-week job trial" hoping to get some early stock at the next company that becomes a unicorn in 10 years.

Re: Green Lumber Fallacy in Software Engineering

#218

Post by walterclifford » Fri, Jan 14, 2022, 6:29 PM UTC

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…

> each of those questions is about a problem our team actually had to solve before

On my last job search I had one interviewer state (very proudly) the systems design question I was being asked was an actual problem his team had to solve. I don't doubt the veracity of his claim at all, but it probably wasn't solved by a single person under the time constraints and pressure of an interview.

Most likely someone on that team spent hours or days researching and designing potential solutions before drafting a design document that was shared and discussed with others, perhaps informally or perhaps in a meeting (or over the course of multiple meetings) where tradeoffs were considered among people with deep knowledge of the existing system and problem space. Expecting a candidate with only superficial (at best) knowledge of your current system to come up with the same or similar solution on their own in 30 or 40 minutes seems a bit unrealistic to me.

Re: Green Lumber Fallacy in Software Engineering

#219

Post by throwawaygal7 » Fri, Jan 14, 2022, 6:52 PM UTC

people in software tend to be introverts who sink a lot of their life and self worth into the job. We see the effects of this in the gatekeeping by elite software engineers who firmly believe the vast majority of degree holding, gainfully employed software engineers are complete idiots lucky to have a job - which is ridiculous.

The other side of it is the ridiculous notion some developers have of not having to meet these standards to get the best jobs.... two sides of the same coin that starts with an unhealthy attachment to your profession as your identity.

Re: Green Lumber Fallacy in Software Engineering

#220

Post by KerryJones » Fri, Jan 14, 2022, 7:00 PM UTC

stonogo wrote: post #196

KerryJones wrote: post #143

As a previous CTO and hiring manager, we did do trials, and it worked great. At the time I found an article showing that traditional interviews resulted in an 18% true-positive expectation of how they would perform, while a week-long trial got you to something like 73%. We paid them for the week like a contractor, and made an evaluation at the end of the week. It weeded people out who were great at code but bad cultu…

> but bad culturally Like people who are already employed?

We did a trial week with someone who ended up technically excellent, but the feedback I got from existing employees who worked with the candidate really didn't like the candidate (so we passed). This didn't come out in the culture screen we did prior to the week.