Недостатньо писати ефективний код. Які слабкі місця та вимоги до українських сеньйорів
Редакція DOU поспілкувалась з ІТ-фахівцями, які проводять співбесіди з кандидатами рівня Senior, щоб з’ясувати критерії та вимоги до їхньої роботи. А також запитала про слабкі місця сучасних українських сеньйорів.
Ілюстрація Уляни Патоки
«Якщо поставити сеньйора робити прості нудні завдання, то скоро він почне вносити різноманітність у рутину»
Павло Кручіна, Development Director в Fintech Project, 14 років досвіду в ІТ
Senior-фахівець, вибачте за тавтологію, повинен мати зрілі технічні навички та зрілі компетенції (soft skills). З технічного боку це означає знати та вміти застосовувати «стандартні» рішення, розуміти, чому вони стали стандартом, межі їхнього застосування і що буде, якщо їх не використовувати. «Креативне рішення» звучить красиво, але зазвичай приносить більше проблем, ніж користі. У плані компетенцій важливо усвідомлювати свої емоції, комунікувати з іншими членами команди та брати на себе відповідальність.
Я наймаю людей, які відповідають моїм вимогам. Знаходити їх в українських реаліях вдається. Так, іноді я помиляюся у виборі. Але знов-таки це моя помилка, а не всі навколо погані.
Якщо говорити про загальні тенденції, то останнім часом (років 5) кандидати на рівень Senior усе більше бояться відповідальності. Раніше люди запитували про те, як їм дорости до тімліда/менеджера, зараз — хто буде їхнім ментором. І таке питання від того, хто претендує на роль Senior або навіть техліда, звучить дивно.
Якщо дати сеньйору прості нудні завдання, то досить скоро він почне вносити різноманітність у рутину. Хоча в моїй практиці дивних ситуацій з Senior-співробітниками трапляється мало. І що «сеньйоріша» людина, то менше :) Якщо всі співробітники мають одні й ті самі професійні проблеми, то в компанії явно проблеми з рекрутингом і менеджментом.
З цікавого для мене (але не для власника компанії) була можливість спостерігати, як прекрасний фахівець (і тут немає ні тіні сарказму) завалив проєкт, намагаючись впровадити в нього нові технології. Щотижня — усе новіші.
Як компаніям привабити Seniors
Бути гранично чесними на співбесіді з претендентом. Якщо немає документації, код «у шоколаді» тільки з вигляду і в найближчий рік потрібно буде не давати йому вмерти — то треба так і сказати. Довго приховувати однаково не вийде.
Бути гранично чесними з собою під час найму. Якщо ви шукайте Manual QA-ліда, а людина говорить про бажання піти в автоматизацію — то це навряд чи буде вдалий вибір.
Комфортне робоче місце, гарна зарплата, адекватний менеджмент тощо — не менш важливі складники. Подібне притягує подібне. Нерозумно сподіватися, що хороший спеціаліст затримається в команді некомпетентних інтриганів.
Є ще такий варіант: давати особливу «плюшку» та шукати людей, для яких це надцінність. Наприклад, можливість взяти в будь-який час відпустку на необмежений період. У цьому разі процес найму буде складним і плинність кадрів — украй невисокою (людям буде важко знайти іншу таку компанію).
«70% українських сеньйорів у вебпрограмуванні насправді є зарозумілими мідлами»
Стас Довгодько, веброзробник, СТО, керівник у вільному плаванні, більш як 17 років досвіду в ІТ
Провів понад сотню співбесід і зробив офер
На мій погляд, рівень Senior — це дещо серйозніше, аніж «трохи більше досвіду». Це має означати, що спеціаліст уже давно технічно опанував професію, оперує бізнес-категоріями та бачить комплексно проблеми. Senior-спеціаліст має, якщо він впевнений, що існує більш раціональний технічний шлях розв’язання бізнес-завдання, донести своє бачення керівництву. Адекватне керівництво у такому разі має дослухатися та обговорити цю пропозицію. Senior, звісно, може помилятися, як і будь-який інший спеціаліст, але його обов’язок — формувати рішення та його обґрунтовувати.
В українських реаліях буває по-різному. Наша дійсність спотворена діяльністю аутсорс-гігантів, для яких личка роками давалась переважно як «рейт, за який можна продати спеціаліста». Я працював із продуктовими компаніями й думаю, що це був первинний фільтр: спеціалісти такого рівня здебільшого вже знаються на моделях бізнесу і приходять з відповідними очікуваннями та розумінням моїх очікувань як співрозмовника.
Інший бік медалі аутсорсу — український ринок програмування вихований лише аутсорсерами. У нас, на жаль, майже не було локального замовника років 10, і тому всі спеціалісти (як і я) з’явилися разом із замовниками «звідти». Ринок був порожнім, наповнювався швидко, градацію вигадували щомісяця в боротьбі за кожний долар-per X. Двадцятирічний сеньйор як явище виникло саме тоді й не на порожньому місці. Лише спілкування із закордонними колегами прочищало мізки: було не дуже зрозуміло, як з того боку скайпу людина вдвічі старша, набагато талановитіша та з більшими знаннями та досвідом, а сеньйор тут ти.
Продуктові компанії переважно не мають чітких циклів розробки, естімейти завжди «на вчора», а ТЗ «на серветках он у тій купі». Часто є необхідність перевіряти ідеї бізнесу за мінімальну ціну в мінімальні терміни, тому таким компаніям/проєктам потрібні спеціалісти, які можуть запропонувати швидкі рішення для різних сценаріїв. Саме сеньйор може це зробити й передбачити майбутні потреби.
В умовах контрактної розробки, коли є формалізоване ТЗ, чітка вертикальна ієрархія і змога апелювати до класичного «цього не було в ТЗ, і тепер треба все переробити», немає потреби у людині, що знає подальші кроки. Тож шукають фахівця, який буде «фігачити» за планом архітектора. І мідл у цьому разі ідеальний варіант. Сеньйор, що успішно пропрацював у продуктовій компанії, в аутсорсі буде або нудьгувати та звільниться, або перепрофілюється на архітектора без досвіду. А навіщо це компанії, та ще й за великі гроші — не дуже зрозуміло.
Я переконаний, що співбесіда на позицію Senior має відрізнятися від інших. Вона має відбуватися у форматі діалогу «про життя». Лише обговорення комплексних ситуацій, максимально наближених до реальних. Розгорнута відповідь вебсеньйора на запитання «Як би ви спроєктували власний CDN для стримінгу відео та які ви бачите проблеми на шляху?» розповість вам набагато більше, аніж 50 питань типу «Де помилка в цій функції на 30 рядків?». Також важливими є зворотні питання від кандидата до потенційного працедавця. Саме в ці моменти стає зрозуміло, чим дихає кандидат і чого очікує від вас.
Власний досвід
У роботі із сеньйорами, вважаю, мені таланило. Більшість спеціалістів залишалася на довгий час, і все було в межах очікувань. Траплялися поодинокі ситуації, що викликали подив. Наприклад, один хлопець, класний спеціаліст, раз на місяць зникав з поля зору. На дзвінки не відповідав, в офіс не ходив, а як з’являвся, то розповідав дивні історії зі шкільного фольклору про тролейбус і те, як переводив бабусь через дорогу. Після третього схожого епізоду ми розійшлися.
Пам’ятаю і ситуацію, коли на співбесіду Senior прийшов хлопець, за фахом, здається, зварювальник. Без попередження, просто зайшов в офіс зі словами: «Я талановитий, а що, справді така зп? Що треба робити?». Оскільки того дня відбувалося
А якось один кандидат дуже переймався кількістю вихідних. Оскільки всі компанії, з якими я працював, завжди дотримувалися державного календаря — це здалося мені дивним, тож співбесіда швидко закінчилася.
Українські сеньйори швидко «ловлять зірку». Водночас, якщо порівнювати із закордонними колегами, кваліфікація їхня посередня, досвіду немає, планувати не вміють, комплексно проблеми не бачать. На мій погляд, 70% українських сеньйорів у вебпрограмуванні насправді є зарозумілими мідлами. Це все відбувається на тлі певного переосмислення рівнів: сьогодні для бізнесу талановитий мідл з іскрою в очах може бути значно ціннішим за сеньйора, який уже трішки понюхав дурних грошей і чомусь поділяє роботу на ту, яка його достойна і яка недостойна. Неодноразово стикався із позицією «я сеньйор, носіть мене на руках».
Як компаніям привабити Seniors
Думаю, по-перше, компаніям варто з’ясувати, чи справді їм потрібні сеньйори та навіщо. Якщо ж відповідь позитивна, на мою думку, українського сеньйора із досвідом
- Стабільність. Ну не вірю я в 35-40-річного спеціаліста, який буде ганятися за приставкою в холі. Він радше хотітиме довгострокового «кредиту». Тут ще можна гратися в соціальні бонуси, як-от довгострокове медичне страхування, включно із сім’єю. Логіка така: я витрачаю своє життя на розвиток компанії, то хай компанія забезпечить мою сім’ю хоч якимось гарантіями.
- Професійна свобода дій. Не завжди спеціаліст має змогу пояснювати технічні рішення, він розв’язує комплексну проблему і розраховує на довіру замовника. Middle-фахівець іноді корисніший, адже пояснює більше.
- Чесність з боку керівництва. Молоді спеціалісти через свій вік не завжди можуть/хочуть помітити фальш чи лестощі в спілкуванні. Людина, старша за безпосереднього керівника, знає, чого хоче. Її не вмотивувати табличкою «Найкращий працівник». Проте такий фахівець може зрозуміти та розв’язати проблеми, якщо знатиме ситуацію повніше (це перетікає в пункт про стабільність).
Я вважаю, що фактор грошей тут відходить на другий план. Будь-який сеньйор у вільному плаванні переб’є ледь не будь-який офер компанії, але отримає майже нульову «стабільність».
«Є кандидати, які спочатку роздувають себе до позиції Senior, хоча знають, що не дотягують до неї»
Богдан Гусев, CTO в Unstoppable domains, 13 років досвіду в ІТ
Я від кандидатів очікую високого рівня володіння основами програмування: змінні, функції, умови, цикли, класи, методи. Також навичок повторного використання коду на практичних завданнях.
Нерідко в українських реаліях у невеликих компаніях (до 100 осіб) практикують неформальний підхід до найму програмістів: співробітник проводить інтерв’ю, ставить питання, не маючи критеріїв оцінювання правильних відповідей. Часто співбесіда обмежується дружньою розмовою.
Наприклад, питання на зразок «Яка ваша думка про технології X? Як би ви розв’язували проблему великого навантаження на сервер? Яке ваше найбільше досягнення на попередній роботі?» не мають достатньо контексту, щоб сформувати критерії правильної відповіді. Так можна оцінити кандидата як людину, але не його професійний рівень.
Інша особливість інтерв’ю, як правило, у великих компаніях, — його проводить людина, що не зацікавлена в наймі кандидата (можливо, він працюватиме в іншому відділі) чи навпаки, надто зацікавлена, коли робота аж горить або є план з найму і його треба виконати.
В обох варіантах успішність інтерв’ю залежить від настрою того, хто його проводить, від самого кандидата залежить мало.
Приклади гарних запитань на співбесіді — у форматі алгоритмічних завдань. Наприклад, у вас є функція draw_point (x, y), запрограмуйте функцію draw_circle (x, y, radius), використовуючи draw_point. Або «Вам потрібно спроєктувати реляційну базу даних соціальної мережі, в якій користувачі можуть додавати одне одного в друзі (а-ля фейсбук). Які таблиці та колонки для цього створите?».
Очікування vs реальність
Одна з моїх головних вимог до кандидата — вміння розв’язувати задачу будь-якого рівня складності відповідно до займаної позиції. Senior Developer повинен добре виконувати завдання рівня Junior, Middle і Senior. Кандидати, що претендують на звання сеньйора, часто валяться на елементарних завданнях, які може зробити будь-який студент.
Інший абсолютно жахливий аспект — небажання Senior-кандидата приділити достатньо часу та сил інтерв’ю. Людина не розуміє, що за три години вирішується, як і де вона проводитиме чверть свого часу в найближчі кілька років. Коли я ухвалюю рішення взяти фахівця на роботу, то подумки дістаю з-під столу валізу з 50
Казуси на інтерв’ю трапляються постійно. Є кандидати, які спочатку роздувають себе до позиції Senior, хоча точно знають, що не дотягують до неї. Така людина буде відтягувати момент практичних завдань до останнього і намагатися зберегти режим дружньої бесіди, в якій ніхто нікому нічого не винен.
Інша група кандидатів — самовпевнені. Вони охоче починають будь-яке завдання. Якщо ж не можуть його розв’язати, то самовпевнено доводять, що це неможливо або що їхнє рішення правильне і найкраще. Це видається особливо безглуздим на тлі того, що я бачив, як це завдання виконує щонайменше сотня кандидатів, і знаю всі деталі.
Про слабкі місця Senior-спеціалістів
Інколи фахівці працюють у «неадекватних» компаніях, і це формує їхні слабкі сторони. У цьому контексті адекватною є компанія, дії якої спрямовані на отримання прибутку. На жаль, нині багато тих, що покликані тішити марнославство свого керівництва. Їхні зарплати та штат, як правило, роздуті, а технічні рішення схожі на стріляння по горобцях із гармати.
Ситуація може бути ускладнена тим, що критерії оцінювання програмістів у таких компаніях теж неадекватні, і менш компетентні люди керують більш компетентними. Програміст, що розвивається в межах такої структури, навчається неадекватних принципів роботи. І під час переходу на нове місце почувається дезорієнтованим. Навіть якщо розробник має тривалий професійний досвід, приводити його до тями потім треба досить довго, щоб він правильно інтерпретував цей досвід.
Як компаніям привабити Seniors
Я роблю акцент на професійному зростанні. Українські реалії такі, що в нас немає технологічних компаній топового рівня, як-от Google, Github, Shopify тощо. Я намагаюся своїм прикладом показати іншим, що той рівень, який в Україні називають Senior Developer, далеко не межа, і пропоную досягати більшого разом.
«Важливо не тільки вміти писати ефективний код, а й збирати вимоги, виявляти технічні ризики, планувати та оцінювати завдання, проводити демки та презентації»
Максим Ковтун, Chief Software Architect в Sigma Software, понад 18 років досвіду в ІТ
Особисті та професійні якості Senior-спеціаліста
Є модель спеціалістів під назвою T-shaped. Здається, вперше її описала компанія Valve у своєму хендбуці. Суть у тому, що спеціаліст має володіти глибокою експертизою в одному напрямі та знати потрохи в інших напрямах і сферах. Глибока експертиза дає змогу робити свій внесок у проєкт, а широкий кругозір — ефективно поєднати її з іншими експертизами та полегшити спілкування з командою. Думаю, ця модель вдало змальовує те, яким має бути Senior-спеціаліст. Це повинна бути експертиза з вирішення якогось типу проблем чи побудови певного типу рішень, а не просто «із застосування технології». Наприклад, «експерт з побудови мобільних бізнес-додатків» або «експерт з оптимізації хмарних рішень», а не «експерт з .NET MVC». Такі фахівці добре опанували кілька технологій, інструментів і підходів, стежать за появою нових і підбирають необхідну комбінацію під кожен проєкт. Натомість «спеціаліст із застосування молотка» всі проблеми вирішує молотком.
Щодо особистих якостей, то я виокремив би дві — вміння ефективно комунікувати та розв’язувати проблеми. Перше — критичний скіл, тому що жоден не може виконати сучасний проєкт самотужки. Неодмінно доведеться спілкуватись з іншими фахівцями, із замовником, можливо, з користувачами системи. Обговорювати вимоги та рішення, аргументувати їх іншим та демонструвати результати своєї роботи. Від того, наскільки вправно ви це робите, залежить, скільки часу будете витрачати на комунікацію, як чітко розумітимете свої завдання, чи розумітиме замовник, як складно було зробити нову фічу або виправити баг. З мого досвіду якість комунікації більш важлива для успіху проєкту, ніж наявність глибоких технічних навичок.
Problem solving — це те, заради чого клієнт шукає фахівців. Щоб вони прийшли та розв’язали його проблему. Від Senior-спеціаліста очікують, що він буде аналізувати проєктні проблеми за своїм напрямом, знаходити вирішення і розблоковувати роботу менш досвідчених колег.
Знайти Senior-спеціалістів з такими навичками у нас непросто, тому їх дуже цінують. Особливо тих, що володіють обома скілами. Їх умовно називаю «стартерами» — це інженери, з якими можна починати нові проєкти. Бо що потрібно для старту? Показати замовнику, що у нас є експертиза, що ми можемо проєкт виконати. Для цього із ним треба поспілкуватися, почути замовника, продемонструвати, що ми його розуміємо, проаналізувати вхідну інформацію та проблему і знайти одне або кілька рішень. Нерідко буває, що в компанії є вільні люди, але проєкт стартувати нема кому, бо немає стартера.
Про співбесіди
На співбесідах я прошу кандидатів намалювати високорівневу архітектуру чи дизайн одного з минулих проєктів на вибір, щоб побачити, наскільки людина усвідомлює, як влаштована її система загалом.
Якось один з кандидатів почав малювати блоки. Я глянув у резюме, а там
Про слабкі місця сеньйорів
Мені здається, що здебільшого у нас інженери приділяють увагу суто технічним навичкам. Чи тому, що думають, ніби тільки цим мають займатися, чи тому, що не вважають інші навички важливими для проєктів. Тут треба розуміти: проєкт — це щось більше, ніж програмний продукт, і його успіх — не те саме, що ідеально написана програма. А тому важливо не тільки вміти писати ефективний код, а й збирати вимоги, виявляти технічні ризики, планувати та оцінювати завдання, проводити демки та презентації тощо. Поліпшення комунікаційних навичок зробило б нашу роботу простішою і приємнішою і підвищило б нашу професійність в очах замовників.
Друга річ — це загальна зрілість, життєвий досвід, вміння сприймати обставини та обмеження, якісь життєві ситуації. Коли, наприклад, ведеш справи з польськими, шведськими або американськими колегами, то завжди є відчуття, що працюєш з дорослими людьми і що вони прийшли робити роботу. Приміром, щось у проєкті не ідеально: чи то частина технічного рішення, чи в процесах щось пішло не так, чи команда замовника не сподобалася. Наші розробники звикли жалітись і чекати, що прийде хтось і щось із цим зробить, замість того, щоб запропонувати зміни в проєкт чи навіть ініціювати та впровадити їх. «Проєкт фіговий, бо ми тут неправильно спринти плануємо» замість «Наступного разу спробуймо планувати спринт не так, а ось так».
На жаль, ніяк не можна гарантувати, що почуття відповідальності за проєкт буде в роботі з українськими колегами. Можливо, тому, що середній вік наших спеціалістів нижчий. Можливо, через відчуття безпеки, яке дає робота в IT. Тож можна трохи розслабитись і повередувати, підкинути зайву роботу нянькам-менеджерам і HR’ам. Яка б не була причина — не можу знайти в цьому позитивного моменту.
Як компаніям привабити Seniors
Senior-розробники — це спеціалісти з ±8 роками досвіду, їм уже за 30, вони бачили не один проєкт і пережили кілька технологій. Вони працювали з різними типами клієнтів і найімовірніше в кількох компаніях. Думаю, вони цінують свій час і зусилля та не бажають їх витрачати дарма. У сеньйорів розвинулась рекламна сліпота, тому кольорові описи вакансій і банери на них не діють. Натомість вони будуть вдячні за короткі повідомлення, в яких є тільки суть, без усіляких прикрас, щоб не доводилось ту суть вишукувати.
Їх наймають для того, щоб розв’язувати проблеми у конкретних напрямах. Тож Senior-спеціаліст очікуватиме, що йому виділять зону відповідальності, де він матиме змогу ухвалювати професійні рішення, ризикувати, робити помилки та радіти вдалим рішенням. Він буде розраховувати на співпрацю з грамотним менеджером проєкту та архітектором. І хотітиме відкритої комунікації з цими людьми та керівництвом: якщо щось треба зробити, скажіть про це, не шукайте примарних мотиваторів.
Думаю, такому фахівцю важливо розуміти, навіщо щось робити, тож він шукатиме причину для кожної своєї задачі. Звісно, сеньйору приємно, коли його внесок у проєкт і компанію бачать і цінують, а його поважають.
«Описую просту вигадану мову програмування і прошу кандидата за її допомогою запрограмувати поведінку мікроконтролера»
Олександр Кагановський, CTO / Engineering director у Larch Networks, понад 15 років досвіду в ІТ
Провів понад 1000 співбесід на трьох останніх місцях роботи. На посади Senior — близько 300 чи 400. Із них найняв приблизно 50 фахівців.
Загалом поділ розробників на рівні досить умовний. Для мене важливіша та користь, яку фахівець дає в проєкті, а не суб’єктивна «посада». Тому під Senior я матиму на увазі ефективного та досвідченого розробника.
Senior в одній предметній галузі під час переходу в іншу може на деякий час стати менш ефективним, ніж Middle. Але завдяки своєму досвіду «справжній» сеньйор опанує нову галузь і досягне зрештою своєї високої продуктивності. В ідеалі Senior-фахівець має писати код, який у майбутньому буде зручно підтримувати та розвивати іншим розробникам.
Не менш важливо й таке (пункти йдуть у довільному порядку):
- Добре знати базові поняття Computer Science, щоб розуміти, як його ПЗ працює в реальній системі.
- Розуміти технології, що використовують у предметній галузі проєкту.
- Мати достатні навички спілкування, щоб обговорювати технічні рішення з колегами, замовниками, керівництвом.
- Володіти англійською мовою на достатньому рівні, якщо це потрібно для роботи в команді, із замовником і технічною документацією (і якщо навіть якийсь проєкт не потребує англійської, то для читання документації вона знадобиться).
- Мати навички роботи в команді для передачі досвіду колегам.
- Бути відповідальнім, володіти тайм-менеджментом (наприклад, вчасно брати участь в робочих мітингах).
- Мати добрі навички самонавчання (щоб вивчати необхідні нові технології або предметну галузь).
- Мати аналітичне та інженерне мислення та вміти шукати способи розв’язання проблем.
- Бути здатним працювати на результат, а не на процес.
- Розуміти методи розробки ПО загалом та особливості їх використання в його команді / проєкті / компанії.
- Вміти за потреби писати документацію, а не тільки код.
- Пропонувати способи підвищити ефективність своєї роботи або роботи команди.
- Розуміти, що ми живемо в реальному неідеальному світі, тому інколи треба орієнтуватися на доцільність проєкту і потреби замовника, а не програмувати лише заради мистецтва (тобто краще щось просто добре зробити вчасно, ніж зробити ідеально — але ніколи).
- Бути професіоналом і робити не тільки те, що цікаво, а й те, що потрібно для проєкту.
- І найважливіше — на Senior-розробника можна покластися, він не потребує мікроменеджменту з боку керівництва. Якщо в нього виникнуть проблеми чи питання в процесі роботи, він сам повідомить керівника про це.
А що на практиці
З мого досвіду роботи з українськими розробниками та закордонними фахівцями, інженери з титулом Senior можуть бути як добрими професіоналами, так і не дуже. Наша компанія не використовує градацію Junior / Middle / Senior. Але, звичайно, більш ефективні працівники, які приносять більше користі своєю працею, отримують вищу оплату.
Якщо я стикаюся з інженером з іншої компанії, то для мене важливим є те, як він розуміє проєкт і рівень своїх повноважень. Пам’ятаю, як колись у 2006 році влаштовувався в компанію Flextronics (потім вона змінила назву на Aricent). Після співбесіди, коли зайшла мова про мою градацію, я сказав, що для мене однаково, буду я вважатися Junior чи Senior. Для мене важливо, чим я займатимуся та який буде рівень оплати. І тоді мене взяли як Senior-розробника.
Під час співбесід часто буває, що кандидат не виявляє достатньої компетенції, щоб претендувати на бажаний рівень оплати. Якщо я бачу, що фахівець все одно може бути корисним у проєкті (умовно кажучи, не тягне на Senior, але добрий Middle або навіть Junior) і водночас має мотивацію розвиватися (тобто в майбутньому зможе стати Senior), то можу запропонувати йому роботу. Але рівень оплати залежить від його внеску в проєкт.
Іноді це влаштовує кандидата, і в майбутньому, коли його рівень компетенції підвищується, то зростає зарплата. Буває, що кандидат не погоджується. Наприклад, якщо на попередньому місці він отримував більше, ніж я готовий йому запропонувати (у своїй галузі людина може бути гарним спеціалістом, однак у моїх проєктах потрібні інші знання та навички). Або людина переоцінює свій професіоналізм.
Трапляється, що і я не можу добре оцінити кандидата. Одного разу я проводив співбесіду з класним, досвідченим фахівцем, але оплата, яку я міг йому запропонувати, була все одно нижчою за його очікування.
Наведу ще кілька прикладів.
У нас значна частина коду пишеться на С та С++. І дуже дивує, коли кандидат претендує на оплату рівня Senior і водночас не знає, як працює цикл for або вивід з форматуванням printf. Чи не може пояснити, що таке балансоване відсортоване бінарне дерево, та порівняти ефективність деяких операцій у такому дереві з two-way list.
Ще я оцінюю здатність кандидата використовувати нові знання під час виконання практичних завдань. Я описую вигадану мову програмування, яка містить лише 5 команд, і прошу за її допомогою запрограмувати поведінку мікроконтролера. Деякі кандидати не можуть це зробити і здаються, кажучи: «Я такої мови не вчив раніше». Звичайно, не вчив. Але в повсякденній роботі доводиться вивчати багато нового, якщо інженер не здатний або боїться це робити, то він точно не Senior.
Слабкі місця українських сеньйорів
Я буду казати за тих, хто все ж радше Senior, аніж ні. Українські інженери можуть бути більш сконцентровані на вирішенні формально поставленого завдання, ніж на розв’язанні реальної проблеми клієнта. Звісно, це загалом відповідальність замовника та менеджера + тімліда сформулювати суть. Але якщо Senior-інженер фокусувався б не лише на окремому завданні, а на продукті загалом — то це давало б кращий результат. У цьому розробники із Заходу часто сильніші. Також деякі сеньйори не готові ефективно взаємодіяти в команді з менш досвідченими спеціалістами, передавати їм знання так, щоб уся команда працювала краще.
Рівень англійської в українських розробників у середньому гірший, ніж в ізраїльських, німецьких, французьких чи скандинавських колег. Я б не сказав, що це сильно заважає роботі (для технічного спілкування рівень англійської і в українських розробників зазвичай достатній), але нам ще є куди розвиватися. У компанії Larch Networks ми проводимо курси з підвищення рівня англійської мови для працівників. Запрошуємо викладачів в офіс, і спеціалісти в робочий час двічі на тиждень відвідують заняття. І я бачу, як з часом рівень спілкування з іноземними колегами суттєво поліпшується.
Якщо казати про недоліки роботи Senior-інженерів із Заходу, то я стикався з різними ситуаціями. Наприклад, інженер має значний досвід у розробці апаратури (HW), де його рівень, можливо, справді Senior. І хоч у програмному забезпеченні (SW) він не дуже тямить, його призначили відповідальним за це. І замість того, щоб консультуватися з більш досвідченими SW-розробниками, людина намагається самостійно придумати архітектуру SW. Або інженер, що має титул Senior, пише код і не виносить спільні великі частини у функції, а натомість шанує copy-paste. Не знає, як працюють вказівники (pointers) у C, чи не може в таск-трекері сформулювати проблему і пише «система зламалася» без жодних деталей. Або ж має проблеми із soft skills — не приходить вчасно на запланований мітинг.
Справжній Senior-розробник зазвичай більш зрілий, ніж міфічний
«Відсутність досвіду роботи з конкретною технологією — не проблема»
Леонід Литвиненко, СТО в YouScan, PhD в Computer Science, 14 років досвіду в ІТ
Провів понад кілька сотень співбесід, з яких близько 30% — з кандидатами на позицію Senior (найняв 7).
Для визначення рівня фахівця, треба дивитись і на soft skills, і на hard skills. Кажучи про soft skills, маю на увазі спілкування, можливість досягнути консенсусу, розуміння, що таке продукт і який результат має бути в кінці, як його виміряти. Зазвичай така людина допомагає зростати колегам і в технічному плані, і в плані «м’яких» компетенцій.
Hard skills — вміння писати код, який легко розуміють і можуть змінити інші. Бачити, що може бути проблемою, а де, навпаки, можна щось винести за дужки. Думати про те, як певне рішення працюватиме і змінюватиметься з часом. Вміти вчитись, переносити принципи з одного середовища на інше. Не боятися пробувати робити не так, як заведено в індустрії, де це має сенс (не боятися йти проти авторитетів).
Відсутність досвіду роботи з конкретною технологією не є проблемою. Це лише інструмент, в якому можна розібратись. У YouScan, наприклад, важливо, щоб Senior розумів кінцеву цінність продукту, ставив собі та іншим питання. Можливо, чогось варто не робити, а щось — виконати і виміряти чи зробити зовсім по-іншому.
А ще важливо, щоб людина писала код, який буде легко підтримувати та змінювати. Для мене це особливо цінно, бо в YouScan, за статистикою, за три роки повністю переписали 95% коду.
Загалом на українському ринку праці мало так званих продуктових розробників. Частіше ІТ-фахівці роблять фічі, а не продукт. Вони зав’язані на поширених підходах навіть там, де можна спростити процес.
Складність роботи із Senior і в тому, що часто конкретний досвід людини буде лише частково перетинатись з тим, що потрібно в конкретній команді. Тому цінність кандидата саме в загальному рівні, а конкретні технології менш важливі, проте кандидати часто фокусують свій саморозвиток саме на конкретних технологіях.
Кожна компанія має для себе з’ясувати, чи є взагалі сенс наймати сеньйорів. Трапляється, що сильний мідл — це кращий варіант. Бо якщо він швидко вчиться, інвестувати в нього — це робити ідеального сеньйора для команди. Зазвичай у сеньйора вже сформований погляд на ті чи інші методи, підходи до роботи, і не факт, що він підійде. Проте якщо він вас влаштовує, то ви робитимете все, щоб найняти та втримати цю людину.
Крім того, варто пам’ятати, що різні компанії рівень Senior бачать по-різному (і мова не лише про аутсорс). Поширеним інструментом для оцінювання рівня розробника є так званий Engineering Ladders Framework.
Якщо ви лише починаєте будувати у себе в компанії систему орієтирів для росту ваших колег, раджу також подивитися на добірку, як це зроблено у інших компаній.
«Якщо звести систему мотивації працівників професійно розвиватися суто до підвищення зарплат — це призведе до професійного вигорання»
Андрій Агеєв, Competence Manager у Software Development Office, SoftServe, 25 років в ІТ
В ІТ-індустрії немає універсального стандарту рівня Senior. Кожна компанія вибудовує свої критерії технічних знань і практичного досвіду для такого фахівця. Спільним є те, що на цей рівень людина виходить за досягнення та відмінні результати роботи.
Якщо говорити безпосередньо про SoftServe, то в нас є чіткі фреймворки визначення рівня працівників, які охоплюють як hard skills (рівень технічної експертизи), так і soft skills (продуктивність, відповідальність та інші якості). За їхню розробку і постійне вдосконалення відповідає окремий відділ — Software Development Office. Серед його функцій — розробка плану розвитку менш досвічених фахівців до рівня Senior. Оскільки для компанії, яка прагне будувати успішний бізнес, важливо вирощувати свої таланти.
Для SoftServe велику роль відіграють не лише технічні знання (хоча на цьому роблять акцент), а й бізнес-компетенції (орієнтовані на клієнта чи компанію). Крім цього, від своїх Senior-спеціалістів ми очікуємо активну участь в житті професійного ком’юніті: виступи на конференціях, проведення мітапів і воркшопів, менторство менш досвідчених колег.
Часто компанії систему мотивації працівників професійно розвиватися зводять суто до підвищення зарплат. Це призводить до професійного вигорання. Адже при такому підході втрачається азарт до чогось нового і незвіданого, який і лежить в основі ІТ-індустрії.
Важливий аспект для втримання сеньйорів у компанії — це давати людям розуміння, як вони можуть зростати, і допомагати розвивати відповідні навички. Для них наступним кар’єрним етапом є позиція тех- чи тімліда, завданням якого вже є управління командою. Тож потрібно фокусуватися на розвитку менеджерських навичок. А далі?
Перший сценарій — це проджект-менеджмент. Багато сеньйорів стають чудовими менеджерами, оскільки знають технологічні складові проєкту і мають навички роботи з командою, бо самі через це пройшли. Другий сценарій — архітектура. Тут теж цілі бізнесу і цілі клієнта виходять на перше місце, а не технології. Це підходить не всім.
Нерідко чую від розробників: «Менеджмент — то не моє. Архітектура — цікаво, але робота з клієнтом і постійна комунікація створюють дискомфорт, а я хочу досліджувати технологію чи інжинірингові практики». Для них цінністю є саме генерувати ідеї та власноруч втілювати їх. А те, що супроводжує ці процеси, не є таким захопливим. Щоб утримати таких людей у компанії, важливо пропонувати складні технологічні проєкти. Інакше інженери вигоратимуть. Ми в SoftServe будуємо кар’єрну мапу з урахуванням цих особливостей.
За індивідуальний розвиток інженерів у нашій компанії відповідають Talent Success Leads (TSL). Вони ведуть конкретні компетенції в конкретному розробницькому центрі і мають бачення загального стратегічного розвитку. Водночас TSL перебувають у постійному контакті з інженерами та їхніми менеджерами. Розуміючи глобальний контекст і особливості конкретної людини, вони допомагають побудувати персональний план довготривалого розвитку в компанії.
Варто зазначити, що підвищення спеціаліста в нашій компанії визначають відповідно до навичок, а не часу перебування на попередній позиції. Є чіткий список знань і вмінь, якими має володіти Senior. Претендує кандидат на цю роль? Навички є? Ласкаво просимо. І байдуже, має він досвіду рік чи десять. Тут я згадую одного кандидата з величезним потенціалом і мотивацією. Він прийшов у компанію наприкінці
