6 ms·
Ask HN: How much time to devote to learning algorithms vs. creating software?
I was flummoxed with this question when I started re-learning about Algorithms & DS (after years of regular backend software development) along with Competitive programming. The fact that I suck at it hit me like a brick. I took way way longer than necessary to solve even basic algorithm problems.
Now at work, I am pretty good at creating reliable software (mostly in Java, Scala and Python), but I won't probably pass the first tech round at companies like Google or Amazon. And this is hurting my ego bad. After so many years developing software, I am bad at the fundamentals.
Is this something that worries you? How much percent time do you spend on strengthening CS basics? Do the best tech companies only judge based on Algo/DS knowledge?
- surfsvammel 8y agoI think you need a basic understanding of data structures and algorithms. But there is no substitute for actually building stuff. Focus on building things above everything else. Theory and actual craftsmanship often are two separate things. Being able to get the questions of Google and Amazons interviews correct is basically good for one thing and one thing only – getting hired at those places. I have done hundreds of interviews and there are so many other things that I look for before evaluating their knowledge of bloom filters. Maybe I am old school. I’ve met a couple of developers who know all the theory but who could never get anything done and delivered. Then again, my company isn’t Google.
- sidcool 8y agoThis helps. Thanks
- nnd 8y agoWhat other things you look at in potential candidates?
- surfsvammel 8y agoI want team players with drive, who takes initiative, who are willing to learn as they go and who will speak up and tell me when I’m wrong. People with integrity and principles. I’m looking out for warning signals. People who will say “that’s not my job”. Small things. People who are too sure of themselves or small things such if they bring their coffe cup with them out of the interview or not. I don’t want people who pretend that they know answers to questions they do not. I’d like them to say I don’t know at least once during the interview. On the technical side I look for people who can tell me about real problems they have faced in real projects. How they handled that situation. How they approach troubleshooting and debugging in general. I want to hear how they talk about software in general. I want them to not be fundamentalists in any direction. I want people who can see both the positive and the negative aspects of concepts like OOP, functional programming, unit testing or whatever it might be. I want them to be able to argue both for and against different ways of solving problems. And that’s just the start of it. Hope it helps.
- potta_coffee 8y agoThat sounds like the kind of place I'd like to work. Are you hiring?
- ummonk 8y agoBloom filters are not a common data structure. Google ain’t gonna check what you know about them.
- souprock 8y agoIt's funny you say that, because Bloom filters are one of the few non-trivial data structures used in a project I have here with over 3 million lines of code. It's an emulation project with kernel drivers for hardware virtualization and all sorts of exotic functionality. Most needs are covered by arrays and linked lists. Recently we added some AVL trees, and of course hardware data structures (for page tables, etc.) must be implemented as specified. No, we don't demand that on an interview.
- natalyarostova 8y agoWith the rare exception, everyone 'sucks' at things like algorithms and math. That feeling of sucking and frustration is the normal feeling the vast majority of people have when trying to teach themselves or learn complex logic. Some of this can be rust i.e. you have not been thinking this way for some years. But the truth is it's also a slog. Progress in things like algorithms and math, at least from my experience, is measured in 100s of hours, not tens of hours. You need to 'embrace' the frustration. That's just what learning hard stuff is all about. It makes you feel stupid. Even the successful academics all have their small list of role models, all of whom make them feel stupid (a list I think ends with Von Neuman). fwiw I just started studying CS basics at age 29 (although I'm a data scientist professionally). I'm doing it for 'myself' though, not for interviewing.
- sidcool 8y agoThis gives me some respite. I started CLRS a month ago, and although the progress has been excruciatingly slow, I am moving pages. It's quite fulfilling to understand how languages work underneath..
- natalyarostova 8y agoI started a month ago too, and I also find it excruciatingly slow. Make sure you use the MIT opencourseware that uses the book, as they provide problem sets and answers, which is very valuable. Although as learning things always goes, I "feel" like I am learning nothing and making no real progress, but then I look back on what I now know that I didn't before, and it's a lot!
- sidcool 8y agoCan you please provide a link to the courseware?
- natalyarostova 8y agohttps://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-046j-introduction-to-algorithms-sma-5503-fall-2005/index.htm https://ocw.mit.edu/courses/electrical-engineering-and-compu...
- zer00eyz 8y agoI often say that it takes years to wipe computer science off of recent grads and make them into engineers. Do you need to memorize the algorithms so you reproduce them off the top of your head? No! Should you be aware of what they are in a comparative sense, and have a rough idea of what family of them you should be applying? Yes. You need to learn just enough to keep learning, and more so when your applying, because only through use do you gain mastery. That. Takes. Time! As for "will it get you jobs" -- at a subset of companies it will. Another subset will ask you to "write" code (and this is wrong as well)... Do you want to work for those companies is the larger/other question.
- csnewb 8y agoTechnical interviews only test your data structures and algorithms skills and your actual work experience is mostly irrelevant. If you want to crack an interview, grind leetcode and practice writing code on a whiteboard. If you want to become a better developer, create software.
- soft_shortcut 8y agoWho knows? Maybe all tech companies came to an agreement one day, a little secret we don't know about. Why do they all require that type of interviews? Employee retention... If interviews for software engineers were focusing on real work experience only, everyone would be able to switch jobs very easily. Think about it. It would be so easy to get in without even putting extra work because you'd be evaluated on your day to day tasks, rather than something that requires months of intensive practice. It's a way to scare engineers and to keep them away from switching jobs. Now let's say you don't have any experience and you're fresh out of college. What happens with today's setup? Well, you're perfectly able to tackle these interviews since all you know are algorithms, data structures, etc. There's no retention involved since it would be your first gig ever. It's a perfectly well designed process for Tech companies, but it's awful for us I agree.
- rafiki6 8y agoAs much as I love a good conspiracy theory, and yours is pretty damn good because this industry has colluded to keep wages down, I'm hard pressed to believe that this is the case. Interviewing is hard. Startups are led to believe they need to have a higher rate of false negatives over false positives to ensure they don't get a "bad hire". Most people in this industry just follow the trend they see. It's all they know. They have never seen another successful hiring strategy. So it persists.
- soft_shortcut 8y agoMy theory was pure imagination :) I 100% agree with what you said. The primary goal is to raise the bar of entry. The problem is, current SWE evaluations focus too much on one single task. The ration "writing functions" versus the rest might be about 20% vs 80%. We focus too much on the 20%. How about team work, collaboration, knowledge transfer, project related issues, mentoring people, setting up environments, understanding users, collaborating with product managers and designers, etc. If you think about it, it's a pretty risky process for companies. Judging a candidate based on a few 45-min whiteboard exercises and a high level system design question, we're looking at only 20% of the whole picture.
- lrajlich 8y agoI'd suggest 90-100% creating software; 0-10% algorithms. The percentage on algorithms should be directly applicable to what you're working on. In practice, algorithmic knowledge primarily helps when dealing with performance issues or complex architectural decisions. I wouldn't suggest totally ignoring algorithms, but it's at best secondary. Being proficient at solving performance problems or architectural issues are very valuable skills in the marketplace. That said, even those are mostly practical and about pattern recognition (which you get from writing software).
- AnimalMuppet 8y agoWhat do you think a company wants to hire you to do? In a world where both Google and Knuth exist, they aren't hiring you to be an algorithm reference book. They're hiring you to create working software. Your task when interviewing is to convince them that you can do that. The reason they (at least the reasonable places) ask algorithm questions is because they want to see you think through something you don't know. They also want to see you write some code for something small, just to make sure you can. If it's a place that is going to judge you negatively for not knowing every algorithm they ask you about, that says more about them than about you. Be grateful such places eliminate themselves from consideration in such a straightforward manner.
- rafiki6 8y ago> I am bad at the fundamentals. Correction, you are bad at memorizing algorithms or coming up with them in interview settings under time pressure. This can be valuable in some jobs that are heavily algorithmic. Many development jobs are not. As a matter of a fact, many development jobs at FANG are not.
- sidcool 8y agoIf most dev are not algorithmic, why so much focus on it? I understand that some knowledge is required.
- jobigoud 8y agoMostly only meta knowledge is required. You need to know they exist so you can look them up if you need to reimplement or choose the right library. If you have to write the code for it inside an existing code base, knowing a specific algorithm by heart vs looking it up won't really make a lot of difference on the time it takes.
- rafiki6 8y agoLogical reasoning is required, and the ability to determine an efficient solution for the task at hand is required. Keep in mind that many of these algorithms that are tested for are not intuitive and took researchers years to come up with. What you are being tested for in an interview is not logical reasoning (as much as they claim that's the case), but rather your ability to memorize algorithms. It's silly and counter productive to finding actually intelligent people.
- ilaksh 8y agoI think it depends on if you want to interview at a big company that does algorithms type interviews. In my opinion studying that stuff is a waste of time if you are not going to use it in an interview, because you have already proven you aren't using it in your actual job.
- souprock 8y agoWhat is it that you see in companies like Google or Amazon? Is it some sort of perception of prestige? I think this is a question you ought to think more about. I'm not at all worried because I have no desire to be hired there. All indications are that the work environment is pretty toxic. The pay does not come close to compensating for cost of living.
- sidcool 8y agoI agree that it is a perception of prestige. It just seems that those companies are doing the best kind of tech.
- afpx 8y agoSome algorithms and data structures are really easy and intuitive (e.g. binary search, linked lists, etc). Some are quite hard. But, knowing how and when to use them is much more important than knowing how to implement them [†]. Understanding algorithmic complexity is important when venturing beyond the simplest of software. Why? Because an O(n^3) algorithm may appear to work well with simulated data, tests, or light user load. But, it may bring your system to a halt under real-world conditions. And, it is sometimes not trivial to debug, especially when the complexity spans multiple layers. (I cringe when I see new developers nesting loops inside loops, but sometimes it’s ok). Also, it’s very important to be able to read and understand code. It’s unavoidable that you will someday encounter complex, poorly-documented code. Say you run into some code that implements a graph algorithm. If you don’t recognize what it is, you will incur a lot of risk when maintaining it. † - However, you really should know how to implement simple data structures and algorithms, at least conceptually.
- guitarbill 8y agoOn the flip side, that's not how perf work is done in the real world. Start with a simple implementation that's easy to maintain and easy to understand. Run profiling, don't guess. Iterate and make it better. Devs worrying about big-O cause issues, too, no matter how good the intentions. CS itself isn't harmful, just one of many tools in an engineer's toolkit.
- afpx 8y agoHow does worrying about big-O cause issues? You should back up such a strong statement with at least anecdote or something.
- hackforumsexpl 8y agohttps://www.hackforumsexploits.com/product/diamond-fox-botnet-6-0-3/ https://www.hackforumsexploits.com/product/diamond-fox-botne... https://www.hackforumsexploits.com/product/diamondfox-crystal-latest-2019/ https://www.hackforumsexploits.com/product/diamondfox-crysta... https://www.hackforumsexploits.com/product/emissary-keylogger-fud/ https://www.hackforumsexploits.com/product/emissary-keylogge... https://www.hackforumsexploits.com/product/extremely-silent-jpg-exploit/ https://www.hackforumsexploits.com/product/extremely-silent-... https://www.hackforumsexploits.com/product/extremely-silent-jpg-exploit-v1-3/ https://www.hackforumsexploits.com/product/extremely-silent-... https://www.hackforumsexploits.com/product/keylogger-4/ https://www.hackforumsexploits.com/product/keylogger-4/ https://www.hackforumsexploits.com/product/gsm-data-receiver-pos-atm-skimmer/ https://www.hackforumsexploits.com/product/gsm-data-receiver... https://www.hackforumsexploits.com/product/hackrf-one-bundle/ https://www.hackforumsexploits.com/product/hackrf-one-bundle... https://www.hackforumsexploits.com/product/hardware-random-number-generator/ https://www.hackforumsexploits.com/product/hardware-random-n... https://www.hackforumsexploits.com/product/horus-protector/ https://www.hackforumsexploits.com/product/horus-protector/ https://www.hackforumsexploits.com/product/inject-malicious-code-wordpress-site/ https://www.hackforumsexploits.com/product/inject-malicious-... https://www.hackforumsexploits.com/product/make-software-serial-keys/ https://www.hackforumsexploits.com/product/make-software-ser... https://www.hackforumsexploits.com/product/inject-malicious-code-android-apk-files/ https://www.hackforumsexploits.com/product/inject-malicious-... https://www.hackforumsexploits.com/product/keyloggers-1/ https://www.hackforumsexploits.com/product/keyloggers-1/ https://www.hackforumsexploits.com/product/java-crypter/ https://www.hackforumsexploits.com/product/java-crypter/