Comments 250
Лучший формат собеседования - это обычный разговор, хотя и со списком тем к обсуждению. Получается проверить хард и софт скиллы и рассказать про компанию в течение часа-двух. В итоге вы с кандидатом понимаете насколько подходите друг другу
Когда проводил первые собесы, они у меня из-за неопытности были в формате допроса и вспоминая их сейчас, понимаю, что это была полная лажа
Плюс тестовое собственной разработки. Когда его делал, главным условием было "3 часа на все пункты". Судя по обратной связи, так и получилось. И ещё по этому тестовому не только даю фидбэк, но и запрашиваю его для допиливания
Тоже пришёл к этому, самый лучший собес - разговор. В ходе разговора можно выяснить практически всё, что необходимо, плюс для кандидата это наименее стрессовый вариант, хорошие кандидаты раскрываются просто на ура. Но решил всё же оставить лайвкодинг для кандидатов ниже уровня сеньор, чтобы отсеять явных самозванцев, но без каких-то алгоритмов, а с реальными небольшими практическими задачками. А для всего остального, конечно же, есть испытательный срок.
Притом, простая повседневная задача даёт немало плюсов. Во-первых, мы смотрим актуальные для нас навыки. Во-вторых, в отличие от сложных алгоритмов, задачу решит большинство и можно проверить стиль написания, качество кода, подход к неймингу, размышления, обработку ошибок и тд. А когда часть кандидатов задачу не решает, то всё это увидеть сложно.
Аналогично, только без кодинга. Стек специфический, обучать ему будут во время испытательного срока (он же обучение).
Так что просто разговор на равных.
Кодинг не должен быть на вашем стеке, это абстрактные задачи на любых популярных языках программирования, чтобы убедиться, что кандидат может в принципе написать какой-то цикл или не делает n квадрат там, где это не нужно
Хотя в реальной практике куда чаще встречаются задачи где можно и даже предпочтительно делать N^2 и даже N^3. Всё зависит от реальной нагрузки, и есть на вход раз в час приходит N = 150 в самом фантастическом сценарии, то наивный алгоритм N^3, написанный за 2 часа, будет лучше чем N logN, на полировку которого ушло 20, и потом это еще невозможно изменить под новые требования. Конечно, речь не идет о совсем базовых алгоритмах.
Задачи технического собеседования - две
1. выяснить что знает кандидат - просто идешь по его резюме и в меру своей компетенции интересуешься что было сделано, как, почему. Беседуете о различных инструментах, библиотеках, как они использовались, кто принимал решение о использовании. Можно для себя полезного почерпнуть много
2. Выяснить подходит ли кандидат на ваш проект. Идешь по своему опроснику, где перечислены и технологии и базовые вопросы, важные для вашего проекта, спрашиваешь. И не ждешь "своего правильного ответа", а слушаешь компетенцию со стороны. Расширяет кругозор. Не обязательно по своему опроснику все вопросы задавать - у кандидата могут быть гэпы в одном и наоборот углубленные знания в другом. Это ты на пункте первом мог уловить. И глубже нужно копать именно там, где кандидат больше знает. Так сказать узнать глубину его кроличьей норы. Это скажет тебе насколько кандидат в принципе умеет копать и разбираться с тем, с чем прямо и долго работал.
Ну а дальше - зависит от тебя, насколько ты сам вообще как человек, разумный, адекватный и умеешь в психологию.
Я раньше просил рассказать про свой диплом. Большинство не могли даже тему вспомнить.
Сейчас бы спрашивал из текущих своих задач проблемные ситуации и как их человек будет решать
Большинство не могли даже тему вспомнить.
Потому что только название темы - 2 абзаца. Кто эту чушь вообще запоминает.
А в чем разница проекта на работе и диплома?
Я на работе тоже не могу вспомнить, какому заказчику что мы делаем. Каждый раз приходится смотреть, разбираться. Тут шаблоны на ejs, тут на handlebars, тут на pug, тут на чистом html, там есть TypeScript, там нет, там jQuery, там чистый JS. У меня проекты делятся на "тот самый, где картинки по-марсиански прибиты к шапке", "тот, где таблицы за экран вылазят", "тот, где у каждого блока подблоки 6-го уровня вложенности", "тот, где на каждой странице свои стили, потому что делали их отдельно одну от другой, и маленькие синие стрелки".
Чушь. Бесполезно. Зачем надо.
Вы зачем в университете учились? Я помню не то что тему, а весь свой диплом наизусть и до сих пор поддерживаю его в актуальном виде, помогает на собеседование пропускать лайв секции заменив на просмотр этого магнум опуса.
Вы поэтому и не понимаете в чем смысл вышки потому что штаны протирали и диплом для глаки сдавали. Учиться надо было.
Зато воинствующие невежды не поленились заминусовать. Вот таких людей я сразу отсеивал. Диплом это образец того, как человек работает по задаче
Думаю, вас заминусили не невежды, а просто люди со стажем.
Мой диплом писан уже более 10 лент назад на PHP. При всей моей гордости на тот момент, сейчас он никому не интересен.
Это образец того, как человек работАЛ по задаче, когда у него был минимум опыта, в какой-то момент в прошлом.
2 часа.
По-моему хватает 30-60 минут собеседования в формате "простого разговора", но в контексте резюме и примерного сценария из списка потенциальных вопросов, которыми естественно можно разбавить этот разговор.
Кому-то требуются перекладыватели json-ов, кому-то — формошлепы, а кому-то — самостоятельные разработчики, готовые брать на себя ответственность и драйвить разработку.
Ну зачем? Почти нетоксичная статья же получилась. Чуток не дотянул.
Отвратительно написано. Автор автоматически превозносит себя над другими только по причине того, что прочитал какую-нибудь "умную книгу" (возможно даже не до конца). Применяет он на практике полученные знания или нет - мы не знаем. На поверку может оказаться, что автор такой же формошлёп, как и большинство, но нашёл повод выпендриться.
При этом, есть ли корреляция между чтением рандомных книжек и теми, кто действительно тянет на себе разработку ("драйвит" - слово неопределённое, ничего не говорит о результатах, только о суете) - ещё надо доказать.
Тем не менее, мне нравятся все советы, которые изложены в статье. Я и сам стараюсь им следовать (особенно о проработке тестовых и задач типа "проведи code-review"), но вот это ложное чувство превосходства собеседующего над собеседуемым - оно просочилось в пассаже про формошлёпов. То, что ты раньше пришёл в компанию N не даёт тебе никакого преимущества над тем, кто пришёл позже. Завтра ты достанешь всех со своей "умной книгой" и уже тебя будет собеседовать тот, кто приходил на интервью к тебе.
Плюс, бесит, если честно, манера считать, что везде "перекладывают json'ы", а вот у нас - настоящее программирование. Автор мог бы сохранить анонимность относительно места работы, и тогда читатель мог бы предположить, что они действительно на работе занимаются чем-то эдаким. Но автор пишет с корпоративного блога) А вот это вот топовое российское IT - он небольшое, на самом деле. Разработчики постоянно переходят между 10 условными компаниями и все прекрасно знают кто, что и как делает.
Так у автора в описании `frontend dev`, вот он, наверное, про себя и говорит формошлеп json'вый...
Спасибо за отзыв! Попробую ответить на все возражения и моменты по-порядку.
> Чуток не дотянул
> Отвратительно написано.
Интересно поменялась градация оценки)
> автоматически превозносит себя над другими
Ни в коем случае не старался вложить этот смысл в текст. Тем более, не было намерения демонстративно подняться над кем-то.
> ... только по причине того, что прочитал какую-нибудь "умную книгу"
Честно говоря, не читал специализированных книг про интервью. Если вы говорите про книги, связанные с программированием в целом, то тогда не совсем понимаю аргумента, не вижу связи.
> На поверку может оказаться, что автор такой же формошлёп, как и большинство, но нашёл повод выпендриться.
Ну так да, я этого и не скрываю) Есть много подобного рода задач, которые надо выполнять. Программирование - ремесло.
Вообще, в нашей рабочей среде подобные формулировки не воспринимаются обидными. Мы часто подшучиваем так друг над другом или люди сами себя так описывают.
В конкретном примере мне нужно было вкратце описать ситуацию, поэтому я выбрал ярлыки, которые лаконично вписывались.
По названным причинам выше не думал, что это сможет задеть. Надеюсь, донес до вас свою точку зрения.
> Плюс, бесит, если честно, манера считать, что везде "перекладывают json'ы", а вот у нас - настоящее программирование.
Не уверен, что вы нашли это в моем тексте, но все же. Я не писал ничего подобно, уж тем более не имел в виду. Стараюсь реально смотреть на вещи. Большинство задач так или иначе однотипны, похожи. Как и писал ранее, программирование - ремесло. Не все задачи интересные, сложные, заставляют изобрести что-то новое, ознакомиться с какой-то новой технологией.
> Но автор пишет с корпоративного блога)
Вы могли заметить, что изначально статья вышла не под корпоративным хабом. Я выпустил ее специально от своего имени, чтобы избежать комментариев в предвзятости. Лишь позже мне предложили добавить в статью в корпоративный блог. Возможно, удалю привязку к корпоративному блогу, чтобы не было таких мыслей.
Интересно поменялась градация оценки)
Мне понравилась статья в целом, поэтому наличие этого абзаца - это именно "чуток". Но сам по себе абзац, если рассмотреть вне текста, весьма неприятен. Вот почему:
Ну так да, я этого и не скрываю) Есть много подобного рода задач, которые надо выполнять. Программирование - ремесло.
Смотрите, как интересно выходит. Вы и сам, с ваших слов, формошлёп, и однотипных задач у вас полно, и с коллегами вы шутите по этому поводу. Но если у вас по результатом собеседования сложилось впечатление, что кандидат - точно такой же формошлёп, то это уже минус:
разным проектам нужны разные разработчики. Кому-то требуются перекладыватели json-ов, кому-то — формошлепы, а кому-то — самостоятельные разработчики, готовые брать на себя ответственность и драйвить разработку.
Возникает закономерный вопрос: а откуда гонор? Вам человек нужен, чтобы вместе с вами ваши ежедневные задачи решал или запускал ракеты в космос? А вы уверены, что для такого "драйвера" у вас найдётся подходящая работа? Или нужна ли вам вся команда, состоящая исключительно из "драйверов"?
Поймите, я не просто так придираюсь к этим формулировкам. Это признак ещё одного пункта некачественного интервью, о котором вы не написали: несоответствие ежедневных задач и требований к кандидату. В других подобных статьях об этом пишут довольно часто, и это весьма распространённая болезнь людей, которым приходится заниматься подбором персонала. Не берусь утверждать, откуда растут ноги у этой болезни: то ли из-за собственного синдрома самозванца, то ли из-за страха отвечать перед начальством за "недостаточно строгое интервью", не суть. Главное, что это тоже распространённая проблема.
Тем не менее, учитывая общую адекватность выводов, к которым вы уже смогли прийти и которыми с поделились в статье, есть надежда, что и до этого вопроса вы доберётесь.
Но если у вас по результатом собеседования сложилось впечатление, что кандидат - точно такой же формошлёп, то это уже минус:
Наверно мы с вами читали разные статьи, но с чего вы взяли, что автор считает что "формошлёп – это уже минус"? А раз 5 перечитал статью и не нашел этого.
Если что я формошлеп и json-перекладыватель большую часть времени. А еще я "вайтишник" (если я правильно вспомнил модное нынче слово). Я "вайтишнулся" лет 15 назад. Мое ВО никак не связано с IT.
В цитате, которую я привёл, явное противопоставление:
разным проектам нужны разные разработчики. Кому-то требуются перекладыватели json-ов, кому-то — формошлепы, а кому-то —самостоятельные разработчики, готовые брать на себя ответственность и драйвить разработку.
В этом месте читателю явно дают понять, что формошлёпы и перекладыватели json-ов - это не самостоятельные разработчики. А вы что же, как собеседующий, самостоятельных не хотите?
А вы точно хирург? :)
Вообще, вы что-то во все стороны воюете. Не могу проследить в ваших комментариях единую точку зрения.
Ложная аналогия. Тут скорее вместо "медсестры" звучит "перекладывалка бинтов". Тоже кривая аналогия, но ближе к сути)
...что кандидат - точно такой же формошлёп, то это уже минус
Не считаю это минусом. Как писал ранее, все зависит от требований проекта и команды.
К примеру, если мы говорим про банк, часто отсеиваются кандидаты, которых вполне можно было бы взять. Они бы справились с рабочими задачами. А где не смогли бы, легко бы научились, так как можно пообщаться с коллегами или попросить о помощи ментора. Это я к чему? К тому, что зачастую мнения собеседующих расходятся. Я понимаю, что человек не идеально прошел стандартные задания на интервью, но вижу, что он вполне способен выполнять будущие задачи. Поэтому даю зеленый свет. Напарник же считает, что если не запустил ракету, то уже никуда не полетит. Это я считаю проблемой, о чем, собственно, и написал в тексте.
Не вижу никаких противоречий.
Вам человек нужен, чтобы вместе с вами ваши ежедневные задачи решал или запускал ракеты в космос?
Чаще — первое. Что касается драйверов, то обычно их ищут целенаправленно. Под конкретный запрос, например: techlead, мейнейнер uikit, и тд. То есть в вакансии об уровне ответственности и об ожиданиях пишется заранее.
В моем направлении, к слову, приветствуется, когда разработчик начинает брать на себя больше ответственности и становится "драйвером". Подчеркну, это происходит по личной инициативе.
Это более подробный комментарий, спасибо.
Как писал ранее, все зависит от требований проекта и команды.
Ну, как я написал в другом комментарии, вы сделали из этого явное противопоставление. У "драйверов" у вас есть положительные стороны: самостоятельные разработчики, готовые брать на себя ответственность. А у "формошлёпов" никаких достоинств нет. Выбор для читателя очевиден. Хотя, по опыту, как раз "формошлёпы" умеют прогнозировать адекватные сроки и выдавать стабильный результат. Ну и с самостоятельностью я бы поспорил. Но не буду накидывать)
Напарник же считает, что если не запустил ракету, то уже никуда не полетит.
Считаю, что нужно уважительно относиться к коллегам, даже если им не довелось сделать что-то эдакое. Илон Маск, конечно, молодец, но ещё большие молодцы его инженеры. Вам не нужна команда, состоящая целиком из Масков. Даже не в каждой команде он нужен, строго говоря.
Ну, как я написал в другом комментарии, вы сделали из этого явное противопоставление.
Уловил суть. Подобная формулировка показалась предвзятой и настроена на предвзятость и выглядит как противоречие. Могу заверить, что это лишь формулировка, целей создать такое впечатление не было. Я посчитал, что "драйвер" звучит слишком абстрактно и решил именно этот термин раскрыть.
Считаю, что нужно уважительно относиться к коллегам, даже если им не довелось сделать что-то эдакое.
Поддерживаю. Думал, что раскрою этот тезис больше, но вышло наоборот. Признаю, что формулировка неоднозначная.
Вставлю и я свое особо ценное. Российские IT компании собеседуют кандидатов так, как будто они Google и будут платить тому счастливчику, которого они возьмут, $10000 в месяц. Но в действительности так собеседуют на $1000. Потому, что спецов на $3000 и выше по HeadHunter'ам они не ищут. Таких берут по рекомендации от коллег.
В общем, для кандидата собеседование - это чистая лотерея. Нет, конечно, если ты мега-гига крутой спец, то у тебя, подозреваю, уже работа есть и на зарплату ты не жалуешься. А если ты обычный простой прогер, то для тебя собеседование - это лотерея. Если у собеседующего еще осталось желание "копаться и выбирать", то кандидату ничего не светит. Ибо он же не само совершенство, а собеседующий на данном этапе ищет именно, что само. А вот если собеседующий уже продолжительное время ищет и пришел к мысли "А ну его всё к черту, возьму уже следующего, который более-менее понравится", то тогда шанс есть. В общем, главный вывод: от кандидата почти ничего не зависит.
Знаете какие-то вакансии, где можно так попрозябать? Я бы не прочь попрозябать за 150. А если ещё и не будут гонять по кишкам фреймворка, а достаточно только уметь им пользоваться и учиться нужному по мере возникновения потребности, то совсем красота.
Ой, коммент про спецов. Не факт, что я спец, я не проходил никакую квалификацию. Тогда отбой.
Прошу прощения, что врываюсь с непрошенным советом: но попроходите собеседований просто. Прям так массивно, чтобы не 2-3, а ближе к 20 (что подразумевает как минимум 50 откликов, а то и больше).
Во-первых, с каждым новым будете увереннее себя чувствовать и сможете интереснее про себя рассказать.
Во-вторых, где-то и повезёт. Как бы не пытались систематизировать опыт собеседований в таких аналитических статьях - это всё ещё лотерея. Иногда в неё выигрывают)
Если мне на каком-то собеседовании предложат трудоустройство, а я откажусь, то буду чувствовать себя неуютно, это как обман чужих ожиданий. Они думают, что нашли работника, а я просто так у них время отнял. Я понимаю, что где-то я нужен и с нынешними знаниями, я же нашёл нынешнюю работу, но даже не знаю, где искать интересные мне вакансии. Вчера ходил по хабр-карьере, там удалёнка с указанной зарплатой с фронтендом на vue — это пять что ли вакансий. Потом отключил обязательность указания зарплаты, из всего выбрал лишь парочку, которые тематически мне бы подошли, но там есть некоторые требования, которым я не удовлетворяю. Они ещё так пишут, типа "знание vue-router". Ну, я с ним просто работал, а вдруг им нужно умение написать свой движок роутинга или хотя бы помнить на память все параметры? Последние два года я делаю такое легаси, что уже даже не помню, как там сейчас канонично этот роутер подключать к проекту, но точно знаю, что это одна строчка в документации, могу банально посмотреть.
Если мне на каком-то собеседовании предложат трудоустройство, а я откажусь, то буду чувствовать себя неуютно, это как обман чужих ожиданий.
Вы эту херню бросьте. Когда я последний раз искал работу, я откликнулся на 25 вакансий, прошёл в общей сложности 27 интервью (с учётом предварительных созвонов с HR и прочих этапов) и получил в финале то ли 4, то ли 5 офферов. Очевидно, мне пришлось кому-то отказать - я ж не волчара какой)
Думаете, отвергнутые компании занесли меня в чёрный список? Очень даже наоборот: раз в полгода пишут и спрашивают, не хочу ли передумать в их пользу.
Вы скажете, это потому что я такой офигенный? Вовсе нет. Меня вон выше IT-медсестрой обозвали) Просто это норма, так сейчас всё устроено. Вы тоже в компании будете не единственный кандидат. Откажетесь вы - позовут следующего по списку. Вот пример со стороны нанимателя под этой же статьёй.
Последние два года я делаю такое легаси
А у нас же везде такой качественный код, что обосраться можно, ага) Говорите честно, что делали. Вспомните два-три примера задач, решением которых особенно гордитесь, и вперёд.
Я понимаю, что так устроено, но воспитание так просто не изменить. Мне внутреннее тяжело обманывать. Или мне с самого начала сказать, что я пришёл не на работу устраиваться, а просто так? Они ведь будут отвлекаться от своей работы, чтобы провести собеседование.
Вопрос, чем я горжусь, и что могу показать из прошлых работ, меня всегда ставит в тупик :( Я половины вообще не помню, а то, что помню, потому что делал это долго, обычно находится за паролем, потому что это какие-то внутренние сервисы. Да и они из-за долгой разработки перестали быть тем, чем я горжусь. Во многих случаях я даже не знаю, под каким адресом работает сайт, который я делаю, потому что моё взаимодействие заканчивается на тестовом сервере. А ещё многое из того, что я делал, уже переделано почти полностью, да и я сам там делал не всё с нуля, а что-то дорабатывал. Типа, один раздел в админке или часть корзины, но её потом ещё допиливали, в итоге там код пяти человек.
Раз был случай, несколько месяцев делали для автоваза сайт, я там писал подбор комплектации машин, где можно было галочками отметить желаемый двигатель, коробку передач, подогрев руля, всё такое, а он на каждом шаге отключал галочки, которые не сочетаются с выбранными, чтобы выйти на что-то финальное. В итоге завернули и сказали, чтобы все галочки были всегда доступны, показывало бы самую близкую комплектацию из имеющихся, а там уж менеджер по телефону уболтает. По итогу сайт так и не запустили. Несколько месяцев работы! Мы тогда ещё после украинских фрилансеров его доделывали, там были какие-то подрядчики на подрядчиках, у них ещё в 2014 стали в обед свет отключать, в итоге разработка попала к нам. В качестве байки наверное могу такое поведать, но код там был страшноват. Если бы я владел какими-то паттернами, то мог бы сделать лучше. Но я и сейчас книгу по ним не прочитал — сил нет на учебники, хочется просто поспать уже неделю по 10-12 часов.
Ещё я на jQuery месяц делал то, что сейчас на vue сделал бы неспешно за неделю. Переизобретал SPA на глобальных переменных. Аж в дрожь бросает. И ведь до открытия мной Vue оставалось полгода что ли.
Вообще говоря, человек, ковыряющийся в легаси, тоже обладает спросом. Но я бы не сказал, что мне это прямо нравится. Я бы сейчас на полгода бросил работу, если бы были какие-то накопления.
Или мне с самого начала сказать, что я пришёл не на работу устраиваться, а просто так?
Вам просто так сказать что вы ищите новую работу, но пойдёте к ним только если всё устроит и не будет вариантов получше.
Более того это даже говорить не нужно. Адекватные работодатели это сами понимают.
обычно находится за паролем, потому что это какие-то внутренние сервисы.
И? Вас же не просят секреты фирмы выбалтывать. У меня тоже большинство проектов под NDA. Но я могу сказать что занимаюсь автоматизацией производственных линий. И что например наиболее интересные проекты были проекты с интеграцией чужих промышленных роботов.
И вы не должны ничего работающего показывать. Спрашивают не для этого, а скорее чтобы понять что вам интересно.
Раз был случай... Ещё я на jQuery месяц делал...
Ну вот это прямо вот так и расскажите.
Вы прямо с языка сняли. У меня точно такой же вопрос немедленно возник после прочтения предыдущего коммента.
Но вообще, если спец настолько крут, то он полгодика попрозябает-попрозябает, да и найдет себе местечко за 400к вечнодеревянных. Ведь таких как он не так уж и много, и потому конкуренция сильно меньше. Не сравнить с теми, кто не может Linux kernel с нуля написать или полностью разработать концепт распределенной системы биллинга и реализовать его за месяц.
Потому, что спецов на $3000 и выше по HeadHunter'ам они не ищут.
Ищут. Откройте хедхантер ) Ну и я сам так устраивался, неоднократно.
Да вам прям не остановится)) И правда, зачем статьи писать, когда их можно в комментах наваливать.
Я старался. Но щепотка приправ не испортит блюдо c:
Дошел до мысли, что бигтехи очень коряво зовут к себе. Вот недавно писали с нескольких крупных компаний, показывают вакансии, ну +- по задачам одно и тоже. Хочется как то подробнее узнать о людях на проектах, что реально хотят и все такое, но нет, ты должен пройти 3+ собеса к каждому из них. И так лень время на это тратить, абсолютно никак не продают работу у них.
А собеседования у многих реально мрак. Единичные истории когда не душат на них как на экзамене
А собеседования у многих реально мрак. Единичные истории когда не душат на них как на экзамене
Я преподом в вузе работал довольно много лет. Некоторые студенты тоже считали, что я душил их на экзамене, а я их изо всех сил за уши тянул, чтобы они сдали. Мне меньше всего хотелось тратить своё время на их пересдачи..
Конечно, есть самовлюбленные мудаки, которым нравится самоутверждаться за счет других. Но большинство собеседующих, действительно, искренне хотят найти себе коллегу в команду и закрыть вакансию. И хотят они это сделать как можно быстрее, потому что пока они собеседуют, задачи стоят. Нет никакого смысла тратить время на кандидата, изначально, желая ему отказать, это идиотизм.
Просто кандидат не всегда может понять, что именно хочет проверить и узнать собеседующий. В статье есть пример, когда дали тестовое с противоречивыми вводными. Автор посчитал, что это небрежность. Тем временем, в компании может быть бардак устоявшаяся практика при постановке задач, ожидается, что исполнитель прежде чем начать что-то делать, все уточнит и напишет "спек", чтобы не переделывать потом. Ищут именно такого человека, который так привык работать. И именно это автор не стал делать, чем и завалил тестовое. Я не хочу сейчас давать тут оценок, плохо это или хорошо, правильно или нет. Я пытаюсь указать на то, что кажущийся идиотизм на сабеседовании, на самом деле, может быть четко спланированной тактикой проверки навыков, необходимых компании. Но вы не понимаете, что именно проверяют и вам всё происходящее кажется глупостью.
Кому лучше, кандидату? На кандидата компании наплевать на данном этапе. Для синьора не проблема "адаптироваться" и освоить любой фреймворк, но куча компаний требуют в вакансии опыт работы с конкретным каким-нибудь и кандидатов без такого опыта не рассматривают, даже если кандидат думает, что ему это нужно. Вас это не смущает?
На кандидата компании наплевать на данном этапе.
большинство собеседующих, действительно, искренне хотят найти себе коллегу в команду и закрыть вакансию. И хотят они это сделать как можно быстрее
Так наплевать или хотят быстрее закрыть вакансию? Одно противоречит другому.
пока они собеседуют, задачи стоят
Пусть себе стоят. Собеседование это такая же часть работы как и непосредственное решение задач. К чему это противопоставление? Или тут бардак, когда люди завалены потоком задач когда все надо сделать вчера. Собеседование при этом не часть рабочего процесса, а что-то отвлекающее от основной работы, с чем надо побыстрее разделаться.
Так наплевать или хотят быстрее закрыть вакансию? Одно противоречит другому.
Одно другому не мешает, никакого противоречия нет. К тому же, про бардак вы сами что-то придумали и заранее обиделись.
Пусть себе стоят.
Кто будет оплачивать этот банкет?
Собеседование это такая же часть работы как и непосредственное решение задач.
У разных работ есть разные приоритеты.
Или тут бардак, когда люди завалены потоком задач когда все надо сделать вчера.
Я понял. Когда у программиста есть задачи и сроки, это бардак. Не бардак, это когда он пьёт смузи, а ему платят 100500 денег в секунду, чтобы когда-нибудь он снизошел до решения возложенных на него задач. Всего хорошего, вы нам не подходите.
Может лучше сразу честно сказать "у нас бардак"
Тогда окажется, что собеседующий глупее собеседуемого, а так быть не должно. ))))
На самом деле, в ИТ сформировался некий КУЛЬТ, где вы должны бесконечно зубрить и самообучаться, а потом какой-то "гуру" на собесе проведет вам экзамен, на тему, которую рандомно выберет он сам. Вы должны со щенячьим взглядом ждать фидбек, не воспринимать отказ в работе как обвинение в профнепригодности, а радоваться прохождению 3 уровней и готовиться к новым собесам. Ради обычной рутинной работы, где вас попытаются прогнуть на зарплату ниже рынка, обнулив весь ваш предыдущий опыт.
Такого идиотизма я не вижу ни в одной профессии. Никто и нигде не ходит по сотням собеседований, чтобы порешать задачки, не ждет идиотских фидбеков, словно манну небесную от богов, и не внушает коллегам нормальность подобного. Теперь ко всему этому цирку прибавилось "вы привыкли работать не так". Уже не знают, чего еще придумать, чтобы потешить свое ЧСВ и отказать в работе.
Аналогичные мысли пришли в голову. Нужно решать модные задачки, читать книжки, ходить на митапы, по ночам спать в наушниках со стримами систем дизайну и т.д. Стало очень сильно напоминать культ достигаторства и продуктивности ради достигаторства и продуктивности. А все остальные - перекладыватели json и формошлепы, кто не литкодит по 12 часов в день.
Автор посчитал, что это небрежность. Тем временем, в компании может быть
бардакустоявшаяся практика при постановке задач, ожидается, что исполнитель прежде чем начать что-то делать, все уточнит и напишет "спек", чтобы не переделывать потом
опыт говорит, что чаще это просто бардак, а не хитроумные практики
Поэтому communication skills - превыше всего, по крайне мере в западных конторах
это проблема исключительно тех кто это ТЗ писал
А кто должен писать ТЗ?
Так именно этого человекка и планируется нанять в примере выше. Он называется синьор. Именно он берет нечетко сформулированную задачу бизнеса, прорабатывает её, разбирается, что там на самом деле нужно, думает об архитектуре и реализации и формирует то самое ТЗ. В этом ключевое его отличие от мидла, для которого кто-то другой ТЗ пишет.
Тут у нас как раз то, о чем я говорил, прямо отличная иллюстрация получилась. У вас не хватает квалификации, чтобы осознать требования компании, но вы уже имеете своё мнение и высказываете его в довольно резкой форме. Именно для этого и даётся такое тестовое, чтобы отсеять вас на первом этапе и не тратить на вас дорогое время интервьювера. Вы пока не подходите.
Ой, у меня ещё круче было. Я, разработчик ПО, был виноват в том, что НЕ ДОГАДАЛСЯ предупредить контрагентов о том, что у банка, в котором открыт счёт предприятия, отзывают лицензию. Хотя за обедом краем уха слышал об этом. Я, оказывается, по собственной инициативе, должен был написать предупреждение, которое должен был опять же сочинить сам, и разместить на сайте, на который вряд ли кто-то ходит и что-то читает. Банки с отозванными лицензиями принимают все входящие платежи, но пользоваться счетами не дают. Поэтому контрагенты деньги перевели туда, куда в договорах прописано. А предприятие не могло ими пользоваться. Ну вот я и был стрелочником.
Не ищите умысла в том что можно объяснить разгильдяйством. :)
Хотя с комментарием согласен
На одном из последних собеседований речь зашла про снифферы, и один из собеседующих спросил: "Что там за значение в одной из колонок". Не сказать, чтоб я так сильно запоминал меню того сниффера, при необходимости уже на опыте понимал куда примерно нужно смотреть. Мне такой вопрос не сильно понравился, и спросил, как часто они такой информацией пользуются, "ну и пару раз за 10+ лет" ответили мне. Ну это же душнилово)) Как потом оказалось, хотели услышать про протокол).
На экзамене, право экзаменатора спрашивать сколько он считает нужным, как мне кажется. Но я же к ребятам прихожу не экзамен сдавать. При таком раскладе и коллег надо будущих экзаменировать. Я так по неопытности пришел на новое место, а там такой мрак был в проекте, совсем не совпадало с вопросами на собеседованиях)
Деньги под программистов выделяет бизнес под определённые цели. Быстрее продукт выпустить, сделать больше фич, уменьшить количество багов, сократить время инцидентов
Большинство собеседующих не понимают что спрашивать и кого они ищут. Чтобы понимать - должна быть выстроенная матрица. Должна быть потребность в ресурсах разработки, а после этого должен быть выделен пул задач и требования к кандидату. И у большинства технических специалистов здесь полный швах. Собеседования в it проводить просто не умеют - те "бест практис", что есть на ютубе, просто слизаны с фаанг
Когда собеседуют тимлида, наверное не стоит спрашивать теорию для Джуна - во-первых, задачи там уже гораздо более верхнеуровневые, чем написание кода, во-вторых - деньги под найм не выделяют для найма теоретиков, у человека есть прикладной опыт и надо понять что он делал.
Заметил, что как раз преподавательский подход и тащат на собесы, устраивая экзамен, вместо того, чтобы понять - комфортно ли вам вместе работать и потянет ли тот пул задач.
А почему вы думаете что
Большинство собеседующих не понимают что спрашивать и кого они ищут. Чтобы понимать - должна быть выстроенная матрица. Должна быть потребность в ресурсах разработки, а после этого должен быть выделен пул задач и требования к кандидату. И у большинства технических специалистов здесь полный швах.
У нас есть поток задач от бизнеса и есть ресурсы разработчиков. Если мы видим, что ресурсов не хватает, мы пытаемся выбить их расширение. Если это удается, ищем разработчика. И мы прекрасно понимаем какими задачами его загрузим и чего от него ждем. Более того, мы это понимаем куда лучше других - HR'ов и прочих.
Я как-то спросил у собеседующего для чего он задаёт все эти вопросы, он ответил "ну, все обычно задают, вот и я тоже. Best practice."
В другом интервью был ответ "я хочу понять как вы думаете", нейросайнтист попался видимо)
В третьем, "а что вы поспрашивали бы".
Т.е. так и есть, собеседующие зачастую вообще не понимают чем они занимаются.
Все правильно, только вот если в компании бардак начинается уже на постановке ТЗ, то этот идиотизм — не кажущийся.
И хорошо, что он вылезает на собесе.
Просто кандидат не всегда может понять, что именно хочет проверить и узнать собеседующий.
Извините, но вы описываете какую-то битву экстрасенсов, а не собеседование. У всех разный контекст, у всех разные подходы к решению задач. Вы проверяете только то, что человек пришёл из среды, максимально похожей на вашу, и привык работать в контексте, похожем на ваш.
Я тоже постараюсь не давать вам оценок, но обычно считается, что погружение в контекст - это процесс, который естественным образом происходит в течении испытательного срока. Следовательно, на собеседовании имеет смысл проверять более абстрактные навыки.
Вы проверяете только то
Я пропустил момент, когда в треде начали обсуждать меня. Я про себя еще ни слова не написал (за исключением рассказа про преподавание).
Следовательно, на собеседовании имеет смысл проверять более абстрактные навыки.
Для кого? Для работодатели имеет смысл проверять те навыки, за которые он собирается платить.
Я тоже постараюсь не давать вам оценок
Спасибо. Я тоже не буду слать вас по матери за переход на личности.
А вы, будучи преподавателем, хорошо научились воспринимать критику. Профессионально, не агрессивно, с достоинством. Курсы не ведёте?
А если серьёзно, вы когда комментарий начали с того, что занимались преподаванием, а потом продолжили рассуждать про собеседования - естественным образом создалось впечатление, что вы сейчас так собеседования и проводите. Следовательно я к вам, как к собеседующему, и обращаюсь.
будучи преподавателем, хорошо научились воспринимать критику
А как работа преподавателем соотноситься с умением воспринимать критику?
В моём представлении среднестатистический преподаватель сталкивается с огромным количеством провокаций и словесных выпадов в свой адрес. В каждой группе есть какой-нибудь уникум, который вместо обучения играет в игру "кто тут самый умный/смешной/говорливый". Со временем должен формироваться иммунитет.
Не увидел в вашем сообщении критики. Увидел демагогию, провокации и переход на личности. Второй раз, кстати.
создалось впечатление
Так всегда бывает, когда не читаешь то, что написано.
Увидел демагогию, провокации и переход на личности.
И как меня земля только носит.
Так всегда бывает, когда не читаешь то, что написано.
Да что-то у вас все кругом должны угадывать, что творится в вашей голове: что соискатель на собеседовании, что читающие ваш комментарий на хабре. Кажется, проблема таки не во мне.
Вы можете продолжать усираться и брызгать слюной, пытаясь меня хоть как-то задеть, реальность от этого не прменяется, реальности пофиг.
Да что-то у вас все кругом должны угадывать, что творится в вашей голове
И опять вы выдумываете ерунду пытаясь оправдать саою неспособность прочитать и осознать несколько предложений...
Вы долго еще за мной бежать будете, доказывая, как я вам безразличен?
реальность от этого не прменяется, реальности пофиг
Реальность вообще штука весьма инертная. Такая деятельность, как комменты на Хабре в принципе оказывают на неё мало влияния: что мои, что ваши. В этом смысле мы с вами равны, как ни в одном другом.
Вы долго еще за мной бежать будете, доказывая, как я вам безразличен?
Вы и сами можете перестать "усираться", и закончить диалог)
Тем временем, в компании может быть
бардакустоявшаяся практика при постановке задач, ожидается, что исполнитель прежде чем начать что-то делать, все уточнит и напишет "спек", чтобы не переделывать потом.
Ну т.е. соискатель должен угадывать, что же от него хотят?
Нет, зачем. Когда я прихожу на рынок, яблокам не нужно угадывать, что я хочу, я просто выберу те, что нужны мне. Работодатель выбирает кандидатов, которые подходят ему, соискатель выбирает компании, которые подходят ему. Каждый из них руководствуется каким-то своими соображениями. Если эти множества пересекутся, возникнет контракт.
Как опытный студент, скажу, что студенты попались глупые и ленивые. Разумист всегда отличит препода, который ждет невероятных знаний и сам шага к студенту не сделает, от преподавателя которому важнее, чтобы студент хоть как-то переварил и записал в пзу знания по дисциплине (хотя бы и те что ему же на экзамене сам и рассказал), такие еще обычно тройки не ставят.
Собеседования в западных биг[техах] это самая сложная часть работы (если приняли). Ежедневная работа в разы проще.
Дошел до мысли, что бигтехи очень коряво зовут к себе
Сила бренда и "вас много , а я одна" во всей красе - другого тут вряд ли стоит ожидать. Рынок-с и вал желающих попасть к ним ...
Дизайн документация и ее pdf аналог в некоторых моментах противоречили друг другу. Мелочь? Да, но она показывает подход людей к работе. Зачем нужна pdf-ка, если есть спецификация в figma?
Это могло быть сделало специально. От вас могли ждать, что вы начнете уточнять задачу.
Можно возразить, что и соврать не трудно.
Так можно и впросак попасть. Если каниддат скажет, что он читает/читал книгу, которую чилал я, я могу задать пару вопросов по существу. Что больше всего понравилось? Согласен ли ты с автором по вопросу Х? И т.д.
Это могло быть сделало специально. От вас могли ждать, что вы начнете уточнять задачу.
Могло быть, но автором это было интерпретировано как небрежность. В этом проблема таких mind games. Кандидаты тоже выбирают компании, как ни странно. Готовы тратить время и терять кандидатов - ок, продолжайте игры разума.
Если тестовое оплачивается, то можно и уточнить..
Назревает вопрос, откуда появилась такая страсть к алгоритмам на собеседованиях?
Ответ очевиден. В ситуации фаангов, если у вас за забором тысячи кандидатов, то у вас нет ресурсов беседовать с каждым по душам. Особенно если каждый второй там по-английски кое-как шпрехает. Только бездушный конвейер, только хардкор. Ну а в наших широтах как всегда устроили карго-культ. Не поняли мотивации, но пафос и низкие трудозатраты пришлись по душе.
Но мне кажется, недолго этой музыке играть. Техногигатны сами выпустили нейро-джинна, который вращает деревья заведомо лучше, чем все кожаные вместе взятые. Я прям уверен, что на просторах Индии и Юго-Восточной Азии уже тьма хитрожопых, которые без проблем гарантированно проходят удаленную алгоритмическую секцию любой сложности с помощью ИИ.
Скоро фаанги столкнутся с выбором. Или отказываться от удаленки вообще и заставлять кандидатов прогать на бумажке при очном присутствии. Или жрать продукт ИИ-революции и принимать в штат всех хитрожопых, а потом увольнять после испыталки. Или искать способы оценить человека именно как человека, а не вращателя деревьев.
Или сторонняя сертификация, как в других инженерных отраслях
Всё верно. Формализация трудоустройства и соблюдение трудового законодательства: если соискатель удовлетворяет требованиям вакансии, то его обязаны нанять. Если его нанять не готовы, то вакансия в публичном доступе висеть не должна.
как в других инженерных отраслях
В какой именно инженерной отрасли сертификация заменила собес? У меня есть знакомые из АСУ ТП, энергетики и производства аппаратуры КИПиА. Везде есть собесы даже несмотря на наличие корочек. Никто не хочет себе в штат хитрожопа, который обмазался сертификатами, оставаясь при этом плохим практиком.
Или вы транслируете голубую мечту тех, что в 2005 году получил сертификат Оркла по Java и теперь хочет, чтобы его везде брали на java senior просто так?
В медицине, насколько знаю, практически именно так и обстоит - корка и формальное резюме без вопросов о практике
что в 2005 году получил сертификат Оркла по Java
<режим душнилы>В 2005-м сертификаты по Java выдавал Sun, а не Oracle </режим душнилы>
Не заменила, а дополнила
Заменила не собес, а тестовые задания, и 33-уровневый цирк с конями и найм по вайбу и софт-скиллам.
АСУТП нефтянка. Не ходишь под себя + добро от СБ = Бобро пожаловать. Можно и без корки))))
Я слышал есть такая штука диплом об образование. Говорят отличный вариант.
Люди готовы тратить 10 лет жизни на подтверждение стажа для рабочей визы и пару лет на самообразование, но не могут потратить 4 года с 16-18 до 20-22 лет на получение диплома.
Говорят. Вот только у меня, например, в дипломе (от 1988 года) написано "Техническая физика". При том, что разработкой профессионально занимаюсь с 1991-го. А программистов в те времена готовили только на матмехе универа (и подготовка там была достаточно специфической). И никаких мобильных, никакого web тогда не было. Писали на фортране, кто-то на коболе, кто-то на С. И, в основном, под большие машины типа ЕС-1033 или БЭСМ-6 (персоналки в те годы у нас только появлялись).
И что толку с того диплома в плане квалификации разработчика?
Если в дипломе написан гипоним к слову специальность, а не специалист, то он мало что говорит о его обладателе. Не то чтобы это было правилом, но наблюдения подтверждают это. Чем общéе специальность в дипломе - тем меньше.
Например, если в документе написано "обслуживание механизмов", "информационные технологии", "кулинария" - то это всё ни о чём. То есть это говорит, что человек отучился, что-то знает по теме (возможно, даже хорошо знает), но ничего не говорит о том, что он умеет и кем может работать.
Если же в документе написано "механик", "программист", "повар" - это уже лучше. Это означает, что данный человек может быть конкретным специалистом согласно диплому. И лучше быть да хоть поваром, чем "специалистом в области кулинарии".
Извините, но это полнейшая ерунда. По крайней мере по моему опыту нет вообще никакой корреляции между названиями/формулировками в дипломе и умениями людей.
Если в дипломе написан гипоним к слову специальность, а не специалист, то он мало что говорит о его обладателе
В моем случае это сделано намеренно. У нас у всего факультета (как и у других факультетов аналогичного профиля) пишется именно так. Ну на вкладыше в диплом чуть "более подробно" - ФТ-0311 :-)
Это "закрытый" фаукультет, курировался он минсредмашем (ныне росатом). Там не полагалось писать чему именно человека учили - все спецкурсы были закрытыми.
Это означает, что данный человек может быть конкретным специалистом
Это означает, что в его вузе так решили вписать, а им на это дал разрешение какой-то госорган. Всё.
А если написано «магистр», то человек может конкретно входить в совет джедаев или сидеть за столом в «Что? Где? Когда?»?
Диплом в этом плане актуален лет 5, потом уже либо человек большую часть знаний забыл, если не работал в этой сфере, либо они у него появились в ходе работы и самообучения.
Не смогут они оценивать человека как человека. Поезд ушёл. Они оценивают человека как автомат как минимум последние 10 лет, местами и больше. Культура уже воспроизвела себя. Максимум, что они сделают - добавят к оценке кандидата другого "нейроджинна". Этот кризис на Западе повсеместен и добрался уже и до небольших компаний. Пишу по личному опыту.
Будет первое
Сам сейчас прохожу много собеседований(ищу новое место) и выделяю для себя ряд забавных моментов.
кандидат должен уметь вообще все:
computer science
алгоритмы и структуры данных
свое направление (frontend, backend, …)
систему задизайнить
а еще коммуникативные навыки должны быть на пределе.
Вот это на самом деле довольно забавный момент, действительно люди хотят, чтобы ты знал все это еще и на очень глубоком уровне. То есть ты должен на протяжении лет 15 все это выучить, применить на проектах, знать, как все реализовано под капотом, все преимущества и недостатки, сложность всего этого, но платить мы тебе будем не сильно больше мидла.
Так же по обратной связи за частую стандартная отписка происходит. Недавно проходил собеседования с Авито - прошел первую секцию на аглоритмы без проблем. Далее, чтобы ускорить процесс попросил оставшиеся 2 секции поставить в 1 день. Мне их поставили и получилось такое:
2я секция решил задачу, в ОС сказали, что решил ее не оптимально (честно, нет вариантов, как можно решить оптимальнее). Хотел постичь тайну оптимального решения этой задачи - мне сказали, что такое они не разглашают, чтобы не слить свои задачи(хотя, суть задачи я помню и так и слить нет никаких проблем). Далее были действительно некоторые спорные моменты по одной из технологий, которую я знаю не на глубоком уровне.
3я секция - проектирование системы, проектировали начальную версию твиттера, как мне показалось - прошло все хорошо(учел все моменты, отвечал на доп. вопросы интервьюера). В итоге мне на эту секцию не дали фидбека вообще потому что по результатам 2го этапа я у них не прошел бы дальше.
Итого казалось бы большая компания, а нормального фидбека от них не получить, что уж тут говорить о мелких
Так а что за задача то в итоге? Напишите уж.
Есть 2 списка посещенные страницы и рекомендуемые.
Посещенные [5, 6, 9], Рекомендуемые [9, 1, 4]
Нужно вернуть список рекомендуемых, исключая посещенные, с той же сортировкой. Размеры список могут быть разными могут быть разными.
В этом примере результатом будет [1, 4] только в этой последовательности.
Мое решение:
Я сделал так - завернул посещенные в set(чтобы можно было искать за O(1)). Итерировался(зная индекс) по посещенным - смотрел есть ли в рекомендуемых и если да - удалял.
Возможно, они считали списки предварительно отсортированными, и хотели чтобы вы прошли двумя указателями по обоим спискам (типа как merge наоборот).
Что примечательно, вы уже знаете такой тип задач и я тоже так подумал, но знаем мы их не потому что на работе подобное делали, а потому что на собесдованиях с такими сталкивались. Такой сюр.
Нет, списки были не сортированными, так да взял бы 2 указателя
[9, 1, 4] на отсортированный непохож.
Возможно, ТС недопонял задание. Или, возможно, нужно было поддерживать эти списки всегда в отсортированном состоянии, чтобы иметь возможность фильтровать однопроходным алгоритмом. Кто его знает, какое решение авторы задачи имели в виду, когда давали её?
Кто его знает, какое решение авторы задачи имели в виду, когда давали её?
В этом и проблема таких задач, напридумывать можно очень много всего, но поди догадайся чего именно от тебя хотят. Вообще вопросов много, какой типичный размер списков, сколько всего страниц, может там вообще битовые маски сравнивать можно, кто его знает.
По логике задачи они скорее отсортированы по разым принципам (посещённые - по порядку посещения, рекомендуемые - приоритет). Может в удалениях проблема, если там структура с удалением за O(n) и надо было in place сделать.
set(чтобы можно было искать за O(1)
Тогда уж unordered_set?
Может быть ожидался не просто set а фильтр Блума?
Я сделал так - завернул посещенные в set(чтобы можно было искать за O(1)). Итерировался(зная индекс) по посещенным - смотрел есть ли в рекомендуемых и если да - удалял.
Завернуть в сет - это хорошо. Но надо было после этого итерироваться по рекомендуемым, с конца списка - тогда затраты на удаление будут минимальными, без возможных реаллокаций памяти.
Направление итерации на асимптотику алгоритма не влияет.
Если списки изначально вида arraylist, то удаление из списка хоть ты тресни будет неоптимально и вызывать реаллокации. Надо создавать новый arraylist result (сразу аллоцируя память размером Рекомендуемыe.size()) и по мере итерации добавлять отфильтрованные элементы в результирующий список.
Если изначально списки вида linkedlist, то там другая история
Если списки изначально вида arraylist, то удаление из списка хоть ты тресни будет неоптимально и вызывать реаллокации. Надо создавать новый arraylist result (сразу аллоцируя память размером Рекомендуемыe.size()) и по мере итерации добавлять отфильтрованные элементы в результирующий список.
В целом верно. Хотя, если список не сортированный (порядок следования элементов не важен), то "удаление" можно проводить путем копирования последнего элемента списка вместо удаляемого с уменьшением значения счетчика "количество элементов в списке".
Предположительно по скорости будет то же самое что и перенос подходящего элемента в новый список (тоже одно копирование), но по памяти экономичнее - один список вместо двух.
Идём по второму списку двумя указателями, по первому проверяем посещение, по второму записываем если посещения не было (ин-плейс, как писали выше). В конце подрезаем размер. И никаких реаллокаций.
Очень специфическое решение, подразумевающее что задача происходит в выжженом поле посреди бескрайнего ничего.
На практике такие задачи бессмысленны, ввиду наличия баз данных, в которых в любом случае будут происходить подобные вычисления.
Ну а если дело происходит в памяти - то set более простое и очевидное решение, очевидное для специалистов любого грэйда. Вместо поддержки очередного костыля впихнутого любителем алгоритмов в прод.
смотрел есть ли в рекомендуемых и если да - удалял.
Не знаю, что за язык и что за список, но предположу, что удаление из этого списка O(n).
"Удаление" из списка может быть очень экономичным - см выше (перенос последнего элемента вместо удаленного). Или вообще флажок "активен/не активен" для каждого элемента. Или два списка с переносом подходящих элементов из одного в другой (если нужно несколько "просевов" делать, то списки после каждого просева меняются местами).
Как раз недавно была такая задача с реализацией "play-off" алгоритма где в цикле на каждом этапе происходил отсев элементов, не прошедших отбор.
Возможно стоило аллоцировать мапу из посещенных, завести счетчик, и далее проходя по рекомендуемым, смотреть - есть ли элемент из рекомендуемых в мапе. Если же его нет, то мы меняем элемент по индексу счетчика в списке рекомендуемых на текущий, и инкрементируем счётчик. В конце обрезаем длину рекомендуемого списка по счетчику. То есть на примере: мы завели мапу из посещенных, идем по списку Рекомендуемых, счетчик = 0. Попадаем на элемент 9, есть в мапе, пропускаем. Далее следует 1, в мапе нет, заменяем в списке элемент с индексом счетчика(0) на 1, счетчик++. И в конце попадаем на 4, в мапе есть, заменяем в списке элемент с индексом счетчика(1) на 4, счетчик++. В итоге получается список [1, 4, 4], который мы обрезаем по значению счетчика(2).
По сути вернуть разность множеств B \ A (B - рекомендуемые, А - посещённые).
Задача из leetcode. (Только там нужно посчитать ещё в две стороны).
https://leetcode.com/problems/find-the-difference-of-two-arrays/
Не секрет, что IT-компании заботятся о своем hr-бренде
Так это делается для новых людей, чтобы пришли на собеседование, а не отказывали заранее. Как скидки для новых абонентов у операторов связи и сервисов подписки.
Но вообще, я все ждал когда автор доберёшься до многоступенчатых многодневных собесов, на мой взгляд, в плане отношения ко времени кпндидата, это ничем не лучше кривого тестового, его хотя бы сам решаешь когда делать, но автор их почему-то не упоминает.
Спасибо за отзыв. Я решил не включать это в статью, так как подобного опыта у меня было крайне мало. Одно или два подобных собеса, где весь процесс растягивался на недели, а опыт был крайне негативным.
Соглашусь, долгие процессы и многоступенчатые собеседования — отдельная боль из-а ощущения, что тебя хотят провести по всем кругам ада, которые только имеются. И усугубляется все тем, что в конце ты получаешь стандартную отписку без какой-либо обратной связи.
Раз уж упоминалась Альфа. Тут много систем, много направлений, много команд (вообще IT подразделение Альфы оценивается в примерно 5тыс человек по всем направлениям). И каждая проводит собес в своем формате.
У нас (центральные банковские системы - то, что работает на центральных серверах) собес (единственный) - это просто разговор с командой. Мы рассказываем чем занимаемся мы, кандидат - чем занимался он. Никаких алгоритмов, никаких тестовых задач.
А дальше уже и кандидат решает нужно ли ему вот это все вот и мы думаем подойдет ли он нам. Обычно после собеседования нескольких кандидатов команда их "рейтингует" - этот лучше всех, тот второй в списке, ну а тот на случай если первые два откажутся...
Все равно потом 3 месяца будет обучение с наставником ну и потом уже в процессе работы наберется опыта.
А это не вы мне фидбек дали: "не подходит, потому что слишком самостоятельный"?
Обычно после собеседования нескольких кандидатов команда их "рейтингует"
"Всё познаётся в сравнении".
Вообще, хороший подход, потому что если оценивать всех кандидатов индивидуально, недостатки можно найти у кого угодно. Когда мы выбираем из нескольких вариантов, включаются совершенно другие когнитивные механизмы, чем если бы мы принимали решение - взять ли конкретного человека. Разная мотивация и разная цена ошибки.
Ну тут вопрос выбора из имеющихся...
Вот в последний раз собеседовали троих. Собеседующих было 3 или 4 человека. Когда всех троих "отсобеседовали" (по очереди) потом собрались и обсудили кому кто и почему понравился или не понравился. Выстроили рейтинг. Послали офер первому по рейтингу. Но он уже нашел себе что-то другое и отказался. Тогда послали следующему. Тот согласился. Сейчас работает.
Это вопрос команды - руководитель управления (в нашей иерархии - административный рукводитель) и лиды (тимлид,техлид). Может быть еще "функциональный руководитель" (тот, с кем решаются все рабочие вопросы, не административные). И раз мы ищем человека в команду, с которым нам потом работать, то решает тут все-таки команда.
Спасибо за комментарий! Хороший подход. А ведется ли какая-то статистка, чтобы понять, сколько решений вынесено удачно, а сколько нет?
Хорошо подметили про наставника. Считаю, что это вполне закрывает некоторые пробелы, выявленные на собеседовании. Так и так кандидат будет вникать, спрашивать, изучать экосистему. А там уже разберется.
"существует ряд компаний-комертонов" кАмертон же
весь абзац "Пришлось покряхтеть с реализацией, .............. но осадочек остался. " повторяется два раза.
Следующий за ним "Проводя интервью ...." тоже, но частично
Добавлю свой опыт: технические собеседования могу вестись по алгоритмам, по пониманию предметной области, по логике специалиста, по стремлению развиваться. Лучшие мои работы "мечты" были такие, где будущий руководитель беседовал со мной немного по знаниям, много по софтам и получал от меня пакет моих работ.
Считаю, что касается технической части, вроде алгоритмов и знаний предмета можно давать тестовое задание на пару часов, которое можно оценить количественно и качественно минут за 10 и выяснить лишь грейд специалиста.
Тестовые задания, по моей оценке поглощающие более двух часов моего времени характеризуют работодателя с худшей стороны. Именно так работодатель доказывает, что ему плевать на личное время потенциального сотрудника.
Итого: собес с Хантером 30 минут, второй собес с хантером еще 30 минут, 1-2 часа техсобес очно, 2+ часа на задание уже приблизительно 5 часов времени, когда работающий в другом месте специалист в режиме многозадачности пытается не провалить собеседование.
Если, конечно, работодатель очень желаемый, то можно и потратить время. Но, как правило, нет.
Все, что выходит за рамки "поговорить с командой на предмет поиска точек общих интересов" уже не интересует.
Вообще преподносить работу как милость, которую еще надо заслужить - такое себе...
Вообще преподносить работу как милость, которую еще надо заслужить - такое себе...
В этот момент все фаанги планеты издают демонический смех ))))
А как же бессмертное
Работать в нашем банке — большая честь
(не намекаю на ваше или автора место работы, цитата принадлежит сотруднику другого банка, все совпадения случайны)
Спасибо за статью. Видно, что здесь результат плотной деятельности по проведению и прохождению интервью.
Супер, спасибо за мысли и опыт. Особенно коснулся момент по поводу включения в интервью реальных задач, с которыми столкнётся человек, а не просто заданиями по типу "ну, это же бэст прэктис". Актуально для любой сферы.
На старте работы в найме не придавала этому значения, думала, что могу сама правильно декомпозировать запрос работодателя и из него выстроить вопросы/задания для первичного собеса с кандидатом. В итоге опытные и классные ребята, идеально подходящие под запрос, пролетали на этапе собеса с нанимающей командой, и оказывалось, что им задавали вопросы максимально отличающиеся от изначально сформулированного запроса. "Что за ...?" - не могла я понять, пока не дошло, что нужно прям вынуть (а если будет нужно и принудительно) из нанимателя конкретные задачи, на которые он ищет человека (а не хотелки уровня "хочу найти родственную душу и чтоб код писал, как Толстой романы"). Кто-то закатит глаза и скажет: "Банально просто!" Да, но оказалось не так очевидно в начале пути.
Спасибо за отзыв!
Соглашусь, сбор четких критериев и хотелок нанимателя крайне важно, чтобы подобрать более подходящих кандидатов. Это довольно объемная и сложная тема, которую надо так же практиковать. Часто встречаю проблемы на этом этапе, когда описание вакансии составляется некорректно или слишком абстрактно, с включением максимума ключевых слов.
Отмечу, что еще важно следить за судьбой кандидата, если вы дали добро после интревью. Был опыт, когда кандидат мне очень понравился, рекомендовал его в команду, а он не прижился. Так что следует держать руку на пульсе и рефлексировать, это может помочь в будущем.
С техническими собеседованиями вообще всегда было непросто - последние 10 лет все кинулись решать задачи, до этого (~ 2010 - 2012) все были укушены паттернами программирования, чуть раньше и одновременно с этим досконально зубрили стандарт языка, чтобы отвечать на бесконечные вопросы "что выдаст вот этот говнокод".
Но вообще алгосы нужны, но в них нужна мера. По моему опыту, нужно обязательно проверять 4 вещи: знает ли человек про динамический массив и куда в него можно вставлять, а куда нельзя, знает ли про двусвязный список и куда в него можно вставлять, а куда нельзя, знает ли пользу сортировки и бинарного поиска и знает ли, что такое хэш-мапа. RB-мапа - как бонус. Потому что 80% неоптимального кода - когда юзают динамический массив вместо мапы. 20% - на все остальное, преимущественно списки (это моя личная статистика за ~12 лет, когда я так или иначе ревьюил чужой код в разных компаниях).
Тестовое задание - вообще тема. Если честно, я бы никогда не взял человека, который откажется сделать тестовое. Единственный минус тестового - нет уверенности в том, что человек его сделал лично, даже после беседы (да, я обожаю делать тестовые, никогда не отказывался и всегда они были интересными).
Просто на поговорить - мне кажется, такие собеседования контрпродуктивны, так как проверяют навыки коммуникации, а не собственно разработки, я такие интервью не люблю ни проводить, ни проходить.
Если честно, я бы никогда не взял человека, который откажется сделать тестовое.
Как интересно устроен мир: вы бы меня не взяли, а я бы к вам и не пошёл.
А если серьёзно, вы рассуждаете исключительно с точки зрения своего удобства как нанимателя. Кажется, вам самому надо пройти пару-тройку собесов для разнообразия.
Тестовое задание - вообще тема.
Скопируйте, пожалуйста, в ответный комментарий 5 последних ответов на тестовые задания, если не сложно.
Очень интересно прочитать, как дают обратную связь в нормальных компаниях. Без имён, анонимно, естественно, чтобы ничего не нарушить.
Зачастую нет вообще никакой обратной связи, ни в больших компаниях, ни в средних, ни тем более в маленьких. Обычно всегда говорят так: "Да вы нам подходите, мы с вами свяжемся...". И всё на этом. Ещё задают не те задания, задают вопросы которые вообще никакого отношения не имеют к должности которую предлагают, спрашивают совершенно не то для чего ищут сотрудника. Я давно уже понял то что эти так называемые рекрутеры берут вопросы из каких-то шаблонов.
Работаю на промпредприятии.
Программисты, насколько я знаю, просто давали задание часа на два, а потом смотрели на результат. Сколько себя помню, ни про кого ничего плохого не говорили, т.е. про работу спросили, работу потом и получали.
----
Мы в техподдержке старались брать только знакомых (ошибка в работе рекомендуемого - это минус рекомендующего), а если через кадровиков, то просили только резюме (никаких тестов на корреляцию знака зодиака претендента с площадью предприятия и ИНН секретаря генерального директора).
Приглашали соискателя и рассказывали: з/п базовую; з/п с переработками; что пользователи адекватны не все; что техника разная; что если на производстве что-то бумкнуло в 2 часа ночи, то один беги и восстанавливай с принтером/системником/сканером/монитором в зубах (напарник остаётся на телефоне и если может, то помогает только дистанционно, а резерв на месте стоит не всегда); что если открыли простой производства, то будь готов с написать подробно что-где-когда и договориться с производственниками, чтобы они отозвали простой; что частенько бывает так, что что-то крикнут в трубку и сразу бросят её: нужно сделать обратный звонок (слава АОНу), выяснить что-где-когда и постараться помочь или найти исполнителя; что смены начинаются с привязкой к графику производства: цеховые к 07:00, наши к 06:30, чтобы проверить/восстановить работу систем, домой вторая смена ночью; что с 17:00 до 08:00 ты админ ИС и перезагрузить сервер или узлы системы – это рутинная операция; что придётся ходить к директорам на поддержку конференций, где можно всякое услышать в адрес ИТ-службы и себя лично; что если проблема на стороне иностранцев, то быстренько оформи инцидент в их системе (Do you speak English?), накидай туда логов, утром поясни им, кто редиска и почему, оповести руководство; что ночью у тебя только три друга: твой мозг, твой напарник и папка с документацией по ИС; что бесплатные печеньки и кофе дома; что "team building" у нас – это не перетягивание каната, а вот это всё описанное выше. В общем – вводили в курс дела.
Зато: кто не пугался, все вписывались в коллектив; всегда помощь друг другу; если эмоции, то на полную, до достижения результата; если решил уйти, то в добрый путь, с наилучшими пожеланиями.
ОЧЕНЬ помогало то, что техподдержка, предоставление доступа и админы были в одном помещении, что даёт рассмотреть любую проблему сразу со всех сторон. Да и программисты для нас не небожители: всё работает – молодцы, что-то сломалось – БЕГИТЕ разбираться вместе.
PS. Всё написал в прошедшем времени, потому что сейчас я занимаюсь другим.
PSS. В Альфе я сам не работал. Работал бывший коллега (сильнейший программист, из тех, кого я знал тогда), был доволен. Лично я общался с сотрудниками Альфы в Москве, когда мы выбирали ITSM- систему (внедренцы сделали нам экскурсию по 4-м организациям с 4-мя разными ИС). До сих пор ощущение спаянного коллектива, настоящей команды без лишних.
пользователи адекватны не все; что техника разная; что если на производстве что-то бумкнуло в 2 часа ночи, то один беги и восстанавливай с принтером/системником/сканером/монитором в зубах...
Вот я тоже предпочитаю сразу карты на стол - платформа мощная, интересная, но весьма специфическая. Т.е. весь опыт будет "нерелевантным" - в стране мало кто ее использует. Требования по производительности, эффективности очень жесткие. Чтобы потом у человека не было "а я не это загадывал..." (с)
Но при этом "люди хорошие" :-) Всегда помогут, всегда ответят, отношения всегда доброжелательные. Руководство адекватное. По деньгам тоже норм.
Мое личное мнение, что невозможно в принципе улучшить процес найма и собеседования. А причина банальна до безобразия - бизнес ищет не того, кто им нужен на самом деле. Попробую раскрыть свою мысль. Любая работа, это не про алгоритмы и закрытие тасок - это про социум, отношения и достижение общей цели. Предположим, что вы молодой парень (а может уже и не очень молодой), и вы хотите построить семью. Вопрос номер один: зачем вам это нужно. Если ответ звучит, как: чтобы стирала, убирала и сопли мне вытирала, то это явно не про построение семьи идет речь. Если вам это нужно для того, чтобы поделиться вашей любовью и заботой, разделить все тяготы совместной жизни и все радости, завести детей, то это уже кардинально другая стратегия. Если вы решили, что семья - это первый ответ, то вполне логично, что вы дилегируете поиск "жены" HR менеджеру, а собеседование будет проводить ваш женатый коллега, с опытом эксплуатации жены семейной жизни. Если ответ второй, то вы озаботитесь поиском сами. Второй вопрос, а как вы будете искать свою половинку? Дадите объявление, что вы молодой и данамично развивающийся парень, и ваша будущая половинка получит хороший опыт, большие перспективы и бесплатный абонемент в тренажерный зал? Опишите требуемый опыт и набор навыков? Думаете, что это сработает? Не буду дальше все расписывать до мелочей, надеюсь, что читатель и сам поймет суть аналогии.
Еще одну аналогию могу привести в пример. Предположим, что на СТО приехал клиент и просит заменить ему свечи зажигания. Механик делает замену свечей, а клиент начинает недовольно предъявлять претензии, что он не доволен проделанной работой. Когда к спору подключается руководство и начинают выяснять, в чем причина, то клиент заявляет, что проблема в том, что двигатель его автомобиля троит, и он решил, что проблема в свечах. Почему он так решил, да потому, что это самое бюджетное решение проблемы из всех возможных, поэтому он его и выбрал. Получается, что проблема клиента - это троящий двигатель, который жрет бензин и колбасит весь автомобиль, но он не об этом говорит механику, а просит произвести замену свечей, надеясь, что само все как-то решится. А когда его надежды рухнули, начинает в этом винить не себя, а механика.
Возвращаемся к бизнесу и найму. Из вышеописанных примеров вполне ясно, что речь не идет о каких-то технических знаниях, а речь идет об отношениях между людьми. Топ менеджер в 99% случаев ведет себя, как клиент на СТО из второго примера или ищет себе рабыню "жену" из первого примера. А при таком подходе это в принципе не может решить проблемы и потребности бизнеса, поэтому и ищут не того, кто реально нужен. А главное, скидывают этот поиск на людей, которым бизнес босса вообще по барабану. Сегодня они здесь, а завтра их уволили. И в какой-то момент сотрудник понимает, что он больше не хочет быть "женой" с односторонней любовью. Поэтому все эти собеседования не про то, что будет выбран самый подходящий кандидат для решения поставленных бизнес задач, а про то, что будет выбран сотрудник, который лично понравится собеседующему, по его каким-то внутренним убеждениям и критериям. А это уж точно не про бизнес! Отсюда вывод: сама система найма в корне неправильна, а значит нет никаких рецептов для улучшения этого процесса, так как борьба идет не с причиной, а со следствием.
А причина банальна до безобразия - бизнес ищет не того, кто им нужен на самом деле.
На самом деле, бизнесу нужно чтобы его задачи решались. Как - это уже наша забота и головная боль. Поэтому выбор способа решения задач бизнеса лежит на нас, а не на бизнесе. Бизнес зарабатывает деньги, мы ему в этом помогаем за "толику малую" от заработанного.
И как много денег вы помогли заработать бизнесу? Вам компания скинула финансовый отчет лично по вашей персоне? А что значит, что задачи решались? Задача "сделать меня богатым за три месяца", как вами решается?
Конкретно по моей персоне не так давно
Вам сегодня должна прийти премия за особый вклад в развитие и оптимизацию нашей АБС, который сделан в рамках проекта Феникс, в части оптимизации процедур процедуры массовых проверок клиентов в части комплаенс процедур и проверок - рассылки уведомлений на наличие паспортов в ФМС (сокращение c 2 часов до 40 минут), ускорении процедуры актуализации данных по клиентам, оптимизацию проверки по спискам террористов
Это не столько про "заработать" сколько про то, чтобы не огрести проблем от регулятора и убытков (в т.ч. и репутационных) со стороны клиентов от того, что что-то тормозит или не работает.
Это "внеплановая" премия (вполне себе ощутимого размера) помимо регулярных бонусов.
Задача "сделать меня богатым за три месяца", как вами решается?
Путем направления к бизнесу толкового аналитика. Который принесет в клювике нормально сформулированные бизнес-цели. Потом подключаем архитектора. И вот у нас определены стейкхолдеры, скоуп проекта, есть черновик архитектуры, оценка трудозатрат, матрица рисков и вот это все.
Подключаем еще людей, и каждый в рамках своей компетенции делает кусочек паззла, чтобы бизнес стал богатым.
Насколько много каждый сотрудник принести бизнесу денег - вопрос риторический. Ответа на него нет.
Зато есть ответ на вопрос какая у проекта экономическая эффективность.
А подключаете, это как? Через какой-то порт, который есть в теле менеджера? А что значит, направляете аналитика? Вы, как наемный сотрудник, нанимаете за свой счет аналитика (которого еще нужно найти под конкретные бизнес задачи) и направляете его своему боссу? Все это софистика, которая не имеет к реальности никакого отношения.
А вот что действительно имеет отношение к реальности, так это то, что Гугл в этом году закрыл ряд своих проектов, в которые вложил сотни миллионов долларов (например из сегодняшнего, это Гугл подкасты), если не больше. И там были и толковые архитекторы, аналитики и разработчики. Но это никоем образом не сделало их продукты конкурентно способными, хотя компания, по факту, является крупным монополистом с "бесконечными" ресурсами.
И тут возникает вполне логичный вопрос, а почему же ваша логика не сработала в такой компании, как Гугл? А может потому, что подход в корне неверен?
А подключаете, это как? Через какой-то порт, который есть в теле менеджера?
Да.
Есть такой порт. Называется рот и уши.
Все это софистика, которая не имеет к реальности никакого отношения.
все это - реализация конкретных проектов, которые более чем имеют отношения к реальности. Проектов которые приносят прибыль. Или не приносят по тем или иным причинам.
Реализация определенных рисков вовсе не говорит о том, что методология разработки плохая. Если мат. ожидание прибыли больше нуля - значит, все нормально. Даже , если какие-то конкретно проекты закрываются с убытком.
И тут возникает вполне логичный вопрос, а почему же ваша логика не сработала в такой компании, как Гугл?
А может наоборот, сработала?
Количество прибыльных проектов явно выше количества убыточных.
Бизнес это не только деньги. Это еще и жизнь бизнесмена, его время и нервы на управление. Его возможность похвалиться своим детищем.
Люди по-разному ведут свой бизнес.
Бизнес может вложиться в процесс найма и организовать его так, чтобы и нанимались люди грамотно и процесс работы был грамотный.
Вы серьезно считает что можно нанять какого-то "специалиста", который сможет адекватно оценивать уровень человека в той области, где он не является профессионалом высокого уровня?
Искусство управления заключается в том, чтобы уметь грамотно делегировать полномочия профессионалам. Если вам говорят "нам в команду нужен еще один человек" и убедительно это аргументируют - дайте команде самой подобрать того, с кем им потом работать. Не вмешивайтесь в то, чего не понимаете. Разные оргвопросы - да, возьмите на себя. Но выбор должен быть за командой. Только так вы получите действительно сильную команду, а не сборище случайных людей.
Вопрос номер один: зачем вам это нужно. Если ответ звучит, как: чтобы стирала, убирала и сопли мне вытирала, то это явно не про построение семьи идет речь. Если вам это нужно для того, чтобы поделиться вашей любовью и заботой, разделить все тяготы совместной жизни и все радости, завести детей, то это уже кардинально другая стратегия. Если вы решили, что семья - это первый ответ, то вполне логично, что вы дилегируете поиск "жены" HR менеджеру, а собеседование будет проводить ваш женатый коллега, с опытом
эксплуатации женысемейной жизни. Если ответ второй, то вы озаботитесь поиском сами.
Да что ж вы делаете-то! *утащил и поставил в рамочку*
Во всех рассуждениях о найме и том, как надо проводить собеседования, я вижу пугающее отсутствие каких-либо эмпирических данных об эффективности того или иного метода отбора.
Понятно, что полноценные исследования могут проводить либо очень большие компании, либо агенства. Но даже им очень тяжело оценить свой уровень ложно-отрицательных ошибок - разве что случайным образом брать тех, кого забраковал HR/нанимающий менеджер, и смотреть, как они будут работать.
С другой стороны, даже если такие исследования кто-то делает, то публиковать их результаты - не в интересах команий/агенств, т.к. кандидаты могут прочесть его и начать мимикрировать под хороших кандидатов.
Спасибо,
граммар наци
только не «подчерпнуть», а почерпнуть. Грамотная письменная речь — лицо компании.
Надеюсь, вы смогли подчерпнуть для себя что-то новое.
Классная статья! Самое главное, что все это прожито на практике. Респектую автору.
Статья хорошая, правда для нашего интервью косяков не нашёл. Мы делаем мини-проект из двух частей, которые симулируют жизненный цикл проекта. Первая часть mvp на пару часов, дальше мини-тикеты на его улучшение. Такой структурой убиваем сразу пачку зайцев: chatgpt теряет контекст (пользоваться можно всем) и кандидаты без головы отлетают; видим как человек адаптируется к изменениям; задачи сменяются и человеку интересно; можно оценивать сколько доп тикетов сделано и их уровень
Спасибо за комментарий! Под mvp вы имеете в виду тестовое задание? Если да и это возможно, то поделитесь, пожалуйста, заданием подробнее, звучит интересно
Самим заданием не поделюсь, по понятным причинам. Подробнее - сначала мы просим сделать совсем примитивную фигню типа "нужно приложение которое умеет Х" (например страница форума с кнопкой "ответ" и записью в базу, без регистрации и смс). На это идёт 2-3 часа чтоб человек успел взять кофе, оттупить и вообще.
Дальше идут доп "тикеты" типа "прикрути регистрацию", "прикрути редактирование", "загрузка файлов", "деплой" и прочее. И к ним идёт условие что "приложение должно жить", то есть никаких вайпов базы и прочего. Тикеты бывают разной сложности, от "напиши докерфайл" до "сделай биллинг с моками" (утрирую, биллинга нет).
На тест идёт целый день, с 9 до 5 с обедом. До этого мини-разговор по видео и онлайн-тест (примитивный)
Интересно, спасибо, что поделились. А сколько обычно занимает процесс закрытия такого проекта? Это присходит в асинхронном режиме? Почему решили не выдавать все задание целиком?
Проект на день с 9 до 5, это он-сайт интервью (дорогу/проживание покрываем), закрытие минут 30-40 включая демо, пару вопросов по не вошедшим тикетам типа "а как бы сделали", ну и просто за жизнь поговорить. Всё синхронно, можно общаться с командой, задавать вопросы и прочее. По сути пытаемся приблизить тест к жизни (удалёнку не практикуем, только офис). Потому же и задание идёт частями, продукт всё-таки не сразу имеет все возможные тз на весь цикл, сначала mvp, дальше по ситуации.
Плюс очень большой момент с выдачей по частям это chatgpt, он довольно быстро теряет контекст задачи и начинает генерить бред. У нас уже была пара chatgpt-программистов, такое себе, код красивый и абсолютно бессмысленный.
Какое-то лютое моталово, если честно. Кандидаты очень сильно должны хотеть у вас работать, если соглашаются на такое. Интересно, чем вы их так привлекаете.
Кажется, что без ущерба качеству можно было бы подготовить для собеседуемых основу проекта, которую уже надо допилить (когда-то занимался таким: у меня даже был отдельный сервак, на котором я для каждого нового кандидата разворачивал свежую тестовую среду).
Вот что вы проверяете первым этапом, когда он создаёт страницу с кнопкой? Что он может нагуглить бойлерплейт, получается. Вся сложность же потом начинается. Зато стресса от того, что надо на собеседовании всё делать с нуля, кандидат хапает прям с порога.
Про моталово я ответил в другой ветке, где и упомянул что речь про Швейцарию, а не про Россию. Чем привлекаем думаю тоже понятно, как минимум зарплатой.
Про среду и прочее - можно. Но пока идея такая что кандидат свободен юзать что умеет, и главное - умение решать задачу, а не настраивать неизвестный ему фреймворк
Тогда да, это многое меняет)
У нас это по сути единственный вариант. Компания небольшая, мороки при найме прилично (Швейцария не ЕС, нужно оформлять пермит даже для европейцев), с жильём для вновь прибывших засада (съем в женеве это боль), да и айтишников в Европе вообще-то не густо. То есть да, в Москве можно найти условного питониста который умеет работать например с фастапи, постгресом и такой-то либой для аналитики. У нас же в лучшем случае выйдет найти питониста с мозгами, который сможет все это освоить в разумные сроки, и то его придётся везти с севера Франции. Завлекаем тем что зп выше чем в окрестных странах раза в 3, ну и что есть достаточно умные люди которые после крупных гуглоамазонов хотят в небольшую компанию чтоб просто иметь импакт, а не долбить одну и ту же функцию до посинения.
Ну и моталово мы пытаемся сгладить. Например рейс не день в день, а в субботу чтоб пару дней погулять по городу. И отель не койка в хостеле с клопами, а нормальный с завтраками и прочим. Понятно что все равно такое, но как лучше я хз.
И видимо ожидается что соискатель всё это будет делать забесплатно?
В плане? Это собеседование. Проезд/жилье оплачиваем если соискатель из другого города/страны. Проект к основному бизнесу не относится никак вообще, его результаты мы тоже кроме оценки соискателя использовать не будем, это отдельно прописано в той кипе бумаг которую подписывают перед собесом. Вы что, платите деньги за собеседование? Я б прошёл в таком разе.
Удивительно как быстро вы уловили суть вопроса. Компании занимаются всей этой ерундой с тестовыми заданиями только потому что для них это бесплатно.
Как только оказывается, что надо платить, то методики отбора существенно меняются - выгоднее не давать тестовое задание, а после собеседования сразу нанимать и оценивать работу уже в процессе испытательного срока. Что характерно, имено такой процесс предусмотрен законом.
А принудительный бесплатный труд, который выдаётся за "тестовое задание" наоборот законом запрещён.
Во-первых законом тестовые задания не запрещены, и я не знаю откуда вы взяли этот бред. Равно как и не понимаю почему вы назвали его принудительным, вы сами подались на вакансию, не хотите - не надо.
после собеседования сразу нанимать и оценивать работу уже в процессе испытательного срока.
Вы очень плохо себе представляете рынок труда и законы в Европе. Да, внезапно, я живу в Швейцарии и компания внезапно тоже здесь. Нанять "сразу" у вас не выйдет просто потому что notice period здесь обычно от 2-3 месяцев и выше, а не 2 недели как в России. Нельзя просто "взять и нанять".
Далее, я живу в Женеве, население 500к человек, и для Европы это нормальный город. Айти здесь не особо популярно, соответственно 99% соискателей живут в лучшем случае в радиусе 100км, а обычно ещё дальше, у нас был ровно один чувак из непосредственно Женевы. То есть после принятого оффера соискателю придётся натурально переезжать как минимум в другой город, и скорее всего - в другую страну, со всеми вытекающими арендами, счетами, регистрациями и т.д.. В такой ситуации выгнать тряпками на мороз через 3 месяца испытательного просто по-человечески некрасиво, потому и делается полный день на месте чтоб и мы, и кандидат убедились что по крайней мере не бесит друг друга.
Как только оказывается, что надо платить
И вот на этот счёт - я там выше написал что жилье и проезд оплачен. И я имел ввиду не метро, а самолёт из условного Мадрида и отель в Женеве. Это стоит денег, поверьте.
Очень хорошо, что вы всё-таки решили упомянуть о том, что говорите об особенностях найма в Европе (хотя это не так уж важно для топика).
Нанять "сразу" у вас не выйдет просто потому что notice period здесь обычно от 2-3 месяцев и выше, а не 2 недели как в России. Нельзя просто "взять и нанять".
Notice period это же про увольнение? А нанять-то никакой проблемы нет, я так полагаю. В России для уведомления по увольнению на испытательном сроке даже не 2 недели, а 3 дня. Не знаю как это в Швейцарии, но для испытательного срока что-то аналогичное по-любому должно быть предусмотрено.
То есть после принятого оффера соискателю придётся натурально переезжать
Странно, конечно, что в 2024 году для работы предполагается куда-то переезжать. Но опять же, это это отдельный вопрос, не относящийся к тому, что за работу по выполнению "тестового задания" вы почему-то считаете нормальным не платить.
Равно как и не понимаю почему вы назвали его принудительным, вы сами подались на вакансию, не хотите - не надо.
"Тестовое задание" не было бы принудительным, если бы отказ от его выполнения не влёк за собой негативных последствий для соискателя. Но работодатели зачастую практикуют отказ от дальнейшего рассмотрения соискателя на позицию по вакансии как меру принуждения к выполнению "тестовых заданий", из-за этого и стоит рассматривать "тестовые задания" как принудительный труд.
В такой ситуации выгнать тряпками на мороз через 3 месяца испытательного просто по-человечески некрасиво, потому и делается полный день на месте
И вот на этот счёт - я там выше написал что жилье и проезд оплачен. И я имел ввиду не метро, а самолёт из условного Мадрида и отель в Женеве. Это стоит денег, поверьте.
Если работодатель очень заботится о том что его действия некрасивы, то ничто не мешает работодателю оплатить жильё для нового сотрудника на время испытательного срока, тогда уволив неподошедшего сотрудника не придётся сильно переживать.
Notice period это же про увольнение? А нанять-то никакой проблемы нет
А человек вот прям сидит без работы и ждёт когда ж вы его наймете. Нет, это значит что после собеседования компании надо ещё от 2 до 6 месяцев ждать пока человек выйдет. И кстати он может ещё отказаться, контракт не подписан.
Странно, конечно, что в 2024 году для работы предполагается куда-то переезжать
У нас фулл-тайм в офисе, без удаленки. Если вам нужна удаленка - ну, работайте там где она есть, никто не заставляет же.
Тестовое задание" не было бы принудительным, если бы отказ от его выполнения не влёк за собой негативных последствий для соискателя
Что за шиза? Негативные последствия это на работу не возьмут? А за что брать, за красивые глаза? Или просто "на посмотреть"? И зарплату тоже платить при этом, даже если квалификация на нуле? Зашибись план, звучит надёжно
ничто не мешает работодателю оплатить жильё для нового сотрудника на время испытательного срока, тогда уволив неподошедшего сотрудника не придётся сильно переживать.
Не совсем. Во-первых переезд это стресс. Во-вторых снять жилье здесь мягко говоря сложно, и если контракт меньше 3 лет то ценник будет конский. В-третьих жилье от компании это доход, с дохода налог, шкала прогрессивная, учитывая цены на меблированные квартиры (а это редкость) на срок меньше года человеку с зп после налогов не останется нихрена.
Короче вы пишете какую-то невероятную чушь уровня школьника с розовыми очками и ощущением что ему все должны. Это не так. Трудовой договор это именно договор, между двумя партиями, от которого обе стороны получают выгоду. Это не благотворительность и не содержание.
Читать дальше после слов о бесполезности алгоритмических задач считаю бесполезным.
Спасибо за комментарий! Считаю бесполезными их для себя. Опять же, если вы разрабатываете низкоуровневые вещи, новые алгоритмы, движки, утилитарное ПО - то это важный навык, которой стоит проверять.
Хотел еще добавить кое-что. По факту, человек все делает через алгоритмы. Мы программируем на алгоритмах, наши программы — комбинация алгоритмов. Другой вопрос, какая их сложность, для чего используются.
Если говорить конкретно, то алгоритмы для обхода графа мне не нужны сейчас. Я знаю, что такие есть в готовом виде, о них написано много материалов. Если понадобятся, возьму готовые. Если задача будет требовать, то погружусь детальнее.
Все зависит от целей. Например, мне в разы интереснее стало погружаться в создание и развитие продуктов. Мне уже не так важно, на каких технологиях это будет сделано — не принципиальный и не первостепенный вопрос, лишь бы создавало ценность. А есть инженеры, которым нравится изучать вопрос детально: раскладывать технологии на винтики, разбирать механики. Супер! Такие люди тоже нужны, без них никуда. Вопрос в том, где они нужны и в каком количестве.
Спорно, смотря какая вакансия. Вот например для условного перекладывателя жсонов с фронта в базу зачем нужно знать как r‐b tree работает или как сделать in-place сортировку? Не, оно полезно, я не спорю, но это не определяющий фактор. Это все равно что спрашивать у фронта основы сети - да, неплохо бы знать что такое dns и как оно работает, но есть и более важные для него вещи
"что с собеседованиями не так"? - то что каждая контора или средненький тимлид хочет написать статью про собеседования на Хабре.
Уже тыщу раз одно и то же перелопатили - и что изменилось? Ничего. Рынок и нехватка рабочих рук - вот что влияет на процессы найма. Если нужно много работников и быстро - процесс найма будет упрощён. Если собираете сливки с рынка - будете выдумывать хитрые этапы, чтобы купить бриллиант по цене сгущенки.
Все что надо знать соискателю - если тебе не нравится как проходит собес, скорее всего, тебе и работа в конторе не понравится - скипай и ищи дальше. Благо вариантов много.
Спасибо за комментарий!
В целом, вы правы. Видел не одну статью на эту тематику, но все же решился написать, так как это был внутренний позыв хайпануть.
Что касается полезности/бесполезности материала, это вещь субъективная. Не претендовал на смену мирового порядка, но если хотя бы 1 человек вынес для себя что-то новое и увидел альтернативу, которую можно внести в свою практику, то я считаю задачу выполненной.
P.S. Я не тимлид c:
Про JB пример видится жизненным как раз с точки зрения реальной работы.
Какой бы ни был коллектив и налаженные процессы - чаще всего выстраивать разработку приходится по разного уровня ущербности драфтам, которые друг-другу где-то противоречат, где-то копируют, многое умалчивают и главная задача все это систематизировать прежде чем писать код. Наверняка можно было спросить насчет вопросов по заданию и наверняка на них отвечают. А код любой сложности ты должен уметь писать по умолчанию. Не важно умеешь ли ты это на бумажке, или с гуглом/чатгпт в обнимку.
А все сложившиеся приседания с целью выявить надрессированную на справочники по сдк и алгоритмы мартышку это конечно же профанация.
Спасибо за комментарий!
Вы правы, в настоящей работе часто многое неизвестно, так же присутствует человеческий фактор. Хаос, бюрократия и прочее. И в этих реалиях приходится жить. Что касается тестового задания, то на мой взгляд, это не mind games, это просто халтура. В случае JB она оказалась незначительной, я по большей части придрался к оформлению, а задавать вопросы не было необходимости, так как разобрался с условиями. Я стараюсь задавать вопросы по тестовым в крайних случаях, так как, во-первых, люди работают, а я их буду отвлекать. Во-вторых, переписка чаще всего идет по почте, а это не самый быстрый канал коммуникации, а ручки то чешутся.
В идеале бизнес работает в логике: вложен капитал, его необходимо обернуть чтобы получить рост, для этого требуется живой работник, работник должен изготовить достаточный для рынка продукт чтобы тот продать.
Почему тогда бизнес отказывается нанимать работника готового работать? Причин может быть несколько:
1) работников хватает,
2) вклад этого работника на (конкретно) этом предприятии незначительно влияет на продукт,
3) навыков работника не достаточно, чтобы произвести продукт (конкретно) в той бизнес-модели, в которой существует предприятие,
4) (конкретно) этот бизнес - на самом деле не бизнес, и не занимается оборотом капитала,
5) с рынком происходят изменения, что ставит под вопрос производства продукта,
-- наверное список можно продолжить.
Если эти причины правда имеют место и набор работников всё равно происходит, то налицо отрыв целей набора от целей бизнеса.
Вот и получаются ничем неограниченные, свободные творческие поиски методик собеседований.
Какая разница как набирать людей, если сама задача набора людей не ограничена ни сроком, ни целью, ни требованиями качества.
Мне нравится такой подход к собеседованию. Помню, что где-то на просторах интернета видел собес в Альфу на котором собеседующие спрашивали, что будет если функцию 2 раза привязать к контекстам через bind (запомнил только это, но там было еще много чего интересного)
Одна из немногих статей про собесы, которая понравилась целиком.
Так а в чëм проблема задач вроде "переворачивания матриц"? Я могу понять неприязнь к более сложным задачам, но эта же совсем элементарна и подвластна любому первокурснику! Кажется авторы таких статей совсем перегибают палку, надо как-то более явно границы обозначать.
Спасибо за комментарий.
Поясню. В конкретном случае я не маркировал задачу на переворот матриц как сложную или легкую. Подметил сам факт наличия данной задачи в списке задач. На мой взгляд, эта задача крайне скучная.
На самом деле в том собеседовании был другой забавный нюанс, который я не обозначил, связанный с этой задачей. Собеседущие постоянно вносили корректировки в условия. И нужно было в конце выдать функцию, которая может переворачивать матрицы n на m с использованием только одного цикла на всю функцию.
Так а в чëм проблема задач вроде "переворачивания матриц"?
Проблемы начинаются, когда размер матрицы кратен кэшу процессора. :)
Покажет, что человек знает что такое массив :)
Я бы такие задачи отнёс в разряд "отсеять совсем слабых". Углубляться в дополнительные условия - на мой взгляд действительно лишнее, особенно если в реальной работе такого делать не придётся
Читал уже несколько подобных статей и мне давно было интересно. Гипотетическая ситуация…
Вы ищете сотрудника на должность "Дизайнер интерфейсов". Будете ли вы на собеседовании спрашивать его о разных течениях/школах живописи? Или какие кисточки стоит использовать для разных типов красок? Или например тестовое задание – нарисовать маслом портрет интервьюера?
У меня немного не технический вопрос.
Как влияет внешность, национальность, голос (акцент?) и тп вещи на отбор? Как сильно учитываются такие критерии?
К примеру, если на собес придет человек с явными признаками "лица кавказской национальности". Понятно, что при прочих равных, предпочтение будет отдаваться больше "своему" и это нормально. Однако хотелось бы услышать какие-то мысли, не обязательно от автора.
Иногда слышу от земляков, что их не взяли чисто по нац признаку.
Я как-то раз проводил эксперимент. Поняв, что вакансий на Angular и Vue гораздо меньше и что от реакта никуда не деться, я начал посылать резюме на проекты на реакте. Часть собеседований сидел с серьезной миной, часть - с улыбкой во весь рот. Во всех случаях я говорил что реакт терпеть не могу и поэтому в работе его избегаю, но на вопросы ответить смогу.
Как показал эксперимент, при наличии базовых знаний технологии, пройти собес "на улыбке" ответив "не знаю" на большинство вопросов очень даже реально.
Поэтому только тестовые задания, только хардкор.
Что не так с техническими собеседованиями в IT?