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

91–100 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#91

Post by jcrites »

paxys wrote: post #60

Data structures and algorithms questions are a perfect proxy for (1) is the candidate smart and (2) can the candidate write moderately complex code (arrays, hash maps, pointers, nested loops). 90% of candidates will fail 2, and you will get a good idea of the rest with 1. Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have.

Why not ask the candidate to solve a problem of the type that they are likely to encounter while actually working at your company: the kind of task that you would ask them to perform on day one.

Inverting a binary tree is not the kind of task that is a software engineer is likely to have to perform at most companies. I think companies can come up with better questions that still involve algorithms and data structures but better correspond to problems that they professional software engineer might actually need to solve.

For example, to repeat a comment I made elsewhere in this thread, ask them to serialize a binary tree to a byte stream, and deserialize the same tree from a byte stream. There are plenty of edge cases in this problem; you learn whether they understand a data structure (binary tree) and how to implement it, as well as how to write algorithms that operate on it (potentially a recursive descent on the tree; potentially a visitor, depending on how the candidate designed the tree).

This also isn’t a problem I’d directly expect to solve during regular work, but it’s useful and close enough: serializing/deserializing objects (data structures) is something I’ve had to do in reality plenty of times. (Even if you’re using an RPC library or IDL, you often have to “serialize“ in the sense of translating into the business object into one generated by the IDL or RPC client)

Re: Green Lumber Fallacy in Software Engineering

#92

Post by maerF0x0 »

> software development is not data structures and algorithms.

Software development is almost entirely about understanding what others want and then translating them into Data structures and algorithms. Author could have meant software development is not about implementing already implemented data structures and algorithms. imo better questions would have a candidate using the DSAs than implementing them. eg: questions that require them to use binary search, bitsets etc

Re: Green Lumber Fallacy in Software Engineering

#93

Post by lsalvatore »

paxys wrote: post #60

Data structures and algorithms questions are a perfect proxy for (1) is the candidate smart and (2) can the candidate write moderately complex code (arrays, hash maps, pointers, nested loops). 90% of candidates will fail 2, and you will get a good idea of the rest with 1. Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have.

Bingo. Smart people understand the domain of interview questions (which we know is contrived) and typically can study enough to implement the solutions. It's not always about getting the question right- it's about demonstrating you are smart, but also these questions are core CS fundementals so it also tests that they have a formal education. Anyone can learn Git, JS, but how many can apply a programming language to a complex problem on the spot?

Re: Green Lumber Fallacy in Software Engineering

#94

Post by jzoch »

caethan wrote: post #57
riddleronroof wrote: post #53

Earlier quoted context omitted.

I bet you have. But how long did you have to solve it? Did you have access to the internet, talking out ideas with your colleagues, coffees? I agree that you can’t simulate real scenario in an interview, but you can also acknowledge that the process is a little cartoonish.

Interviewees are encouraged to use Google, code on a laptop rather than on a whiteboard, etc. Sadly, I only get an hour to interview people rather than a week. But I have had people complain about "completely unrealistic problems unrelated to the real work" when the problem is something I literally had to solve 3 months ago.

To be fair, you could just give them the question ahead of time. Email them 3 days before their interview with the question and say see you soon. That is much closer to actual conditions

Re: Green Lumber Fallacy in Software Engineering

#95

Post by paxys »

jcrites wrote: post #91
paxys wrote: post #60

Data structures and algorithms questions are a perfect proxy for (1) is the candidate smart and (2) can the candidate write moderately complex code (arrays, hash maps, pointers, nested loops). 90% of candidates will fail 2, and you will get a good idea of the rest with 1. Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have.

Why not ask the candidate to solve a problem of the type that they are likely to encounter while actually working at your company: the kind of task that you would ask them to perform on day one. Inverting a binary tree is not the kind of task that is a software engineer is likely to have to perform at most companies. I think companies can come up with better questions that still involve algorithms and data structures…

"Invert a binary tree" is something that keeps coming up in discussions like this one but isn't a real question that is often asked. Some of the questions I have personally come across in coding interviews with large companies (Google, Uber, Square, Twitter, LinkedIn):

- Implement a LRU cache

- Implement a rate limiter

- Read and process a very large file line by line

- Combine two sorted streams

- Calculate the sum of a specific section of a MxN grid

