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

27

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

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

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

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

DormoTheNord
источник
5
Я буду осторожен, выкладывая ответы на проблемы с собеседованием на github, поскольку некоторые компании предпочитают сохранять конфиденциальность своих проблем.
Scroog1
7
Вопросы общедоступны в их блоге (они прислали мне ссылку на сообщение в блоге), поэтому я не думаю, что они обеспокоены этим.
DormoTheNord
3
@DormoTheNord Я бы сказал, что вы не слишком перегружены: хороший процесс разработки - это нечто совершенно отличное от чрезмерного проектирования и (IMO) хороший знак.
К.Стефф
3
Я бы потратил некоторое дополнительное время на документирование любых серых областей в описании проблемы, предположениях, ограничениях, ... Покажите, что вы не просто погружаетесь в кодирование, но размышляете над проблемой и ее контекстом.
HABO
4
@DormoTheNord Вопросы могут быть открытыми, но ваши ответы тоже будут. Он будет доступен другим собеседникам, если они смогут его найти. Это им, вероятно, не понравится.
Изката

Ответы:

29

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

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

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

Scroog1
источник
2
Пойдете ли вы так далеко, чтобы сказать, что если компания отклонит меня за то, что я планирую сделать, это будет признаком того, что компания не уважает методологии разработки программного обеспечения и что я бы предпочел не работать в этой компании?
DormoTheNord
7
Я не обязательно зайду так далеко, потому что в этом есть определенная удача (к сожалению). Вы можете взять одного интервьюера, которому не понравился такой подход; или они могут быть в плохом настроении в тот день и не хотят просматривать дополнительные данные, предоставленные этим подходом. Тем не менее, как правило, нет никакого вреда в разъяснении уровня детализации, которую они хотят. Кроме того, задание одного или двух уточняющих вопросов также может быть хорошим знаком для интервьюера (хотя, очевидно, он не постоянно бомбардирует их неинформированными вопросами).
Scroog1
+1 - до тех пор, пока вы не отвлекаете от решения, я хотел бы видеть модульные тесты и все остальное, что вы делаете без запроса.
Теластин
1
Слишком много, чтобы посмотреть на риск, можно уменьшить, отправив как базовую ссылку на github, так и ссылку непосредственно на исходный код для теста на ленивый / занятый.
Дэн Нили,
15

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

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

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

Стив Хилл
источник
6

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

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

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

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

Джимми Хоффа
источник
Не существует жесткого ограничения по времени, но просто записка о том, что задание не должно занимать приличного программиста более трех часов. Действительно ли они проверят мой журнал git, чтобы убедиться, что я потратил на него всего три часа от коммита № 1 до финального коммита?
DormoTheNord
2
@DormoTheNord, если нет ограничения по времени, то время, не затраченное на запрошенное решение, может рассматриваться как плохая расстановка приоритетов. К сожалению, инженеры все являются независимыми мыслителями и поэтому имеют свое собственное мнение об этих вещах от одного к другому, в таких случаях может быть удача ничьей, является ли человек, проверяющий то, что вы сделали, таким, чтобы увидеть это таким образом, или вроде бы видеть это как большое благо. Я знал великих инженеров обеих сторон. В этих случаях все сводится к тому, что вы цените, отображаете это и кого-то, кто ценит то же, что и вы, по достоинству оценят, именно с кем вы хотите работать.
Джимми Хоффа
Это то, что я ненавижу в собеседованиях ... удача, связанная с удовлетворением личных предпочтений интервьюера. Может быть, это должно быть стандартизировано :)
DormoTheNord
Не волнуйтесь, удача сойдет на нет в вашей карьере. Тебе просто нужно везти, когда ты получаешь удачу, а когда получаешь неудачу :)
Scroog1
1
Я был бы осторожен в описании его как «золотое покрытие», потому что этот термин обычно считается плохим: en.wikipedia.org/wiki/Gold_plating_%28analogy%29
whatsisname
6

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

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

Корбин Март
источник
3

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

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

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

Kaz
источник
1

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

Я бы поступил с осторожностью. Оцените актуальность задачи для работы и убедитесь, что возмещение расходов работодателем в будущем принесет вам 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 можно легко научить.

Reactgular
источник
2
@JimmyHoffa Вы не согласны с моим полным ответом или только с моими комментариями о тестировании? Может быть, я не смог правильно выразить свою точку зрения, а может и нет? Для меня я ценю больше человеческий компонент, чем письменный тест. Кандидат, который проваливает FizzBuzz, ничего для меня не доказывает. Я должен поговорить с этим человеком, чтобы понять почему. но я хочу нанять квалифицированных работников (всегда). Я просто не думаю пойти домой написать этот тест и вернуться. Это эффективный способ сделать это. Я бы лучше задал вопрос FizzBuzz и посмотрел, как они его решают. Ты понимаешь?
Reactgular
1
@JimmyHoffa Я думаю, что это сводится к ожиданиям работодателей о найме. С учетом вышесказанного я все больше склоняюсь к вашей стороне, тем больше читаю о тестировании FizzBuzz. У программиста, который не может пройти ни на одном уровне карьеры, есть проблемы. Я просто не уверен, что этот вид тестирования такой же, как у OP. См. Этот связанный вопрос: stackoverflow.com/questions/117812/…
Reactgular
Проще говоря, я фанат напряженных процессов собеседования и кандидатов, которые пытаются выйти за рамки (не ставя под угрозу основные запросы; в противном случае они расставляют приоритеты во времени). Весь ваш ответ, кажется, говорит против обеих этих вещей.
Джимми Хоффа
1
thecodelesscode.com/case/23?topic=elegance
Джимми Хоффа
@JimmyHoffa Я думаю, что мое отношение исходит от фриланса в креативной сфере, где клиенты часто просят продавца завершить творческую работу или тесты в рамках предварительного тендера. Я не делаю такую ​​работу, потому что, если бы я потратил часы на каждую перспективу, я бы не сделал оплачиваемой работы. Когда я сказал ОП, действовать осторожно, он надеялся, что он не будет терять время. ОП хотела потратить время на выполнение дополнительной работы. Это искушение, но стоит ли оно того? Возможно, но ОП не уточнил это. Это может быть краткосрочная контрактная работа.
Reactgular
0

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

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

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

Hbas
источник