Ознаки досвідченого програміста — які риси та поведінка цінуються у роботі

Привіт! Мене звати Іван Довгаль. У сфері програмування я працюю близько 10 років, з них 4 — в компанії Innovecs на позиції Technical Lead. У свою першу ІТ-компанію потрапив відразу після завершення університету, хоча системним адмініструванням почав займатися й раніше. Тоді я жив у Донецьку, але вже планував переїжджати до Києва. В якийсь час я навіть змінив ІТ на шахту :), але потім повернувся. Завжди уявляв себе в комфортному офісі з гарним видом на місто. У 2014 році я таки переїхав до Києва і потрапив до сучасного офісу Innovecs, як і хотів.

За час роботи отримав досвід у сфері розробки коду, управлінні командою й проведенні технічних інтерв’ю. Сьогодні хочу розповісти про кілька важливих якостей досвідченого програміста — яким повинен бути його майндсет, особисті та професійні якості.

Стаття буде корисною інженерам-початківцям і тим, хто хоче розвиватися у напрямку Engineering Leadership, прагне росту і переходу на вищий рівень. Кандидатам буде цікаво дізнатися, чого від них очікують на технічних співбесідах і за якими критеріями відбувається «відбір» найкращих.

Про «живий мозок» програміста або Базовий набір навичок досвідченого розробника

Є різні підходи до визначення необхідного набору навичок програміста. Вимоги відрізняються залежно від компанії, проєкту й команди, з якою працюєш. Найбільш поширене визначення, яке мені імпонує: «Досвідчений» — той, хто не лише знає теорію, але успішно працює з реальними практичними завданнями, знає і вміє знаходити рішення нестандартних задач.

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

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

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

Зрозуміло, що досвідчений програміст добре володіє технологією або кількома, з якими працює. В ідеалі він знає кілька фреймворків. Але перш ніж освоювати певну технологію, програміст здобуває знання з базової архітектури систем і мереж, структури даних і алгоритмів, системного адміністрування, вивчає загалом Computer Science. Таким шляхом йдуть і сисадміни, і DevOps. Якщо йдеться про програмування як таке, то тут важливо розуміти структури даних та алгоритми, абстракції технологій, принципи OОП.

Після вивчення певної мови програміст переходить до вивчення фреймворків й бібліотек. Це вже більш високі абстракції, які об’єднують менші. Якщо ви Frontend-розробник, то йдеться про React, Angular, Vue.

Глибоке розуміння технологій і вміння знайти найкращий підхід

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

Швидкість роботи — це не завжди ознака кваліфікації Senior Engineer. Натомість робота на результат — це його невід’ємна якість. Ефективність дій, рухів важить більше, ніж кількість рядків коду і швидкість. Знайти підхід до розробки проєкту, при якому якість і швидкість у балансі під силу саме досвідченому інженеру.

Вміння враховувати «користувацький досвід»

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

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

Слідування технічному процесу

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

Треба заглиблюватися у технічну документацію — це допоможе уникнути дурних помилок і збереже ваш час та нерви Tech Lead. Ну, досвідчені це знають й інших навчають :)

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

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

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

Якісний аналіз і розробка архітектури

Щоб якісно аналізувати й розумітися в архітектурі, треба знати теорію і мати достатньо практичного досвіду. Senior Engineer вміє зробити цілісний аналіз вимог й розробити архітектуру програмного забезпечення з ефективною імплементацією на різних рівнях.

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

Вміння схематично пояснювати

Для досвідченого програміста, а особливо для Tech Lead хорошою навичкою є вміння пояснювати інформацію про принципи технології графічно за допомогою простих діаграм.

Діаграми, графіки й схеми забезпечують цілісне уявлення як про технологію, так і про проєкт. Візуалізація, системний підхід спрощує роботу усій команді. Таким чином Tech Lead передає бачення повної картини іншим.

Створення ефективного workflow

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

Або ж намагаються заохочувати інших програмістів із команди більше вчитися й аналізувати свої помилки під час code review.

Про здоровий перфекціонізм, або як писати якісний код і не вмерти на роботі

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

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

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

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

Вміння працювати в команді

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

Впевненість при виконанні складних задач

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

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

