в США, к примеру, могут быть интересные последствия такого подаренного оплаченного отпуска. например, медицинская страховка работодателя может перестать действовать в день фактического прекращения трудоустройства. это не всегда так — зависит и от штата, и от работодателя, но такое может произойти. если в эти две недели вдруг заболеть, может выйти дорого.
когда на большую часть вопросов кандидат отвечает «меня не забанили в гугле», то шансов мало. когда он знает, в какую сторону копать, но не помнит каких-то деталей, то ответ про гугл принимается. например, решает задачу поиска пути конем на шахматной доске через BFS, при этом говорит, что она может быть улучшена через A*, но он не помнит, как это сделать — в реальной жизни нагуглил бы за 5 минут.
что значит нет? почитайте, как устроено интервью в топ 5 мировых софтверных компаний. не на листочке, а на доске. но суть та же. в последнее время некоторые по желанию стали давать компьютер, где писать надо в ноутпэде (если повезет, с подсветкой синтаксиса).
в чем оскорбление заключается? в том, что они хотят какие-то вещи проверить перед приемом на работу? есть стандартный процесс собеседования в эти «мировые» компании, который всех там работающих не оскорбляет, а вас почему-то оскорбляет.
«писать на листочке» — это обобщающее определение, означающее, что IDE использовать не дадут. это может быть доска, листочек, простенький текстовый редактор. гугл дает на выбор редактор с подсветкой синтаксиса (без возможности запустить код) или доску. многие дают сейчас такой выбор. некоторые уже даже позволяют запускать IDE (но не из top 10 компаний), хотя все еще есть места, где предпочитают маркер и доску.
вы остаетесь вообще без понимания того, как кандидат подходит к написанию кода — все в кучу или разбито на функции, использует ли синхронизационный примитив или влепит спин-лок, как и в каком порядке подойдет к решению составляющих частей (начнет ли с самых важных кусков, обозначив утилити-функции только названиями или станет ковыряться в малозначащих вещах), как он подойдет к поиску ошибок, которые с большой вероятностью будут в коде. результат далеко не бинарный, результат дает множество данных о способностях кандидата.
простой код, как правило, в комментариях не нуждается. а вот сложный код — как раз наоборот. как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто. иначе может быть очень дорого чинить инцидент в проде, потому что кто-то улучшил какой-то кусок. кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии. но не пользоваться каким-то инструментом с объяснением «мы все равно им пользуемся неправильно» мне кажется странным.
да. практически всегда хочет. часто задача формулируется так, чтобы кандидату надо было задавать вопросы, чтобы прийти к решению. вопросы, ход мыслей, процесс решения и общий подход к проблеме часто важнее правильного результата.
почему на закуску? архитектурные интервью так же важны как и интервью на кодинг. на них надо выделять отдельные секции, где эти навыки и оценивать. человек высокого уровня будет скорее всего заниматься больше не ручным трудом, но он должен быть способен помочь застрявшему мидлу, к примеру, если понадобится. а как он это будет делать, если он ничего этого не может?
пару месяцев назад я интервьюировался на позиции, эквивалентные гугловому Staff Engineer в несколько других компаний. и решать алгоритмические задачи (где на доске, где на компьютере) приходилось везде. так же приходилось решать high scale system design задачи, проходить behavioral секции и много чего еще. но при этом никому почему-то был не нужен человек, который может говорить о высоких материях, и при этом не может решить алгоритмическую задачу (при условии, что он претендует на техническую позицию, а не позицию менеджера людей).
Про FAANG и так все понятно — сотни постов и тысячи комментов в западной блогосфере написаны на тему сломанности их техинтервью, но ситуацию это не меняет. Что забавно, они тоже пишут что даже там в работе эти алгоритмы реально не нужны.
нужны они в FAANG. не каждый день, но достаточно часто. какой-нибудь reservoir sampling, к примеру, мне пригодился для шардинга ки-спэйса для распределенной обработки не так давно. задачи на многопоточность — так вообще каждодневно нужны. изредка что-то из графов пригождается. ну и в целом — даже если в большинстве случаев это будет двиганье протобафов, иногда будет появляться что-то, где желательно уметь рассмотреть возможность оптимизации (иногда на порядки). а без знания того, что какой-то алгоритм или структура существует и каким-то образом может быть применен(а), шанс на то, что эта оптимизация произойдет, достаточно низкий.
про «только» разговора не было. был о том, что надо, чтобы и высокие материи знал, и руками работать мог. если он все это делал настолько давно, что теперь может только о высоких материях, то он для нас сильно неидеален.
а что, по-вашему, у него надо спрашивать? просто поговорить о высоких материях? а если он 10К попросит? а если 20К? Вообще без собеседования брать? Высокая зарплата не должна освобождать от требования уметь и понимать то, что умеет и понимает типичный мидл. Высокая позиция предполагает, что в дополнение ко всему тому у вас еще и отличное понимание архитектуры, организации процессов и еще чего-то там есть.
Вот еще ниже спрашивают про комментарии. Они должны быть не на доске, а в тестовом задании или в примерах своего кода, которые демонстрирует кандидат. Как без комментариев-то в вашем коду будут разбираться коллеги? Или вы об этом не задумывались? Не приспособлены к работе в команде?
Есть красивая теория, о том, что хорошо написанный код в комментариях не нуждается. Теория эта вдребезги разбивается о реальную жизнь, однако многие в нее все же верят.
ДП на интервью — это в последнее время редкость. в гугле уже не рекомендуют давать задачи на ДП, хотя изредка их все же можно встретить. это раньше давали достаточно часто. в других местах тоже не так чтобы часто попадалось. три месяца назад я сходил на интервью в пяток компаний — в среднем по 6 секций в каждой — и из всех этих 30 секций ДП было только на одной, и то — это была запасная задача, потому что решение основной я знал, и интервьюеру пришлось что-то еще срочно выдумывать.
мы недавно взяли такого олимпиадника. причем, не просто олимпиадника, а тренера одной из азиатских олимпийских команд. но взяли на entry-level позицию. и вроде как и с настоящей работой справляется. секции на дизайн и архитектуру проводят в зависимости от уровня, на который кандидата рассматривают. чем выше уровень, тем больше внимания этому уделяется. на начальные позиции легко можно пройти, просто умея решать задачи.
в моей практике тоже не встречалось случаев, когда придирались к запятым. при этом я сам прошел десятки интервью и гораздо больше их провел. мы даем на выбор — писать или на доске, или на компьютере (не в IDE, но в редакторе с подсветкой синтаксиса). и примерно половина кандидатов-таки выбирает доску.
Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда
почти в половине случаев люди, которые очень хорошо рассказывают про решение, не могли его вменяемо написать.
пара дней совместной работы тоже никакой гарантии не дает. вы, похоже, путаете «будет» и «может быть». кандидат вполне может оказаться хорошим разработчиком, способным быть хорошим работником, однако это не значит, что он таковым будет. через пару дней вашего короткого периода и получения офера все может и закончиться. способа определить, будет он хорошим работником или нет, не существует.
ну и по поводу подхода в целом: для какого-нибудь условного джуниора пару дней наблюдения за тем, как он пишет круды (или, как говорят в гуглах, двигает протобафы), может и подойдет. а вот у синиоров на такое обычно времени нет. а если вдруг есть, то ему на эти два дня надо вполне себе широкий спектр интересных задач найти (при этом таких, чтобы их еще и закончить можно было), чтобы можно было какие-то выводы сделать.
самый надежный на сегодняшний день индикатор — это личная рекомендация от людей, мнению которых доверяешь, и у которых есть личный опыт работы с человеком. это тоже не 100% гарантия, но уже сильно ближе. жаль только, что крайне редко такой индикатор доступен.
и это кстати очень хорошо. они и свое время таким образом сэкономят, и время команды интервьюеров. еще лучше было бы, если бы эти мега-парни еще у рекрутера догадались спросить о формате интервью и вообще не приходили бы.
нет ни одного надежного способа достоверно определить, будет ли кандидат хорошим работником или нет. умение решать задачи на алгоритмы на доске показывает хотя бы то, что кандидат способен за разумное время разобрать эти алгоритмы и набить руку на решение таких задач. то есть он обучаем, мотивирован, и в целом соображает. на интервью на синиор инженера ожидать, что на интервью придется писать только круды, немного странно.
пару месяцев назад я интервьюировался на позиции, эквивалентные гугловому Staff Engineer в несколько других компаний. и решать алгоритмические задачи (где на доске, где на компьютере) приходилось везде. так же приходилось решать high scale system design задачи, проходить behavioral секции и много чего еще. но при этом никому почему-то был не нужен человек, который может говорить о высоких материях, и при этом не может решить алгоритмическую задачу (при условии, что он претендует на техническую позицию, а не позицию менеджера людей).
нужны они в FAANG. не каждый день, но достаточно часто. какой-нибудь reservoir sampling, к примеру, мне пригодился для шардинга ки-спэйса для распределенной обработки не так давно. задачи на многопоточность — так вообще каждодневно нужны. изредка что-то из графов пригождается. ну и в целом — даже если в большинстве случаев это будет двиганье протобафов, иногда будет появляться что-то, где желательно уметь рассмотреть возможность оптимизации (иногда на порядки). а без знания того, что какой-то алгоритм или структура существует и каким-то образом может быть применен(а), шанс на то, что эта оптимизация произойдет, достаточно низкий.
Есть красивая теория, о том, что хорошо написанный код в комментариях не нуждается. Теория эта вдребезги разбивается о реальную жизнь, однако многие в нее все же верят.
почти в половине случаев люди, которые очень хорошо рассказывают про решение, не могли его вменяемо написать.
ну и по поводу подхода в целом: для какого-нибудь условного джуниора пару дней наблюдения за тем, как он пишет круды (или, как говорят в гуглах, двигает протобафы), может и подойдет. а вот у синиоров на такое обычно времени нет. а если вдруг есть, то ему на эти два дня надо вполне себе широкий спектр интересных задач найти (при этом таких, чтобы их еще и закончить можно было), чтобы можно было какие-то выводы сделать.
самый надежный на сегодняшний день индикатор — это личная рекомендация от людей, мнению которых доверяешь, и у которых есть личный опыт работы с человеком. это тоже не 100% гарантия, но уже сильно ближе. жаль только, что крайне редко такой индикатор доступен.