Pinterest Engineering

San Francisco - Pinterest

Pinterest is a visual discovery tool for collecting and organizing things you love and enjoy. Millions of people use Pinterest daily in their lives and work. No matter what you're interested in, there's a place for it here.

As a Software Engineer on the Growth Team at Pinterest, you’ll have a huge impact on how we design, build and deliver our service to millions of people. You should be a generalist who enjoys working across the software stack with a strong focus on data and a keen eye for product. Prototyping, running A/B tests, pushing code into production, weighing in on the best ways to grow Pinterest and engage Pinners...if that all sounds good to you, then this might just be the place for you.

Responsibilities:

-Find ways to get new users on the site and engaged with the product. This includes SEO, signup optimizations, new-user experiences and any product change you think needs to happen. For more about how we work, read all about how we recently rebuilt our new user experience and created our SEO sitemaps on our engineering blog: http://engineering.pinterest.com/
-Be heavily involved in every step of the product development process, from ideation to implementation to release.
-Build new features that increase social sharing both within Pinterest and externally with friends (SMS, Facebook, Twitter).
-Improve the messaging platform so that we can send our Pinners engaging and timely notifications and emails.
-Run experiments on new and…

These are some of the top sites' engineering blogs which I collected over a period of time - I removed those which have already been posted:

Google: http://googledevelopers.blogspot.com/ http://google-engtools.blogspot.com/ http://googleresearch.blogspot.com/

YouTube: http://youtube-eng.blogspot.com/

Baidu: http://usa.baidu.com/category/baidutechblog/

Yahoo: http://yahooeng.tumblr.com/ http://yahoodevelopers.tumblr.com/

Wikipedia (closest I could find): https://blog.wikimedia.org/c/technology/

Amazon: https://aws.amazon.com/blogs/aws/

Twitter: https://engineering.twitter.com/

eBay: http://www.ebaytechblog.com/

Microsoft: http://microsoftengineering.com

FourSquare: http://engineering.foursquare.com/

Apple (closest): https://developer.apple.com/

Paypal: https://www.paypal-engineering.com/ https://devblog.paypal.com/

Dropbox: https://blogs.dropbox.com/tech/

Edit: More (collected from this link: http://www.quora.com/What-are-the-top-startup-engineering-blogs):

Yelp: http://engineeringblog.yelp.com/

Quora: http://engineering.quora.com/

Yammer: http://eng.yammer.com/blog/

AirBnB: http://nerds.airbnb.com/

Square: https://corner.squareup.com/

Flickr: http://code.flickr.net/

Soundcloud: https://developers.soundcloud.com/blog/

Cloudera: http://blog.cloudera.com/blog/

Slideshare: http://engineering.slideshare.net/

Heroku: http://engineering.heroku.com/

Pinterest: http://engineering.pinterest.com/

Inspired by the Pinterest paper at KDD on implementing Visual Search, I have created this barebones but functional implementation of a Visual Search server using ~450,000 Female Fashion images crawled from an image aggregation website. The code uses Pool 3 layer features extracted from the Google's latest Inception model using Tensor Flow. The extracted vectors are then indexed using an Approximate Nearest Neighbor implementation from Nearpy. The AMI provided contains both images and pre-computed vectors.

In future I plan to add more images ~2 Million in the same domain. Test various combination of nearest neighbor indexes and multiple vectors per images using some form of a multibox style detector. I will also add a script to launch spot GPU instances via Cloudformation to economically index images using S3 and SQS. I am building a companion iOS swift app however, since Tensor Flow hasn't been ported to iOS yet, its still in development.

https://engineering.pinterest.com/blog/building-scalable-machine-vision-pipeline

Although the original blog post focuses on JavaScript and browsers, MessagePack itself doesn't mainly focus on them.

A major use case of MessagePack is to store serialized objects in memcached. A blog post written by Pinterest describes this use case (http://engineering.pinterest.com/posts/2012/memcache-games/).
They use MessagePack with Python which is faster than one with JavaScript. They could store more objects in a server without performance declination (e.g. gzip).

It's true that MessagePack is not always faster than JSON (e.g. within browsers), and it's not always smaller than other serialization methods (e.g. with gzip compression). So we should consider that which serialization methods should I use for "my" case.

There are also general tendency which is helpful to select MessagePack or JSON:

MessagePack is faster to serialize binary data such as thumbnail images.
MessagePack is better to reduce overheads to exchange small objects between servers.
JSON is better to use it with browsers.

Using Elixir here for a couple of months, for an app backend, and even for shell script type of projects. Great language, no surprises, and very responsive community -- really, my biggest wish is for more people to try it, as I think it's still relatively niche. Had no previous Erlang experience. While you don't have to write Erlang code itself, you'll over time become familiar with Erlang/OTP architecture concepts, such as GenServer, ETS, distributed nodes, and so on.

Was very happy to see this recent post from Pinterest [1] as a sign that some of the more "mainstream" teams are starting to look at it.

Also, a repost [2] of some helpful tips if you're just getting started.

[1] https://engineering.pinterest.com/blog/introducing-new-open-source-tools-elixir-community

[2] https://news.ycombinator.com/item?id=10278870

two things:

1) elixir is relatively young so there aren't many projects that have had a chance to grow to be huge. so yea, take everything you read about it with that grain of salt. people haven't grown to hate it yet...maybe everyone will always love it, but I wouldn't bet on it.

2) when used in certain contexts, elixir applications may end up being quite a bit smaller than comparable java/scala/python/whatever apps. A lot of what we end up writing with microservices is just basic RPC and fault tolerance boilerplate stuff, which OTP takes care of out of the box. Example, pinterest re-writing a 10kloc java app in 1kloc of elixir, running it on fewer servers: https://engineering.pinterest.com/blog/introducing-new-open-source-tools-elixir-community