> твои сотрудники - это самое ценное, что у тебя есть, поэтому относиться к ним надо по-человечески
Полностью разделяю вашу точку зрения. Одна из важнейших задач любого руководителя — это забота о его команде, обеспечение комфортных условий ее работы.
> Вероятнее всего статью минусуют из-за супернеудачной обложки
У меня были сомнений по поводу обложки. Сперва думал выбрать что-то нейтральное, но не смог придумать и решил все же рискнуть.
> Сессионки в 30-40 минут учат принимать решения в основном быстро и на основе сиюминутных данных...
Согласен с вами. В Скваде ты больше играешь на короткую/среднюю дистанцию. В контексте погружения в роль лида мне кажется это самое оно. Умение реагировать на постоянно меняющиеся вводные, разные контексты. Плюс, отработка социальной составляющей у игры на уроне. Неплохой старт, как мне кажется.
> В комментариях справедливо заметили Eve, в котором стратегического элемента ощутимо больше.
О данном мастодонте только слышал, знаю, что игра циклопических масштабов. Не было опыта игры в нее.
> Foxhole
Если не ошибаюсь, то в этой игре ты такая же часть общего механизма, просто у тебя куда больше опций, чем можно заняться (операционка всякая, логистика). Плюс, текстовый формат общения, менее динамичный. Игрушка зачет)
> Ну да, ну да, а потом у нас работают аналитики и разработчики, которые задачу могут выполнить только с помощью стековерфлоу, не понимая как и что работает.
Вы возводите в абсолют. Разработчики разных уровней и компетенций пользуются ресурсами вида stack overflow, chat gpt и прочими "ускоряторами", не обязательно вникая в код на 100%. Это никак не говорит о разработчике, что он не думает.
Не во все следует вникать детально. На то и есть уже готовые алгоритмы, которые были оптимизированы спецами. Уже есть библиотеки и фреймворки, которые решают прикладные задачи. Для решения большинства бизнес-задач глубокие знания алгоритмов не нужны. Отсутствие этих знаний и навыков никак не скажется на твоей работоспособности и эффективности. Более того, заняться оптимизацией можно будет потом.
Если речь идет о прикладном программисте, который создает общие инструменты, пишет библиотеки/фреймворки, занимается оптимизацией производительности, то тогда да. На подобной роли хорошо бы шарить за алгоритмы, структуры данных, паттерны и еще куча других моментов, потому что такова спецификаработы.
Раз уж на то пошло, то тогда и библиотеками/фреймворками лучше не пользоваться, не вникнув в них до конца. Безусловно, ты будешь хорошим специалистом, если будешь понимать, как работает твой инструмент. Но...где та точка, достигнув которой, ты сможешь сказать, что знаешь как оно работает?
> У человека, который разбирается в том, как что-то работает и почему оно работает именно так, всегда будет преимущество перед выпускниками курсов "программируем на Пайтон". И это прекрасно.
Лично никогда не сталкивался с дискриминацией и никогда не видел предвзятого отношения к собеседуемым со стороны коллег. Так что опыта в данном вопросе у меня нет.
Ну, как я написал в другом комментарии, вы сделали из этого явное противопоставление.
Уловил суть. Подобная формулировка показалась предвзятой и настроена на предвзятость и выглядит как противоречие. Могу заверить, что это лишь формулировка, целей создать такое впечатление не было. Я посчитал, что "драйвер" звучит слишком абстрактно и решил именно этот термин раскрыть.
Считаю, что нужно уважительно относиться к коллегам, даже если им не довелось сделать что-то эдакое.
Поддерживаю. Думал, что раскрою этот тезис больше, но вышло наоборот. Признаю, что формулировка неоднозначная.
Интересно, спасибо, что поделились. А сколько обычно занимает процесс закрытия такого проекта? Это присходит в асинхронном режиме? Почему решили не выдавать все задание целиком?
Хотел еще добавить кое-что. По факту, человек все делает через алгоритмы. Мы программируем на алгоритмах, наши программы — комбинация алгоритмов. Другой вопрос, какая их сложность, для чего используются. Если говорить конкретно, то алгоритмы для обхода графа мне не нужны сейчас. Я знаю, что такие есть в готовом виде, о них написано много материалов. Если понадобятся, возьму готовые. Если задача будет требовать, то погружусь детальнее. Все зависит от целей. Например, мне в разы интереснее стало погружаться в создание и развитие продуктов. Мне уже не так важно, на каких технологиях это будет сделано — не принципиальный и не первостепенный вопрос, лишь бы создавало ценность. А есть инженеры, которым нравится изучать вопрос детально: раскладывать технологии на винтики, разбирать механики. Супер! Такие люди тоже нужны, без них никуда. Вопрос в том, где они нужны и в каком количестве.
В целом, вы правы. Видел не одну статью на эту тематику, но все же решился написать, так как это был внутренний позыв хайпануть.
Что касается полезности/бесполезности материала, это вещь субъективная. Не претендовал на смену мирового порядка, но если хотя бы 1 человек вынес для себя что-то новое и увидел альтернативу, которую можно внести в свою практику, то я считаю задачу выполненной.
Вы правы, в настоящей работе часто многое неизвестно, так же присутствует человеческий фактор. Хаос, бюрократия и прочее. И в этих реалиях приходится жить. Что касается тестового задания, то на мой взгляд, это не mind games, это просто халтура. В случае JB она оказалась незначительной, я по большей части придрался к оформлению, а задавать вопросы не было необходимости, так как разобрался с условиями. Я стараюсь задавать вопросы по тестовым в крайних случаях, так как, во-первых, люди работают, а я их буду отвлекать. Во-вторых, переписка чаще всего идет по почте, а это не самый быстрый канал коммуникации, а ручки то чешутся.
Спасибо за комментарий! Да, сам из собеса вынес пару интересных фактов. Это, правда, зависит от собеседующих. Некоторые могут прям подробно рассказать про механики, накидать ссылок почитать. За это таким ребятам респект.
Поясню. В конкретном случае я не маркировал задачу на переворот матриц как сложную или легкую. Подметил сам факт наличия данной задачи в списке задач. На мой взгляд, эта задача крайне скучная. На самом деле в том собеседовании был другой забавный нюанс, который я не обозначил, связанный с этой задачей. Собеседущие постоянно вносили корректировки в условия. И нужно было в конце выдать функцию, которая может переворачивать матрицы n на m с использованием только одного цикла на всю функцию.
Спасибо за комментарий! Считаю бесполезными их для себя. Опять же, если вы разрабатываете низкоуровневые вещи, новые алгоритмы, движки, утилитарное ПО - то это важный навык, которой стоит проверять.
Спасибо за комментарий! Под mvp вы имеете в виду тестовое задание? Если да и это возможно, то поделитесь, пожалуйста, заданием подробнее, звучит интересно
Благодарю за отзыв!
> твои сотрудники - это самое ценное, что у тебя есть, поэтому относиться к ним надо по-человечески
Полностью разделяю вашу точку зрения. Одна из важнейших задач любого руководителя — это забота о его команде, обеспечение комфортных условий ее работы.
Это база. Они все могут
Спасибо за комментарий!
Согласен. Попробуй объяснить большой пачке людей, что в огне стоять не надо
Спасибо за отзыв!
Да даже "дворцовые" интриги. К сожалению, не играл в этот проект.
> Организация деятельности сотен человек
Это планирование уже совершенного другого уровня. Подойдет для тренировки C-level позиции
:D
Большое спасибо за отзыв!
> Вероятнее всего статью минусуют из-за супернеудачной обложки
У меня были сомнений по поводу обложки. Сперва думал выбрать что-то нейтральное, но не смог придумать и решил все же рискнуть.
> Сессионки в 30-40 минут учат принимать решения в основном быстро и на основе сиюминутных данных...
Согласен с вами. В Скваде ты больше играешь на короткую/среднюю дистанцию. В контексте погружения в роль лида мне кажется это самое оно. Умение реагировать на постоянно меняющиеся вводные, разные контексты. Плюс, отработка социальной составляющей у игры на уроне. Неплохой старт, как мне кажется.
> В комментариях справедливо заметили Eve, в котором стратегического элемента ощутимо больше.
О данном мастодонте только слышал, знаю, что игра циклопических масштабов. Не было опыта игры в нее.
> Foxhole
Если не ошибаюсь, то в этой игре ты такая же часть общего механизма, просто у тебя куда больше опций, чем можно заняться (операционка всякая, логистика). Плюс, текстовый формат общения, менее динамичный. Игрушка зачет)
Спасибо за комментарий!
> Ну да, ну да, а потом у нас работают аналитики и разработчики, которые задачу могут выполнить только с помощью стековерфлоу, не понимая как и что работает.
Вы возводите в абсолют. Разработчики разных уровней и компетенций пользуются ресурсами вида stack overflow, chat gpt и прочими "ускоряторами", не обязательно вникая в код на 100%. Это никак не говорит о разработчике, что он не думает.
Не во все следует вникать детально. На то и есть уже готовые алгоритмы, которые были оптимизированы спецами. Уже есть библиотеки и фреймворки, которые решают прикладные задачи. Для решения большинства бизнес-задач глубокие знания алгоритмов не нужны. Отсутствие этих знаний и навыков никак не скажется на твоей работоспособности и эффективности. Более того, заняться оптимизацией можно будет потом.
Если речь идет о прикладном программисте, который создает общие инструменты, пишет библиотеки/фреймворки, занимается оптимизацией производительности, то тогда да. На подобной роли хорошо бы шарить за алгоритмы, структуры данных, паттерны и еще куча других моментов, потому что такова специфика работы.
Раз уж на то пошло, то тогда и библиотеками/фреймворками лучше не пользоваться, не вникнув в них до конца. Безусловно, ты будешь хорошим специалистом, если будешь понимать, как работает твой инструмент. Но...где та точка, достигнув которой, ты сможешь сказать, что знаешь как оно работает?
> У человека, который разбирается в том, как что-то работает и почему оно работает именно так, всегда будет преимущество перед выпускниками курсов "программируем на Пайтон". И это прекрасно.
Да, все так.
Спасибо за комментарий.
Мне понравилась идея с заданием про портрет интервьера. Пожалуй, возьму на заметку для последующих интервью)
Спасибо за комментарий.
Лично никогда не сталкивался с дискриминацией и никогда не видел предвзятого отношения к собеседуемым со стороны коллег. Так что опыта в данном вопросе у меня нет.
Уловил суть. Подобная формулировка показалась предвзятой и настроена на предвзятость и выглядит как противоречие. Могу заверить, что это лишь формулировка, целей создать такое впечатление не было. Я посчитал, что "драйвер" звучит слишком абстрактно и решил именно этот термин раскрыть.
Поддерживаю. Думал, что раскрою этот тезис больше, но вышло наоборот. Признаю, что формулировка неоднозначная.
Благодарю за ваш отзыв! Греет душу
Интересно, спасибо, что поделились. А сколько обычно занимает процесс закрытия такого проекта? Это присходит в асинхронном режиме? Почему решили не выдавать все задание целиком?
Хотел еще добавить кое-что. По факту, человек все делает через алгоритмы. Мы программируем на алгоритмах, наши программы — комбинация алгоритмов. Другой вопрос, какая их сложность, для чего используются.
Если говорить конкретно, то алгоритмы для обхода графа мне не нужны сейчас. Я знаю, что такие есть в готовом виде, о них написано много материалов. Если понадобятся, возьму готовые. Если задача будет требовать, то погружусь детальнее.
Все зависит от целей. Например, мне в разы интереснее стало погружаться в создание и развитие продуктов. Мне уже не так важно, на каких технологиях это будет сделано — не принципиальный и не первостепенный вопрос, лишь бы создавало ценность. А есть инженеры, которым нравится изучать вопрос детально: раскладывать технологии на винтики, разбирать механики. Супер! Такие люди тоже нужны, без них никуда. Вопрос в том, где они нужны и в каком количестве.
Спасибо за комментарий!
В целом, вы правы. Видел не одну статью на эту тематику, но все же решился написать, так как это был внутренний позыв
хайпануть.Что касается полезности/бесполезности материала, это вещь субъективная. Не претендовал на смену мирового порядка, но если хотя бы 1 человек вынес для себя что-то новое и увидел альтернативу, которую можно внести в свою практику, то я считаю задачу выполненной.
P.S. Я не тимлид c:
Спасибо за комментарий!
Вы правы, в настоящей работе часто многое неизвестно, так же присутствует человеческий фактор. Хаос, бюрократия и прочее. И в этих реалиях приходится жить. Что касается тестового задания, то на мой взгляд, это не mind games, это просто халтура. В случае JB она оказалась незначительной, я по большей части придрался к оформлению, а задавать вопросы не было необходимости, так как разобрался с условиями. Я стараюсь задавать вопросы по тестовым в крайних случаях, так как, во-первых, люди работают, а я их буду отвлекать. Во-вторых, переписка чаще всего идет по почте, а это не самый быстрый канал коммуникации, а ручки то чешутся.
Спасибо за комментарий! Да, сам из собеса вынес пару интересных фактов. Это, правда, зависит от собеседующих. Некоторые могут прям подробно рассказать про механики, накидать ссылок почитать. За это таким ребятам респект.
Спасибо за комментарий.
Поясню. В конкретном случае я не маркировал задачу на переворот матриц как сложную или легкую. Подметил сам факт наличия данной задачи в списке задач. На мой взгляд, эта задача крайне скучная.
На самом деле в том собеседовании был другой забавный нюанс, который я не обозначил, связанный с этой задачей. Собеседущие постоянно вносили корректировки в условия. И нужно было в конце выдать функцию, которая может переворачивать матрицы n на m с использованием только одного цикла на всю функцию.
Спасибо за ваш отзыв, на душе приятно)
Спасибо за комментарий! Считаю бесполезными их для себя. Опять же, если вы разрабатываете низкоуровневые вещи, новые алгоритмы, движки, утилитарное ПО - то это важный навык, которой стоит проверять.
Спасибо за комментарий! Под mvp вы имеете в виду тестовое задание? Если да и это возможно, то поделитесь, пожалуйста, заданием подробнее, звучит интересно