Skip to content
Hiring — shared
Share
Explore
Here are my thoughts and outcomes of the last n years of hiring developers, analysts, architects, testers, and DevOps engineers along with arranging the multiple bootcamps. This article is completely opinionated and may be helpful to bring some personal insights and potentially improve the candidate's experience and the business outcomes.
All the pictures are either drawn in , , , generated by GPTs, taken from your posts (many thanks for sharing your wisdom), or are based on many conferences and books. References are at the end of the article.

What is the process?

Here as always a good place for a critical thinking reminder. You need to preserve some common sense and tailor the practices described here, as well as I myself adjust the processes when needed.
A typical hiring pipeline looks like this one below. The most common changes are: language interview is needed only for the developer positions, people, who will be focused on delivering the production-grade code. This stage is focused on the abilities to think algorithmically (my concern) and to know the common abstractions of the language, the framework ontology (lead-developer’s concern). This stage of the interview will be described in details in the further article. For analysts, architects, testers and DevOps, the system design interview with some adjustments to each of the role with the possible extension towards the troubleshooting interview takes place. Management interview as a separate stage is important for associate managers levels and above. Otherwise, it can be combined with the previous stages.
image.png

Now let's discuss and what we want to check with such a multi-step hiring process. For sure, you can use the holistic frameworks like , and many insights I took from that awesome framework.
image.png
Let's run through them
- People management: how the candidate manages people - Managing teams: how a candidate manages a team - Process & project management: how the candidate knows how to organize work in order to achieve the desired results. - Soft skills: how the candidate is able to communicate and convey their thoughts. This point is checked throughout the interview process. - Technical skills: even if we are looking for technical managers, so they should have an understanding of engineering. Remember to adjust the requirements, depending on the role! - Cultural fit: it is important that the company's values and management approach are close to the candidate's management philosophy and practices. In addition, it is essential that the candidate is comfortable with the team itself, as they are different: they work on different products (b2b, b2c, internal, external, ...), with different stages of product maturity, with different engineering practices, different team composition, etc.
Two approaches to hiring are worth discussing separately: company-based or team-based. Each of them has its pros and cons:
Company-based hiring
+ Uniform requirements provide a predictable level of candidates and generally provide a repeatable process. + The process can be scaled by adding interviewers at any of the interview stages where shortages are felt.
- This process is difficult to organize and maintain. - Not all candidates like this process, as they often want to spend less effort on interviews and get feedback faster. - The process has significant overheads.

Team-hiring
+ With this type of hiring, we can get more precisely into the needs of a particular team without having to check things that won't be needed to get the job done. + Candidates usually like this type of process because of its simplicity. + Overhead costs are lower than company-based hiring. + This process is fairly easy to organize, as the hiring manager can do everything themselves
- The process is difficult to scale as it is all tied to interviewers personalities and team specifics. - The level of candidates hired depends directly on the hiring managers and can vary a lot from company to company. For example, some managers may take people to just close a position without waiting for the right candidate, and some may look for an ideal candidate for years.
As we are constantly growing and changing our structure, as we aim to decentralize important decision-making: the overall direction is set by strategy, and specific actions need to be taken by managers on the ground, we use company-based hiring, and use fit interviews to match to the team’s needs.

Here come the interview stages:

Peer review assessment

After going through the mandatory interview stages, we have results for management, system design and other interviews, each of them are rated on a scale of junior, middle, senior. This can be graphically represented as a radar chart.
image.png
These results are then aggregated into a decision matrix and evaluated by a peer-review group, who can expertly grade the candidate. Often, this group will additionally make recommendations to hiring managers, for example, indicating the type of team where the candidate can add the most value or what points should be emphasized during the fit interview.
A typical team-lead profile.
image.png
A software engeneer profile:
image.png
A software engenner with possible software architect positions after an additional interview.
image.png

In short, you should choose a candidate who has at least a 90 percent chance of achieving a set of outcomes that only the top 10 percent of possible candidates could achieve.

References with one-line comments

What to do

- a canocical book, amagingly hard to read, goes right after Jean Baudrillard - Fatal Strategies in my list.
- DDD in simple words, must to read

How to do

Roxanne E. Miller - The Quest for Software Requirements - must read.
- surprisingly not boring
- a must read, focused on ability to evolute as the main function of the architecture.
- hard, but must-to-read for data archs
- simple and essential patterns, an easy start, a good read.
- availability vs reliability and patterns to reach higher availability
- not only about paying the CSP bills, worth to read
- a canonical, but kinda old book, better to read Larry Constantine, Fawler is hard to grasp
- amaising must read for solution architects, almast actual nowadays.
- a prequel to the pandora-box with microservices. Trains your critical thinking.
- good and holistic, but need to re-read

How to operate

- was nice to decompose my work as a deployment lead
- google practises, structured as internal articles.
- remember, that you are not Google, but nice to pretend.
- must-read.

Interviews

Current article is also inspired by the interview preparation guids, but note, that without the books above you can’t really understand, if the candidate learnt the preparation resources and has no basis behind.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.