On Recruiting Full Stacks

Hi there! I'm Radek, and I've been one of the "interviewing people" for years now. Today, more than a hundred interviews later, we've finally decided to tell the world how we do it.

Every recruitment process starts way before there’s any candidate. Most of them end as soon as someone gets hired – we go one step further, including the onboarding. This process is a result of years of gradual improvements.

This time we’ll look into the process I’ve been part of for over five years now. No. I’m not an expert, and no, I’m not educated in this direction at all. However, I think I can say I’m at least decent at it.

Everything all starts with a need. Here it’s a need for more people. Usually, the goal is to be able to have more projects in parallel; otherwise, to cover the lack of a specific skill or just hire someone smart or promising.

But before there’s anyone to talk to, people need to know that we’re recruiting. What works best for us are the bootcamps and meetups we held to promote certain technology. Next are the job boards, direct recommendations, and the company website (especially when shared on social media).

It’s essential to be open to different scenarios. Let’s take an example: we have a dire need of an experienced person with a solid understanding of X. If in the process of searching we’ll find someone not entirely covering this position but interesting in other ways, we’d definitely give it a try.

As suggested in the title, we’re focused on JavaScript full-stack developers. Every programmer in the company is skilled in both front- and backend, often with a strong preference for one over the other. However, when it comes to hiring, we’re fine to hire someone inexperienced in “one of the ends” – they’ll learn it. Similarly, we’re open to web developers experienced in other, mostly web, technologies willing to switch to JavaScript.

Finally, there are internships. Students are required to have some real-life commercial experience in order to graduate.
In most cases, it’s between four and eight weeks. And as there’s a lot of students, universities often have one or even several partnership programs with local companies in mind. It’s pretty simple: every company prepares a short, job offer-ish description and receives a list of interested students.

To make it all work, every participating company is often obliged to hire at least a couple of students “in return.” It was never a problem for us as we found some great people every single time. In a way, we treat the internship as a great way of giving the person time and resources to grow and show us their real potential.

When a fresh resume – or CV if you like – hits our email, only a few people can access it. That’s because there are people spamming mass-sending those to all companies. A very brief “pre-review review” eliminates all these entirely unrelated ones (some are really far from IT).

Later, all relevant ones are posted on a “recruitment Slack channel.” And once again, only a strictly limited group of people can access it, mostly interviewers. Everyone is encouraged to comment on each resume – it’s like voting for and against but with more context. Recommendations from within the company work similarly – the resume is posted on Slack. No extra points nor a “fast lane.”

To make an informed decision, we try to know as much as possible from this limited piece of information. Our goal is to evaluate a candidate as a whole, with a specific position as a direction, not a goal. And yes, we do read some code samples, e.g., hosted demos or a GitHub profile.

However, a resume is a very limited form. Nobody stops you from sending an eight pages long one (that actually happened), but the sad truth is that most people are not that interested in reading them. Let’s face it – the first page is the most important one. (Often, it’s the only one being read.)

But the biggest problem is that there’s no objective scale of experience. Years can be some sort of a baseline, but neither a precise nor a fair one. I personally prefer some bullet points about previous positions or own projects. You can put the names of technologies there as well as describe the tasks you’ve been doing – that’s enough to get the idea of who I am looking at.

When it comes to describing a skill level, there are a lot of possibilities. I've seen a lot of arbitrary “X/Y” scales, (filled) circles and boxes, line and pie charts, and even word clouds... A list of technologies is fine and lets you be far more precise, as you may add frameworks and libraries next to the languages you know. In the end, what does “JavaScript ●●●○○” even mean?

The resume was OKAY. What now? Well, for years, the whole process was a little shorter – we’d already go into the technical chat. But as the company grew, it became unfeasible – too many candidates failed the non-technical part. That’s why we have made it into an additional step.

The whole meeting is just an informal chat, maybe a video call or even a short phone call. In the end, we’d like to work with you, and it’d be nice to get to know each other. It’s not something one could “fail”, but it’s a nice way to introduce someone to the company culture.