Постійне бажання розвиватися і знаходити потрібну інформацію

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

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

Вміння зберігати рівновагу

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

Досвідчений програміст знайде альтернативне рішення, зберігаючи врівноваженість. У спокої легше знайти нестандартне розв’язання задачі, аніж в емоціях.

Вміння ділитися знаннями й давати зворотній зв’язок

В ідеалі досвідчені програмісти діляться знаннями з іншими, беруть участь у вебінарах, конференціях, хакатонах. Одна справа, ділитися знаннями з книжки чи чужої теорії, інша справа — ділитися досвідом, своїми пережитими «болями». Правда, не всі люблять це робити, однак нетворкінг — штука корисна.

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

Вчасний фідбек — це про прозорість менеджменту і про ефективну комунікацію. Добре, якщо програмісти на позиції Team Lead це розуміють і практикують.

Вміння визнавати свої помилки

Ще одна хороша якість досвідченого програміста — вміння визнавати свої помилки. Хто вміє це робити, той вміє і брати відповідальність. Помилки — це можливість взяти урок й здобути цінний досвід на майбутнє. Це не означає, що Tech Lead бере на себе вину за баги когось із команди, але вміє дати корисні інсайти під час code review, підказує, як розв’язати задачу, якщо з нею стикнулися.

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

Про фейли, яких не може допускати Senior

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

Щодо вагомих технічних фейлів, то не стикався з такими, бо не часто працював з програмістами нижче рівня Senior. Звичайно, що можливі фейли Senior та Junior інженерів дуже відрізняються.

Я назвав би фейлом надсилати код в репу без прогонки тесту. Найкраще цей процес автоматизувати, як це є у нашій компанії. Ще один фейл — «костилювання» коду. Іноді виникає бажання зробити код швидко, але якщо цей прискорений процес погіршить якість, у майбутньому це все стане очевидним.

Є різні підходи до якості коду. Треба враховувати SOLID принципи. Якщо ти робиш поліморфну функцію, треба стежити, щоб вона не зламала ті місця, у яких вже використовується. Під час будь-яких виправлень коду маєш враховувати, до яких наслідків це призведе і як повпливає в цілому.

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

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

Лінь Senior — це коли ти звик до якогось процесу, і довіряєш, думаєш, ну, потім підкоригую. Часто це не завжди добре завершується, але все ж частіше завершується краще, ніж у джуніора :)

Про «симулянтів», або Як відрізнити досвідченого і недосвідченого програміста

Недосвідчених програмістів можна виявити на двох етапах: по-перше, під час співбесіди, по-друге, і щонайгірше, під час роботи, якщо пропустили «симулянта».

Питання, які допомагають мені визначити досвід програміста:

  • Скільки років досвіду?
  • А скільки з них у роботі з конкретною технологією?
  • Серія вузькоспеціалізованих питань, спрямовані на визначення глибини знань технології й фреймворку.
  • Питання про базові речі володіння мовою.

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

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

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

Загалом під час співбесід визначаємо як soft skills, так і hard skills. Технічний блок запитань відрізняється залежно від технології й проєкту.

Про ріст від Junior до Senior: поради з розвитку і росту

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

Свого часу мені допомогли курси Java Rush — там усе легко пояснювали, і ти відразу можеш практикувати. Але це все не про фронтенд.

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

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

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

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

Що більше досвіду здобуває розробник, то більше усвідомлює важливість розвитку у напрямку Engineering Leadrship. І тут йдеться не лише про тих інженерів, які вже управляють командами, але і про розробників, які завжди на хвилі трендів, вивчають нове і комплексно розвивають свої hard i soft skills, щоб ділитися своїми знаннями і вміннями з іншими.

👍ПодобаєтьсяСподобалось21
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как аксакал и таки довольно опытный скажу: херня всё это. Программист должен решать проблемы клиента, если да таки да, нет — извини. Можно и костыли писать, и без прогонки тестов в прод запускать, если чётко знаешь что делаешь и надо быстро, и с неоптимальным набором технологий работать(если так хочет заказчик), и не общаться с другими(бесплатно). Годы опыта с технологией вообще чушь. Я вот технологии spoon месяц назад вообще не знал, но работаю.

