Чи є "Наймання тільки найкращих" справді практичною порадою для звичайного програмування настільних додатків? [зачинено]

У фоновому режимі ми робимо настільні інженерні програми, з AutoCAD на зразок інтерфейсу користувача, щось подібне до етабів .

Одна річ, яка мене справді клопоче, - це чи потрібно найняти найкращих розробників? Для початку ми відчуваємо великі труднощі при підборі; Більшість резюме, які ми бачимо, або роблять прості програми CRUD, або налаштування SharePoint, які, на мою думку, насправді не передбачають багато жорстких програм. Навіть ті, кого ми закликаємо на співбесіду, більшість не може виконати послідовність Фібоначчі і простий двійковий пошук, і ми досить люб’язні, щоб дати підказки і чітко прописати проблеми, щоб кандидатам не довелося шукати словник для перевірки. що означає "послідовність Фібоначчі".

Це змусило мене задуматися: Так, нам потрібен певний рівень здатності до програмування, коли ми робимо обчислювальну геометрію / лінійні програми програмування, і нам потрібен певний рівень здатності до програмування, коли розробляємо архітектуру програмного забезпечення / або вирішуємо, який шаблон програмного забезпечення використовувати, але крім цього , багато нашого коду - це просто сантехнічний код (я думаю), який може зробити хтось, хто знайомий з програмуванням.

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

Що ти думаєш?

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

Я пропоную вам занадто сильно читати Джоела. Те, що він написав у своєму блозі, суперечить його відгукам на цьому веб-сайті, тому я б дуже не сприймав його слова.

Що робить суперзірку і чому потрібно мати її, відкриває довгу і нікуди не обговорювану дискусію. Це елітаризм і це не практично.

Вам потрібна людина, яка:

1. Хочеться робити те, що ви робите
2. Був би пристрасним захопленим програмістом
3. Мав би потенціал, щоб дізнатися, що потрібно, щоб правильно виконати свою роботу

Решта не має ніякого значення.

Ви б не повірили, скільки там молодих випускників, які нічого іншого не хочуть, окрім як зануритися у такий проект, що є сильним для CS, і ніколи не дивитись на кодування програм CRUD. Поки я був одним із них, я практично мріяв приєднатися до проекту навколо розробки компілятора, але не зміг його знайти. Чому б не дати шанс одному з них?

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

більшість резюме, які ми бачимо, або роблять прості програми CRUD, або налаштовують SharePoint

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

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

Другим моментом, який слід пам’ятати, є те, що при вимірюванні пропускної спроможності проекту спостерігається пік продуктивності для команд з 5-8 осіб. Ви не повернетесь до тієї ж продуктивності, поки не будете мати команду з понад 20 людей. Будьте дуже, дуже обережні щодо того, щоб збільшити команду за розмірами, де працює невелика динаміка команди. І якщо ви збираєтесь залишитися нижче цього порогу, тоді ви дуже хочете, щоб тих 5-8 людей були хорошими.

Обидва пункти рішуче говорять про те, щоб витримати правильний прокат.

Усі заявляють, що "наймають лише перших 1 перцентилей". Якби це було правдою, 100% зайнятих людей були б у "першому перцентилі" всіх людей, тож 99% усіх людей були б безробітними (у будь-якій галузі). Оскільки це, очевидно, не так, і ми всі досвідчені люди, які явно не в цій групі (чому ще взагалі ви задаєте це питання ...), ми знаємо, що це неправда.

Насправді організації, що складаються виключно з таких людей, були б дуже нестабільними. Занадто багато его, занадто багато суперечливих ідей. Це або розвалиться, як кожен робить свою справу, занепадаючи в ніколи не закінчуються теоретичні дискусії про відносні достоїнства всього, або перетворюється на постійну кричущу відповідність, коли настрої спалахують, коли потрібно приймати рішення.

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

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

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

"більшість не може виконати послідовність Фібоначчі та простий двійковий пошук"

Ваші критерії, безумовно, неправильні. У моїй групі ми всі фізики чи інженери. Надіюсь, ніхто не може займатися бінарним пошуком, тому що ми не відвідували курси CS і в реальному житті використовуємо для цього бібліотеку. Я б навіть сказав: той, хто сам пише бінсарха, не знає, як зосередитися на важливих речах.

Це набагато важливіше, якщо кандидат розумний і вписується в групу. Якщо ви хочете перевірити його талант програмування, дайте йому / їй роботу, щоб виконувати вдома. Зверніть увагу, скільки часу йому / їй потрібно, і обговоріть результати, щоб дізнатися, чи справді це кандидати.

Я думаю, що "наймати найкращих" стає занадто великим культом.

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

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

Незважаючи на це, вимагати базової компетентності та мінімальних розумних вимог не є розумним і не є чимось, з чим слід компромісувати.

Подумайте про рутинну операцію: залежно від вашої толерантності до ризику, ви, мабуть, вважаєте за краще, щоб середній лікар її виконував, а не чекав 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 пише про це у програмуванні Pearls ). Можливо, це не так вже й погано тестувати, поки ви не виключаєте кандидатів на основі їх неспроможності вирішити. Якщо вони вирішують це швидко і правильно, то, принаймні, це натякає на те, який тип програміста вони є, щоб ви мали більше інформації в цьому конкретному випадку.

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

Задайте собі це запитання (ви якось уже це робили ..): Якщо у вас інший інженер на цій же посаді протягом 5 років, чи очікуєте ви, що вона запам'ятає серію fibonanci та двійкові пошуки?

якщо відповідь "ні", то змініть свою схему інтерв'ю. Можливо, вам потрібно знати десяток алгоритмів пошуку, якщо ви хочете працювати над пошуковою програмою, наприклад google або bing. Всі інші просто використовують map.get ("");

орієнтуйте свої співбесіди на те, що потрібно на посаді, а не на доброго програміста з підручником.

Якщо ви дійсно не цікавитеся якістю, я б запропонував скористатись одним із веб-сайтів, що займаються аутсорсингом, і почати з невеликих проектів. Тоді ви можете заплатити їм, якщо вони зможуть виконати роботу, і мати простий спосіб застави, якщо вони не можуть.

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

Я повністю згоден з більшістю коментарів вище, які стосуються пристосування людини до проблеми. Зазвичай це призводить до довгострокових відносин, а не до наймання суперзірки для роботи над звичайною проблемою - це просто засмутить його швидко піти.
Сказавши це, ви завжди повинні намагатися найняти свою компанію, а не конкретну посаду. Тому що цей самий хлопець збирається рано чи пізно переходити між командами за допомогою особистих контактів тощо, і він може виявитися дедветом десь деінде. Переконайтеся, що у вашій компанії є дуже суворі внутрішні рекомендації щодо трансферу, і ви матимете чітку картину того, що ви будете робити у вашій команді протягом наступних двох років, перш ніж наймати людину, яка, на вашу думку, може не відповідати компанії (але вирішить поточну проблему ). Я бачив занадто багато випадків, коли посередність у розробниках змушувала команду працювати надто важко, щоб вмістити їх навколо.