Должен ли я волноваться по поводу заданий по программированию сверхинжиниринга, данных во время интервью? [закрыто]

Недавно у меня было телефонное интервью с компанией. После этого телефонного интервью мне сказали выполнить короткое задание по программированию (небольшая программа; она не должна занимать более трех часов). Я только прямо проинструктирован, чтобы выполнить назначение и сдать код. Мне предоставили полную свободу использовать любой язык, который я пожелал, и мне не сказали, как именно включить код.

Сразу же я планировал добавить его на Github, написать для него набор тестов, использовать Travis-CI (бесплатная непрерывная интеграция для общедоступных репозиториев Github) для запуска наборов тестов и использовать CMake для создания make-файлов Linux для Travis-CI. Таким образом, я могу не только продемонстрировать, что я понимаю, как использовать Git, CMake, Travis-CI и как писать тесты, но я также могу просто ссылаться на страницу Travis-CI, чтобы они могли видеть результаты тестов. Я подумал, что это сделало бы это немного более удобным для интервьюера.

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

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

Как интервьюер, я был бы рад видеть знание процесса разработки программного обеспечения, продемонстрированное этим подходом; в отличие от просто написания кода.

В частности, наличие набора тестов даже для очень простых задач было бы хорошим знаком (даже уровня FizzBuzz). Я видел, как кандидаты представили решения, которые даже не решили проблему, и простой набор тестов показал бы им это. Кроме того, наличие истории коммитов позволяет мне получить представление о мыслительном процессе, который кандидат использовал, чтобы найти решение.

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

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

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

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

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

Избыточное проектирование - плохое слово, когда вы создаете AbstractFactoryManagerAdaptors, которые подключаются для раздачи BuzzManager и FizzManager просто для решения FizzBuzz.

То, что вы делаете, это чрезмерное усердие, которое даже не вещь (хотя определенное усердие определенно есть).

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

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

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

В действительности никого не волнует, может ли кандидат быстро запустить git-репо или создать make-файлы, потому что это всего лишь воспоминание о том, что он или она выучил наизусть. Это второстепенные навыки по отношению к актуальному решению проблем и аспекту дизайна вопроса об интервью.

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

Тем не менее, аспект решения теста хорош. Доставка ответа с помощью набора регрессионных тестов, вероятно, принесет вам очки. Тем более, если ваш набор тестов использует в коде существенные случаи. Набор тестов не должен иметь много формальных атрибутов и полагаться на инструменты; просто тот факт, что у вас там кто-то есть, достаточно для собеседования. Более или менее очевидно, что если вы можете собрать несколько специальных модульных тестов в интервью, вы можете сделать это с помощью инструментов в реальном проекте.

Недавно у меня было телефонное интервью с компанией. После этого телефонного интервью мне сказали выполнить короткое задание по программированию (небольшая программа; она не должна занимать более трех часов).

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

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

Тестирование имеет свое место. Задайте себе следующие вопросы о тесте и ответьте соответственно.

1. Справедлив ли тест с учетом вашего текущего уровня карьеры?
2. Есть ли у теста четко определенный правильный ответ?
3. Заинтересован ли интервьюер в вашем потенциале как личности, или они проявляют больший интерес к результатам тестов (т.е. наемные агентства ужасны для этого).
4. Представляет ли тест вид работы, который вам нравится выполнять, или это неоднозначная проверка навыков (т. Е. Тестирование, если вы знаете синтаксис Java).

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

Вы только что ответили на свой вопрос.

Сразу же я планировал добавить его на Github, написать для него набор тестов, использовать Travis-CI (бесплатная непрерывная интеграция для общедоступных репозиториев Github) для запуска наборов тестов и использовать CMake для создания make-файлов Linux для Travis-CI.

Нет, это не то, что они просили тебя сделать.

Таким образом, я могу не только продемонстрировать, что я понимаю, как использовать Git, CMake, Travis-CI и как писать тесты, но я также могу просто ссылаться на страницу Travis-CI, чтобы они могли видеть результаты тестов. Я подумал, что это сделало бы это немного более удобным для интервьюера.

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

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

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

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

Они возьмут ваш исходный код и передадут по офису. Люди будут комментировать это, и вы не хотите, чтобы они говорили: «Он совершил эту ошибку? Но проводил время, используя Git, CMake и Travis-CI. Какой идиот за то, что упустил эту ошибку».

Вот и все. Вы потеряли.

Они хотят знать, что вы можете кодировать, потому что они не могут научить вас этому. Git, CMake и Travis-CI можно легко научить.

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

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

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