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

81–90 of 169 posts

Re: How to Rock an Algorithms Interview

#81

Post by georgieporgie »

rguzman wrote: post #79
georgieporgie wrote: post #76

Earlier quoted context omitted.

The companies who ask these questions do so because their engineers deal with these kinds of scaling challenges every day I'm skeptical of that statement. Some of the engineers at, say, Google, deal with code complexity and scaling every day. Most probably don't. Certainly, most at the non-Googlish companies hardly ever deal with this. Yet the majority of interviews I've gone to over 12+ years have involved significa…

People ask algorithms questions not because they are relevant, but because they are a good proxy for your abilities. Well, at least they are perceived to be a good proxy ...

Right, that's my point. It become sort of a cargo cult of candidate selection by people who don't actually understand what they want or need.

Re: How to Rock an Algorithms Interview

#83

Post by angelbob »

georgieporgie wrote: post #76
haberman wrote: post #64

Earlier quoted context omitted.

> Maybe it's because none of my personal projects have gotten popular enough to be subjected to the kind of load that reveals such problems. That's probably the case, and there's no shame in that. The companies who ask these questions do so because their engineers deal with these kinds of scaling challenges every day. They can't afford to have people casually slip in an O(n^2) algorithm when an O(n lg n) or O(n) algo…

The companies who ask these questions do so because their engineers deal with these kinds of scaling challenges every day I'm skeptical of that statement. Some of the engineers at, say, Google, deal with code complexity and scaling every day. Most probably don't. Certainly, most at the non-Googlish companies hardly ever deal with this. Yet the majority of interviews I've gone to over 12+ years have involved significa…

I've worked at a long series of companies that deal with these at least every week or so. Maybe not daily. But I'm writing code where it matters most days.

Maybe I'm unusually hardcore? I'm definitely not all about the algorithms, but I work on a lot of systems programming.

The other thing is that often you don't realize that what you're doing requires thinking of this until somebody else has to go fix what you wrote. The fix will even look very simple. The insight going into the fix isn't as simple, though.

Re: How to Rock an Algorithms Interview

#84

Post by haberman »

georgieporgie wrote: post #76
haberman wrote: post #64

Earlier quoted context omitted.

> Maybe it's because none of my personal projects have gotten popular enough to be subjected to the kind of load that reveals such problems. That's probably the case, and there's no shame in that. The companies who ask these questions do so because their engineers deal with these kinds of scaling challenges every day. They can't afford to have people casually slip in an O(n^2) algorithm when an O(n lg n) or O(n) algo…

The companies who ask these questions do so because their engineers deal with these kinds of scaling challenges every day I'm skeptical of that statement. Some of the engineers at, say, Google, deal with code complexity and scaling every day. Most probably don't. Certainly, most at the non-Googlish companies hardly ever deal with this. Yet the majority of interviews I've gone to over 12+ years have involved significa…

> I'm skeptical of that statement. Some of the engineers at, say, Google, deal with code complexity and scaling every day. Most probably don't.

I am an engineer at Google, and basically all of the engineers I work with have to scale their software in least one dimension such that big-O complexity is a significant (and daily) concern. What I mean by "daily concern" is that the check-ins are happening on a daily basis would be noticeably inefficient if they used an O(n^2) algorithm instead of an O(n) algorithm, for example.

> Certainly, most at the non-Googlish companies hardly ever deal with this.

My main experience is Google and Amazon, so I couldn't say. I was meaning to talk mainly about Google/Amazon/Facebook/Twitter-like companies. I'm betting Palantir is also one such place.

Re: How to Rock an Algorithms Interview

#85

