Ask HN: How much time to devote to learning algorithms vs. creating software? | Hacker News Reader

Ask HN: How much time to devote to learning algorithms vs. creating software?

63 pointssidcool33 comments

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?

View on HN

I 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.

With 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.

This 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..

I 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!

Can you please provide a link to the courseware?

https://ocw.mit.edu/courses/electrical-engineering-and-compu...

Thanks

I've read some of and done exercises in The Algorithm Design Manual instead of CLRS as I was always told and read CLRS is more a reference. I found The Algorithm Design Manual interesting and nicely paced, not slow at all. I actually very much enjoy it and will often re-read chapters or sections and pick out things I might have just slightly glossed over.

I can't say anything about CLRS as I haven't read it or any parts of it.

To me, a one semester course is 150 hours (10 hours classroom and homework and home study per week, 15 weeks). If you study on your own, without lectures or office hours, I imagine it should be harder.

I’m trying to read a good chunk of a math book (Analysis on Manifolds) while following a syllabus for it so that I know I’m covering roughly one semester of material in one semester of study hours. The most I can realistically devote right now is 30 minutes per day, most days per week. That means this is basically a one year project if I’m consistent enough to spend time on it everyday.

Some people seem to act like it’s extremely easy to teach yourself technical material, but I really don’t buy it unless you do one or more of 1) learn at a very shallow level 2) ignore keeping rest of your life in order and can sacrifice lots of time 3) work in a situation where you have a lot of resources and free time to do it (eg a technical lab at graduate school where reading the book is part of your actual research duties)

So I agree with you completely

I think a lot of people learn at a shallow level. That's what I used to do. I'd "read" textbooks with the illusion of gaining knowledge. But real knowledge I've learned is earned through a level of torture in trying to answer practice problems that's almost self-torture.

I 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.

This helps. Thanks

What other things you look at in potential candidates?

I 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.

That sounds like the kind of place I'd like to work. Are you hiring?

Bloom filters are not a common data structure. Google ain’t gonna check what you know about them.

It'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.

> 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.

If most dev are not algorithmic, why so much focus on it? I understand that some knowledge is required.

Mostly 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.

Logical 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.

Some 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.

On 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.

How does worrying about big-O cause issues? You should back up such a strong statement with at least anecdote or something.

Who 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.

As 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.

My 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.

What 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.

I agree that it is a perception of prestige. It just seems that those companies are doing the best kind of tech.

What 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.

Technical 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.

I'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).

I 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.

Reply on news.ycombinator.com