14
.
11
.
2023
10
.
02
.
2019
HR
Visuality

Guide to recruitment at Visuality

Michał Piórkowski
Founder

This content is a bit outdated, and even though it's good to read the article we encourage you to check out the updated recruitment process - here.

As some of you may know Visuality was created in 2007 not as a software house but as an interactive agency. It means that for the first 3 years we were focusing on building fairly simple websites, content management systems and doing a lot of design-related things. After those exciting times, we realized that there is a growing demand for custom build applications --- that's when we decided to switch from being an agency to become a software house. Pretty soon we started hiring people but before we did that we had a long discussion about our mission. As a result, two things came up --- we wanted to focus mainly on providing the best quality of software and we also wanted to create a great working environment. As for the latter, you definitely should read our DNA description. In this article, I'd like to focus on the first part. If you are not that much into reading, there is a nice diagram at the end

What is quality basically?

At the beginning of the journey, it's pretty simple, with only 5 people around in the company, it's so easy to talk about quality and manage it. The problem appears when the team starts to grow which should make you think very precisely about the perfect candidate and the recruitment process itself. After many iterations, we have perfected our recruitment process and I would like to shortly describe how it looks here and what's our aim during every phase.

Everything starts with finding the right candidates. This is the job I like to do on my own, with a bit of help from my talented office manager, Alicja. We go through LinkedIn and try to find the candidates that would fit our requirements. The first thing we're looking at is education. We're aiming to find people that have gone through IT career. The reason is fairly simple --- we want to be sure that any candidate we talk to has the basic knowledge every student of IT should have. A lot of people are surprised we're thinking about such topics but our experience has shown us that if we want our people to grow and be capable of doing almost anything, they have to be familiar with those basics. Otherwise, they may hit a proverbial wall at some point. Of course, all of this does not mean that every candidate we talk to or hire has an IT degree, but most of them did and the ones that didn't were actually recommended to us through our vast network of friends in the IT industry.

Once we filter matching candidates we read their profiles carefully to see if they indicate further cultural inclination that is necessary for them to enjoy working here. If everything looks good, me or Alicja (personally) write a message to each candidate and try to arrange the recruitment process ourself..

Once we agree on the dates the true fun begins:)

Visuality recruitment --- chapter 1

The first meeting lasts about 3 hours. It's divided into two parts. The first one is a meeting with me (in Warsaw) or Adam (in Poznań) and lasts about 45--60 minutes. What is very crucial at this stage is that we know exactly who are we looking for and feel if we can offer a given person a good opportunity to grow and work in the place he/she wants to. This part is rather "soft" --- we talk about previous experiences, teamwork, education and all the things that are important for a given person. After that, we give a brief description of our company and our culture. When our part is finished two people from our team (engineers) join the meeting. We will be giving you challenges that can be solved with fundamental engineering knowledge or experience. We also try to dig a bit deeper into the answers to see how much you learned through studies or experience. The questions here refer to some fundamentals that are related to engineering. So if you want to be prepared for this part you can refresh your basic knowledge a bit (but of course it's not a must) and more importantly be yourself when giving answers. In this part we want to see how the person is thinking, how is he/she solving a given (usually simple) problem. That is why anything that has to be solved can be written in ANY language (we actually had a candidate who did it in VBA as he was feeling most comfortable with this language). What matters here is to see if the person is a true engineer and can approach problems in this manner.

What I should also mention is that everything is done in English, as this is our official language (because of international team and clients).

Visuality recruitment - chapter 2

If we see that the candidate is promising and the first part went well, we invite him or her to the second part. This one is attended by two members of the current team (engineers) and its main purpose is to check the main technology skills (backend or frontend). So during this part candidates are using Ruby and Javascript. We also check if the developer is up to date with current techniques and trends. This part takes up to 2 hours.

Visuality recruitment --- the final chapter

To be able to participate in the third part of the recruitment we look at the notes from previous parts and see if it's feasible to talk. We do not want to waste our candidates' time and give them false hopes. This part is basically pair-programming with one of our team members (an engineer) where a candidate is given a task and has to solve it while the team member is watching the way of thinking and solving issues. This part checks mainly coding skills, logical thinking and solution architecture skills. It takes around one hour.

Summary

After all three parts, we give an offer to the candidate. The offer is based on the things we have seen, the experience gathered so far by the candidate and on our salary policy. Also after conducting all three parts, we're able to set the first OKRs for the future employee, so the person will know exactly what are the things he or she has to work on during the first quarter in Visuality. We also decide who should be the first team-leader and which project he/she should join.

If at any part of the recruitment we see that there is no chemistry between us, we give a clear answer and try to provide more feedback if necessary/needed. What is very important that not being a good fit for us does not mean something is wrong. Very often we refer the candidates that didn't get the job to other companies we know if we are sure that they match their expectations and culture. It's an obvious statement, but there is no company in the world that is good for anybody.

I hope this article will give our future candidates a better vision of what is awaiting them and our clients a better understanding of the way we have been building engineering teams of professionals for a few years now.

To make it a bit easier to understand our process we created a simple diagram:)

Michał Piórkowski
Founder

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

Writing Chrome Extensions Is (probably) Easier Than You Think

14
.
11
.
2023
Antoni Smoliński
Tutorial
Frontend
Backend

Bounded Context - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

The origin of Poltrax development - story of POLTRAX (part 2)

29
.
11
.
2023
Stanisław Zawadzki
Ruby on Rails
Startups
Business
Backend

Ruby Meetups in 2022 - Summary

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Visuality
Conferences

Repository - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Example Application - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

How to launch a successful startup - story of POLTRAX (part 1)

14
.
11
.
2023
Michał Piórkowski
Ruby on Rails
Startups
Business

How to use different git emails for different projects

14
.
11
.
2023
Michał Łęcicki
Backend
Tutorial

Aggregate - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Visuality at wroc_love.rb 2022: It's back and it's good!

14
.
11
.
2023
Patryk Ptasiński
Ruby on Rails
Conferences
Ruby

Our journey to Event Storming

14
.
11
.
2023
Michał Łęcicki
Visuality
Event Storming

Should I use Active Record Callbacks?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Tutorial

How to rescue a transaction to roll back changes?

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Backend
Ruby
Tutorial

Safe navigation operator '&.' vs '.try' in Rails

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Ruby
Tutorial

What does the ||= operator actually mean in Ruby?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Ruby
Tutorial

How to design an entity - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Entity - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Should I use instance variables in Rails views?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Frontend
Backend
Tutorial

Data Quality in Ruby on Rails

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Software

We started using Event Storming. Here’s why!

14
.
11
.
2023
Mariusz Kozieł
Event Storming
Visuality

First Miłośnicy Ruby Warsaw Meetup

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality

Should I use Action Filters?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Tutorial

Value Object - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial