Comments 25
Рекрутер - Расскажите о внутреннем устройстве LinkedBlockingQueue.
Кандидат - Но ведь это самое внутреннее устройство никак нельзя увидеть, просто открыв IDE!
Рекрутер - Такие вещи совершенно необходимо знать наизусть! Зачем вы вообще пришли на нашу замечательную вакансию? Ладно, расскажите тогда про внутреннее устройство IDE, которую открывали. Хоть это вы знаете?
И тут набежали эти самые hr-ры и сеньоры и начали минусовать... Верный признак, что написано по делу) Последние год перестал собесится даже для тренировки, потому что все собесы именно такие. Им без разницы, сколько ты микросервисов написал, что для этого применял. Им надо обязательно удостовериться, насколько хорошо я знаю математические основы красно-черного дерева. Жду продолжения, занёс в закладки
Подозреваю минусят, поскольку автор оделся и ушел в самом сочном месте. Статья, по сути хорошее вступление. Когда читатель уже настроен на правильный лад, когда готов внимать, автор просто разворачивается и пропадает во тьме.... мало кому понравится такое.
А у меня на последнем десятке собеседований только в тиньке спрашивали за язык и алгоритмы. Остальные собеседования были на удивление человечными. А ещё лет 5 назад наизусть знал устройство хешмапы и работу гарбадж коллектора :) - хешмапу спрашивал каждый первый, мусорку - каждый второй. Я, правда, из банков только в тинёк из любопытства совплся на небанковский проект, может банковские интервьюеры и повсеместно двинутые. А вот за пределами банков всё куда как иначе.
А, кстати, какая разница сколько микросервисов нашкандыбал? Кому это может быть интересно?
И, вообще не понимаю этого плача - языки и алго проходить же просто - вопросы одинаковые, задачки несложные. Критерии тоже понятные ответил - не ответил, решил - не решил. А с этими задушевными разговорами фиг знает - недостаточно выполнил ритуальных приседаний - отказали :)
Просто эти задачи на Алгосы выглядят совсем уж искусственно, по крайней мере большинство из них, а если ты на роль выше джуна собесишься, то хочешь, чтобы у тебя спрашивали за практику, а именно за работу над каким-либо проектом. Условно, спросить как бы ты реализовал ту или иную фичу
если ты на роль выше джуна собесишься, то хочешь, чтобы у тебя спрашивали за практику
Не знаю как вы, а я хочу чтобы вообще ничего не спрашивали :). А если спрашивали, то что-нибудь простое. Алго-беседа, вот, простая. Я их по три штуки на завтрак ем. Сисдизайн секция - ... ну, она тоже простая, но для интровертов уж больно напряжная, - много общаться приходится. Лучше без неё.
Условно, спросить как бы ты реализовал ту или иную фичу
А это тоже спрашивают. На сыстэм десигн секциях. Когда доходите до уровня, когда имеет смысл спрашивать. Причём проводить её должен высокоуровневый перец.
А когда уровень претендента невысок, зачем тратить время дорогого специалиста на пустые собеседования? Никчёмные отсеятся на алго-, джунов и мидлов прособеседуют не самые дорогие инженеры. Спрашивать их "как бы ты реализовал" - малоосмысленно, это не их работа. Ну, а кто прорвался через первичный отбор, теми займутся дорогостоящие сеньоры и прогонят сисдизайн. Довольно нелепая секция, на самом деле. Ещё менее полезная, чем алго. Всё равно системы никто таким способом не дизайнит :).
Сами собесы - это вообще не о том, чем придётся заниматься - это фильтр, чтобы отсеять тех, кто не осилил простых вещей. Ну, и лотерея, конечно. Так к ним и следует относиться. Быстро, с наименьшими затратами пройти, получит офер и забыть на несколько лет. А вот это всё, - "хочу чтобы меня на собесе подрючили по проектам", - я не понимаю. До мидлов включительно ваши проекты вообще мало кого волнуют, а помидоров и так про них спрашивают. Причём, скорее из чистого любопытства - по доброй воле сеньор работу меняет когда ему старая разонравилась, а, значит, на новом месте он хочет заниматься чем-то не таким, как на прежней и, значит, вопросы о предыдущем опыте имеет смысл задавать разве что для поддержания разговора. :)
В реальной жизни знание core безусловно нужно, но определяющим является, насколько хорошо разработчик знает тот же Spring Security или реактивщину, и вообще фреймворк как таковой. Бизнесу некогда ждать, когда вы напишите свою самую прекрасную в мире реализацию очереди или какой то особенный вид коллекции, ему результат нужен вчера. И именно для этого и придумали архитектурные паттерны, написали кучу всяких видов orm, key-value бд, очередей сообщений и прочих инструментов, правильный выбор которых и владение ими и даёт быстрый бизнес результат. И количество микросервисов, которые претендент "нашкондыбал", говорит об уровне опыта в реализации именно бизнес задач. Но на тех собесах, которые мне попадались, эти знания интересовали меньше всего, а вот вопросы по core разбирали минут по сорок. Они действительно думают, что человек, реализовавший с десяток проектов, не знает, чем отличаются типы int и Integer?)))
Написано интересно, но крайне раздражает привычка дробить и без того небольшие статьи ра части :(
Почему нельзя сразу мысль изложить до конца?
В других компаниях на техсобес приходят лиды команд или сеньорные разработчики. Так как это отвлекает их от прямых обязанностей, они чаще всего относятся к кандидатам не очень‑то благосклонно, а вопросы формируют как будто из желания кандидата завалить на экзамене — максимально далекие от практики и глубокие по сути.
Мне как-то не встречались лиды, которым безразличен состав команды в их подчинении.
Джун и Лид встречаются на собесе:
- Какими вы видите слабые места LinkedBlockingQueue через пять лет?
- За что?!
- Ну что-то ведь спрашивать надо!
В других компаниях на техсобес приходят лиды команд или сеньорные разработчики. Так как это отвлекает их от прямых обязанностей, они чаще всего относятся к кандидатам не очень‑то благосклонно, а вопросы формируют как будто из желания кандидата завалить на экзамене — максимально далекие от практики и глубокие по сути.
Странно, люди нанимают в свою команду и часто под свою ответственность - и такое. Странно, как так-то?
Наверное что-то в организации стоит подправить :)
И может тогда и статью писать не стоит будет дальше :)
1
У него для принятия решения о найме есть ровно два повода — текучка и новые проекты. Он одобряет некое количество человек (по сути, выделяет бюджет) и спускает задачу HR‑директору — нанять! Для директора главное — чтобы человек более‑менее нормально выполнял рабочие задачи на своем месте без превышения бюджета. Остальное его не сильно волнует.
Причины текучки директора не интересуют ? :) (впрочем это довольно "по современному")
Одобряет некоторое количество человек...главное более-менее выполнял рабочие задачи...остальное не волнует...
Видимо я извращенец какой-то ? Раз считаю, что главное это результативность, или это "старовер" ? :)
Недавно тоже, довелось пообщаться с представителями одной немаленькой фирмы, дают опросники, где вижу довольно "неожиданные" задачи. Спрашиваю, "это тест на вменяемость и адекватность или всё же задачи которые требуют решения ?"
- Понимайте как хотите.
- А у кого уточнить ? (т.к. общаюсь с "HR" а не технарём, который понимает написанное).
- просто пишите что думаете.
- но если писать решение, то тут банально нет места (после вопроса идёт около 2-3 см чистого пространства).
- (уже начиная ёрзать) Ну нам такие вопросы передали с профильного отдела !
- а кто верстал такой вопросник ?
- ~не обращайте внимания, это не важно.
Один из пунктов, содержит простенькую задачу по механике, но выполненную "деффачкой дезигнером" из каких то фрагментов картинок, БЕЗ ПОНИМАНИЯ азов механики.
Пытаюсь уточнить некоторые ключевые моменты, вновь получаю "не обращайте внимания". Как не обращать, если от того-или иного ключевого момента на "чертеже" зависит результат, причём прямо с противоположными в итоге результатами.
Перехожу к другому пункту, там ещё "веселее" - законы физики off напрочь (даже на уровне понимания начального школьного уровня).
Следующий этап, общение уже с живыми специалистами - проблем никаких ,всё бодро и адекватно. Интересуюсь "что это было" (по предыдущему этапу), уточняю, что из адекватного объяснения лично для меня, это только "грубый отсев" для тех, кто вообще не в теме.
В ответ некоторое смущение и невнятные "объяснения".
Третий этап, уже профильный "технарь", в общении с которым незаметно пролетело чуть больше часа. Рассказали друг-другу разные "интересные случаи" из личной практики, естественно без малейших проблем поняли взаимный уровень знаний.
Но в итоге, судя по всему всё прошло мимо. Какого-то дальнейшего развития событий не произошло.
Вот и думаю, кто же в итоге был нужен такой структуре ?
Есть мнение, что многие структуры проводят такой балаган только для той или иной "статистики". Мол, вот... проводили поиск, никого не нашли, т.к. никто не смог правильно ответить ни на один вопрос... (специально оформленный так, что правильно ответить нельзя)
Ну или "было много кандидатов, долгий поиск, всё не то, но "чисто случайно" встретили сына директора который идеально подошёл" :)
Это все только говорит о том, что ИТ им не нужно. Если бы было нужно, то hr не скидывали бы технические собеседования на айтишников, а составили бы вместе с ними четкий перечень вопросов по стеку, технологиям, которыми должен владеть кандидат для работы по тем задачам, которыми ему придется заниматься, и собесили именно по нему, следя за тем, чтобы собеседование не уходило в темы, не относящиеся к прямым обязанностям вакансии. А сейчас hr говорят "мы в ИТ не умеем, у нас лапки", и передают всю техническую часть на людей, которые вообще то никакого отношения к найму персонала не имеют, и поэтому начинают сочинять вопросы, какие им в институте задавали на экзаменах.
И такое есть...
Встречал в одной конторе, где делал свой небольшой проект, ситуацию, что кадровик просил посмотреть описание вакансии (для обслуживания того что я ставлю). А там какая-то дикая смесь "эникейщиства".
Спрашиваю - кто вам такое написал ?
- да это я сама, зашла на (хх.ру) и скопировала несколько похожих на свой взгляд описаний.
Ну Ок, человек по сути хоть что-то сделал самостоятельно + не постеснялся посоветоваться.
Сообща "допилили" до варианта который не стыдно публиковать (+ написал им, что примерно должен отвечать кандидат).
Не знаю насколько "срослось", но вроде как уже несколько лет прошло и не дёргали.
В других компаниях на техсобес приходят лиды команд или сеньорные разработчики. Так как это отвлекает их от прямых обязанностей, они чаще всего относятся к кандидатам не очень‑то благосклонно, а вопросы формируют как будто из желания кандидата завалить на экзамене — максимально далекие от практики и глубокие по сути.
являюсь "сеньорным разработчиком", проводящим собеседования для с++ разработчиков. Собеседования для меня - это такие же прямые обязанности как и написание кода, код-ревью и т.п.. Что значит "отвлекает", не понимаю. Я заинтересован работать с профессионалами, в этом вся мотивация. Отношусь ко всем кандидатам одинаково лояльно и всегда объясняю почему меня интересует именно то, что я спрашиваю (написать балансировку КЧ дерева не прошу. Хорошо, если человек это знает. Не знает - тоже хорошо, т.к. это не нужно знать в реальной разработке 99.9% разработчикам). Чтобы не тратить свое и чужое время, обсудил и научил своих hr уточнять у кандидатов используемый ими стек разработки и субъективный уровень владения ЯП-ами и инструментами.
Мне важно насколько быстро человек может читать чужой сложный код, на лету проектировать несложные структуры, быстро писать код, не пропуская и не забывая различные const, std::move и т.п., разбирается где и какой контейнер использовать.
Кому сразу говорю нет - например, джун не может рассказать, что такое итератор - до свидания через полгода. Не знает как устроены внутри простые string, vector, list - тоже до новых встреч. К кандидатам-сеньорам требования другие, конечно, но тоже их проверить можно за полчаса на простых примерах кода.
насколько быстро человек может читать чужой сложный код
Это задача код-ревью, чтобы её делать, нужно быть хоть немного в теме написанного сервиса. И на ревью на рабочем месте можно потратить полчаса-час, на собеседовании - не более 10 минут, причем в состоянии стресса.
быстро писать код
Серьезно? У вас там чемпионаты на скоростное кодирование чтоли проходят?:)))
Читать незнакомый код - это не только код-ревью и это очень важный навык. Если человек не может прокомментировать небольшой, но сложный код, потом он точно также будет тупить и в реальной жизни и долго разбираться с багами. Пять строк кода распознать можно за пару минут, я не даю простыню целую читать.
Никаких замеров скорости тоже никто не делает, но хорошего специалиста сразу видно по тому как он пишет код.
Почему они такие… О вопросах на интервью