Если бы вам нужно было выбрать случайное имя из 10 имен, как бы вы это сделали?

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

Может быть, вы написали бы короткую программу, чтобы выбрать один элемент из предоставленного списка.

Или, может быть, вы попросите кого-то другого сделать это.

В этом и заключается наша проблема: найти решение можно разными способами.

Итак, в мире найма, как вы оцениваете решение проблем?

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

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

Формирование нашей проблемы

У нас есть публичный репозиторий интервью на GitHub, который мы отправляем каждому кандидату, заинтересованному в позиции разработки продукта. В репозитории GitHub есть несколько файлов по разным темам; от devops к визуализации данных, от Python к HTML и CSS и от SQL к JavaScript.

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

Как компания, которая быстро движется и повторяется, мы решили, что наша оценка должна делать то же самое.

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

Улучшение решения

Мы старались помнить следующее:

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

Помня об этих критериях, мы переработали большую часть нашей оценки JavaScript.

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

Проблема 2 (вкус простоты)

Как бы вы написали функцию, которая принимает либо массив Javascript, либо объект, и вызывает функцию для каждого элемента, использующего значение и ключ или индекс в качестве аргументов?

Давайте разберемся…

  • Вопрос обрисовывает проблему и четко определяет ожидания, но выбор реализации остается за кандидатом.
  • Вы можете добавить десятки дополнительных операторов для этой простой функции в зависимости от того, насколько тщательно вы ее реализуете. Мы не тестируем, чтобы кто-то проверял каждую возможную переменную. Но если да, то что они выбрали и почему?
  • Проблема настолько проста, насколько кажется. Многие фронтенд-разработчики используют итерирующую функцию несколько раз в день. Однако обычно это не написанная от руки функция: она исходит из фреймворка или библиотеки, которая используется в проекте.

Проблема 5 (привкус сложности)

Как бы вы моделировали наследование? Учитывая предка «Shape» в качестве конструктора, создайте 2 дочерних конструктора, «Rectangle» и «Circle», которые наследуются от «Shape», и определите метод «getArea», который правильно вычисляет их площадь. Оставьте метод getType нетронутым.

  • Мы четко обозначили ожидания, но, поскольку существует более 10 способов моделирования наследования, кандидат может выбрать, какой метод или пути ему наиболее подходят.
  • До самой последней версии стандарта ECMA в JavaScript не было классов как части синтаксиса, прототипы были их версией создания наследования. Прототипы глубоко встроены в язык, и почти все основано на прототипе «Объект». Проблема, связанная с прототипами, увеличивает широту проблемы, а также позволяет глубже погрузиться в одну из наиболее сложных частей языка.
  • Получив отзывы, мы переписали язык, чтобы было ясно, что делать с каждым новым конструктором и какие методы/свойства должны быть доступны.

Эволюция решения

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

Мы знаем, что вы можете найти решение разными способами, и мы еще не закончили изучение вариантов в нашей оценке проблем.

Поэтому я воспользуюсь своим собственным советом и попрошу кого-нибудь помочь оценить его и предоставить обратную связь.

До решения проблемы (или 6)? Мы хотели бы получить отзывы о репозитории GitHub и о том, как вы оцениваете инженеров. Напишите нам [email protected].

Об авторе: Питер Фриз (Peter Freeze) — инженер-программист mySidewalk, читатель статей и (что наиболее важно) поселенец Катана.