Post by pavelludiq »

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'll give you my point of view. I'm young(21), I'm in my third year as an informatics student, and I feel greatly intimidated by all these hard stuff. I can barely write a working web app, even with all the hand-holding modern frameworks give me. I don't consider myself smart(i'm bright enough to be a programmer, but nothing more).

Recently I sat down and thought about where I want to be in 5-10 years. I don't want to be writing django apps in 10 years, I don't want to write software that sort of works some of the time, and i don't want to be a replaceable commodity programmer working on outsourced software that the real programmers didn't feel like working on, so they send it to India, or Eastern Europe(which is where I’m from). Sure, I can make a comfortable living that way, but what I want to be in 10 years is a competent expert.

I want to work in diverse fields, with people much smarter than me, and the little knowledge and experience I can gain in my career I want to pass down to younger programmers. I want to wake up in the morning and be proud that I've build things that actually matter, and not just the latest social networking pop-culture crap that many of us are dealing with now. In short, i want to e a hacker!

To do this, I decided to dedicate myself to actually learn the hard stuff that most people shy away from, just because they can get by with only some python/ruby/php and jquery knowledge. Math, CS(algorithms, data structures, languages, compilers, architectures, networks, operating systems), science, philosophy, history, art, etc. All hard stuff that I'll never need to know in order to build a web store site for a small business that barely gets the web, get paid, and go wash the car on the weekend. Even if i can never learn all of it, even a fraction is better that writing the same simple web apps for 10 years.

Re: How to Rock an Algorithms Interview

#86

Post by VladRussian »

mcantor wrote: post #69
VladRussian wrote: post #48

Earlier quoted context omitted.

>I'll worry about the time my code takes once it's notieably slow. the Dunning-Kruger is exactly about ability to notice >If everything I write runs in a fraction of a second, where are different fractions of a second out there. Some are slow, some aren't. One either knows which are which or he doesn't. >why would I waste my brain optimizing it to make it faster, when all I'd achieve is introduce tricky bugs. that is…

>I'll worry about the time my code takes once it's notieably slow. the Dunning-Kruger is exactly about ability to notice It seems like you are saying that every programmer ought to go out of his way to become fluent in algorithms, because without fluency he or she will never notice when their code is running slowly. If so, I disagree. It requires no skill to notice whether code is running slowly--you needn't look fur…

>"Jeez, this thing takes forever to boot up"

this "forever" consists of myriad of "a fraction of a second"-s, with each fraction individually not being "notieably slow" and thus not "prematurely optimized".

And if not optimized "prematurely" (ie. written efficiently from the start), then after-the-fact optimization, if happens at all, would shave only a fraction out of the "forever" - thus it frequently doesn't happen at all because of such low projected ROI.

Re: How to Rock an Algorithms Interview

#87

Post by [deleted] »

mcantor wrote: post #69
VladRussian wrote: post #48

Earlier quoted context omitted.

>I'll worry about the time my code takes once it's notieably slow. the Dunning-Kruger is exactly about ability to notice >If everything I write runs in a fraction of a second, where are different fractions of a second out there. Some are slow, some aren't. One either knows which are which or he doesn't. >why would I waste my brain optimizing it to make it faster, when all I'd achieve is introduce tricky bugs. that is…

>I'll worry about the time my code takes once it's notieably slow. the Dunning-Kruger is exactly about ability to notice It seems like you are saying that every programmer ought to go out of his way to become fluent in algorithms, because without fluency he or she will never notice when their code is running slowly. If so, I disagree. It requires no skill to notice whether code is running slowly--you needn't look fur…

[deleted]

Re: How to Rock an Algorithms Interview

#88

Post by bmohlenhoff »

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…

http://www.amazon.com/Algorithms-Nutshell-OReilly-George-Hei...

The book was written as a companion to Introduction to Algorithms by CLRS and is comparatively lighter on theory, but still a handy desk reference.

disclaimer: it was written by my undergraduate advisors

Re: How to Rock an Algorithms Interview

#89

Post by hellotoast »

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…

Author of the post here. I don't think you're "doing it wrong" or missing anything because of a cognitive blindspot. Algo skills are important for certain types of problems (scaling, number crunching), but useless for others (interaction design, API design, ...). It's just one of the skills we're looking for, since a lot of our meatiest problems don't require algorithms at all (beyond a simple hashtable or two). If you've looked at your own coding history and don't see the need to be more fluent with algorithms, then you're probably right.

Re: How to Rock an Algorithms Interview

#90

Post by Hoff »

dennyferra wrote: post #50
ohyes wrote: post #29

Earlier quoted context omitted.

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…

I've been doing this exact same thing to learn. I read an interview question that asked how to sort a linked list. I tried implementing it on my own. Later I looked online to see other implementations and compared with my version. I was a little bummed to see my solution wasn't ideal but it only made me dig deeper. Later on I found some Stanford lectures, particularly Programming Abstractions by Julie Zelenski (aroun…

The Art of Computer Programming (TAOCP), Knuth

http://www-cs-faculty.stanford.edu/~uno/taocp.html

Post reply on HN