Комментарии 25
если fuzzbuzz код на языке человек не может написать то зачем его дальше собеседовать?
и о чем?
Вот к заданиям на дом тестовым возможно хуже отношение.
Потому что отнимает время только у того кто его делает.
1) старым — несколько лет назад;
2) чужим — писала команда и самая лучшая часть кода не претендента;
3) взятым откуда-то из стековерфлоу;
4) просто хорошо заученным рабочим примером.
15 минут лайв кодинга в стиле парного программирования расскажет больше чем час беседы.
если не использовать живой кодинг.
тот кто готовится к собеседованиям к вам попадет.
а тот кто все время работал, и не готовился, не пройдет.
Цель взять того кто хорошо кодит, а не хорошо проходит собеседования.
Эм, как раз таки по алгоритмическим задачам куча инструментов, чтобы прокачаться, заучить и пройти эту секцию. И потом с облегчением забыть до следующего собеседования. А опыт вы никак не сможете наговорить.
15 минут лайв кодинга в стиле парного программирования расскажет больше чем час беседы.
У меня была задача, нужно было в json вытащить все значения с ключом 'url'. Я затупил и забыл, что в json также могуть быть массивы, хотя пример был перед глазами. А еще задача была проверить на валидное количество скобочек, я её решил, потому что помнил(по сути заучил) как она решается с использованием стека.
С удовольствием послушаю как вы меня оцените по этим задачам.
P.S. Алгоритмические собеседования - это бюррократический подход к найму в больших корпорациях типа Яндекса и Гугла. Ничего они не рассказывают, кроме того, что программист умеет проходить собеседования по алгоритмическим заданиям. Для этих корпораций такой подход работает, для всех остальных - это карго-культ, которые повторяют за Яндексом и придумывают свои смыслы таких собеседований.
Я заранее до собеседований предлагаю кандидату выбрать любой свой код для рассказа о том, что за задачу решал, какой код в итоге получился.
Нет открытого или доступного для демонстрации кода - не беда: предоагаю выбрать любой код на языке из вакансии и рассказать о нём в стиле код ревью.
Приходит повар в ресторан на собеседование, а ему говорят, приготовь нам соус бешамель по-азиатски. Ну а что, вполне понятное желание посмотреть на кулинарные способности.
Если серьёзно, наличие алгоритмической секции может означать одно из двух. Либо в компании техническая бюрократия, либо интервьюер не умеет проводить собеседования. В любом случае, в таком месте лучше не работать.
Позволю себе продолжить вашу мысль:
... а потом оказывается, что повар будет все свое рабочее время готовить витаминный салат из капусты и моркови)))
Приходит повар в ресторан на собеседование, а ему говорят: давайте приготовим что-нибудь. А он в ответ: ещё чего, от повара готовить требуете, в таком месте лучше не работать!
Мне в алгоритмической части хочется узнать как кандидат работает и насколько с ним комфортно. Фактически задания для лайвкодинга это просто способ смоделировать рабочую ситуацию: тривиальная задача, нечеткая, сложная. Написать в итоге что-то работоспособное это цель, а результат для меня - сам процесс. В идеале хочется видеть целеустремленность, грамотность, аккуратность и слышать вопросы в случае затруднений.
А разве такие рабочие ситуации бывают? Приходит продукт менеджер и говорит: "отсортируй пузырьком клиентов по дате подписки". У вас такое бывало?
По-моему, разработчику гораздо чаще приходится направлять свои благодетели на анализ предметной области и совместное с бизнесом планирование сроков.
Как правило задачи от бизнеса выглядят так:
Птица летит на юг, лодка идёт на встречу с заданной скоростью. Сделай такой сервис, чтобы мы могли продолжить платить нашим курьерам прежнюю зарплату за большее количество заказов. Два дня на бэкенд? А чего так долго?
Вам разве не хочется узнать насколько комфортно с кандидатом будет решать подобные задачи? Насколько у него развит кругозор, предприимчивость, способность делать технические решения подходящие реальным задачам бизнеса.
Всего этого не узнать, если потратить внимание и заинтересованность кандидата на придумывание алгоритмов в стрессовой ситуации.
отсортируй пузырьком клиентов по дате подписки
Может в бородатых двухтысячных и была мода написать конкретный алгоритм, и чаще всего просили сортировку пузырьком, то сейчас задачи даются совершенно другие. Никакого заранее правильного способа решения нет, нет конкретного алгоритма. Нужно просто взять и решить задачу.
А как нанимать то? Лайв кодить нельзя, алгоритмы - нельзя, system design, видимо, тоже нельзя.
Попробую рассказать про свое видение этой ситуации... Я - разработчик и у меня есть задачи на спринт, работая над задачей могу сделать перерыв, прогуляться, попить кофе, обсудить с коллегой, посмотреть схожне решение в проекте и воспользоваться отчасти (или полностью) им, почитать документацию и статьи, и даже (о, ужас!) погуглить или залезть на stackоverflow - все это возможно потому, что я бездарь, а возможно потому, что сторонник взвешенных решений (т.к. работаю в финтех). Это вкратце мой рабочий процесс. Как это соотносится с тем, что обычно происходило у меня на алгоритмических и лайвкодинг собеседованиях, я не понимаю до сих пор, честно.
Резюмирую. На собеседованиях обычно проверят нечто лишь похожее на обычные рабочий процесс, в той или иной степени. Вряд ли получится воспроизвести в точности, приближенной к реальности. Поэтому, все равно при найме и интуиция нанимающего играет роль, и множество субъективных факторов. Объективность только на слайдах доклада про успешный опыт. Золотое решение выйдет слишком накладным по ресурсам.
Вы когда хотите воспользоваться услугой стоматолога, сантехника или таксиста. Как выбираете специалиста? Отправляете им тестовое задание или спрашиваете теорию по специальности? С разработчиками так же.
Лучше обсуждать в формате диалога предстоящие задачи бизнеса в контексте опыта кандидата. Если хотите, идеальное собеседование — это консультация у разработчика по вопросам решения ваших задач.
В процессе такого диалога можно узнать наличие навыков по вашим технологиям и насколько продуктивным может быть сотрудничество. Разве это не главное?
Вы предлагает ничего не проверять? Ну т.е. таксиста я не проверяю, мне ж ехать с ним, а не работать. Натянутая какая то аналогия.
Стоматолога и сантехника - ну такой себе пример. Я не за тестовое задание, кстати. Теорию спросить могу, потому что мне интересно, как мои зубы чинят, но это другое уже. А Вы готовы поверить незнакомому стоматологу на основании одной беседы?
В формате беседы - это хорошо. К сожалению, иногда это слишком далеко от реальности, некоторые кандидаты очень сладко беседуют, но потом очень плохо работают.
Аналогия прямая. Таксист вам оказывает услугу, транспортирует ваше тело в другое место, в котором у вас очевидно есть какие-то дела. Разработчик точно так же оказывает услугу по развитию компании, только через программное обеспечение, а не автомобиль.
Предлагаю на собеседовании обсуждать реальные задачи компании, которые предстоит решать.
Обсуждение ведь и есть настоящая работа, первый этап любой задачи. Не надо моделировать ситуации и что-то там проверять искусственно. Если интервьюер не способен в процессе такого обсуждения отличить сладкие беседы от дельных предложений — это вопрос его компетенций.
Другое дело конечно, если надо "работать", то есть сидеть в штате ровно как можно дольше. Тогда, да, надо проверить что человек хороший и надёжный! Без шуток, надо проверить по всем параметрам: образование, военный билет, медкомиссию, наличие профессиональных сертификатов, алгоритмы...
А как нанимать то?
Как хотите так и нанимайте, просто имейте ввиду, что вас с другой стороны также оценивают. И лично я хорошо понимаю (даже если не вижу собеседника), когда вопросы задаются по списку. Или когда человек просто нагуглил "список вопросов на собеседовании по языку x" и задает их.
Совершенно другой уровень собеседования, когда вместо классических вопросов "чем технология x отличается от технологии y" (например чем SQL-базы отличаются от NoSQL) задают вопрос "в каких случаях лучше использовать технологию x, а в каких - y"
Плюс, ни разу не встречал, но считаю важной и показательной темой, когда человек может рассказать про инструменты в языке x, которые использовать не стоит, и почему.
Потому что нагуглить что делает технология х - легко, а вот узнать, чем она плоха, и что лучше было бы без неё, можно только поработав с ней годик-два.
С другой стороны, вопросы должны соответствовать уровню зарплаты. Если запросы на сеньор+, а зарплата милда - такие работодатели идут лесом сразу.
А как нанимать то? Лайв кодить нельзя, алгоритмы - нельзя, system design, видимо, тоже нельзя.
Просто сразу взять синьора помидора. Он же врать не будет по поводу своих навыков и точно подходит.
Но частенько случается, что кандидат раньше с задачей не сталкивался и начинает придумывать решение на ходу.
Вот тут я немного выпал в осадок. В этом же и есть весь смысл — посмотреть, как кандидат умеет придумать решение. Что толку разговаривать, если видно, что задача знакомая и кандидат быстренько пишет уже известное решение? Надо другую задачу, значит. Или что тут имеется в виду?
Не очень удачная формулировка. Обычно у кандидатов какие-то паттерны решения тех или проблем накапливаются, и рассуждения ведутся через призму это дела. Например, если кандидат знает, что такое BST, и заюзал его в процессе решения, то вряд ли он станет доставать оттуда все числа, сортировать и брать 3й элемент, чтобы узнать 3й по счету элемент.
А бывает, что кандидат просто в ноль не знает, как решить, или хотя бы как подойти к проблеме. Никаких паттернов. Вот тут об этом было скорее.
Подготовка к решению алгоритмических задач развивает алгоритмическое мышление, формирует полезные шаблоны и образы в голове. Кандидат с такими навыками вероятно будет быстрее решать и другие задачи.
На что обращать внимание на алгоритмических секциях собеседований