
Ask HN: How much time to devote to learning algorithms vs. creating software? - sidcool
I was flummoxed with this question when I started re-learning about Algorithms &amp; 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.<p>Now at work, I am pretty good at creating reliable software (mostly in Java, Scala and Python), but I won&#x27;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.<p>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&#x2F;DS knowledge?
======
zer00eyz
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.

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

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

~~~
natalyarostova
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!

~~~
sidcool
Can you please provide a link to the courseware?

~~~
natalyarostova
[https://ocw.mit.edu/courses/electrical-engineering-and-
compu...](https://ocw.mit.edu/courses/electrical-engineering-and-computer-
science/6-046j-introduction-to-algorithms-sma-5503-fall-2005/index.htm)

~~~
sidcool
Thanks

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

~~~
nnd
What other things you look at in potential candidates?

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

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

------
rafiki6
> 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
If most dev are not algorithmic, why so much focus on it? I understand that
some knowledge is required.

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

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

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

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

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

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

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

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

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

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

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

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

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

