Live data from Hacker News

JavaScript Algorithms and Data Structures (2018)

github.com

31–36 of 36 posts

Re: JavaScript Algorithms and Data Structures (2018)

#31

Do we really need yet another list of algorithms to memorize for interviews? Is another list going to make a better JavaScript engineer? Will help me understand JavaScript better? Will it help me on the job? Will it make me a faster and better React developer? The obvious answer to all of the above rhetorical questions - fuck no. That being said, it is still a topic of interviews, so I will up-vote bc this is pretty…

[deleted]

Re: JavaScript Algorithms and Data Structures (2018)

#32
post #15
post #11

Is there any practical reason use, say, a linked list from this library vs javaScript's native growable array. You can use unshift() to delete in the middle.

Presumably, inserting and removing from the middle of a linked list is much faster than from an array.

I did some quick benchmarks the other day between sorted array vs red black tree of https://github.com/preludejs and it looked like rb tree had better generic performance for N > 20k - ie. memcpy is better for most cases/cases that fall under 20k. You should measure of course for your use case. Libraries/your implementation should make it easy to switch between underlying representation.

Re: JavaScript Algorithms and Data Structures (2018)

#33
post #20

Earlier quoted context omitted.

Doesn't GOOG go hard in the paint with those questions though?

Not just GOOG, but all of FAANGMULAetc... and smaller start ups as well. Robinhood asked me a dynamic programming leetcode question for their web engineer (front end) role and Bloomberg asked me a OOP design question (asked to code in Python, even though I do not have Python on my resume...interviewer was a Python developer) for a javascript role - both were 1st round phone screens. The tech industry has normalized t…

I’ve never been interviewed in any of these nonsense ways.

I’m sure it’s popular. But it’s not everywhere.

Re: JavaScript Algorithms and Data Structures (2018)

#34
post #12
post #11

Is there any practical reason use, say, a linked list from this library vs javaScript's native growable array. You can use unshift() to delete in the middle.

Only the usual reasons to use a linked list. E.g. if you want to store stable references to cells in the linked list as in a linked hash map.

Are there practical reasons for using a linked list in JS? This is an honest question. I’ve taken immutability to heart, so storing a stable yet presumably mutable reference to a cell seems like a bad idea to me. (If it’s immutable, you can keep and use the cell’s value instead of caring that it came from a list.)

Re: JavaScript Algorithms and Data Structures (2018)

#35

Do we really need yet another list of algorithms to memorize for interviews? Is another list going to make a better JavaScript engineer? Will help me understand JavaScript better? Will it help me on the job? Will it make me a faster and better React developer? The obvious answer to all of the above rhetorical questions - fuck no. That being said, it is still a topic of interviews, so I will up-vote bc this is pretty…

Reciting algorithms is reverse gatekeeping. If an employer wants to grill you on them, get out of there.

Are you saying it’s not important to know what a binary search is?

If I interview someone I don’t go deep into algorithms but I want to know that they know how about binary search or hashmaps. Ignorance of these shows ignorance of the basics of computation.

Re: JavaScript Algorithms and Data Structures (2018)

#36
post #27

Earlier quoted context omitted.

I've wondered about this -- are such data structures useful? Interviews aside?

Being able to rattle off exactly how any particular data structure is implemented isn't useful for most developers. Being able to reason about algorithms and data structures _is_ useful in day-to-day development. And that does start with having a basic understanding of some subset of them. You can clearly see the impact of computational ignorance on the modern web. JS engines have been optimized to hell and back and…

Thanks for your response -- I think you're probably right, but alot of JS's slowness seems to just be all the junk a typical page needs to pull in via HTTPS for all the ads, frameworks and what not. Also videos that autostart themselves, obnoxious pop-ups that take your full screen up after you scroll 20% into an article, etc. That's not necessarily JS's fault. Also algorithms wouldn't help there. :p
Post reply on HN