Считается, что собеседования предназначены для выбора подходящих кандидатов на должность. Соответственно, технические собеседования, предположительно, нужны для оценки кандидатов на технические роли.

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

Я считаю, что это должно быть важно для вас, ведь вы, вероятно, отфильтровываете кандидатов, которые могли лучше подойти под ваши требования. Кандидатов, которые соответствуют реальной должности и повседневной работе на ней. К тому же вы, вероятно, впустую тратите на это лишние ресурсы (время и усилия).

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

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

▍ Важное признание

Должен сознаться: я ужасно справляюсь с техническими собеседованиями.

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

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

^{Примечание: я не работал в самых крупных организациях. Большие масштабы проектов относительны к размеру организации, где я трудился. Поэтому должен признать, что масштаб и влияние инженера-управленца в компании из 800 человек сильно отличается от масштабов в компании из десяти тысяч человек. Тем не менее, я считаю, что в целом представленные в статье утверждения сохраняют свою истинность, потому что в конечном итоге проблема не в инструменте, а в том, как его применяют.}

Вы можете спросить у любой команды, в которой я был или которой руководил, у любого инженера, с которым я работал, или у любого моего руководителя: все они скажут, что мои технические знания обширнее, чем говорится в статье. (А затем они, вероятно, посочувствуют мне из-за синдрома самозванца.)

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

Это очень маловероятно.

Так почему же я так плохо проявлял себя на технических собеседованиях? Да, разумеется, я испытываю стресс, но это не объясняет, почему я так сильно на них проваливаюсь.

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

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

Давайте попробуем ответить на этот вопрос.

▍ Паралич анализа

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

Первая и менее важная причина заключается в том, что мои навыки не исключительно технические. Я не тот человек, который решает задачи только ради их решения. Я решаю задачи для своей команды, наших клиентов (внутренних или внешних) и/или для организации.

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

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

Да, я использовал для решения технологию X, алгоритмы Y или даже структуры данных Z. Но всё это появлялось по ходу дела. У меня никогда не было такой ситуации, и я никогда не слышал о таких ситуациях, чтобы кому-то в реальности приходилось реализовывать решение из префиксного дерева и поиска за O(n) в рамках тридцати минут.

На самом деле, мне постоянно приходится сталкиваться со следующими задачами:

• Необходимость лавировать между давлением в организации, взаимосвязями и динамикой движения команды.
• Упрямое выявление и устранение сложновоспроизводимых багов.
• Бенчмаркинг/решение проблем производительности и масштабируемости.
• Работа с продуктовыми и дизайнерскими командами над своевременными релизами.
• Использование ресурсов для накапливания понимания и наблюдений.
• Асинхронное общение через разные каналы коммуникации, документацию и код, чтобы избежать изолированности.
• Поддержка, менторство и руководство.
• Создание issue, отстаивание необходимости их решения и обеспечение планирования этого.

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

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

Но ведь годы опыта и навыки должны же мне помочь справляться с какими-то простыми техническими задачами, ведь так?

Ну… и да, и нет. Давайте поговорим о второй проблеме, чтобы разобраться, почему всё не так просто.

▍ Сложности собеседований

Самые часто встречающиеся типы технических собеседований:

• Оценка кодинга (иными словами, leetcode).
  По сути, функциональная викторина. Кандидатам даётся функциональная задача, и они должны выработать идеальное решение. Это задача live-кодинга.
• Разработка приложения.
  Похожа на оценку кодинга, однако такие задачи более стилистические по своей природе. Задача заключается в создании простого приложения или компонента. Это может быть задача live-кодинга или задание на дом.
• Проектирование систем.
  Самый расплывчатый тип. Кандидатов просят порассуждать на высоком уровне, как бы они создавали и проектировали какой-то популярный сервис, приложение или компонент. Часто они должны рисовать какие-то диаграммы на белой доске (цифровой или аналоговой).

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

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

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

Мне кажется, подобное «испытание огнём» имеет смысл, если ваша организация — одна из тех, где разработчики находятся под постоянным давлением и где поддерживается культура «сделай или умри». Если же это не так, то подумайте о разнице между ответами на вопросы викторины с друзьями и ответами на те же вопросы в условиях соревнования с другими участниками в прямом эфире игрового телешоу. А, да, и приз за игру — это ваша должность.

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

Также нужно учесть и ещё один аспект. Как насчёт разницы между кандидатами, уже встречавшими эту задачу викторины, и теми, кто ещё её не встречал? Если смысл не просто в выполнении задачи и вы хотите оценить только их навык решения задач, то не оцените ли вы быстро решившего её человека выше, чем того, кто решил её с трудом? Это значит, что у вас возник перекос в сторону того, кто СЛУЧАЙНО имел дело с этой задачей (или запомнил её). Более того, с большой долей вероятности это не даст вам никаких качественных данных о пригодности кандидата к работе.

Но как говорилось выше, тревожность и опыт (или его отсутствие) — не единственные причины плохого проявления моих навыков.

