Live data from Hacker News

How to Rock an Algorithms Interview

blog.palantir.com

11–20 of 169 posts

Re: How to Rock an Algorithms Interview

#11
post #7

For an excellent discussion of the approaches outlined here and problem solving heuristics in general check out Polya's How To Solve It , it's a classic ( http://en.wikipedia.org/wiki/How_to_Solve_It )

Thanks for the link for the article - I appreciate it.

Re: How to Rock an Algorithms Interview

#12
One thing I noticed in recent interview is that the problems often test if the candidate can think to use two structures or algorithms to solve a problem. Early on, I made the mistake of thinking of interview questions more as homework problems from college where there was often only one type of data structure or algorithm involved in a problem. That's good when teaching a single concept, but real-world problem are more complex. My advice is to find problems that use multiple structures or concepts together and study and code those.

Also, learn to code the basics so well that you can do them by hand on a basic text editor or whiteboard. Get so good at it that you can write code that has a very good chance of running if it were actually compiled/run. I found that it's very different to code on a whiteboard than it is in an IDE or text editor. When my first interview came up, I struggled to write down things with a dry-erase that would have taken me seconds on-screen.

One strategy that I liked to see an employer use was homework. That might make some job seekers cringe, but gave me a chance to write real code like I would for a job. It was also a filter for how badly I wanted a job. There were jobs I didn't complete the homework for just because the location or employer wasn't something I was genuinely interested in.

I did homework for the position I landed and they did a code review as part of my interview. It went well, because I got to see how my future co-workers would handle giving feedback, and some comfort on my end that this employer actually cared enough to do code reviews.

Re: How to Rock an Algorithms Interview

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

have each applicant interview each other. The applicant that gets the most 'hires' wins

Re: How to Rock an Algorithms Interview

#16
post #9
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…

Two more approaches: 1) There's the well-known Secretary (or Marriage, or Sultan's Dowry) Problem ( http://en.wikipedia.org/wiki/Secretary_problem ). It has three caveats, though: * Solution assumes that you have a lot of (e.g. ~20) candidates. * It is assumed that you can sum up each candidate's ability in a single number. This is the hardest part, since the human mind works relationally and assigning absolute numbe…

1) The secretary problem does NOT assume a large number of candidates. In fact, your odds go down as the number of candidates go up.

2) The secretary problem DOES assume you can't go back once you've evaluated a candidate. This is not the case for prospective employees.

Edit: s/passed on/evaluated/

Re: How to Rock an Algorithms Interview

#17
I had an interview back in 2009 where the CTO of the startup asked me a question, I answered it, after which he very confidently corrected me with the wrong answer(!)

Needless to say I didn't join them. The startup also went belly up about 6 months after I interviewed there. How do guys like this get funded?

Re: How to Rock an Algorithms Interview

#18
For me, this blog post represents a step backwards. They open up saying that the 1 hour interview provides absolutely no indication of how well a prospective candidate will perform. Hopefully most people will agree here. Then they go ahead and state that their staple interview will be an on the spot problem solving screening and then list the steps the expect the candidate to take in solving said problem. What does this say about their own problem solving skills? I will leave this upto the reader. Let me throw an alternative out. Why don't you give a prospective candidate a written test/problem and give them as much time as they want, using methods and environments they are comfortable with, and have them return to you a solution of their choosing. Wouldn't this best capture how a person breaks down a problem, solves it, and finally presents a solution? Leave the onsite to better understand someones personality, likableness, and workability. Maybe even ask them to walk you thru how they came up with the solution and how they worked the problem. The options here are plentiful.

Re: How to Rock an Algorithms Interview

#20
post #9

Earlier quoted context omitted.

Two more approaches: 1) There's the well-known Secretary (or Marriage, or Sultan's Dowry) Problem ( http://en.wikipedia.org/wiki/Secretary_problem ). It has three caveats, though: * Solution assumes that you have a lot of (e.g. ~20) candidates. * It is assumed that you can sum up each candidate's ability in a single number. This is the hardest part, since the human mind works relationally and assigning absolute numbe…

1) The secretary problem does NOT assume a large number of candidates. In fact, your odds go down as the number of candidates go up. 2) The secretary problem DOES assume you can't go back once you've evaluated a candidate. This is not the case for prospective employees. Edit: s/passed on/evaluated/

I meant the 1/e neat solution (where the summation is replaced by an integral) assumes the large number. Otherwise, the sum can be evaluated directly, but no closed form solution exists.

I don't get your second statement, though, what do you mean by the "odds"? The 1/e solution is asymptotic.

Post reply on HN