И как эффективно оценить свои навыки

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

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

Прежде чем мы начнем, нам нужно определение старшего или ведущего инженера-программиста.

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

По сути, это тот, кто может добраться из точки А в точку Б, не перемещаясь по алфавиту в обратном направлении. Вы узнаете больше о том, как я определяю старшего или ведущего инженера-программиста, по мере изучения статьи.

📅 Запишитесь на собеседование без явных ожиданий

Несколько раз я получал календарное приглашение на «30-минутный чат», не имея представления о стадии процесса. Это может привести к неудобным ситуациям и потере времени, когда собеседники ожидают дружеского знакомства и, возможно, даже звонка со своего планшета, но вместо этого сталкиваются с несколькими проблемами кодирования, которые они должны быстро решить. При этом можно легко оттолкнуть талант.

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

Я должен сказать, что это чаще всего происходит, когда привлекается сторонний рекрутер.

🙋🏽 Не выделять время на вопросы

Многие собеседования проходят примерно так: 10% знакомств, 85% интервьюер рассказывает о компании и задает вопросы, и, возможно, у кандидата есть 5% свободного времени, чтобы задать несколько вопросов в самом конце. Я называю эти интервью беседами с ботами и считаю их рискованными для компании.

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

Это приводит ко второму пункту: когда вы не позволяете кандидату говорить и задавать вопросы, вы не поймете, что для него важно, и не сможете использовать эту информацию при составлении наиболее конкурентоспособного предложения. Прочтите: самый конкурентоспособный, не обязательно самый высокий.

Не поймите меня неправильно: очень важно выделить время и объяснить, над чем будет работать кандидат и какое сотрудничество ожидается в случае его приема на работу. Как только вы сошлись с этими ожиданиями, позвольте кандидату вести не менее 20–40% беседы и извлекать уроки из нее.

🎨 Начиная с узкого вопроса

Такие вопросы, как «Как вы делаете это на Java», создают для кандидата ненужные границы, ограничивая его способность проявлять знания и творческий потенциал. Даже если вы действительно хотите получить ответ на свой очень конкретный вопрос, это можно сделать более разумным способом.

Начните с широкого вопроса, например «Как бы вы подошли к этой проблеме?». Таким образом, вы сначала создаете пространство, чтобы узнать больше о кандидате, и при этом у вас все еще остается пространство, чтобы сузить проблему по мере развития разговора, вплоть до вашего первоначального предполагаемого вопроса!

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

📚 Ожидается, что кандидат знает каждый бит синтаксиса языка

Старшие инженеры склонны больше думать о том, что делает код на более высоком уровне, не вдаваясь в детали языка и не пытаясь заставить функцию занимать 2 строки вместо 4.

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

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

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

🪜 Спрашивать кандидатов только об их карьере

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

Что может отличать инженера от других, так это его целеустремленность и готовность наставлять, тренировать и продвигать людей вокруг них. Задавая вопросы о том, как кандидат способствовал росту своих коллег, вы можете понять, благодарен ли кандидат / готов ли он приносить пользу другим людям, поднимая их и организацию в целом.

📟 Судейство, основанное на их знании конкретной структуры

Я был свидетелем того, как интервьюеры, которые сами были старшими инженерами («старшими» в контексте данной организации), отклоняли кандидатов из-за отсутствия у них глубоких знаний о Hibernate, Sequelize или какой-либо другой структуре. Во-первых, это дает очень ограниченную ценность, потому что кандидат может быть экспертом в чем-то подобном, и они могут быстро этому научиться. Во-вторых, это может указывать на то, что интервьюер склонен использовать определенные технологии, что может быть красным флажком для кандидата.

Вместо этого проверьте их уровень понимания семантики распределенных систем, предоставив пример системы и задав широкий вопрос, например «Что здесь может пойти не так?». Вы сможете судить, хорошо ли кандидат понимает основы работы компьютеров и общается ли друг с другом. И если у них действительно есть эти основы, они смогут быстро освоить любую структуру и, что особенно важно, разрабатывать действительно гибкое, масштабируемое и простое программное обеспечение, делая правильные компромиссы.

Те же идеи применимы к вопросу: «Как бы вы структурировали файлы в этом проекте?» vs «Как бы вы структурировали данные для определенного варианта использования и разбили код на микросервисы или функции?». Второй вопрос создает место для гораздо более широкого ответа, позволяя интервьюеру лучше понять мышление кандидата, вместо того, чтобы сужать потенциальный ответ до деталей одного инструмента.

🧮 Всегда относитесь к сложности положительно

Цитата Грегора Хопе прекрасно объясняет проблему:

Разработчики известны своей самоуверенностью (сюрприз, сюрприз!) И часто отдают предпочтение комплексным решениям, которые рассматриваются как «проблемы».

Очень редко фрагмент кода оказывается настолько ценным, что в него требуется встроенная жесткая устойчивость, потому что большинство из нас работает с веб-приложениями, а не с системами управления полетом или устройствами жизнеобеспечения. И все же мы склонны слишком усложнять вещи, часто даже не имея ни одного клиента заранее или не зная об их реальных потребностях.

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

И последнее, но не менее важное: спросите об их работе с множеством различных технологий, но не ожидайте, что они будут экспертами в каждой из них. Таким образом, вы сможете почувствовать их честность, порядочность и открытость к обучению.

На самом деле вам нужен кто-то с производственным опытом на всех уровнях технологического стека: серверная часть / интерфейс, базы данных, инфраструктура, тестирование, автоматизация сборки, мониторинг и документация. Честный, открытый, скромный и всегда старающийся изо всех сил. Тот, кому можно доверять.

Если вы хотите прочитать некоторые мысли об оценке лидерских качеств кандидата, ознакомьтесь с Недостающим элементом собеседований с техническим руководством.

Хотите связаться с автором?

Посетите konarskis.com.