«Нервные сотрудники мне не нужны». Tech lead с 20+ годами опыта рассказывает, как проводит собесы

Кто пишет: В этом разделе принято писать ни о том. Живу в такой-то долине, веду такой-то телеграмм канал. О себе проще. 20+ лет опыт непосредственно разработки, это всегда был embedded и различные *nix системы. Живу там, где тихо. Никаких каналов не веду. Тихо и спокойно занимаюсь парой открытых проектов помимо работы. Предпочитаю технику людям. Сейчас являюсь tech lead и senior architect. Активный участник коммьюнити dev.by, который пожелал сохранить анонимность. 

Я не HR, я не менеджер. Я не люблю людей и общение. Но на технические части собеседований таскают меня. Потому здесь я постараюсь рассказать весь процесс поиска новых сотрудников: от отсева резюме до принятия решений.

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

Очень разнообразное оборудование, с которым в области приходиться работать, и подход порой может меняться. Мы в команде работаем с C и С++. Это то, что называется true embedded. 

Мы вполне охотно берём студентов, и только закончивших в том числе. Я лично в своё время взял на работу двоих. Очень талантливые и быстро учатся. 

Какое резюме нам подойдет

Задача — отсеять неподходящих кандидатов ещё на этом этапе. Кстати, cover letter я никогда не читаю — оставьте это для HR. Но, совет молодым, — делайте направленное резюме (target resume). Так я увижу, что кандидату интересна область смежная с нашей работой

Несовместимые технологии (лучше не указывайте их в CV)

Это мнение моё, не претендует ни на что. Опыт из собственных ошибок, за которые потом пришлось отвечать.

• JavaScript и С\С++ — не совместимы.

Человек в итоге не будет знать ни то, ни другое, и постоянно путать подходы. А подходы JavaScript не работают от слова вообще. Многие компании даже делают трансляторы в C++ и потом компиляцию, просто потому что не могут найти специалистов.

• Опыт в web не совместим.

Человек понимает API как REST, и чтобы объяснить, что такое чистый TCP или UDP (не говоря уже о CAN bus), уйдёт слишком много времени. У них часто не укладывается в голове что такое raw data. Кругом json и REST. Просто трата времени. Если кандидат гипотетически попадет на проект с пользовательским интерфейсом — будут проблемы. Используя свой web подход и отдав им под самостоятельный контроль проект, мы получим крайне медлительную поделку, потребляющую кучу ресурсов. Мы занимаемся true embedded.

• Rust.

Практика показала, что пишущие на Rust — крайне токсичные люди. Постоянная беготня с нытьём, что надо срочно всё переписать на rust, иначе мы все умрём. Если вы не дружите с памятью вам, делать в отрасли нечего. И да, в true embedded ни в C ни в C++ проблем этих нет. Динамической памяти нет вообще. Хотя в C++ их вообще нет уже давно. Читайте стандарты.

Как представить свой опыт и проекты

Я не хочу читать про ваш опыт управления, я не хочу читать про DevOps, про базы данный и про то, какая у вас каша в голове. GitHub это не технология, это просто ресурс. Если мы говорим о контроле версий, то это git, не GitHub. VS code это не технология, это редактор текста, не умеющий ничего без плагинов кроме наверное подсветки синтаксиса.

Мне совершенно плевать, что вы знаете Microsoft Word. Вся эта мелочь говорит, что вы просто не знаете, что написать, и спамите своим резюме без разбора. 

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

Если вы указали какие-то проекты или работы в том же GitHub, ну, ребята, потрудитесь привести их хоть в кокой-то порядок. Я не поленюсь и зайду посмотреть. И часто видишь, когда даже в рамках одного файла разные стили.

Ну что можно сказать? Copy-paste проект? И время размещения за пару дней до отправки резюме?

Итого по резюме:

• Делайте target resume. Шансы возрастают.
• Не указывайте нерелевантные проекты, и несовместимые технологии. Нету релевантных — может это не ваше, не ваша отрасль, это нормально. 
• Потратьте время, сделайте хоть один простой домашний проект. Всякие штуки вроде arduino пачками валяются.

Легко узнаю копипаст из Stack Overflow 

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

Задания эти простые и легко находятся в Google. Мне интересно, как человек подойдёт к таким, казалось бы, совсем несложным задачам.

Встречались и такие, которые даже Google не использовали, чтобы их найти. Это, отчасти, моя цель — я знаю что их легко найти и решений куча. Начиная от стандартных и банальных, заканчивая высоко оптимизированными. Все их я знаю, могу без подсказки узнать copypaste прямо из Stack Overflow. 

Как собеседует техлид

• Пока HR и менеджер задают общие вопросы, я просматриваю решение задач.
• Нормально чего-то не знать. Призываю быть честным и не выдумывать ответы.  Иногда человек не зная начинает придумывать такую инопланетную ерунду, что собеседование превращается в «поставь диагноз этому расстройству». И с пеной из рта доказывают, что эта инопланетная технология существует.
• Я не гоняю по конструкциям языка, куче библиотек, API и т. д. Если человек понимает основы — это видно и достаточно. Остальное он найдёт.
• Не проверяю знания алгоритмов. Всё, что можно придумать, уже реализовали или как минимум можно найти. Нет смысла всё это заучивать — важно понимание.
• Если кандидат просто напутал что-то, но где-то рядом (не откровенная чушь) — это видно. В таких случаях я всегда даю правильный ответ. Так человек, мне кажется, чувствует себя спокойнее и уверенней.
• Если задание не просто copypaste, я подсказываю, какое решение будет лучше и/или проще. Кто знает, может кандидату пригодится у нас в команде, может где-то в другом месте. Пусть время собеседования будет пользой.
• Всегда спрашиваю, какой из языков программирования человек знает лучше, и начинаю с этого языка. Спрашиваю понимание основных конструкций. Только если вижу глубокое понимание, тогда начинаю спрашивать более детально.
• Задаю общие вопросы на разных уровнях: коммуникации, отладка, работа с памятью, многопоточность, сборка, операционные системы. 
• Все вопросы начинаются от основ, нет основ — пропускаю тему. Углубляемся в детали если есть, что спрашивать.

Заключение

Просто пара тезисов, которые помогли бы успешно пройти собеседование у нас в компании.

1. Target resume. 
2. Хоть какие-то релевантные проекты.
3. Не поленитесь взять нужное вам время и подумать над простыми задачами. Не делайте copy-paste
4. Не выдумывайте, будьте честны если чего-то не знаете.

Мнение автора может не совпадать с мнением редакции. 

Вы потратили на этот материал две минуты. Потратьте ещё 15 секунд, пожалуйста.

dev.by, как и другим честным медиа, сегодня очень сложно: редакция работает за пределами страны, а наши рекламные доходы сократились в несколько раз.Но мы справляемся — с вашей помощью.

Это вы делитесь с нами инфоповодами, мнениями, опытом, временем и вниманием. А 170 читателей поддерживают нас донатами. В 2023 году мы хотим собрать 1000 читателей-подписчиков.  Помочь нам можно через Patreon. Сейчас средний чек — около 10$, но мы рады любой сумме.  В Беларуси Patreon заблокирован. Мы будем добавлять другие способы.

Спасибо, что прочитали это сообщение.

Вы тоже можете начать вести свой блог на dev.by — вот инструкция. Или присылайте темы, идеи и вопросы на blog@dev.by. 

Что ещё почитать: 

• «Это не райское место». Программистка хотела вернуться в IT, но передумала. Рассказала, почему
• Особенности работы на аутсорс и продуктовую компанию. На примере EPAM, Softeq, Yandex и Glovo
• Мотивируй, объясняй и защищай. 4 совета, как построить отношения с командой