Улучшите свою игру кодинг-интервьюер с помощью этих советов

Собеседований по программированию втайне боятся почти все инженеры-программисты, а целая индустрия книг и веб-сайтов, кажется, существует только для того, чтобы смягчить этот страх. Но правда в том, что ИНТЕРВЬЮЕР часто не очень хорош в процессе и не получает достаточно конкретной обратной связи о своем неблагородстве.

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

Подготовьтесь заранее, сэкономьте время на собеседовании

Существует сильная корреляция между тем, насколько подготовлен интервьюер, и тем, сколько времени на собеседовании будет посвящено написанию кода. В лучшем собеседовании, которое у меня когда-либо было, мы потратили 100% времени на проверку моих навыков программирования, потому что интервьюер был так хорошо подготовлен.

Этот интервьюер пришел с ноутбуком, на котором была предварительно загружена проблема, которая была полностью выражена - HTML, CSS и место для JavaScript - в среде редактирования в браузере (например, Codepen, JSFiddle и т. Д.). Мы потратили немного времени на то, чтобы возиться с механикой общих документов, досок и т. Д. Что более важно, мы потратили минимум времени на понимание проблемы на концептуальном уровне, потому что я мог видеть это как ПРЯМОЙ КОД, а не словесное описание проблемы, которая зависело от способности интервьюера выразить свое мнение.

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

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

Позвольте собеседнику использовать весь набор инструментов разработчика.

Лучший интервьюер когда-либо сказал мне, что хотел бы увидеть, как я использую обычный набор инструментов разработки, включая консоль JavaScript, инспектор элементов и WEB SEARCH. Я один из тех людей, которых на собеседовании очень волнует, если я забываю какую-то тривиальную часть API, например, возвращает ли определенная функция строку или массив. Я оценил возможность выполнить 20-секундный поиск в Интернете, который прояснил этот вопрос в моей голове, вместо того, чтобы сводить меня с ума, заставляя гадать. Да ладно, я не гуглил «как мне написать JavaScriptz?»… Скорее, «О, есть это супер непонятное свойство CSS, которое я никогда раньше не видел, но могу здесь конструктивно использовать».

В наши дни я думаю, что гораздо важнее увидеть, как разработчики используют инструменты, чем каким-то образом помешать им получить помощь извне. Любой разработчик JavaScript, который говорит мне, что никогда не заглядывает в Stack Overflow, - лжец или идиот. Так почему же почему-то до сих пор считается квазиморальной добродетелью отключать интервьюеров от их обычного рабочего процесса вместо того, чтобы наблюдать за ним в действии?

Создавайте, не сокращайте

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

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

Контекст реального мира

Я намного лучше справляюсь с вопросами, которые представлены в реальном контексте, который меня волнует. Если бы вы попросили меня выполнить рекурсивный поиск в глубину древовидной структуры данных, я бы запнулся и задохнулся. В принципе, я бы себя вывел из себя. Но если бы вы попросили меня написать полифилл для поиска чего-либо в части DOM, я мог бы придумать приличный фрагмент кода. Это один и тот же вопрос в контексте 45-минутного собеседования, ни один из них не проверяет навыки программирования лучше, чем другой для веб-разработчика.

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

Eng менеджеры: имитационное интервью с вашими разработчиками

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

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

TL;DR

  • Заранее загрузите код в редактор в браузере. Доски закончились.
  • Разрешите кандидатам использовать обычные инструменты разработчика, включая поиск в Интернете.
  • Начните с более мелких вопросов и добивайтесь успеха, не начинайте с гигантских вопросов и сокращайте количество неудач.
  • Используйте вопросы из повседневной работы, а не из общих абстракций.
  • Eng-менеджеры: соблюдайте интервью со своими разработчиками и дайте им обратную связь.

Если вам понравился этот пост, не забудьте порекомендовать его и поделиться им. Другие замечательные статьи можно найти на сайте Code Like A Girl.