▍ Вдалеке слышится слабый сигнал!

Давайте рассмотрим, какой сигнал организации могут получить от этих собеседований.

На мой взгляд, практически никакого полезного.

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

Допустим, люди запоминают всё это, но ведь в этом нет ничего особо плохого? Согласен, само по себе это неплохо. Знания — это здорово! Всегда стоит стремиться получать их.

Однако цель собеседований — оценить кандидатов на соответствие должности. Должности, на которой они будут достигать результатов, а не решать отдельную пограничную часть задач этой должности.

^{Примечание: часто я задаюсь вопросом, не потому ли организации оказываются такими чрезмерно усложнёнными системами, когда достаточно было бы более простых. Если попадающие на должности кандидаты имеют сильный стимул в основном делать упор на мелкие детали, то, вероятно, они с большей вероятностью будут реализовывать сложность, не задумываясь о её необходимости и том, действительно ли смогут команды/организации поддерживать такие системы.}

Я читал о компаниях и работал в таких организациях, которые раздают подготовительные материалы к своим собеседованиям. Как же так? Разве многих лет опыта недостаточно для подготовки? Я готовлюсь к должности или к самому собеседованию? Зачем мне нужна специальная подготовка… к собеседованию? Может, стоит задаться вопросом, а не оцениваем ли мы что-то не то?

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

▍ Виртуальный мир

В реальной ситуации истинны многие из этих пунктов, если не все из них:

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

И, что самое важное: над какими такими задачами люди работают, чтобы от них ожидали решения за 30-40 минут (с учётом вводной части и подготовки)? Исправление опечаток? Возможно, выполнение анализа первопричин вот в таком коде?

should_crash_system = True
if should_crash_system:
  crash_system()

В реальном мире у разработчиков есть время на обдумывание задачи, её проработку, а затем совершенствование решения. Это чем-то похоже на написание текстов. Вы создаёте примерный план, редактируете и совершенствуете черновики, а потом полируете текст перед публикацией. Разработчики обычно выпускают усовершенствованную версию, а не заготовку «лишь бы заработало». Исключением может быть парное программирование или метод утёнка, когда процесс больше становится групповым.

Условия собеседования не дают ни этого пространства, ни времени, ни, будем уж реалистами, безопасности.

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

Да, иногда бывает так, что вы приходите на совещание руководителей и с ходу должны ответить на новый запрос. Я бывал на многих таких совещаниях с директорами, вице-президентами и даже с высшим руководством. И мне никогда не приходилось выдавать план или что-то большее, чем возможное «да»/«нет», приблизительные сроки (X месяцев) или оценка сложности, ну и, может быть, грубая оценка требований к команде (X инженеров). На таких совещаниях мы говорим и общаемся максимум по пять минут.

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

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

Ладно, с этим мы разобрались, давайте вернёмся к разбору разных типов собеседований.

▍ Подробный разбор

Оценка кодинга

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

Есть вероятность, что на своей должности вы не сталкиваетесь с этим регулярно. Поэтому подобные задачи на собеседованиях хороши, если вы хотите найти человека на должность, где алгоритмы и структуры данных являются критически важным знанием. Например, это может быть ключевой член команды, работающий с глубокими вопросами производительности при создании какого-то сложного движка или крупномасштабного решения. Такая должность, кандидат на которую на самом деле будет регулярно (50%+ времени?) глубоко анализировать, реализовывать и создавать структуры данных/алгоритмы. Но если это так, то вам, наверно, стоит провести целый набор проверок, а не только одну.

Ещё одна ситуация, в которой могут использоваться подобные типы интервью — это отбор только что выпустившихся студентов (колледжей или буткемпов), а также позиции стажёра/джуна/мида нижнего уровня. Причина в том, что в этом случае ни за что другое практически невозможно зацепиться. От кандидатов на такие должности ожидается почти полное отсутствие опыта, поэтому необходимо проводить некую проверку знаний.

Разработка приложения

Проблема с задачами на разработку приложения заключается в том, что часто они начинаются с чистого листа. На реальной же работе разработчики обычно не тратят свой день на создание проекта целиком. Кроме того, некоторым немного сложно заинтересоваться задачей, не имеющей практически никакой ценности. Разработчиков часто увлекает решение задач или релиз для какой-то конечной стороны (команды/организации/пользователей и так далее). Однако в этом случае и собеседующий, и собеседуемый знают, что это работа на выброс. Худшие в мире условия для хакатона!

Тем не менее, у таких собеседований тоже есть свой способ применения. Такие задачи на написание приложений, вероятно, хороши, если вы нанимаете разработчиков для прототипирования/проектов R&D. Это должности, на которых разработчики должны регулярно доводить проекты с 0 до 1. Важно уточнить, что я не имею в виду стартапы. Стартап с большей вероятностью выпустит приложение один раз, а не через каждый спринт.

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

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

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

