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

Було багато дискусій навколо відмінного питання " Чи допоможе висока репутація в Stack Overflow отримати хорошу роботу? ". Я одразу погодився з Джошком, який в основному сказав " Ні " (я поясню, чому), але Джоель зазвучав з безліччю переконливих фактів, які змусили мене також виграти його.

Моє запитання - які інші навички (крім технічного генія) ви вимагаєте від розробника? Щоб отримати роботу або зберегти її.

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

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

Я хотів би знати, що ви вимагаєте від своїх розробників і ЧОМУ це важливо (зрештою, ви наймаєте когось для написання коду, чи не так? Чому б ви хотіли, щоб він був напористим?) . В ідеалі я хотів би, щоб ви створили приклад питання, яке б ви задали під час інтерв'ю на підтримку вашої відповіді.

Відмінні комунікативні навички.

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

EDIT: Спосіб побачити їх під час інтерв'ю може бути, запитавши у них, що таке їх улюблена рамка для X, а потім сказати, що їм потрібно працювати над проектом, де X може бути використаний, але це політичне рішення використовувати технологію Y (що явно старше і має деякі обмеження, які вирішує X).

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

Робота в команді / спілкування:

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

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

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

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

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

Це більше рис, ніж навичок, але я, мабуть, припускаю, що їх все-таки варто знайти в когось, щоб бути успішним розробником:

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

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

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

Самомотивація також була б важливим вмінням бачити. Що їх рухає? Наскільки добре вони можуть це сформулювати? "Офісний простір" має цю лінію від Пітера Гіббонса:

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

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

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

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

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

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

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

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

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

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

«Кава - це для близьких людей», - як казала колись у фільмі людина.

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

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

Його ніколи не вистачає.

Здоровий глузд. Вирішення проблеми. Інтерес до технології в цілому. Ставлення робити все правильно. Наполегливість. Гра в команді / спілкування

Оцініть кожен вміння на 1-5. Якщо ви отримали хв 3 і в середньому 20+. Вам буде хороше життя як розробник. 25+ стане успішним розробником. Менше 10 і вам потрібно серйозно задуматися про кар’єру в розробці програмного забезпечення.