Building Tinder

The Tinder experience is rooted in simplicity. It takes the complex, anxious and sometimes awkward act of introducing yourself to another person to a playful, almost minimalist level—the iconic swiping through a stack of profile cards, an intuitive interface design, the thrill of getting a new match.

But as every engineer knows, true simplicity is an iceberg. Tinder is no different; beneath the surface of that simple, playful UI is a platform of tremendous complexity and serious technological challenges. Behind every swipe is a system that manages millions of requests a minute, billions of events a day, terabytes of data, and all the scaling challenges of an immense, growing and global user base.

Simplicity is serious business.

At Tinder engineering (a.k.a. Tindev), we are solving serious engineering problems that go way beyond the swipe. Our “matching” algorithm is real time and location-based. You could think of Tinder as one large search engine—but there’s a twist. Other large, global search engines are unilateral: their algorithms are one-sided; there’s no need to worry if the blue links will like you back. :) Tinder's algorithm is bilateral: it’s only a match if I like you and you like me back. We optimize for rewarding everyone.

The engineers at Tinder are here to move fast: supporting and sustaining a rapid product iteration cycle. The product is in a constant state of evolution, compelling the team to solve complex problems in the simplest and most scalable way.

How do we solve these complex problems?

By applying constraints.

Naturally, a development team prefers to have fewer constraints—in the development process as well as in the tools they use to build—if given the choice, any engineer would choose more freedom to create. That makes perfect sense. But as the team, systems and user base grow, it becomes much more beneficial to apply certain constraints to sustain growth and agility.

We believe the right constraints can deliver a positive impact on product development:

Code quality and design pattern: Keeping the codebase clean from the get-go will benefit the development process as the product scales. We champion a strong CLEAN architecture at Tinder. We will share our CLEAN architecture practice in detail in our next set of blogs. Stay Tuned.

A consistent development and release process: At Tinder, it’s a two-week scrum. Every release starts with a storyboard, a list of work items, bugs and test cases. At the end of the release, we run through regression and integration testing, we log and triage new issues, and it’s off to our users. We then monitor the last release as the new cycle begins. It sounds like a lot of work, because it is. Every release has different goals and challenges. With multiple teams developing their features in parallel, we stay on schedule by applying a consistent branching strategy and release process.

Disciplined UI\UX design changes: We believe every pixel is meaningful and functional. With the goal of building an intuitive and satisfying experience in every frame of the app, the team knows that when they add new features they must do so without cluttering the UI and maintain a minimalist design style.

By moving fast.

In the software industry, whoever moves fastest, while maintaining quality, will have a huge advantage over the competition. I believe moving at an accelerated pace doesn’t mean sacrificing the quality of our code. On the contrary, the constraints we adhere to can strengthen the entire system. We’ve seen this. Tinder used to release a new product on an six- to eight-week cadence, at a rate of six iterations per year. Starting April of this year, we moved to a two-week cadence, at a rate of 26 iterations per year. By accelerating the release cadence, we decreased the size of incremental changes; even very large features were chunked into smaller phases. As a result, every release is less likely to have massive issues.

We strive to always have a shippable main branch. By being in “release mode” at all times, our code is consistently being tested and verified, which allows us to identify issues and turn around fixes quickly.
We are moving faster than ever before—whether it’s a major launch like Tinder Social and Tinder Anthems, or a product enhancement like improved matching—we are releasing in rapid iteration and incrementally improving product quality with every release.

By hiring only the best.

Tinder hires engineers with rock solid development skills—people who are serious about computer science, ambitious, and looking to take on new challenges. We give them the best environment to learn and grow as a team. If there is one thing all of our engineers have in common, it’s that they’re almost impatient: the tougher the problem, the more excited they are to tackle it. We invest heavily in their training and development: every new member participates in Tindev bootcamp, a rotation program through different platform teams, and individual mentorships.

I’ve been at Tinder for six months now; I can say that as an engineer, solving these complex problems has been profoundly satisfying. Building simplicity is difficult. Building a team that can build for simplicity is even harder. What began as a small team of developers in Los Angeles is quickly becoming one of the most prolific, skilled and innovative engineering teams in the world. I joined Tinder with the conviction of building a world-class software engineering team to deliver a transformative product in a global market—and we’re well on our way.

Big things are happening here. Fast. If you’re a serious engineer who loves a fun office culture, come join us.

Apply today.