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

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

У меня такое ощущение, что интервьюеры (по понятным причинам) имеют определенные субъективные предпочтения, связанные с парадигмами программирования, выбором архитектуры и так далее. Эти предпочтения могут повлиять на процесс проверки.

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


Проблема в том, что когда я отправляю код на техзадание, я не знаю, кто моя аудитория. Выбор технологии часто не говорит мне о многом, потому что некоторые языки являются мультипарадигмальными (например, C# и Scala), и могут быть два одинаково допустимых способа их использования (например, способ Java и способ Haskell). И вообще, я ужасно не умею оценивать предпочтения другого человека, не спрашивая их.

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

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

Ответы (3)

Ответ на это и да, и нет. Некоторые интервьюеры будут похожи на меня. Когда они дают вам задание, они хотят, чтобы вы задавали вопросы. На самом деле, одна из целей задания — посмотреть, задаете ли вы вопросы. (Я не беру домой «задания», это для личного собеседования у доски.) Если я даю расплывчатое задание, это потому, что я ожидаю, что вы зададите уточняющие вопросы, прежде чем начнете.

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

  • Вы используете определенное руководство по стилю? (Необязательно добавьте «или мне просто использовать X», где X — это какое-то известное руководство по стилю в вашем сообществе.)
  • можно ли использовать [фреймворк] или вам нужен чистый [язык]?
  • можете ли вы дать мне некоторый контекст более широкой картины, в которую это впишется (если вас просят разработать API или какой-либо другой внешний интерфейс и вам нужна дополнительная информация, чтобы сделать выбор)
  • у вас есть пример чего-то еще от вашей команды, чтобы я мог использовать аналогичный подход к именованию и макету?

Если человек отказывается отвечать на эти вопросы, возможно, он говорит вам, что работа там вам не подойдет. Они могут думать про себя: «Этот кандидат не может принимать никаких решений и спрашивает меня о тривиальных вещах». Они могут гордиться собой и своей способностью не обращать внимания на ваш выбор стиля, соглашения об именах, в некоторых случаях даже выбор парадигмы, чтобы обнаружить за этим настоящий талант программиста. Ваш вопрос подразумевает, что у них нет такой способности, и они могут рассчитывать против вас. (Или, конечно, это может показать, насколько вы достаточно умны, чтобы знать два способа сделать это, и достаточно мудры, чтобы спросить, какой способ они предпочитают. Многое зависит от того, как вы сформулируете вопрос.)

Итог: если вам нужна информация для продолжения (например, они не сказали вам, какой язык программирования использовать или какую версию чего-то выбрать), или вы можете задать один короткий простой вопрос, например: «У вас есть руководство по стилю, которое вы хотите, чтобы я Follow", то, вероятно, безопасно задать один вопрос, если это асинхронная вещь по электронной почте или через веб-сайт. В зависимости от ответа, вы можете чувствовать себя в безопасности, спрашивая другого. Если это интервью на доске или сеанс удаленного сопряжения, продолжайте и спрашивайте столько, сколько хотите, это часть процесса.

Старайтесь задавать хорошие вопросы везде, где можете. Сравнивать:

  • Вы хотели, чтобы тесты были и на этом?

с:

  • Мы включаем тесты, верно? Используете ли вы [тестовый фреймворк]?

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

Спасибо за ответ. Я думаю, что мне следует удалить слово «читабельность» из моего вопроса, потому что оно отвлекает от того, что я хотел спросить. Меня больше всего беспокоят сильные предпочтения в более крупных вещах, таких как парадигмы программирования — например: что, если интервьюер решительно выступает за традиционный императивный ООП, в то время как более современное решение FP может помочь (или наоборот)?
Мне трудно представить, что описание работы не будет вашим руководством, наряду с языком и фреймворком, который вам посоветовали использовать. Но в любом случае, один вопрос, который не заставит вас выглядеть слабым, это ключ.
Не могли бы вы сказать, что для меня разумно потребовать это до того, как я на самом деле выполню задание? То есть, если они отказываются разъяснять, и я действительно не могу сказать, что они хотели бы видеть (и что им не нравилось), не прозвучал бы я неразумно, если бы вообще отказался от «игры» (так сказать)?
Я не думаю, что имеет значение, разумно это или нет. Если вы решите не выполнять задание, они, вероятно, не возьмут вас на работу. Они могут не думать о вас плохо, но вы не сможете пропустить это и перейти к интервью из-за их отказа сообщить вам больше информации. Считаю ли я , что вы поступили разумно, остановив процесс найма, который вам не подходит? Конечно. Но это не дает вам работу.
«Они могут гордиться собой и своей способностью не замечать [...] выбор парадигмы [...], чтобы распознать настоящий талант программиста под ним» — я улавливаю здесь намек на неодобрение? Если да, не могли бы вы немного расширить его? Я виновен в предположении, что тот, кто хорошо выражает себя в одной парадигме, будет хорошо выражать себя и в другой...
Нет, я не осуждаю интервьюера. Я думаю, многие могут сказать, хорош ты или нет, даже если ты используешь другой подход. А другие думают, что могут, хотя на самом деле они находятся под влиянием таких вещей, как «фу, тлеющий огонь» и тому подобное. Я предупреждаю, что если вы скажете интервьюеру: «Мне нужно знать, предпочитаете ли вы А или Б, потому что я думаю, что если я случайно если вы сделаете это в А, вы не сможете увидеть, насколько я гениален, только потому, что вы предпочитаете Б», это не комплимент.

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

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

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

У интервью две цели:

  1. Чтобы компания решила, подходите ли вы для этой роли.
  2. Потому что вы решаете, является ли компания хорошим местом для вас, чтобы работать.

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

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

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

Если вы не хотите спрашивать, я надеюсь, что вы, по крайней мере, всегда объясните. Это то, что я делаю на собеседованиях.

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

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