Говорю вам "спасибо" из 2024 года. Я неделю пробовал быстро работать на маке... Переключение между приложениями - боль.
Я понимаю про другую идеалогию, но если она неудобная для работы, значит, она неудобна для работы. И через сторонние программы это решается либо криво, либо как на Windows.
Про себя я понял, что я и макос не подходим друг другу.
Я согласен с тем, что кадровые решения стоит принимать на следующий день. Только я рассматриваю ситуацию, когда человек в принципе не готов (или не может по каким-то причинам) принять это кадровое решение.
На осознание своих сомнений и колебаний нужно много времени. На оценку последствий своих решений нужно много времени. Подготовка к принятию решению занимает не один день. Вот переход от состояния "я ещё думаю" к состоянию "я решил" уже возможно за 60 секунд. Когда решение принято, и мысли переключаются с разбора сомнений к составлению плана действий.
Отвечу на вам вопрос "И даже дела не надо передавать ?" цитатой из статьи:
важная часть решения про увольнение сотрудника — это план как его заменить. Выпишите на листок бумаги что именно делал сотрудник, за какие фичи отвечал, есть ли уникальные знания. Теперь можно заняться перераспределением обязанностей.
Может это не явно, но перераспределение обязанностей включает в себя передачу дел от увольняемого к другим сотрудникам.
Резонное замечание про начало переговоров. Зависит конечно от человека, не у всех будет желание вставать в позицию
Про "озаботиться заранее" - второй блок на схеме про шаги в увольнении.
Не все работают по ТК РФ. Многие работают по договорам подряда, где процесс увольнения проще и не так жёстко регулируется законом. Так что есть ситуации, когда можно просто сказать: "Вы уволены".
Читал. Про сложности понимаю. Статья всё же про то, что некоторые не могут решиться на увольнение сотрудника как таковое. Если есть желание, то отдел кадров в помощь. Умение вести такие переговоры - отдельная тема.
Ключевой момент для меня в том, что я не ставлю задачу в каждом кандидате найти талант. На это уйдёт много времени и душевных сил. Я пробовал, оно себя не оправдало. Сейчас я ставлю задачу найти подходящего кандидата под свои критерии.
Успехи и ошибки в найме нескольких десятков дата-инженеров говорят о том, что есть тенденция к тому, что кандидаты, успешно прошедшие такие тестовые задания, хорошо показывают себя в реальной работе. Тенденции того, что кандидаты, не справившиеся с тестовым задания, оказываются скрытыми талантами, не наблюдается. На это и опираюсь.
Я допускаю, что иногда мои собеседования дают ложноотрицательный результат (отказ достойному кандидату), но не думаю, что процент таких ошибок очень высок.
То есть Вы берете на работу первого попавшегося подходящего, не выбирая лучшего из лучших?
Да. Первого подходящего. Может быть не лучшего, но достаточно хорошего. Главное определиться с уровнем "достаточно". Очень сокращает время поиска.
То есть если в резюме имеются ссылки на проекты и достижения, то смотреть их Вам некогда?
Смотрю всё это на этапе скрининга. Если меня всё устраивает, то я назначаю тех. собеседование. При наличии ссылок на проекты или репозитории, могу оставить себе заметку, что тестовые задания можно не давать, качество кода меня устраивает.
Так «по каким-то» или «по формальным»?
Вы можете определить для себя сами свои критерии. Бывает, что у человека на руках несколько офферов, тогда нужно понять стоит ли дальше вести диалог, что может привлечь его именно в нашу компанию. Или видно, что человек токсичный. Или чувствует себя "звездой", которой все должны.
Вы уверены, что ваше чутьё совпадает с чутьём остальных членов команды?
Уверен. Если собеседую для другой команды, назначаю дополнительный звонок с тем тимлидом. Или всей командой. Но так как я набираю людей, то обычно они все уживаются с друг другом. Беру на себя этот риск.
Стрессоустойчивость давно исчезла из списка требований в IT-вакансияx.
Для разных людей разные ситуации вызывают стресс. Я люблю выступать публично, с удовольствием сам прохожу собеседования. Для кого-то это будет стрессовыми ситуациями. Важно умение человека справляться со своим собственным ощущением стресса. Для кого-то стендап на английском языке будет стрессом. Для кого-то норм. Я не требую какой-то абстрактной стрессоустойчивости, но умение с ней справляться приветствуется.
Собеседование для большинства интровертов айтишников — стресс.
Что же может быть более спокойного для интроверта, чем вернуться к написанию кода, а не отвечать на сложные вопросы, глядя в глаза незнакомому человеку? Вот они таблицы, вот он код, вот сидим спокойно пишем. Код-ревью потом тоже будет стресс вызывать?
Быстрые собеседования — очередной способ избежать выполнения работы, которую надо выполнять, но не хочется.
Сколько по вашему мнению нужно проводить собеседование? Как его спланировать, чтобы избежать стресса с обеих сторон и найти лучших специалистов?
Слишком долго. К тому же надо как-то отсечь "профессиональных болтунов", которые рассуждают прекрасно, а вот с конкретными делами у них сложно. Были на моей практике такие уникумы.
В том-то и прикол, что ладно оконные функции, часть дата-инженеров джойны не понимает. Поэтому практика показала, что достаточно уверенного понимания простых запросов, чтобы в работе показывать себя достаточно хорошо.
Я никогда не жду точного решения проблемы в таком случае. Интересно сколько человек может выдать гипотез и будут ли среди них правильные. Или хотя бы в правильном направлении.
Например, если джавист умеет пользовать профайлером, то скорее всего он капал в сторону оптимизации производительности. Если в случае с падающим джава-приложением кандидат предложит воспользоваться профайлером, это значительно повышает шансы того, что он найдёт и исправит ошибку в реальной работе.
Вообще собеседование больше похоже на некое предсказание: будет толк от человека или не будет. На 100% никогда не скажешь. Но процентов на 80% вполне можно.
Где-то 15% техсобеседований сейчас заканчиваются оффером.
В транскрипте не вижу смысла, потому что никто не будет его перечитывать. Я принимаю решение, я принимаю его сразу после собеседования. Код тестовых заданий и оценки ответов на вопросы сохраняю.
Я тоже считаю, что упавшие проды - это плохой признак. Работать надо спокойно, размеренно, с удовольствием и минимальным уровнем стресса. Героизм - это признак плохого менеджмента.
Лайв-кодинг для питонистов, которых я собеседовал, был адовым стрессом. Никто не помнит названия и параметры методов. Циклы пишут с трудом. Объявить класс - целый подвиг. Но это питонисты, к ним отдельный разговор.
А дата-инженер вроде как пользуется SQL каждый день, синтаксис простейший, почему лайв-кодинг должен вызывать стресс? Я прошу всего два запроса: один с 1 джойном, другой - с джойном и группировкой по двум столбцам. Я брал пару кандидатов, которые туго выполнили тестовые задания. В итоге пришлось уволить через пару месяцев. Но все те, кто работают, сделали тестовые задания хорошо. Весьма очевидная корреляция на мой взгляд. Да, не 100% гарантия, но достаточно надёжный показатель.
Если человек не понимает отличия джойнов (left, right, inner, outer), то вряд ли он когда-то копался в оптимизации запросов. И вряд ли он выдаст что-то приличное как дата-инженер. И не важно на SQL надо написать или на Python (Pandas например). Или сможет сделать и понять схему "звезда" или "снежинка".
Есть базовые вещи, без понимания которых нет надежды на что-то неординарное в решении задач. Никто не пишет сортировки в реальной работе, но какие они бывают надо хотя бы знать.
Собеседование, - это для большинства хороших инженеров ультрастрессовая ситуация
Иногда это видно, и я пытаюсь расслабить кандидата. С другой стороны, это показатель того, как человек справляется со стрессовыми ситуациями. В обычной работе они тоже случаются. А если прод упал и начальник материться на чём свет стоит, что станет делать кандидат, который плохо справляется со стрессом на собеседовании?
Я тоже не пытаюсь никого завалить, но какой-то теорминимум у кандидата должен быть. Если не освоено деление столбиком, то вряд ли он будет разбираться в производных второго порядка.
Говорю вам "спасибо" из 2024 года. Я неделю пробовал быстро работать на маке... Переключение между приложениями - боль.
Я понимаю про другую идеалогию, но если она неудобная для работы, значит, она неудобна для работы. И через сторонние программы это решается либо криво, либо как на Windows.
Про себя я понял, что я и макос не подходим друг другу.
Я согласен с тем, что кадровые решения стоит принимать на следующий день. Только я рассматриваю ситуацию, когда человек в принципе не готов (или не может по каким-то причинам) принять это кадровое решение.
На осознание своих сомнений и колебаний нужно много времени. На оценку последствий своих решений нужно много времени. Подготовка к принятию решению занимает не один день. Вот переход от состояния "я ещё думаю" к состоянию "я решил" уже возможно за 60 секунд. Когда решение принято, и мысли переключаются с разбора сомнений к составлению плана действий.
Отвечу на вам вопрос "И даже дела не надо передавать ?" цитатой из статьи:
Может это не явно, но перераспределение обязанностей включает в себя передачу дел от увольняемого к другим сотрудникам.
Встречался со случаями, когда испытательный срок проходил, а начинающий тимлид всё ещё верил с сотрудника.
И цитата из текста статьи:
Спасибо за конструктивный комментарий, я добавил мысль про "договориться" в статью.
Резонное замечание про начало переговоров. Зависит конечно от человека, не у всех будет желание вставать в позицию
Про "озаботиться заранее" - второй блок на схеме про шаги в увольнении.
Не все работают по ТК РФ. Многие работают по договорам подряда, где процесс увольнения проще и не так жёстко регулируется законом. Так что есть ситуации, когда можно просто сказать: "Вы уволены".
Читал. Про сложности понимаю. Статья всё же про то, что некоторые не могут решиться на увольнение сотрудника как таковое. Если есть желание, то отдел кадров в помощь. Умение вести такие переговоры - отдельная тема.
Ключевой момент для меня в том, что я не ставлю задачу в каждом кандидате найти талант. На это уйдёт много времени и душевных сил. Я пробовал, оно себя не оправдало. Сейчас я ставлю задачу найти подходящего кандидата под свои критерии.
Успехи и ошибки в найме нескольких десятков дата-инженеров говорят о том, что есть тенденция к тому, что кандидаты, успешно прошедшие такие тестовые задания, хорошо показывают себя в реальной работе. Тенденции того, что кандидаты, не справившиеся с тестовым задания, оказываются скрытыми талантами, не наблюдается. На это и опираюсь.
Я допускаю, что иногда мои собеседования дают ложноотрицательный результат (отказ достойному кандидату), но не думаю, что процент таких ошибок очень высок.
Много вопросов, отвечаю.
Да. Первого подходящего. Может быть не лучшего, но достаточно хорошего. Главное определиться с уровнем "достаточно". Очень сокращает время поиска.
Смотрю всё это на этапе скрининга. Если меня всё устраивает, то я назначаю тех. собеседование. При наличии ссылок на проекты или репозитории, могу оставить себе заметку, что тестовые задания можно не давать, качество кода меня устраивает.
Вы можете определить для себя сами свои критерии. Бывает, что у человека на руках несколько офферов, тогда нужно понять стоит ли дальше вести диалог, что может привлечь его именно в нашу компанию. Или видно, что человек токсичный. Или чувствует себя "звездой", которой все должны.
Уверен. Если собеседую для другой команды, назначаю дополнительный звонок с тем тимлидом. Или всей командой. Но так как я набираю людей, то обычно они все уживаются с друг другом. Беру на себя этот риск.
Для разных людей разные ситуации вызывают стресс. Я люблю выступать публично, с удовольствием сам прохожу собеседования. Для кого-то это будет стрессовыми ситуациями. Важно умение человека справляться со своим собственным ощущением стресса. Для кого-то стендап на английском языке будет стрессом. Для кого-то норм. Я не требую какой-то абстрактной стрессоустойчивости, но умение с ней справляться приветствуется.
Что же может быть более спокойного для интроверта, чем вернуться к написанию кода, а не отвечать на сложные вопросы, глядя в глаза незнакомому человеку? Вот они таблицы, вот он код, вот сидим спокойно пишем. Код-ревью потом тоже будет стресс вызывать?
Сколько по вашему мнению нужно проводить собеседование? Как его спланировать, чтобы избежать стресса с обеих сторон и найти лучших специалистов?
Практика показывает, что между описанием типов джойнов и умением их применять лежит просто пропасть.
Скрининг делается HR-отделом. Ко мне на собеседования попадают только адекватные кандидаты.
Слишком долго. К тому же надо как-то отсечь "профессиональных болтунов", которые рассуждают прекрасно, а вот с конкретными делами у них сложно. Были на моей практике такие уникумы.
В том-то и прикол, что ладно оконные функции, часть дата-инженеров джойны не понимает. Поэтому практика показала, что достаточно уверенного понимания простых запросов, чтобы в работе показывать себя достаточно хорошо.
Подбрасывание монетки точно даст намного больший процент найма неподходящих людей, так что точно нет =)
Я никогда не жду точного решения проблемы в таком случае. Интересно сколько человек может выдать гипотез и будут ли среди них правильные. Или хотя бы в правильном направлении.
Например, если джавист умеет пользовать профайлером, то скорее всего он капал в сторону оптимизации производительности. Если в случае с падающим джава-приложением кандидат предложит воспользоваться профайлером, это значительно повышает шансы того, что он найдёт и исправит ошибку в реальной работе.
Вообще собеседование больше похоже на некое предсказание: будет толк от человека или не будет. На 100% никогда не скажешь. Но процентов на 80% вполне можно.
Где-то 15% техсобеседований сейчас заканчиваются оффером.
В транскрипте не вижу смысла, потому что никто не будет его перечитывать. Я принимаю решение, я принимаю его сразу после собеседования. Код тестовых заданий и оценки ответов на вопросы сохраняю.
4 открытых позиции есть прямо сейчас. Закрыть надо как можно быстрее. А за два года порядка 30 нанятых дата-инженеров.
Я тоже считаю, что упавшие проды - это плохой признак. Работать надо спокойно, размеренно, с удовольствием и минимальным уровнем стресса. Героизм - это признак плохого менеджмента.
Лайв-кодинг для питонистов, которых я собеседовал, был адовым стрессом. Никто не помнит названия и параметры методов. Циклы пишут с трудом. Объявить класс - целый подвиг. Но это питонисты, к ним отдельный разговор.
А дата-инженер вроде как пользуется SQL каждый день, синтаксис простейший, почему лайв-кодинг должен вызывать стресс? Я прошу всего два запроса: один с 1 джойном, другой - с джойном и группировкой по двум столбцам. Я брал пару кандидатов, которые туго выполнили тестовые задания. В итоге пришлось уволить через пару месяцев. Но все те, кто работают, сделали тестовые задания хорошо. Весьма очевидная корреляция на мой взгляд. Да, не 100% гарантия, но достаточно надёжный показатель.
Если человек не понимает отличия джойнов (left, right, inner, outer), то вряд ли он когда-то копался в оптимизации запросов. И вряд ли он выдаст что-то приличное как дата-инженер. И не важно на SQL надо написать или на Python (Pandas например). Или сможет сделать и понять схему "звезда" или "снежинка".
Есть базовые вещи, без понимания которых нет надежды на что-то неординарное в решении задач. Никто не пишет сортировки в реальной работе, но какие они бывают надо хотя бы знать.
Иногда это видно, и я пытаюсь расслабить кандидата. С другой стороны, это показатель того, как человек справляется со стрессовыми ситуациями. В обычной работе они тоже случаются. А если прод упал и начальник материться на чём свет стоит, что станет делать кандидат, который плохо справляется со стрессом на собеседовании?
Я тоже не пытаюсь никого завалить, но какой-то теорминимум у кандидата должен быть. Если не освоено деление столбиком, то вряд ли он будет разбираться в производных второго порядка.