Live data from Hacker News

Green Lumber Fallacy in Software Engineering

chrisbehan.ca

21–30 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#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 the one who solved the problem. When the competition is fierce, the candidate would probably still have to spend some time practicing on these problems.

Re: Green Lumber Fallacy in Software Engineering

#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 required to solve Hanoi's tower problem....

In fact, for the current job I am in got thru the initial interviews and then was told I needed to take online 'skills assessment' test to move forward - I told the interviewer (nicely) 'forget it, I don't want the job if I have to take the test; if my resume and track record isn't enough then maybe this isn't right for me.' (keeping in mind that I have a 30 year track record, not a recent college grad)

Guess the hiring manager agreed, because they hired me anyway (still haven't taken the test).

Re: Green Lumber Fallacy in Software Engineering

#24
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…

This is the #1 cause for me staying in my current position that I hate.

Re: Green Lumber Fallacy in Software Engineering

#25
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…

Interesting interview questions might be

- download this OSS project - explain to me where / how this API works, how deep does the call stack go. What tests exist for it?

- write me the spec for that call. discuss.

Re: Green Lumber Fallacy in Software Engineering

#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 is green if you look at it (being plant material which was recently alive). I'm not saying a full-size tree will be green like your kitchen garden basil stalks inside, but e.g. under the bark there are green hues.

I would never have thought it came from the "green = n00b" connection. Am I the mistaken one, now?

[1] https://with.thegra.in/green-lumber

Re: Green Lumber Fallacy in Software Engineering

#28

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 them with something meaningful. I'd even go so far as to say that we work bizarrely hard at asking uselessly inappropriate questions. It is easier to ask questions related to the real job.

Re: Green Lumber Fallacy in Software Engineering

#29
> All the MAANG companies use algorithmic and system design style questions as their main metric for hiring candidates. The internal justification for doing so is likely a combination of “this is what everyone else does” and “it’s a quick way to evaluate someone’s skill”.

They argue that this is the only way to weed out all these candidates. It is MAANG's version of the SAT.

> the best solution is to have trial work periods. There’s no better way to see how someone performs at the job than having them actually do the job.

Agreed. But how do they implement this?

Re: Green Lumber Fallacy in Software Engineering

#30
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, the material isn't a mystery.

Post reply on HN