Чрезмерная инженерия - предупредительный знак? [закрыто]

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

Теперь мой вопрос, это предупреждающий знак?

РЕДАКТИРОВАТЬ: довольно много дискуссия основана на недостатке теста - что справедливо. Как я описал в комментарии, основная предпосылка теста состоит в том, чтобы показать, как вы можете читать данные из файла разумным способом (и вы будете поражены разнообразием подходов, которые мы видим), и как соответствовать элементы до расчета задержки между обновлениями. Теперь, чтобы это сработало, необходимо сделать определенные предположения относительно данных, и мы ищем эти предположения, и мы также прямо заявляем, что хотим увидеть подход, который вы выбираете (включая подход ОО и т. Д.). Все это в течение двух часов. временные рамки.

ИМХО, когда я брал интервью, это было самое полное упражнение, которое я встречал.

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

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

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

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

Кажется, у кандидатов есть две отдельные проблемы:

1. Отсутствие смысла упражнения - это довольно тревожно. Все навыки программирования в мире не принесут хорошего результата, если кто-то не сможет поставить задачу, которую он решает правильно. Я обнаружил, что наиболее продуктивные инженеры - это те, кто способен определить истинную проблему, которая должна быть решена, даже если это не совсем поставленная проблема. Способность критически думать о задаваемом вопросе и, возможно, переформулировать его в нечто, что проще решить, является критическим навыком. Пропущенный момент, когда проблема четко указана, должен быть большим красным флагом.
2. Решение проблемы с помощью избыточного оборудования - это вторичная проблема, которая часто является результатом первой проблемы. Есть пара различных патологий, которые могут иметь такой результат. Во-первых, неправильное понимание проблемы или ее слишком широкое определение может привести к слишком сложному решению. Это явно связано с первым пунктом выше. Во-вторых, попытка «выпендриться», продумывая будущие сценарии, которые могут быть неактуальными. Это может быть проблематично, потому что это указывает на то, что кандидат не понимает ценности простоты в решениях и отложенной сложности, пока это действительно не необходимо. Это то, что может быть исправлено с хорошим руководством, но это настороже, когда кто-то входит в организацию.

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

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

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

Вот некоторые вещи, которые, возможно, не были упомянуты в ваших требованиях:

• Стандарты кодирования

• Комментарии

• Обработка исключений

• Описательные имена переменных, классов, методов

• После идиоматического использования языка

• Правильный объектно-ориентированный дизайн

• Внимание к возможным проблемам параллелизма

• Написание тестовых случаев для кода

Обратили ли вы внимание на одну из этих вещей, не заявив об этом явно? Как кандидат узнает, какие из них вас волнуют, а какие нет?

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

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

ИМХО ответ однозначно да , это предупреждающий знак, если

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

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

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

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

Может быть.

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

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

Если решение было правильным, то оно становится менее понятным. Лично я считаю, что многие люди слишком сильно увлекаются ЯГНИ . Если вы можете взять конкретную проблему и создать общее решение, не увеличивая сложность и не снижая удобство обслуживания, то почему бы не сделать общее решение? (Подумайте, перевернуть строку или перевернуть любую коллекцию) На мой взгляд, такая «чрезмерная инженерия» явно хороша.

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

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

Может быть, но рассмотрим следующее:

• Интервью тяжело: люди в стрессе. Это должно быть в значительной степени учтено в любой проблеме, которую вы даете кому-то

• Длина требования: как долго и просто требования? Вы сделали их лишними, чтобы убедиться, что вы включили все. В результате они могут быть понятны вам, но требования могут быть чрезмерно сложными! Один раз я проходил собеседование по поводу проблемы с примерно 3 страницами текста для задачи, которая была относительно простой. Иногда весь этот текст может быть трудно читать и интерпретировать на собеседовании, а также может быть неверно истолкован.

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

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

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

Многое из этого может быть связано с тем, как вы формулируете вопрос и как вы рассматриваете интервью целиком.

Это как: «Давайте посмотрим, насколько вы креативны. Что такое 2 + 2?» Четыре? Все, что вы могли бы придумать, это самый простой, очевидный и точный ответ? Молодые разработчики / разработчики начального уровня, которые так стремятся произвести впечатление во время собеседования, возьмут «Мы хотим проверить ваши навыки кодирования или увидеть, насколько вы хороши в программировании». означать «сделать что-то очень сложное». Нам всем нравится думать, что проще - это лучшее, кроме случаев, когда это усложняет ситуацию.

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

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

Это зависит, но, как правило, нет.

Дизайн в целом - это навык, приобретенный с опытом. Описание Аарона в этой прогрессии, связанное с Марджаном, обычно хорошее.

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

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

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

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

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

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

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