The most important part of the “first encounter” is the language check. We’re a software house working almost exclusively with foreign clients, and all of the communication and code are in English. There’s no need for an excellent accent, but as you’re most likely going to talk to the client on a daily basis, an ability to present your own work or “do small talk” is required.

Furthermore, we may ask here a couple of extra questions about the resume. These are often about the past positions and one’s view on the technologies we use. If there’s no front- or backend experience in the resume, we’ll also ask how a full-stack position works for that person and what they’d like to focus on work-wise – own roadmaps are important.

It’s also the first time where we may try to check whether you have some traits we value. There’s no strict definition of what a trait is, but “a general skill in a certain area, not necessarily related to the position you’re applying for” is a close one. We have an extensive list of ones we care about, including DevOps, hardware, security, auditing, writing, marketing, public speaking, open-source, and management (as in tech lead).

There’s also a short questionnaire: availability (full or part-time), notice period, preferred employment form, and finally – one’s salary expectations. There’s no need to worry about the last one; it’s just something we want to consider. If we’d like to hire someone, we’ll come up with an offer anyway. And if it doesn’t meet the salary expectations, we’re open to discussing what’d need to change in order to achieve it. In addition to that, we may propose a timeline on how it may look like in the nearest future.

There’s also time for questions about the company, both ongoing and planned projects, working hours, vacations, etc. Basically, everything is already covered in the job description. However, there’s always something else we didn’t think of.

At this point, we also plan when they’ll meet the CEO. It’s really important for some people, less for others... In any case, it is for us. This quick talk is a part of the company “culture check.” But no worries! It’s made and meant to be good for both sides – it’s essential to feel good at work.

Now I can finally meet you! Let’s start with a short chat about who you are and why you are here. I know, I read your resume, and someone already asked you that once or twice. But as it’s our first chat – let’s have a nice and friendly start. And let that be clear: it’s a chat, not an interrogation.

No FizzBuzz. No whiteboard. No binary trees to invert. There are, of course, strictly technical questions. If you don’t know the answer, we’ll try to rephrase and ask it again. The goal is to check whether you understand, not remember. If possible, we may ask the same question using another programming language you know. (You’d be surprised how well it works.)

There are also open questions. These are not strictly related to one language or library but rather to more general phenomena. This shows whether your level of understanding of software development ends at the code or goes (far)beyond that. I’d say there are three possible outcomes: “my code”, “our code”, “code in general”. It’s hard to describe, but it somehow corresponds to the level of experience and self-reliance.

Finally, there are some with a couple of lines of code to read. Here we don’t really focus on whether you can or cannot tell what the result will be, but rather how you work on that. You won’t be allowed to access any kind of online or offline documentation, but we’ll answer all of the questions. Once again: we value understanding over knowledge.

Of course, not everyone will answer every single question. To make the best of the time both sides invest in the process, we’ll not only give you the answers right away but also provide you with relevant feedback afterward.

That’s actually the most important part of the whole step – feedback. If you work with us, this feedback will be something we’d like you to work on – it’ll be a part of the onboarding process. And if not, we’ll gladly share our findings to make up for your time.

Once we’re done, we’re the ones answering questions. It’s up to you whether you'll have any, but I strongly recommend having one or two. In the end, you're now talking with your soon-to-be colleagues, right?

There are at least a million ways to conduct a proper tech interview, and new ones are coming up every day. And as you may have expected, there are also some... Unconventional ones. Do you know Factorio?

This text from Erik McClure describes in detail how this game can be used as an environment to interview programmers. It’s completely infeasible to do so(of course), even if someone actually knows the game. However, the fact that people have to check whether it’s a joke or not shows the problem with hiring.

We’re doing our best. If it were possible, we’d be done in fifteen minutes, really. The process I’m describing now is a result of long years and hundreds of such technical chats. We’ve tried reordering questions, (un)grouping them, making them longer or shorter... It’s all about time. A longer hiring process yields far more information about the candidates but, of course, takes more time. Hiring people instantly for a (short) trial period is fast but costs their salary as well as the eventual repair costs. The problem is to balance it out.

