Green Lumber Fallacy in Software Engineering

I don't understand why people hate DS&A so much. Just do it. Get money, jump ship, get more money, it also makes you a better engineer. It gives you better compensation, it helps you, helps everyone, helps your team, your company. It helps avoid wasting time as well on both sides.

There is no downside of studying DS&A and Leetcode, if there is, the downside is minimal.

And yes, you can have DS&A knowledge without handicapping your other software engineering knowledge. It is a fallacy to think that a Leetcode monkey wouldn't be able to code resilient, robust software, with good variables and good readable, maintainable code, and vice versa. Like, seriously. Why this is even an argument?

And after DS&A interview, there is behavioral questions interview. If someone is a crazy person, ideally behavioral questions would weed that out.

I don't understand why people prefer "here take home questions/work for 5 hours for free" over DS&A interview.

Also, it is "Green Lumber fallacy" to think that a knowledge of "how webpack 1, 2, 3, 4, and nth build system in JavaScript here works" will make you a better engineer. Those kinds of knowledge aren't long lasting, and it is also quite easy to learn relative to DS&A.

Here is the problem with these kinds of articles. Majority of them are written by people who hate these kinds of interview questions, and by extension, they probably aren't that good at it.

There are articles that sing praise of DS&A interview but of course it doesn't get here on HN because it is not controversial and the number of bitter SWE who don't have DS&A knowledge overwhelms those who do.

Not saying the author doesn't have DS&A knowlege, just my generalization.

And yes of course there are people who excel at software engineering without DS&A, but that's not the point of DS&A interview. The point of DS&A interview is as fast as possible system to vet engineers that aren't time wasting on both sides. It accomplish its purpose nicely. Engineers aren't as non-fungible as they think. Deal with it.

Design a binary tree containing integers. Design a function to serialize this to a byte array (or byte stream); and design a function to deserialize that same output back into its original tree form.

I thought this was completely reasonable and also very practical, as it tests data structure knowledge to the extent that is likely to come up during real programming tasks, in a context that is entirely plausible as well (needing to serialize data in order to store it or pass it between systems, etc.)

I had to look up what it means to invert a binary tree since I hadn’t heard that term in a while. It seems like something you’d be more likely to do with a binary search tree than an arbitrary binary tree, but the operation makes sense on both. (Given that a binary tree represents a sequence of elements, “inverting” the tree means constructing a tree representing the same sequence of elements in reverse.)

If you realize that inversion is as simple as swapping the left and right edges for every node — either in place or by constructing a new tree - then the problem is actually fairly simple.

… as long as the candidate has a clear understanding of what “inverse” means — I might clarify and ask them to “reverse” the tree - it doesn’t seem like a particularly difficult interview question.

However I’m not a fan of interview questions that require a “flash of insight” - even one such as “oh this question has a simple solution: swap left and right of each node” - since candidates might get tripped up looking for traps that require algorithms something more complex than the obvious.

Also I think that kind of task is rather removed from the kind of problem that we typically work on as software engineers on a daily basis. Serializing and deserializing data structures is something that I do in one fashion or another not infrequently - usually not with custom code but I think a competent programmer should be able to write that code.

Binary trees and algorithms on them are not something that come up very often in practice in my experience. They might come up if you were building a collections library or a particularly optimal solution to a large scale problem.

Otherwise, I don’t think I’ve seen a binary search tree in userland business logic the entirety of my professional career. On the other hand I’ve definitely had to write serialization/deserialization functions for object graphs. Although this is less common now that there are a variety of good serialization libraries and RPC tool kits, I find it’s often still necessary to convert between their generated structures and the native ones used by business logic.

In conclusion: the question seems like one that I would expect a competent developer to be able to solve, as long as they’re given a clear understanding of what the problem actually means (i.e. explain what it means to invert a tree and not takeoff points for not knowing that) - but it’s not a good problem IMO because it’s not the kind of code one would typically need to write while solving routine business problems.

All that being said, Google also rejected me during my last round of interviews; I believe this was because I was transparent with the recruiter about my interviewing at other companies and offers that I had, and Google’s offer (per the recruiter) would have been for considerably lower compensation. They said they did not want to compete on compensation because it would be unfair to their existing employee population, and so - per my best read of the situation (there was no discussion about my interview performance, and rather about this) - they decided not to make an offer that was lower on compensation, and potentially also on comparative level. So I might not be the best person to comment on Google‘s hiring practices. During a previous interview they did give me an offer though so shrug. (I interview periodically to benchmark comp and stay sharp)

It is a skill that you will lose if you spend a year without interviewing/leetcode practicing.

Sure I’ll do it, but you may as well test me on painting famous oil artwork from memory too.

> I don't understand why people prefer "here take home questions/work for 5 hours for free" over DS&A interview.

The alternative is hundreds of hours of speculative investment memorizing books/websites of algos. People will take full time courses on passing these interviews.

- Personal time taken that is not relevant to the job?

>> Also, it is "Green Lumber fallacy" to think that a knowledge of "how webpack 1, 2, 3, 4, and nth build system in JavaScript here works" will make you a better engineer. Those kinds of knowledge aren't long lasting, and it is also quite easy to learn relative to DS&A.

- Being able to demonstrate that you know how A build system works, and the details enough to show you've had to actually solve issues with it, may not be long lasting, but it does show you learn your tools.

>> I don't understand why people prefer "here take home questions/work for 5 hours for free" over DS&A interview.

- Awfully presumptive to assume they should be unpaid. I'd also take an unpaid, but interesting and novel engineering problem, over the unpaid hours of grinding leetcode that is considered interview prep.

>> Here is the problem with these kinds of articles. Majority of them are written by people who hate these kinds of interview questions, and by extension, they probably aren't that good at it.

- I'm a hiring manager and I hate them, from both sides of the interview table, because it tells me nothing about the candidate that I want to know. I've done them, I've both passed and failed them (entirely dependent on the question, my frame of mind at the time, if it's one I've done before or where I can easily come up with the 'clever' solution, etc); I also recognize they're measuring a very specific thing (your willingness to do bullshit prep work), that isn't job related.

I'll also add, the same arguments in favor of DS&A algorithms apply to those lateral thinking brain teasers that no one uses any more, the "how many manhole covers are there in NYC" style of thing.