перемінну -> змінну

сферчиний кінь у ваккумі:
1- таки кінь
2 — таки сферичинй,
а ще він може розширятися

Питання, які допомагають мені визначити досвід програміста:

Серія вузькоспеціалізованих питань, спрямовані на визначення глибини знань технології й фреймворку.

Цiкаво, наприклад яких?

есть два стула проекта (ц)

Загалом скажу, що фейли Senior походять від ліні, а фейли Junior — від недосвідченості й неуважності.
Лінь Senior — це коли ти звик до якогось процесу, і довіряєш, думаєш, ну, потім підкоригую. Часто це не завжди добре завершується, але все ж частіше завершується краще, ніж у джуніора :)

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

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

А навіщо тут «стежити»? Якщо ваші зміни щось поламали, наприклад, на рівні логіки, тести відразу впадуть і це буде легко помітити.

Я назвав би фейлом надсилати код в репу без прогонки тесту. Найкраще цей процес автоматизувати, як це є у нашій компанії.

Дякую за пост, але мені ймовірність такої події здається вкрай мінімальною, тому що у всіх серйозних компаніях є налаштований CI/CD.
А ось написати новий код і не написати на нього тест — так, це косяк, який часто зустрічається. Просто він не завжди приводить до помилок, але якщо наводить, то потім ховайся хтось може ...

Оскільки ви пишете статтю для джунів, то, будь ласка, не створюйте хибне враження що перейти на вищий рівень тотожно стати лідом. Це не так в багатьох компаніях.
В аутсорсі можна стати архітектором, тим хто продає (здається звуть їх солюшн архітект, але це не точно).
В західних компаніях (можливо вже є і в локальних) можна перейти на stuff enginner, principal engineer, senior principal engineer.
Усі ці позицію можуть отримувати набагато більше ніж тім/тех ліди. Вони навіть можуть мати своїх лідів і отримувати більшу зарплатню ніж свій де лід. Навіть сіньйор може отримувати більше ніж його лід. Це нормально і правильно! Кожен виконує свою роль і має бути винагороджений відповідно до своєї користі для компанії. Тому крутий сіньйор має отримувати більше ніж його лід такий собі сіньйор але з додатковою функцією people management, яку теж виконує так собі.
Звісно може бути і так що лід дійсно найбільш скіловий, але чи не означає це що він не здатен наймати людей сильніших за себе?

Хороший спеціаліст чи ні, можна визначити лише в процесі роботи, жодне інтервʼю не дасть реальної картини.

Хороший спеціаліст визначається трьома параметрами:
1. Кваліфікація яка допоможе зробити 99% задач на типовому галерному проекті або довести і обґрунтувати чому таск робити не потрібно.
При цьому задрочувати технічними питаннями на співбесіді які гугляться менш як за 3 хвилини не варто. Варто запитати які задачі робила людина і чому обрала саме ці рішення. Все. При цьому це буде релевантно як для техліда так і для джуніора.

2. Не бикує ні до колег ні до менеджменту ні тим паче до замовника, може підтримати елементарний small talk на кухні на 5 хв.

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

Все решта балабольство і від лукавого.

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

це можна сформулювати по іншому:
якщо запрягся, то тягне лямку, може, глибоко не спаше, але борозду не спортить

Я Вася, вже 10 років працюю в компанії Х, ЗП в мене менше середнього по доу зате я лід/скрам мастер/менеджер. На нормальну зп 7к+$ я пройти не можу, працювати нормально не вмію тому напишу статю як мають працювати інші.

По хард скілах — працювати треба добре, погано працювати не треба.

По софт скілах — кілька А4 «за все добре проти всього поганого». Дякую джуніор техрайтеру за допомогу (а ні, не буду її вказувати)

По співбесідах — для хард скілів компанія дає список питань з відповідями, я по них проходжусь. Задачки (і практичні таски) не даю бо сам не шарю. 80% ми говоримо про софт скіли і як важливо мати тести на проекті.

По розвитку — є курси і сетрифікації. Жодну не здав але дивився відосіки скачані через торрент. Компанія пообіцяла +100$ за гугл сертифікацію тому я здав дуже рідкісну Associate Gmail User з першого!11 разу.

