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

111–120 of 169 posts

Re: How to Rock an Algorithms Interview

#111

Post by jchonphoenix »

I'm seeing a lot of great discussion on this thread, but I'd like to point out that you should NEVER rely on memorization to know the asymptotic bounds of operations on data structures.

You should understand how that data structure works and then derive the running time from that.

People seem to know hash sets use O(1) lookup, trees use O(log(n)), and so forth. In reality, they have an in depth understanding of the underlying implementation and are rederiving their answers on the spot with simple mental calculations.

Re: How to Rock an Algorithms Interview

#112

Post by ori_b »

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…

As a self taught programmer, I fully agree with you. Forcing myself to work through CLRS was the most important thing I did on my way towards where I am.

What you said isn't condescending at all. If you are a self taught programmer and you haven't read up and gotten a good handle on big O notation, data structures, and algorithms, do yourself a favor and start.

Re: How to Rock an Algorithms Interview

#113

Post by regs »

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

Earlier quoted context omitted.

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…

That would only be a risk if we were talking about a typical high school multiple choice test. I would think that a cheater would be filtered out by this point in their career (this point being applying to a high tech company). However, collaborating on a solution is not necessarily a bad thing. I think the goal here is to find candidates which can deliver unique, valuable, and insightful problem solving skills. To g…

You'd be surprised at what people will do to game an interview. I've had people give me the correct answer to a question I didn't ask (but from our list of questions) - clearly having gotten from someone else who had interviewed earlier.

Note that algorithms interviews are just one part of a larger inventory that one takes of a candidates, one dimension. Take home and/or whiteboard coding can be a part of that process as well, but each has its downsides.

What we look for, in particular, is methods that have a very low false positive rate. In person algorithm interviews, where the point is not the 'right' answer but hearing about how someone thinks are in that category. You can't really fake it.

Re: How to Rock an Algorithms Interview

#115

Post by regs »

steve8918 wrote: post #70

The interview process at this point, at least in Silicon Valley, is broken. There's an arms race between interview "gamers" that memorize all the answers to every single question out there, vs interviewers that are asking increasingly ridiculous questions. It's naive to think these days that not knowing the answer to a common question, but coming up with the answer will work. It won't. If 9 candidates know the answer…

It was much cooler to be jaded about the interview process last year.

But in all seriousness, I'm sure there are companies like the one you described and there are many that aren't that way. I'm certain that your blanket characterization of 'the interview process, at least in Silicon Valley' being broken is incorrect.

You don't need to come up with weirder and harder questions. You just want to give them something in a form that they haven't seen before. It makes them listen and think, which is what you're looking for.

I always look at an interview to be more like a code review than a unit test: it's not about getting the right answer, it's how you get there that tells me what kind of an engineer you are. In fact, if you get the answer too quickly or jump to it, even if I don't think you're cheating, I need to ask another question or make you explain yourself in depth so I can probe how you got there.

Re: How to Rock an Algorithms Interview

#116

Post by william42 »

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?

YC uses HN usernames internally.

Re: How to Rock an Algorithms Interview

#117

Post by sciboy »

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…

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 understanding of the mathematics behind it than he did. I'm not smarter, far from it, just have more tools to call on. And this was a guy that taught the algorithms course at a good university.

We are all capable of learning almost anything, but a lack of knowledge about the subject matter constrains your solution search space to a large degree. I believe strongly that fluency in algorithms is a minimal prerequistite to be a decent developer. It's like learning calculus without knowing trig, you can do it, but you'll be reinventing (poorly) a tonne of work that came before and you'll be slower and less accurate. It's not like it's rocket science either, you could get a basic understanding in a concentrated day of work so there's no reason not to.

Re: How to Rock an Algorithms Interview

#118

Post by mcantor »

groby_b wrote: post #95
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…

Based on 20 years of experience, lack of fluency in algorithms _is_ a surefire indicator of bad architecture skills. Yes, it gives a few false positives, but the amount of false negatives is pretty much 0. And since actually getting a new person on-board is an expensive process, you aim for criteria that are a bit too stringent, if you can afford it. There's also the issue that making a bad algorithmic decision at th…

Thank you, this is an illuminating response! Hopefully I'll remember to look back on this thread when I'm enlightened so I can see if I've switched sides on the debate. :-)

Re: How to Rock an Algorithms Interview

#119

Post by lars8128 »

georgieporgie wrote: post #81
rguzman wrote: post #79

Earlier quoted context omitted.

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.

I suspect a "cargo cult" for hiring is not what rguzman meant. Rather, algorithm skills are one of the best signals you can extract from a short interview. I've always found them to be much better at predicting a candidate's ability to do the job than anything else I could ask in 45 minutes. That may mean I'm a poor interviewer, but until I can figure out better questions to ask, I'm happy to use this signal since in my experience it works well.

Re: How to Rock an Algorithms Interview

#120

Post by outworlder »

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. 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 time for me to hit the books, and where to start. Obviously, it would take me longer than someone with prior experience in writing such code! If the overarching question is "does algorithmic fluency constitute a dealbreaker when hiring at certain positions", then I suppose the answer depends on how much longer it would take. I can only speculate on the difference in a flagrantly biased manner, as I would egotistically prefer to believe that I ought to be hired in more cases than not. :-)"

You are SERIOUSLY underestimating the amount of time required to learn that stuff. In essence, the full 4 years of a CS course deals with data structures, algorithm and math. Good luck finding a project where the stakeholders are willing to wait that much. Also, unless you are a very unique snowflake, you will not have the required discipline.

On the other hand, learning a new language is accomplished in a matter of days. Learning how to code well requires experience and willingness to learn from one's mistakes.

Which a candidate with a good CS background may already have.

Post reply on HN