How Visuality Recruits - Conversation, not an Exam

When did you first feel you might become a programmer? It is a question I often open a technical interview with.

The answers cover a broad spectrum - from the first family computer fascination to a changed major in the middle of college. It proved to be the fastest way to get a person into a conversation instead of reciting a CV. It sets the tone for the next three hours, because this is a conversation, not an exam.

In the previous article we described how Visuality defines mid, senior, master and expert levels. This one is about how we check those levels in recruitment: what we actually look at, and the part that is genuinely difficult, which is telling a senior from a master.

First Learn About Motivation

Our recruitment is built on two long conversations. The first one has no code in it. We talk about a candidate's path so far and dreams for the future. We learn about their history, communication, English skills, how they approach unsolved problems, and are they involved in the Ruby community.

This part answers two questions at once. Whether the person would be happy working at Visuality, and whether Visuality would gain from having such a talent on board. Both have to be true.

What the Technical Interview Covers

The core is the same for any position from mid upwards. We start with the career path, focusing on what somebody personally built and owned, then move through backend, databases, infrastructure, frontend and LLMs. With senior and above we do system design and architecture exercises. We also look for AI-native engineers - people who work with tools like Claude Code or Codex daily and treat agents as part of the craft.

The interview finishes with live coding in a Rails codebase. No vibes allowed at this time, we need to see a candidate looking at real code.

Looking for Boundaries, Not for Gaps

The goal of this conversation is never to catch a person on lack of knowledge. Everybody has a boundary, the interviewer included, and we are looking for where the boundary shows up. We steer each topic deeper until we reach the edge of what somebody has worked with, take a minute to be sure we are reading it right, and move on. Nobody fails at that moment. Reaching it is the point of the exercise.

Doing this across a spectrum of topics maps a landscape of knowledge. That map is the level.

What Mid, Senior and Master Answers Look Like

Let's discuss an example question. Two parts of a system need to know about the same signal. How do they find out?

A mid-level engineer solves it with an HTTP call. It works, and nothing they have built ever needed more. It's the simplest solution, but it may be just fine for this level of experience.

A senior asks before answering. What's the volume. What happens when the other side is down. Does the caller need the answer right now, or just need it to have happened. The answers rule the direct call out, and they name what replaces it: publish the event to a message bus. Let the other system subscribe and consume the message when it's ready. The answer covers the whole application and the next few years of it.

A master names similar tools and keeps going. Why are these two parts separate, who owns each one, and is the split paying for itself. If two teams own them, the message schema becomes a contract between those teams, and changing it later stops being a code change and turns into a negotiation with a deprecation window. They will also tell you who gets paged when the consumer falls behind, and whether this company can realistically run a broker at four in the morning. The application has stopped being the largest object in view.

The difference is in the depth of answers, in choosing the right tools and in having the experiences to draw examples from.

A Master in One Niche Can Be Mid in Another

One question maps one boundary, not a person. Somebody can be a master in their own niche and mid in service oriented architecture, which is why no single answer decides a level. The career path we go through at the start of the interview is what tells us where to look for the depth.

The Conversation Goes Both Ways

Whenever I find a gap witin an essential aspect, I never just skip to another topic. I do my best to introduce the concept, the way you would explain it to a colleague. If examples or references come up, I send the links after the meeting. A few hours of somebody's attention should be worth something to them whether or not we make an offer.

Every candidate gets feedback, hired or not. It used to be an email with my observations. Now it's a separate meeting for anyone who wants it. I gladly share what impressed me and what I dissagreed with. It's also a good moment to share sources of knowledge or strategies for improvement.

The Complexity of Running This Interview

Telling a senior from a master means being able to follow a master's knowledge for as long as it takes. That takes deep knowledge and a lot of experience. On the scale from the previous article - it requires an expert level.

Nobody can map a boundary from inside it. Whatever the interviewer doesn't know sets the ceiling of the conversation. Above that ceiling every answer looks correct. A company that recruits this way caps itself at the level of whoever conducts the interviews.

Every Developer at Visuality Was Hired This Way

Everybody at Visuality has been through these conversations, one candidate at a time, hand picked and hired on what we saw across those hours rather than on what a CV claimed.

Hiring well is only the first half of the job. What happens afterwards, and how we help people grow towards excellence once they are here, is the subject of the next article.