The good thing is that most operations on most data-structures (as well as many of the more common algorithms) don't require solving recurrence equations to determine their asymptotic growth, usually our intuition based on counting tends to be pretty close.

Sketch out your basic data structures on a piece of paper, then just use your finger to trace out how you could do insert, delete, search, etc you can usually tell if something is taking O(lg n), O(n), O(n lg n), etc just by counting the steps you take. After you're comfortable with this, sketch it in your head. You can't forget something that you understand.

The point is that if figuring what out Big O is seems like something you have to memorize to recall quickly, then you very likely don't really understand the underlying data structure/algorithm (and as such you rightfully should do poorly on algorithms interviews). Take the time to make sure you really understand what's going on, and everything else should fall into place.

This is a bizarrely short-sighted move.

I have to wonder if Spotify has fallen victim to the siren's lure of "social". Perhaps they believe their future lies in integration with the social graph and news feed. If so (IMHO), they are sorely mistaken.

I believe some services already have you tweet or post that you've listened to a particular song. Zuckerberg seems to believe in "sharing and more sharing" [1] and automatic sharing. What would be the end result of this? On a particularly music-filled day I might send 100+ posts about songs I've listen to? Really? People will ever look at that?

If it's part of the main news feed, it's spam. If it's not, nobody cares... except Facebook, who can mine such data.

And maybe Spotify except... they already have access to this data (for their subscribers). It just makes no sense.

Spotify is also late to the party (in the US at least). Any kind of restriction like this is incredibly risky. Other established players don't have this restriction. While you can argue that "normal people" don't care, who recommends such services to family and friends? It's us.

And any player in the music space would be remiss to ignore the 800 pound gorilla in the room, being Apple's iTunes. iCloud launches soon. Honestly I think it'll kill a few of these "upstarts".

Also, I am less than convinced of the utility of mobile streaming. Bandwidth and connectivity are still issues. Increasing storage and all-you-can-eat subscription models seem like a far better solution (IMHO).

[1]: http://bits.blogs.nytimes.com/2011/09/23/zuckerbergs-unspoke...

>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 that candidate a numerical model and then compute the distance from the current candidate to the ideal candidate.* Hire the candidate with the lowest computed distance. If a candidate comes along with a lower computed distance fire the old candidate and hire the new one.

Simulated Annealing: As with the greedy algorithm, but instead of hiring based solely on lowest computed distance, include a small % chance that you will randomly fire the candidate and hire candidate that is slightly worse. (Optional extension to the algorithm is to keep the best candidate so far cached somewhere, potentially a transporter buffer).

Genetic Algorithms: From your pool of candidates, select the top candidates. Breed these candidates, randomly introducing mutations. Repeat again with the progeny of the previous pool, until one of the candidates passes a satisficing threshold 'distance' score.

* = Notice that this is the actually the most difficult part of (almost any useful application of) these algorithms but I managed to hand-wave right through it.

Hell must be freezing over.

10 June 2011: Duke Nukem Forever released - https://secure.wikimedia.org/wikipedia/en/wiki/Development_o...

12 July 2011: PuTTY 0.61 released - http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.ht...

20 July 2011: "Signs of life from GNU Hurd" - https://lwn.net/Articles/452296/

28 July 2011: GNU Emacs developers discover that Emacs has been violating the GPL since 2009 - https://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01...

26 September 2011: Textmate 2 Alpha announced

I joked about this on my blog earlier this year, but wasn't expecting it to happen.

A reply from Darren, a Spotify employee:

"Hey Guys thanks for your question, Unfortunately you will need a Facebook account to access Spotify from now on, unless you already have an account set up.

This does not stop you creating the Facebook account adding nothing to it and making it totally private as the Facebook account does not have to be actively used. "

This is asinine.

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 traditional CS education in college. Maybe there's some kind of magic that happens in Algorithms [1-3]01 that permanently etches these characteristics into your brain. But whatever it is, I missed out.

My main problem is that I don't seem to need this information to do what I do. 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. Maybe I've been lucky. 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. Maybe it's because I haven't worked on the kind of project that needs this sort of attention. Whatever the reason, I simply have never hit a point in my work (which I assure you has been non-trivial at times) when I sat back and said to myself, "Gosh, if only I were more familiar with the complexity breakdown of the classic data structures, I would be able to solve this problem much more effectively or efficiently."

