3 ms·
> The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times
by gumby 3y ago
> The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one.
It really depends on what you're working on. A package to manage a dentist's office should be as off the shelf as possible. I don't care about I/O and try to do as little as possible, using whatever's off the shelf, but my HFT buddies are bumming the hell out of it, customizing the kernel, and whatnot. You may use elastic search to save you time and money, but the folks working on it have probably run over it so much there's nothing but custom code left.
It's all context.
- josephg 3y agoYep I absolutely agree with this. I’ve spent about the last year optimising text CRDTs so they’re actually usable in practice. A few years ago, 800mb of ram usage and 5 minutes processing was common to open a document. Now we’re talking 2mb of ram and 20ms. That is the difference between something not being viable and something being usable everywhere. And yes: my code involved a lot of custom data structures and algorithms. There were no libraries in cargo which did exactly what I needed. This thread is full of people bemoaning “leetcode problems” for being irrelevant in software jobs. But I use them all the time in my work. Software engineering is far more varied than any of our individual careers.
- neon_electro 3y agoI'm happy for you that you've found a job where the things Leetcode emphasizes has merit and importance and value in your day to day work. Everyone who's on the other side of the Leetcode debate from you wants the exact same thing - an interview process that is representative of the actual day-to-day work. As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do.
- josephg 3y agoYes. You, me and the GP commenter seem to all be vigorously agreeing with one another. Job interviews should be based on what the role entails. If that includes data structures and algorithms, so be it. If not, leave them out! As the GP commenter said: > It really depends on what you're working on. ... It's all context. I brought it up because many (most) commenters in this thread seem to be claiming that this knowledge and skill is never useful. That its ridiculous to ask about this stuff in any job interviews, except as a ritualistic hazing ritual. This is also absurd. > As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do. I've never had an employer name any data structures explicitly. Its our job as the software experts to know which tools and technologies are relevant. But with that said, I can't remember ever using custom data structures in frontend website code either. If I were hiring a web developer, there are so many things I'd rather spend time talking about in an interview. (HTML & CSS knowledge, web frameworks, design skills, raw programming skill, etc.)
- Apocryphon 3y ago> many (most) commenters in this thread seem to be claiming that this knowledge and skill is never useful. Those commenters are making generalizations because many (most) jobs in the industry do not find that knowledge and skill useful. Certainly specialized edge positions exist.
- nonameiguess 3y agoI believe Google at least at that time was trying to hire engineers who could theoretically be put to work on any team, potentially being asked to create TensorFlow or MapReduce or contributing to the Linux kernel in service of Android, not people who have pigeonholed themselves into only being considered web developers. If pure CRUD companies only looking for JavaScript specialists are also using leetcode screening, they're missing the point.
- noleetcode 3y agoHere's the difference: I bet you had time to think through the novel problems and didn't have someone hovering over your shoulder, demanding you come up with solutions within 20 - 30 minutes -or else-.