Green Lumber Fallacy in Software Engineering
chrisbehan.ca
Green Lumber Fallacy in Software Engineering
1–10 of 238 posts
Re: Green Lumber Fallacy in Software Engineering
#2> solving DSA-style problems and building software are two different things
disagree. I'd say that both are needed skills for software. Software is made layers, like a cake. Maybe DSA style problems are like grounding the flour (or making the oven itself?) and the other building skills (which I agree, seem like different skillsets) are about decorating the cake and mixing the dough or something.
So in practice nobody is grinding their own flour; the flour is being bough already processed (in programming this'd correspond to importing the algorithms from a lib)
Re: Green Lumber Fallacy in Software Engineering
#3sure, but if performance in those types of questions are a good predictor of success in the job then I'd go on asking them. Probably they aren't but just saying "I won't need this in my job so I won't ask in an interview" is short sighted.
Re: Green Lumber Fallacy in Software Engineering
#4> solving DSA-style problems and building software are two different things disagree. I'd say that both are needed skills for software. Software is made layers, like a cake. Maybe DSA style problems are like grounding the flour (or making the oven itself?) and the other building skills (which I agree, seem like different skillsets) are about decorating the cake and mixing the dough or something. So in practice nobody…
I agree to a certain extent, it has been in my mind the big difference between impactful engineers and engineers that do a lot of stuff, it seems that many people can write code, but being able to conceptualize the software at the layer of DSA's allows one to flow fluidly from multiple levels of abstractions and aspects of the problem more seamlessly.
That being said I also have serious beef with "architects" whose primary capabilities are programming in powerpoint and being professional XML developers.
Re: Green Lumber Fallacy in Software Engineering
#5I very much agree. But this is written in a somewhat "this is bad" style and misses the "you should do this, instead" part. This article contains both: https://talktotheduck.dev/debugging-the-technical-interview-...
Re: Green Lumber Fallacy in Software Engineering
#6Data structures and algorithms are important to very important in software engineering and I think it's quite right to include questions on them in interviews.
But that's not the same as knowing by heart how to implement non-trivial algorithms. There's the green lumber fallacy.
To have a feel for the 'right' data structures and algorithms to use for specific problems is a key skill. But then the detailed algorithm is only one Google away these days, although I would expect someone to be able to derive the simple ones themselves.
Re: Green Lumber Fallacy in Software Engineering
#7The 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 problem solving approaches you need to take are very relevant. Thinking about the requirements, thinking at the right level of abstraction, defensive coding, to name just a few.
Communication and whatnot are all on top of that, and yes, absolutely do need to be evaluated.
I'll also note that MAANG companies have extremely sophisticated software stacks (and multiple ones for each company!) that were built by people who were hired using that method.
If it is wrong, it's working pretty darn well.
There are many things I would change if I could, but we do have an existence proof that, in the aggregate at least, the people this interviewing method selects for can build amazing software stacks.
Re: Green Lumber Fallacy in Software Engineering
#8In the physical world there are folks who design bridges, dams, buildings, telescopes, furniture, and a million other things. All of those have unique requirements and skill sets. In software, we also make a huge number of categorically different systems each with its own skill set, but we call all of it 'software engineering.'
There are folks who are great at their job (called "software engineering") and their work never invokes their knowledge of algorithms. There are also folks who spend day in and day out tuning and designing new systems and deep knowledge of algorithms is essential (we also call this "software engineering").
Re: Green Lumber Fallacy in Software Engineering
#9I think this phenomena is at least partly responsible for why so many devs stay in the same position and why they are difficult to find/hire.
Before a tech interview, good candidates will spend a large amount of time doing 'homework' which is just practicing answering the asinine questions that tech interviewers give that is usually barely relevant to the position, if at all.
Equally, if not more important, is the candidate's experience or ability to navigate legacy code, testing philosophy, handling incomplete/inconsistent requirements, and attention to detail, among other traits. Of course these won't merit the same attention in an interview.
On the one hand firms have difficulty finding good candidates, on the other hand they are giving ridiculous tech interviews that aren't a great judge of what kind of employee they will be.
Re: Green Lumber Fallacy in Software Engineering
#10> I’ve never heard of an ex ICPC competitor go on to build a great piece of software
Telegram.