П.С. тепер для промоушинів/+100$ в Innovecs треба статтю на доу написати?

Очевидно що над даним постом працював перфекціоніст. Усе чітко, зрозуміло, з розділовими знаками, структуровано, без зайвих смислових ускладнень і т.д. Дякую, такі пости приємно читати.

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

Може я чогось невірно зрозумів, але для мене це виглядає як призов до демократії на проекті. На мій погляд, такого бути не повинно. Так само не повинно бути й монархії, коли умовно найбільш досвідчений вирішує все сам. Як на мене, добре працює лише науковий підхід.
Тобто при обранні технології варто проаналізувати з різних точок зору, як її використання вплине на проект на великій дистанції, оцінити всі плюси і мінуси і тоді вже приймати рішення.
Наприклад, я неодноразово стикався з тим, що команда обирає підхід, який базується на широкому використанні raw SQL при роботі з БД замість вивчення і використання можливостей тієї чи іншої ORM. Підхід зазвичай аргументується тим, що «ORM не взмозі формувати досить ефективні запити» (що може бути правдою для окремих специфічних випадків), або тим, що «SQL всі знають краще за особливості ORM, тому розробка буде ефективнішою» (команді складно працювати з ORM). На практиці, у порівнянні з підходом code first, на середніх і великих проектах це завжди призводить до уповільнення розробки на довгих проміжках часу і зниження якості коду і рішення в цілому.
Бо у такому разі співпадіння структури БД і об’єктів, які відображають її в застосунку, а також запитів, які формує застосунок до БД, вже не контролюється компілятором. Це робить будь-які, навіть найменші зміни структури БД занадто коштовними і призводить до збільшення вірогідності runtime errors. Врешті решт будь-який рефакторинг, який хоч трохи чіпає структуру БД стає занадто дорогим і ризикованим, якість коду падає, темп розробки уповільнюється, мотивація команди знищується.
Тому — тільки науковий підхід з аналізом впливу кожного рішення з усіх боків. Будь-яка поверхнева аргументація без глибокого аналізу при обрання технології та/або підходу є суто небезпечною.

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

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

Це не означає, що Tech Lead бере на себе вину за баги когось із команди, але вміє дати корисні інсайти під час code review, підказує, як розв’язати задачу, якщо з нею стикнулися.

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

Треба враховувати SOLID принципи.

Вибачте, не зміг утриматись. Хтось може пояснити, як використовується принцип Лісовскі в Golang або JS?

Загалом скажу, що фейли Senior походять від ліні, а фейли Junior — від недосвідченості й неуважності.

Контраверсійно, як на мене. Тобто якщо я належав через те, що чогось не помітив (неуважність), то вже все, час «разжаловать» в джуни?

Скільки років досвіду?
А скільки з них у роботі з конкретною технологією?

Завжди ненавидів такі питання. Скільки років в мене досвіду з SQL? Можна сказати, що приблизно 6, якщо враховувати тільки роки, коли я кожного дня писав код на ньому. Або можна сказати, що 25+, бо я майже завжди ним користуюся, так чи інакше. Яка відповідь вірна? Жодна.
Доречі, співбесіда без хоча б 15 хвилин live coding — погана співбесіда. Це як наймати водія, не переконавшись, що він взмозі завести автівку.

але коли поставиш елементарні питання з цього списку, він не може відповісти

Нещодавно, мене зрізали на співбесіди питанням, чим в C# в блоці catch, throw; відрізняється від throw ex;. Я не памя’тав відповідь, але після співбесіди нагуглив її на дві хвилини. Здатність/нездатність відповідати на питання RTFM не каже НІ ПРО ЩО. Перевірка пам’яті.

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

Доречі, дякую за статтю. Допомогла дещо згадати та зайвий раз систематизувати.

На моє глибоке переконання, навіть найкращі інтерв’юери помиляються десь у половині випадків. Для цього і існує trial period

100%