The thing is, I know that I'm perfectly capable of nurturing greater fluency in algorithms, so it seems like a waste to inevitably flub the more demanding portions of algorithm-based interviews. So what should I do? Is the answer as simple as biting the bullet and using flash cards until I know it all by rote (which feels like cheating), or am I "doing it wrong" somehow? Is my lack of fluency preventing me from understanding just how important it is (a la Dunning-Kruger)?

I just pulled Steve McConnell's (must read!) CODE COMPELTE: A Practical Handbook of Software Construction off my bookshelf. The section How Long Can a Rountine Be? references some surprising (but perhaps dated) studies that suggest the evidence in favor of short routines is "very thin" and the evidence in favor of longer routines is "compelling". These studies are probably biased to desktop and corporate software written in C during the 1980s.

The consensus is that routines should have fewer than 200 LOC, but that routines shorter than ~30 LOC are not correlated with lower cost, fault rate, or programmer comprehension. btw, the longest function I've seen in commercial software I've worked on was 12,000 LOC! I will not name names. :)

* A study by Basili and Perricone found that routine size was inversely correlated with errors; as the size of routines increased (up to 200 LOC), the number of errors per LOC decreased (1984).

* Another study found that routine size was not correlated with errors, even though structural complexity and amount of data were correlated with errors (Shen et al. 1985)

* A 1986 study found that small routines (32 LOC or fewer) were not correlated with lower cost or fault rate (Card, Church, and Agresti 1986; Card and Glass 1990). The evidence suggested that larger routines (65 LOC or more) were cheaper to develop per LOC.

* An empirical study of 450 routines found that small routines (those with fewer than 143 source statements, including comments) had 23% more errors per LOC than larger routines (Selby and Basili 1991).

* A study of upper-level computer-science students found that students' comprehension of a program that was super-modularized into routines about 10 lines long was no better than their comprehension of a program that had no routines at all (Conte, Dunsmore, and Shen 1986). When the program was broken into routines of moderate length (about 25 lines), however, students scored 65% better on a test of comprehension.

* A recent [sic!] study found that code needed to be changed least when routines averaged 100 to 150 LOC (Lind and Vairavan 1989).

* In a study of the code for IBM's OS/360 operating system and other systems, the most error-prone routines were those that were larger than 500 LOC. Beyond 500 lines, the error rate tended to be proportional to the size of the routine (Jones 1986a).

* An empirical study of a 148 KLOC program found that routines with fewer than 143 source statements were 2.4 times less expensive to fix than larger routines (Selby and Basili 1991).

Get off your high horse. An installation of the JRE on Windows will install the Java VM, plugins for several browsers, a Java update scheduler, the Java Web start framework, a control panel and a bunch of other related utilities. In other words, a software suite.

First off, I would love to make this comment longer but I'm pressed for time. If you would like to, send me an email. My HN name @gmail.com.

I was born & raised on a boat so it is hard for completely put myself in your shoes (notably, I do not get sea sick, no matter what), but I personally think it is do-able. I have not done it yet, but I've sailed quite a bit and someday I want to start crossing oceans. Financially it isn't as bad as most people think. I actually think that the oppurtunity cost of quitting your job for a year or two is the biggest expense.

First off, you need to know how to sail at its most basic level. The cheapest way to learn is to get a dinghy (a Laser, maybe a Hobie 16 or Hobie 17 are all easy to find. Something decently high performance - you want to wipe out sometimes so that you learn.) You need a lot of time on the water and there is absolutely no substitute. You need to learn how to drive by the feel of the wind on your neck, and you need to learn which clouds are safe and which ones are going to wreck you.

