Мда, а потом внезапно таким образом оказывается, что либо дальше двигаться долго и мучительно, и команда разбегается от такого франкинштейна, или каждый релиз приносит кучу багов, и уже клиенты разбегаются. Но вариант когда разбегаются и те и другие гораздо более реалистичный.
Вот тут написано про «токсичные» вопросы. И даже предположить не постарались, что эти вопросы для чего то задаются. Может вопрос для отвлечения внимания, чтоб проверить концентрацию? Может действительно им вот сейчас надо 20 Пб из одного цода в другой перегнать (и у них пока лучшая идея сделать это на грузовике)? Может опыт команды говорит, что следуя принципам SOLID действительно код получается лучше?
В статье сразу делается предположения, что (1) вопросы глупые и (2) задавать их не нужно. Если эти предположения поставить под сомнения, то и выводы получатся не такие.
В целом, смотреть, как там собеседуют в чужом болоте, конечно полезно. Но если это делать вот с такими установками, то ни чего хорошего из этого не выйдет. Скорее всего вывод будет — я один тут Д'Артаньян.
Ну не совсем.
Даже в советские времена дельные рац. предложения от рядовых сотрудников принимали.
Другое дело, что предложения должны быть «рац.» А они не всегда такие.
Какая-то однобокая статья. Из-за чего складывается двойственное чувство. Вроде, написано всё по делу, и надо срочно брать на вооружение. С другой стороны раскрыт вопрос только с точки зрения разработчиков.
Ну хорошо, обсуждать будем. Был у меня сотрудник, который тратил по 4 часа времени своего руководителя на пропихивание гениальных идей. Некоторые были очевидными и обсосанными командой со всех сторон. Но 99% были не жизнеспособны. На некоторых мы сильно обожглись. Но даже объективное тестирование ему не помогало, и он продолжал стоять на своём. Вот если б он от нас не ушёл, мне надо было бы извинение у него просить, что я к нему не прислушивался? И, что ещё важнее, после траты моего времени на один рабочий месяц мне надо было бы прислушиваться к его идеям?
Ok. А идеи переписать всё на язык X надо обсуждать? А если у нас разработчиков на этом языке нет вообще? Или можно просто сказать: «Чувак, у нас на X пишешь, только ты. А только вот в этом модуле 100500 строк. Мы переписывать не будем, т.к. долго и дорого»?
По моему, было бы клёво, если б разработчик, до того как произнесёт своё предложение, немного его обдумал. Как он сам это делать собирается.
Одним словом, истина оказалась не в крайностях.
Может дело в ценовой планке, может в том, что автор руководит в основном управленцами, но…
По моему опыту hard skills довольно хороший показатель. Работник с высокими hard skills имеет и высокие soft skills.
Ну возьмём даже пример, надо придумать алгоритм частного случая np-полной задачи. Тот у кого есть понимание сможет довольно веско аргументировать свою позицию. У кого понимания нет будет гнать предлагать долгое решение и отстоять его не сможет.
В статье сразу делается предположения, что (1) вопросы глупые и (2) задавать их не нужно. Если эти предположения поставить под сомнения, то и выводы получатся не такие.
В целом, смотреть, как там собеседуют в чужом болоте, конечно полезно. Но если это делать вот с такими установками, то ни чего хорошего из этого не выйдет. Скорее всего вывод будет — я один тут Д'Артаньян.
Даже в советские времена дельные рац. предложения от рядовых сотрудников принимали.
Другое дело, что предложения должны быть «рац.» А они не всегда такие.
Ну хорошо, обсуждать будем. Был у меня сотрудник, который тратил по 4 часа времени своего руководителя на пропихивание гениальных идей. Некоторые были очевидными и обсосанными командой со всех сторон. Но 99% были не жизнеспособны. На некоторых мы сильно обожглись. Но даже объективное тестирование ему не помогало, и он продолжал стоять на своём. Вот если б он от нас не ушёл, мне надо было бы извинение у него просить, что я к нему не прислушивался? И, что ещё важнее, после траты моего времени на один рабочий месяц мне надо было бы прислушиваться к его идеям?
Ok. А идеи переписать всё на язык X надо обсуждать? А если у нас разработчиков на этом языке нет вообще? Или можно просто сказать: «Чувак, у нас на X пишешь, только ты. А только вот в этом модуле 100500 строк. Мы переписывать не будем, т.к. долго и дорого»?
По моему, было бы клёво, если б разработчик, до того как произнесёт своё предложение, немного его обдумал. Как он сам это делать собирается.
Одним словом, истина оказалась не в крайностях.
По моему опыту hard skills довольно хороший показатель. Работник с высокими hard skills имеет и высокие soft skills.
Ну возьмём даже пример, надо придумать алгоритм частного случая np-полной задачи. Тот у кого есть понимание сможет довольно веско аргументировать свою позицию. У кого понимания нет будет гнать предлагать долгое решение и отстоять его не сможет.