Hiring a new person is always a challenge and generates uncertainty. Moreover, in technical teams, there is an added difficulty due to the particularities of the market: there is a lot of demand for these types of profiles.

Although we have already given some insight into how we approach the selection of technical profiles at Devengo, in this article, we are going to go into depth and explain the details of our technical hiring process. We will approach the process from two points of view: from the company’s point of view and from one of the people who went through the process and ended up being part of the team (myself!).

Technical Hiring: The Offer

(Devengo POV)

Conducting a technical hiring process for a backend developer in 2024 is difficult. Launching a job offer in the most common/popular channels will create a paradoxical situation where one gets literally hundreds/thousands of CVs, AND almost all of them are not even close to suitable candidates.Very low signal-to-noise ratio.

Because of that, we have chosen Manfred as our partner for most of the technical hiring processes we have initiated since we started Devengo. They provide a curated pool of talent and take care of the initial pre-screening, introducing only the profiles that have a chance of being a good match with Devengo.

Dealing with this process internally will not only require a lot of time to sieve through all the potential candidates but will almost certainly miss many interesting profiles of adjacent technologies that our media efforts can’t reach. Externalising that work lets us focus on the important part: creating a great offer.

So, how do we create a great offer? We think that every team effort should always start with the same critical piece: the mission.

We then apply the same principles we use in our work. We apply finesse to craft an explanation about why our mission is meaningful and important, including the rationale, context, the data and the sources that provide the base for our take on the problem. We try to explain why and how we apply a pragmatic approach to solve it. We describe the practices and culture we have built to make it a reality. In short, we try to provide the candidate multiple reasons to at least get interested in us and request a first interview.

(Raúl’s POV)

After more than a year of consulting and technical training, I was looking for a new job, and it was clear to me that what I really liked was developing products.

Devengo was not a totally unknown company for me because, despite being small and young, it is quite present in the Spanish startup ecosystem and in the country’s technical environment.

The first thing that struck me about Devengo’s offer was how well-written and detailed it was. It gave a feeling of seriousness and of having everything clear, without improvisations. I had no doubts about what my role would be and what was waiting for me on the team. So don’t underestimate the first impact that the text of the offer itself can have. Do not skimp on this because it can be the difference between a candidate (and possible future member) paying attention to you or discarding you.

Apart from this, the characteristics of what Devengo offered fit perfectly with what I was looking for:

  • Small, early-stage, product-based company.
  • 100% remote. They don’t even have an office!
  • International Spirit
  • A good financial compensation, plus phantom shares.

First contact interview

(Devengo’s POV)

If both parties match, the first interview we have is an informal three-way meeting (more like a chat) for about 30 minutes between Alberto (co-founder and COO), Aitor (CTO), and the candidate. The objective of this talk is to confirm that the interest on both sides is real and that it makes sense to go ahead with the process.

It helps to clarify any misunderstandings the offer may have generated in the candidate, and in rare occasions we may determine that the candidate will not be a good cultural fit for the team. In any case this first meeting provides both parties a go/no go moment before they have invested too much time.

(Raúl’s POV)

The truth is that for this first talk, I had very few questions since, as I said before, the offer was so well-written and detailed that it gave little room for doubt. The only question on my part was to understand the details of the phantom shares since I had never had this type of compensation.

Apart from that, it helped me to meet Alberto and Aitor and confirm that Devengo gave me a good vibe (I am a very intuitive person!).

Technical interview

(Devengo’s POV)

This second interview is with the entire technical team and is basically a chat for the candidate to tell their vision of software development. Why with the entire team? Isn’t it an overkill? Aren’t we taking too much time/money from our employees? Well, it’s the team that the candidate will potentially be working with for 8 hours a day, Monday through Friday. It is essential that both parties are comfortable (at least initially) with the people they will be spending so many hours with.


This interview is mainly divided into three parts:

  • A 25-30 minute technical presentation on the candidate’s own project. Ideally, the one they’re working on or one that has been relevant for its impact/relevance:
    • how it is structured: architecture, libraries, delivery, testing, etc.
    • the “why” of that stack,
    • what things have turned out really well, and what things need to be improved.

