Является ли «Найм только лучших» действительно практическим советом для нормального программирования приложений для настольных компьютеров? [закрыто]

Для фона мы создаем приложения для настольных систем с интерфейсом, похожим на AutoCAD, похожим на etabs .

Меня действительно беспокоит то, что нужно нанимать лучших разработчиков? Для начала, мы испытываем большие трудности при наборе персонала; большинство резюме, которое мы видим, или делают простые приложения CRUD, или настройку SharePoint, которая, я не думаю, действительно включает в себя много жесткого программирования. Даже те, кого мы зовем на собеседование, большинство не могут выполнить последовательность Фибоначчи и простой двоичный поиск, и мы достаточно любезны, чтобы выдавать подсказки и четко излагать проблемы, чтобы кандидатам не приходилось искать словарь для проверки что означает «последовательность Фибоначчи».

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

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

Как вы думаете?

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

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

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

Вам нужен человек, который:

1. Хотел бы делать то, что вы делаете
2. Был бы страстный увлеченный программист
3. Будет иметь потенциал, чтобы узнать, что нужно, чтобы сделать вашу работу правильно

Остальное не имеет значения.

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

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

большинство резюме, которые мы видим, либо делают простые приложения CRUD, либо настраивают SharePoint

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

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

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

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

Все утверждают, что «нанимают только 1 верхний процентиль». Если бы это было правдой, все 100% работающих людей были бы в «верхнем 1-м процентиле» всех людей, поэтому 99% всех людей были бы безработными (в любой данной области). Поскольку это явно не так, и мы все опытные люди, которые явно не входят в эту группу (почему вы вообще задаете этот вопрос ...), мы знаем, что это не так.

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

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

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

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

«большинство не может сделать последовательность Фибоначчи и простой двоичный поиск»

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

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

Я думаю, что «найм лучших» становится слишком культовым.

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

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

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

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

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

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

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

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

Я настоятельно рекомендую вам определить людей, которых у вас в настоящее время есть в вашей команде, которые являются «ключевыми людьми» (например, добиться цели, иметь хорошие отношения, хорошо работать с неопределенностью / требованиями высокого уровня и т. Д.), А затем нанять людей, которых у них есть. работал в прошлом (и уважение, очевидно). Это устраняет большую неопределенность в процессе собеседования и помогает объединить команду.

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

Как уже упоминалось, обратите внимание на процесс собеседования. Заставьте кандидатов написать код (или, лучше, рассмотрите их решение проблемы «1 час домой»), заставьте их пообедать с командой. Познакомьтесь с их техническими и межличностными навыками. И никогда не бойтесь сказать «нет», даже если вы отчаянно нуждаетесь в еще 20 людях для большого проекта, который начнется на следующей неделе.

По моему опыту принцип Паретто относится и к программированию: 80% работы выполняется 20% разработчиков и наоборот. ОК, цифры могут быть преувеличены. В действительности у вас будет примерно 20% сотрудников, выполняющих 50% работы (под работой я подразумеваю хорошую работу, а не просто строки кода). Это на самом деле больше похоже на кривую колокола. Таким образом, в команде из 10 человек будет 1 герой, 2 отличных парня, 4 средних и 2-3 жалких.

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

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

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

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

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

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

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

Итак, вы собираетесь снизить свои стандарты. Это круто, возможно, вы передумаете после того, как наймете действительно паршивого человека. Тот, который ответит на все ваши вопросы CS безупречно, но кто действительно не может написать одну строку производственного кода. Удачи с этим :)

Давайте сделаем шаг назад.

Что мы пытаемся сделать? Написать программное обеспечение.

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

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

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

Правильно, так что вы просите чертов Арнольд? Создайте веб-сайт на PHP, напишите немного jQuery, сделайте так, чтобы PHP выполнял некоторые базовые CRUD с MSSQL, и измените цвета фона.

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

Итак, тебе не нужно лучшее? Да, мне просто нужен кто-то с навыком, который соответствует моим целям.

Ой. Да уж.

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

Плохой прокат

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

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

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

Но если вы решили нанять менее опытных людей, вам следует рассмотреть возможность использования технологий, с которыми легко работать. Например, если вы планируете использовать C ++ для всего проекта, ограничьте часть C ++ библиотеками, написанными вашими лучшими сотрудниками, и позвольте другим реализовать пользовательский интерфейс в Visual Basic.

Запишите значения, которые вы ищете в сотрудника, который вступит в ваши ряды.

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

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

Понять и принять ценности ваших нынешних сотрудников и передать их в ваших рабочих приложениях. Хорошие компании с устойчивой системой ценностей привлекают хороших сотрудников.

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

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

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

Сдача перед тем, как начать, самый верный способ проиграть.

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

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

Задайте себе этот вопрос (вы вроде как уже ..): Если у вас есть другой инженер на той же должности в течение 5 лет, ожидаете ли вы, что она вспомнит ряды Фибонанчи и бинарные поиски?

если ответ «нет», измените схему собеседования. Может быть, вам нужно знать дюжину алгоритмов поиска, если вы хотите работать с таким поисковым приложением, как Google или Bing. Все остальные просто используют map.get ("");

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

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

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

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