В настоящее время я нахожусь в поиске новой позиции в качестве Front-End Developer. Я очень хорошо знаю JavaScript и могу поэтично рассказать о замыканиях, каррировании, прототипировании, шаблонах проектирования, производительности приложений и общей архитектуре интерфейса. Но все же я все равно заканчиваю тем, что взрываю собеседования при приеме на работу. (К вашему сведению, большинство работ, на которые я беру интервью, связано с созданием SPA с использованием какой-то инфраструктуры MVC)
Обычно тесты кодирования представляют собой небольшие фрагменты кода, с которыми я никогда не сталкивался профессионально. Как написать функцию, чтобы решить какую-то математическую задачу. Помимо унаследованной неловкости от попыток писать код, держа телефон в одной руке и заставляя незнакомца видеть ваш экран и наблюдать за каждым набираемым вами символом, я просто не вижу такого рода вещи в реальном мире.
Это серьезный набор навыков, которого мне не хватает, или интервьюеры задают мне неуместные вопросы. Я полагаю, что мне следует заняться функциональным программированием и алгоритмическими изменениями, но я не нашел много хороших ресурсов в Интернете (или в печати), какие-либо предложения?
источник
Ответы:
Написание кода - это только часть процесса собеседования.
На самом деле решение логической проблемы - это только часть задачи написания кода.
Интервьюеры хотят быть уверены, что:
Вы можете написать код. Многие кандидаты с 10-летним опытом работы на каком-либо языке вообще не могут написать никакого кода, и этот тест предназначен для отклонения этих кандидатов.
Вы думаете о проблеме, прежде чем писать код. Многие прыгали к своим клавишам, писали десятки строк кода, а потом находили, что они неправильно поняли исходную проблему, потому что не думали об этом.
Вы можете адаптироваться при написании кода. Скажем, вы нашли решение, но когда вы начали его реализовывать, оказалось, что ваша первая идея была не самой лучшей; Можете ли вы быстро переключиться на лучший, в конечном итоге рефакторинг кода, который вы написали?
Это также означает, что такие интервью должны быть более интерактивными . Вместо набора одной рукой купите комплект громкой связи или позвоните через Skype и используйте гарнитуру. Печатайте так, как вы печатаете на работе, комментируя и объясняя, что вы делаете: это внезапно станет намного менее неловким.
Вы занимались парным программированием? Если да, ситуация на собеседовании очень похожа, за исключением того, что интервьюер может не высказать вам свое мнение, и вы не попросите его поменять клавиатуру с вами, когда вы закончите.
Вот несколько примеров чисто математической проблемы и того, как она показывает нематематические навыки разработчика.
Пример 1: простое упражнение по кодированию
Здесь интервьюер хочет, чтобы вы думали как можно быстрее, находили решение и быстро его реализовывали. Такое упражнение не связано с тем, что делают настоящие разработчики, и гораздо ближе к тому, что вы можете найти при получении степени CS, но интервьюерам нравятся такие вещи, так что давайте сделаем это. Кроме того, ограничение по времени делает невозможным проведение какого-либо автоматического тестирования, поэтому интервьюер, вероятно, не ожидает этого от вас.
«Описание алгоритма заставляет меня задуматься о рекурсии. Второе правило приводит к следующей рекурсивной функции ».
«Чтобы завершить рекурсию, мы добавим специальные случаи, заменив тело
fibonacci
функции»."Выполнено."
Вывод
Как я уже сказал, такое упражнение совершенно не связано с реальной работой разработчика. Это делает это бессмысленным? Не совсем, потому что, по крайней мере, это показывает, что человек:
Умеет думать о проблеме. Некоторые кандидаты будут полностью потеряны, и в состоянии стресса потребуется больше, чем выделенное время, чтобы подумать о возможном способе решения проблемы.
Знает рекурсию или умеет обходить рекурсию через обычный цикл. Позже интервьюер может спросить, были ли способы использовать / не использовать рекурсию, и каковы преимущества / недостатки рекурсии.
Знает основы языка программирования. Неважно, использовал ли человек
switch
, защитное предложение, условное обозначение или словарь : в зависимости от фона разные кандидаты будут выбирать разные инструменты для достижения одного и того же результата.Сосредоточена на проблеме, не приводя такие вещи, как модульные тесты, масштабируемость или производительность. Затем интервьюер может спросить, почему с точки зрения производительности вышеупомянутая функция ужасна, ожидая, что кандидат объяснит, что нужно сделать, чтобы довести производительность до разумного уровня.
Пример 2: хитрые вопросы
Теперь у нас есть интересное ограничение, которое показывает, что интервьюер на самом деле заботится не о способности кандидата решать проблемы, а о его способности угадывать, какие пути быстрее других.
Эти сложные вопросы обычно требуют сложных ответов. Здесь, учитывая временные ограничения, нет возможности сделать несколько реализаций, сравнить их, профилировать самую быструю и предложить оптимальное решение.
Вместо этого, как насчет:
«Позвольте мне Google« Первые числа Фибоначчи »... Это выглядит многообещающе. С помощью
простого(это будет оксюморон) регулярного выражения мы можем создать список значений через запятую ».«Наконец, сама программа».
Вывод
Сложные вопросы требуют сложных ответов. Не будь героическим и не начинай бенчмаркинг и профилирование, когда у тебя всего три минуты. Подумайте над умными способами решить проблему, используя свой опыт. Мой опыт подсказывает мне, что использование карты может оказаться быстрее, чем вычисление числа. Это может быть неправильно, но эту попытку следует ожидать, учитывая ограничение по времени.
Знание ваших инструментов также помогает и является неотъемлемой частью навыков разработчика: не зная регулярных выражений, я бы либо потратил выделенные три минуты поиск в Google для списка через запятую, либо начал бы писать анализатор, который будет создавать нужный мне массив.
Помните, что хороший разработчик - это не тот, кто начинает кодирование сразу, а тот, кто знает, как избежать кодирования при наличии лучшей возможности. Некоторые интервьюеры без колебаний дадут вам задания, которые выглядят как кодирующие, но для которых совсем не требуется код.
Пример 3: завершить разработку приложения
Давайте начнем.
«Пример последовательности очень полезен, так как он позволит мне провести кучу модульных тестов, чтобы убедиться, что моя реализация не выглядит совершенно неправильно. В общем, я использую Mocha для node.js или QUnit для клиентского JavaScript, но здесь, для простоты, я просто добавлю несколько тестовых функций ».
«Я начинаю с создания
index.htm
иfib.js
файлов. Затем я наполняюindex.htm
действительно минималистичным и не совместимым с W3C кодом (мы можем вернуться к этому позже, если вам также интересны мои навыки HTML) ».«Давайте теперь напишем некоторый код, который вызовет функцию генератора Фибоначчи и покажет результаты».
«Пришло время запустить код в первый раз, и ... он не работает. Ничего не произошло. Зачем?"
«Хорошо, я забыл
fibonacci.init();
в конце. Я добавил его, и все же ничего не происходит, хотя он должен хотя бы отобразить сообщение в консоли. Подождите, верно, это не такonclick
, ноclick
; Я использую JQuery так часто, что начинаю забывать названия событий в простом JavaScript ».«Давайте добавим несколько тестов».
«Сравнение массивов может быть сложным, поэтому я просто скопирую и вставлю
Array.prototype.equals
код из этого ответа ».«Теперь, когда мы запускаем приложение, оно отображает:»
«Тест не прошел, что было ожидаемо, учитывая нашу фактическую реализацию (
return [1, 2, 3];
) последовательности Фибоначчи. Пришло время изменить это.«Из исходного утверждения последовательность Фибоначчи начинается с того
[0, 1]
, чтоcompute
становится:»«Это позволяет пройти первый тест, и теперь мы можем написать наш второй».
«Это терпит неудачу, поэтому мы возвращаемся
compute
и модифицируем его».«Теперь оба теста пройдены, и пришло время перейти к некраевым случаям».
«Все три теста пройдены сейчас, за исключением того, что результат не выглядит правильным для больших длин, таких как 100. Чтобы получить эти результаты правильно, мы должны были использовать библиотеку произвольной точности . Есть также вещи для улучшения. Например, соглашения об именах иногда слишком плохие (что
fib
?). Связанный с HTML код JavaScript должен также идти к другому объекту, а также к тестированию кода. Кроме того, я не проверялcompute(0)
и не проверял входные данные ».Вывод
Проходя по примеру, вы можете увидеть взаимодействие, ожидаемое во время интервью. Не все было гладко (вначале я сделал несколько ошибок, которые привели меня в неловкую ситуацию, когда при запуске приложения ничего не происходит), и оригинальный подход был неудачным, если мы должны поддерживать большую длину последовательности, но я достиг показать что:
compute(0)
что не получится, но для демо это не имеет значения).Это именно то, что интервьюер должен ожидать от вас.
источник