"Не так важливо, яке завдання, як підхід і ставлення до його виконання". Що визначає сеньйора
Бородате слово Senior викликає жваві суперечки і є джерелом жартів, та все ж майже всі хочуть мати цей префікс. Мовляв, це справа честі.
У статті я спробую розкласти цю личку на елементарні частинки з різних вимірів: з погляду компанії і спеціаліста, ринку та конкретної професійної кар’єри, віку і навичок, технічних умінь і soft skills.
Почав писати цей текст як коментар до статті, але що далі писав, то ставало зрозуміліше, що мої думки тягнуть на окрему колонку.
Одразу скажу, що там, де сеньйор, там і сеньйорита, а двічі писати всюди мені ліньки :)
Різниця між Junior, Middle та Senior з погляду завдань
Це питання не зовсім про те, для кого завдання. Це означало б перевести фокус з різниці між тайтлами на різницю між завданнями. Можна будь-кого навчити точити олівці, але кому саме призначене завдання заточити олівець — для сеньйора, мідла чи джуна? Важко сказати. Різниця радше в тому, як завдання виконують, наскільки автономно і як розв’язують супутні проблеми в процесі, якщо його дати трьом інженерам різних рівнів.
Щоб не прив’язуватись до складних матерій, скажімо, є завдання на канбан-дошці — приготувати вареники для 5 осіб, бо стейкхолдери дуже хочуть вареників з вишнями. А плита — одна на кілька команд. Тут є і спільні ресурси, які треба зарезервувати (плита), і складний нелінійний процес, і необхідність спланувати якісні та кількісні показники результату (розмір кінцевих порцій, вигляд і смак). Є і дедлайн, бо стейкхолдери голодні.
Ілюстрації Уляни Патоки
Джун у загальних рисах знає, як тримати качалку, як розкачати та порізати тісто, як користуватись плитою. А чогось не знає. Наприклад, як замісити тісто чи ліпити вареники, бо не готував нічого складнішого за яєчню. Джуну потрібне зовнішнє керівництво, щоб стежили за процесом. Та навіть з контролем і поясненнями результат не буде гарантований. Але йому можна довірити нескладні чіткі речі: зганяти в магазин, просіяти борошно, помити вишні чи повибирати кісточки, розігріти плиту, закип’ятити воду.
Мідл щось готував, але не ліпив вареники, а просто варив пельмені з магазину. Він думає, що цих знань досить і приготувати вареники для великої кількості людей не складніше, ніж зварити собі на вечерю пельмені. Мідл блочить себе й команду на незначних проблемах, які через це перетворюються на великі. Наприклад, каже щось на зразок «Дайте мені чітку інструкцію по пунктах, як треба готувати вареники та acceptance criteria», «Я ці вареники за 5 хвилин нароблю», «Ліпити вареники довго й нудно, це проти принципу code reuse, створімо краще робота (фреймворк) для ліплення вареників».
Мідл буде старатись ліпити кожен вареник ідеально, вкладаючи у страву всю душу й нестримну жагу застосування знань і best practices. Як писав Мартін Фаулер про мікросервісну архітектуру вареників, намагатиметься впровадити
Мідлу варто часом нагадувати (тут доречне слово «скеровувати», to guide), що треба робити вареники зі слів бабусі, записаних на клаптику паперу, а не переписувати рецепт, поки стейкхолдери мруть з голоду. Що не потрібно писати фреймворки й роботів для умовних 50 вареників. Що наліпити 50 штук абияк, але вчасно — краще, ніж лише 5, які б вони не були ідеальні. Про резервування плити й качалки (shared resources) взагалі не йдеться, як і про оцінювання завдання загалом. Резервування інструментів чи планування часу та розміру майбутніх порцій повністю на відповідальності, наприклад, PM’а.
Загалом мідл зробить так, як треба, переробить, якщо треба, але його не можна залишати із завданням наодинці. Необхідна зовнішня координація.
Сеньйор побачить завдання з виготовлення 5 порцій, зразу оцінюватиме все загалом (top-down) і з кінця (from the deadline). Він уточнить розмір порцій, щоб збагнути обсяг роботи. З’ясує, чи це на раз, чи треба буде готувати вареники регулярно, бо тоді певна автоматизація матиме сенс. Спитає і про плиту і про виключне право на неї, бо знає, що вона буде вкрай необхідна, і ця критична залежність від плити — потенційний ризик. Оцінить завдання загалом і те, чи здатен зробити все вчасно. Якщо ні — скаже, скільки зможе зробити. Напевне, попросить час на оцінювання процесу. Якщо візьме це завдання, піде сам домовлятись за плиту наперед або наголосить, що PM має потурбуватись про це.
Якщо плита недоступна чи зламана або не така, як треба, порушить цю проблему, можливо, навіть завчасно. Якщо немає рецепта — знайде, а що може додумає сам. Попросить час на експериментальне приготування. Ліпитиме вареники власноруч, бо розуміє, що часу на створення роботів і штучний інтелект немає. Всередині процесу сеньйор вже точно знатиме, чи встигає все завершити, і повідомить, якщо ні або якщо виникли проблеми, котрі він не може вирішити самостійно без загрози зриву завдання.
Джун і мідл потребують активної уваги, часто є part of the problem, not part of a solution. Сеньйору не треба зовнішня координація, бо він сам драйвить процес і стає part of the solution. Зазвичай йому потрібна допомога зовні, тільки щоб «пробивати стіни», як-от залучити іншу команду, переламати бюрократію через коліно, пришвидшити відповідь від людини, яка на іншому континенті колупається в носі, поки тут усе горить. Сеньйор не потребує значного контролю від менеджерів, він їм навіть допомагає, але потребує і очікує також допомоги і того підходу, що нині називають servant leadership. І це логічно, бо він розбирається в проблемі глибше, детальніше і краще, ніж будь-який менеджер.
Тут не так важливо, яке завдання, як підхід і ставлення до його виконання, до планування, використання свого і чужого часу.
Що визначає сеньйора
Hard skills vs soft skills
Корисність технічних навичок, або як їх називають hard skills, спеціаліста визначають лише щодо конкретного проєкту чи навіть конкретного завдання.
Пов’язувати будь-які погони вище Middle/Junior тільки з hard skills, тобто технічною експертизою інженера, — короткозорий підхід. Так здебільшого вважають мідли та джуніори. Але таке сприйняття може бути у будь-кого: і сеньйор-інженера, і архітектора, і менеджера, і CTO. Технічні навички — звісно, необхідна складова, але цього недостатньо, щоб бути професіоналом своєї справи.
Senior, Principal, Lead, Architect — всі ці звання вимагають не просто кодити швидше, знати більше фреймворків чи мов і парадигм програмування, а вміти оцінювати й планувати час і ресурси наперед — свої та команди. Що вищий ранг, то більше прогнози мають відповідати реальному стану справ на проєкті й більше малопомітних нюансів враховувати. Володіння конкретною предметною галуззю теж важить багато. Скажімо, знання внутрішніх процесів електронних платежів чи GDPR — це виходить за межі суто технічних інженерних навичок, хоч і не належать до софт скілс.
Хтось може заперечити, що планувати — то справа не розробника, а PM’а, але я відповім, що кожен Senior має бути трошки PM’ом. Планування — спільна відповідальність.
Дехто зауважить, що спілкуватись із замовником його мовою — це робота Product Owner чи Business Analyst або іншого спеціалізованого менеджера. А я відповім, що кожен Senior має бути трохи PO, трохи BA. Спілкування та розуміння — спільна відповідальність.
Робота в команді та ієрархії, менторство, критика та аргументації в дискусіях, резервування часу на беклог, документація, форс-мажори, вирішення конфліктів, інтерв’ю, гендерні чи іншого характеру інклюзивні відносини, кризовий менеджмент, планування бюджетів чи кількох проєктів, які конфліктують за ресурси, — усе це мало стосується кодингу, але спеціаліст має в них розбиратись, хоча б поверхово встромивши носа, щоб бути справді професіоналом.
Тому для сеньйора hard skills відходять на другий план, на перший план виходять soft skills. І що сеньйорніший сеньйор (Architect, Principal, Lead etc), то важливіші «м’які навички».
Це особливо очевидно, коли уявити 15 пихатих архітектів із 300 років загального досвіду, які збираються одного дня з топами обговорювати трансформацію компанії. Саме софт скіли, а не спільна вечірка опісля, не дають таким зустрічам перетворитись на беззмістовний базар з потоками матюків.
Володіння завданням
Принцип task ownership тісно пов’язаний з тим, що називають proactiveness. Суть володіння завданням — у відповідальності за драйв його прогресу і доведення до завершення. Для тих, хто знає Inversion of Control, це певною мірою інверсія відповідальності. Девіз тут: Can I do something from my side to make it faster, available, ordered, reserved, unblocked?
Сеньйор не покладається на інших людей, щоб вони надали ресурси, і не перекладає на інших відповідальність за затримки, вирішення блокерів. Це розділяє і власник завдання. У найпростішому випадку він має активно відстежувати процес, вимагати й нагадувати, цікавитись прогресом, можливо, допомогти з реалізацією у межах власних можливостей, а не просто чекати, доки необхідне дадуть. У важких випадках це може бути бізнес-поїздка інженера за океан, щоб швидко розв’язати проблему на місці face-to-face з інженером іншої команди, замовником тощо.
Якщо приземлити це до прикладу з варениками, то резервація плити як зовнішнього необхідного сеньйору ресурсу має бути турботою PM’а, бо це спільні ресурси кількох команд. Реальним прикладом може стати UAT-оточення чи якась спільна «залізяка». Щоб зварити вареники, потрібно отримати виключне право на користування плитою на певний час. Але сеньйор як власник завдання розуміє, що навіть якщо резервування плити — відповідальність когось іншого, то неготові вареники і голодні стейкхолдери — це саме його відповідальність і провал саме його завдання. Він активно буде комунікувати й допомагати розв’язати проблему: вимагати й нагадувати про ті ресурси як PM’у, так і людям, що за них відповідальні. Такий сеньйор легко дасть менеджеру по шиї завчасно (образно, звісно) або самостійно «підніме» питання нагору. У разі, якщо критична проблема доступу до плити довго не вирішується і його вареники під ризиком.
Різновиди сеньйорів
Слово Senior — беззмістовне без контексту, коли відірване від язика, з якого злітає, і коли безвідносне до людини, стосовно якої вживається. Ця личка перевантажена настільки, що можна сперечатись на рівному місці й не розуміти одне одного.
Позичимо трохи ідей із сеньйор-психології, бо це несправжня наука, тому можна робити все, що хочеться, й будувати які завгодно теорії☺
По-перше, є власне самосприйняття, або Я-Сеньйор. Ви можете бути впевненими чи невпевненими у собі, загалом чи тільки професійно, бо маєте сильне чи слабке Я-Сеньйор. Ви можете вважати себе Senior або не надавати великого значення званням взагалі чи мати важку стадію хронічного синдрому самозванця.
По-друге, є власний ідеал чи вектор професіоналізму, може, навіть кілька. Назвемо його Ідеал-Сеньйор. Тут просто — це те, як ви уявляєте справжнє сеньйорство. Порівнюючи себе з колегами, Марком Цукербергом, хакером на цікавій годині CCC чи рок-зіркою на GitHub, чи навіть з хвацькою тьотьою Мотьою, власницею генделика за рогом.
Я-Сеньйор та Ідеал-Сеньйор — результати нашого виховання та навчання, прочитаних книжок, переглянутих роликів у інтернеті, конференцій, спілкування з класними (а може, й ні) спеціалістами. Ці поняття несуть баласт минулого досвіду роботи, досягнень та невдач. Щось у собі можна змінити, а те, що бере коріння в глибокому дитинстві чи темпераменті — ні. Бо це така глибока частина, яка робить нас нами.
Є ще ЯвРезюме-Сеньйор — тобто те, як ви себе описали в резюме.
Люди люблять прикрашати, прибріхувати та відверто брехати в резюме. Що відрізняє справді сеньйора від решти — мінімальна різниця між реальним і написаним. Грубо кажучи, якщо у вас в резюме — Ansible, Terraform чи Infrastructure as a Code, то для сеньйора це означає, що він безпосередньо писав і підтримував той код не один місяць, а не просто робив у власній уяві terraform apply всередині написаного іншою командою автоматичного пайплайну, що магічно запустився, коли він виконав git push, навіть не з консолі, а зі зручної IDE.
Тут має значення професійна етика. Якщо юний орел навіть пролетить у вузьку шпаринку, то все одно скоро стане очевидно для всіх у команді, хто є хто, навіть якщо це не будуть озвучувати. До того ж світ тісний і сховати тонку брехню часто не виходить саме через горизонтальні знайомства. Хоча комусь так щастить. Але справді сеньйор не будує свою професію на такій удачі, це нетривкий фундамент.
Тепер до зовнішніх. Є те, як уявляє сеньйора оточення — команда, менеджер, рекрутер, СxO, близький або не дуже знайомий. Усе це різні уявлення, і не дуже здорово дорослій самодостатній людині виправдовувати чужі. Наприклад, доводити свою профпридатність сусідці, в якої зламався ноутбук. Бо вона натякає, що ви профнепридатний програміст, якщо не можете відремонтувати древню модель ноута за символічну шоколадку й пів години.
Є ще такі різновиди: Вакансія-Сеньйор, Інтерв’ю-Сеньйор, Позиція-Сеньйор, Щабель-Сеньйор і Зарплата-Сеньйор.
Вакансія-Сеньйор — це просто: введіть власну професію у LinkedIn чи візьміть у HR’а профіль своєї вакансії і порівняйте, чи підходите ви на позицію, на якій уже працюєте. Такий підхід відкрив, на моїй пам’яті, не одну пару невинних очей.
Soft skills здорового порівняння себе з вимогами до своєї роботи — гарний привід для самовдосконалення та подальшого зростання, адже дозу натхнення і розширення свідомості від опису деяких вакансій важко порівняти з будь-якими наркотиками. Шкода, що рідко хто взагалі вдумливо читає ті натхненні тексти.
Інтерв’ю-Сеньйор — це та міфічна людина, яка відстрілює патерни «банди чотирьох», напам’ять знає java-файл класу Object, розкаже все про дюжину методів сортування, вміє рахувати кількість тенісних м’ячів в автобусах, здатна маркером створити з нуля HA-архітектуру багаторівневої системи на білій дошці за 15 хвилин, розказати про багатопотоковість, компілятори чи бази даних краще за її творців. При цьому, звісно, не виступить і крапля поту на чолі; спеціаліст випромінює впевненість, оптимізм та жагу до нових складних завдань саме у вашій компанії! Як елементарні частинки у колайдерах, такі Інтерв’ю-Сеньйори існують лише в колайдерах — тобто на інтерв’ю. Є, звісно, окремі генії, які живуть з енциклопедією в голові, але більшість з нас мають неідеальну пам’ять, та ще й купу турбот у житті, крім бінарних дерев чи тонкостей сортування. Коли це вже 250 разів написано, розжовано й гуглиться за 5 хвилин.
Проблема виникає в ситуаціях, коли вас оцінює людина, яка не може абсолютно збагнути ваші тонкі внутрішні Я-Сеньйор та Ідеал-Сеньйор з ваших слів чи з Резюме-Сеньйора.
Вміти бути Інтерв’ю-Сеньйором і є, до речі, важливим софт скілом. Це вміння продати себе. Не просто свої навички і вміння, а ще й себе як людину, як професіонала, якому можна довірити завдання. Тому сеньйор — це й трошки сейлз, трошки перемовник. Мати підвішений язик, поважати правила гри, знати професійний, та й просто етикет — частина цього процесу.
Позиція-Сеньйор — тут сказати особливо нічого. Так написано у контракті. Єдине додам, що мені (і не тільки) глибоко байдуже, чи написана та личка десь у двох екземплярах. Але є люди, яким це принципово, принаймні в певний період кар’єрного зростання. Це нормально, тут немає нічого поганого.
Щабель-Сеньйор має значення, коли ми зростаємо в певній компанії. Отримати підвищення — завжди чудове досягнення. Оплески, привітання, брендова футболка, більша довіра та відповідальність, часто з надбавкою до компенсації — це приємно. І в тому й суть — це інструмент мотивації, який чомусь мало використовують у тій IT-Україні, яку я знаю. Не буду узагальнювати, бо мав справу лише з аутсорсом.
Можу суб’єктивно порівняти з Німеччиною.
У німецькій компанії 15 і більше інженерних ступенів, якими можна дертись хоч усе життя. Часом ви можете змінювати напрями з технічного на управлінський, хоча нерідко вони паралельні. В Україні достатньо дивна, як на мене, бідна й одноманітна трирівнева кар’єрна градація. Далі вважають нормальним зростання в менеджери (мабуть, це пов’язано з гомогенністю галузі, де всі інженери — більше чи менше взаємозамінні гайки-ресурси).
Щабель-Сеньйор, як і будь-який щабель, — це інструмент мотивації, штучного створення цілком реальних кар’єрних перспектив, інструмент визнання, побудови лояльності, надання більших повноважень і відповідальності тощо. В західних компаніях, які часом старші за найстарших працівників — це потужний мотиваційний фактор.
Уявіть CEO Siemens, який знає про засновників у кращому разі з Вікіпедії, але після 7 років управління такою махиною — це ж довше, ніж навчання в університеті — стає уже незамінним. Хоч, б’юсь об заклад, він і досі час від часу дізнається щось нове про коника, якого осідлав. Або уявіть працівника, який працює у конкретному відділі техзабезпечення банку не один десяток років, здійснив не одну міграцію критичного модуля і досить агресивно ставиться до всіх ваших «контейнерів», «кубернетісів» і «клаудів». Такі люди та їхні знання справді неймовірно цінні. І компанії створюють умови для визнання їх серед інших співробітників. Наголошую, ці умови — штучно створені, але бенефіт від прогресу в кар’єрі цілком реальний. Цікаво дізнатись, чи є приклади з українських реалій. Напишіть у коментарях!
Будь-який щабель, як і власне Щабель-Сеньор, може не відповідати своєму рівню за технічними навичками, та й навичками взагалі. Принцип Пітера — саме про щаблі. І зіставити Щабель-Сеньйора та власне людину можна лише за досить довгого періоду роботи з нею в конкретній команді або за детального розбору минулих проєктів.
Як сеньйор ви маєте бути трохи кар’єристом і трохи знавцем office politics, мусите мати хоч дрібку професійних амбіцій. Просто тому, що у середовищі, де всі сеньйори, ніхто особливо не сеньйор ☺ А такий соціальний еквілібріум довго не існує.
Моє стійке враження: у Німеччині тайтли здебільшого роздаються як мотивація та визнання відчутних досягнень, в Україні — як певний прогрес у професійному навчанні.
Іншими словами, в Німеччині наступний тайтл дадуть дуже не скоро, за плідну роботу й очевидні досягнення або як зростання в кар’єрі. В Україні це як університетський диплом, заздалегідь очікуване людиною визнання, що вона щось вивчила і щось може зробити чи пропрацювала в певній вузькій галузі
Загалом у Німеччині нормально перейти в іншу компанію, і в личці не буде більше ні слова Senior чи особливого тайтла. Наприклад, із Senior Software Developer перейти на Software Developer і заробляти навіть більше. Не можу сказати те саме про Україну, хоча минуло багато часу, тому можу помилятись.
В обох країнах покладатись на слово Senior в резюме — досить необачно.
Тепер найсмачніше — Зарплата-Сеньйор. Хочеться багато говорити, але сказати особливо нічого, крім важкої правди. А правда в тому, що зарплата будь-якого працівника залежить від багатьох факторів, але загалом не має стосунку до вас як спеціаліста чи людини. Ви цілком можете вважати, що на свою зарплату, коли досягли певного рівня, впливаєте приблизно так само, як на сніг, вітер чи хмари, швидко й сильно дихаючи. Зарплата — абсолютно економічна матерія, яка залежить від макроекономіки, стану ринку в розрізі певної спеціалізації, фінансових можливостей і заначок компанії і того, як ваші очікування в них вписуються, від локальної конкуренції за конкретну посаду тощо.
Це особливо має бути зрозуміло в нинішню кризу і особливо тим, хто пережив кризу
Певною мірою ми маємо змогу вибирати: піти в недофінансований цікавий стартап чи в забезпечену грошима нуднувату велику компанію. Трапляються забезпечені стартапи й недофінансовані нудні великі компанії. Але це вибір у невеликих межах.
Зарплата залежить і від вміння вести перемовини й того, чи маєте ви дефіцитні навички для конкретної позиції. Але чи здатні ви побачити й використати сильну позицію в процесі salary negotiations — теж залежить від вас.
Тут варто лише зазначити: не майте жодного сумніву, що HR-відділ будь-якої середньої чи великої компанії має незрівнянно більше досвіду в зарплатних перемовинах та обізнаний з ринком набагато краще за будь-якого окремого інженера.
Кожен, хто вважає себе сеньйором, має бути підкованим перемовником. Це написано в частині про зарплати, але ця навичка важлива в усіх сферах професійного життя. Коли я кажу «перемовини» — це не тільки про гроші чи витискання вищої зарплати. Це вміння поступатись чимось у процесі роботи.
Огляд підходів до визначення сеньйорів
Я кілька разів перечитував статтю, в яку мої відповіді не потрапили через розмір, і вважаю, що без порівняння різних думок, ця колонка була б неповною. Деякі думки відверто дивують, але деякі слушні, і це приємно. Найближчі мені міркування Ковтуна та Кагановського. Вони допомогли зробити текст удвічі довшим і краще сформулювати деякі поняття.
Ковтун єдиний згадав концепцію T-shaped та підкреслив надмірний фокус середнього українського фахівця на технічних навичках, з чим я повністю згоден. Не зовсім погоджуюся з його фільтром «про 8 років досвіду» і фільтром «за 30», але певен, автор і не мав на увазі застосовувати ці критерії сліпо, а радше орієнтовно.
Кагановський, своєю чергою, зазначив дещо важливе: Senior досить легко переходить в іншу галузь і водночас швидко відновлює продуктивність. Я б сказав, що це не просто через досвід, а саме через софт скіли. Коли у мене був би вибір найняти сеньйора з суміжної галузі, чи джуна/мідла з потрібної — я схилявся б до першого варіанта. Звісно, такий сеньйор справді має демонструвати бажання і потенціал до переходу, та й інтерв’ю в нього було б зовсім не з простих.
Він також навів приклад «сеньйорів», що претендують на високу зарплату, коли не здатні пояснити щось базове, і цей досвід я з ним поділяю. У світі DevOps модно бути YAML-програмістом і не вміти порахувати IP-мережі чи пояснити SSL. А у світі розробки немало спеціалістів, які запросто напишуть контролер у наявному коді, але не здатні перемножити дві матриці чи створити з нуля структуру проєкту.
Загалом не згоден про більшу зрілість західних розробників. Мій досвід свідчить, що це не так. Хоч увага до софт скілів на Заході — це частина професійного зростання з самого початку, це не дає їм перевагу в тому, що вкладається у слово «зрілість». Проте софт скіли — таки велика частина цього поняття. Саме люди з прокачаними «м’якими навичками» обганяють простих технічних пролетарів у кар’єрі.
Також Кагановський єдиний, хто згадав work-life balance. Професіонал, що себе цінує, завжди дбає про це і працює для того, щоб жити, а не навпаки. Senior’у не вийде нахрапом нав’язати нічні зміни чи овертайми і при цьому не втратити його назавжди. Не всі компанії це розуміють.
Неприємно читати базарні коментарі про СТО, але приємно, що є розумні відгуки. Створилося враження, що в Україні до кінця не визріло розуміння, що за створіння цей сеньйор, навіщо він і що з ним робити, не тільки серед сеньйорів, а й серед управлінців. Проте ми рухаємося в правильному, на мій погляд, напрямку.
У тій статті також згадували про менторство. Думки в коментарях розділились, але здатність бути ментором і здатність бути в ролі ситуативного trainee — це окремий важливий софт скіл. Тут мова не про onboarding і не про джуніорів. Це радше навичка вчитися у всіх і навчати всіх — те, що ще називають knowledge sharing.
Очікування і реальність
Senior = Soft skills, помножені на T-shaped individual
Думаю, загалом люди як на Заході, так і в Україні, не поділяють чи не усвідомлюють цю формулу, а «гарячий» ринок дає певне хибне враження, що личка в резюме щось означає. Title does not entitle.
Якщо переді мною резюме зі словом Senior, я очікую, що кандидат має хоча б деякі софт скіли, достатній рівень технічних навичок для проєкту, відкритість і гнучкість мислення.
Senior — це той рівень, де ти уже або професіонал, або ти ще не Senior. Зростання після сеньйора — це вже професійне вдосконалення та підвищення своєї професійної корисності вглиб і вшир (того, що зветься value). Необхідний професіоналізм — це компетенції роботи з людьми, які набуваються і з часом, і з досвідом. Але не всі ми однакові, у всіх є таланти та особливості.
Хтось інтуїтивно відчуває це й професійно працює джуніором у 20, комусь і в 40 доводиться пояснювати певні речі. Що, скажімо, сексизм — це непрофесійно у професійному житті. Або що треба активно проговорювати проблеми, а не приховувати їх. Тут варто сказати, що лікувати той же сексизм в особистому світогляді чи виховувати дорослих людей — теж непрофесійно, бо не треба лізти в особисте або намагатись перевиховати уже сформовану особистість, якщо у вас не дуже близькі стосунки. Дарма я зачепився за сексизм як приклад, тому поставлю тут крапку.
Є ще чудове слово — «поміркованість». Мабуть, це я і вкладаю в слово «зрілість». Якщо мідл ще має бажання поекспериментувати з новими речами прямо на проєкті, бо десь в інтернеті цікаве написали, то Senior — поміркований інженер, який знайде баланс між новим підходом і підтримкою наявного в робочому стані. Ця поміркованість — стандартний modus operandi. Сеньйор теж багато експериментує, але при цьому не кидає свою компанію під автобус.
Тому технічна експертиза тут відходить дещо на другий план.
Для мене основні критерії Senior — це наявність софт скілів. Серед іншого неназваного і забутого:
- здорова алергія на неконтрольований перфекціонізм;
- вміння працювати й робити прогрес в неоптимальних умовах та вміння бігати з перешкодами: відсутність документації чи якісних тестів, відволікання, конфліктна команда, необхідність ухвалити рішення на свій розсуд і ризик, поки хтось у відпустці, взяти лідерство в невизначеній локальній ситуації;
- вміння визнати, де бракує технічної експертизи, і сказати про це через своє его;
- вміння стояти на своєму й конструктивно аргументувати, як і слухати аргументи інших;
- тактовність у критиці й вміння критикувати, як і сприймати критику інших;
- вміння визнати неправильність підходу, свою помилку чи проблему й проговорити це з командою чи менеджментом;
- вміння працювати в команді з людьми різних компетенцій і різних рівнів, мати терпіння і витримку взаємодіяти з конфліктними колегами певний час;
- вміння бути ментором і дослухатись, коли хтось менторить тебе;
- вміння бути одночасним власником кількох невеликих завдань;
- вміння працювати з конфліктними ситуаціями на базовому рівні;
- вміння оцінювати завдання в команді.
Якщо відштовхуватись від понять soft values чи синергія, то Senior — абсолютно чітко має додавати soft values в команду, а не створювати нові командні, процесні чи корпоративні проблеми.
Як оцінювати і визначати Seniors: власний досвід
Інколи на етапі скринінгу резюме бувають випадки, коли класним кандидатам відмовляють через неякісні резюме. Кілька тижнів тому переглядав теку з такими і натрапив на абсолютно паршиво відформатоване резюме чудового олдскульного хакера із
Якщо дійшло до співбесід, то відбір може закінчитися, якщо йдеться про клінічні варіанти брехні. Зазвичай я даю людині змогу самій сказати, в чому вона сильна, а тоді ставлю з цієї сфери питання. Брехня тут, на жаль, трапляється частіше, ніж хотілося б. Я з усмішкою ввічливо запитую далі, навіть підбадьорюю, але вже знаю, що цього кандидата побачу востаннє в житті. Єдине, що врятує орла — це зворотне питання, що я думаю про його відповідь. Такі, на жаль, рідко задають.
З боку DevOps чи Infrastructure часто трапляється, що кандидати, які знають AWS чи GCP (навіть з не одним сертифікатом), не можуть відповісти на базові речі типу обрахунку IP-адрес. Або мережеві інженери-сеньйори, які ніколи не робили фейловер роутера чи не знають, що таке spine-leaf, RSTP, LACP чи
Щодо hard skills, то цього року мав цікаву співбесіду з кандидатом на Lead Infrastructure Engineer, убивцею процесів:
- Can you explain what is OOM killer and how it works?
- I can, I was killing processes 9 years, you need to use kill command
Стосовно розробки, пригадую, якось я писав тестове завдання для друга на Android-позицію, бо він не знав, як порахувати суму елементів матриці по діагоналі. Довелось усе розжувати. Він щиро здивувався, що на роботі йому треба знати таку математику, і тут певною мірою мав слушність. Це до слова про західних інженерів — він німець.
Серед розробників розчаровує, коли людина палко розказує про патерни, методики тощо, але не може застосувати на дошці той самий патерн або не знає базові алгоритми, не здатна створити з нуля структуру простенького проєкту.
Розчаровує, коли сліпо транслюють best practices чи hype: клауд краще, ніж онсайт, контейнери краще за віртуалки, копіпейст — це зло, YAML кращий за JSON, а JSON кращий за XML, а ось Фаулер сказав, що мікросервіси... тощо.
Сумно, коли Seniorи-погані-танцюристи приходять на проєкт і наступного дня починають жалітись, що все зроблено не так, усе паршиво і що їм не створили умови для плідної роботи.
Буває різне, але здебільшого таких кандидатів легко відсіяти якісним півгодинним технічним скринігом перед основними інтерв’ю, щасливчики — не проходять випробувальний термін. Юні орли, що пролітають таки в шпарину, стають, на жаль, баластом.
Розчаровують і PM’и, які не можуть визначити реальний час та ідеальний, не враховують фінансові витрати у плануваннях чи ставляться до людей як до бездушних ресурсів. Засмучує стабільна тенденція приписувати досягнення команди з 20 лобастих інженерів собі, а ще пошук крайніх. Я не професійний PM, але певне уявлення маю, бо мушу.
Як привабити і втримати сильного фахівця в компанії
Привабити треба, звісно, відчуттям натхнення, що людина працюватиме над цікавим і потрібним проєктом, добрими умовами роботи, конкурентною компенсацією, можливостями розвитку й професійної самореалізації. Не всі пункти завжди можливі, але хоч кілька має бути.
А щоб втримати, маргінально кращі умови не допоможуть, треба потурбуватись про перспективу і довгострокові відносини між компанією та спеціалістом, вчасно визначати проблеми, індивідуальні потреби й особисті цілі людини. І в межах розумного допомогти розв’язати проблеми чи надати людині можливості реалізувати потреби й цілі.
Loyalty is a two-way street, мені подобається думати про себе і компанію як про рівних незалежних агентів. І саме на основі конкретної лояльності компанії як машини до мене як гвинтика я будую свою лояльність до неї. І з часом природно починаю почуватися її частиною. Хоча треба завжди мати на увазі, що ці відносини в більшості аспектів асиметричні, і асиметрія тут не на користь працівника.
Яскравий приклад лояльності махини до гвинтика з особистого досвіду. Одна з минулих компаній дала мені можливість півтора року працювати з України через особисті потреби. Кроки назустріч такого масштабу важать на моїх терезах багато, навіть якщо компанія чи проєкт загалом — не дуже. Але треба навчитись чітко розрізняти конкретного менеджера і компанію загалом, щоб розуміти, від кого ця лояльність йде і кому її повертати. Коли вас звільняють чи ви говорите про підвищення — ви спілкуєтесь з компанією в особі менеджера, який, можливо, просто транслює те, що зовсім не може змінити. Не всі розмежовують лояльність до чи від компанії та лояльність до чи від конкретного управлінця.
Часто кажуть, що люди приходять в компанію, а йдуть від менеджерів, але я не згоден. Йти з болем треба і від хороших менеджерів, якщо вони на пару з вами працюють у поганій компанії, і від поганих менеджерів, навіть якщо вони — в хорошій.
Лояльність — тема цікава, сподіваюсь топи українських компаній напишуть, how they understand and execute this concept from their side ;)
Отже, хто такий Senior
Це коли всі вищезазначені поняття збігаються в одній точці, а ми — професіонали своєї справи, впевнено відчуваємо це внутрішньо, отримуємо за це явне і неявне прийняття та визнання колег, які нижче, вище та на тому ж рівні корпоративної ієрархії, коли це випромінюється на інтерв’ю, коли це не брехня в резюме, коли на проєкті ви справді працюєте над свого рівня завданнями, коли це виливається у співмірну з рештою сеньйорів на ринку зарплату чи інші матеріальні та нематеріальні бонуси.
На моїй пам’яті було всіляке. І якщо звернутись до бородатого жарту, то серед іншого мене не дивують ані
Так вийшло, що мені з дитинства пощастило з внутрішнім сприйняттям та вектором. Я, звісно, починав з азів, як роблять усі нормальні люди, але в мене завжди було здорове відчуття зростання, яке допомогло пройти найскладніші періоди і найгостріші конфлікти. Не буду проєктувати це на всіх, ми всі різні, але якщо є, не дай боже, хронічна професійна вавка — найперше, де варто шукати негаразди — у власній самооцінці. Раджу почати зі статті Юрія Савки.
Якщо ви не сеньйор або навіть якщо ви вже щасливий сеньйор, але відчуваєте, що щось не так, і маєте внутрішню непевність, давно застрягли професійно — попрацюйте саме з собою.
Ще наприкінці статті автор згадує дві системи спортивної самооцінки, і раджу взяти це на озброєння. Так вийшло, що саме «повсякденна» в мене змалку в порядку і з дитинства вектор був правильний. Може, саме тому мені завжди було начхати, яка в мене личка, як мене хтось називає, в кого яка особиста думка про мою роботу, якщо я сам знаю, що більше зробити не міг. «Змагальна», думаю, — це трохи перебільшення. Для спорту, мабуть, підходить, але для командних інженерних проєктів може бути шкідливо. Раджу «освоїти» «повсякденну» самооцінку усім, але вибір за вами.
Вдячний редакції DOU за цікаву тему, що спонукала до такого довгого тексту. А вам, сеньйори й сеньйорити в минулому, теперішньому чи майбутньому, дякую за витрачений час на читання та бажаю постійного професійного зростання і вдосконалення.
