How to Rock an Algorithms Interview • Hacker News Board

Re: How to Rock an Algorithms Interview

#131

Post by dlo » Tue, Sep 27, 2011, 2:55 AM UTC

sciboy wrote: post #117

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…

We once hired a guy with PhD in computer science & he was a (great) lecturer & researcher for many years. We got him to do some "complicated stuff". I'm not going to go further into the details in case he recognises this. After he left I went back to learn math for interest and got really into it. I now realise that literally six months of the work he did I could do in an afternoon as I now have a deeper understandin…

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 were in his situation, how long would it have taken you to characterize the problem so that you could solve it? Have you had successes doing "complicated stuff" for which there wasn't already something existing to key off of?

In computer science, there is the notion of the NP-complete problem, for which there is no known efficient solution. But if a solution is found, it can be verified very quickly. I think the analogy holds here.

Re: How to Rock an Algorithms Interview

#132

Post by jaylevitt » Tue, Sep 27, 2011, 3:04 AM UTC

jchonphoenix wrote: post #67

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…

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'm self-taught. I also wrote the world's then-largest mail system, which eventually handled 4,000 TPS at zero downtime on servers about as powerful as my iPhone. I also don't know algorithms.

E-mail, at the time, didn't need them - there was no search, no deduplication, no anything but "do a bunch of deterministic, bounded operations very quickly." Sure, some hash tables and plenty of linked lists, but that's about it.

Am I just a big fat outlier there, condemned to cram Skiena before every interview for the rest of my life?

Re: How to Rock an Algorithms Interview

#133

Post by ashr » Tue, Sep 27, 2011, 3:51 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…

It is unfortunate that instead of turning into a discussion about how to excel in an algorithms interview (which is what the original post is about) this thread has wandered into whether it is useful to even learn algorithms.

What a waste!

Re: How to Rock an Algorithms Interview

#134

Post by dhugiaskmak » Tue, Sep 27, 2011, 4:11 AM UTC

pjscott wrote: post #109

Blunt wrote: post #71

Frankly, I find this type of interview insulting. Let's face it. Unless you work with "algorithms" on a dialy basis, I'm willing to bet that most who do not cannot regurgitate a red black tree at the drop of a hat. I work in this field off in on as an embedded developer and I'm always going to various texts on the subject to align my thinking with the code I'm writing (C++ in my case). It's one thing to talk through…

I don't think anybody's asking you to write a red-black tree of the top of your head, but it would be nice if everybody knew what a balanced tree was and why they might be useful.

It would be nice, but I bet the former question is asked far more frequently than the latter.

Re: How to Rock an Algorithms Interview

#135

Post by njharman » Tue, Sep 27, 2011, 4:12 AM UTC

esrauch wrote: post #31

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?

More than one application I've handled recently has included links to HN and LinkedIn profiles. Most list github account.

Re: How to Rock an Algorithms Interview

#136

Post by kamaal » Tue, Sep 27, 2011, 4:16 AM UTC

outworlder wrote: post #120

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…

"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 understand some theory and some practical aspects of things with some tool usage. It is more than sufficient to that to solve the problem for the moment.

That is how most of the software is, its practically impossible to know every thing from the book. What is more important today is given the body of knowledge can a person study and solve the problems. A person can be productive and deliver the goods with the above approach, With a little discipline.

That's how most knowledge based work happens in the 21st century.

I also see a lot of people around me trading stocks, although they understand virtually nothing about economics in detail. For the most the part they can make 10-15% profit on their investment by just using some basic analytical skills.

Re: How to Rock an Algorithms Interview

#137

Post by rluhar » Tue, Sep 27, 2011, 4:18 AM UTC

haberman wrote: post #84

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…

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

And financial companies, banks, hedge funds etc. Even the most "boring" financial companies (actuaries, insurance companies) process huge amounts of data where performance becomes critical.

We have a data base that gathers about a 5GB of market data a day and we have to run algorithms to analyse the data and analyse the behaviour of our system. Efficient algorithms become very important.

Re: How to Rock an Algorithms Interview

#138

Post by jebblue » Tue, Sep 27, 2011, 4:22 AM UTC

jchonphoenix wrote: post #67

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…

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…

>> Edit: I realize the above comment sounds a little condescending. It wasn't meant to be. I have met self taught programmers that are amazing. Most people just don't have the self discipline to fully learn a subject matter (I many times don't). So a lot of "self taught" programmers have only taught themselves 10% of what they need to know and never bother learning the other 90%.

It was condescending to my eyes, nothing more nothing less.

Re: How to Rock an Algorithms Interview

#139

Post by jchonphoenix » Tue, Sep 27, 2011, 4:37 AM UTC

jaylevitt wrote: post #132

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'm self-taught. I also wrote the world's then-largest mail system, which eventually handled 4,000 TPS at zero downtime on servers about as powerful as my iPhone. I also don't know algorithms. E-mail, at the time, didn't need them - there was no search, no deduplication, no anything but "do a bunch of deterministic, bounded operations very quickly." Sure, some hash tables and plenty of linked lists, but that's about…

You may be an outlier, or you may just not be in the group of self taught programmers that was described. As I said, most self taught programmers don't fully understand what they do. Many, however, do. I was just explaining the most common case.

Judging by the fact that you were able to do many deterministic bounded operations quickly, and understand why they were bounded and why they were quick, I get the feeling that you'd do much better at an algorithm interview than you give yourself credit for.

And I'd also cram CLRS before an interview :P I know I'm good at what I do compared to the avg coder, but compared to the average coder at Palantir, I have a long way to go. I'm in no way satisfied with my ability where it is today and its always smart to take a refresher before an interview.

Re: How to Rock an Algorithms Interview

#140

Post by kamaal » Tue, Sep 27, 2011, 4:38 AM UTC

You must hire people for two things to win big today's world. Productivity and Analytical skills. If you are searching people with specific factual knowledge, sure that is important but often that leads only to mediocre or average results.

If you know how to do a thing before hand, that helps only in solving that kind of problems specifically. And that too only if the person is productive enough to do it in time. Any new problem or a change in paradigm of thought will require you to undergo the same regime of work what it would be for a newbie. They don't call learning a never ending process just like that.

The biggest winning point in today's world is not knowing something. But discovering something quickly, and acting on it in time. If you are not hiring people for this you will end with a lot of work force which looks good, but doesn't necessarily translate to doing good.

This is the biggest problem with education systems around the world currently. They impart facts and leave the person just there. Further its the individual responsibility to take that forward.

The most brilliant folks who have done big around me have hardly been algorithm experts. In fact if you are one, you are not likely to take big risks. You are more than happy with the addiction towards that monthly salary. And what helps you pay of those college loans.

The most successful around me are the ones, do a great thing. Think about the next step. Research about it, work on it with full productivity. Deliver.. Next step and the process goes on.

If you hire people for factual knowledge you may hire the best, but you are sure to miss out the exceptional. This is probably the reason, why big companies fail to come with game changers.

You get folks who are great at the regular day to day operations. But anything else, and you see the problems clear.