Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Rock an Algorithms Interview

blog.palantir.com

Post reply on HN
Print view View original

151–160 of 169 posts

Re: How to Rock an Algorithms Interview

#151

Post by kamaal »

pavelludiq wrote: post #147
kamaal wrote: post #144

Earlier quoted context omitted.

I would say that you will feel this way once you see someone doing half the difficult job you do, but because of his productivity and problem solving skills takes huge strides because of the lack of good folks in the 'outsourcing quality' work that you describe. The day you see such a guy, you suddenly get a feeling about the what the hell are you doing being average among the crowd of algorithm writers, while you co…

I have to disagree. How did those people become brilliant? Hanging around smarter people probably had something to do with it. That's why I joined HN in the first place, 1207 days ago I was probably among the most inexperienced, and stupid people on this site, probably still am, even though I've grown so much since. I think there is no shame in choosing the simpler route, but i can't make this choice for my self. I c…

I am all for hanging out with smart people. Learning and working on tough problems. But If your even half serious about doing something big. Those leanings have to happen quickly. You will have to then go on by yourself. Do something on your own, lead and manage something big.

My point was that there is no benefit in being the average among the best. But you can do wonders by being the best among the averages.

Of course you can disagree with this. But more often, all you will need is certain guiding principles in life 'which you need to learn from smart people' after that you will have to the grind work individually on your own. The sooner you learn those principles the better. There is never going to be a situation where you will be carbon copying from those smart people all over the time.

The other sort of learning, is incremental learning which happens all time, regardless of where or what work you do. Regarding specific life changing learnings, there are only going to very few of those in your whole life.

Re: How to Rock an Algorithms Interview

#152

Post by jamii »

mcantor wrote: post #30
tikhonj wrote: post #25

Earlier quoted context omitted.

What I've found is that I do not remember that, say, a tree map or heap have logarithmic insertion time, but rather have a vague mapping of general concepts to behavior: something like "tree" => logarithms, "list" => lines (linear), "array" => magic (constant). Then I think something like "a hashmap is like an array, so it can be accessed in constant time". If you're a visual thinker, the "shape" of an algorithm or d…

Thank you, this is a great answer that confirmed some of my suspicions. I'd be interested if anyone could recommend other good resources such as Project Euler. Perhaps the book Data Structures and Algorithms ought to be higher up on my reading list? I would feel a lot more enthusiastic about getting a copy and diving into it if someone with the context of my OP question could confirm that it's a relevant resource.

The facebook puzzles are pretty good, especially for graph algortihms.

Re: How to Rock an Algorithms Interview

#153

Post by cygwin98 »

sciboy wrote: post #146
dlo wrote: post #131

Earlier quoted context omitted.

I don't have enough information to make any conclusions here. But let me add to the discussion that more often than not, it is an order of magnitude (or more!) easier to look at someone else's solution and understand it than it is to arrive at the solution in the first place. I am even willing to believe that, perhaps if the problem were very well-defined, you might be able to solve it in an afternoon. But if you wer…

It wasn't this. The example was trying to show that a lack of knowledge can be catastrophic in terms of productivity for even the gurus. He spent more than six months on this particular problem and if he had known more math (very typical of people in comp sci unfortunately) he would have been enormously more productive. The problem was formulated before he started any work on this, it really was his lack of (graduate…

To be fair, what he needed was actually DOMAIN knowledge, in this case, some specific math stuffs. Unfortunately, unlike other domain knowledge such as business workflow, stuffs like Math and Physics are kind of hard-core, can not be quickly picked up by self-learning. He should have had some domain experts (mathematicians) to help him.

Re: How to Rock an Algorithms Interview

#154

Post by sateesh »

adbge wrote: post #37
mcantor wrote: post #21

FTA: You should know these data structures inside and out. What are the insertion/deletion/lookup characteristics? (O(log n) for a balanced binary tree, for example.) How does one achieve this? Not just being familiar with data structures and algorithms (I am), but being fluent in them, to the extent that you can produce the Big O complexity for different operations off the top of your head. I didn't have a tradition…

Related: What books or other resources would HNers recommend for someone with limited algorithm and data structure experience who wants to beef up via self-study? I'm specifically interested in books/other resources that lend themselves to self-study. It's easy enough to look up what MIT is using for their Intro to Algorithms course, but it's harder to gauge if a book or other resource is suitable for usage outside o…

I have found "Foundations of Computer Science" by Aho and Ullman approachable. The book is available online at: http://infolab.stanford.edu/~ullman/focs.html

Re: How to Rock an Algorithms Interview

#155

Post by zephjc »

praptak wrote: post #23
ohyes wrote: post #4

