HN user

matslina

172 karma
Posts6
Comments12
View on HN

Glibc falls back to quicksort from merge sort (its default algorithm) when there's to little free memory available to accommodate merge sort's O(n) requirement. Quicksort only uses O(log n) additional memory, making it a good option in that sense. O(1) would of course be better, but even for huge inputs that logarithm makes the memory consumption a non-issue in most cases. Heapsort does give you O(1) memory, but also comes with poorer cache locality and overall performance than quicksort, making it a not so compelling option.

Mergesort would be a poor choice for qsort() due to the linear space complexity. With N bytes of RAM, you'd only be able to sort (a bit less than) N/2 bytes of data. An in-place algorithm is preferable.

Glibc is the only libc I'm aware of that implements mergesort. It still falls back to quicksort for large inputs though.

Spotify's Service Infrastructure (SI) team in New York City is hiring.

We, the SI engineers, are on a mission to act as force multipliers for all Spotify engineers. We build and maintain software components that allow our feature teams to move fast without breaking things. Some examples of what SI engineers are currently working on:

- Core authentication systems for Spotify

- High-performance inter-system messaging software

- Core storage technologies (Cassandra, PostgreSQL)

- Service discovery and orchestration

The NYC-based SI team is just booting up and we're still quite small. New team members can expect to have a significant impact on our projects. Our mission is to revamp how Spotify deploys backend services and while we're currently looking at LXC, nothing is set in stone. As the team grows we'll start to branch off into other areas of the Spotify infrastructure universe. Lots of fun will be had.

If we are the right team for you, and vice versa, then you're probably a bit like us. Here are some of the traits that we share:

- a passion for programming and computing in a large scale distributed environment with millions of users

- significant familiarity with GNU/Linux or other UNIX-like systems

- knowledge of a couple of programming languages, typically including Python or Java

- an urge to KISS, to iterate, to deliver and to produce high quality software in the process

Does this sound like a place for you? If so, please reach out to us. We'd love to get to know you. Send us your CV (if you have one), a link to your hobby project or github and perhaps a short message to further explain who you are. Mention HN and we'll pay extra attention to your application.

https://www.spotify.com/se/jobs/view/omlBWfwY/

Spotify, New York, USA.

Software Engineer - Backend Infrastructure

Our engineering team is responsible for the infrastructure underlying Spotify's music experience. We work on large scale distributed systems, from handling a billion playlists to streaming music to millions of users with subsecond latency in a fault-tolerant manner.

As an infrastructure engineer at Spotify, you will help us build, scale and maintain these systems, all of which have a direct impact on the lives of our users and the success of our business.

We are looking for candidates who share a passion for tackling complexity and building platforms that can scale through multiple orders of magnitude.

http://www.spotify.com/en/jobs/view/omlBWfwY/