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