[andsoitis]

> balancing binary trees, time/space complexity of sorting algos .... I needed knowledge like it, but you can look that up as well)

In my experience, it is now about knowing how to do these things but when to reach for them when solving a problem.

[ttymck]

Agreed! And I never reach for them, because I work on web apps. If I was a database developer, the story might be different. But I don't feel the need to be interviewed on those topics over and over again. Subsequently, I don't know how to do those things.

[switchbak]

Having worked in this space for decades, I think most people I've met agree it's ludicrous, but there's strong pulls to keep it in place.

The most compelling argument I've heard is "we get so many applicants at $bigcompany that we need a fast and objective way to filter people out". And sure, that works, but think of the masses of great people you're turning off with that approach? Most great devs I know won't put up with that crap, including myself. Not a problem if you've optimized your company to build masses of code with early-career employees I suppose.

Knowing the tradeoffs we're making in data structures and having a broad understanding of different algorithms to throw at a problem is very handy. It's also almost completely unnecessary at the typical web shop (like you say). I use these things a bit in my work (not the typical web shop), but mostly indirectly via DBs and similar tools where I need to understand the tradeoffs. I'm certainly not implementing anything with red/black trees, making my custom bloom filters, etc. We have an ecosystem of tools for a reason, that would be silly to reinvent the wheel everywhere without a damn good reason.

[joshuahutt]

One thing I realized after doing some studying is that your approach is limited by the concepts and tools you're familiar with. As I learned more about data structures and algorithms and as I practiced using them and evaluating the complexity of my implementations, I felt a lot more clarity and confidence about solving problems and structuring my code efficiently.

[newaccount74]

Yes! I doubt companies grill you about binary trees because they expect you to actually implement any of the algorithms in your day to day work.

They want to know if you have studied the fundamentals, so you at least have a chance of understanding whatever you are going to be copy-pasting from Stack Overflow.

[scruple]

But I did study the fundamentals. It just happened to be almost 2 decades ago and I haven't used 95% of it since entering the industry. How could it possibly be relevant?

I've gone the route of avoiding typical interviews altogether by leaning into my network for opportunities.

There are plenty of places where I think I'd like to work, where I'd be very motivated, and where I'd make an impact to the organization, but I'll never bother because their interview style is bad.

> have a chance of understanding whatever you are going to be copy-pasting from Stack Overflow.

And, frankly, I avoid all of this because what you've said here is exactly the sort of place where I don't want to work.

[joshuahutt]

There are plenty of places you can build valuable products and not have to think about optimization, ever. I'd imagine there are even places inside MANGA that you might get away without it. But, would expect those things to be the exception, not the rule.

While their process might be arbitrary, it tries to ensure that entrants can comfortably think about and select appropriate data structures and algorithms for problems, on demand.

In most cases, prepping for this feels like rote memorization, but through that process you start to build an intuition that helps you be more efficient at pattern matching and isolating the constraints/bottlenecks. And you've proven that you can learn and apply the algos. It's not the most fun of interview styles, but it does work for them.

[tluyben2]

But a degree(s) and portfolio shows that already (it is what they are for; when I show my EE degree, they don’t ask me to solder together a computer from this here 74LSxx series box; no, they just hire me; why is software hiring so nasty?); if you are a junior, your degree will show what fresh knowledge you have and the question is if you are a talented dev or not. If you are a senior it shows that you understand the fundamentals (your degree) and you can execute (your portfolio) (and actually that shows you know the fundamentals too).

So what’s the 6 week interview for? To recognise talent? Sure I can see that in a junior a bit (but I doubt you find out more in the all those interviews than a 15 minute chat, at least that’s my experience; you will actually need to hire and try them on a project in the team to know their feel for it all) but in a senior that’s the portfolio again.

To me it feels that we are starting in a position where the interviewer assumes I lied about everything I sent in and this all is to prove myself (again and again). I am not in kindergarten; I have decades of experience in huge project; good luck finding a stooge who likes abusive relations.

[joshuahutt]

I imagine that most of the EE roles you've applied for have an order of magnitude fewer applicants than the software roles. The greater volume probably leads to a wider spread of skill levels, including the drastically under-skilled.

It does feel like the balance of power in these interviews is way out of whack, but that's what you get when there's way more applicants than open roles. If you're a developer with a good reputation, sometimes you can skip most of the red tape [1]. That bar is extremely high, though.

[1] https://youtu.be/8Ia6FX-tqcE?t=4999