At this stage, we already know everything we need, except one little thing...What is the actual experience of working together? Yes, together – it’s important for you to make sure you want to work with us. That’s where a trial day comes in – a full day of actual work. And as it’s a full day of actual work, it’s actually paid.

An important aspect of it is that we not only want to simulate the day-to-day work on a technical level but also on the social one. It’s definitely “less social” now when it has to be a series of remote sessions, but that’s how we work for a year now. Luckily, most people are already used to video calls.

During that day, we do a mini-version of the sprint. It starts with planning the (already prepared) tasks, then there’s time for coding and a short demo and retro at the end of the day. To make it even more “real,” we do have one or two brief pair programming sessions (between 5 and 15 minutes).

Historically, the act of pair programming turned out to be far more important than we initially thought. For a long time, we were only answering questions and helping with technical problems. No initiative from the candidate implied zero technical communication throughout the whole day. What is more, pair-programming lets us see how one solves code problems, as we may pinpoint one straight away instead of waiting for it for the demo.

The missing piece is some way to proceed with the already mentioned “culture check.” And lunch works just great. No, we aren’t forcing anyone to eat – that’s not the point! The fact of going out of the office with a larger group, usually ten, is something we already do, and a “plus one” feels natural. The conversations that happen there are often the most interesting ones, really.

But there’s more than that. Everyone in the company is allowed to veto the candidate at any time of the entire process. People are complex creatures and, for a lot of reasons, may not want to work together. And as we want to make sure everyone will be fine, this option exists. (We never used it, though.)

At the end of the day (literally), once the demo and retro are done, we decide whether to make an offer or not. As I mentioned before, the feedback gathered throughout the day is given in any case; often (technical) parts of it are briefly explained in detail during the day. Once the decision is made, we can go home.

Technically, onboarding is not a part of the hiring process. However, as these are related and strictly following each other, we treat them as such. However, this step is no longer focused on deciding whether the newest employee will stay with us but rather on further (self) development.

Working on the feedback accumulated during the process is one of the (soft)requirements to be considered fully onboarded. Others include a few in-house trainings of tools and processes. These are rather basic, like the issue tracker or how we report and keep track of vacations.

Keep in mind that the onboarding process is more than that. Our focus is still the evaluation. We have a special budget planned just for that – having time to properly evaluate the new employee.

It all starts with creating an email and other accounts. Once that’s done, these have to be configured. And as it takes time each time, we have created our own Handbook. It includes (almost) all of the important links and clearly defines the processes one may need to do their job.

To make it easier, everyone gets a buddy. Reading one document over and over can be overwhelming, and simply asking someone may be much faster. This person is not necessarily someone you’ll work with – it’s more of a “contact” or a “first-aid” kind of relation. It’s someone who “knows or knows who will”.

Towards the end, everyone gets to talk to all of the “important people” of the company. It’s highly unlikely they didn’t meet them already, but here it’s more of an introduction of their roles and the work they do. It may be eye-opening, or at least interesting, to know what does CEO or CTO does.

All of that is written down in the form of a short checklist. It may feel extremely formal, but it’s there just to make sure we won’t forget a single thing. There is a couple of other meetings: with more experienced people in the same position, to talk about the future, but also with other coworkers, to understand what do they do. That’s also known as the T-shaped skills approach.

As always, it ends with a review, mostly feedback of people the person worked with, also on a non-technical level. We also consider people’s opinions from the circles you’ve been in, like QA Meeting or DevOps Group – it may result in some interesting suggestions for further self-improvements.

That was a long one! At least the text was long – how about the process? All the preparations (step 0) are impacted by many factors and takes between a day and a couple of weeks. The whole hiring part (steps 1 through 4) usually takes a week or two. The onboarding is always one calendar month.

Do I think we could do better at it? Definitely. Do I have an idea how? Not really. Once again, it works for us. And from what we hear, people are fine with the length and transparency of it. The whole process is constantly evolving and has some kind of art in it. All people in this process really feel it. No "What kind of pizza are you?" questions, sorry.

The article also appeared on the author's blog: radekmie