Почему алгоритмические вопросы не дают вам лучших сотрудников.

TL; DR: потому что это может быть не причиной того, почему вы больше не хотите работать с этим человеком.

Я был интервьюером и интервьюером достаточно раз, чтобы сформировать некоторые модели, которыми я чувствую необходимость поделиться с вами, ребята. Давайте сразу же приступим.

  1. Вы задаете вопрос о LinkedList / Array, кандидат решает его безупречно. Что он отвечает? Он отвечает на то, что человек тратит время и готовится к этому вопросу. Чего он не отвечает, так это того, как часто кандидат использовал его на практике и какие преимущества и недостатки он действительно привносит в вашу кодовую базу. Есть ли в вашем коде проблемы с производительностью связанных списков / массивов? Во многих случаях в моем коде или коде компании, к которой я присоединился, этих проблем не было, но у них были другие, и никто не заботился о них.
  2. Как работает HashMap? Buckets, алгоритм хеширования, все в порядке, мы все это знаем, верно? Но что, если ваш коллега не будет использовать это в коде, или наоборот - везде использовать HashMaps? Существует гораздо больше структур данных, которые более элегантно вписываются в код, и некоторые фреймворки имеют свои собственные модификации, поэтому, возможно, задайте более конкретные вопросы, которые вы зададите в PR?
  3. Напишите абстрактный алгоритм решения проблемы. Я бы хотел, чтобы больше людей задавали истинные причины этого вопроса. Часто мне хотелось бы, чтобы вопрос формировался следующим образом: «Как бы вы разработали решение этой проблемы и представили его своей команде, включая PM и QA?». Это звучит так же / так же, как и исходный вопрос, но в этом случае вам не нужно писать фактический алгоритм, вам просто нужно представить его, чтобы другие люди могли понять его без знаний кодирования, что, как я считаю, более важно на повседневной основе. Когда у вас есть готовое решение в коде и вы отправляете PR, вероятно, уже слишком поздно, и вы не будете счастливы увидеть 20 комментариев на своей странице разговора. Но вы можете быстро нарисовать схему схемы проектирования, показывающую, как, по вашему мнению, это должно работать, это будет более полезно, потому что это более наглядно и легко обсудить с коллегами.

Я полностью понимаю, что не участвовал во всех возможных собеседованиях, и многие компании хорошо справляются с заданием правильных вопросов, и я искренне рад за них.

Вот несколько примеров того, что вы могли бы попросить вместо этого, чтобы убедиться, что вы нанимаете правильного кандидата, который хорошо вписывается в вашу команду.

  1. Каждый ли вы писали устаревший код и почему? Я много раз ловил себя на написании устаревшего кода, иногда просто нет других вариантов. Ваша кодовая база может вообще не подходить для тестов, и единственное решение - начать рефакторинг в какой-то момент, иначе будет очень сложно поддерживать этот код.
  2. Вы когда-нибудь отправляли коммит без комментариев об изменении 5 файлов? Или просто упомяните что-то вроде «исправления ошибки» и, возможно, прикрепите ссылку на сбой, которая может работать через некоторое время. Пожалуйста, не поленитесь и напишите причину, по которой вы меняете код, не обязательно описывать сами изменения. Это действительно помогает другим, и они скажут вам спасибо.
  3. Вы когда-нибудь писали файл класса, содержащий более 500 строк кода, и почему это было срочно? Серьезно ?! Я тоже так делал, но теперь не делаю. Причина заключалась в том, что быстро развивающаяся компания хотела завоевать рынок. Прямо сейчас существует множество документации о различных шаблонах и о том, как их быстро реализовать, и, что более важно, о том, как правильно их тестировать.
  4. Вы когда-нибудь говорили своему руководителю, что нам нужно прекратить разработку новых функций и начать рефакторинг кода? на той же странице, что и вы, то здесь нет вопросов, отличная команда! Но иногда менеджеры меняются или теряют объем работы, необходимой для завершения MVP, и в код просто добавляются новые TODO.
  5. Сколько TODO содержится в вашем коде и когда вы планировали их разрешить? См. предыдущий вопрос? Это неизбежно! Что вы можете с этим поделать? Добавьте билеты, добавьте промежуточный PR и решите или создайте билеты для каждого TODO, который вы создали. Более того, вы можете перейти к другому целому проекту и создать на его основе несколько десятков заявок. Кто знает, может быть, вы поймете, почему ваши показатели в годовом сопоставлении продолжают снижаться, а не расти.
  6. Как часто вы применяете шаблон проектирования Factory? Я много раз видел if (NEW_FEATURE). Есть ли лучший подход? Да, используйте factory, который в первую очередь даст вам правильный объект, поэтому вся ваша логика будет свернута под этой реализацией.
  7. Почему, по вашему мнению, плохо иметь 7 вложенных циклов for с операторами «if»? Стиль кода важен, вопросов быть не должно. Вопрос в том, как собрать всех на одной странице? Надеюсь, в настоящее время есть несколько инструментов, которые могут проверять стиль кода на уровне фиксации, поэтому, пожалуйста, используйте их, если это возможно. Читать PR, который не предназначен для чтения, сложно, поэтому приложите усилия, и в конце концов кто-нибудь скажет вам спасибо.
  8. Если вы хотите применить новую структуру, какую конкретную проблему вы хотели бы решить с ее помощью. Реализовано ли ваше предыдущее решение на 100%? Немного, но я видел некоторые места, где технология была использована для самой технологии, это весело, блестяще, но мы как бы не можем ее использовать, и это не так. не вписывается в нашу кодовую базу из-за некоторых ограничений. Или мы не сможем реализовать это в полном объеме. А в следующем квартале была завезена новая техника. Будьте мудры, выбор, который вы делаете, важен.
  9. Когда вы над чем-то работаете, ваши коллеги или руководитель всегда знают, как вы продвигаетесь? Им нужно знать? Каждый раз, когда я скучаю по стендапу или опаздываю, я чувствую себя виноватым, потому что другие люди полагаются на меня и хотят знать истинное состояние прогресса, а не мою интуицию. Нечестность с самим собой - одна из причин, по которой мы не смогли выполнить поставку в срок. В большинстве случаев это сложно измерить, но иногда это просто мотивация. Есть также способы его улучшить.
  10. За какую часть кода вы отвечали? Вы этим гордились? Что бы вы изменили тогда? За какую часть кода вы хотите отвечать? У нас есть программы командного обмена или буткемпов внутри компании, что бы вы хотели попробовать? В конце концов, вы пытаетесь нанять человека для решения какой-то конкретной проблемы внутри компании (если вы не являетесь частью Большой четверки, где по какой-то причине применяется совершенно другой подход).
  11. Если я присоединюсь к команде, какую работу вы будете ожидать от меня? Это очень прямой вопрос, и не многие компании дадут вам ответ, но должны. Важность этого вопроса может быть слишком очевидной, но не многие до сих пор его задают.

Не стесняйтесь делиться любыми своими мыслями / отзывами. Я хочу быть умнее и тоже применять твои знания. Спасибо!