Слабые стороны на собеседовании: что отвечать в IT

Вопрос про слабые стороны обычно задают в паре с сильными, ближе к концу скрининга или на финале. В банке Sobes он записан так, как звучит в жизни: «Какие у тебя сильные и слабые стороны (софтовые)? Что стремишься прокачать?», «Назовите свои сильные и слабые стороны». Первую формулировку открывали больше 3 000 раз: готовятся к нему многие, хотя спрашивают его реже, чем про зарплату или причину ухода.

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

Что на самом деле проверяют

Список ваших недостатков интервьюеру не нужен. Он смотрит на три вещи:

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

Вторая часть вопроса в формулировке из банка, «что стремишься прокачать», прямо подсказывает, чего ждут: план, а не исповедь.

Почему «перфекционист» не работает

Это достоинство, переодетое в недостаток, и это видно. Ответ не даёт интервьюеру никакой информации и заодно показывает, что вы уклонились от вопроса. Если перфекционизм вам действительно мешает, скажите, как именно: «затягиваю ревью, потому что цепляюсь к мелочам». Это уже настоящая слабость, и с ней можно работать по формуле ниже.

Формула ответа

Три части, секунд сорок:

Реальная слабость, названная конкретно. Лучше поведение, чем черта характера: «занижаю оценки сроков», а не «я оптимист».
Что вы с ней делаете. Приём, привычка, договорённость с командой.
Как она проявляется сейчас. Честно: стало лучше, но до конца не ушло.

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

Пять примеров

Оценка сроков

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

Работает, потому что проблема знакома любому руководителю, а приём конкретный и проверяемый.

Публичные выступления

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

Для разработчика эта слабость не критична, а готовность тренировать неприятное выглядит хорошо.

Делегирование

Мне проще сделать самому, чем объяснить. Когда я стал вести команду из четырёх человек, это быстро превратилось в проблему: я был узким местом. Сейчас задачи, которые я могу сделать за два часа, а коллега за день, намеренно отдаю коллеге и смотрю только результат на ревью. Рука к клавиатуре всё ещё тянется, особенно когда горят сроки.

Ответ для тимлида или senior, который двигается к руководству. Подробнее о том, чего ждут на таких интервью, в статье про собеседование на тимлида.

Глубина против скорости

Я люблю докапываться до причины и могу потратить полдня на то, что не влияет на задачу. Теперь ставлю себе лимит: час на исследование, потом пишу в чат, что нашёл, и спрашиваю, стоит ли копать дальше. В половине случаев отвечают, что не стоит.

Обратная версия тоже честная: «быстро делаю и иногда пропускаю граничные случаи, поэтому перед отправкой на ревью прохожу по собственному чек-листу».

Документация

Я плохо документирую. Задачу закрыл, а описание решения остаётся у меня в голове, и через полгода коллеги приходят с вопросами. Договорился с командой, что без короткого описания в задаче мердж не делаем. Для своих задач правило соблюдаю, большие архитектурные документы всё ещё пишу с опозданием.

Правило, о котором вы договорились с командой, сильнее обещания «стараюсь исправиться».

Чего не называть

Слабость, без которой роль невозможна. Тестировщик, который «невнимателен к деталям», или аналитик, которому «трудно общаться с людьми», сам снял свою кандидатуру.
Черты, которые читаются как конфликтность: «не терплю глупых людей», «говорю всё прямо в лицо».
Чужие недостатки под видом своих: «слишком многого жду от коллег».
Технический пробел в стеке вакансии. Это слабость другого рода, о ней и так узнают на техническом этапе. А вот «в Kubernetes я пользователь, а не администратор» на вопрос про то, что хотите прокачать, подходит.
Ничего. «Не знаю, вроде нет слабых сторон» хуже любого примера из списка выше.

Если спросят «а ещё?»

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

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

Откройте последние ретро, ревью или отзывы руководителя и выпишите то, что вам говорили больше одного раза. Это и есть ваш материал, выдумывать ничего не придётся. Если на собеседованиях вы пользовались Sobes Copilot, загляните в экран «Прогресс»: там видны темы, которые оценены как слабые в двух и более разборах.

Выберите две слабости, для каждой запишите три фразы по формуле и произнесите вслух. Затем проверьте в разговоре: пройдите мок-интервью в HR-режиме и дайте этот ответ в одной сессии с рассказом о себе. Хорошо, когда они друг другу не противоречат.