Чи погана ідея запитати інтерв'юера, яка найбільша сила та слабкість у їхньої команди розробників? [зачинено]

Мені було цікаво, чи це гарне запитання, щоб задати можливого роботодавця під час співбесіди на посаду розробника:

Яка найбільша сила та слабкість у вашій команді розробників?

У нас у всіх виникає це питання, коли ми опитуємось на інтерв'ю, то чому б не поставити їм взамін? Я думаю, що це дуже гарне питання, оскільки ми могли дізнатися про команду, і як ця сила чи слабкість можуть вплинути на нас, але я не хочу дратувати інтерв'юера.

Чи є якийсь мінус задавати це питання під час співбесіди на посаду розробника?

Це не погане питання, однак я особисто не ставлю це так.

Я б спершу розпитав команду розвитку та їхні процеси, а сам спробував підібрати те, що є сильним і слабким. Важко задати гарний набір запитань, оскільки вони будуть різними залежно від наданих відповідей, якої посади ви претендуєте та що найбільше цінуєте в команді розробників.

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

Не фразуйте це так. Усі ненавидять фальшиве (сильне та слабке) питання "ІМХО". Немає необхідності повертати його та використовувати знову.

Набагато кращими та достовірнішими питаннями, які дістаються до тієї самої інформації, були б такі:

• Розкажіть про історію вашої команди, як ви розпочали роботу, звідки взялися члени команди? Куди поїхали попередні члени команди, коли виїхали?

• Чому ви хочете заповнити позицію x?

• Які найскладніші виклики, з якими ви зіткнулися з вашою командою, працюєте тут?

• Чи можете ви пройти мене по життєвому циклу проекту, над яким працювала ця команда? Як це почалося і закінчилося? Які стосунки команди до зацікавлених сторін, тестерів (якщо такі є), операторів (якщо такі є) та обслуговування?

• Коли справи йдуть не так, як реагує ваша команда? Чи можете ви сказати мені про останню / поточну / найбільшу кризу?

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

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

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

Так, у цьому питанні є декілька недоліків. Перш за все, наскільки добре людина, яку ви запитуєте, насправді має можливість відповісти на це питання? Якщо ви запитуєте когось із HR в цьому питанні, вони можуть мати мало уявлення про те, що тут є законною відповіддю. Навіть керівник може не знати, чи є команда відносно новою, і все не так відоме з точки зору соціальної динаміки та вдосконалення справ. Інша сторона полягає в тому, наскільки ви готові до мовної гімнастики, можливо, ви починаєте з цього питання, оскільки є більше, ніж невелика ймовірність того, що будь-яка відповідь буде навантажена модними словами або розпливчастою, що вона має мало значення, якщо ви не знаєте, як слідкувати. з деякими важчими питаннями. Наприклад, якщо вони стверджують, що вони співпрацюють і добре допомагають, чи готові ви далі допитуватися?

З іншого боку, я б більше спокуси попросити трохи історії команди:

• Скільки часу ця команда була разом?
• У кого тут багато років?
• Які ролі зазвичай грають різні люди?

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

Коментар про те, щоб запитати це людині, не знаючи, наскільки добре вони відповідають, потрапляє у ті "мовні гімнастики", які я згадую вище, оскільки я легко передбачу, що хтось заявив щось подібне: "Ми наймаємо тут тільки найкраще" або щось інше, що є котловиною для відповіді, яка потребує певного дослідження, щоб знайти відповідь, це просто хтось, хто намагається бути ввічливим, а не пропонувати точну відповідь. Ще однією загальною відповіддю було б те, що "всі так добре поживаються", що можна було б замислитися, чи є приховані бойові дії чи справді команда куча зрілих людей, які добре працюють разом.

Замість того, щоб просити слабкість, я б повторно поставив питання: "Який найбільший виклик вашої команди розвитку?" так що це не сприймається тим, що хтось навмисно намагається розпалити неприємності, а скоріше намагатися отримати деяке розуміння того, як бачать команду.

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

Якщо вони вважають це образливим чи не відчувають, що вам належить задавати такі питання, ви можете не хотіти роботи. Будь-яка відраза до питання може бути ознакою невпевненості або хоча б поганого спілкування.

Особисто мені подобаються люди, які нападають на проблеми, тому що вони бажають їх розпізнати (Хіба це не крок 1 з 12?).

Часто виникають проблеми, що не відповідають контролю лідера: бюджет, застарілий код, чисельність персоналу, хороші люди залишають на високооплачувану роботу, характер роботи означає, що розробникам доводиться розміщувати членів команди в різних часових поясах, вищий менеджмент має деякі Схильності мікроменеджменту, політика на рівні компанії, наприклад, дрес-код, робочий час тощо.

Одне з моїх питань щодо мого майбутнього роботодавця - "чому ти любиш працювати для своєї компанії?"

Він спрямований на отримання однотипної інформації, але позитивно та оптимістично. У великих місцях для роботи ви побачите, що часто ваш інтерв'юер починає хлипати всілякі чудові відомості, які ви дійсно хочете знати, щоб прийняти своє рішення!

Я вважаю це дійсно дивним питанням. Якої відповіді чи інформації ви очікували?

Якщо ви подаєте заявку на посаду з розробки, я би розраховував, що ви поцікавитесь більше про технічні аспекти. Як, наприклад, "які методології ви використовуєте?", "Які інструменти ви використовуєте?" Тощо.

Запитувати команди про свою думку про себе це не є настільки розмовним, як питання про те, як їх реакція на події призвела до результату. Цей тип запитань відомий як поведінкові запитання , і ґрунтуються на ідеї, що минула поведінка є найкращим прогнозувачем майбутньої поведінки.

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

Наприклад, "З моменту вступу в команду, що було найбільшим успіхом команди, що створило можливість для неї, які дії команди мали найбільший вплив на те, щоб це відбулося, і який був ефект від цього успіху на компанії?"

Я думаю, що це чудове запитання, хоча я б його задав трохи інакше. Раніше я задавав такі питання, як:

• Які найбільші технічні проблеми у вашому магазині?
• Яким є діапазон / поширення у наборах навичок серед вашої команди?
• Скільки проблем викликає силос у вашому магазині?

Ці питання допомагають вам опосередковано розкривати інформацію про те, як працює команда. Технічні виклики розкривають ставлення колективу до (нових) технологій. Набір діапазонів умінь виявляє професійну основу колективу. Силонг ​​розкриває проблеми власності коду та его.