Comment by madflame991 | Hacker News Reader

Comment by madflame991 | Hacker News Reader

Parent Full thread

"I'd spend a month or two immersing myself in the technical, in the algorithms, in the memorization, and in the process push aside my creative and experimental tendencies."

Memorization is certainly not the way to learn how to solve math/cs/logic problems. There's a lot of thinking and (creative) experimentation involved when trying to solve a problem.

A lot of problems are classic problems in disguise. You'd be amazed to find out how many problems are just sorting + one traversal: reducing the average wait time in a queue, convex hull, counting duplicate elements (no extra space), interval scheduling, maximum number of overlapping intervals and a ton more. Can you memorize all of these problems individually? No, but you can ask yourself "how about if I sort my data first, what then?". If that doesn't work then try another question: "I have this brute force algorithm, if I use some other data structure will it get better?" - that question alone solves half of the problems I've ever seen. Follow up questions would be "does my problem look fractal-y?, maybe I can divide it repeatedly" or "can I incrementally build the solution?"

Even more interesting is that problems usually have more than one optimal solution: Prim's algorithms and Kruskal's solve the same problem in opposite-ish ways and use different data structs. How about substring searching: Boyer- Moore searches backwards, Rabin Karp computes hashes while others simulate automata. With self-adjusting binary trees it's the same story: a lot of very diverse solutions to the same problem.

Solving problems implies doing a lot of permutations and experimenting with data structures and classic approaches if you ask me - it's certainly not about memorising more than "sorting sorts and hash tables have constant-ish access time"

Is this process any different than changing colors, fonts and layout on a website until you get a good-looking enough whole? All you have to know are some principles about contrast, alignment, spacing and what not, and the rest is experimentation.

The author's point was that memorization is how you pass these silly interviews.

There's a wonderful paragraph in Skienna's algorithm book, where he states that if you can reduce your problem to a graph problem you should do so, and that you should never invent your own graph algorithm - the standard ones will solve whatever problem you have. Perhaps a bit overstated, but by and large true. There is definitely value in having all of that information at hand so you can fairly quickly perform the mental gymnastics to find a good solution.

I think most people complaining about interviews would agree with that. The thing is that so many people don't work in areas where they need at at the front of their brains, but they do work in areas where similar levels of ability are needed. Product design, finding difficult bugs, working with customers, leading teams, and so on. Bad interviews test memorization.

I'm doing almost all linear algebra these days. I can talk to you about matrix computations, round off errors of various implementations, and so on. You probably can't. But only because you are not doing it, and I am. I TA'ed a graduate level Algorithms class. At the time I could do whatever graph algorithm you wanted, now I can't because it is not what I work on now and most of the details have fled my brain. Doesn't mean I can't do it, just like you not being able to implement a Cholesky decomposition on a whiteboard means that you couldn't do linear algebra programming if it became your job.

"A lot of problems are classic problems in disguise. You'd be amazed to find out how many problems are just sorting + one traversal: reducing the average wait time in a queue, convex hull, counting duplicate elements (no extra space), interval scheduling, maximum number of overlapping intervals and a ton more. Can you memorize all of these problems individually? No, but you can ask yourself "how about if I sort my data first, what then?"

Amusingly, that's much of what an SQL query optimizer does. It has tables, indices, sorts, searches, and temporary files available, and automatically constructs an algorithm to do the query.

We need more technology like that, where you ask, and it figures out how.

This is still methodical thinking, and is not really lateral or creative in the sense that we understand it. Yes, a real mathematician thinks a lot, we can even say they are creative, but one using standard math to solve standard problems just has to practice solving problems in that class to become proficient.

A designer does not just change colors, fonts, and layouts until a website looks good, but that is a completely different kettle of fish (creativity and design are not equivalent, but programmers barely understand what designers really do).

Reply on news.ycombinator.com