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

31–40 of 169 posts

Re: How to Rock an Algorithms Interview

#31

Post by esrauch »

njharman wrote: post #10

>Given a whiteboard and one hour, We, hiring folks, aren't limited to just that anymore. There's github, linkedin, hn/reddit posts, random google stalking, etc. I can find a lot about you, your attitudes, opinions, ability to communicate, style, etc. that, or you for whatever reason (paranoid, on the lam, aren't passionate) have zero online presence). The face to face interview is mostly to confirm or refute what I'v…

What about people who don't use their real name online? Do people really give recruiters their reddit username?

Re: How to Rock an Algorithms Interview

#32

Post by VladRussian »

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…

>My main problem is that I don't seem to need this information to do what I do. 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. Maybe I've been lucky.

if you don't know the time it really should take, then you just don't know what you have a performance problem. Dunning-Kruger in application to software engineering. Too typical a situation in the industry.

Re: How to Rock an Algorithms Interview

#33

Post by alain94040 »

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

Re: How to Rock an Algorithms Interview

#34

Post by [deleted] »

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…

[deleted]

Re: How to Rock an Algorithms Interview

#36

Post by alain94040 »

VladRussian wrote: post #32
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…

>My main problem is that I don't seem to need this information to do what I do. 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. Maybe I've been lucky. if you don't know the time it really should take, then you just don't know what you have a performance problem. Dunning-Kruger in application to sof…

I'm an engineer. I'll worry about the time my code takes once it's notieably slow. If everything I write runs in a fraction of a second, why would I waste my brain optimizing it to make it faster, when all I'd achieve is introduce tricky bugs.

Coding is an engineering discipline: it's all about tradeoffs. Bugs and reliability. Performance. I know to focus on what is important to get a working product.

Re: How to Rock an Algorithms Interview

#37

Post by adbge »

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 of a classroom setting. Bonus points if it has a practical focus so that I can quickly add the gleaned knowledge to my real-world toolkit.

Re: How to Rock an Algorithms Interview

#38

Post by mcantor »

ohyes wrote: post #29
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…

I didn't do CS as a major in undergrad (I found it too easy... that sound pretentious, but the program at my college simply wasn't difficult enough for me), but I did do a MS in CS afterwards. It helped a lot with basis for algorithms (terminology so you can understand what you are reading), but it didn't really teach me all of the data-structures and algorithms that I know. (There are really too many to cover everyt…

Thank you for the Wikipedia suggestion; I hadn't really considered using it as a learning resource because I've had bad experiences trying that with other fields. (For example, I think Wikipedia is an abhorrent place to learn mathematics, though it clearly functions well as a reference for people who already know what the hell is going on.) Perhaps being already fluent in the fundamental concepts of programming and computer science will make the Wikipedia articles on data structures & algorithms more useful from a learning perspective.

Tinkering with the source code for $language is also a great idea! That meshes with my empirical experience that the best way to learn is to "play". These days, it's rare for me to write code that isn't related to some specific personal project or business goal; maybe bringing back a bit of the "play" aspect is one of the keys to improving fluency.

Re: How to Rock an Algorithms Interview

#39

Post by rcfox »

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…

There aren't too many things to remember in order to be useful:

- Operations that take the same amount of time regardless of the input are O(1). ie: 1+1 takes just as long as 10000+10000 (okay, not really, but it's a reasonable assumption.)

- Doing a small sequence of operations runs in O(maximum of all operations). Doing 5 adds (which are O(1)) runs in O(1). Doing an O(n) operation followed by an O(k) (where k > n) runs in O(k) time.

- Looping n times over O(k) operations runs in O(n*k) time. (Assume n is fairly big.)

- Due to the structure of a tree, accessing a node is generally O(depth of the node). Max depth = log_m(number of nodes) for a full tree. (Where m is the number of children each node has. For a binary tree, m=2)

- From there, you can pretty much combine these rules to analyze many algorithms. These aren't by any means all of the rules, but they are some of the most useful in my experience.

Re: How to Rock an Algorithms Interview

#40

Post by tedunangst »

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…

On like the very first day of algorithms class there was a table with a bunch of data structures down the side and insert, lookup, delete across the table with a bunch of n's and lg n's in the cells. There was also a table very much like it on the first exam, except the cells were empty.
Post reply on HN