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

  • Логические. Это, казалось бы, простые проблемы, которые требуют хитрости или понимания, чтобы решить их правильно. Если вы слышали это раньше или знакомы, вы можете пройти через них, иначе вам придется полагаться на серию подсказок, чтобы получить окончательный ответ. Вероятно, это не лучший способ судить о чьих-то способностях, поскольку они, скорее всего, не связаны с работой, которую они на самом деле будут выполнять.
  • Структуры данных. Немного более законный, чем головоломка, этот вопрос копается в ваших знаниях о структурах данных. Обычно они начинаются с некоторой сложности, а затем заканчиваются реализацией некоторого типа обхода или поиска по дереву. Теория и знание этого важны, но довольно редко приходится реализовывать низкоуровневую структуру данных.
  • Архитектура. Это перемещает более высокий уровень и просит вас подумать о разработке более крупного приложения. Как будут выглядеть различные компоненты? Если это сервис, какие конечные точки будут открыты? Каковы аргументы и результаты для каждого из вызовов? Как бы вы масштабировали это? Что делать, если вам нужно внести изменения? Это полезный способ увидеть, как кто-то думает и знаком ли он с архитектурой больших и сложных систем.
  • Технический. В зависимости от предметной области это касается нюансов языка или технологии. Они варьируются от стиля быстрой стрельбы, когда запрашиваются описания различных кодов состояния HTTP, до более глубокого погружения в протокол TCP / IP и обсуждения сетей высокого уровня или нюансов конкретного языка или версий приложений. Цель здесь состоит в том, чтобы быстро понять, знает ли человек, о чем он говорит, или это только поверхностное знание. Используемый вместе с некоторыми другими подходами, это надежный способ оценить точность резюме.
  • Тест кода. Это типичный тест кода, в котором вам дается задача, компьютер и ограничение по времени. Будем надеяться, что проблема достаточно проста и предлагает множество вариантов реализации, которые позволяют вам увидеть процесс обдумывания и решения. Наиболее успешные из них включают представление проблемы и обеспечение того, чтобы все были на одной волне, а также случайные проверки, чтобы ответить на любые вопросы. Сложность здесь в том, что не все могут программировать в среде с высоким давлением, и вы можете упустить много замечательных людей, которые являются сильными программистами, но плохо справляются с тестами кода.
  • Парное программирование. Разновидностью теста кода, который пытается сделать его немного менее напряженным, является выполнение парного упражнения, в котором вы оба работаете над проблемой и обмениваетесь идеями друг с другом. Цель состоит в том, чтобы кандидат выполнил большую часть кодирования, а вы выступаете в роли наблюдателя, поскольку вы действительно хотите получить представление о способностях человека к кодированию. Это также помогает показать вам, ладите ли вы, поскольку это быстрый взгляд на то, как вы будете работать вместе над одним и тем же проектом.
  • Добавление функции. Это работа с кем-то над производственным кодом для создания простой функции. Парное программирование обычно выполняется для предопределенной задачи, но это берет реальную проблему, над которой вы работаете, и превращает ее в парное упражнение. Я не видел, чтобы это было сделано, так как обычно требуется тонна контекста, чтобы подтолкнуть кого-то к вашей кодовой базе, и каждый человек в конечном итоге получает разный опыт. Теоретически красиво, но на практике не знаю.
  • Исправление юнит-тестов. Я видел это несколько раз, и обычно это был полностью написанный проект с несколькими сломанными модульными тестами. Ваша задача — просмотреть базовый код и исправить его, чтобы модульные тесты прошли успешно. Мне нравится этот, поскольку он проверяет то, что нужно делать всем — просматривать чужой код, понимать, что он пытается сделать, и вносить некоторые улучшения, не нарушая существующую функциональность. Это требует изрядной работы по настройке, особенно если вам нужно поддерживать несколько языков, но это отличный способ проверить навыки, которыми должен обладать любой разработчик.

Цель каждого собеседования — убедиться, что человек, с которым вы беседуете, добьется успеха в своей работе. Лучший способ — дать им что-то, максимально приближенное к самой работе. Если им это удастся, то, скорее всего, они смогут выполнить работу самостоятельно, а если они потерпят неудачу, скорее всего, они не смогут ее сократить. Подразумевается, что вам нужно структурировать свой процесс, чтобы оптимизировать его. Ни один из них не расскажет вам все, что вам нужно знать, поэтому важно смешивать и сочетать, чтобы найти комбинацию, которая даст вам максимальную уверенность в вашем процессе.