Привет, меня зовут Сергей Киселев, я управляю командой Development Platform в MWS Cloud Platform, а ещё давно провожу собеседования разработчиков и собираю команды. Умею делать алгоритмические секции без негатива от кандидатов, сам иногда собираю оферы, учу сына писать на C++. В этой статье расскажу, как мы построили процесс интервью для разработчика в MWS Cloud Platform. И почему важно на собеседовании проверять практические навыки.

В конце 2023 года мы начали найм большой команды для нового публичного облака от компании МТС. Цель — быстро нанимать опытных разработчиков. В итоге наняли более 200 разработчиков (C++, Golang, Java, Kotlin). Кандидат приходил к нам на одно техническое интервью, и по результатам мы были готовы проводить финальное собеседование в команду для разработчика уровня middle+. Для senior+ мы ещё проводили system design интервью, либо спрашивали о кандидате у доверенного эксперта.

Сейчас мы можем меньше чем за неделю дать кандидату офер. Мы построили удобный процесс, основываясь на собственном опыте затяжных и непонятных интервью в других компаниях. И обратная связь от кандидатов это подтверждает.

Структура интервью

Joker: «You know what I noticed? Nobody panics when things go "according to plan." Even if the plan is horrifying»

В начале встречи собеседующий знакомит кандидата с форматом технического интервью и объясняет правила игры. При взаимном интересе можно кратко обсудить опыт кандидата по написанию кода. Тут важно не затягивать и сразу перейти к основным темам технического интервью. В результате можно визуализировать опыт кандидата в векторную диаграмму, чтобы быстро оценить его компетенции.

На оценку каждого навыка мы тратим не более 15 минут. Важно успеть проверить ключевые вещи и не уходить глубоко. На всё у нас 90 минут, из которых надо выделить время на знакомство и пару вопросов от кандидата. Четыре темы ключевые: ревью кода, написание кода, concurrency, проектирование. Все эти темы важны в ежедневной работе наших разработчиков. Есть ещё бонусная штука — joker-вопрос от собеседующего, обычно это тема, знакомая всем участникам собеседования.

Ревью кода

Joker: «Never start with the head. The victim gets all fuzzy. He can't feel the next...»

Мы начинаем с код-ревью — этим занимаются все разработчики у нас в компании, и поэтому важно понять, есть ли тут совпадение по культуре. Код на ревью будет с вопросами, здесь нет правильных ответов, но есть маркеры, на которые кандидат обращает внимание, тут важна культура обсуждения замечаний к коду.

Пример одной из задач на ревью кода (мы даём чуть больше):

func (s *Service) Handle(data Data) *Result {
  for {
    result, err := s.DataService.Create()
    switch {
    case err == nil:
      return result
    case err.Again:
    default:
      log.Logger.Err(err)
      break
    }
  }
  return nil
}

Кто-то проговаривает проблемы с кодом, идеально, если это появляется в виде комментариев в коде. Довольно сомнительно, когда кандидат начинает вносить изменения в код. В любом случае всё это сигналы, которые нужно собрать и зафиксировать в отчёте. Пользуясь этой информацией, будем принимать решение о найме.

На ревью кода мы проверяем, что кандидат:

• может уточнить, что от него требуется, и договориться об ожиданиях;

• видел подобный код ранее и знает про потенциальные проблемы;

• умеет читать чужой код и замечать проблемы;

• может писать замечания к чужому коду.

Написание кода

Joker: «In... you see, in their last moments, people show you who they really are. So in a way, I know your friends better than you ever did».

Многие компании практикуют лайв-кодинг при оценке кандидатов. Иногда это превращается в суровые алгоритмические секции на много часов. Не все кандидаты к этому готовы, но мы решили не отказываться от написания кода на собеседовании. Мы даём одну простую (leetcode easy) задачу и оцениваем, как кандидат пишет код. Если читаешь и пишешь код каждый день, то точно помнишь, как пишутся операторы, циклы и сигнатуры функций.

