Hiring — shared

Explore

Interview Guide

Screening interview

System design section

Troubleshooting and SRE section

Management section

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

https://excalidraw.com/⁠

https://sketchboard.io/⁠

https://miro.com/⁠

, 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.

⁠

Now let's think of what we want to check with a multi-step hiring process. For sure, you can use the holistic frameworks like

SFIA views⁠

, and many insights I took from that awesome framework.

⁠

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:

⁠

Screening interview⁠

⁠

System design section⁠

⁠

Troubleshooting and SRE section⁠

⁠

Management section⁠

⁠

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.

⁠

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.

⁠

A software engeneer profile:

⁠

A software engenner with possible software architect positions after an additional interview.

⁠

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

⁠

Domain-Driven Design: Tackling Complexity in the Heart of Software⁠

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

⁠

What Is Domain-Driven Design?⁠

- DDD in simple words, must to read

How to do

⁠

Software Requirements. Third Edition⁠

- must read.

Roxanne E. Miller - The Quest for Software Requirements - must read.

⁠

Fundamentals of Software Architecture⁠

- surprisingly not boring

⁠

Building Evolutionary Architectures⁠

- a must read, focused on ability to evolute as the main function of the architecture.

⁠

Designing Data-Intensive Applications⁠

- hard, but must-to-read for data archs

⁠

Designing Distributed Systems⁠

- simple and essential patterns, an easy start, a good read.

⁠

Architecting for Scale, 2nd Edition⁠

- availability vs reliability and patterns to reach higher availability

⁠

Cloud Native⁠

- not only about paying the CSP bills, worth to read

⁠

Patterns of Enterprise Application Architecture⁠

- a canonical, but kinda old book, better to read Larry Constantine, Fawler is hard to grasp

⁠

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions⁠

- amaising must read for solution architects, almast actual nowadays.

⁠

Monolith to Microservices⁠

- a prequel to the pandora-box with microservices. Trains your critical thinking.

⁠

Building Microservices, 2nd Edition⁠

- good and holistic, but need to re-read

How to operate

⁠

Release It!, 2nd Edition⁠

- was nice to decompose my work as a deployment lead

⁠

Site Reliability Engineering⁠

- google practises, structured as internal articles.

⁠

The Site Reliability Workbook⁠

- remember, that you are not Google, but nice to pretend.

⁠

Kubernetes Patterns⁠

- must-read.

Interviews

⁠

Who: The A Method for Hiring⁠

- must-read

⁠

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.

⁠

GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.⁠

⁠

GitHub - Developer-Y/Scalable-Software-Architecture: Collection of tech talks, papers and web links on Distributed Systems, Scalability and System Design.⁠

⁠

Distributed Systems lecture series⁠

⁠

nealford.com • Architectural Katas⁠

⁠

TianPan.co⁠

⁠

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.