Однако, по сути, мы говорим о проектировании архитектуры систем. В наличии архитектурных навыков, разумеется, нет ничего плохого. Но сегодня практически в любом цикле собеседований есть раунд того или иного проектирования систем. Мы что, действительно ожидаем, что ВСЕ будут архитекторами? Кроме того, большинство задач на собеседованиях по проектированию систем связаны с фулстек-задачами, имеющими большой масштаб. Не поймите меня неправильно, я сам хочу, чтобы даже мид-разработчики думали о том, как их изменения могут повлиять на производительность, стабильность, масштабируемость и расширяемость системы. Однако, судя по этой тенденции проведения собеседований, мы теперь утверждаем, что каждый член команды должен уметь решать архитектурные проблемы фулстека, и это настолько важно, что по этому критерию нужно отсекать кандидатов?

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

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

Уверен, что последний абзац может вызвать недоумение. Попробую объяснить.

Для начала вспомним, что мы обсуждаем собеседования. Также стоит помнить, что я могу поискать информацию о том, как компания Y создала крупномасштабную систему. Я могу запомнить принцип и повторить его вам. Это справедливо для любого выпускника или того, кто только что сдавал экзамены.

Тем не менее, даже если выпускник медицинского знает процедуру, это ещё не делает его врачом. Ему всё равно нужен личный опыт. Он должен столкнуться с ситуациями из реального мира.

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

▍ Истина

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

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

По моему мнению, реальная проблема технических собеседований заключается в следующем:

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

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

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

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

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

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

Что же можно придумать вместо этого?

Лично я знаю тот вклад, который делал в организациях. И ещё я знаю, что только пару раз я проходил дальше технических собеседований благодаря удаче или доброте собеседующего.

^{Забавная история: я участвовал в последнем техническом собеседовании на должность, предполагавшую работу с NodeJS. После вводной беседы проводящий собеседование сказал, что он разработчик на GoLang, а потому практически никак не сможет оценить мои знания. Я отметил, что мне нравится его футболка с названием музыкальной группы, и в результате мы час проболтали о музыке. Я получил работу и принёс большую пользу этой компании.}

Именно поэтому я так сильно настроен против них и говорю об этом, когда представляется возможность.

Стоит понимать, что такие собеседования начали проводить, потому что на них, якобы, сложно «имитировать» результаты. Я считаю, что это не совсем так. Если у вас есть время, терпение и хорошая память, то имитировать знание не так уж трудно.

Лично я получаю более качественный сигнал от собеседований в виде свободного общения или STAR (situation, task, action, result, то есть клишированных «расскажите, что вы делали, когда...»). Подобные собеседования не очень высоко ценятся, потому что кандидаты могут заранее подготовиться к таким вопросам. Что, как мы знаем, невозможно в случае более современных технических собеседований ;)

Однако подобные типы собеседований могут быть невероятно ценными, если собеседующий обладает большой широтой знаний. Я был свидетелем того, как проводящие собеседование задавали глубокие вопросы о сделанном выборе и о том, знает ли кандидат об X, или что могло произойти, если Y.

Ещё важнее то, что разговорные собеседования обычно шире охватывают soft skills. Они начинаются как беседа, доходят до технических подробностей, а затем переходят к более широким вопросам личных умений. Хм, странно, ведь это очень похоже на то, как обычно и работают инженеры.

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

^{Примечание: мне бы хотелось также упомянуть идею о том, что кандидаты должны подготавливать полномасштабную презентацию. Учитывая нестабильность в отрасли, увольнения и тому подобное, люди любую должность со стабильной зарплатой. Помните, что они, возможно, ищут не только должность, на которую подали резюме в вашу организацию, и у них может и не быть свободного времени для создания презентации. В идеале стоит задавать вопросы типа «расскажите о проекте, где...», а не просить «презентовать проект».}

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

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

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

Как это выглядит?

Собеседования на все должности состоят из 3-4 раундов.

• Менеджер по найму — общее представление того, что имеет кандидат, на что он делает упор и насколько он может влиться в команду.
• Проверка на соответствие команде — способ работы кандидата, больше специфики относительно технологий и повседневного исполнения задач.
• Конкретно по должности:
  
  • Джуниор: «простая» задача на кодинг, которую должны уметь выполнить кандидаты.
  • Мид: кандидату даётся имитация проекта и его просят добавить фичу X.
    ИЛИ кандидату дают имитацию фичи, которую отправили на ревью и которую ему нужно покритиковать.
  • Сеньор: глубокое погружение/презентация проекта.
  • Инженер-управленец: проектирование системы или глубокое погружение/презентация.
  • Ведущий инженер: проектирование системы.
• Дополнительно: часто это собеседование со стороны соседней команды, чтобы получить «внешне», менее подверженное искажениям мнение.
  
  • Сюда можно добавить также собеседование конкретно по должности; часто используется для вакансий уровня управленцев и выше

▍ А что насчёт меня?

Я знаю, что плохо справляюсь с техническими собеседованиями.

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

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

Telegram-канал со скидками, розыгрышами призов и новостями IT 💻