Пример одной из задач с решением (мы даём чуть сложнее, кандидат пишет только код внутри функции):

// Find Words Containing Character
// You are given a 0-indexed array of strings words and a character x.
// Return an array of indices representing the words that contain the character x.
// Note that the returned array may be in **any** order.
public List<Integer> findWordsContaining(String[] words, char x) {
	List<Integer> result = new ArrayList<>();
	int index = 0;
	for (String word: words) {
		if (word.indexOf(x) >= 0) {
			result.add(index);
		}
		index++;
	}
	return result;
}

Задача на код — это не про алгоритмы, а скорее про написание обычного кода. Мы специально не даём сложные алгоритмические задачи. Но если кандидат попросит сложнее, то наш собеседующий может пойти ему навстречу и дать что-то посложнее. Основная цель — понять, как кандидат работает с новым кодом. Это именно то, что делают наши разработчики каждый день.

На написании кода мы проверяем, что кандидат:

• может придумать и объяснить способ решения;

• не усложняет задачу и учитывает время на решение;

• может оперативно написать простое решение и не путается в своём коде;

• проверяет своё решение самостоятельно и не перекладывает тестирование на собеседующего.

Concurrency

Joker: «You see, I'm a guy of simple taste. I enjoy... dynamite... and gunpowder... and gasoline».

В современных языках и подходах прячут сложность concurrency за синтаксисом или библиотеками. Но опытный разработчик всё равно должен понимать, как это устроено внутри и когда абстракция начинает течь. Часто дебаг проблемы затрагивает множество слоёв, и без понимания основ разработчик оказывается беспомощен. Поэтому мы даём задачу на concurrency и просим написать код для обсуждения.

Пример довольно спорной реализации deadlock на go channels (код пишет кандидат):

ch1 := make(chan string)
ch2 := make(chan string)
go func() {
	println(<-ch1)
	ch2 <- "message2"
}()
println(<-ch2)
ch1 <- "message1"

// > fatal error: all goroutines are asleep - deadlock!

Два опытных разработчика на этой секции обсуждают несовершенство языка и библиотек. При этом можно не иметь в этом практического опыта, но иметь интерес к этой теме. Кроме книг есть статьи с разбором внутрянки. На крайний случай — конференции, где докладчики любят хвастаться опытом concurrency. И мы хотим убедиться, что у нас общие интересы с кандидатом.

На concurrency-секции мы проверяем, что кандидат:

• имеет базовые знания про concurrency и как это работает на современных операционных системах;

• понимает абстракции внутри языка программирования (atomic, cas, barrier, semaphore, channel, etc);

• осознаёт, как работает взаимодействие между потоками и как это реализуется в языке программирования;

• есть опыт решения проблем с concurrency.

Проектирование

Joker: «All you care about is money. This town deserves a better class of criminal... and I'm gonna give it to them».

Мы бы хотели писать приложения по аналогии со сборкой лего, но почти у всех получается карточный домик. Часто опытным разработчикам устраивают отдельное интервью по системному дизайну. Крайне важно учитывать хрупкость отдельных кусочков и создавать сервисы без десятикратного запаса прочности. У нас нет времени на этот разговор на техническом интервью, но мы можем проверить базовые навыки по проектированию и эксплуатации сервисов.

Пример задачи на проектирование с вопросами для фасилитации (кандидату вопросы не показываем):

## Задача:
Вы написали идеальный CRUD-сервис с rest api. У вас есть база данных для модели приложения. Как будет выглядеть добавление нового метода на ваш бэкенд? Требуется расписать последовательность шагов по добавлению нового метода. На что стоит обращать внимание? Как вы поймёте, что всё работает у пользователя?

## Вопросы:
* Как вы будете выполнять сложные вычисления на бэкенде, которые запустятся после вызова нового метода?
* Будет ли блокироваться поток обработки запроса пользователя? 
* Как вы будете тестировать свой код?
* Как поймёте, что всё работает у пользователя? А если пользователей много?
* Как устроен мониторинг работоспособности вашего метода? 
* Какие причины могут привести к проблемам работы нового метода? 
* Как правильно ограничить доступ новых пользователей к новой фиче?
* ...