Then you should step up to 30-40 foot keelboats. You probably don't want to buy one straight away. Learn on someone else's boat as crew for racing or deliveries. (a delivery is generally moving a couple hundred miles for the owner, i.e. the owner needs the boat moved from NYC to Maryland, but can't do it himself. He hires you to move it and pays all expenses. I've done this several times and it always seems to lead to the hairest situations because you are forced by the schedule to sail even if the weather doesn't cooperate. Generally you will be shorthanded 2-3 people which is good practice for offshore work)

So at this point you probably have been sailing for 3-5 years or so, know how to do everything on someone elses boat, and you need to buy your own boat. There is a lot of discussion on a fast boat vs a slow boat. A fast boat means you spend less time out there which is good mentally, but they are more physically demanding (bigger sails, crash through waves harder, get wetter, etc), but you can also avoid weather if you know a storm is coming. Faster boats break more often. A slow plodding boat can survive everything, but you can't avoid anything. Slow boats are cheaper.

You also need to figure out your route. Sailing non-stop around the world is one thing, but honestly that is kind of boring. I know 3 couples who have done it, and they made a point of stopping a lot along the way so it took about 3 years each. (1 couple stopped in New Zealand and taught school for a year, 1 couple was in Indonesia during the tsunamai on their boat in the harbor, and in the aftermath stayed for a year because they were doctors). The stops sound like more of the journey than the sailing honestly.

If I were to think of places to start, I'd subscribe to some sailing magazines. Cruising World comes to mind, there is also Sail, and Sailing. For websites, try Sailing Anarchy (rough crowd in the forums for sure, but there are some gems). You will definitely find them ridiculing people for what not to do on Sailing Anarchy.

Disclaimer: sailing is very dangerous. Way more dangerous than most people realize. I personally know 5 people that have been killed sailing in the last 4 years. It can happen in a lot of different ways. And I personally have been involved in some really close calls. Sinking boats, out of control boats, overturned boats. The fastest boat in the world (Rambler 100) just flipped and almost killed its crew off of Ireland. In the 70s the Fastnet race killed 50 people. The Volvo Ocean Race had a professional get killed in its last go-round. The ocean is no less forgiving now than it was in the 1700s. The Coast Guard can only reach so far, and when you are in the middle of the ocean you are absolutely alone.

As just one example, a few weeks ago we went out racing on a wednesday night (3 man high performance boat). It was a clear, calm night. Thunderstorms were rolling in, we saw them, we thought we could keep the sails up about 2 minutes longer than we should have. We knocked the boat over on it's side, the guy driving fell below and cut open his shin and was bleeding everywhere trying to get back up, the boat had no driver, and the 2nd guy on the boat froze like a deer in the headlights. Our sails were dragging us down and the wind was up like crazy and the rain rolled in to the point where we no longer could see our competitors who were 75 feet away. I crawled up to the bow and cut down one of the sails and hand over handed the thing into the boat, and when we finally got it all sorted out and the rain cut back, we were still sailing at full speed and realized we were in the middle of a reef. We got out of the reef without sinking the boat and decided to just quit the race and go home. I think my adrenalin was still going 4 hours afterwards.

I flipped my race boat a couple years ago while teaching my girlfriend to sail and the keel broke. The boat started sinking, and she started getting hypothermia. Another guy who was out that day coaching jumped in the water in full clothes to help me get it back upright and took her in by powerboat while I sailed the sinking boat back to the crane to get it pulled out.

The point is, unlike other sports when shit hit the fan, there is no time out. You don't blow the whistle and talk about it. If there are rocks coming up and your boat is out of control - you are going to hit the rocks and sink. If the boat flips - you better hold your breath and start swimming and hope it comes back upright. If something snaps and the rig falls down, better start cutting before it punches a hole in the boat and sinks you. When things start going wrong you can feel really exposed out there, with little to no safety net, so you better be prepared.

Anyone can do it but you have to do your homework. You have to put in the practice and preparation.

edit: My god, I posted that before reading the article itself, I can't believe how close his story is to my experience. Aside from the 90 foot wave comment (90 foot waves simply are not common, hurricane irene was throwing legit 30-40 footers around but it's hard to believe much more than that), he is spot on. I've never put a word on it, but initiative is exactly right. That day I went out and I mentioned the 2nd crew had the deer in the headlights look, he had 10x the experience of me, owned a boat bigger than mine, but in that moment he was completely stuck and useless until we started yelling at him what to do. This is an amazing account of what it is actually like. Really not that much hyperbole (which believe me, sailors are prone to, but it really is like this).

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, however, in addition to systems knowledge, is extremely important to creating good software in general. If you can't determine how your software will scale with big data, and you can't understand why efficient code that runs quickly with small operations does so, you simply can't write good software.

I realize a lot of people on HN take offense at these claims because they've written programs without this knowledge and claim they are self taught. The reality, however, is that they aren't good programmers. You don't need a good programmer to write a prototype that works and determines market fit. You do need good programmers to scale your product, add features efficiently, and architect solutions without making a crippling mess of your code.

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