Live data from Hacker News

Green Lumber Fallacy in Software Engineering

chrisbehan.ca

31–40 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#31

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…

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

Re: Green Lumber Fallacy in Software Engineering

#32
post #23
post #9

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

>>partly responsible for why so many devs stay in the same position That is why I am staying put for the time being; hate the interview process, hate being asked stupid questions about solving problems that I will never have to solve in real life. Ask me about projects I have worked on, ask me about code I have developed ask about my experience etc - but I am still looking for the development job where I will be requ…

I have a very talented SWE friend who only left a now-public unicorn because they were recruited by a former colleague at a startup they knew wouldn't involve leetcode in the interview process.

I have another very talented SWE friend who has been doing leetcode exercises off and on for months and is struggling to start doing applications even though they do not like their current work and are undercompensated.

They fear they will fail algo / data structures and yet this person has an excellent public track record of quality contributions and comms in FOSS.

From what I've observed leetcode screens are problematic enough that they are causing market inefficiency.

Re: Green Lumber Fallacy in Software Engineering

#33
post #21

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…

I agree with everything you said. The best interviews ive had are those where I felt like I am working together with the interviewer. I think being able to handle criticism is an important trait to look out for. Many times interviewees will defend their method too aggressively. But if you have to pick between two people who are equally pleasant to work with, but one was able to solve the problem, you'll probably pick…

I interview candidates at a company with a relatively high volume of interviews and I use DSA criteria in my interviews. But here's what I do:

- I phrase the question in a way that has some semblance of day-to-day relevance. That is to say that at some point in the process of coming up with a solution, the ability to apply a relevant data structure will come up, but it will be in service of an end goal that looks like the deliverable of a sprint task.

- I come into the interview aware of multiple solutions and I am open to any of them.

- I pace feedback so that the candidate actually solves the problem by the end of the interview, no matter their level (which does mean, in some cases, literally spelling out the step to unblock themselves).

The rationale is that solving a hard DSA question doesn't give me all that much signal in and of itself. Watching a candidate bang out something with a level of complexity a little higher than fizz buzz is usually sufficient to evaluate whether the candidate has familiarity with the language. The choice of idioms and APIs can tell me things about their relative level of expertise with the stack (i.e. it can generally be safely assumed that an already employed candidate can hold their candle, and the question for me is more along the lines of "to which extent").

During the course of an interview, I can usually pick up a distinct and noticeable difference in focus between candidates, especially surrounding topics related to proactiveness/curiosity (e.g. does the candidate have understanding of aspects one abstraction level lower than the API they usually use, are they aware of well known pros and cons of some specific idiom, does their argumentation seem derived from personal experience vs parroted from a hivemind, etc). This tends to correlate surprisingly accurately to how much autonomy and growth they demonstrate on the job.

"Hardcore" DSA evaluation only really comes in as a criteria to determine whether the candidate is of very high quality when most other criteria have already been evaluated as acceptable/desirable. These nice-to-have criteria come into play in some cases where I want to advocate for the candidate when the evaluation panel is split due to one seemingly bad session (possibly due to factors such as nervousness or mixed signals), or inversely when the role logically demands a higher bar but the panel is situationally incentivized to hire down to meet a quota.

I've been told by several candidates that they appreciate my interviewing style, and conversely, I feel like I get a much better feel for the candidate than strictly evaluating DSA skills and nothing else.

Re: Green Lumber Fallacy in Software Engineering

#34
post #8

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

I've spent a lot of time fixing or working around messes caused by people who don't know algorithms and data structures. If you don't know about those problems then you're likely to solve one without recognizing it and do a poor job of it. Worse if you don't have data structures and algorithms training you're unlikey to be able to reason about time and space complexity.

Unlike at startup or enterprise dev shops, at the scale of FAANG, those sorts of problems (e.g. turning n into n*2 and the like) at a backend are very likely going to cause crashes or something essential to time out. If you haven't worked on a service with 5-10K or more servers you aren't likely to really get how quickly and how frequently things are going to go bad if you aren't very careful.

There aren't many if any engineers designing bridges who haven't had the entire curriculum. If you want to practice independently as an engineer then you have to get a license which involves taking a hard test which recaps your entire undergrad curriculum and maybe more. I peeked over my brother's shoulder when he was studying for the EIT. Not easy to pass. And like doctors and lawyers they have to keep up with their professions to renew their licenses. So, no.

Re: Green Lumber Fallacy in Software Engineering

#36
post #26

While trying to read more about the actual case of the trader who didn't know what he was trading, I found [1] which contains this quote: > The “green” in green Douglas fir refers to the fact that it has been newly cut (it has not been dried), just like someone who is new at something is referred to as green. This was interesting/funny to me, since I was sure that the name "green lumber" comes from the fact that it i…

See also "green cheese". "Green" has metaphorically meant "fresh, new, immature" in English for a long time. I don't think that quote is claiming that it _came from_ "green = n00b" but that it shares the same source.

Re: Green Lumber Fallacy in Software Engineering

#38

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…

In reality though, you learn how to solve a bunch of categories of problems on your own time, then put on a show where you go from the naive solution to the correct one. It's not as if someone is going to figure out dynamic programming during the interview, and once you know those concepts it is pretty apparent where to apply them. Honestly, I probably wouldn't even come up with the trick for the 3sum problem during an interview. Maybe I am dumb or maybe this is common, but the only reason I pass is because I've done the leetcode grind. The interview is just performative.

Re: Green Lumber Fallacy in Software Engineering

#39

Reasons we test for data structures and algorithms: - The work sucks because existing employees don't know DSA's - We want people to re-implement and refactor with better DSA's - We want to know the candidate studied for the interview (took it seriously) - We actually do want them to know DSA's when joining the team - It's the least you can do when applying for a CS job Most recruiters provide links and resources, th…

The material is irrelevant, at least for most software engineers. (For a FAANG, not so much. But for most places? Irrelevant.)

I understand the time-space tradeoffs of the various STL collections, and the Java collections. In 35 years, that's been all I have needed. (And, if it does come up, why spend months memorizing what I can spend minutes googleing?) I am not a huge outlier.

Interview for what you need. Anything else is wasteful. Do your people spend most of their time trying to squeeze the absolute most efficiency out of their data structures and algorithms? If so, yes, interview for that. If not, though, then don't interview for that.

Leetcode interviews when that doesn't match the work are just abuse. "Here, take months of your spare time learning to jump through this hoop that's actually irrelevant to the job." That's abuse. The only way that makes any sense is if you need employees that you can continue to abuse after you hire them. And if so, then I don't want to work for your company.

As I said, FAANGs are an exception. They need people who can go from n (log n)^2 to n log n. It makes a huge difference to them. If that's your company, then I'm not talking about you.

Re: Green Lumber Fallacy in Software Engineering

#40
post #8

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

I've spent a lot of time fixing or working around messes caused by people who don't know algorithms and data structures. If you don't know about those problems then you're likely to solve one without recognizing it and do a poor job of it. Worse if you don't have data structures and algorithms training you're unlikey to be able to reason about time and space complexity. Unlike at startup or enterprise dev shops, at t…

> I've spent a lot of time fixing or working around messes caused by people who don't know algorithms and data structures.

Rare these days, that kind of mess unless the entire department is off kilter. Contemporary practice is to team up, and be in constant communication about the code base, requirements, approaches. Someone in the team or adjacent will know the proper approach and be able to communicate it to the others.

Post reply on HN