15 minutes you won't regret!

Too much hassle to muck with backports and package pinning for a QoL tool - my feedback would be to try to make this install without tomfoolery on the stable branch of major distros.

Once upon a time I worked for what was (once) the world's largest BBS. Remember the US Robotics Courier HST? 16.8kbps! Now imagine a room filled with shelf after shelf of Couriers, several hundred individual lines, at least a few hundred amps worth - all negotiating vigorously, clicking on-hook and off, all the time. Fun times.

Pretty sure I could still tell the difference between a 14.4k and 16.8k negotiation by ear.

It took Instagram Stories two quarters to catch up to Snapchat's total MAU.

1. GAAP says that revenue from a software service subscription (e.g. cloud service) can only be counted as revenue once the service has been delivered, not at time of sale.

http://www.marketwatch.com/story/ea-to-ease-non-gaap-usage-a...

http://www.grayboxpdx.com/blog/post/revenue-recognition-for-...

2. Equity-based compensation is accounted for as a cost.

http://mercercapital.com/financialreportingblog/equity-based...

We've got our warts and a pile of tech debt, and I wouldn't want anyone to think otherwise. Containers are a part of a long-term strategy to get away from puppet and onto more idempotent units of deployment, and move a lot of what is considered to be "configuration" back into the build process where it belongs.

I think this Quora post does a good job of redshift vs. bigquery: https://www.quora.com/How-good-is-Googles-BigQuery-as-compar...

More generally speaking, (excuse me for being a little hand-wavey here) many of the AWS offerings feel like polished, managed versions of familiar tools. Redshift, for example, feels a bit like "hey we figured out how to abstract away a bunch of mysql instances to feel like a big processing cluster". That's not a bad thing, necessarily. The google stuff feels much more intentional - "we need to solve the problem of doing these sorts of queries at scale" vs. "we need to solve the problem of scaling mysql to solve these types of queries"

Maybe they're just better at abstraction, but whatever - that works for me!

The way we think about this is that there are basically two classes of cloud services: commodities and differentiated services. Commodities are storage/network/compute, and the big players are going to compete on price and quality on these for the foreseeable future (as with most commodities).

The differentiated services stuff is a bit more interesting. Different players have different strengths and weaknesses here - AWS has way, way better capabilities when it comes to administration and access control and identity management, for example (which is actually pretty important when trying to do this in a large org). The places were Google is strong (data platform) are the places that are most important for us as a business.

Compelling: dataproc+gcs, bigquery, pubsub, dataflow Made it safe: high-enough quality, cheap enough.

What more would you like to know?

Getting shared-storage and indepedently operated/scaled compute clusters on top of that storage isn't easily achievable with the standard Hadoop stack, and building that on top of HDFS is non-trivial.

We've been very pleasantly surprised. The cloud team has been pretty awesome to work with, including lots of engineer<->engineer contact, walk-throughs of systems and code for critical dependencies, and solid support and collaboration. Exceeded our expectations.

  To fix this problem, we introduced the simple rule that new 
  stable releases of the software must (a) talk to old stable 
  releases and (b) they must support existing apps, without 
  changes. We more or less succeeded with that, so ZeroMQ 
  versions 3.2 and 4.0 work nicely with 2.2 and 2.1, for  
  example.

There are obviously patterns for doing this in monoliths (or, say, mobile clients - another type of monolith), but at some point you are bound by the dependencies inherent in a single runtime.

- Backend Engineers: Improve our ad systems and enable better, more relevant targeting. Build and scale our backends.

- Frontend Web Developers: Mine, aggregate and visualize complex data. Engage users and optimize front-end experiences. Build advertising platforms and tools.

- Web Developer Team Lead: Build and lead a team of web engineers to create the next generation of Spotify experiences

- Machine Learning: Improve our music recommendations, mine those datasets!

- Mobile (iOS and Android): I heard something about 1B smartphones by 2015.

- Mobile Team Lead

- Backend Infrastructure: Build the stuff that the guys building the stuff are building it with; Storage, high-performance messaging, service registration and discovery.

- Lots of things not-mentioned (http://www.spotify.com/se/jobs/)

On the backend, we have an (extremely) service-oriented architecture written primarily in Python and Java with smatterings of C++ and others thrown in. Storage is Postgres or Cassandra. Messaging is zmq and protobuf and a few other interesting things.

On the frontend, we do hybrid native+CEF for most platforms.

Our website gets a lot of oohs and aahs for being a particularly good example of parallax scrolling.

We're looking for experienced developers, no junior roles, sorry. Apply on the website, but mention HN and get bumped to the top of the resume pile!

- SRE

- Backend Infrastructure

- Machine Learning

- Mobile iOS and Android

- Team lead positions for most of the above

- Lots of things not-mentioned (http://www.spotify.com/se/jobs/)

On the backend, we have an (extremely) service-oriented architecture written primarily in python and java with smatterings of C++ and others thrown in. Storage is Postgres or Cassandra. Messaging is zmq and protobuf and a few other interesting things.

On the frontend, we do hybrid native+CEF for most platforms.

We have (I think, anyway) a pretty interesting approach to how we work, which you can read some more about here: http://de.scribd.com/doc/113617905/Scaling-Agile-Spotify and here: https://hep.cat/d/nrh-how-we-work.pdf

We're looking for experienced developers, no junior roles, sorry.

Apply on the website, but mention HN and get bumped to the top of the resume pile!

Backend: SRE, Software Engineer (Infrastructure), Software Engineer (Backend)

Primarily Python & Java, also C/C++, deployed on Debian with Puppet. Looking for dev and ops (and devops?) with experience working at scale.

http://spotify.com/jobs/