- Parse and solve a math equation

- Find the nth most common word in a blob of text

These are all pretty realistic representations of what a software engineer can be expected to do day to day.

Re: Green Lumber Fallacy in Software Engineering

#96

Post by jfengel »

tetsuhamu wrote: post #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, th…

It's the least you can do when applying for a CS job

I think that's precisely it: it's the least you can do. Students are taught data structures and algorithms because they don't know anything else. They can sort numbers and munge strings... and that's all.

They don't know any frameworks. They don't know any problem domains. They don't know how to debug, or read an API, or identify code smells.

But they have to write something, and if you want that something to be more than three lines long you have to make them do something complicated with the incredibly limited domain of knowledge they have. Thus, data structures and algorithms.

Nobody ever needs to calculate Fibonacci numbers. But if they can't write a recursive descent compiler, or even handle an HTML parser, they have to learn to write recursive code on something. Thus, they do something trivial.

And then they forget it, because they've applied that knowledge to something more useful. Much as you never do long division by hand, even though you had to learn how to, and you would possibly screw it up if handed one now.

A student getting a BS had better know a lot more than the least of it. Test it if you can't think of anything else that might know, but it's not going to tell you if they know anything that matters.

And the engineer with more experience is even less likely to have used that freshman-year stuff recently. As you say, it can tell you that they cared enough to cram it again... but they're cramming it because they don't actually need it.

Re: Green Lumber Fallacy in Software Engineering

#97

Post by 0xbadcafebee »

mytailorisrich wrote: post #43
0xbadcafebee wrote: post #20

Earlier quoted context omitted.

Data structures and algorithms are just parts, like screws and nails. When you're building a house, you don't need to remember if you should use 2 18-penny nails or 3 16-penny nails, or if you can use screws, and what kinds. What matters is that you know how to go look up the building code, find out what's required, use those parts, know how to verify they're installed correctly, and know the consequences to doing it…

This is not a good analogy as it seems to go very much into details. If you're a builder I might expect you to know when to use a steel beam rather than timber even if you don't know by heart what grade and size for any random load (I don't know anything about building but that feels like the right level). Likewise, if you're a software engineer I expect you to know what's a hash table, a binary tree, a linked list,…

I think we're in agreement. My point is that there's certain questions that certain roles shouldn't be expected to have the expertise to answer, and certain answers that make no difference to the job being hired for.

Say you need a builder for a house that an architect designed with wooden beams. Then you interview the builder, and ask them what kind of beam they should use for a theoretical house, and then ask them all sorts of questions about steel beams. Well they don't have the expertise to answer the first question, and the second question doesn't apply to this job at all!

Of course there's a body of knowledge that needs to be known. But I think we need to better codify what knowledge is needed by which people to do what kinds of work. And then have a way to establish that they know how to 'do the work', versus just having a body of knowledge.

Re: Green Lumber Fallacy in Software Engineering

#98

Post by Scene_Cast2 »

robbiep wrote: post #75
Scene_Cast2 wrote: post #73

One amusing thing I've noticed about MAANG companies (with perhaps the exception of Google) is that despite passing the technical interview, the employees do not actually do any difficult or tricky implementations when something like that is actually needed. I can't figure out if it's a strong aversion or an inability - the end result being the same in both cases, at best some approximation gets implemented instead,…

This is highly off topic so I apologise to everyone - but this is the second time I’ve seen MAANG and it’s obvious what it is, but why have the body public decided to replace the F with an M, when we haven’t replaced then G with an A?

I'm just going with what the article used. I think MANGA is another acronym and is more pleasant to write or pronounce.

Why not Alphabet - just a guess, but they haven't really pushed Alphabet branding.

Re: Green Lumber Fallacy in Software Engineering

#100

Post by snarf21 »

erehweb wrote: post #55

Article says "There’s no better way to see how someone performs at the job than having them actually do the job." and argues for a trial work period. Well sure, except the first part of any job is coming up to speed on the domain, the codebase, who the key people are, etc. So if you want to see how someone really performs, you're going to have to wait a while past that initial period. And that means you're going to h…

If that is what they really want, then do a 1099 paying task that takes 40 hours over a months time with a weekly check-in meeting to ask questions not solvable via email. I don't love that idea but it is respectful of everyone's time at least.
Post reply on HN