Полагаю это просто бардак, или собесы в разные команды/по разным стекам. Или и то и то Я собеседовался в Т, тоже было прошел штук 10-15 собеседований. Сначала на архитектора 3 штуки. Не мое, но предложили, чего бы не попробовать. Не сложилось - тогда на разраба 3 штуки, оверквалифайд, на тимлида 1-2, снова оверквалифайд, на юнит лида вроде одно и дальше знакомство с командами штук 5 разных. Развлечение на несколько месяцев, и впустую. Но я не жалуюсь лучше так, чем попасть в команду в которую ты не подходишь, или не ту позицию. Но в итоге вот те самые штук 15 собесов - пока к позиции примерились, пока к команде, вот и набежало.
Был опыт в не очень известную компанию, больше 30 часов собеседований на руководящую должность. Но это уже история про собеседования переходящие в онбординг, и это прямо идеально. А вот рассказы про "о боже два этапа на руководителя" это ну прямо смешно.
Выхолащивание подразумевает, что их стало меньше. Как менеджер, скажу что все же, компетенций стало несколько больше. Однако, все еще драматически мало.
Что изменилось, так это потихоньку приходит понимание это факта. Лет 10 назад о таком даже не думали.
Это не вопрос личного мнения. Качается тот навык, который вы практикуете. Читая книги вы практикуете навык чтения книг. Информация - да, ее из книг подчерпнуть можно. Но это знания, а не навыки. Они могут улучшить навыки, но только при условии, если они тут же применяются на практике, к которой прилагается эффективная обратная связь. Потому что, спойлер, когда они будут применены, они будут применены неправильно - ведь нет достаточного навыка, а значит должен быть механизм коррекции. Другими словами, чтение книг поможет, только если оно прилагается к эффективному обучению. А просто читать книги - это абсолютно нерабочий совет. Приблизительно как "вы голодны? Почитайте книгу по кулинарии".
А "среднестатистический работник" это кто? Разработчик, тестировщик, менеджер? На каком стеке? В какой отрасли? С каким опытом работы в какой компании? С какой квалификацией? Хард-софт скилы? Удаленка/офис? Регион/Столица? Все же очень отличается - кто-то хайлоад делает, кто-то круды перекладывает, а кто-то вообще на 1С пишет. Кто-то в отрасли 20 лет, а кто-то 1 год. Вот например есть такое мнение о среднестатистическом разработчике (прямиком из бигтеха) https://t.me/ITBizRadio_chat/3830 А для меня вот наоборот - потому что вокруг меня другие люди. А так в отрасли всякие есть, биоразнообразие.
Сам нанимаю в данный момент, в том самом топе айти контор. И могу сказать, что многие кто работают лидами в итоге на собеседовании показывают посредственные результаты, и как следствие - соответствующие офферы. Хорошие офферы есть, в том числе и в указанные выше суммы. Но получают их не только лишь все. Кто-то получает офферы из диапазона, который вы указали. Оба имеют место быть. Зависит от квалификации... и интервьювера. С наймом все не простт :)
Так что я бы, исходя из своего опыта, из того что человеку стабильно больше 350 за лида не дают, сделал бы вывод, что стоит, видимо, что-то подтянуть, а не на рынок пенять. Больше получить можно совершенно точно. Но не просто - такой запрос должен быть соответственно подкреплен.
Подход замечательный, но тут, как водится есть много нюансов. И с массивами их прямо много. Для того чтобы это работало быстро, нужны следующие, не указанные в статье условия:
1. Данных должно быть немного, либо вам не нужно делать по ним поиск. Почему - для списков кликхаус не строит файл засечек, и не имеет встроенных механизмов поддержания упорядоченности и алгоритма бинарного поиска по массиву. Переход на массивы поднимает сложность поиска до линейной (перебор массива в лоб). При малых выборках это не страшно, и может работать эффективнее, но если у вас в массиве хотя бы десятки тысяч записей, это будет проблемой (засечки работают обычно от 8к).
2. У вас должна быть возможность хранить такой массив в MergeTree или ReplacingMergeTree, т.е. вы записываете его один раз и не дополняете, либо перезаписываете целиком, и при этом его сортируете (руками). Дело в том, что данные хранятся на диске сжато, а сортированные данные сжимаются гораздо лучше. Поэтому плоские таблицы без массивов всегда упорядочены и хорошо жмуться. Если ваш массив будет неупорядочен, он будет занимать существенно больше места на диске. А чтение с диска самая медленная операция. Что вместе с предыдущим (нет засечек, и массив всегда читается весь) может оказать драматически негативный эффект на производительность. Т.е. эффективно будет работать, только если вы этот массив руками записываете - если использовать AggregatingMergeTree, то в нем нет simple аггрегации массивов с сортировкой и/или дедупликацией. И там варианты либо не сортированный массив(который плохо жмется), либо аггрегационный тип хранилища, который еще больше занимает места и требует дообработки (и будет еще медленнее). Могут еще и дубликаты пробегать.
3. Данных в массиве не больше 1млн штук. Это вроде бы по документации лимит массива. Для большинства задач этого достаточно, но стоит всегда об этом помнить, чтобы внезапно не упереться, и не обнаружить что массивы совсем не подходят и все надо переделывать. В статье об этом сказано, но не указано число.
При этом, если вы ни под одно из этих ограничений не попадаете, можно действительно получить существенный прирост к производительности (я вроде бы до x2 выжимал) и потреблению ресурсов (CPU и память). Но если они у вас есть - эффект будет противоположный.
К сожалению даже когда подвезут - ее надо довольно круто допиливать напильником, чтобы асинхронность в ней не тормозила. Реализовали ее весьма так себе.
Например задавать уточняющие вопросы. Пока вы задаете вопросы исключено в формате, почему мы делаем ту дичь, что из вашей собственной головы вылезает. Если вы будете задавать уточняющие вопросы по оригинальным вводным, а не по тем, которые вы сами придумали, получится совсем другой разговор.
Теперь вы придумали, что мы разговаривали с peer коллегами. И что интересно, в обоих сценариях, которые вы сами придумываете, мы всегда творим какую то дичь.
Знаете такую штуку на собеседованиях, как проекционные вопросы?
Во-первых, вы не ответили на мои вопросы, и уже задаете свои. Если вы потрудитесь дать на них ответы, возможно поймете что ваши новые - просто лишены смысла. Вы меня расспрашиваете о звонке руководителю, который сами придумали.
Если под "нет дефицита кадров" вы имеете в виду наличие самих кандидатов на рынке - то тогда его нет. Кандидаты есть. Собеседовать есть кого. Но если добавить уточнение "Кандидатов, которые подходят" - то вот с этим все плохо. На собеседованиях - мрак. Кандидаты есть, а нанять некого.
Во все щели сейчас имеют на собеседованиях
Это вероятно потому, что компании наобжигались нанимать абы каких инженеров. Неудачный найм - очень дорогое, и крайне сомнительное удовольствие. Раньше об этом как-то не думали.
Раньше так и делали. Сейчас есть более продвинутые инструменты.
По-моему, языки программирования как раз за тем и придумали, чтобы не морочить голову ассемблером
Для того чтобы эффективнее разрабатывать. Но если вам требуется производительный код, то без понимания того, как оно работает под капотом далеко не уедешь.
Я правильно понимаю, что человек ещё не уволился с предыдущего места работы, а вы бог знает какими способами нашли телефон его начальника, позвонили ему и обрадовали его новостью, что человек собирается уволиться? Если это было именно так, то вы просто мразоты. Что дальше? Хакерские атаки, фишинг и пробив через даркнет, чтобы больше данных о кандидате выудить?
Нет, понимаете неправильно. Неужели вы сами сделали бы это таким странным образом? Или вы просто взяли, придумали заведомо мразотный сценарий и приписали его незнакомому человеку? Если это так, то вы просто мразоты. Что дальше? Надуманые обвинения, переходы на личности, оскорбления?
СБ существует в очень ограниченном кругу компаний. В подавляющем большинстве такого нет. А там где есть, справедливости ради, это обычно уместно. Если вы сталкиваетесь с СБ в среднестатистической компании, это само по себе довольно много о компании говорит.
Ну, вообще то, если каждый бьет - то да, с рожей что-то не так. А конкретнее с выбором. Потому что в целом, это ненормально, и если воспроизводится стабильно и с разными людьми, то дело уже явно не в них. И нет, максимум информации о кандидате - это не выгода работодателя, это обоюдная выгода, когда все проговаривается на берегу. И работает это в обе стороны. И о каких "ресурсов как у государства речь" вы говорите? Большинство компаний на рекрутинг выделяют сущие гроши. И все ресурсы которые там есть - собеседование и личный нетворкинг. Тоже самое, что есть и у самого кандидата, только компанию или руководителя "пробивать" на порядок проще в силу размера.
Полагаю это просто бардак, или собесы в разные команды/по разным стекам. Или и то и то
Я собеседовался в Т, тоже было прошел штук 10-15 собеседований.
Сначала на архитектора 3 штуки. Не мое, но предложили, чего бы не попробовать. Не сложилось - тогда на разраба 3 штуки, оверквалифайд, на тимлида 1-2, снова оверквалифайд, на юнит лида вроде одно и дальше знакомство с командами штук 5 разных. Развлечение на несколько месяцев, и впустую. Но я не жалуюсь лучше так, чем попасть в команду в которую ты не подходишь, или не ту позицию. Но в итоге вот те самые штук 15 собесов -
пока к позиции примерились, пока к команде, вот и набежало.
Был опыт в не очень известную компанию, больше 30 часов собеседований на руководящую должность. Но это уже история про собеседования переходящие в онбординг, и это прямо идеально.
А вот рассказы про "о боже два этапа на руководителя" это ну прямо смешно.
https://habr.com/ru/articles/882030/#comment_27919474
Вот тут пишут про 15, и в сабже про то, что добавили еще одну. 15, видимо, мало.
И аж целых два этапа собеседований! Кошмар, отдельное техническое собеседование, а потом аж общение с менеджером!
Стало слишком много этапов, потому что это рынок работодателя.
Где то в это время нервно курит в стороне собеседование на разраба в Яндекс.
Выхолащивание подразумевает, что их стало меньше. Как менеджер, скажу что все же, компетенций стало несколько больше. Однако, все еще драматически мало.
Что изменилось, так это потихоньку приходит понимание это факта. Лет 10 назад о таком даже не думали.
Это не вопрос личного мнения.
Качается тот навык, который вы практикуете. Читая книги вы практикуете навык чтения книг.
Информация - да, ее из книг подчерпнуть можно. Но это знания, а не навыки. Они могут улучшить навыки, но только при условии, если они тут же применяются на практике, к которой прилагается эффективная обратная связь. Потому что, спойлер, когда они будут применены, они будут применены неправильно - ведь нет достаточного навыка, а значит должен быть механизм коррекции.
Другими словами, чтение книг поможет, только если оно прилагается к эффективному обучению. А просто читать книги - это абсолютно нерабочий совет. Приблизительно как "вы голодны? Почитайте книгу по кулинарии".
Вот только проблема, чтение книг по психологии(как и любых других) развивает только один навык - навык чтения, а не того, что предполагается в статье.
А "среднестатистический работник" это кто? Разработчик, тестировщик, менеджер? На каком стеке? В какой отрасли? С каким опытом работы в какой компании? С какой квалификацией? Хард-софт скилы? Удаленка/офис? Регион/Столица? Все же очень отличается - кто-то хайлоад делает, кто-то круды перекладывает, а кто-то вообще на 1С пишет. Кто-то в отрасли 20 лет, а кто-то 1 год.
Вот например есть такое мнение о среднестатистическом разработчике (прямиком из бигтеха) https://t.me/ITBizRadio_chat/3830
А для меня вот наоборот - потому что вокруг меня другие люди. А так в отрасли всякие есть, биоразнообразие.
Сам нанимаю в данный момент, в том самом топе айти контор. И могу сказать, что многие кто работают лидами в итоге на собеседовании показывают посредственные результаты, и как следствие - соответствующие офферы. Хорошие офферы есть, в том числе и в указанные выше суммы. Но получают их не только лишь все. Кто-то получает офферы из диапазона, который вы указали. Оба имеют место быть. Зависит от квалификации... и интервьювера. С наймом все не простт :)
Так что я бы, исходя из своего опыта, из того что человеку стабильно больше 350 за лида не дают, сделал бы вывод, что стоит, видимо, что-то подтянуть, а не на рынок пенять. Больше получить можно совершенно точно. Но не просто - такой запрос должен быть соответственно подкреплен.
Подход замечательный, но тут, как водится есть много нюансов. И с массивами их прямо много.
Для того чтобы это работало быстро, нужны следующие, не указанные в статье условия:
1. Данных должно быть немного, либо вам не нужно делать по ним поиск.
Почему - для списков кликхаус не строит файл засечек, и не имеет встроенных механизмов поддержания упорядоченности и алгоритма бинарного поиска по массиву. Переход на массивы поднимает сложность поиска до линейной (перебор массива в лоб). При малых выборках это не страшно, и может работать эффективнее, но если у вас в массиве хотя бы десятки тысяч записей, это будет проблемой (засечки работают обычно от 8к).
2. У вас должна быть возможность хранить такой массив в MergeTree или ReplacingMergeTree, т.е. вы записываете его один раз и не дополняете, либо перезаписываете целиком, и при этом его сортируете (руками). Дело в том, что данные хранятся на диске сжато, а сортированные данные сжимаются гораздо лучше. Поэтому плоские таблицы без массивов всегда упорядочены и хорошо жмуться. Если ваш массив будет неупорядочен, он будет занимать существенно больше места на диске. А чтение с диска самая медленная операция. Что вместе с предыдущим (нет засечек, и массив всегда читается весь) может оказать драматически негативный эффект на производительность. Т.е. эффективно будет работать, только если вы этот массив руками записываете - если использовать AggregatingMergeTree, то в нем нет simple аггрегации массивов с сортировкой и/или дедупликацией. И там варианты либо не сортированный массив(который плохо жмется), либо аггрегационный тип хранилища, который еще больше занимает места и требует дообработки (и будет еще медленнее). Могут еще и дубликаты пробегать.
3. Данных в массиве не больше 1млн штук. Это вроде бы по документации лимит массива. Для большинства задач этого достаточно, но стоит всегда об этом помнить, чтобы внезапно не упереться, и не обнаружить что массивы совсем не подходят и все надо переделывать. В статье об этом сказано, но не указано число.
При этом, если вы ни под одно из этих ограничений не попадаете, можно действительно получить существенный прирост к производительности (я вроде бы до x2 выжимал) и потреблению ресурсов (CPU и память). Но если они у вас есть - эффект будет противоположный.
Ну, допустим, ква.
К сожалению даже когда подвезут - ее надо довольно круто допиливать напильником, чтобы асинхронность в ней не тормозила. Реализовали ее весьма так себе.
Интересно у вас происходят zoom созвоны однако.
Например задавать уточняющие вопросы. Пока вы задаете вопросы исключено в формате, почему мы делаем ту дичь, что из вашей собственной головы вылезает.
Если вы будете задавать уточняющие вопросы по оригинальным вводным, а не по тем, которые вы сами придумали, получится совсем другой разговор.
Теперь вы придумали, что мы разговаривали с peer коллегами. И что интересно, в обоих сценариях, которые вы сами придумываете, мы всегда творим какую то дичь.
Знаете такую штуку на собеседованиях, как проекционные вопросы?
Во-первых, вы не ответили на мои вопросы, и уже задаете свои. Если вы потрудитесь дать на них ответы, возможно поймете что ваши новые - просто лишены смысла. Вы меня расспрашиваете о звонке руководителю, который сами придумали.
Если под "нет дефицита кадров" вы имеете в виду наличие самих кандидатов на рынке - то тогда его нет. Кандидаты есть. Собеседовать есть кого. Но если добавить уточнение "Кандидатов, которые подходят" - то вот с этим все плохо. На собеседованиях - мрак. Кандидаты есть, а нанять некого.
Это вероятно потому, что компании наобжигались нанимать абы каких инженеров. Неудачный найм - очень дорогое, и крайне сомнительное удовольствие. Раньше об этом как-то не думали.
Ой ну питон же. Это же по профилю видно. Кстати, у меня есть вакансия... :)
Раньше так и делали. Сейчас есть более продвинутые инструменты.
Для того чтобы эффективнее разрабатывать. Но если вам требуется производительный код, то без понимания того, как оно работает под капотом далеко не уедешь.
Нет, понимаете неправильно. Неужели вы сами сделали бы это таким странным образом? Или вы просто взяли, придумали заведомо мразотный сценарий и приписали его незнакомому человеку? Если это так, то вы просто мразоты. Что дальше? Надуманые обвинения, переходы на личности, оскорбления?
СБ существует в очень ограниченном кругу компаний. В подавляющем большинстве такого нет. А там где есть, справедливости ради, это обычно уместно. Если вы сталкиваетесь с СБ в среднестатистической компании, это само по себе довольно много о компании говорит.
Ну, вообще то, если каждый бьет - то да, с рожей что-то не так. А конкретнее с выбором. Потому что в целом, это ненормально, и если воспроизводится стабильно и с разными людьми, то дело уже явно не в них.
И нет, максимум информации о кандидате - это не выгода работодателя, это обоюдная выгода, когда все проговаривается на берегу. И работает это в обе стороны.
И о каких "ресурсов как у государства речь" вы говорите? Большинство компаний на рекрутинг выделяют сущие гроши. И все ресурсы которые там есть - собеседование и личный нетворкинг. Тоже самое, что есть и у самого кандидата, только компанию или руководителя "пробивать" на порядок проще в силу размера.