Я хреново пишу код. Это просто не одна из моих сильных сторон. Напрашивается вопрос: как можно найти кого-то, кто хорошо разбирается в том (программировании), которым не являетесь вы? Я знаю, что я не один в этом положении. Но это не вопрос поиска людей для работы, о которой вы ничего не знаете. Речь идет об использовании знаний, которые у вас есть, чтобы помочь найти людей, которые хорошо подходят для должности, которую вы понимаете. В частности, речь идет об использовании этих знаний для поиска правильных архетипов.

Me?

Я могу написать функциональный код, когда мне нужно. Но в лучшем случае это, как правило, похоже на клейкую ленту, которая просто выполняет свою работу. Он работает достаточно хорошо, чтобы продержаться достаточно долго, чтобы его заменили люди, лучше подходящие для этой задачи. Мне повезло, что за эти годы я смог найти замечательных людей, которые сделали эти замены (или просто написали лучший код для начала).

Обучение тому, как хорошо брать интервью, само по себе требует большого опыта. Поскольку это требует времени, есть несколько основных фреймворков, которым я сейчас следую. Если я нанимаю кого-то для выполнения работы, то, как правило, в какой-то момент я хотя бы пытался выполнить часть этой работы. Трудно понять фокус позиции, если вы никогда не пытались сделать это самостоятельно. Отличным примером этого (для меня) было написание кода Go (Голанг). Хотя этот пример действительно применим к любому языку, который вам нравится.

Что я знаю в целом

  1. Большинство настоящих программистов используют ссылки (произносится как Google или Stack Overflow) почти все время.
  2. Интервью, к лучшему или к худшему, похоже на скороварку. Таким образом, когда люди больше рассказывают о своем реальном опыте и опираются на то, что они уже сделали, это обычно немного снимает напряжение.

Поскольку я знаю, что не смогу (или не захочу) оценивать сложные задачи программирования, мне не нужно задавать ни одну из них. Так что мне остается? Я считаю, что вы действительно можете многому научиться, разговаривая с человеком об его опыте. Эти вопросы обычно ведут к некоторым действительно интересным кроличьим норам.

Вопросы, чтобы заставить людей говорить

  1. Какой был первый проект, который вы создали на Go? Какова была ваша первоначальная реакция на язык? Как эти чувства развивались по мере того, как вы углублялись в язык?
  2. Расскажите мне об одном или двух последних проектах, которые вы создали на Go.
  3. Какие заметные изменения вы внесли в эти проекты, которые являются прямым результатом того, чему вы научились на собственном горьком опыте из предыдущих проектов? Не обязательно иметь отношение к Go.
  4. Что вам нравится и что не нравится в Go как в языке (с точки зрения структурных и синтаксических решений)? Вы понимаете, почему эти вещи существуют в языке именно так, как они есть?
  5. Какую самую большую ошибку вы допустили в Go и как вы ее исправили? Как ты это поймал?
  6. Какие инструменты вы используете для поддержки своего развития? Ваше окружение? Почему и как они сравниваются/сопоставляются с другими инструментами?

Я обычно (но не всегда, потому что здесь могут появиться красные флажки) меньше интересуюсь всеми рассуждениями как таковыми и больше интересуюсь уровнем критического мышления, которое кто-то делает. Многие люди могут писать код. Но не все критически относятся к своим инструментам, процессам и продуктам.

Реальные тесты

Если есть разумное приближение решения, которое можно дать для проблемы, которую команда решила за последние несколько месяцев, я бы дал кандидату некоторый контекст и попросил их поделиться со мной своими идеями. Я бы дал им столько информации и контекста, сколько было у команды в то время. Если они придумывали решение, которое, казалось бы, сработает на первый взгляд или мы пытались, но оно не помогло, я рассказывал им, что произошло и почему. Цель состоит в том, чтобы увидеть, как они думают. Я хочу дать им решаемую проблему и посмотреть, как их опыт поможет им в ответах. Меня даже обычно не волнует, правильно ли они вычисляют (хотя это всегда плюс). Этот процесс имеет несколько положительных эффектов в моем опыте.

  1. Ни один кандидат не хочет решать ваши проблемы за вас бесплатно. Поскольку вы уже решили проблему, это не проблема. Но они могут дать вам интересное представление о подобном или лучшем решении. Они могут дать вам представление о плюсах и минусах вашего существующего решения.
  2. Это также позволяет им узнать типы проблем, с которыми они могут регулярно сталкиваться при работе в вашей организации. Что может быть лучше, чем показать кандидату его перспективную рабочую нагрузку, чем дать ему задание, которое только что было выполнено?

Основная идея этой части собеседования заключается в том, что вы хотите знать, понимает ли кандидат то, о чем он говорит. Если они этого не делают, чувствуете ли вы, что они способны понять это и критически подумать о том, как этого добиться? Вы также хотите убедиться, что они допустили какие-то ошибки раньше или, по крайней мере, поняли подводные камни, если они сами не совершали ошибок. Мы все роем себе ямы, вопрос в том, умеем ли мы и выкапывать.

Первоначально опубликовано на https://eric.lubow.org 4 сентября 2019 г.