• Phone screening.
• Team overview meeting.
• Lunch.
• Technical Interview.

Someone once told me if you want to understand a company's DNA, look at its products.

Consider Tinder's HQ. I grew up in Southern California, so I know what this part of Sunset Boulevard is like. I imagine setting up an HQ here was the idea of a C-level person who was renting a house in the hills above the boulevard and bragged about celebrity neighbors. During my time outside the interview room, nearly everyone I chatted with used to live in reasonable locations but had since moved into apartment buildings on Sunset Boulevard. They were all young people, not raising families. Of course, this was before the pandemic. Remote work may be more of an option now, but choices like an HQ location reflect a company's DNA.

The technical part of the interview was an experience. The interviewer, who was also the manager of the team I was interviewing for, jumped right into a question without preamble. The question was about an on-call alert and how I would handle it. It was a very general question focused on HTTP status codes.

I have a lot of on-call experience. I know a company can leave on-call responsibilities indeterminate if allowed to. This is why, when you deploy an app or service, you ensure the process for troubleshooting it is documented. Create alerts for critical components, indeed, but you control what's deployed and how, so you can control how to handle errors and how to describe alerts, making the problem clearer for the person on-call who you woke up. Projects should have runbooks; alerts and errors should be handled in specific internal ways that provide information to people on-call.

I went into these details with the interviewer, but he had tunnel vision for his question and continued to focus on HTTP status codes. In the end, I refused to answer his questions because he did not answer mine. Why was I being woken up by this general error when we control the pipes? By the way, knowing a specific HTTP status code (and there are many of them) does not mean you're experienced. It means a service has failed so many times that that general error has dug into your memory.

There was another person in the room with him, an intern. This intern then asked a coding question straight from a classroom: reinvent something to do with strings, like reversal or splicing, etc. Nothing is wrong with that or the intern. This is more reflective of a manager who likes to bring interns to interviews or, if not interns, then someone believed to be more in touch with these academic coding questions.

There were other parts of the interview that were just fine. Those two points, I think, paint a clear picture of the type of employee who would thrive there. If you are young and just out of school, try this place; you might enjoy it. If you're older, raising a family, and value your personal time, consider the company's product because it will tell you who they are.