Нещодавно, мене зрізали на співбесіди питанням, чим в C# в блоці catch, throw; відрізняється від throw ex;. Я не памя’тав відповідь, але після співбесіди нагуглив її на дві хвилини. Здатність/нездатність відповідати на питання RTFM не каже НІ ПРО ЩО. Перевірка пам’яті.

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

Якщо зовсім чесно, останнім часом я взагалі не впевнений, чи варто на співбесіді питати RTFM. Якщо мене питають тільки RTFM протягом 10 хвилин або більше, я починаю відчувати нестерпну нудоту і бажання працювати з тією людиною в мене миттєво випаровується. RTFM завжди можна нагуглити, принаймні якщо є розуміння картини з висоти пташиного політу. Набагато цікавіше з’ясувати як людина мислить. Як підходить до вирішення нетривіальних проблем. На що звертає увагу, як підходить до пошуку рішення, наскільки ефективно здатна мислити out of the box, чи все в неї гаразд з логічним мисленням, наскільки швидко та точно вона здатна сприймати нову інформацію та користуватися нею, чи достатньо розвинено критичне мислення. Все, що можна зробити просто прочитавши простий мануал, може зробити навіть мавпа. :)
Тобто мабуть можна спитати пару простих речей RTFM щоб перевірити, що людина не бреше в CV і дійсно працювала з тією чи іншою технологією. Але захоплюватися цим точно не варто. :)

Мені чисто для статистики стало цікаво. Ви самі писали статтю українською, чи це вам хтось її переклав?

Були. Не зміг швидко та впевнено розповісти про SOLID. Недостатньо спав вночі, бо кацапи не давали. І взагалі в мене це запитання викликає нудоту та відразу. Зустрічав людей, які відповідають на це запитання дуже швидко і впевнено (видно, що вчили), але коли доходить до роботи з кодом, виявляється, що всі ці «знання» ні до чого не прив’язані. ;)
Невміння швидко без гугла відповісти на запитання — це не прокол. Це може бути пов’язано з поточним станом і не каже ні про що. Прокол — це бага, яка йде на продакшн і яку після виявлення не вдається пофіксити протягом години-двох.

А як знати під час роботи коли саме це нагуглити?

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

Наприклад, я неодноразово стикався з тим, що команда обирає підхід, який базується на широкому використанні raw SQL при роботі з БД замість вивчення і використання можливостей тієї чи іншої ORM. Підхід зазвичай аргументується тим, що «ORM не взмозі формувати досить ефективні запити» (що може бути правдою для окремих специфічних випадків)
...
у такому разі співпадіння структури БД і об’єктів, які відображають її в застосунку, а також запитів, які формує застосунок до БД, вже не контролюється компілятором. Це робить будь-які, навіть найменші зміни структури БД занадто коштовними і призводить до збільшення вірогідності runtime errors. Врешті решт будь-який рефакторинг, який хоч трохи чіпає структуру БД стає занадто дорогим і ризикованим, якість коду падає, темп розробки уповільнюється, мотивація команди знищується.

Мені здається що ORM краще використовувати у самих простих запитах, де немає джоїнів. В противному разі, справді, потрібно дуже добре знати ORM. А такі знання є вже менш потужними, у порівнянні зі знаннями raw SQL.

Щоб не було розсинхронізації між об’єктами в застосунку і таблицями в базі даних, ясно що треба використовувати у сервісах для бази даних якісь типи з дженеріками. Це звісно не 100% прибирає цю проблему, але навіть ORM це не завжди гарантує.

Мені здається що ORM краще використовувати у самих простих запитах, де немає джоїнів.

А вивчити LINQ, наприклад, що заважає? Він не складніший за SQL. Ну, хіба що трохи. Зате, перевіряється компілятором.

Це звісно не 100% прибирає цю проблему, але навіть ORM це не завжди гарантує.

Якраз використання ORM, принаймні, якщо вона підтримує code first, на сто відсотків гарантує синхронізацію структури бази та коду застосунку. Звісно, якщо використовувати його як слід, і не намагатися одночасно змінювати структуру БД іншими засобами.

Доречі, співбесіда без хоча б 15 хвилин live coding — погана співбесіда. Це як наймати водія, не переконавшись, що він взмозі завести автівку.

