📛 Собеседование не гарантирует найм хорошего программиста
По большому счету собеседование не гарантирует вообще ничего.
Даже в компаниях, известных своими сложными интервью, не будем показывать пальцем, не все кандидаты проходят испытательный срок.
Я не знаю статистики, но вот случай из жизни.
🙇♂️ К нам в команду взяли нового разработчика. Он успешно прошел все собеседования, и так же успешно был уволен на третьем месяце работы.
Судя по т ому то он рассказывал на стендапах он не делала вообще ничего.
🎭 Другой показательный пример был на предыдущей работе. Мы побеседовали чувака, на собеседование он очень живо отвечал на вопросы. Рассказывал как он решал похожие задачи в прошлом. Живо интересовался проектом, рассказывал как бы и что он реализовал. И все было так складно, что он всем понравился и его взяли.
Но буквально через пару месяцев его было не узнать. Он делал все как-то натужно, очень долго и безынициативно. На словах все было неплохо, но код писался крайне медленно.
Казалось, что на собеседование был один человек, а на работу вышел другой.
Я думаю, что чувак просто выгорел, и ему все надоело. На собеседовании, в стрессовой ситуации, он был бодр, а когда стресс прошел, желание работать так же ушло.
😒 Другой пример случился совсем недавно на одном из собеседований, которые я проводил. Претендент очень лихо отвечал на вопросы, решал задачи достаточно быстро, и вообще выглядел достойно.
Единственное, я заметил, что в любой непонятной ситуации он смотрит налево, видимо там был второй монитор. Ну вы понимаете к чему я клоню...
Тогда я на одной из задач решил его запутать. Сказал, что его рабочее решение неверно и попросил объяснить как это работает...
В резюме соискателя я так и написал, что чувак все решил, но объяснить решение задач не может.
Все эти случаи показывают, что собеседование достаточно мало говорит о кандидате. Я уже молчу, что часто сами собеседования проверяют вещи, которые не нужны в работе.
Проще всего собеседовать Джуниоров и Мидлов. Поскольку у них проверяют технические знания. И они либо есть, либо их нет. Но чем старше тем сложнее.
Именно поэтому мне нравится идея разговорных собеседований. Да, такие собеседования сложно стандартизировать, что может быть проблемой для больших компаний. Зато ничего лучше разговора не покажет, насколько человек глубоко понимает предмет о котором говорит, и самое главное насколько вам будет комфортно работать вместе.
Да, моно ошибиться и уже во время работы понять, что человек не подошел. Но как показал мой опыт, никакой из способов не дает гарантию от этого.
Именно поэтому я всеми конечностями голосую за разговорные собеседования, да их может быть много, но только так можно понять, впишется ли человек в команду или нет.
А что думаешь ты про собеседования с кодом, про устные собеседования? Расскажи про свой опыт собеседований как с одной, так и с другой стороны.
По большому счету собеседование не гарантирует вообще ничего.
Даже в компаниях, известных своими сложными интервью, не будем показывать пальцем, не все кандидаты проходят испытательный срок.
Я не знаю статистики, но вот случай из жизни.
🙇♂️ К нам в команду взяли нового разработчика. Он успешно прошел все собеседования, и так же успешно был уволен на третьем месяце работы.
Судя по т ому то он рассказывал на стендапах он не делала вообще ничего.
🎭 Другой показательный пример был на предыдущей работе. Мы побеседовали чувака, на собеседование он очень живо отвечал на вопросы. Рассказывал как он решал похожие задачи в прошлом. Живо интересовался проектом, рассказывал как бы и что он реализовал. И все было так складно, что он всем понравился и его взяли.
Но буквально через пару месяцев его было не узнать. Он делал все как-то натужно, очень долго и безынициативно. На словах все было неплохо, но код писался крайне медленно.
Казалось, что на собеседование был один человек, а на работу вышел другой.
Я думаю, что чувак просто выгорел, и ему все надоело. На собеседовании, в стрессовой ситуации, он был бодр, а когда стресс прошел, желание работать так же ушло.
😒 Другой пример случился совсем недавно на одном из собеседований, которые я проводил. Претендент очень лихо отвечал на вопросы, решал задачи достаточно быстро, и вообще выглядел достойно.
Единственное, я заметил, что в любой непонятной ситуации он смотрит налево, видимо там был второй монитор. Ну вы понимаете к чему я клоню...
Тогда я на одной из задач решил его запутать. Сказал, что его рабочее решение неверно и попросил объяснить как это работает...
В резюме соискателя я так и написал, что чувак все решил, но объяснить решение задач не может.
Все эти случаи показывают, что собеседование достаточно мало говорит о кандидате. Я уже молчу, что часто сами собеседования проверяют вещи, которые не нужны в работе.
Проще всего собеседовать Джуниоров и Мидлов. Поскольку у них проверяют технические знания. И они либо есть, либо их нет. Но чем старше тем сложнее.
Именно поэтому мне нравится идея разговорных собеседований. Да, такие собеседования сложно стандартизировать, что может быть проблемой для больших компаний. Зато ничего лучше разговора не покажет, насколько человек глубоко понимает предмет о котором говорит, и самое главное насколько вам будет комфортно работать вместе.
Да, моно ошибиться и уже во время работы понять, что человек не подошел. Но как показал мой опыт, никакой из способов не дает гарантию от этого.
Именно поэтому я всеми конечностями голосую за разговорные собеседования, да их может быть много, но только так можно понять, впишется ли человек в команду или нет.
А что думаешь ты про собеседования с кодом, про устные собеседования? Расскажи про свой опыт собеседований как с одной, так и с другой стороны.
🚮 Однажды тебя попросят выкинуть весь код
Однажды тебе нужно будет выкинуть свой код, и ты ничего не сможешь с этим поделать.
Иногда это происходит когда бизнес меняет свои планы, иногда рынок диктует свои условия и приложение, в которое ты вложил столько сил больше не нужно.
У меня же это случилось когда продали dc, Я бы не сказал, что я был главным контрибьютером или в этом приложении были заложены мои архитектурные идеи. Но было несколько фичей в которые я вложил много сил.
Чтобы двигаться дальше, нам нужно было отдать какое-то количество технического долга, и конец 2021 и начало 2022 мы занимались именно этим.
Исправлять чужие архитектурные ошибки в работающем приложении такое себе занятие. Сил нужно много, а один из главных таргетов успешности - это чтобы никто ничего не заметил.
И вот, спустя пол года не самой приятной разработки, мы узнаем, что будет интеграция, а еще через несколько месяцев мы узнаем, как эта интеграция будет происходить.
Весь код, который мы старательно причесывали больше не нужен.
В этой ситуации для себя я сделал вывод, что не стоит заострять внимание на самом факте обесценивания проделанной работы. Стоит смотреть на проблему шире.
В целом программисты в одной области решают одни и те же задачи, соответственно если весь код выкинуть, то появляется возможность решить проблему заново. Да, вводные будут другие, но опыт останется с тобой.
В DC я не всегда писал код идеально. Иногда у меня не было времени написать хорошо, иногда просто не хватало мотивации или экспертизы. В момент осознания ненужности моего кода, я радовался, что мои ошибки никому не обидеться поддерживать.
Ну самое главное, я вспоминал свой самый первый проект. Это был вью для пеленгатора. Разработка этого проекта остановлена, тем не менее его несколько раз продали. Соответственно это оборудование будет работать ближайшие лет 10-20, а в месте с ним будет работать мой код.
Всем рано или поздно придется выкинуть код проекта, к которому сильное привязался, и это будет неприятно, но стоит воспринимать это как шанс сделать в следующий раз лучше.
Однажды тебе нужно будет выкинуть свой код, и ты ничего не сможешь с этим поделать.
Иногда это происходит когда бизнес меняет свои планы, иногда рынок диктует свои условия и приложение, в которое ты вложил столько сил больше не нужно.
У меня же это случилось когда продали dc, Я бы не сказал, что я был главным контрибьютером или в этом приложении были заложены мои архитектурные идеи. Но было несколько фичей в которые я вложил много сил.
Чтобы двигаться дальше, нам нужно было отдать какое-то количество технического долга, и конец 2021 и начало 2022 мы занимались именно этим.
Исправлять чужие архитектурные ошибки в работающем приложении такое себе занятие. Сил нужно много, а один из главных таргетов успешности - это чтобы никто ничего не заметил.
И вот, спустя пол года не самой приятной разработки, мы узнаем, что будет интеграция, а еще через несколько месяцев мы узнаем, как эта интеграция будет происходить.
Весь код, который мы старательно причесывали больше не нужен.
В этой ситуации для себя я сделал вывод, что не стоит заострять внимание на самом факте обесценивания проделанной работы. Стоит смотреть на проблему шире.
В целом программисты в одной области решают одни и те же задачи, соответственно если весь код выкинуть, то появляется возможность решить проблему заново. Да, вводные будут другие, но опыт останется с тобой.
В DC я не всегда писал код идеально. Иногда у меня не было времени написать хорошо, иногда просто не хватало мотивации или экспертизы. В момент осознания ненужности моего кода, я радовался, что мои ошибки никому не обидеться поддерживать.
Ну самое главное, я вспоминал свой самый первый проект. Это был вью для пеленгатора. Разработка этого проекта остановлена, тем не менее его несколько раз продали. Соответственно это оборудование будет работать ближайшие лет 10-20, а в месте с ним будет работать мой код.
Всем рано или поздно придется выкинуть код проекта, к которому сильное привязался, и это будет неприятно, но стоит воспринимать это как шанс сделать в следующий раз лучше.
📚 Отзыв о книге от "От джуна до сеньора. Как стать востребованным разработчиком"
Если коротко:
- кликбейстное название, которое не подтверждается содержимым
- полезна исключительно для тех, кто еще не в профессии
- больше похоже на альманах проблем, с которым столнется программист.
- много рассказывается про проблемы джунов, немного про проблемы синьеров, проблем у мидлов, как будто нет
- ни слова о том, чтобы стать востребованным разработчиком
А теперь подробнее.
Первое, что бросается в глаза это название, точнее его кликбейтность. По моему скромному мнению название - исключительно творение маркетологов. А сама книга очень слабо отвечает на вопрос, поставленный в названии. Скорее это книга - сборник некоторых проблем с которыми столкнется разработчик на своем пути.
Я ни в коем случае не хочу ничего сказать о профессионализме автора, думаю, если он мог собрать и систематизировать такое количество проблем, он действительно разработчик с большим стажем.
Но умение писать код, не поставляется отдельно от умения писать книги.
Книга разбита на главы, которые расставлены в хронологическом порядке. Сначала автор рассказывает о вещах полезных тем кто делает первые шаги. Потом достаточно долго рассказывает о проблемах младших разработчиков, а потом как-то резко переходит к переходит к вопросу выгорания и развитию карьеры на синьерских прозициях.
Я сразу вспомнил знаменитый гайд как нарисовать сову.
Я понимаю, что все джуны, как и все синьеры имеют синьеры сталкиваются с одинаковыми пробелмами. А вот пробелмы миддл разработчиков более индивидуальны. Но раз автор строит книгу основываясь на своем опыте, можно было рассказать про смену стека про потолок среднячка, про смену работы и так далее.
Вот и получается, что с одной стороны это своего рода альманах проблем с которыми сталкивается разработчик на своем пути, с другой стороны не очень полный.
Зато то, что есть, подкреплено не только описанием проблемы, но и описанием того, как эту проблему решать, и даже домашним заданием.
Так же автор каждую главу подкрепляет историями из жизни, и умозаключениями, которые он вынес, исходя из своего опыта.
Множество тем, которые описывает автор действительно актуальны для подавляющего числа будущих программистов. И тут хотелось бы сказать, предупрежден, значит вооружен, но у меня возникает вопрос, а надо ли разбираться с проблемой до того как она случилась?
С одной стороны да, а с другой проблемных ситуаций может быть столько что просто знание всех может сделать тебя невротиком.
В итоге книга будет полезна перед покупкой курсов по программированию, чтобы понимать с чем сталкиваются в этой профессии. Поскольку достаточно поверхностно описывает проблемы, с которым столкнуться большая часть разработчиков. Основная претензия у меня к этой книге - это ее название, которое не оправдывается ее содержимым. В остальном, если не создавать высоких ожиданий вполне пригодная книга для тех кто хочет познакомиться с профессией программиста чуть ближе.
Остальные отзывы по книгам можно натий по хештегу #книги
Если коротко:
- кликбейстное название, которое не подтверждается содержимым
- полезна исключительно для тех, кто еще не в профессии
- больше похоже на альманах проблем, с которым столнется программист.
- много рассказывается про проблемы джунов, немного про проблемы синьеров, проблем у мидлов, как будто нет
- ни слова о том, чтобы стать востребованным разработчиком
А теперь подробнее.
Первое, что бросается в глаза это название, точнее его кликбейтность. По моему скромному мнению название - исключительно творение маркетологов. А сама книга очень слабо отвечает на вопрос, поставленный в названии. Скорее это книга - сборник некоторых проблем с которыми столкнется разработчик на своем пути.
Я ни в коем случае не хочу ничего сказать о профессионализме автора, думаю, если он мог собрать и систематизировать такое количество проблем, он действительно разработчик с большим стажем.
Но умение писать код, не поставляется отдельно от умения писать книги.
Книга разбита на главы, которые расставлены в хронологическом порядке. Сначала автор рассказывает о вещах полезных тем кто делает первые шаги. Потом достаточно долго рассказывает о проблемах младших разработчиков, а потом как-то резко переходит к переходит к вопросу выгорания и развитию карьеры на синьерских прозициях.
Я сразу вспомнил знаменитый гайд как нарисовать сову.
Я понимаю, что все джуны, как и все синьеры имеют синьеры сталкиваются с одинаковыми пробелмами. А вот пробелмы миддл разработчиков более индивидуальны. Но раз автор строит книгу основываясь на своем опыте, можно было рассказать про смену стека про потолок среднячка, про смену работы и так далее.
Вот и получается, что с одной стороны это своего рода альманах проблем с которыми сталкивается разработчик на своем пути, с другой стороны не очень полный.
Зато то, что есть, подкреплено не только описанием проблемы, но и описанием того, как эту проблему решать, и даже домашним заданием.
Так же автор каждую главу подкрепляет историями из жизни, и умозаключениями, которые он вынес, исходя из своего опыта.
Множество тем, которые описывает автор действительно актуальны для подавляющего числа будущих программистов. И тут хотелось бы сказать, предупрежден, значит вооружен, но у меня возникает вопрос, а надо ли разбираться с проблемой до того как она случилась?
С одной стороны да, а с другой проблемных ситуаций может быть столько что просто знание всех может сделать тебя невротиком.
В итоге книга будет полезна перед покупкой курсов по программированию, чтобы понимать с чем сталкиваются в этой профессии. Поскольку достаточно поверхностно описывает проблемы, с которым столкнуться большая часть разработчиков. Основная претензия у меня к этой книге - это ее название, которое не оправдывается ее содержимым. В остальном, если не создавать высоких ожиданий вполне пригодная книга для тех кто хочет познакомиться с профессией программиста чуть ближе.
Остальные отзывы по книгам можно натий по хештегу #книги
🔥 Снова про выгорание
Хотел бы я сказать, что ты никогда не будешь уставать так, что тебя будет тошнить от одной мысли о работе. Что выходные будут казаться передышкой между мучительным рабочими днями, а из отпуска не захочется возвращаться. Хотел бы я сказать, что ты никогда не столкнешься с профессиональным выгоранием. Но это было бы неправдой.
В какой-то момент ты почувствуешь, что все, чем ты занимаешься, – бессмысленно, что твои решения в коде – некачественные и глупые. Ты начнешь допускать грубые ошибки, станешь хуже принимать решения, хуже анализировать новые задачи и требования.
Поздравляю, ты стал профессиональным разработчиком.
Можно попробовать описать причины таких кризисов, но с одной стороны их слишком много, а с другой они чрезвычайно индивидуальны. У меня были свои, у тебя будут свои.
💥 Первый совет, который я хочу тебе дать: притормози. Возьми отпуск, больничный, пусть даже тебе это обойдется тебе дорого, твое здоровье все-равно дороже.
Если ты исчерпал весь свой ресурс, то можешь сделать лишь одно: остановиться и обдумать ситуацию без нависающих над тобой дедлайнов, ошибок и клиентов.
☂️ Дай себе столько времени, чтобы передохнуть, сколько необходимо. Вместе с выгоранием приходит потеря интереса ко всему, что тебя радовало, мотивировало, интересовало. Твоя задача – сделать паузу, чтобы эти ощущения вернулись. Если ты снова чувствуешь интерес, захотелось попробовать что-то новое в разработке, заинтересовала какая-то новая технология, – поздравляю, ты на правильном пути.
💡 Однако есть и другой сценарий. Возможно, ты почувствуешь, что не хочешь больше заниматься разработкой. Не пугайся этой мысли, дай ей право на существование. Возможно ты отбросишь эту мысль чуть позже, поскольку она покажется тебе глупой, а возможно - это просто старт чего-то нового.
В IT множество специальностей, где не нужно писать код, возможно тебе захочется заняться чем-то еще.
💨 Выгорание и психологические расстройства часто идут рука об руку, и тебе нужно понимать, что не всегда потеря интереса к работе связана только с самой работой. Без внешнего наблюдателя (aka психолога) понять это бывает не просто.
👨⚕️ Поэтому самый главный совет все-таки - это обратиться к специалисту.
Хотел бы я сказать, что ты никогда не будешь уставать так, что тебя будет тошнить от одной мысли о работе. Что выходные будут казаться передышкой между мучительным рабочими днями, а из отпуска не захочется возвращаться. Хотел бы я сказать, что ты никогда не столкнешься с профессиональным выгоранием. Но это было бы неправдой.
В какой-то момент ты почувствуешь, что все, чем ты занимаешься, – бессмысленно, что твои решения в коде – некачественные и глупые. Ты начнешь допускать грубые ошибки, станешь хуже принимать решения, хуже анализировать новые задачи и требования.
Поздравляю, ты стал профессиональным разработчиком.
Можно попробовать описать причины таких кризисов, но с одной стороны их слишком много, а с другой они чрезвычайно индивидуальны. У меня были свои, у тебя будут свои.
💥 Первый совет, который я хочу тебе дать: притормози. Возьми отпуск, больничный, пусть даже тебе это обойдется тебе дорого, твое здоровье все-равно дороже.
Если ты исчерпал весь свой ресурс, то можешь сделать лишь одно: остановиться и обдумать ситуацию без нависающих над тобой дедлайнов, ошибок и клиентов.
☂️ Дай себе столько времени, чтобы передохнуть, сколько необходимо. Вместе с выгоранием приходит потеря интереса ко всему, что тебя радовало, мотивировало, интересовало. Твоя задача – сделать паузу, чтобы эти ощущения вернулись. Если ты снова чувствуешь интерес, захотелось попробовать что-то новое в разработке, заинтересовала какая-то новая технология, – поздравляю, ты на правильном пути.
💡 Однако есть и другой сценарий. Возможно, ты почувствуешь, что не хочешь больше заниматься разработкой. Не пугайся этой мысли, дай ей право на существование. Возможно ты отбросишь эту мысль чуть позже, поскольку она покажется тебе глупой, а возможно - это просто старт чего-то нового.
В IT множество специальностей, где не нужно писать код, возможно тебе захочется заняться чем-то еще.
💨 Выгорание и психологические расстройства часто идут рука об руку, и тебе нужно понимать, что не всегда потеря интереса к работе связана только с самой работой. Без внешнего наблюдателя (aka психолога) понять это бывает не просто.
👨⚕️ Поэтому самый главный совет все-таки - это обратиться к специалисту.
🥃 Я бы хотел бухать на рабочем месте
На собеседование заходит чувак и после стандартных приветствий достает из внутреннего кармана бутылку пива... Такая история произошла на собеседовании в компании, где я работал.
Суть этого перформанса была в том, что чуваку любил прибухнуть на пока писал код. И самое главное не хотел от этого отказываться. Для него остальной разговор был бессмысленным, если для новой компании такое поведение неприемлемо.
Я откровенно завидую этому чуваку, не в смысле, что я бы тоже хотел пить на работе, а потому что он знает чего хочет и не боится об этом заявлять. До меня вообще далеко не сразу дошла мысль, что к новой работе можно предъявлять какие-то критерии, и отсеивать компании на основе них. А потому был очень легкой мишенью для хантеров.
Мне присылали описание, полное захватывающих возможностей, и все, я уже был готов общаться. Иногда осознавал от чего я хочу уйти, но никогда осознанно не шел к чему-то. Так у меня появился список чего я не хочу видеть на новом месте, и это лучше, чем ничего, но я все-равно не знал чего хочу.
Только один раз я составил список »пожеланий» к новой работе, но и то он не пригодился.
Знать чего ты хочешь, как мне кажется крайне важно. Это понимание позволяет каждую смену работы использовать для достижения своей цели. А иначе, новая работа может оказаться пустой тратой времени.
И вообще рефлексия над тем, чего хочешь получить отлично работает не только при смене работы, но и во многих других сферах. По сути это процесс целеполагание основанный на внутренних желаниях.
А что для тебя важно в новой работе, если бы ты прямо сейчас ее искал?
На собеседование заходит чувак и после стандартных приветствий достает из внутреннего кармана бутылку пива... Такая история произошла на собеседовании в компании, где я работал.
Суть этого перформанса была в том, что чуваку любил прибухнуть на пока писал код. И самое главное не хотел от этого отказываться. Для него остальной разговор был бессмысленным, если для новой компании такое поведение неприемлемо.
Я откровенно завидую этому чуваку, не в смысле, что я бы тоже хотел пить на работе, а потому что он знает чего хочет и не боится об этом заявлять. До меня вообще далеко не сразу дошла мысль, что к новой работе можно предъявлять какие-то критерии, и отсеивать компании на основе них. А потому был очень легкой мишенью для хантеров.
Мне присылали описание, полное захватывающих возможностей, и все, я уже был готов общаться. Иногда осознавал от чего я хочу уйти, но никогда осознанно не шел к чему-то. Так у меня появился список чего я не хочу видеть на новом месте, и это лучше, чем ничего, но я все-равно не знал чего хочу.
Только один раз я составил список »пожеланий» к новой работе, но и то он не пригодился.
Знать чего ты хочешь, как мне кажется крайне важно. Это понимание позволяет каждую смену работы использовать для достижения своей цели. А иначе, новая работа может оказаться пустой тратой времени.
И вообще рефлексия над тем, чего хочешь получить отлично работает не только при смене работы, но и во многих других сферах. По сути это процесс целеполагание основанный на внутренних желаниях.
А что для тебя важно в новой работе, если бы ты прямо сейчас ее искал?
🥊🥊 Вот и прилетела ответочка
Ну вот прилетела ответочка, на мой пост про код ревью. Олег с канала Коды-некоды Громова, написал статью, где в в целом достаточно неплохо оппонирует, и расписывает чем, может быть полезно код ревью.
Опрос после того поста показал, что со мной не согласна большая часть читателей. И это заставляет меня пояснить свою мысль во второй статье.
Дисклеймер, я не хочу сказать, что от код ревью одни минусы. Если бы это было так, то эта практика не получила бы такого распространения. Идея была в том, что из любого, даже самого полезного, процесса сделать карго культ, он начнет приносить проблемы.
На другой чаще весов плюсы про которые все не устают говорить.
Но как понять, где та грань, когда ты осмысленно применяешь процесс и он приносит пользу, и когда его уже возвели в культ? К сожалением, у меня нет четкого ответа на этот вопрос, но зато у меня есть другой маркер.
Людям свойственно особенно рьяно защищать идеи, в которые они верят, но которые до конца не понимают. Вспомнить хотя бы религиозные войны.
И вот то количество людей которые накинулись на меня, в том числе и в личке, уверяя что я в корне не прав и вообще ничего не понимаю, как бы намекает мне, что для многих это стало карго культом.
Ну вот прилетела ответочка, на мой пост про код ревью. Олег с канала Коды-некоды Громова, написал статью, где в в целом достаточно неплохо оппонирует, и расписывает чем, может быть полезно код ревью.
Опрос после того поста показал, что со мной не согласна большая часть читателей. И это заставляет меня пояснить свою мысль во второй статье.
Дисклеймер, я не хочу сказать, что от код ревью одни минусы. Если бы это было так, то эта практика не получила бы такого распространения. Идея была в том, что из любого, даже самого полезного, процесса сделать карго культ, он начнет приносить проблемы.
На другой чаще весов плюсы про которые все не устают говорить.
Но как понять, где та грань, когда ты осмысленно применяешь процесс и он приносит пользу, и когда его уже возвели в культ? К сожалением, у меня нет четкого ответа на этот вопрос, но зато у меня есть другой маркер.
Людям свойственно особенно рьяно защищать идеи, в которые они верят, но которые до конца не понимают. Вспомнить хотя бы религиозные войны.
И вот то количество людей которые накинулись на меня, в том числе и в личке, уверяя что я в корне не прав и вообще ничего не понимаю, как бы намекает мне, что для многих это стало карго культом.
Telegram
Коды-некоды Громова
Код-ревью: убрать нельзя оставить 😱
Пока я дописываю следующий пост о совпадениях, хочу разбавить поток рефлексии более практичной и холиварной темой для своих читателей-разработчиков 😈
Мой знакомый Алекс написал о том, какие негативные последствия бывают…
Пока я дописываю следующий пост о совпадениях, хочу разбавить поток рефлексии более практичной и холиварной темой для своих читателей-разработчиков 😈
Мой знакомый Алекс написал о том, какие негативные последствия бывают…
🕵️♀️ Как пройти собеседование в IT без опыта
Сегодня я расскажу как разработчик без опыта и совести может пройти собеседование. Как можно получать офер на большую сумму и кидаю еще пару камней в огород процесса собеседования.
Недавно я рассказывал про то, что процесс собеседования мягко говоря не совершенен, сегодня я продолжу это доказывать.
Прохождение собеседований - это отдельный навык, который не всегда коррелирует с умением выполнять рабочие задачи. Когда я начинаю искать работу, я сначала набираю форму. Прохожу 2-3 собеседования в компании, куда я идти точно не собираюсь. Я называю это прийти в форму.
Если собеседование - это отдельный навык, то им можно овладеть. И, скажу по секрету, иногда даже проще чем хорошо научиться программировать.
☝️ Давай представим Васю. Вася окончил курсы по программированию, и очень хочет попасть на работу. У него есть некоторые знания в теории, но нет практики.
✌️ Вася сочиняет себе резюме, в которое добавляет несуществующий опыт. Например, пару лет работал в какой-то маленькой веб студии в маленьком городке. С оформлением через ИП или вообще без официального трудоустройства. Проверять такие вещи сложно.
🤟 Далее Вася за неделю просматривает все публичные собеседования которые только есть на Ютубе. Так он знакомиться с большей частью вопросов, которые обычно спрашивают. Вася готовится и заучивает ответы на эти вопросы.
🤞 Все, Вася готов! С таким набором знаний вероятность найти работу для Васи очень велика.
Далее Вася, имея 2 года несуществующего опыта, легче попадает на собеседования. Опять же цель у Васи не попасть в топ компании, он выбирает не очень крупны, и соответственно не очень требовательные компании. За 5 собеседований оттачивает навык прохождения собеседований, и учится не расстраиваться, к отказу.
Можно ли вывести Васю на чистую воду? Да легко, можно построить собеседование не формально, и углубиться в предыдущий опыт работы. И кто-то даже будет так делать, но таких меньшинство. Поскольку такой подход не стандартизируем, а еще он энерго затратен.
Сегодня я расскажу как разработчик без опыта и совести может пройти собеседование. Как можно получать офер на большую сумму и кидаю еще пару камней в огород процесса собеседования.
Недавно я рассказывал про то, что процесс собеседования мягко говоря не совершенен, сегодня я продолжу это доказывать.
Прохождение собеседований - это отдельный навык, который не всегда коррелирует с умением выполнять рабочие задачи. Когда я начинаю искать работу, я сначала набираю форму. Прохожу 2-3 собеседования в компании, куда я идти точно не собираюсь. Я называю это прийти в форму.
Если собеседование - это отдельный навык, то им можно овладеть. И, скажу по секрету, иногда даже проще чем хорошо научиться программировать.
☝️ Давай представим Васю. Вася окончил курсы по программированию, и очень хочет попасть на работу. У него есть некоторые знания в теории, но нет практики.
✌️ Вася сочиняет себе резюме, в которое добавляет несуществующий опыт. Например, пару лет работал в какой-то маленькой веб студии в маленьком городке. С оформлением через ИП или вообще без официального трудоустройства. Проверять такие вещи сложно.
🤟 Далее Вася за неделю просматривает все публичные собеседования которые только есть на Ютубе. Так он знакомиться с большей частью вопросов, которые обычно спрашивают. Вася готовится и заучивает ответы на эти вопросы.
🤞 Все, Вася готов! С таким набором знаний вероятность найти работу для Васи очень велика.
Далее Вася, имея 2 года несуществующего опыта, легче попадает на собеседования. Опять же цель у Васи не попасть в топ компании, он выбирает не очень крупны, и соответственно не очень требовательные компании. За 5 собеседований оттачивает навык прохождения собеседований, и учится не расстраиваться, к отказу.
Можно ли вывести Васю на чистую воду? Да легко, можно построить собеседование не формально, и углубиться в предыдущий опыт работы. И кто-то даже будет так делать, но таких меньшинство. Поскольку такой подход не стандартизируем, а еще он энерго затратен.
В твоем резюме
Anonymous Poll
63%
👌Только правда и ничего кроме правды
33%
🖖Немножко приукрасил
4%
🤙 Есть места где я не работал
И в дагонку, нормально ли привирать в резюме?
Anonymous Poll
19%
🤣 Да, требования нереальные
37%
👩🎓Все врут, разница ли в том, что не все говорят
44%
😇 Нет, надо быть честным
📖 ☕︎ Почему не все любят ходить на работу - мысли о книге Патрика Ленсиони
Есть такой редкий жанр - бизнес роман. И до последнего времени, у меня с ним отношения как-то не складывались.
Все произведения Ленсиони у меня оставляют ощущение неудовлетворенности. С литературной точки зрения они откровенно слабы. Герои чаще всего плоские, не выразительные, события описываются сухо, ситуации бытовые. Зато примеры из книги очень наглядны. Я легко вижу мысль, которую автор закладывает в незамысловатые диалоги и простые сюжетные ходы.
В итоге получалось с одной стороны книги не тянули на художественную литературу, а с другой до научпопа тоже не дотягивали. Хотя я понимаю, что это особенности жанра.
Но с этой книгой все ложилось иначе. Глубины и многогранности добавил мой жизненный опыт. Мои родители считали, что получение удовольствие от работы - лотерея. Либо ты выиграл и ты любишь ходить на работу, либо нет. И этот нарратив я слышал с самого детства. Хотя сам был другого мнения, считая что надо ходить только на любимую работу, я ни разу не задумался из чего складывается это желание или нежелание.
А состоит оно всего из трех ингредиентов
- обезличенность
- ненужность
- неизмеряемость
Обезличенность и ненужность - это именно то, что объединяет большую часть клише об офисном планктоне. Армия мужчин средних лет в белых рубашках, некоторые в галстуках, а кто-то с каплей горчицы обеденного перерыва. И непременно, ненавидящих свою работу.
Я как-то писал, что несмотря на то, что далеко не все мне нравится в текущем месте. Я чувствую особый кайф, понимая, что мой код увидит огромное количество человек.
Был в моей практике и обратный пример, когда процессы были отлажены, но к разработчикам относились достаточно потребительски. Я тогда был тим лидом, и когда я подсветил руководителю, что у нас текучка кадров он сказал: "Разработчиков всегда можно нанять новых"
Тут отлично подойдет цитата из книги:
Работа, которая не приносит удовлетворения, — не то же самое, что плохая работа.
В этой цитате для меня кроется главный урок этой книги. Можно получать удовольствие даже не от самой хорошей работы.
С неизмеряемостью все несколько сложнее. Безусловно, ощущение прогресса мощный мотиватор. Но у меня в жизни был совершенно противоположный опыт.
Студентом я подрабатывал заправщиком картриджей для принтера. Несмотря на то, что платили мне оклад, оценивали меня по количеству заправленных картриджей. Признаюсь, я ненавидел эту работу, хотя достаточно быстро прогрессировал.
Сейчас мою работу измерить сложнее, но иногда я пытаюсь. Я иногда ввожу игровые механики в свой рабочий процесс. Например, считаю количество строк кода, или количество файлов в которых я добавил изменения.
Помогает ли мне это? Скорее да, но эффект сильно слабее, чем о мысли про количество пользователей моей работы. Хотя в книге этот пункт выделяется особенно сильно.
Если резюмировать, то я советую прочитать эту книгу, и подумать над тем, насколько тебе нравится ходить на свою работу, и как, следуя примерам из книги, можно изменить это отношение к лучшему.
PS Вообще мне нравится писать обзоры на книги, но я еще в поисках своей формы для обзора. Напиши, пожалуйста, в комментариях, как тебе такой формат, где я беру основную мысль книги и перекладываю на собственный опыт. Что понравилось? А что можно было бы улучшить?
Спасибо, что дочитал, хорошего дня
#книги
Есть такой редкий жанр - бизнес роман. И до последнего времени, у меня с ним отношения как-то не складывались.
Все произведения Ленсиони у меня оставляют ощущение неудовлетворенности. С литературной точки зрения они откровенно слабы. Герои чаще всего плоские, не выразительные, события описываются сухо, ситуации бытовые. Зато примеры из книги очень наглядны. Я легко вижу мысль, которую автор закладывает в незамысловатые диалоги и простые сюжетные ходы.
В итоге получалось с одной стороны книги не тянули на художественную литературу, а с другой до научпопа тоже не дотягивали. Хотя я понимаю, что это особенности жанра.
Но с этой книгой все ложилось иначе. Глубины и многогранности добавил мой жизненный опыт. Мои родители считали, что получение удовольствие от работы - лотерея. Либо ты выиграл и ты любишь ходить на работу, либо нет. И этот нарратив я слышал с самого детства. Хотя сам был другого мнения, считая что надо ходить только на любимую работу, я ни разу не задумался из чего складывается это желание или нежелание.
А состоит оно всего из трех ингредиентов
- обезличенность
- ненужность
- неизмеряемость
Обезличенность и ненужность - это именно то, что объединяет большую часть клише об офисном планктоне. Армия мужчин средних лет в белых рубашках, некоторые в галстуках, а кто-то с каплей горчицы обеденного перерыва. И непременно, ненавидящих свою работу.
Я как-то писал, что несмотря на то, что далеко не все мне нравится в текущем месте. Я чувствую особый кайф, понимая, что мой код увидит огромное количество человек.
Был в моей практике и обратный пример, когда процессы были отлажены, но к разработчикам относились достаточно потребительски. Я тогда был тим лидом, и когда я подсветил руководителю, что у нас текучка кадров он сказал: "Разработчиков всегда можно нанять новых"
Тут отлично подойдет цитата из книги:
Работа, которая не приносит удовлетворения, — не то же самое, что плохая работа.
В этой цитате для меня кроется главный урок этой книги. Можно получать удовольствие даже не от самой хорошей работы.
С неизмеряемостью все несколько сложнее. Безусловно, ощущение прогресса мощный мотиватор. Но у меня в жизни был совершенно противоположный опыт.
Студентом я подрабатывал заправщиком картриджей для принтера. Несмотря на то, что платили мне оклад, оценивали меня по количеству заправленных картриджей. Признаюсь, я ненавидел эту работу, хотя достаточно быстро прогрессировал.
Сейчас мою работу измерить сложнее, но иногда я пытаюсь. Я иногда ввожу игровые механики в свой рабочий процесс. Например, считаю количество строк кода, или количество файлов в которых я добавил изменения.
Помогает ли мне это? Скорее да, но эффект сильно слабее, чем о мысли про количество пользователей моей работы. Хотя в книге этот пункт выделяется особенно сильно.
Если резюмировать, то я советую прочитать эту книгу, и подумать над тем, насколько тебе нравится ходить на свою работу, и как, следуя примерам из книги, можно изменить это отношение к лучшему.
PS Вообще мне нравится писать обзоры на книги, но я еще в поисках своей формы для обзора. Напиши, пожалуйста, в комментариях, как тебе такой формат, где я беру основную мысль книги и перекладываю на собственный опыт. Что понравилось? А что можно было бы улучшить?
Спасибо, что дочитал, хорошего дня
#книги
📅 О проектах выходного дня
Сантехник не будет чинить трубы, что отдохнуть, уборщик не пойдет убираться к соседу, чтобы переключиться, а вот программист будет.
Понадобилось мне подобрать доменное имя. Казалось бы сервисов whois полным-полно, но на одном не удобная фильтрация, другой после каждого запроса сбрасывает фильтры, у третьего маленький выбор зон... Короче, я понял, что мне не удобно, и решил написать скрипт, который делает все это, и выводит обычным списком. Ну а где скрипт, там и телеграм бот, чтобы было под рукой... В общем идея мне понравилось, а руки зачесались сделать😀
Михай Чиксентмихайи писал, что задача захватывает нас, когда цель понятна, и она сложнее тех задач, которые заставляют зевать, и проще тех, которые вгоняют в ступор.
Эта задача была именно такой. Я хотел просто ввести слово, и получить список свободных доменных имен. Я умею писать ботов, и написал их не мало, поэтому эта задача не повергла меня в ступор, но и простой она тоже не был. В общем идеальный проект выходного дня.
Поскольку API позволяет проверить 1 домен за запрос, я написал шину данных, которая одновременно делает только 5 запросов. Вернулся один из запросов, тут же запустился следующий, и так далее, пока не кончатся домены для проверки.
Похожую задачу я когда-то решал на собеседовании и несколько раз на литкоде. Это все-таки случилось, мне приходился этот опыт!!!
Несмотря на то, что для внешнего наблюдателя что сейчас, что на работе я все так же сижу на том же стулом, за тем же компьютером. Пишу на том же языке в том же редакторе те же символы, для меня разница огромна.
На работе, программист чаще всего решает задачи, приходящие из вне. Тут же я пишу код из внутренних побуждений, я сам захотел решить эту проблему, я сам ее и решаю.
Очень похожую радость, я испытывал, когда только учился программировать, когда твой первый скрипт в итоге после долгих мучений все-таки работает, так как ты этого хотел. Думаю, все кто программирует меня поймут.
В этом неоспоримый плюс подобных проектов. В такое моменты, помимо положительных эмоций я еще вспоминаю, почему мне так нравится программировать.
К сожалению, у проектов выходного дня есть и обратная сторона.
Код написан, домены ищутся, а результат можно увидеть через телеграм бота, а не в консоли. И тут возникает вопрос, а что дальше?
В таком виде - этим решением можно воспользоваться один раз, и забыть его где-то в приватном репозитории гитхабе. А если все-таки публиковать? То доработок нужно еще столько же, если не больше. Причем это уже рутинные задачи, по исправлению ошибок, написанию текстов и инструкций и так далее. Нести тяжело, а бросить жалко.
Вот как поступить?
И самое обидное, нет готового ответа. Нельзя доводить до идеала все проекты - идей много, а времени и сил нет. Но и бросать все идеи тоже не выход. Огромное количество проектов выходного дня превратились в итоге в дело жизни.
Для себя я решил, что если идея в моменте меня зажгла, и мне захотелось ее реализовать, то реализовывать однозначно надо. Особенно если есть понимание, что разработка не займет много времени. Тут и удовольствие от решенной задачи, и новый опыт, и возможность попробовать другие инструменты.
А вот с публикацией все сложнее, часть проектов я опубликовал, но без должного внимания, они не пользуются популярностью, большая же часть так и пылится не дописанная.
Главное соблюсти баланс, получить положительных эмоций больше, чем потратить сил на доработки.
ПС бота для поиска доменов, я все-таки дописал. Можете пользоваться, вдруг кому тоже пригодится😀
ПСС А были у тебя такие проекты выходного дня? Или были идеи, поделись в коментариях)
ПССС бесит случайно найденная картинка на аватарке у бота, накидайте вариантов в комментариях
Сантехник не будет чинить трубы, что отдохнуть, уборщик не пойдет убираться к соседу, чтобы переключиться, а вот программист будет.
Понадобилось мне подобрать доменное имя. Казалось бы сервисов whois полным-полно, но на одном не удобная фильтрация, другой после каждого запроса сбрасывает фильтры, у третьего маленький выбор зон... Короче, я понял, что мне не удобно, и решил написать скрипт, который делает все это, и выводит обычным списком. Ну а где скрипт, там и телеграм бот, чтобы было под рукой... В общем идея мне понравилось, а руки зачесались сделать😀
Михай Чиксентмихайи писал, что задача захватывает нас, когда цель понятна, и она сложнее тех задач, которые заставляют зевать, и проще тех, которые вгоняют в ступор.
Эта задача была именно такой. Я хотел просто ввести слово, и получить список свободных доменных имен. Я умею писать ботов, и написал их не мало, поэтому эта задача не повергла меня в ступор, но и простой она тоже не был. В общем идеальный проект выходного дня.
Поскольку API позволяет проверить 1 домен за запрос, я написал шину данных, которая одновременно делает только 5 запросов. Вернулся один из запросов, тут же запустился следующий, и так далее, пока не кончатся домены для проверки.
Похожую задачу я когда-то решал на собеседовании и несколько раз на литкоде. Это все-таки случилось, мне приходился этот опыт!!!
Несмотря на то, что для внешнего наблюдателя что сейчас, что на работе я все так же сижу на том же стулом, за тем же компьютером. Пишу на том же языке в том же редакторе те же символы, для меня разница огромна.
На работе, программист чаще всего решает задачи, приходящие из вне. Тут же я пишу код из внутренних побуждений, я сам захотел решить эту проблему, я сам ее и решаю.
Очень похожую радость, я испытывал, когда только учился программировать, когда твой первый скрипт в итоге после долгих мучений все-таки работает, так как ты этого хотел. Думаю, все кто программирует меня поймут.
В этом неоспоримый плюс подобных проектов. В такое моменты, помимо положительных эмоций я еще вспоминаю, почему мне так нравится программировать.
К сожалению, у проектов выходного дня есть и обратная сторона.
Код написан, домены ищутся, а результат можно увидеть через телеграм бота, а не в консоли. И тут возникает вопрос, а что дальше?
В таком виде - этим решением можно воспользоваться один раз, и забыть его где-то в приватном репозитории гитхабе. А если все-таки публиковать? То доработок нужно еще столько же, если не больше. Причем это уже рутинные задачи, по исправлению ошибок, написанию текстов и инструкций и так далее. Нести тяжело, а бросить жалко.
Вот как поступить?
И самое обидное, нет готового ответа. Нельзя доводить до идеала все проекты - идей много, а времени и сил нет. Но и бросать все идеи тоже не выход. Огромное количество проектов выходного дня превратились в итоге в дело жизни.
Для себя я решил, что если идея в моменте меня зажгла, и мне захотелось ее реализовать, то реализовывать однозначно надо. Особенно если есть понимание, что разработка не займет много времени. Тут и удовольствие от решенной задачи, и новый опыт, и возможность попробовать другие инструменты.
А вот с публикацией все сложнее, часть проектов я опубликовал, но без должного внимания, они не пользуются популярностью, большая же часть так и пылится не дописанная.
Главное соблюсти баланс, получить положительных эмоций больше, чем потратить сил на доработки.
ПС бота для поиска доменов, я все-таки дописал. Можете пользоваться, вдруг кому тоже пригодится😀
ПСС А были у тебя такие проекты выходного дня? Или были идеи, поделись в коментариях)
ПССС бесит случайно найденная картинка на аватарке у бота, накидайте вариантов в комментариях
🤼 Как осадить интервьюера на техническом собеседовании
Собеседование - это ситуация где встречаются два неравноправных человека, хотя бы потом что один знает ответы на вопросы. К сожалению, некоторые интервьюеры пользуются этим, еще сильнее давя на кандидата.
Есть несколько типов интервьюеров, которых я не переношу. Эти ребята ведут себя токсично, пытаясь самоутвердится за мой счет. И чтобы не быть жертвой я выработал схемы унижения интервьюера на техническом собеседовании.
Тип первый - высокомерный всезнайка
Понять, что ты попал к этому типу очень просто. Такие люди валят различными вопросами, связанными с тонкостями конкретной технологии.
Я не считаю, что такие вопросы задавать не нужно. Они могут показать кругозор кандидата, но не нужно все собеседование составлять из подобных вопросов.
Это заставляет кандидата ощущать себя ничтожно, хотя зачастую это энциклопедические знания, которые редко встретишь на практике.
Для таких моментов у меня припасен вопрос: "А как часто вы используете это в своем проекте?"
Очевидно, если код изобилует различными хаками, то либо этот код излишне переусложнен, либо он так плохо написан. Поскольку интервьюер в данный момент лицо компании, все мое презрение к их коду обращено именно к нему.
Если интервьюер признается, что в компании пишут не так хорошо, то и его позиция будет не такая уверенная. Дальше мне проще на него давить, мол, что ты тут такой умный, а код пишешь не очень.
Конечно, он может сказать, что они никогда не применяют подобные вещи в повседневной работе, и их код чище слезы младенца. Но в этот момент теряется смысл задавать подобные вопросы. Можно с тем же успехом поговорить про квантовую физику.
Тип второй - новичок
Это интервьюеры, которы нагуглили список вопросов к собеседованию, но сами толком не особо понимают. От того, что у него есть ответ перед глазами, он не становится опытнее.
Я хорошо отношусь к неопытным интервьюерам, но только если он не пытается повысить свое ЧСВ за мой счет.
Для таких ребят у меня есть много вопросов о том, как это работает под капотом.
Например, дает мне интервьюер вопрос на замыкания. Допустим я отвечаю неправильно, и он с видом победителя сообщает мне правильный ответ. Я не даю ему перейти к следующему вопросу, и пытаюсь разобраться, почему же ответ все-таки такой, а не другой. Я задаю множество вопросов, заставляя интервьюера чувствовать себя неуверенно.
Можно поглумиться еще сильнее. Сначала настаивать, что интервьюер ошибается, а через какое-то время предложить проверить. И в тот момент, когда вскрывается моя неправота, сказать: "Ну я же говорил!".
Вообще газлайтинг работает против всех неуверенных интервьюеров, выбивая почву у них из-под ног, тут главное самому излучать уверенность.
Ну и вообще любые примеры давления на интервьюера должны выполняться с невозмутимым видом и в вежливом тоне. Иначе все эти способы будут работать против вас.
Причем, если ты думаешь, что после такого тебя не возьмут в эту компанию, то, скорее всего ты прав. Но у меня был случай, когда я очень жестко осадил интервьюера, но меня все-равно позвали в компанию, и даже больше, когда я отказался, перезвонили через год и снова позвали. Но я так понял у них в целом токсичная обстановка.
Собеседование - это ситуация где встречаются два неравноправных человека, хотя бы потом что один знает ответы на вопросы. К сожалению, некоторые интервьюеры пользуются этим, еще сильнее давя на кандидата.
Есть несколько типов интервьюеров, которых я не переношу. Эти ребята ведут себя токсично, пытаясь самоутвердится за мой счет. И чтобы не быть жертвой я выработал схемы унижения интервьюера на техническом собеседовании.
Тип первый - высокомерный всезнайка
Понять, что ты попал к этому типу очень просто. Такие люди валят различными вопросами, связанными с тонкостями конкретной технологии.
Я не считаю, что такие вопросы задавать не нужно. Они могут показать кругозор кандидата, но не нужно все собеседование составлять из подобных вопросов.
Это заставляет кандидата ощущать себя ничтожно, хотя зачастую это энциклопедические знания, которые редко встретишь на практике.
Для таких моментов у меня припасен вопрос: "А как часто вы используете это в своем проекте?"
Очевидно, если код изобилует различными хаками, то либо этот код излишне переусложнен, либо он так плохо написан. Поскольку интервьюер в данный момент лицо компании, все мое презрение к их коду обращено именно к нему.
Если интервьюер признается, что в компании пишут не так хорошо, то и его позиция будет не такая уверенная. Дальше мне проще на него давить, мол, что ты тут такой умный, а код пишешь не очень.
Конечно, он может сказать, что они никогда не применяют подобные вещи в повседневной работе, и их код чище слезы младенца. Но в этот момент теряется смысл задавать подобные вопросы. Можно с тем же успехом поговорить про квантовую физику.
Тип второй - новичок
Это интервьюеры, которы нагуглили список вопросов к собеседованию, но сами толком не особо понимают. От того, что у него есть ответ перед глазами, он не становится опытнее.
Я хорошо отношусь к неопытным интервьюерам, но только если он не пытается повысить свое ЧСВ за мой счет.
Для таких ребят у меня есть много вопросов о том, как это работает под капотом.
Например, дает мне интервьюер вопрос на замыкания. Допустим я отвечаю неправильно, и он с видом победителя сообщает мне правильный ответ. Я не даю ему перейти к следующему вопросу, и пытаюсь разобраться, почему же ответ все-таки такой, а не другой. Я задаю множество вопросов, заставляя интервьюера чувствовать себя неуверенно.
Можно поглумиться еще сильнее. Сначала настаивать, что интервьюер ошибается, а через какое-то время предложить проверить. И в тот момент, когда вскрывается моя неправота, сказать: "Ну я же говорил!".
Вообще газлайтинг работает против всех неуверенных интервьюеров, выбивая почву у них из-под ног, тут главное самому излучать уверенность.
Ну и вообще любые примеры давления на интервьюера должны выполняться с невозмутимым видом и в вежливом тоне. Иначе все эти способы будут работать против вас.
Причем, если ты думаешь, что после такого тебя не возьмут в эту компанию, то, скорее всего ты прав. Но у меня был случай, когда я очень жестко осадил интервьюера, но меня все-равно позвали в компанию, и даже больше, когда я отказался, перезвонили через год и снова позвали. Но я так понял у них в целом токсичная обстановка.
🦥Почему учиться лень?
Что делать, когда обучение или работа наводят скуку? Когда понимаешь, что было бы неплохо разобраться с новой технологией, но нет мотивации на это.
Думаю, это состояние знакомо каждому. Но почему-то у кого-то есть желание после работы почитать Хабр или посмотреть курс по-английскому, а у кого-то нет.
Во всем виноват дофамин. Этот гормон - главная причина желания или нежелания часто делать что-то.
Работает это достаточно просто. Представь себе витрину с товарами, и у каждого товара есть какая-то цена. Только у нашего центра принятия решений не товары. И каждый раз выбирая между уборкой и приставкой, мозг оценивает, что в результате уборки он получит Х дофамина, а поиграв в плойку 100Х дофамина. Каждый раз мозг стремится получить как можно больше дофамина.
Другая особенность дофамина в том, что мозг постепенно вырабатывает толерантность к нему, а значит, со временем его нужно все больше и больше.
Если компьютерная игра надоела, и она больше не вызывает положительных эмоций, твой мозг привык к такому источнику и нужен новый. При этом мозг еще и привык к такому количеству дофамина. Именно поэтому уборка все еще тебе не интересна, потому что она дает всего X дофамина.
Но если источника такой же мощности не удалось, начинается абстинентный синдром. В простонародье - скука.
При этом планка желаемого количества дофамина со временем будет снижаться. Если остаться наедине с учебником в комнате, в которой совершенно нечем заняться, сначала ты будешь скучать, а потом с интересом возьмешься за учебник.
В этом я нашел первый секрет того, как с удовольствием тратить время на обучение, будь то пет-проект или новая технология. Важно выкинуть из жизни мощные источники в виде социальных сетей, фильмов, игр и иногда скучать.
Вообще в современном обществе не принято скучать, и для того, чтобы это состояние никогда не наступало, у нас есть смартфон.
Второй лайфхак заключается в том, что у меня есть воскресенье, в которое я не сажусь за компьютер, и стараюсь не пользоваться телефоном для развлечения. Я называю это день цифрового детокса.
Другая особенность обучения заключается в том, что со временем, когда появляется положительная обратная связь от обучения, сам процесс обучения начинает нравиться.
В итоге я сначала заставляю себя поскучать, чтобы захотелось чему-то учиться. Потом начинаю учиться таким образом и стараюсь как можно быстрее получить положительную обратную связь. И в какой-то момент это начинает работать как снежный ком. И мне уже приходится следить, чтобы не перегореть к новому занятию.
Что делать, когда обучение или работа наводят скуку? Когда понимаешь, что было бы неплохо разобраться с новой технологией, но нет мотивации на это.
Думаю, это состояние знакомо каждому. Но почему-то у кого-то есть желание после работы почитать Хабр или посмотреть курс по-английскому, а у кого-то нет.
Во всем виноват дофамин. Этот гормон - главная причина желания или нежелания часто делать что-то.
Работает это достаточно просто. Представь себе витрину с товарами, и у каждого товара есть какая-то цена. Только у нашего центра принятия решений не товары. И каждый раз выбирая между уборкой и приставкой, мозг оценивает, что в результате уборки он получит Х дофамина, а поиграв в плойку 100Х дофамина. Каждый раз мозг стремится получить как можно больше дофамина.
Другая особенность дофамина в том, что мозг постепенно вырабатывает толерантность к нему, а значит, со временем его нужно все больше и больше.
Если компьютерная игра надоела, и она больше не вызывает положительных эмоций, твой мозг привык к такому источнику и нужен новый. При этом мозг еще и привык к такому количеству дофамина. Именно поэтому уборка все еще тебе не интересна, потому что она дает всего X дофамина.
Но если источника такой же мощности не удалось, начинается абстинентный синдром. В простонародье - скука.
При этом планка желаемого количества дофамина со временем будет снижаться. Если остаться наедине с учебником в комнате, в которой совершенно нечем заняться, сначала ты будешь скучать, а потом с интересом возьмешься за учебник.
В этом я нашел первый секрет того, как с удовольствием тратить время на обучение, будь то пет-проект или новая технология. Важно выкинуть из жизни мощные источники в виде социальных сетей, фильмов, игр и иногда скучать.
Вообще в современном обществе не принято скучать, и для того, чтобы это состояние никогда не наступало, у нас есть смартфон.
Второй лайфхак заключается в том, что у меня есть воскресенье, в которое я не сажусь за компьютер, и стараюсь не пользоваться телефоном для развлечения. Я называю это день цифрового детокса.
Другая особенность обучения заключается в том, что со временем, когда появляется положительная обратная связь от обучения, сам процесс обучения начинает нравиться.
В итоге я сначала заставляю себя поскучать, чтобы захотелось чему-то учиться. Потом начинаю учиться таким образом и стараюсь как можно быстрее получить положительную обратную связь. И в какой-то момент это начинает работать как снежный ком. И мне уже приходится следить, чтобы не перегореть к новому занятию.
Всем привет! Последние несколько месяцев я экспериментирую с форматами и темами записей. Сейчас мне бы хотелось узнать у тебя, что бы тебе хотелось видеть в этом канале?
Можно писать любые пожелания, как по темам, так и по форматам.
Можно писать любые пожелания, как по темам, так и по форматам.
🙅🏻♂️ Эти проблемы не замечают на собеседовании
Помните, я говорил что собеседования не гарантирую вообще ничего. В эту тему интересный случай произошел у нас на работе.
Чувак вполне успешно прошел все этапы собеседования. Во время собеседования он показал отличные технические знания, да и в целом показался адекватным. А на работу вышел, кажется, кто-то другой.
На стендапах у него часто возникали "технические проблемы", из-за которых он то не отвечал совсем, то переспрашивал, то отвечал как-то невпопад. В рабочее время до него было невозможно дописаться, отвечал он с задержкой в 3-4 часа, а иногда и вовсе на следующий деть.
Его подержали пару месяцев, а потом уволили. Есть подозрение, что он просто одновременно работал на нескольких работах.
К сожалению, такие вещи сложно выяснить на собеседовании
А вот другой пример, с моей предыдущей работы.
Чувак был отличный технический специалист. У него был крутой опыт и глубокие технические знания. На собеседовании он выглядел очень воодушевленный и в красках рассказывал о том, как он может решить задачи которые перед ним планировали поставить,.
Чувак вышел на работу, начал разрабатывать архитектуру, и в какой-то момент стало заметно, что он работает медленнее, а воодушевление куда-то испарилось. Это стало очевидно не сразу, но спустя несколько месяцев не заметить было невозможно.
Судя по всему, чувак просто выгорел. Но поскольку собеседование это стресс, то он взбодрился и выглядел воодушевлено, но вот во время рабочей рутины, ему становилось скучно.
Можно ли увидеть это на собеседовании?
Скорее всего оба эти случаи не так очевидны, как недостаток технических знаний, но если иметь список вопросов, о кандидате на которые хочется ответить в процессе собеседования и вынести туда эти и другие, косвенно можно найти ответы на эти вопросы.
Помните, я говорил что собеседования не гарантирую вообще ничего. В эту тему интересный случай произошел у нас на работе.
Чувак вполне успешно прошел все этапы собеседования. Во время собеседования он показал отличные технические знания, да и в целом показался адекватным. А на работу вышел, кажется, кто-то другой.
На стендапах у него часто возникали "технические проблемы", из-за которых он то не отвечал совсем, то переспрашивал, то отвечал как-то невпопад. В рабочее время до него было невозможно дописаться, отвечал он с задержкой в 3-4 часа, а иногда и вовсе на следующий деть.
Его подержали пару месяцев, а потом уволили. Есть подозрение, что он просто одновременно работал на нескольких работах.
К сожалению, такие вещи сложно выяснить на собеседовании
А вот другой пример, с моей предыдущей работы.
Чувак был отличный технический специалист. У него был крутой опыт и глубокие технические знания. На собеседовании он выглядел очень воодушевленный и в красках рассказывал о том, как он может решить задачи которые перед ним планировали поставить,.
Чувак вышел на работу, начал разрабатывать архитектуру, и в какой-то момент стало заметно, что он работает медленнее, а воодушевление куда-то испарилось. Это стало очевидно не сразу, но спустя несколько месяцев не заметить было невозможно.
Судя по всему, чувак просто выгорел. Но поскольку собеседование это стресс, то он взбодрился и выглядел воодушевлено, но вот во время рабочей рутины, ему становилось скучно.
Можно ли увидеть это на собеседовании?
Скорее всего оба эти случаи не так очевидны, как недостаток технических знаний, но если иметь список вопросов, о кандидате на которые хочется ответить в процессе собеседования и вынести туда эти и другие, косвенно можно найти ответы на эти вопросы.
😷 COVID прошел, а что осталось?
Можно сказать, что пандемия COVID ушла в историю. Сегодня мне бы хотелось порассуждать о том, как пандемия повлияла на работу IT сферу вокруг меня.
☎️ Зум встреча - встреча по-умолчанию
До 2020 удаленные сотрудники часто чувствовали себя обделенными. Я помню ощущение потери контекста
когда по каким-то причинам приходилось по долгу работать из дома.
Для коллег дефолтный режим работы из офиса, поэтому тебя могу забыть подключить на встречу, или договориться о чем-то в кофе пойнте и тебе об этом не сказав. Да и вообще, человек подключенный ко встрече удаленно получает сильно меньше вербальной и невербальной информации, чем присутствующие лично. И на долгосрочной перспективе это приводит к недопониманию.
Сейчас у нас у любой встречи есть ссылка на зум. И даже находясь в одном офисе, мы часто не идем в отдельную комнату, а просто созваниваемся в зуме.
🦼 Гибридный формат - нова реальность.
Если компания против удаленной работы, для того, чтобы не терять кадры, предлагают гибрид. Такой формат есть в 29 из 31 вакансии, которые мне пришли за последнее время.
Это расплывчатый термин. Он может означать как: "приходи в любой день в офис" , так и "Ладно по средам можешь остаться дома". Тем не менее, раньше про такой режим я вообще не слышал.
И это плавно приводит к следующему, пожалуй самому значительному последствию.
💨 Люди почувствовали вкус удвоение.
Есть какая-то часть людей, которым комфортно работать только из офиса. Есть часть, которым комфортно работать только из дома, и часть которым удобно совмещать.
Понять к какой группе ты относишься можно было только на практике. И вот все мы попробовали каково это работать полностью удаленно. Кстати, тебе как?
Именно поэтому людей, которым нравится работать из дома, или ходить в офис несколько раз в неделю сильно прибавилось.
Я свой путь разработчика начинал на фрилансе, и если честно тогда мне не понравилось. Поэтому я был сторонник работы в офисе. Через три года удаленной работы, я сменил свое мнение. Я научился работать дома, научился отделять рабочее время от личного, научился само организовывать себя. Теперь в офис я хочу, чтобы пообщаться с коллегами или сыграть в бильярд.
Думаю поэтому все компании теперь предлагают гибрид.
🏢 Офисы никуда не делись
С другой стороны офисы тоже никуда не делись. Поскольку по-прежнему, есть значимое количество тех, кто хочет работать там.
Но офисы начинают претерпевать изменения.
В офисах становится меньше переговорок на большое количество человек. Зато появляется огромное количество будок для одиночек. А большие пространства делятся на более маленькие.
Маятник качается туда-сюда. И если COVID оттянул маятник в одну сторону, то сейчас мы находимся в состоянии отката. Компании с сильным брендом стараются вернуть людей в офис. Более хитрые компании своенравно трактуют термин "Гибрид". Но COVID так сильно оттянул маятник, что само основание оказалось на новом месте. А значит условия труда и особенности работы уже не вернутся в 2020.
Можно сказать, что пандемия COVID ушла в историю. Сегодня мне бы хотелось порассуждать о том, как пандемия повлияла на работу IT сферу вокруг меня.
☎️ Зум встреча - встреча по-умолчанию
До 2020 удаленные сотрудники часто чувствовали себя обделенными. Я помню ощущение потери контекста
когда по каким-то причинам приходилось по долгу работать из дома.
Для коллег дефолтный режим работы из офиса, поэтому тебя могу забыть подключить на встречу, или договориться о чем-то в кофе пойнте и тебе об этом не сказав. Да и вообще, человек подключенный ко встрече удаленно получает сильно меньше вербальной и невербальной информации, чем присутствующие лично. И на долгосрочной перспективе это приводит к недопониманию.
Сейчас у нас у любой встречи есть ссылка на зум. И даже находясь в одном офисе, мы часто не идем в отдельную комнату, а просто созваниваемся в зуме.
🦼 Гибридный формат - нова реальность.
Если компания против удаленной работы, для того, чтобы не терять кадры, предлагают гибрид. Такой формат есть в 29 из 31 вакансии, которые мне пришли за последнее время.
Это расплывчатый термин. Он может означать как: "приходи в любой день в офис" , так и "Ладно по средам можешь остаться дома". Тем не менее, раньше про такой режим я вообще не слышал.
И это плавно приводит к следующему, пожалуй самому значительному последствию.
💨 Люди почувствовали вкус удвоение.
Есть какая-то часть людей, которым комфортно работать только из офиса. Есть часть, которым комфортно работать только из дома, и часть которым удобно совмещать.
Понять к какой группе ты относишься можно было только на практике. И вот все мы попробовали каково это работать полностью удаленно. Кстати, тебе как?
Именно поэтому людей, которым нравится работать из дома, или ходить в офис несколько раз в неделю сильно прибавилось.
Я свой путь разработчика начинал на фрилансе, и если честно тогда мне не понравилось. Поэтому я был сторонник работы в офисе. Через три года удаленной работы, я сменил свое мнение. Я научился работать дома, научился отделять рабочее время от личного, научился само организовывать себя. Теперь в офис я хочу, чтобы пообщаться с коллегами или сыграть в бильярд.
Думаю поэтому все компании теперь предлагают гибрид.
🏢 Офисы никуда не делись
С другой стороны офисы тоже никуда не делись. Поскольку по-прежнему, есть значимое количество тех, кто хочет работать там.
Но офисы начинают претерпевать изменения.
В офисах становится меньше переговорок на большое количество человек. Зато появляется огромное количество будок для одиночек. А большие пространства делятся на более маленькие.
Маятник качается туда-сюда. И если COVID оттянул маятник в одну сторону, то сейчас мы находимся в состоянии отката. Компании с сильным брендом стараются вернуть людей в офис. Более хитрые компании своенравно трактуют термин "Гибрид". Но COVID так сильно оттянул маятник, что само основание оказалось на новом месте. А значит условия труда и особенности работы уже не вернутся в 2020.
🤑 Юра, сколько ты зарабатываешь?
Ты знаешь сколько зарабатывает вой коллега? А твой руководитель? Вот и я не знаю, но считаю это не правильно.
Был у меня случай. Мой знакомый аналитик с комплексом самозванца получал не самую большую зарплату. В какой-то момент ему дали в помощники Джуна.
Взяли его на вырост, но джун был плох. Ничего делать не хотел, и через пол года его решили уволить. Создали тикет, куда позвали всех сопричастный, в том числе и моего знакомого.
Оттуда мой знакомый узнал что его подчиненный пол года получал зарплату больше чем он. И это при том, что мой знакомый делал работу за себя, доделывал за джуном и еще и пытался его чему-то учить.
В итоге они уволились вместе.
Сначала уволили джуна, а потом мой знакомый пошел просить прибавку. Абсолютные числа он называть не мог, а в относительных он хотел зарплату х2. Но в компании была политика не повышать больше чем на 20 процентов в пол года. Короче, проще было уволиться.
Почему зарплаты принято скрывать?
У меня нет ответа на этот вопрос. Возможно так компания экономит на тех не может попросить себе ЗП побольше. Возможно, ни у кого из топ менеджментов не хватает яичек сломать статус-кво и публично сказать сколько он получает.
Но мне кажется это должно поменяться.
Я считаю, что команда должна знать сколько получает каждый из ее членов. Так же я считаю что именно команда должна отвечать за процесс изменения размера зарплаты.
А как считаешь ты? Поделить мнением в комментариях?
Ты знаешь сколько зарабатывает вой коллега? А твой руководитель? Вот и я не знаю, но считаю это не правильно.
Был у меня случай. Мой знакомый аналитик с комплексом самозванца получал не самую большую зарплату. В какой-то момент ему дали в помощники Джуна.
Взяли его на вырост, но джун был плох. Ничего делать не хотел, и через пол года его решили уволить. Создали тикет, куда позвали всех сопричастный, в том числе и моего знакомого.
Оттуда мой знакомый узнал что его подчиненный пол года получал зарплату больше чем он. И это при том, что мой знакомый делал работу за себя, доделывал за джуном и еще и пытался его чему-то учить.
В итоге они уволились вместе.
Сначала уволили джуна, а потом мой знакомый пошел просить прибавку. Абсолютные числа он называть не мог, а в относительных он хотел зарплату х2. Но в компании была политика не повышать больше чем на 20 процентов в пол года. Короче, проще было уволиться.
Почему зарплаты принято скрывать?
У меня нет ответа на этот вопрос. Возможно так компания экономит на тех не может попросить себе ЗП побольше. Возможно, ни у кого из топ менеджментов не хватает яичек сломать статус-кво и публично сказать сколько он получает.
Но мне кажется это должно поменяться.
Я считаю, что команда должна знать сколько получает каждый из ее членов. Так же я считаю что именно команда должна отвечать за процесс изменения размера зарплаты.
А как считаешь ты? Поделить мнением в комментариях?
Привет, если ты решил поддержать канал, то это можно сделать
- Boosty
- Patreon
- Крипту
Но я по-прежнему считаю, что все что я делаю должно быть доступно. Поэтому материалы все так же будут публиковаться здесь, на моем сайте, ютубе и дзене.
- Boosty
- Patreon
- Крипту
Но я по-прежнему считаю, что все что я делаю должно быть доступно. Поэтому материалы все так же будут публиковаться здесь, на моем сайте, ютубе и дзене.
boosty.to
Alex Four - Философствую об IT, пишу телеграм боты
Приветы, на связи Алекс. Теперь весь контент будет дублироваться здесь на Бусти. Я по-прежнему считаю, что все мои читатели должны иметь доступ ко всему, что я пишу, тем не менее, я хочу чтобы и у вас, самых благодарных, была возможность отблагодарить…
🔢 Что не так с оценкой работы программиста?
Во всех крупных компаниях, в которых я работал, процесс ревью был устроен по-разному, но всегда убого. И по рассказам коллег из других компаний, там тоже не лучше.
Обычно это происходит так:
☝️ собирается обратная связь от коллег
✌️ собирается обратная связь от руководителей
🤷 руководители, которые не понимают чем занимается конкретный разработчик, оценивают его работу
Я вижу несколько проблем в этой схеме.
Во-первых, руководитель должен оценить, но он не знает, чем занимался сотрудник которого оценивают.
Во-вторых, каждому из руководителей приходится в короткий период (1-2 дня) оценить много, очень много людей
Стоит помнить, что любой человек ленив. И в единичном случае готов разобраться, но когда людей много все сводится к какому-то очень простому алгоритму. Поэтому чтобы это было проще, в некоторых компаниях вводят измеримый показатель. Это может быть количество коммитов, количество закрытых тикетов, количество проработанных часов. Что угодно у чего есть цифра. Я это называю индусским подходом. Причем, далеко не всегда параметр оценки известен всем.
В третьих, обратная связь. Я уже достаточно давно на нее не рассчитываю после ревью.
Получил прибавку, значит молодец, все делал правильно! А что все? Догадайся сам!
Можно ли с этим что-то сделать?
Да, нужно просто делегировать. Делегировать оценку каждого сотрудника тому, кто знает как он работает.
Самое очевидное отдать оценку непосредственному руководителю, но это путь к нездоровым отношениям в команде. Я же предлагаю отдать решение за оценку сотрудника команде, в которой этот сотрудник работает.
Представьте голосование, в котором каждый оценивает как поработал его коллега. При этом каждый должен высказаться и как-то аргументировать свою оценку.
Есть три оценки, плохо, хорошо и отлично. По-умолчанию, все работают хорошо, и большая часть получает именно такую оценку. Чтобы получить какую-то другую оценку, необходимо чтобы кто-то поставил ее и аргументировал. И главное, команда должна согласилась с этим решением.
Кто-то может сказать, что это почва для сговора. Да, но это просто решается. Например, в команде не может быть больше 1-й оценки отлично, а еще подобные обсуждения должны проходиться открыто. Другими словами, любой человек из компании может прийти на встречу и послушать. А еще такие встречи можно записывать.
Самые страшные поступки люди совершают, веря что об этом никто не узнает. Поэтому огласка - это отличный инструмент против злоупотреблений.
Второй инструмент - это статистика. Можно отслеживать различные аномалии. Но наличие аномалии не должно автоматически означать что решение, которое приняла команда неверное. Нужно уважать решение команды и очень хорошо разобраться прежде чем что-то с ним делать.
Статистика вещь обоюдоострая. С одной стороны она позволяет выявить аномалии, а с другой цифры могут подгоняться.
Разумеется команде заранее нужно объяснить правила игры. Причем рассказать не только правила, но и почему эти правила появились. Например, открытость нужна для того, что бы избежать злоупотреблений. Запись делается для того, чтобы можно было вернуться к обсуждению в случае возникновения аномалии или на следующий ревью. Необходимо так же объяснить, что обсуждение должно вестись в уважительной манере, а обстановка не должна быть токсичной. Возможно, для этого потребуется присутствие человека, который будет фасилитировать беседу в нужном направлении.
Ну и самое главное, нужно дать возможность сотрудникам полностью погрузиться в процесс оценки. Необходимо освободить людей от рабочих задач. Никто не будет приходить на обсуждение в другую команду, если с этим будет конкурировать горящий релиз.
В результате обсуждения у каждого будет возможность посмотреть на себя глазами коллег, получить адекватную обратную связь. А так же высказаться, и быть услышанным.
Если тебе понравился пост, меня теперь можно отблагодарить на бусти. Спасибо, что дочитал до конца. Хорошего дня)
Во всех крупных компаниях, в которых я работал, процесс ревью был устроен по-разному, но всегда убого. И по рассказам коллег из других компаний, там тоже не лучше.
Обычно это происходит так:
☝️ собирается обратная связь от коллег
✌️ собирается обратная связь от руководителей
🤷 руководители, которые не понимают чем занимается конкретный разработчик, оценивают его работу
Я вижу несколько проблем в этой схеме.
Во-первых, руководитель должен оценить, но он не знает, чем занимался сотрудник которого оценивают.
Во-вторых, каждому из руководителей приходится в короткий период (1-2 дня) оценить много, очень много людей
Стоит помнить, что любой человек ленив. И в единичном случае готов разобраться, но когда людей много все сводится к какому-то очень простому алгоритму. Поэтому чтобы это было проще, в некоторых компаниях вводят измеримый показатель. Это может быть количество коммитов, количество закрытых тикетов, количество проработанных часов. Что угодно у чего есть цифра. Я это называю индусским подходом. Причем, далеко не всегда параметр оценки известен всем.
В третьих, обратная связь. Я уже достаточно давно на нее не рассчитываю после ревью.
Получил прибавку, значит молодец, все делал правильно! А что все? Догадайся сам!
Можно ли с этим что-то сделать?
Да, нужно просто делегировать. Делегировать оценку каждого сотрудника тому, кто знает как он работает.
Самое очевидное отдать оценку непосредственному руководителю, но это путь к нездоровым отношениям в команде. Я же предлагаю отдать решение за оценку сотрудника команде, в которой этот сотрудник работает.
Представьте голосование, в котором каждый оценивает как поработал его коллега. При этом каждый должен высказаться и как-то аргументировать свою оценку.
Есть три оценки, плохо, хорошо и отлично. По-умолчанию, все работают хорошо, и большая часть получает именно такую оценку. Чтобы получить какую-то другую оценку, необходимо чтобы кто-то поставил ее и аргументировал. И главное, команда должна согласилась с этим решением.
Кто-то может сказать, что это почва для сговора. Да, но это просто решается. Например, в команде не может быть больше 1-й оценки отлично, а еще подобные обсуждения должны проходиться открыто. Другими словами, любой человек из компании может прийти на встречу и послушать. А еще такие встречи можно записывать.
Самые страшные поступки люди совершают, веря что об этом никто не узнает. Поэтому огласка - это отличный инструмент против злоупотреблений.
Второй инструмент - это статистика. Можно отслеживать различные аномалии. Но наличие аномалии не должно автоматически означать что решение, которое приняла команда неверное. Нужно уважать решение команды и очень хорошо разобраться прежде чем что-то с ним делать.
Статистика вещь обоюдоострая. С одной стороны она позволяет выявить аномалии, а с другой цифры могут подгоняться.
Разумеется команде заранее нужно объяснить правила игры. Причем рассказать не только правила, но и почему эти правила появились. Например, открытость нужна для того, что бы избежать злоупотреблений. Запись делается для того, чтобы можно было вернуться к обсуждению в случае возникновения аномалии или на следующий ревью. Необходимо так же объяснить, что обсуждение должно вестись в уважительной манере, а обстановка не должна быть токсичной. Возможно, для этого потребуется присутствие человека, который будет фасилитировать беседу в нужном направлении.
Ну и самое главное, нужно дать возможность сотрудникам полностью погрузиться в процесс оценки. Необходимо освободить людей от рабочих задач. Никто не будет приходить на обсуждение в другую команду, если с этим будет конкурировать горящий релиз.
В результате обсуждения у каждого будет возможность посмотреть на себя глазами коллег, получить адекватную обратную связь. А так же высказаться, и быть услышанным.
Если тебе понравился пост, меня теперь можно отблагодарить на бусти. Спасибо, что дочитал до конца. Хорошего дня)