Комментарии 55
А я вот пришел к прямо противоположному подходу к собеседованиям. Я за свою карьеру видел взлет и падение J2EE. Видел взлет Spring'a. Но, уверен, что и спринг не вечен, рано или поздно найдется фреймворк, который сместит его с пьедестала. Помню лет 20 назад всех интересовал только Oracle. Сейчас PostgreSQL. Поэтому про тонкости использования того или иного фреймворка или СУБД я вообще не спрашиваю. Все эти знания недолговечны и гуглятся за 5 минут. Пробелы в знаниях новичка выявляются за 2-3 ревью и так же быстро устраняются.
Главное, что отличает хорошего разработчика от плохого - это развитое абстрактное мышление. Умение думать, проще говоря. И здесь ничего лучше life-coding'а я для себя не нашел. Высылаю кандидату заготовку проекта, прошу открыть его в любимой IDE и пошарить экран. А дальше начинается разговор двух умных людей... Задачки, которые я предлагаю кандидату, не требуют знания экзотических алгоритмов и использования каких либо фреймворков. Я прекрасно понимаю, что для кандидата собеседование это сильный стресс, поэтому задачки не олимпиадного уровня. Но вот как следует подумать, чтобы их решить, придется. Пока этот метод ни разу меня не подвел.
Спасибо за отзыв, Дмитрий!
Я бы не сказал, что это противоположные взгляды - они вполне могут дополнять друг друга.
И посмотреть в реальном времени, как человек рассуждает и набирает код - тоже интересная практика. Благо даже специальные онлайн-сервисы для этого есть и даже Идея для этого не обязательна.
Я предпочитаю, чтобы кандидат работал именно в любимой IDE. Прежде всего для того, чтобы уменьшить уровень стресса - чтобы человек судорожно не искал, как выполнить те или иные привычные для него действия. Это во первых. А во вторых, глядя на то, как именно кандидат работает в привычной для него IDE, я получаю очень много дополнительной информации, которая помогает мне принять правильное решение. Ну и в третьих, диалог сильно упрощается, если есть возможность скомпилировать, выполнить и подебажить код. Так разработчик попадает в привычную для себя среду, и раскрывает свои лучшие способности.
И еще... Я официально разрешаю пользоваться на собеседовании гуглом... Умному кандидату это поможет не засыпаться на незнании какой нибудь досадной мелочи. А не очень умному он все равно ничем не поможет - думать за человека гугл пока не научился.
Как быть когда работа на рабочем оборудовании, а на личном ничего нет, или открывались последний раз пять лет назад? :)
Подход, несомненно, крутой, но есть недостаток, что не у всех на домашнем ПК(если он вообще есть) уcтановлена и настроена IDE. С позиции условного сишника или плюсовика - CLion платный, да и не все пилят опенсорс/студенты.
Конечно, позиция не брать таких людей тоже имеет право на жизнь, и я полность на вашей стороне, что нужно разговаривать, а не устраивать допрос по спецификациям фреймворка и порядку аругментов в функциях.
Если нет возможности использовать профессиональную IDE, то используем онлайн сервисы. По статистике такие проблемы возникают примерно у 1 из 8 кандидатов. Но тут сам кандидат должен четко понимать одну вещь - он сам себя ставит в невыгодное положение. Ему объективно сложнее писать код в онлайн редакторе, соответственно у его конкурентов больше шансов на успех.
Почему "умение думать" не дать кандидату на дом, если вы понимаете что для него это сильный стресс? Лив кодингом вы проверите лишь способность кандидата решать примитивные задачки в условиях сильного стресса не оптимальным путем, оставив у него неприятное ощущение от собеседования, вместо того чтобы дать задачку должного уровня, над которой кандидату будет интересно спокойно подумать, что безусловно добавит еиу симпатии к вашей компании.
Может открыть курсы психологической помощи программистам, которых на собеседовании просят (кто бы мог подумать!?) написать немного кода?
Откуда вообще стресс берётся, Вас там бьют что ли?
К тому же, можно заранее предупредить о лайв кодинге, чтоб кандидат заблаговременно подготовил окружение
На рынке труда острый дефицит разработчиков. Если я начну давать "задания на дом", то я потеряю бОльшую часть кандидатов. Причем в эту бОльшую часть скорее всего войдут самые сильные кандидаты.
Полностью согласен! Когда со всех сторон 100500 приглашений, утруждаться решением тестовых заданий не каждый захочет. Только если уж оооочень интересна вакансия. Ну или из чисто спортивного интереса, если задачка любопытная.
Все надо постараться понять и принять решение за час собеседования. Про то и статья.
Странно, то есть все эти потерянные кандидаты говорят: "Нет, не хочу это делать в спокойной обстановке, хочу лив кодинг, чтобы на меня выжидающе смотрела пара глаз интервьюеров. Меня это ух как заводит!" ? Вы потеряете кандидатов только если будете давать скучные задания на 8 часов работы. Что-то интересное на час полтора - сильные не откажутся.
Абсолютное большинство кандидатов отказываются делать домашние задания (в чем я их очень хорошо понимаю). Если не верите - проведите эксперимент, предложите домашнее задание вашим кандидатам.
Не на злобу дня, мне права интересно что вы пытаетесь узнать и доказать заставляя кандидата писать код и думать как его лучше объяснить.
Почему все вдруг кинулись на некий суррогат в виде онлайн кодинга, почему не ревью, которое наш хлеб наш?
Просто, что бы увидеть ход мыслей кандидата. Тут даже не столь важно решит он ее или нет. И никто никого не заставляет, об этом необходимо предупреждать заранее, а кандидат может отказаться. К примеру, я предпочту лайвкодинг на 30 минут, чем тестовое на пару часов.
Буквально этим летом, проходил собеседование в одну известную российскую контору. Они, не предупредив меня, вывалили мне алгоритмическую задачу, тупо скопированную с литкода. Так я у них прямо в лоб спросил пример того как знания и умения решать такие задачи применяется в их повседневной работе, в моем случае, на фронте. Естественно, они не смогли ответит на этот вопрос. Поэтому я не стал даже пытаться решить их задачу, попрощался и закончил встречу. Никто никому ничего не должен. Но видимо они обиделись и даже обратную связь не дали, хотя там еще была теоретическая часть.
Oбсолютно с вами согласен.
Но почему лайвкодинг а не ревью (когда кандидат рассматривает заранее подготовленный PR). Последнее гораздо часть нашей профессии.
Если я правильно помню Доктора Хауса, слушать музыку и играть музыку - разные неврологические процессы и задействуют разные области мозга :)
Даже такая инженерная задача, как написание кода, все равно предполагает выбор из нескольких относительно равноправных вариантов решения и является более творческой, чем ревью.
Мне кажется что в ревью (после него) есть место на разговор, "а что бы можно было улучшить", "а как бы Вы подошли к задаче".
А вот "Доктор Хаус" отлично применим к лайфкодинг с его несколькими одновременными процессами презентации мысленного процесса и самого мысленного процесса. Возможно, Вам комфортнее работать с людьми с таким набором качеств.
Я хочу сказаць, что лайфкодинг имеет столько же общего с реальной работой как и алгоритмические задачки. Каждое задание в какой то мере покрывает определённый тип навыков, абсолютно игнорируя, или даже подавляя другие.
то скорее всего получите ответ типа: «8-10 часов, но в выходные и отпуске, возможно, чуть меньше»
Не баян, а классика
Время — 18. 00, все сотрудники сидят трудятся. Один из сотрудников выключает компьютер, одевает пиджак, берет портфель и уходит. Все провожают его неодобрительным взглядом.
Следующий день. В 18. 00 тот же сотрудник выключает компьютер, одевает пиджак, берет портфель и уходит. Все продолжают работать и начинают недовольно шептаться.
Следующий день. В 18. 00 тот же сотрудник выключает компьютер, одевает пиджак, берет портфель и тут к нему подлетает коллега. — Вася, как тебе не стыдно, мы сидим работаем, конец квартала, столько работы, нам тоже хочется вовремя домой а ты такой единоличник... — Ребята, да я вообще в ОТПУСКЕ!!!
Сначала подумал, что какая-то опечатка, но если автор искренне считает, что насыщенная прочими интересами жизнь не совместима с программированием, то, видимо, нет.
Видимо мне еще есть куда расти в софт-скилах - наверное не сумел подать идею достаточно прозрачно. Фокус как раз в том, что есть категория вопросов, на которые отвечают не то, что думают, а то, что считают правильным ответом. И тут нужно быть более изобретательным. По моему опыту проективные интервью - это очень полезная техника, которой нужно уметь владеть.
Что касается личного времени, то я очень дорожу своим и уважаю в каждом право ни личную жизнь, на хобби и т.п.
Здесь я подсветил слово «ручка» потому, что это сленг, незнание которого намекает на отсутствие реального опыта
Вообще, нет
По моему опыту, этот термин используется не так уж и часто, несмотря на 10+ лет опыта, встречал скорее в отдельных командах
Достаточно опрометчиво поступаете
Вот да, если злоупотреблять такими словечками, можно вообще скатиться в "Бревно на спутнике макаку чешет".
@dopusteam, удовлетворите любопытство пожалуйста, а как Вы называете эндпоинты? Я имею в виду в повседневности, когда с коллегами что-то обсуждаете.
Роут, эндпоинт. Ручкой обычно называют крутилку в настройках, опцию конфигурации или состояния, какой-то параметр - по аналогии с подстроечной ручкой на радиоаппаратуре. Но это сленговый термин, истинное значение которого, похоже, вам не знакомо. Из чего я делаю вывод, что у Вас отсутствует реальный опыт.
Вот тут есть некоторое отличие в степени категоричности: для меня незнание сленга лишь "намекает", а Вы "делаете вывод". Если появились намеки, сигналы и сомнения, то можно задержаться на вопросе чуть дольше и прояснить.
Мне, наоборот, использование термина "ручка" вместо более популярных аналогов намекает на то, что человек работал за всю карьеру примерно в одной компании (кто-то это рассматривает как "мало опыта") и поэтому даже не подозревает, что его могут не понять.
@KGeist, не суть. Это некий намек, сигнал, который всего лишь нужно проверить. Он может подтвердиться или нет. В любом случае - собеседование это попытка понять опыт соискателя "с колокольни" своего опыта и тут нет безусловного эталона.
Про "ручку" впервые услышал пару лет назад от представителей Яндекса, и до сих пор режет слух. По-моему, это пошло от них, но не распространено повсеместно (в комментариях с докладов Яндекса часто можно увидеть вопросы вроде "про какие ручки он говорит"?). Обычно же эндпойнт, роут, я сам предпочитаю называть API-метод или REST-метод.
Вот пример непонимания: https://habr.com/ru/company/yandex/blog/489048/comments/#comment_21316610
Роут - это про что-то типа Camel скорее. А термин "ручка" значительно более древний, чем пара лет. И по моему опыту он более распространен. Однако повторюсь, это всего лишь намек - ничего фатального из этого не следует.
Не спорю, что термин более древний, чем пара лет -- просто я до этого особо не обращал внимание.
Вот ещё пример:
https://habr.com/ru/company/wrike/blog/475558/#comment_20878414
Опыт опыту рознь :)
В первый раз услышала такое название endpoint. Ну я правда в Российских компаниях давно не работала. Так что очень сомнительный критерий
А как Вы тестируете тех, кто определяет, что «В REST сервис требуется добавить ручку" ?
@ChePeter, я, извиняюсь, вопроса не понял :)
Если о том, как я набираю аналитиков и/или архитекторов, то бывает это нечасто и я присутствую на собесе "вторым номером". А проводит его тот, кому я доверяю - в смысле с кем наши подходы и взгляды совпадают.
Очень толково! Лично мне всегда нравились собесы, где интервьювер не занимается раздражающим допросом - и сам стараюсь практиковать именно такой стиль. Еще понравилась идея прерывателей и ранжирования техчасти по приоритетам, без «галопом по европам». В общем, нашел для себя над чем задуматься - спасибо вам за это!
Спасибо за позитивный отзыв, @dimskiy!
Если это поможет сберечь хотя бы часок-другой на интервью - уже все не зря :)
Здесь я подсветил слово «ручка» потому, что это сленг, незнание которого намекает на отсутствие реального опыта
тошнит от этих ручек и прочих вульгарностей. есть нормальный термин для этого.
Какой? Я знаю кучу англицизмов, с которыми автокорректор телефона категорически не согласен, и ни одного нормального слова для обозначения API endpoint.
От того, что вы замените англицизм взятым довольно таки "от балды" неанглицизмом — кому должно стать лучше, и почему?
Всё-таки англицизм хорош тем, что при чтении литературы на английском проще, когда на обоих языках примерно один термин, проще ориентироваться.
Мне станет лучше от того, что автокорректор телефона перестанет мне мешать. Мелочь, а приятно.
Ну почему же "от балды"? Это слово обычно употребляется в словосочетании "дернуть ручку", а оно порождает довольно понятный ассоциативный ряд.
Endpoint - хороший вариант, но немного длинный и менее удобный для произношения. Впрочем это вкусовщина.
А вот роут мне для этого случая не нравится после apache camel - совершенно другие ассоциации.
Вариант хэндлера принять проще, но он уж больно общий: этим словом и message driven и event driven подходы можно окрестить. И даже exception handler - тоже хэндлер. Не передает оно специфики.
В этом плане замечание @YourChief понятно (про крутилку настроек). Ассоциация понятна. Но тут просто другой опыт.
Ну потому что от балды. Думаю, вы сами понимаете, сколько других слов в словосочетании "дернуть X" вам даст приемлемо применимый к ситуации ассоциативный ряд.
Если мы говорим именно про код, обрабатывающий некий запрос к вебсерверу по некоторому адресу — то это таки эндпоинт. Это однозначно понимают и бэки, и фронты, и русскоязычные разработчики, и англоязычные. Сами по себе handlers (из чего пошла вами любимая русификация) — они в общем-то далеко не везде так называются.
Спасибо, @JustDont, за оживленную дискуссию по этому поводу.
Уж не знаю видна ли вам вся ироничность этого холивара, но в том же абзаце, который вызвал такой насыщенный отклик, есть фраза:
Но не только маркер, это проверка насколько мы с кандидатом говорим на одном языке.
Если Вам не нравится терминология на проекте, значит не стоит туда идти. И это отлично, что все прояснилось на собесе - меньше разочарований. А значит слово достигло своей цели: помогло принять решение (в данном случае кандидату)
Какой неожиданно бурный отклик вызвало ничем непримечательное слово "ручка" :)
Спасибо за обратную связь, коллеги, пусть и на неожиданном месте!
А мне вот вообще кажется идея узнать за 60 минут порочна.
За это время в лучшем случае я за это время составить свое/субъективное мнение и не факт что оно будет верным, другой человек спросить кандидата другие вопросы и его мнение будет отличаться от моего... Кто тогда прав будет?
Т.е. первый вопрос, а как вы проверяете что ваши методики проверки знаний работают корректно?
Второй вопрос - стек: а что, вы действительно считаете что есть только Spring boot? И знание его ньюансов так важно? Ну вот в качестве примеров транзакции например почему не спросить, чем именно отличается уровень транзакции serializable от repeatable read, и как это реализовано в бд?
Так же про более базовые вещи, я например не вижу смысла спрашивать за rest api endpoint , если человек не знает разницу между UDP/TCP/HTTP
Т.е. у меня есть такое и убеждение (которое может быть не верно) что базовые знания важны, а фреймворки могут меняться со временем, базовые же реже меняются
За 60 минут конечно ничего толком не понять, но большего мне не даст рынок труда! Будет понятно только если кандидат полный ноль. В остальных же случаях - это конечно только домыслы и предположения, основанные на своем опыте. Но разве это значит, что нужно сложить руки и положиться на удачу? На мой взгляд - нет. Есть способы, повышающие достоверность "кофейной гущи" и своим набором ингредиентов я тут поделился.
У кого-то принципиально иной опыт и набор ингредиентов будет другим. Все специфично.
Мне бы очень о многом хотелось поговорить с кандидатом, но у меня всего лишь час. А все последние проекты у меня сугубо прикладные. Поэтому я фокусируюсь на вопросах, которые позволят мне понять сможет ли он мне "с порога" начать запиливать мои реальные прикладные таски. Я и по java core конечно тоже спрашиваю, просто цепочку вопросов начинаю раскручивать не с этого.
Кстати, в статье были разные примеры. Создание иммутабельных объектов, например. А от спринговых бинов реквестового скоупа на ThreadLocal можно перейти. С синглтонов - на double check locking и на reordering в JMM. Главное вести беседу органично и вокруг того, что мне интересно от кандидата в работе.
За последние 10 лет это время сократилось с 2-3 лет до 1 года даже для разработчиков высокой квалификации. Новички же и вовсе находятся в перманентном поиске новых карьерных и зарплатных возможностей.
Это, конечно, беда. Какая тут квалификация, если получаются уже не разработчики, а просто исполнители, причем четко поставленных задач. Проекта не знают (и не успеют узнать), свое предложить не могут - пришли, задание получили, выполнили, см. пункт 1. Точно ли имеют смысл какие-то софт-скиллы, если через год этого человека тут уже не будет? Не лучше ли делать упор на технические знания, чтобы новичок сразу садился и пилил? Мы тут сами с наймом мучаемся, уже не знаем толком, кого искать.
Спасибо за вопрос, @Caraul! Вы мне им прекрасную идею для размышлений подкинули - почему люди с развитыми софт-скилами задерживаются все-таки подольше (ну или мне так показалось).
Из того, что требуется непосредственно в работе: допытаться от аналитиков, от бизнеса, от архитектуры чего же именно те хотят? Пинговать, пушить, задавать правильные вопросы, фиксировать уточнения постановки в трекере и т.д.
Далее, уметь отстоять свои интересы. Если что-то не удобно, то прийти на ретро и объяснить команде свою позицию и быть убедительным, чтобы тебя поняли и исправили процессы внутрикомандные (например, подход к ревью или написанию тестов). Если мало денег - прийти и убедить их повысить, а не сразу обновлять резюме.
Еще - уметь говорить нет. Например, когда тебе пишут в нерабочее время и просят срочно-срочно.
Словом, столько всяких кейсов на ум приходит, что тут на еще одну статью наберется... to be continued :)
Зачем этот творческий поиск и эксперименты над людьми?
Все уже давно изучено и придумано профессионалами именно в сфере найма. Как искать, кого нанимать, как удержать или как уволить? Есть масса книг по данной тематике. Там все это разобрано. И про софт-скилы и хард-скилы и вообще про все. Даже небольшой труд снимет массу вопросов.
Сэкономите себе и другим огромную кучу времени.
Узнать за 60 минут