>Given a whiteboard and one hour, determine whether the person across from you is someone you’d like to work with, in the trenches, for the next n years. If we ignore the requirements of one hour... Brute force: Hire a random candidate that hasn't been hired by you before. Fire them when you get fed up with them. Hire a different candidate. Repeat. Greedy Algorithm: Develop the model for an ideal candidate, assign th…

Recursive: require the candidate to come up with the perfect hiring strategy.

Now, would the old candidate be pushed down the stack, or would there be some TCO (tailing candidate optimization) going on where only the most recent one exists?

Re: How to Rock an Algorithms Interview

#156

Post by gaius »

kamaal wrote: post #136
outworlder wrote: post #120

Earlier quoted context omitted.

"I contend that I am capable of learning new material quickly enough that, if I were suddenly called upon at my job to write code which handles all of the slings and arrows of algorithmic complexity, I would be able to do so with very little friction. To phrase it differently: I (probably) don't know enough to write gorgeous, algorithmically sophisticated code on the first pass, but I know enough to know when it's ti…

When talking of learning in this sense, no one talks of reading the book from the first page to the last page. The learning is often sufficient to serve the needs at the moment. If I have to quickly fix my juicer, I don't under go do Electrical and mechanical engineering courses for the next 4 years. Instead what I do is, I define the problem. Search for the solutions on the internet. The solution requires me to unde…

Search for the solutions on the internet

This is the problem with kids these days.

Re: How to Rock an Algorithms Interview

#157

Post by alttag »

I think the part that's missing from discussion here is: "First: Make sure you understand the problem". Sure, for strictly algorithmic questions, where there is one mathematically demonstrable optimal answer (or at least, a way to compare solutions), this may seem less important, but for more open-ended questions (e.g., "How many barbers are there in [$LOCATION]?"), clarifying the why is essential, because definitions are important and vary by context. It's also important to seek whether a "good enough" solution is acceptable, or if high optimization is important. (Related, what are the memory/processing/load/runtime constraints, if any.) These are the sorts of questions that, in my mind, demonstrates a candidate's willingness to reflect on his/her own solutions.

Re: How to Rock an Algorithms Interview

#158

Post by Thrymr »

glenjamin wrote: post #104
strlen wrote: post #91

Earlier quoted context omitted.

> I work predominantly with server-side, interpreted languages, and I just don't run into the bottlenecks and performance problems that Big O-knowledge seems to mitigate. Algorithmic complexity isn't about performance, it's about scalability. A hand-written implementation in assembly that's O(N^2) will be slower than an implementation in Basic that's O(N) (or even O(N log N)) for a sufficiently large N. I suggest pic…

The problem with this is, in most cases you're not dealing with sufficiently large N - plus the high-level language of choice will already come with an efficient sorting algorithm for whatever lsit type it provides. Whenver you do start to approach values of N for which you need to fine tune, you're going to be researching and profiling and optimising the hot code anyway. I'm not saying you don't need to know algorit…

Maybe. But it is terribly easy in a high level language to use a built-in function that is O(N) and put in in a loop, and now you're at O(N^2). Maybe it works in reasonable time for N=10,000. Maybe you test it on small data sets to see that it works. Now turn it loose on an N=10^7 dataset. Oh.

Re: How to Rock an Algorithms Interview

#159

Post by Thrymr »

alain94040 wrote: post #33

... or you could just forget about O(n) questions in interviews. I know those got really popular with Google, but as an R&D software developer, I probably had to worry about complexity maybe about 0.1% of my time. How clean is your code? Do you have good coding habits? Do you get lost inside complex data structures? Do you understand concurrency issues?

"as an R&D software developer, I probably had to worry about complexity maybe about 0.1% of my time."

Yes, but does it scale? If you deal with 10x, or 100x, or 1000x the data, that % will grow. Fast.

Re: How to Rock an Algorithms Interview

#160

Post by nvarsj »

eric-hu wrote: post #57
dr_rezzy wrote: post #18

For me, this blog post represents a step backwards. They open up saying that the 1 hour interview provides absolutely no indication of how well a prospective candidate will perform. Hopefully most people will agree here. Then they go ahead and state that their staple interview will be an on the spot problem solving screening and then list the steps the expect the candidate to take in solving said problem. What does t…

That does seem to be an interview technique used at some companies. It comes with its own set of problems, though. What if someone asks a friend for help or pays someone to solve the problem in its entirety? If your problems aren't unique enough, they could also google the answers. With that said, I actually prefer your approach. Its pitfalls have to be weighed carefully; hiring someone who knew enough to fake it cou…

Apple does something very similar (or at least used to). They give a difficult algorithmic coding problem and a few days to complete it. Then they grill you on it at the on site interview. There is no way you could fake explaining it - you have to really understand what you did.
Post reply on HN