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

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

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

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

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

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial

GraphQL in Ruby on Rails: How to Extend Connections

14
.
11
.
2023
Cezary Kłos
Ruby on Rails
GraphQL
Backend
Tutorial

Tetris on Rails

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

EURUKO 2023 - here's what you've missed

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

Easy introduction to Connection Pool in ruby

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

When crazy ideas bring great time or how we organized our first Conference!

04
.
12
.
2023
Alexander Repnikov
Ruby on Rails
Conferences
Visuality

Stacey Matrix & Takeaways - why does your IT project suck?

14
.
11
.
2023
Wiktor De Witte
Project Management
Business

A simple guide to pessimistic locking in Rails

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

Poltrax design - story of POLTRAX (part 3)

04
.
12
.
2023
Mateusz Wodyk
Startups
Business
Design

Writing Chrome Extensions Is (probably) Easier Than You Think

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