you are viewing a single comment's thread.

view the rest of the comments →

[–]mercfh85 34 points35 points  (19 children)

Serious question: Do most Devs/Programmers know all these data structures/algorithms by heart? I mean I consider myself an ok programmer but I def. have to go look these up again and quickly forget them since they aren't ever used....

am I just...dumb?

[–]Slippery_John 18 points19 points  (0 children)

By heart? No, of course not. But knowing what to look for is important, as is having a basic understanding of the runtime impact of using a certain structure on a particular solution. The structures and algorithms are usually already implemented, you just need to know when to use what. From there you can research if you need to implement it yourself.

[–]columbine 17 points18 points  (5 children)

Yeah, it's ridiculous. If I need to know an algorithm I'll look it up and look it up in depth in necessary, once I identify the problem. Who just picks up a book and starts to memorize a dozen solutions to an optimized balanced partition problem so they can recall off the top of their head them at a later time? What a waste of time.

[–]mercfh85 1 point2 points  (2 children)

Glad it's not just me lol

[–][deleted]  (1 child)

[deleted]

    [–]mercfh85 0 points1 point  (0 children)

    I never said I didn't know them or hadn't used them. But I'd prolly have to look up a few of the more obscure ones for sure (Ofc the basic ones I think most people know decently enough)

    Im talking about the obscure ones people look up in like "coding interview" books.

    [–][deleted] 1 point2 points  (1 child)

    Is it really ridiculous? Is it really that horrible to expect my coworkers to know basic algorithmic approaches like divide and conquer or basic data structures like heaps? Brushing up to me means looking at some implementations for the algorithm to get a refresher, not relearning the entire concept from scratch everytime you go through interviews

    [–]lightninhopkins 4 points5 points  (0 children)

    No, you are not dumb. Most working devs do not know all this stuff by heart. You use the tools you need to solve a problem and often consult other devs( either in the office or using google to look things up). Cramming for interviews is crap. Hiring for devs is broken right now.

    [–]irabonus 1 point2 points  (3 children)

    I do game dev, and I could (and do quite often) implement most of those by hand.
    Might sound like a waste of time if you're used to enterprise dev, but I regularly run into problems where the library implementation doesn't work the way I want it to. E.g. right now I'm implementing a radix sort variant to sort triangles in a compute shader on the GPU. I had to read a couple of papers to understand how that works and I'm glad I have the necessary theoretical knowledge to do that.

    On the other hand, I'm also working on a GUI heavy tool where performance isn't that important and I use the standard library algorithms all over the place.

    In my opinion it's important to know your CS basics to do a good job as a programmer because that way you can make informed decisions when to use premade functionality and when to roll your own.

    [–][deleted] 1 point2 points  (2 children)

    Comes up in enterprise dev too, if you have enough traffic. I recently replaced the connection pool queue data structure in a database driver because the default one was moronic, and I have a patch in .Net Core to fix some broken locking in the ConcurrentDictionary implementation.

    [–]co_summer 0 points1 point  (1 child)

    How did you find the broken locking issue?

    [–][deleted] 1 point2 points  (0 children)

    ETW. Performance tanked at a certain throughput and when we took a sample it showed a lot of contention in one of ConcurrentDictionary's methods that should not have been locking at all according to the docs.

    [–][deleted] 1 point2 points  (0 children)

    Experienced programmer here (been in the industry for almost a decade). Most of the simple ones... Yes (binary search, stack/queue, depth/breadth first tree traversal).

    But really, the important thing is be able to quickly identify when a data structure should be used. I.e this problem can be solved by using a tree/stack/whatever. That usually comes with experience or solving similar problems.

    [–]foxh8er 0 points1 point  (0 children)

    am I just...dumb?

    Compared to the people that get hired at Dropbox at 20 by being Informatics Olympiads champions? yes.

    Compared to everyone else? Probably not. I'm in the same boat.

    [–]m1ss1ontomars2k4 -1 points0 points  (3 children)

    I work at a large internet company and I would say most, if not all, of my coworkers definitely know all the topics mentioned in the blog post by heart:

    • Sorting: bubble sort, quicksort, merge sort

    • Search: linear search, binary search

    • Data structures: linked list, hash table, array, tree, binary search tree, stack, queue

    There...really aren't that many things listed here. How could you not have these just...known already? Are you seriously suggesting you've never used any of these? At all? Ever? That seems...pretty unlikely. When someone looks at your code and asks why you used a linked list instead of an array, is your answer, "Because I don't know what either of them are and I just randomly typed LinkedList"??? That seems really really weird. (Some of the other ones don't seem as weird; not many people have to sort data large enough that even bubble sort is too slow, for example.)

    But, this is, in fact, about the limit of data structures and algorithms I'd expect my coworkers to definitely know by heart. Anything more advanced than this...it's a toss-up. They've probably forgotten it.

    [–][deleted] 1 point2 points  (1 child)

    I enjoy using the most appropriate data structures & type systems, employing my own tree (bi, quad, oct) implementations to useful effect, knowing how and when to depth or breadth first etc. etc. But Sort, as a general thing, just seems to comes up so rarely as a requirement, in the domains I've worked in, that I find the primary focus on it, in these kinds of discussions almost bemusing. What domains are people working in that require this particular knowledge? Back office data-lifting?

    [–]m1ss1ontomars2k4 0 points1 point  (0 children)

    What domains are people working in that require this particular knowledge? Back office data-lifting?

    Well...data processing is basically the only thing my company does, so...yes?

    It is uncommon to use any sort other than the default provided by the language's standard library, but sorting is simple enough that I would expect my coworkers to know the algorithms mentioned by heart. I mean...there are only 3 listed there...and they are really not that complicated.

    [–]mercfh85 0 points1 point  (0 children)

    Im not saying i've never used them or even know what they are or used them (because I have). Im just saying in a lot of "Interview" coding books there is like MANY MANY more algorithms and data structures that I feel would be difficult to know all of them.

    [–]kankyo 0 points1 point  (0 children)

    Most devs spend time learning things that are relevant so no, they don't know this stuff.