We like it to be a real project and not a pet project because we think the latter are not very realistic. We would also like to see concrete code, although you can support it in a presentation if it is not possible to show the code due to a non-disclosure agreement, for example.

  • A 25-30 minute review of an Open Source project done with Ruby on Rails.
    • General practices that you have observed.
    • Aspects of the project that are well-focused and effective.
    • Areas that are poorly structured or could be improved.
    • Elements that are too complex or lack flexibility.

The candidate is expected to spend 3-4 hours on the project and critique it. Even if they have no previous experience with Ruby on Rails, we are interested in seeing what they can learn from an audit.

  • Presentation of the Devengo code base and the way of working:

After going through these parts, we leave the rest of the time to explain to the candidate how we are working on the project in general and on the backend in particular. We show them the code base they will be working on, how it is structured, how the different parts communicate, how we work on a day-to-day basis, etc. The aim is also to resolve any doubts that the candidate may have about our technical or operational/organisational approach, making it very clear what they will find if they finally become part of the team. Nobody wants unexpected surprises when starting to work in a new place, do they?

After this interview, the engineering people involved in it must provide a personal evaluation of the candidate. The assessment must be one of the following:

Yes

  • All must-haves criteria that were evaluated in the interview were present.

Resounding Yes

  • Extends Yes
  • Meets a substantial proportion of our “nice to have” criteria for the role.
  • Brings attractive qualities that we were not necessarily looking for.

No

  • One or more must-have criteria that were evaluated were found to be missing

Resounding No

  • Extends No
  • The candidate demonstrated clear opposition to our values/principles
  • The candidate demonstrated an unwillingness to learn our practices and rituals.

(Raúl’s POV)


In the first part, when presenting a project I had worked on, I felt very comfortable as I had quite a bit of control over the project. I liked to see from the conversation with the technical team that we agreed on many of the techniques and ways of thinking. But I liked even more the incisive questions they asked, which made me wonder about aspects of this project and if they could have been done better.

It is super interesting to see the external view of something that you are very familiar with and have deeply internalised, as it is sometimes difficult to rethink things. To give just one example, I realised that this project had many parts that were made from scratch and that it would have been interesting to leverage some existing tools.

I must admit that preparing to analyse an Open-Source project was more difficult for me. This was partly because I had no idea about Ruby on Rails and partly because I approached it wrong: I took it as an exam. Then, at the moment of truth, I realised that it was simply a conversation in which we were deciphering the most important parts. I was even able to ask them questions about Ruby/Rails!


The most important thing is that the objective of the meeting was achieved and that I got the information that I personally consider most valuable for me in the selection process:

  • What will my day-to-day work in this company really be like?
  • What will it be like to work with this code and tools?
  • Will I feel comfortable?
  • What feeling do my colleagues give me?


At this stage of my professional career, I would avoid at all costs starting to work in a place where I have not at least chatted for a while with all the team members.

We stayed for a long time—about four hours if I remember correctly—largely because we all asked a lot of questions and made many comments. I actually think that’s a good sign, as it indicates that there is an interest in getting to know each other thoroughly (like when time flies by on a romantic date, you know what I mean ;) ).


Welcome interview


If everything goes well and both parties agree that we want to work together, there will be a last talk with Alberto and Fernando (CEO and co-founder). It could be considered a welcome meeting, in which the details of the contract are discussed, and any possible last doubts that may have been left unanswered are resolved. It is also agreed on what day the candidate will start working, what hardware needs to be prepared, etc.

The only thing left to do is get down to work! The first days in a company are usually complicated for both the candidate and the company. The onboarding process is essential to making this landing as smooth and effective as possible, and at Devengo, we have a well-defined one.
But we explain that in part II of this series.

Author

  • Raul Vilares

    I'm a developer with a passion for delivering real value through my work. With a background in team management and technical coaching, I bring a diverse skill set to the table. I love coding and crafting solutions using object-oriented design and best practices. I thrive in collaborative environments, prioritizing teamwork and continuous improvement. When I'm not programming, you'll likely find me birdwatching. Let's create something awesome together!