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

14

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

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

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

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

epignosisx
источник
2
хорошо ясно, что роль, которую они нанимают, является одной слабостью ...
JK.
Какую позицию об этом спрашивали?
Карлсон
6
Я спрашиваю: «Что является худшей частью этой позиции?» Я также спрашиваю продавцов, что их клиенты больше всего ненавидят в своих продуктах.
JeffO
6
Если вы сформулируете это хорошо, он также скажет интервьюеру: « Я забочусь о команде, к которой я могу присоединиться, и я могу видеть за пределами своего собственного носа ».
Росс Паттерсон
1
"Какая твоя самая большая слабость?" является одним из вопросов о овсянке 6 дрянных интервью .
Крис Бурт-Браун

Ответы:

19

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

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

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

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

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

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

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

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

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

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

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

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

Angelo
источник
6

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

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

Томас Оуэнс
источник
Это тонкий способ оценить ваши навыки межличностного общения и ваш взгляд на работу в группе людей. Не уверен, что юридическое лицо будет думать о людях, которые спрашивают об этом, но определенно увидит это как вопрос обзора конца года, а не интервью.
Карлсон
Хрррм. Я написал свой ответ прежде, чем прочитал твой, но +1 за второй абзац. Я согласен с тем, что ФП лучше было бы спросить о текущей командной практике и процессах.
Рейчел
2

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

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

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

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


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

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

JB King
источник
Я согласен, что задавать этот тип вопроса сознательно HR-сотруднику было бы контрпродуктивно. Однако, если вы не знаете, что человек не может ответить на вопрос, то, скорее всего, если вы спросите его, вы обнаружите этот факт, и это многое вам скажет (например, что компания отправляет не тех людей, чтобы проводить интервью).
Йорис Тиммерманс,
1

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

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

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

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

JeffO
источник
1

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

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

Йорис Тиммерманс
источник
0

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

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

BЈовић
источник
-1 Ваш ответ подразумевает, что разработчики кодируют обезьян. Большое профессиональное программирование - это создание команды. Например, команда Scrum должна установить свои собственные правила и таким образом понимать сильные и слабые стороны команды.
Farmor
@Farmor Что за комментарий БС. Каждая команда должна установить свои правила. Плюс, если бы они знали свое самое слабое место, они бы не исправили это?
BЈовић
Я не слежу за тобой. Вы пишете: «Каждая команда должна установить свои правила». Это как раз то, что я хочу сказать, «команда Scrum должна установить свои собственные правила». Вы не согласны с этим? Также иногда вы можете знать слабое место, но не исправлять его, поскольку решения либо неизвестны, либо трудно. Например, у команды может быть проблема в том, что она однородна, но у нее проблемы с получением правильных компетенций. Я чувствую, что моей команде не хватает действительно хорошего специалиста по JavaScript, и что мы все являемся экспертами по работе с клиентами.
Farmor
@Farmor Команда без правил называется ковбойским кодированием . Конечно же, команды схваток устанавливают свои правила ( это в значительной степени подводит итог подонкам и совершенно не похоже на ковбойское кодирование). Отсутствие опыта легко исправить: наймите кого-нибудь компетентного. Некоторые команды сталкиваются с более серьезными проблемами, но они не знают, как их улучшить.
BЈовић
@Farmor - я считаю, что BЈовић просто не понимает реальную проблему с вашим ответом. Когда я читаю это, вы, похоже, пытаетесь сказать, что хороший «мягкий» вопрос может многое рассказать вам о должности, компании, интервьюере или кандидате, поэтому хорошо иметь такие в своем арсенале. а также технические вопросы.
Йорис Тиммерманс
0

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

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

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

просчеты
источник
0

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

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

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

Стивен Гросс
источник