Hi, I am Sébastien.
I help people build great software together.

How Meetic Hires Software Engineers (part 2) : The Hiring Process

In part 1 of this series about hiring, I described the key principles that drive our hiring process, as well as the competencies we evaluate and challenge. In a nutshell, our principles are:

• We hunt for and hire T-shaped engineers
• Our hiring process is short
• We avoid biases
• We prioritize system and software design over coding
• We prioritize collaboration and self-organization over charisma and storytelling skills
• We prioritize hiring engineers with the right mindset for the team: either tech-minded or product-minded people
• We hire to minimize turnover
• Whenever there is any doubt, there is no doubt

In this part, we'll take a deep dive into the hiring process. The goal is to give a concrete example of how we apply those principles. There are likely many ways to design an interview process that fits both our values and the needs of the company or organization. However, starting from something is often a good approach. The aim of this post is to inspire other tech leaders who may need to structure their approach to hiring and to help future Meetic applicants prepare for the interviews.

Overall, our hiring process consists of three interviews:

• The first screening call
• A technical and collaboration skills interview
• A delivery management interview

Each step helps us gain a better understanding of how the applicant thinks, their previous experience, and their potential for growth at Meetic.

How Meetic Hires Software Engineers (part 1) : The Design Principles

In my previous post about Meetic's engineering organization, I explained how our matrix organizational structure relies on both the hard and soft skills of our software engineers. We need both to maintain high-quality standards in our tech systems and keep pace with product innovations. This requires engineers to be proficient in writing software and collaborating with product teams.

However, it is one thing to write about the importance of working with skilled professionals, and another to actually find and hire them. Google, Apple, and Facebook all claim to hire the best, and Valve was already doing so in 1996. Similarly, Reed Hastings begins his book about Netflix culture by stating that the content only applies when working with the best.

But what if you're not a Big Tech company? What if you cannot afford to pay everyone in the 90th percentile of San Francisco market rates, regardless of their role or location? In the last decade, there has been inflation in engineers’ salaries in France and elsewhere, making it difficult to attract the best talent even if things stabilize.

Although Meetic does not face the same engineering challenges as Google, Netflix, or Apple, we are still a social network with millions of active users in Europe. Running and improving the platform requires a certain level of skill. In addition, our organization values the soft skills of our engineers.

In the past few years, I have spent time working on the topic of hiring, first as a backend tech lead, then as an engineering manager, and now as an engineering director. Despite not being Google and not likely to hire the best among the best, I've wondered about what constitutes a good hiring process. How can hard skills be evaluated consistently with the job to be done? How can engineers be attracted and evaluated in the same hiring process?

How Meetic works: an organization designed to ship fast and maintain quality

Meetic, like most tech-first companies, needs to keep its code base clean and scalable. It is our biggest asset, and we need to take care of it. Most companies are either good at shipping fast or maintaining high code quality. Doing both is hard and we've been working on this topic for a while.

While there is still room for improvement, I considered we have found the right balance between long-term tech projects and product development. I'd like to share the receipt. Of course, there is no one-size-fits-all when it comes to organizations, roles, and processes. However, the organization I describe below and the design principles on which it relies are pretty common. Especially for companies that work with both web apps and native apps.

In this post, I'll deep dive into 3 key factors that have helped us achieve great product development success and high-quality standards :

• The way we run our teams and our tech communities
• The hard skills we expect from the Engineering Managers and the role the Tech Leads play in the tech communities
• The hard and soft skills we expect from the Software Engineers

A simple reverse proxy in Go using Gin

Reverse proxies are great to handle logging, tracing, and authentication on applications you don't own or which you cannot modify the source code to make them do what you need.

A reverse proxy is nothing more than an HTTP server that handles a request and makes the request to a backend server. When doing so, it may add some headers, log data about the request or stop the request if authentication fails.

Go provide a reverse proxy feature in its standard library. It's a great start, but you will probably find out it lacks some helper features such as logging or handling routing easily.

On the other hand, Gin is a very popular and great web-based application framework. It helps to build powerful REST API quickly, it has a lot of useful features and it's very fast since it uses httprouter under the hood. The idea is to handle HTTP requests with Gin and then proxy the request to the backend using the built-in reverse proxy.

The ReverseProxy struct contains a Director field. A director a function where you tell the reverse proxy what to do with the incoming request. It is where you may change the host, maybe add some headers, or even check the authentication.

remote, err := url.Parse("http://myremotedomain.com")
if err != nil {
	panic(err)
}

proxy := httputil.NewSingleHostReverseProxy(remote)
proxy.Director = func(req *http.Request) {
	req.Host = remote.Host
	req.URL.Scheme = remote.Scheme
	req.URL.Host = remote.Host
}

Parsing git status with Go

At work I often have to switch from a repo to another, making some changes here and not there, starting a new branch on repo A and then, fixing an issue on repo B. Ideally, a big fat monorepo should help me to deal with the ~40 apps and libs I work on. But monorepos have drawbacks when you're not Facebook or Google. By the time, they become heavier and soon a simple git status takes more than 2 seconds.

Instead of a monorepo I have built a few script helping me to deal with all those repos. One of them helps me knowing the status of each repository, just to know where I am and what I was doing before being interrupted.

So here we are… building a Go script to parse a git repository status.