Это плохая идея спросить интервьюера, какова самая сильная и слабая сторона их команды разработчиков? [закрыто]

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

Какова самая сильная и слабая сторона вашей команды разработчиков?

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

Есть ли какой-либо недостаток в том, чтобы задавать этот вопрос при собеседовании на должность разработчика?

Это неплохой вопрос, однако я бы не стал так его формулировать.

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

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

Не формулируйте это так. Все ненавидят фальшивый (ИМХО) вопрос «о сильных и слабых сторонах». Нет необходимости переворачивать его и использовать снова.

Гораздо лучше и более достоверные вопросы, которые получают ту же информацию, будут следующие:

• Расскажите мне об истории вашей команды, как вы начали, откуда пришли члены команды? Куда делись предыдущие члены команды, когда они уходили?

• Почему вы ищете, чтобы заполнить позицию х?

• С какими трудностями вы и ваша команда сталкиваетесь при работе?

• Можете ли вы рассказать мне о жизненном цикле проекта, над которым работала эта команда? Как это началось и закончилось? Каковы отношения команды с заинтересованными сторонами, тестировщиками (если есть), оперативными работниками (если есть) и техническим обслуживанием?

• Когда дела идут плохо, как реагирует ваша команда? Можете ли вы рассказать мне о последнем / текущем / самом большом кризисе?

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

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

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

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

С другой стороны, я бы больше хотел спросить немного истории команды:

• Как долго эта команда была вместе?
• У кого сколько лет здесь?
• Какие роли обычно играют разные люди?

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

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

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

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

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

Лично мне нравятся люди, которые нападают на проблемы, потому что они хотят их узнать (разве это не шаг 1 из 12?).

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

Один из моих вопросов для моего будущего работодателя: «Почему ты любишь работать в своей компании?»

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

Я нахожу это действительно странным вопросом. Какой ответ или информацию вы ожидаете?

Если вы подаете заявку на должность разработчика, я ожидаю, что вы спросите больше о технических аспектах. Как, например, «какие методологии вы используете?», «Какие инструменты вы используете?» И т. Д.

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

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

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

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

• Каковы основные технические проблемы в вашем магазине?
• Каков диапазон / распространение навыков в вашей команде?
• Насколько большая проблема в вашем магазине?

Эти вопросы помогают вам косвенно раскрыть информацию о том, как работает команда. Технические проблемы раскрывают отношение команды к (новым) технологиям. Range-in-skillsets раскрывает профессиональный опыт в команде. Элевация раскрывает проблемы владения кодом и эго.