How we assess seniority

This page explains how we assess seniority in our hiring process: why we use practical tasks, what we look at when we review them, how time is used as one benchmark, and what happens next. It is not a job description, and it is not the specification for a particular task. The details of each task are provided separately for the relevant role.

Why we use this approach

We hire across different engineering profiles, including backend, frontend, and other software engineering roles. Over time, we needed a more consistent way to assess seniority across those roles.

CVs, titles, and interviews still matter. They give useful background. But they do not always show how someone handles a practical engineering problem with a clear scope. On the other hand, we do not want to ask candidates to spend many hours on large take-home assignments. Those tasks are often too open-ended, hard to compare fairly, and disproportionately time-consuming, especially for experienced engineers.

So we use focused, role-specific tasks with deliberately limited scope. That gives us something practical to assess, without turning the process into a large unpaid exercise.

What seniority means in practice

For us, seniority is not defined only by years of experience or by title. Those things matter as context, but they are not enough by themselves.

What matters more is how an engineer approaches a bounded piece of work. Seniority often shows up in how quickly someone understands the problem, how well they scope it, how sound their technical decisions are, how proportionate their implementation choices are, how correct the result is, and how clearly they can explain the trade-offs behind it.

Put simply, seniority is not something a candidate proves by stating it. It becomes visible in the way they work through a practical task and in how they talk through their reasoning afterwards.

Why our practical tasks are focused and limited

A practical task should clarify level, not create unnecessary burden. That is why our tasks are intentionally focused and limited in scope.

We do not use them as project delivery work or unpaid production work. The output is used for assessment and discussion in the hiring process, not for delivery into our product environment. We also do not design these tasks as long, open-ended exercises, and we are not trying to create trick questions or artificial difficulty.

In most cases, the task is straightforward by design. What matters is not whether it looks impressive on paper, but how the candidate approaches it, how quickly they see what matters, and how sensibly they move towards a working solution.

That distinction matters. We are not looking for the most elaborate submission, and we are not interested in over-engineering. The point of the task is to make practical seniority visible in a bounded setting.

How self-assessment works

Candidates receive access to the relevant task in advance. We do this because we want the technical discussion to be concrete and informed, not based on surprise.

Looking at the task beforehand gives candidates a clear reference point for the level of practical problem-solving expected for the role. For many people, that is useful in itself. Some will look at the task and immediately see a path to a solution. Others may feel it is manageable but would take more time and effort. Others may decide that the role is not the right fit for their current level of practical readiness.

We think that kind of self-assessment is useful. It does not replace our evaluation, but it does reduce ambiguity. It helps candidates understand what is expected, and it helps make the later technical discussion more specific and more balanced.

How we use time as a benchmark

Time matters in our process, but it is not used on its own and it is not the sole basis for a decision.

We use internal benchmark timings based on our own calibration of the tasks. Those benchmarks are part of our internal framework for assessing practical seniority. They give us a reference point for how quickly a candidate reaches a working baseline on a task of comparable scope.

A working solution is the starting point. The speed at which a candidate reaches that point is one meaningful signal, because practical seniority often shows up not only in whether someone can solve a problem, but in how quickly they can orient themselves, make sound decisions, and move towards a correct result.

In broad terms, candidates operating at a more senior level will often reach that baseline more quickly and with more confidence in their decisions, while candidates at earlier stages may need materially more time. But timing is only one part of the picture. We always consider it alongside correctness, implementation quality, scope control, and technical reasoning.

We explain this openly because we want candidates to understand how the task is used. The benchmark helps us keep the process consistent and transparent. It is not a standalone verdict.

What we evaluate

A working solution matters, but it is only the starting point. What we are really looking at is whether the candidate understood the task properly and whether the result reflects sound engineering judgement for the level they claim.

That includes correctness, but also proportion. We look at whether the implementation is pragmatic, whether the structure is clean and coherent, whether business rules and validation are handled sensibly, and whether the candidate can explain their choices in a clear and well-reasoned way.

We are not looking for the most complex solution, and we are not looking for unnecessary sophistication. A correct, sensible, well-scoped implementation is usually more valuable than something elaborate that goes beyond what the task actually requires. The task is not there to show everything a candidate knows. It is there to show how they work when the scope is clear and judgement still matters.

What happens after the task

Once the candidate has reviewed the task, it becomes part of the technical discussion with our CTO or technical leadership. That gives us a concrete basis for discussing approach, implementation choices, trade-offs, and priorities.

Depending on the situation, the candidate may be asked how they would structure the work, what they considered most important, which decisions were straightforward, and where judgement was required. Where needed, we may also use an additional practical validation step in a supervised setting to clarify open questions.

The purpose of this stage is not to create pressure. It is to make the assessment more concrete, more structured, and less dependent on general impressions alone.

Role-specific assessment tasks

This page explains the general method we use to assess engineering seniority. The detailed practical task depends on the role, so each position has its own role-specific task page.

If you are applying for an engineering role, please review the task linked to that position before the technical discussion. It will give you a clearer sense of expected scope and help you prepare in an informed and practical way.