1.) DS and Algo knowledge are way overrated in day-to-day job functions. I have yet to have to implement a single DS or Algo from those classes (they are almost always available to the framework, standard library, or language), runtime complexity has literally never once come up in my life, and the most I've ever needed to know about data structures is "which one should I use here?" and 99% of the time its either a vector (arraylist) or a map (dictionary).
2.) Just because you don't have a proclivity for code-golf does not mean you don't know DS and Algos, it just means that you don't waste your free time writing unreadable code for useless puzzles which serve only as interview questions.
> runtime complexity has literally never once come up in my life
There are definitely different types of programming jobs, but for some contrast: I have never had a job where runtime complexity did not come up as a significant factor somewhat frequently.
It really comes down to what you’re doing, but at a certain scale or size of problem you really do need to know about algorithms, data structures, and runtime complexity to avoid having your runtime explode, server costs become untenable, opening the door to extremely long running requests and other problems.
In my experience the biggest bottlenecks are in the network. Most optimizations are also very very low hanging fruit because the original code was written by a moron
Using electron isn't a performance decision, it's a labor one. It's easier to write a website once and then just export to electron than it is to rewrite your application in QT or XAML or another native desktop framework and have to hire C++ or C# developers
If Browsers can do Figma and VS code, they're already a far capable and approachable platform at least for most desktop applications than Qt especially for anything that has some data entry such as ERPs etc.
And it's free. Qt is not.
> There are definitely different types of programming jobs
That's what most people on HN forget. The programming world is huge. Even more so, if you include all the stuff we wouldn't traditionally include, such as people using code to optimise business or production processes.
It's always best to assume that you don't know what "most software jobs" are like, because you're very unlikely to have seen more than a tiny slice of it.
I'd estimate that 98% of companies are just receive-deserilze-validate-transform-store a.k a CRUD shops though some might have borken it down into distributed chunks (Micro Services) without any of the distributed tooling or mindset and awareness in place.
So... That's less likely where you'll need your dynamic programming or palindromes in constant time or space.
As a different perspective: I end up writing a fair bit of code that involves data structures and algorithms. Runtime complexity does come up in my line of work, and I've definitely had to solve a couple of issues related to code being accidentally quadratic. So I do value basic Big-O analysis, and it's definitely nice to know some core data structures, especially arrays and hash tables.
But what leetcode and leetcode interviews optimize for isn't all that valuable. In the context of the job there are usually different space/time constraints than what you'll see in leetcode, and there are also integration constraints that can change/invalidate textbook approaches.
Most importantly, though, you always have more than 30-60 minutes to figure things out, and can consult whatever references you want.
I think if you don’t know it, you are blind to it. We had some AWS lambda function timing out and the person working on it kept adding more and more resources to get it to complete on time but it would inevitably slow down again. I took a look at it and realized that they were building a huge array and performing a lookup in it each time. Converting the array to a set immediately dropped the runtime and fixed the issue for good.
I once had a lambda that was running at like 10mins and timing out. It downloaded a bunch of data from an API, ran some statistical functions on it, and then uploaded it to a database.
I found that the biggest performance increase came from async downloads. By sending multiple http requests at once it went from 10 to 2min. After that, optimizing the queries sent to the API reduced the amount of data that had to be downloaded. Finally, I found the best way to bulk upload data to mysql was to use file based uploads which simply copy themselves into the database. Sending 500 inserts at a time was wayyyyy slower. Managed to get it down to 30s. I also switched from python to Java but I never measured the difference between the two
Their point (to me) was that leetcode was hard and if they knew how to solve leetcode, they would apply for FAANG companies, but leetcode is just data structs and algorithms
1.) DS and Algo knowledge are way overrated in day-to-day job functions. I have yet to have to implement a single DS or Algo from those classes (they are almost always available to the framework, standard library, or language), runtime complexity has literally never once come up in my life, and the most I've ever needed to know about data structures is "which one should I use here?" and 99% of the time its either a vector (arraylist) or a map (dictionary).
2.) Just because you don't have a proclivity for code-golf does not mean you don't know DS and Algos, it just means that you don't waste your free time writing unreadable code for useless puzzles which serve only as interview questions.