За свою инженерную карьеру я провёл десятки собеседований. Чтобы успешно пройти алгоритмическую секцию, кандидату недостаточно просто написать код. Нужно ещё этот код объяснять и в целом поддерживать беседу — общение здесь неизбежно.
За время общения с кандидатами я заметил некоторые повторяющиеся ошибки, которых можно избежать, если держать в фокусе внимания сравнительно простые вещи. Возможно, мои наблюдения будут вам полезны при интервью на следующее место работы.
Следите за таймингом
И это не про O(N). На типичном собеседовании по алгоритмам от вас ожидают, что в течение часа-полутора вы напишете решение пары задач. Если ещё и объясните их, будет вообще супер.
Но частенько случается, что кандидат раньше с задачей не сталкивался и начинает придумывать решение на ходу. Как это происходит: человек посидит-подумает, набросает пару строк. Так, тут не то… Нужно с другого конца, итератор. В общем, сами понимаете.
К чему это приводит? Как правило, к тому, что через 30-40 минут от начала собеседования кандидат приходит в точку, когда нужно «буквально пару циклов дописать, и всё должно заработать». При таком сценарии на второй задаче можно поставить крест.
Совет: следите за временем. Если решаете одну задачу больше 30 минут и находитесь где-то посередине процесса, что-то здесь не так. Справиться с ситуацией можно, проговорив примерное решение словами хотя бы в общих чертах.
Рассказывайте о своём решении
Иногда случается так, что вроде хочется уже начать код писать, а там пристают с каким-то вопросами, вроде «рассказать решение». А иногда даже во время обсуждения решения начинают какие-то уточняющие вопросы задавать и уводить в сторону. Так же и забыть можно, что хотел закодить.
У интервьюера нет цели никого увести с истинного пути. Так делают в основном для того, чтобы убедиться, что кандидат мыслит в верном направлении. Это помогает сразу скорректировать решение, пока человек не влез в дебри реализации. Порой благодаря наводящим вопросам кандидат сам понимает, что его повело немного не туда, и быстро исправляется.
Совет: не ждите, пока вас попросят проговорить основной алгоритм решения. Рассказывайте его сами. Таким образом вы облегчите жизнь и сэкономите время и себе, и интервьюеру.
Решайте проблемы стратегически
Бывало у вас такое, что думаете-думаете над задачей, пробуете-пробуете — и всё никак? Вроде бы подсказок и так много было, и вроде обсудили возможные подходы, но тупик. Что тут можно сделать?
Как вариант, можно до такого не доводить, а попросить перейти к следующей задаче. Если чувствуете, что совсем не идёт, имеет смысл двигаться дальше, чтобы не завалить собеседование. Я не раз видел своими глазами, как кандидат после неудачной попытки на первом вопросе быстро и успешно разбирался со вторым, после чего возвращался к первому и без проблем решал его. Возможно, помогает переключение контекста.
Совет: можно подходить к проблеме с чисто организационной точки зрения, меняя порядок выполнения работ. Бывает, что это помогает.
Не зацикливайтесь на мелочах
Ситуация: вы на собеседовании, задача понятна, путь к решению примерно понятен, код уже выходит из-под клавиш. И тут кажется, что двумя строчками выше можно было сделать красивее и оптимальнее: «сейчас зарефакторим и дальше пойдём, а то потом ещё забудем про эту правку», «этот кусок можно вообще переместить...».
Знакомо? Скажу так: я видел, как при таком исправлении мелочей и рефакторинге кандидаты вообще забывали, что хотели написать в итоге.
Совет: сначала запрограммируйте сам алгоритм, а потом уже занимайтесь украшениями. Не обращайте внимания на мелочи раньше времени. Скорее всего, на интервью от вас будут ожидать понимания алгоритма и способности его воплотить. А оставшееся время можно и на более интересные вопросы оставить.
Заключение
Следуя этим небольшим и, казалось бы, простым принципам, вы можете существенно улучшить положение дел на собеседовании:
Следите за временем, не тратьте слишком много на одну задачу.
Рассказывайте про решение. Спросите явно, туда ли вы двигаетесь.
Если застряли, меняйте задачи местами, решайте их с конца. Иногда это правда помогает.
Не утопайте в мелочах раньше времени, первым делом — основной алгоритм.
Всем добра, проходите собеседования и получайте классные офферы!
Комментарии (24)
warhamster
18.06.2022 01:28Но частенько случается, что кандидат раньше с задачей не сталкивался и начинает придумывать решение на ходу.
Вот тут я немного выпал в осадок. В этом же и есть весь смысл — посмотреть, как кандидат умеет придумать решение. Что толку разговаривать, если видно, что задача знакомая и кандидат быстренько пишет уже известное решение? Надо другую задачу, значит. Или что тут имеется в виду?
kostyanoy Автор
18.06.2022 11:24Не очень удачная формулировка. Обычно у кандидатов какие-то паттерны решения тех или проблем накапливаются, и рассуждения ведутся через призму это дела. Например, если кандидат знает, что такое BST, и заюзал его в процессе решения, то вряд ли он станет доставать оттуда все числа, сортировать и брать 3й элемент, чтобы узнать 3й по счету элемент.
А бывает, что кандидат просто в ноль не знает, как решить, или хотя бы как подойти к проблеме. Никаких паттернов. Вот тут об этом было скорее.
wrqqq
На что обращать внимание на алгоритмических секциях собеседованийЕсли присутствуют - в таком месте лучше не работать, если это не гугл.
antonblockchain
Вполне понятно желание посмотреть код.
если fuzzbuzz код на языке человек не может написать то зачем его дальше собеседовать?
и о чем?
Вот к заданиям на дом тестовым возможно хуже отношение.
Потому что отнимает время только у того кто его делает.
segment
Можно просто попросить показать код из проектов кандидата
antonblockchain
Код из проектов, может быть.
1) старым — несколько лет назад;
2) чужим — писала команда и самая лучшая часть кода не претендента;
3) взятым откуда-то из стековерфлоу;
4) просто хорошо заученным рабочим примером.
15 минут лайв кодинга в стиле парного программирования расскажет больше чем час беседы.
если не использовать живой кодинг.
тот кто готовится к собеседованиям к вам попадет.
а тот кто все время работал, и не готовился, не пройдет.
Цель взять того кто хорошо кодит, а не хорошо проходит собеседования.
kalombo
Эм, как раз таки по алгоритмическим задачам куча инструментов, чтобы прокачаться, заучить и пройти эту секцию. И потом с облегчением забыть до следующего собеседования. А опыт вы никак не сможете наговорить.
У меня была задача, нужно было в json вытащить все значения с ключом 'url'. Я затупил и забыл, что в json также могуть быть массивы, хотя пример был перед глазами. А еще задача была проверить на валидное количество скобочек, я её решил, потому что помнил(по сути заучил) как она решается с использованием стека.
С удовольствием послушаю как вы меня оцените по этим задачам.
P.S. Алгоритмические собеседования - это бюррократический подход к найму в больших корпорациях типа Яндекса и Гугла. Ничего они не рассказывают, кроме того, что программист умеет проходить собеседования по алгоритмическим заданиям. Для этих корпораций такой подход работает, для всех остальных - это карго-культ, которые повторяют за Яндексом и придумывают свои смыслы таких собеседований.
antonblockchain
по этому в лайв кодинге будет вопрос:
«а как там с массивами в json это тоже объекты?»
segment
Если собеседующий имеет квалификацию, то все перечисленные пункты разбиваются хорошими вопросами и разговором о коде. Сколько бы человек не заучивал примеры, это будет видно.
JekaMas
Я заранее до собеседований предлагаю кандидату выбрать любой свой код для рассказа о том, что за задачу решал, какой код в итоге получился.
Нет открытого или доступного для демонстрации кода - не беда: предоагаю выбрать любой код на языке из вакансии и рассказать о нём в стиле код ревью.
lebedec
Приходит повар в ресторан на собеседование, а ему говорят, приготовь нам соус бешамель по-азиатски. Ну а что, вполне понятное желание посмотреть на кулинарные способности.
Если серьёзно, наличие алгоритмической секции может означать одно из двух. Либо в компании техническая бюрократия, либо интервьюер не умеет проводить собеседования. В любом случае, в таком месте лучше не работать.
Nialpe
Позволю себе продолжить вашу мысль:
... а потом оказывается, что повар будет все свое рабочее время готовить витаминный салат из капусты и моркови)))
Dolios
Приходит повар в ресторан на собеседование, а ему говорят: давайте приготовим что-нибудь. А он в ответ: ещё чего, от повара готовить требуете, в таком месте лучше не работать!
funca
Мне в алгоритмической части хочется узнать как кандидат работает и насколько с ним комфортно. Фактически задания для лайвкодинга это просто способ смоделировать рабочую ситуацию: тривиальная задача, нечеткая, сложная. Написать в итоге что-то работоспособное это цель, а результат для меня - сам процесс. В идеале хочется видеть целеустремленность, грамотность, аккуратность и слышать вопросы в случае затруднений.
lebedec
А разве такие рабочие ситуации бывают? Приходит продукт менеджер и говорит: "отсортируй пузырьком клиентов по дате подписки". У вас такое бывало?
По-моему, разработчику гораздо чаще приходится направлять свои благодетели на анализ предметной области и совместное с бизнесом планирование сроков.
Как правило задачи от бизнеса выглядят так:
Вам разве не хочется узнать насколько комфортно с кандидатом будет решать подобные задачи? Насколько у него развит кругозор, предприимчивость, способность делать технические решения подходящие реальным задачам бизнеса.
Всего этого не узнать, если потратить внимание и заинтересованность кандидата на придумывание алгоритмов в стрессовой ситуации.
Spunreal
Может в бородатых двухтысячных и была мода написать конкретный алгоритм, и чаще всего просили сортировку пузырьком, то сейчас задачи даются совершенно другие. Никакого заранее правильного способа решения нет, нет конкретного алгоритма. Нужно просто взять и решить задачу.
dopusteam
А как нанимать то? Лайв кодить нельзя, алгоритмы - нельзя, system design, видимо, тоже нельзя.
Nialpe
Попробую рассказать про свое видение этой ситуации... Я - разработчик и у меня есть задачи на спринт, работая над задачей могу сделать перерыв, прогуляться, попить кофе, обсудить с коллегой, посмотреть схожне решение в проекте и воспользоваться отчасти (или полностью) им, почитать документацию и статьи, и даже (о, ужас!) погуглить или залезть на stackоverflow - все это возможно потому, что я бездарь, а возможно потому, что сторонник взвешенных решений (т.к. работаю в финтех). Это вкратце мой рабочий процесс. Как это соотносится с тем, что обычно происходило у меня на алгоритмических и лайвкодинг собеседованиях, я не понимаю до сих пор, честно.
Резюмирую. На собеседованиях обычно проверят нечто лишь похожее на обычные рабочий процесс, в той или иной степени. Вряд ли получится воспроизвести в точности, приближенной к реальности. Поэтому, все равно при найме и интуиция нанимающего играет роль, и множество субъективных факторов. Объективность только на слайдах доклада про успешный опыт. Золотое решение выйдет слишком накладным по ресурсам.
lebedec
Вы когда хотите воспользоваться услугой стоматолога, сантехника или таксиста. Как выбираете специалиста? Отправляете им тестовое задание или спрашиваете теорию по специальности? С разработчиками так же.
Лучше обсуждать в формате диалога предстоящие задачи бизнеса в контексте опыта кандидата. Если хотите, идеальное собеседование — это консультация у разработчика по вопросам решения ваших задач.
В процессе такого диалога можно узнать наличие навыков по вашим технологиям и насколько продуктивным может быть сотрудничество. Разве это не главное?
dopusteam
Вы предлагает ничего не проверять? Ну т.е. таксиста я не проверяю, мне ж ехать с ним, а не работать. Натянутая какая то аналогия.
Стоматолога и сантехника - ну такой себе пример. Я не за тестовое задание, кстати. Теорию спросить могу, потому что мне интересно, как мои зубы чинят, но это другое уже. А Вы готовы поверить незнакомому стоматологу на основании одной беседы?
В формате беседы - это хорошо. К сожалению, иногда это слишком далеко от реальности, некоторые кандидаты очень сладко беседуют, но потом очень плохо работают.
lebedec
Аналогия прямая. Таксист вам оказывает услугу, транспортирует ваше тело в другое место, в котором у вас очевидно есть какие-то дела. Разработчик точно так же оказывает услугу по развитию компании, только через программное обеспечение, а не автомобиль.
Предлагаю на собеседовании обсуждать реальные задачи компании, которые предстоит решать.
Обсуждение ведь и есть настоящая работа, первый этап любой задачи. Не надо моделировать ситуации и что-то там проверять искусственно. Если интервьюер не способен в процессе такого обсуждения отличить сладкие беседы от дельных предложений — это вопрос его компетенций.
Другое дело конечно, если надо "работать", то есть сидеть в штате ровно как можно дольше. Тогда, да, надо проверить что человек хороший и надёжный! Без шуток, надо проверить по всем параметрам: образование, военный билет, медкомиссию, наличие профессиональных сертификатов, алгоритмы...
HellWalk
Как хотите так и нанимайте, просто имейте ввиду, что вас с другой стороны также оценивают. И лично я хорошо понимаю (даже если не вижу собеседника), когда вопросы задаются по списку. Или когда человек просто нагуглил "список вопросов на собеседовании по языку x" и задает их.
Совершенно другой уровень собеседования, когда вместо классических вопросов "чем технология x отличается от технологии y" (например чем SQL-базы отличаются от NoSQL) задают вопрос "в каких случаях лучше использовать технологию x, а в каких - y"
Плюс, ни разу не встречал, но считаю важной и показательной темой, когда человек может рассказать про инструменты в языке x, которые использовать не стоит, и почему.
Потому что нагуглить что делает технология х - легко, а вот узнать, чем она плоха, и что лучше было бы без неё, можно только поработав с ней годик-два.
С другой стороны, вопросы должны соответствовать уровню зарплаты. Если запросы на сеньор+, а зарплата милда - такие работодатели идут лесом сразу.
dopusteam
Я выскажу своё мнение. На некоторые вопросы можно ответить неправильно - ну всякое бывает. Обычно важнее направление мысли и рассуждения. Про инструменты - хорошая идея, кстати.
Spunreal
Просто сразу взять синьора помидора. Он же врать не будет по поводу своих навыков и точно подходит.