Когда быть техническим гением недостаточно, чтобы быть успешным разработчиком? [закрыто]

Было много дискуссий вокруг отличного вопроса « Поможет ли высокая репутация в Stack Overflow найти хорошую работу? ». Я сразу же согласился с JoshK , что в основном сказал « Нет » (я объясню , почему), но Джоэл подхватила с большим количеством убедительных фактов , которые заставили меня upvote его , а также.

Мой вопрос: какие еще навыки (кроме технического гения) вам требуются от разработчика? Чтобы получить работу или сохранить ее.

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

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

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

Отличные коммуникативные навыки.

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

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

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

Командная работа / общение:

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

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

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

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

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

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

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

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

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

Самомотивация также была бы важным навыком, чтобы видеть. Что их гонит? Насколько хорошо они могут сформулировать это? «Офисное пространство» имеет следующую строку от Питера Гиббона:

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

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

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

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

2) Работа в команде - это немного другой навык, который сильно зависит от первого. По сути, мне нужно определить, будет ли человек, которого я пытаюсь нанять, принести пользу команде в целом, или будут какие-то личные конфликты, которые я могу нанять. Никто не может предсказать будущее, но вы не можете игнорировать предупреждающие знаки в интервью.

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

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

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

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

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

«Кофе для близких», как однажды сказал мужчина в фильме.

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

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

Его никогда не достаточно.

Здравый смысл. Решение проблем. Интерес к технологии в целом. Отношение делать все правильно. Упорство. Командная игра / Общение.

Оцените каждый навык на 1-5. Если вы получили мин 3 и в среднем 20+. У вас будет хорошая жизнь в качестве разработчика. 25+ будет успешным разработчиком. Менее 10, и вам нужно серьезно подумать о карьере в разработке программного обеспечения.