За 15 минут мы можем оценить готовность кандидата пройти полноценное интервью по системному дизайну. Это интервью проводят уже наши техлиды, и там мы проверяем готовность выйти за пределы написания кода. Но и на секции по проектированию мы получаем важную информацию о навыках кандидата по проектированию и поддержке своего сервиса. Эта секция важна для оценки потенциала middle-разработчиков. А опытным senior-кандидатам мы предлагаем по итогам этой секции пройти собеседование на system design. 

На секции по проектированию мы проверяем, что кандидат:

• поддерживал и/или дежурил за свой сервис в проде;

• понимает, как диагностировать сложные проблемы и оценивать надежность;

• знает, что такое observability: логи, трейсы, метрики, алерты;

• имеет потенциал экспертизы выше senior и сможет пройти наше system design интервью.

Дополнительные темы

Joker: «See, madness, as you know, is like gravity. All it takes, is a little push!..»

Если остаётся время и кандидат готов ещё поговорить о своём опыте, то можно затронуть другие вопросы. Это может быть тема, важная для собеседующего, тогда он задаёт прицельные вопросы, чтобы вычислить кандидатов, которые «в теме». Например, понимание, как как писать и оптимизировать SQL-запросы. Или готовить k8s и писать для него операторы. Возможно, это будет глубокое погружение в системное программирование.

В дополнительное время я прошу кандидата рассказать про свой опыт, в какой-то степени это joker-тема от кандидата. Ведь он рассказывает тему, в которой считает себя экспертом. Не обязательно, чтобы собеседующий разбирался в этой теме, тут важно оценить, насколько кандидат умеет объяснять. И вдруг окажется, что именно его экспертиза нам очень нужна и мы бы про не узнали иначе.

Обсуждая дополнительные темы, мы проверяем, что кандидат:

• чем-то интересуется, а не просто пишет код по указке техлида;

• имеет экспертизу в какой-то области и знает, как там всё устроено;

• может рассказать и понятно объяснить свою тему;

• применял этот опыт в проде и осознаёт стоимость поддержки.

Обратная связь

Joker: «I believe whatever doesn't kill you simply makes you… stranger!»

По внутренней оценке, только половина всех кандидатов успешно проходит наше техническое интервью. Это хорошие показатели, и они получаются из-за качественной предварительной оценки готовности кандидата пройти интервью. До интервью опытный разработчик оценивает кандидата по итогам скрининга и резюме. Мы стараемся не тратить время кандидатов и собеседующих впустую.

Если кандидат ведёт себя адекватно на собеседовании, то ему может быть озвучена обратная связь. Это происходит в конце встречи либо через рекрутера. Были случаи, когда к нам возвращались спустя время после проработки обратной связи. Либо приходили к нам спустя полгода-год после отказа на повторное собеседование и мы им давали офер.

Что дальше

Joker: «Now... our operation is small... but there is a lot of potential... for aggressive expansion. So which of you fine gentlemen would like to join our team?»

Мы продолжаем нанимать в MWS Cloud Platform, вакансии в команду можно посмотреть на карьерном сайте MWS. Сейчас облако готовится к выходу в паблик, скоро все смогут сравнить наше облачное решение с рынком и выбрать своего дилера. Я уже его осторожно потестил в превью, и мне пока всё очень нравится по производительности и надёжности (с поправкой на превью).

На Хабре я уже писал о принципах построения Development Platform команд. Чуть позже я планирую отдельно рассказать о наших system design собеседованиях, процессе найма и перформанс-ревью. О том, как они работают вместе и дополняют друг друга. Возможно, затрону тему отличия нашего архитектурного интервью и расскажу детальнее про наши критерии оценки.

Если вы собеседовались к нам MWS Cloud Platform на разработчика и реальность оказалось не такой, то приносите мне обратную связь (комментарий, личка, телеграм). Спасибо, что прочитали, и до связи в другой раз!