От переводчика Рик Липперт известен прежде всего как ведущий разработчик языка C# (в прошлом), и многие наверняка читали его блог.
Сказочные приключения в программировании .
Раньше даже официальную публиковали на MSDN. перевод этот блог, который прекратился после того, как Липперт покинул Microsoft. Конечно, нет ничего лучше, чем прочитать оригинал, но я для разнообразия решил перевести кое-что из недавних постов Рика.
Надеюсь, это будет интересно.
Ранее я переиздал две свои старые статьи (оригиналы: один раз , два — ок.
перев.
), касательно процесса технического собеседования.
Думаю, можно было бы подробнее описать, как я провожу собеседования и на что обращаю внимание.
Вот мои основные цели:
не нанимайте плохих сотрудников; нанимайте хороших работников; оставить у кандидата положительное впечатление о компании.Конечно, избежать найма плохого сотрудника гораздо важнее, чем нанять хорошего.
Если мы не получим отличного сотрудника, это очень плохо, но плохой подбор персонала может снизить продуктивность команды на годы.
Последний пункт также является ключевым; Если мы хотим нанять кого-то, нам, очевидно, нужно произвести хорошее впечатление.
Но я также хочу, чтобы все, кому отказали, тоже имели о нас хорошее мнение.
У них есть друзья, которые, возможно, захотят взять интервью.
Когда-нибудь они могут решить купить наш продукт или порекомендовать его.
Собеседование — дорогостоящий бизнес-процесс; если это не приведет к найму, то, возможно, мы получим клиента или, по крайней мере, больше доброй воли.
Интервью проходит следующим образом.
Прежде всего я должен убедиться, что претенденту комфортно, есть чем утолить жажду, не хочется в туалет и так далее.
Затем, если человек до меня уже брал у кого-то интервью, то я спрашиваю: «Как делаЭ» Цель этого вопроса — прояснить ситуацию, начать разговор и посмотреть, есть ли у кандидата вопросы по поводу собеседования.
Иногда у меня есть информация о том, как кандидат уже себя зарекомендовал, но она не предназначена для принятия решений.
(В Microsoft нас поощряли как можно быстрее давать обратную связь следующим интервьюерам в цепочке, чтобы они могли разобраться в потенциальных проблемах; в Coverity мы более склонны к тому, чтобы каждый интервьюер начинал беспристрастно.
Оба подхода имеют свои плюсы.
и минусы.
) После этого я выбираю из резюме кандидата что-нибудь интересное и не слишком старое, сначала прошу дать мне «Elevator Pitch» — несколько предложений, описывающих проект, почему он был интересен, важен — а потом прошу описать более подробно проблема решена в этом проекте.
Это, опять же, поможет кандидату расслабиться, поскольку он рассказывает о чем-то из своего резюме и, вероятно, у него это хорошо получается.
Хочу прежде всего выяснить – может ли собеседник нормально общаться? Вы будете удивлены, узнав, сколько людей не могут рассказать о вещах, указанных в их резюме, в одном или двух предложениях.
Во-вторых, что они на самом деле делали в этом проекте? Это может быть шоком, но люди постоянно приукрашивают свои достижения.
Глядя на детали того, что сделал кандидат, я могу понять, действительно ли он «умен и добивается результатов» или нет. Затем мы переходим к действительно интересной части: технической задаче.
Цель — выяснить, способен ли кандидат написать тот тип кода, который нужно будет писать каждый день.
Я знаю, что написание кода от руки на доске подвергается критике, и я согласен с этой критикой.
Это неестественная среда, не такая, как при написании кода, это стрессовая ситуация и т. д. Я стараюсь придумать вопросы, которые сводят к минимуму эти проблемы, но при этом показывают мне, сможет ли кандидат справиться с реальной работой.
(А если человек не хочет писать код на доске, мы можем сделать это на компьютере.
Однако вопросы, которые я задаю, редко требуют написания более шести строк кода.
Лучшие кандидаты должны уметь написать половину дюжину коротких строк без помощи текстового процессора.
) И этот этап действительно важен.
Я проверяю, соответствуют ли кандидаты необычному набору требований.
Кандидаты в команды, работающие над инструментами языкового анализа, должны хорошо владеть теоретическими основами информатики и в то же время быть способными работать в реальном мире несовершенного кода.
Я взял интервью у группы ученых, которые глубоко разбирались в теории, но не могли писать реальный код, а также у опытных промышленных программистов, которые не могли сказать мне, что такое двоичное дерево.
хороший техническая проблема имеет следующие характеристики: можно поставить и решить с помощью небольшого количества кода за короткое время; не требует внезапного озарения, чего трудно добиться в стрессовой ситуации; Это не загадка с подвохом; при желании его можно усложнить или упростить, чтобы лучше оценить уровень кандидата; аналогичны проблемам, которые соискателю придется решать на рабочем месте; проверяет не только написание кода, но и другие навыки, например, способность читать существующий код или справляться с неясными требованиями; Задача, которую я долгое время использовал в Microsoft и которая работает еще лучше в Coverity, имеет следующую схему: Во-первых, есть два метода, написанные на C++ из общедоступного API, каждый из которых состоит из трёх строк очень простого кода.
API управляет «задачами» на «сервере» и используется «клиентом».
Сценарий намеренно очень расплывчатый, но код понятен.
Я знакомлю кандидата с каждой строкой и проверяю, что он понимает код. Здесь мне нужны только базовые знания простого синтаксиса (подавляющее большинство кандидатов согласно резюме знакомы с C++, так как это обязательное требование для вакансии).
Далее я поручаю кандидату проверить этот код на предмет какие-то проблемы .
И я смотрю, в каком направлении он копает, изучая чужой код. Представленный код имеет проблемы с дизайном, надежностью, безопасностью, тестируемостью и переносимостью.
Я вижу, какие проблемы кандидат находит самостоятельно, и если он что-то упускает, могу ему сказать: «Если клиент намеренно попытается нарушить работу сервера, что вы будете делатьЭ» или «Что произойдет, если я скомпилирую этот код для запуска на 64-битной машинеЭ» и посмотрим, поймет ли он подсказку.
Это настоящий навык, который мне нужно использовать каждый день — в первую очередь, при просмотре собственного кода и кода моих коллег.
А во-вторых, мое дело — написание программ, которые анализируют глючный код и определяют, что он глючный.
Если заявитель не имеет возможности проверить чужой код, вряд ли он вообще где-либо добьется успеха.
Тот, кто не может найти ни одну из десятка ошибок в программе, содержащей шесть инструкций, вряд ли сможет написать анализатор кода, обнаруживающий ошибки.
Здесь я ищу понимание, критическое мышление и базовые знания предметной области.
Часто на этом этапе появляются сигналы опасности.
У меня были соискатели со степенью «кандидата компьютерных наук», которые не знали, например, что в 64-битной архитектуре длина указателя составляет 64 бита.
А зачем им знать? Как говорится, астрономия – это не наука о создании телескопов.
Обширные знания в области теоретической информатики не обязательно влекут за собой знание пропускной способности шины между процессором и памятью.
Но кандидат, не понимающий, как указатели реализуются в распространённых архитектурах, вряд ли сможет успешно работать в команде, разрабатывающей анализаторы, которые ищут ошибки, связанные с длиной указателя.
Также многие заявители выявляют ошибки в коде, но не могут описать их последствия.
Неопределённое поведение по определению является неопределённым.
Но описание того, что может произойти, если злонамеренный клиент назначит указатель на произвольную память и заставит сервер выполнить виртуальный метод с этим указателем, демонстрирует понимание того, как компилятор на самом деле генерирует код. Это первый этап технической задачи.
Следующий этап включает в себя проектирование и, возможно, небольшое количество кода.
«Вы можете изменить реализацию API, но не сигнатуры методов — как бы вы исправили каждую найденную ошибкуЭ» Опять же, это базовый рабочий навык, который нам приходится использовать каждый день: исправить ошибку на «сервере», не имея возможности изменить поведение «клиента».
Возможно, код вызова принадлежит заказчику, или другой команде, или уже продан, или что-то еще.
На этом этапе я обращаю внимание на следующее: Есть ли еще какие-нибудь красные флажки? Боже, количество кандидатов, которые пытались решить проблему переносимости путем сжатия 64-битного указателя в 32-битное целое число, огромно.
Здесь нет никакой сложной загадки, которую я прошу вас разгадать.
Вы не сможете уместить двадцать фунтов муки в десятифунтовый мешок.
Должно быть очевидно, что необходимо найти другой путь решения проблемы.
Какие инструменты может иметь в своем багаже соискатель работы? Все кандидаты в конечном итоге понимают, что им необходимо добавить вспомогательную структуру данных для преобразования 32-битного целого числа в 64-битный указатель.
Знают ли они о существующих реализациях такого сопоставления? Если нет, уверены ли они, что смогут написать что-то подобное? Может ли кандидат определить действительно сложную часть задачи? Сложность здесь не в осознании необходимости сопоставления, а в обеспечении уникальности ключей при добавлении новой пары ключ-значение (как я упоминал в предыдущем эпизоде, оригинальный - ок.
перевод).
Даже когда я неоднократно спрашиваю: «В вашем решении вы никогда не рассказывали мне, как вычислить значение ключа — как генерируется это значениеЭ», некоторые кандидаты просто игнорируют это и продолжают объяснять мне, как работает сопоставление.
Либо они возвращаются к предыдущему пункту и пытаются сжать 64-битное значение в уникальный 32-битный ключ, что невозможно и приводит к маппингу.
Как кандидату выйти из такой неоднозначной ситуации? Проблема намеренно расплывчата и неясна, а самая сложная часть — создание уникальных значений.
Если у вас есть два клиента, каждый из которых создает две «задачи», а затем отключается, то генерировать уникальные 32-битные целочисленные ключи легко.
Если миллионы клиентов генерируют миллионы «заданий», то получить уникальные ключи может быть очень сложно.
Многие кандидаты никогда не спрашивают меня, сколько клиентов и «задач» в этой системе, и поэтому у одних возникают слишком сложные идеи, а другие предлагают принципиально не масштабируемое решение.
Может ли кандидат провести параллели с ранее решенными задачами? Это сложно сделать в стрессовой ситуации, но смотреть все равно интересно.
Некоторые кандидаты очень быстро понимают, что проблема «генерировать уникальное 32-битное число и не использовать его повторно, пока клиент не закончит с ним работу» должна была быть ранее решена тем, кто написал 32-битную версию диспетчера памяти.
В конце концов, что такое менеджер памяти? Устройство, которое выдает вам уникальный указатель по запросу и не выдает вам тот же указатель снова, пока вы его не освободите.
Следовательно, сформулированную мной задачу можно свести к ранее решенной.
Некоторые кандидаты говорят о распределении памяти и подобных вещах, как будто это волшебство.
Многие поняли, что проблема аналогична реализации кучи; но только один сказал: «Я решу проблему, получив кучу из Windows в 4 миллиарда байт, а затем выделив отдельные байты из кучи для генерации уникальных 32-битных чисел».
Windows создает кучу из четырех миллиардов байт, а затем выделяет из нее отдельные байты для генерации уникальных 32-битных чисел.
Это действительно сведет проблему к уже решенной! Если кандидат справится очень хорошо, то усложнить задачу довольно легко.
Предположим, что клиенты используются многими потоками; Какая стратегия синхронизации обеспечит высокую пропускную способность? Допустим, состояния задач необходимо сохранять при перезагрузке компьютера.
Что делать, если сервер находится в кластере и может перенаправлять нагрузку на другие серверы.
Я хочу узнать, насколько глубоки их знания.
Или я могу упростить задачу, ограничив количество клиентов десятью.
Предположим, что «задачи» начинаются и заканчиваются в определенном порядке, так что следующая «задача» начинается после завершения предыдущей.
И так далее.
Мне хотелось бы, чтобы абитуриенты почувствовали, что они преодолели хоть какую-то проблему.
В конце собеседования я стараюсь выиграть немного времени, чтобы кандидат успел задать вопросы о команде, вакансии, компании и т. д. (никто никогда не спрашивал: «Будете ли вы писать код, расширяющий связанный списокЭ» и я бы очень удивился, если бы кто-то это сделал).
Для меня это еще одна возможность «прорекламировать» нашу компанию, а также понять из вопросов соискателей, что для них важно.
Теги: #интервью #эрик липперт #Управление развитием #Управление персоналом #Карьера в ИТ-индустрии
-
Основы Беспроводной Сети
19 Oct, 24 -
Победа Над Openoffice?
19 Oct, 24 -
Первое Впечатление От Mbltdev 2015
19 Oct, 24
