How to Rock an Algorithms Interview • Hacker News Board

Re: How to Rock an Algorithms Interview

#121

Post by jimbokun » Tue, Sep 27, 2011, 1:04 AM UTC

mcantor wrote: post #80

jchonphoenix wrote: post #67

Earlier quoted context omitted.

Our interviews at Palantir test for these for two reasons: We evaluate a lot of people coming straight out of school in CS. They don't have much experience in development. Thus, the best way to test if a candidate is smart is to see if he's learned his course material well. We do a lot of heavy algorithms and distributed systems, so we ask that, but it also happens to be what students learn. Running time and Oh, howe…

I upvoted you for the good explanation (and the refreshingly self-aware edit). However, I think it is rather presumptuous to paint the broad strokes of "good" and "bad" without adding so many caveats that it would no longer be germane to this conversation. By your definition, I am currently a "bad programmer" because I do not have fluency in algorithms. (I will leave the objective truth of this statement as an exerci…

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

How do you know whether or not this is true? Until you know it, how do you go about estimating how long it will take to you to learn it? How do you even assess when you've learned "enough" algorithmic complexity for the task at hand? Can you give any reasons someone looking to hire you should believe that you can learn the ins and outs of algorithmic complexity with "very little friction"?

Re: How to Rock an Algorithms Interview

#122

Post by jarek » Tue, Sep 27, 2011, 1:19 AM UTC

ryan-c wrote: post #27

regs wrote: post #19

Earlier quoted context omitted.

Whoops - yeah, we're working on that problem right now - at the moment it's back up.

It looks like it should stay up now - the traffic from this is much more than we usually get, but it's doing fine now that the server has more resources available to it.

You sure there couldn't have been an algorithm you could have optimized instead of just throwing more resources at the problem? Your solution seems awfully real world.

Re: How to Rock an Algorithms Interview

#123

Post by jimbokun » Tue, Sep 27, 2011, 1:21 AM UTC

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

I tend to think of programming tasks being split into two major categories: applications programming and systems programming.

My definition of these terms: applications programming is writing software to be used by a normal person. Systems programming is writing software to be used by another programmer. (These definitions may be a little different from how these terms are commonly used.)

From your self description, you seem to land pretty squarely on the application programming side of that divide. For most application programming tasks, getting good performance consists mostly of selecting libraries, databases, web servers, languages, etc. with the performance characteristics your application requires, and building your application on top of them.

The system programmer is the one writing those libraries, etc. and so those performance requirements fall squarely on them.

So I would say that as long as you stick to applications programming, algorithmic ignorance probably isn't a major problem. But a company like Palantir needs systems programmers (per my definition above, even if the "clients" are just other developers within the company) which is why they need to ask algorithms questions in their interviews.

Re: How to Rock an Algorithms Interview

#124

Post by jimbokun » Tue, Sep 27, 2011, 1:29 AM UTC

pavelludiq wrote: post #85

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 t…

This seems to be the path taken by Paul Graham and Robert Morris (just to name an obvious example most readers here will know). Because they knew a lot about Computer Science (and Lisp), they were able to take an approach to building their software and business that their competitors would have never considered. I'm guessing their knowledge of "science, philosophy, history, art, etc." played a big part in their approach, as well.

Which is to say, I think you're on the right track if you don't just want to follow the popular trends, but want a chance to do something new in a way that no one has even considered yet. Which certainly sounds a lot more fun, if nothing else.

Re: How to Rock an Algorithms Interview

#125

Post by earl » Tue, Sep 27, 2011, 1:34 AM UTC

prodigal_erik wrote: post #96

mcantor wrote: post #80

Earlier quoted context omitted.

I upvoted you for the good explanation (and the refreshingly self-aware edit). However, I think it is rather presumptuous to paint the broad strokes of "good" and "bad" without adding so many caveats that it would no longer be germane to this conversation. By your definition, I am currently a "bad programmer" because I do not have fluency in algorithms. (I will leave the objective truth of this statement as an exerci…

The thing is, it's very easy to end up using a bad algorithm without noticing. If you're doing a linear search over a collection of n elements, fine, but if you end up having to do it n -ish times, suddenly you're up to O( n ^2), and if n is ever a few million in reality, your app will enter a loop that's practically infinite. Meanwhile, sorting them would be O( n log2 n ) and intersecting two sorted lists is O( n ),…

This algorithm fetish is just stupid. If a function / program isn't slow then it doesn't matter and if it's slow the dev will notice. I mean, come on -- is the dev not going to notice a practically infinite loop?

Re: How to Rock an Algorithms Interview

#126

Post by jimbokun » Tue, Sep 27, 2011, 1:37 AM UTC

georgieporgie wrote: post #106

angelbob wrote: post #83

Earlier quoted context omitted.

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…

I've worked at a long series of companies that deal with these at least every week or so And I've worked at a long series of companies that don't. That's the thing: different strokes for different folks, as it were. Maybe I'm unusually hardcore? I think it's less about degree-of-core-ness and more about platform and domain knowledge. Personally, if I were hiring for what I consider to be a fairly typical company, I w…

My preference would be that any developer for any job should be able to write functional, and (fairly) bug-free code.

Then I would hope they have a good sense of usability, if they are writing user facing code. And I would hope they have a good sense of algorithms and other aspects of scalability, if they are writing server side or systems code.

Re: How to Rock an Algorithms Interview

#127

Post by jobu » Tue, Sep 27, 2011, 1:46 AM UTC

rhizome wrote: post #52

MattLaroche wrote: post #6

Disclaimer: I work at Palantir Technologies. These are my own opinions and not my company's. The Palantir post is great for how to handle yourself when you are already there. Steve Yegge's "Get That Job at Google" is a great how-to-really-prepare piece. http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... A couple other suggestions: * Find sample questions that similar companies use. Work through them. Dis…

You mean the anti-Wikileaks Palantir?

Yes (http://www.businessinsider.com/palantir-wikileaks-2011-2), but they have since have since apologized for that (http://www.businessinsider.com/palantir-wikileaks-apology-20...

Re: How to Rock an Algorithms Interview

#128

Post by zobzu » Tue, Sep 27, 2011, 1:48 AM UTC

why those quizz interview sux is simple: anyone can look up the questions, learn them in 2 weeks of time (going slowly) if they've any kind of basic programming knowledge. so basically the questions are wasting the interviewed person's time.

if the person fails that test, it means they just didnt care much about that job. but i'm pretty sure any skilled interviewer can figure that out through a much quicker process.

Re: How to Rock an Algorithms Interview

#129

Post by neilk » Tue, Sep 27, 2011, 2:16 AM UTC

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 don't seem to need this information to do what I do

Are you sure about that? Have you never tried to do something, found it was taking forever, and gave up? Maybe you concluded it was impossible, or you found some way to approximate what you needed.

I am another self-taught programmer, and believe me you are going to be kicking yourself once you do learn a few good algorithms and data structures. Your favorite accomplishments -- intricate beasts that you felt you had tamed with much sweat and effort -- are going to turn into five or six lines. Or maybe two or three small, easy to understand programs. Impossibly large amounts of data are going to look easily tameable.

> How does one achieve this?

Not so hard - read a good book. There are lots.

Re: How to Rock an Algorithms Interview

#130

Post by astrofinch » Tue, Sep 27, 2011, 2:32 AM UTC

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…

The collections data structures are more or less designed to achieve certain performance characteristics. So knowing those performance characteristics means knowing what those data structures were designed to do. This seems like a pretty critical part of familiarity to me.