не пройшов жодного лайфкодінг інтерв"ю, мабуть не вмію водити,
з.і. 15+++ років в ойті... але то таке

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

ти правий 146%,
відповідь настільки точна, наскільки безглузда,
тільки яким боком лайфкоднінг до абіди?

А яким чином те, що я написав про співбесіду стосується того, що ти ніби-то «не вмієш водити»? Зазвичай, якщо людина робить елементарну логічну помилку, для цього може бути три причини:

1. Людина не здатна в логіку взагалі
2. Людиною володіють сильні емоції, які заважають логічному мисленню.
3. Людина свідомо маніпулює.

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

Сбацай чьо-нибудь... Мурку
www.youtube.com/watch?v=fYvLiJEqT0I

що співбесіда без лайфкодінгу не є гарною,

«піво бєз водкі — дєнгі на вєтєр»

ажно ніяк не випливає,

що випливає? догма що лайфкодінг мастхев?

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

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

Будь-яке судження, яке містить в собі епітети типу «поганий» або «гарний» є оцінювальним, тобто суб’єктивним. Якщо комусь це треба доводити, ну ОК. Можна це робити. Але логіки в цьому я все одно не бачу. :)

Доречі, співбесіда без хоча б 15 хвилин live coding — погана співбесіда.

dou.ua/...​rums/topic/38289/#2409208

Вибачте, не зміг утриматись. Хтось може пояснити, як використовується принцип Лісовскі в Golang або JS?

а якщо дивитися на принцип ширшєє, не влазячи в прокрустове ложе специфічної МП?

Нещодавно, мене зрізали на співбесіди питанням, чим в C# в блоці catch, throw; відрізняється від throw ex;. Я не памя’тав відповідь, але після співбесіди нагуглив її на дві хвилини. Здатність/нездатність відповідати на питання RTFM не каже НІ ПРО ЩО. Перевірка пам’яті.

після бою кулаками не машуть,
а от якби був лайфкодінг...

Нещодавно, мене зрізали на співбесіди питанням, чим в C# в блоці catch, throw; відрізняється від throw ex;. Я не памя’тав відповідь, але після співбесіди нагуглив її на дві
хвилини

Это базовый классический вопрос для дотнетчика джуна, просто проверка насколько часто ты работал с экзепшнами, если достаточно часто, то с вероятностью 99% ты сталкивался с дилеммой надо или нет прокидывать callstack выше.
Это не про memorize, а про сколько осознанного кода написал.

Ну, якщо прийняти за істину, що єдине, що треба усвідомлювати, коли пишеш код — це правильний спосіб перезапуску виняткових ситуацій, тоді в цьому можливо навіть є сенс. ;) Але я зараз спеціально передивився один із своїх попередніх проектів і з’ясував, що там на цілий проект всього 3 (прописом три) випадки re-throw. В проекті десятки тисяч строчок коду. А якщо враховувати autogenerated — майже півтора мільони. Я не знаю, можливо джуну обов’язково треба пам’ятати такі речі. Я завжди таке гуглив. :D

Хз как там в c#, в с++ вообще не вспомню, чтоб за 8 лет работы была необходимости снова бросать исключение из catch блока.

Такие варианты случаются. И о возможности «rethrow» нужно помнить. Но как конкретно, в конкретном ЯП — это уже нужно гуглить.

Зазвичай робиться коли треба записати виключення в log. Після цього цілком логічно кинути його ще раз. Але, це дійсно не так вже часто доводиться робити. Цілком вірогідно, що за кілька років роботи розробником цього робити не доведеться жодного разу, або доведеться раз чи два. :)

Читати легко, але масло масляне. Нічого про тайм менеджмент, про мотивацію команди.

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

Автор неграмотний і російськомовний.
Статтю писала компанія)

Піар стаття на замовлення «маркетингового» відділу компанії Innovecs.
Вміння відкосити від подібних прохань написання статей і іншої «дурної» роботи — теж один з хайлевел скілів досвідченого програміста.

Може когось найняв? Стаття наче профі райтером написана.

Мені просто важко увити, як можна накатити таку сканертину тексту «на прохання». Сподіваюся тільки, що автору не довелрся овертаймити для її написання.

Підписатись на коментарі