Spotify Labs

NYC Spotify employee here. Spotify has a very honest, open, and autonomous culture. Spotify is comprised of many Missions which are defined by a business purpose like ads, user engagement, or analytics. Within a Mission you will have one or more Tribes. Each Tribe is loosely associated with the Mission goal and addresses a portion of the overall Mission. A Squad is a delivery team/product team. Squads are accountable for building great products. They are given autonomy to make the right decisions for the direction of their product. Squads function as "mini-startups", if you will. A grouping of many Squads is called a Tribe. A Mission will have one or more Tribes. It's a tad confusing and I'm sure I've gotten some of definitions wrong, but you get the general gist.

As for the people culture, Spotify values the growth of employees. We focus heavily on personal growth over product delivery. We believe if we build good people they will build good products. I was doubtful before joining Spotify that they would fulfill everything I was told (about the culture) during the interview process but everything has held true.

For better descriptions of Spotify check out the engineering culture video:
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

I would encourage you to apply. Spotify is a great place to work.

Reminds me of a issue Spotify had too with unicodes and usernames.

https://labs.spotify.com/2013/06/18/creative-usernames/

I had someone tell me that programming isn't real work before, and this is yet another example of all the small little details going into building things that most people don't really think about day to day.

I haven't had to work with login code in a while, but might at some point. I know some systems only allow alphanumeric usernames, but sounds like can't force people to have alphanumeric emails... Well I guess you could but might upset someone. I know there's normalizing functions though like NFD, NFC, NFKD or NFKC that might work for usernames but not sure what's really recommended.

Then also brute forcing attempts to try to mitigate attacks and other considerations to make also when building out an account system. Then if your company is large enough to provide phone support, not sure how you'd tell the support person which specific emoji you used in your username.

Agile principles generalize to all software development. The specific application of those principles at one company won’t.

That’s the core difference people miss.

Of course then there is the difference between “software development” and “one individual programmer”. Not all programmers will gel with Agile stuff as well as the next one. That’s why it’s not supposed to be rigid (it often is when done poorly).

But yes, an understanding of the principles is required to translate them into practices for a team. Rigid adherence to Scrum or XP is missing the point.

For a good look at a way one company took the principles of Agile and applied them in a very effective but utterly idiosyncratic way... look at Spotify.

Pt 1: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Pt 2: https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

I work at Spotify on ML. I spent quite sometime working on our production vector model pipelines.

We have three components:

1. Training data: Scalding pipelines (could be any large scale production framework) to preprocess training data and reduce it to a few hundred gigs.

2. Run latent vector models (Matrix factorization, Embedding models etc) to generate item vectors. This stage is designed to be non specific to framework. We use typed avro objects to communicate with the previous stage.

3. Production deployment of models. Essentially glue code that ensures that models are versioned, atomic (user, music vectors are all from the same batch) and deployed into music recommendation and realtime frameworks.

Read here[1] more.

[1] https://labs.spotify.com/2016/08/07/commodity-music-ml-services/

There are a bunch of great references for career ladders, broadly speaking, that discuss the rollout process and what each level means for that company. The best not only say something about the levels, but about how the levels are interpreted in line with that company's culture, whatever it means. It's very hard to get to levels beyond senior as a pure generalist: you're typically going to have to have worked on projects with significant, company-wide impact, and that usually means (a) doing something unique within a domain and (b) working with many others, in different types of roles, in your company, in order to have that impact.

Two good intro readings on career ladders:

https://labs.spotify.com/2016/02/08/technical-career-path/
http://dresscode.renttherunway.com/blog/ladder

Shipping python projects isn't easy. Even if you have a prefect package on pypi, that specifies its dependencies, it may conflict with other tools using other versions of those libraries.

Compiling python does not feel right.

Using native packages is better[1], but you have to plan it out. You can package virtualenvs into native packages[2] - and this is probably the most solid way, but you'll need packaging setups for various package managers.

In short, "written in Go" for me means with a high probability, just run "go get x" - or download a binary.

Since we are at it, I'd love to hear about better shipping strategies for Python projects.

[1] https://hynek.me/talks/python-deployments/
[2] https://labs.spotify.com/2013/10/10/packaging-in-your-packaging-dh-virtualenv/