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

В последнее время я думал о вопросах интервью и размышлял о неудачном опыте интервью, который у меня был в прошлом. Особо следует отметить, когда я спросил интервьюера, почему команда решила использовать EJB 3 вместо Spring в своем продукте. Интервьюер в значительной степени оторвал мое лицо, крича: «Поскольку Spring - это еще не все, и конец всей разработке программного обеспечения на Java, хотите ли вы эту работу или нет?». В ответ на это я сказал ему, что это, вероятно, не работа для меня, и я быстро вышел из собеседования.

В начале интервью мне сообщили, что у компании высокая текучесть кадров, продукт, над которым они работали, изначально создавался в Modula-3, затем портировался на Perl и, наконец, на Java. Мне вручили 10-страничный буклет технических вопросов, касающихся Java, EJB, SQL и JDBC, и мне задавали вопросы о технологических стеках, с которыми я работал. Когда мне предложили задать вопросы, я почувствовал, что было бы разумно спросить их об их технологическом стеке и получить разумные ответы, а не отправлять интервьюера в огонь.

Вопрос: Это хорошая идея, чтобы исследовать архитектурный выбор, взятый в интервью? Если нет, то почему?

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

1) Выясните, каково их мышление и отношение к разработке программного обеспечения. 2) Определите, соответствует ли их подход тому, как я бы подходил к таким проблемам.

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

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

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

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

Я не лежу на собеседовании по обе стороны стола, потому что тогда они думают, что нанимают кого-то другого / собираются работать где-то в другом месте. И я ожидаю того же в ответ от человека на другой стороне интервью.

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

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

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

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

Если бы я попал в ситуацию, описанную в вопросе, вместо того, чтобы уйти, я мог бы сказать что-то вроде: «О, да, я согласен, что весна определенно не является правильным решением для всего. Спасибо, что сообщили мне немного о вашей архитектуре! Я всегда ищу понимание того, как правильно выбрать инструменты ». (хотя ваш вопрос странный - вы спрашиваете, почему они выбрали весну, и они выбрали ее, потому что это еще не конец?)

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

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

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

Один раз он переспал с продавцом Oracle и решил, что вся дальнейшая разработка будет осуществляться с использованием веб-сервисов Java 1.4, Oracle ERP и интерфейса Borland C ++ с использованием, в основном, прекращенных сторонних компонентов графического интерфейса, и мы бы предпочли тратить $ 60 000 в месяц на пробелы, чтобы удержать клиентов от прыжка с корабля, чем пересматривать любые решения и делать постоянные улучшения, которые могут принести новый доход, если нам повезет. Не раскачивай лодку, что с тобой? "

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

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

Вопрос: Это хорошая идея, чтобы исследовать архитектурный выбор, взятый в интервью? Если нет, то почему?

Это абсолютно нормально, я бы расценил это как позитив.

Если ваш интервьюер не может справиться с этим, он многое говорит о них, а не вы.

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

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

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

Задание таких вопросов также позволяет оценить заинтересованность компании в совершенствовании и компетентности. Как сказал кто-то другой, одно дело, если вы получите ответ типа (я не знаю Java, но использую .NET, поэтому буду использовать примеры .NET) Когда мы писали приложение, не было зрелых ORM, поэтому мы использовали хранимые процедуры с слой шлюза данных. Мы хотели бы перейти к Entity Framework в будущем и еще раз полностью получить ответ, как будто мы просто используем хранимые процедуры. Entity Framework выглядит пугающе и может потребовать работы по рефакторингу, и мы не можем ничего рефакторировать, потому что у генерального директора есть список новых функций, над которыми он хочет, чтобы мы работали, и если мы потратим время на изучение Entity Framework, он уволит нас тратить время, Один указывает на понимание и желание улучшиться, другой указывает на посредственную в лучшем случае среду, в которой каждый делает минимум, чтобы пройтись по нему.

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

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

Проще говоря: вы должны спросить « Как вы выбрали технологию X вместо технологии Y? ».

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

Когда вы спрашиваете: « Почему вы выбрали технологию X вместо технологии Y? », Может получиться, что вы не согласны с их решением (что нормально ... но может быть воспринято как враждебное) или что вы хотите похвастаться тем, сколько вы знать о рассматриваемых технологиях (которые будут раздражать всех), несмотря на ваши благие намерения.

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

1. Если босс не может допустить какой-либо ошибки формы или временного сбоя, это босс, на которого вы, вероятно, не хотите работать.
2. Вы можете рассказать, как компания справляется со стрессовой ситуацией.

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

В конечном счете, если вы говорите об удовлетворенности работой, технология (язык / платформа / компилятор / что-то еще) не так важна, как вовлеченные личности и рабочая среда.

Несколько лет назад я был на собеседовании, и мне задавали различные технические вопросы о языке программирования ... который я не очень хорошо выполнил (60/40 правильно / неправильно). Обсуждение перешло к проекту, который они имели в руках, и я начал задавать вопросы о дизайне, а затем указал на пару проблем и ограничений, которые они введут.

Мне предложили работу на следующий день. К сожалению, я не смог принять это по личным причинам.

Задавать вопросы о дизайне не должно быть проблемой, если они умные вопросы, особенно если вы можете связать их с их бизнесом.

Я не проводил много собеседований, но из вашего опыта я бы сделал вывод:

а) Это нормально, если вы хотите принять обоснованное решение о том, хотите ли вы работу;

б) Это не нормально, если вы уже решили, что хотите эту работу.

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

Вот несколько советов

1. Вопрос о том, почему они выбрали какое-то существующее решение, может быть плохим вопросом, потому что, вероятно, команде разработчиков не дали возможности изменить или выбрать его.
2. Также команда, вероятно, уже знает, почему технология была не лучшим выбором
3. Но, к сожалению, последнее, что нужно команде разработчиков, - это люди, пытающиеся изменить архитектуру или подвергнуть сомнению выбор, сделанный 10 лет назад, - создается впечатление, что их технология уже устарела, и такие сообщения в команде могут расстроить разработчиков о текущей ситуации
4. Таким образом, в интервью последнее, что вы должны сделать, это создать впечатление, что вы будете постоянно жаловаться на решения, которые команда не может контролировать