
Ask HN: How to Approach Algorithm Studying? - rubicon33
I&#x27;m using leetcode.com to study algorithms and I&#x27;m finding I&#x27;m actually struggling on my first pass.<p>Generally, I can intuit the &quot;brute force&quot; solution, but the &quot;right&quot; answer with linear&#x2F;constant time often requires looking at the answer.<p>Should I expect that with practice, I&#x27;ll eventually get better at quickly finding the optimal solution?  Or, is it expected that optimal solutions are &quot;memorized&quot; similar to how hard sciences like ME &#x2F; EE &#x2F; CE memorize formulas?<p>Take ThreeSum problem for example.  I was able to write the brute force solution without any prior knowledge of the problem.  In an interview with time constraints this WOULD have been my solution.<p>I now understand that&#x27;s not the right solution.  I&#x27;ve looked at the answer, and I have the &quot;right&quot; solution memorized.  That kind of feels like cheating though  Should I have been able to write that &quot;right&quot; solution straight away, with no prior exposure to the problem?<p>Just trying to understand what my goal is in this process, and what is considered &quot;success&quot; for my studies.
======
shahbaby
I'm also trying to figure this out, here's my approach so far.

1\. Categorize - Can I identify what type of problem this is? (ie Graph
problem, bit problem, sliding window, etc.)?

2\. Plan a solution - Can I come up with a strategy to solve it?

3\. Based on how I felt about 1 and 2, am I confident enough to dive in and
solve it?

3A. If yes, as a final check, go to the discussions and see if you can get
some confirmation that you had the right approach just by reading the titles.
For example, if you were thinking that this was a backtracking problem because
that was the only way you thought it could be solved and you see that the most
upvoted posts are talking about priority queus, you probably had the wrong
approach. Otherwise if it looks like you were on the right track, only then
should you go ahead and start coding it.

3B. If you had the wrong approach or if you weren't confident that you could
solve it, then go ahead and learn from the solution.

You will learn a lot from the solutions that others posts but you will hardly
learn anything by wasting hours on a flawed solution.

To be clear, to get good requires going well beyond the fundamentals, you need
to learn from the best of the best in order to stand a chance.

~~~
marcuspvk
great advice. id say limit yourself to 10 mins to come up with a solution, and
focus on getting a solid intuition consistently

~~~
rubicon33
Let's take ThreeSum as an example.

Imagine you're encountering ThreeSum for the FIRST TIME as I did a few days
ago. I'd never before seen this problem.

What should my EXPECTATION OF SELF be for this? What is reasonable for someone
STUDYING to improve at algorithms. What would be considered SUCCESS?

Should I .... be able to intuit the O(N + NlogN) solution?

Ok maybe you would agree that's unreasonable to be able to just come up with
naturally having never seen the problem before.

Should I ... be able to intuit the O(n^2 * logn) solution?

Even that solution might reasonably evade someone? Or not?

Should I .... be able to intuit the brute force solution O(N^3) but have the
O(N + NlogN) solution memorized?

From wiki
[https://en.wikipedia.org/wiki/3SUM](https://en.wikipedia.org/wiki/3SUM) ...
it appears that the O(N + NlogN) took formal algorithm research and study.
Perhaps it's unreasonable to expect myself to on-the-fly solve some of these
algorithms with sub-cubic time?

~~~
bakuninsbart
I would count the stages of success like this:

1\. Brute force it. -> That is actually the most important step. In regards to
this one specifically, I would be surprised if interviewers expect more than
O(n^2).

2\. Guess what the best runtime would be. -> If you can reason why you expect
what to be the best runtime, it should bring you through all interviews.

3\. Get good solutions, but memorizing won't help you in the real world
(though it might in some interviews). Interview situation is pretty unique. In
a normal work environment, you can search the internet, argue with collegues,
sleep over it. If runtime is essential for the program you are writing, it
cannot be expected of anyone to come up with best solutions on the fly.

Regarding brute force solutions, they can still vary in quality. Is it
correct, easily understandable, without side-effects?

------
maps7
Let's take Euclid's algorithm which gets the greatest common denominator
between two given numbers. Euclid was a mathematician and "father of
geometry". According to Wikipedia, the algorithm was improved a long time
after he first described it. That means his one wasn't even the best!

Now we have programmers being tested in hour long interviews... how could they
come up with this stuff on the spot?

There is a reason why people have to study for tech company interviews.
Knowing the solution to a problem that is similar to the one that is being
asked will go a long way in the interview.

~~~
rubicon33
That's exactly what I'm trying to get at with this post.

I initially started my study of algorithms about a week ago, with nearly a
decade of professional programming experience under my belt.

I quickly realized that expecting myself to find the optimal, or even near-
optimal solution, was setting myself up for failure. Yet (hence this post) I
wasn't sure if that was the case for other people.

I continue to wonder what other people's experiences have been like in the
pursuit of algorithm study. Do you find that the intuitive, brute force
solution is readily available in your mind, but that you have to "peak" aka
"cheat" to find the elegant / right solution? Or are most people finding
themselves able to just tackle the problems outright, getting (or nearly
getting) the optimal (or nearly optimal) solution on first pass...?

~~~
maps7
Personally I am the same as you. My first attempt is never the optimal
solution.

------
sosilkj
agree w/ another comment that suggested going through an algorithms textbook
first. (MIT 6.006 online is also good.) i speak from experience: in some cases
there might be tools missing from your algo toolbox and it could be worth more
studying to fill in gaps.

for example, consider the maximum subarray problem (LC 53). this is a dynamic
programming problem. but if you don't know DP, you could spend a long time
staring at this problem without progress. even looking at the solutions won't
be that informative if the concepts of DP are not familiar. MIT's 6.006 course
takes _four_ lectures to cover DP (not including the recitations!), which
should tell you something.

------
plinkplonk
In your place, I'd work through a basic algorithms + data structures book
first, doing the exercises etc before attempting leetcode.

Learning via attempting leetcode problems directly seems suboptimal, like
trying to learn calculus by taking timed exams vs working through a basic text
first.

my 2 cents. fwiw.

~~~
tommydan
And what will your goto algorithms and data structures book be?

~~~
nerdomancer
I would suggest "The Algorithm Design Manual" by Skiena. It helped me a lot.

------
rubicon33
Again what I'm basically asking is -

Should you be MEMORIZING solutions, or, expecting yourself to come up with the
O(N)/O(1) solutions on your own?

~~~
lamchob
Why are these the only options? Why can't you just know there is a solution,
and know where you can look details up? Expecting to find ideal solutions on
your own every time is tedious and taking time away from solving the actual
problem you are working on.

~~~
rubicon33
Because that's not how interviews work, basically.

Trust me, I understand that in the real world that's exactly how you would
approach these problems.

