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

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

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

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

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

Точно, Геннадію!
Ви абсолютно праві і це інший аргумент, чому за 5 інтерв’ю найм можна заврешувати. Якщо вам на інтерв’ю рекрутери «постачають» не тих кандидатів, то тим паче нема сенсу витрачати ваш та їх час і перебирати людей з непідходящої когорти. Скоріше за все треба передивитись свій підхід (яку людину шукаємо, яку вакансію даємо, де даємо, як даємо, скільки платимо і т.д.). 5 інтерв’ю, то ще доволі консервативно. Зачасту наймаючий менеджер може зекономити собі час, глянувши на профілі кандидатів в пайплайні і визначитись чи воронка найму буде видавати йому потрібних кандидатів.
При цьому дуже розповсюджений інший кейс: «а от в минулій компанії я працював з людиною яка за зарплатню $1000 стільки всього вміла робити, а ці кандидати якісь нетямущі» або ще більш ймовірне «в нашій команді всі вміють робити і от це і от так, а ці кандидати не вміють, ну як ми їх можемо взяти», тобто порівнюють існуючих співробітників, пройшовших онбординг і адаптацію в компанії і проекті з кандидатами з ринку, які не мають контексту, або бракують певних знань, що можна опанувати за тижні, максимум місяці.

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

Як каже неповторний Сергій Немчинський «якщо ви знаєте 30% від того, що ви робиться на проекті, ви знаєте забагато і вам потрібно міняти роботу»

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

Також варто враховувати, як побудований загальний пайплайн найму. Якщо ви не визначились після 5 співбесід хоча б одним потецнійним офером, то щось не так докорінно або в самій вакансії, або вимогах, або вашому розумінні, хто вам потрібен.
Вважаю, що все ще є позиції на ринку, де можна позвати знайомого і він буде перформити. Більш того, велика частина джунівських позицій саме так і повинна заповнюватись.
Звичайно, чим вище позиція, тим більше вимоги до інтервю, аж до моменту, як правильно було сказано, що ви не в змозі оцінити професіоналізм кандидата.
Ну і звичайно умови ринку також впливають на процес найму, іноді можна вихопити дійсно класних спеців за відносно помірні кошти, іноді треба наймати з тих, хто є і не дивитись «а от у 2018 були кандидати, ото кандидати».

Варто також зазначити такий момент. Загалом найняти треба спеціаліста, найкращого з наявних за умов, що він відповідає мінімальним, ні, не так, МІНІМАЛЬНИМ вимогам на проекті. Інший підхід можливий лише, якщо ви готові платити максимальну ціну на ринку (а здебільшого її платити не готові).

Стаття гарна, але в чому користь для кандидатів?

Памятаю років 20 тому читав якусь наукова фантастику, чи то Філіппа Діка, чи когось іншого, цифрове суспільство і все таке. І памятаю, що там найбільшою образою в мережі було, якщо хтось приймав людину за бота. А от тут, дивлячись на ваші відповіді, Олексію, згадалось — а ви часом не бот (або використовуєте LLM для відповідей на коментарі)? Бо виглядає це все дуже крінжово.
Щодо статті: Для кандидатів, особливо новачків, і без досвіду — це класно пройти по всіх питаннях і побачити свої білі плями. Що цікаво, для того, щоб отримати роботу, точно не треба знати відповіді на всі з них. Думаю, чо десь на рівні 60-70% вже буде суттєво вирізняти вас серед інших.
Для наймаючих менеджерів — питання яки починаються з «що» можна точно викидувати (тільки якщо «що» не стоїть на початку питання «що ви будете робити, якщо ...». Більш доречними будуть питання «Як» і практичні ситуативні питання наприкінці статті.
Погоджусь з тим, що кожен має знати віповіді на більшсть з цих питань, але в досить стислий час 60-90 хвилин, який відводиться на переважну більшість інтерв’ю чути від кандидата визначення сталих термінів ну зовсім не хочеться. До таких питань можна звернутись, якщо раптом ви розумієте, що контекст ваш і кандидиата щодо певної ситуації відрізняється, тоді можна і пройтись по питаннях «що так регресійне тестування».
Але як список — дуже корисний (хоча здається на dou вже такі статті були)

Дякую, якщо знайшли коментар корисним.
Щодо англійської — звичайно знання мови можна покращувати постійно, питання. Чи це гарна інвестиція часу у порівнянні з іншими навичками. І тут перед нами стоїть law of diminishing returns. Умовно кажучи, вище C1 все менша користь буде видна в порівнянні за витраченим часом (особливо за умов наявності сучасних LLM інструментів які допомагають з письмом). І наприклад, замість того щоб покращувати свою англійську, краще було б оволодіти public speaking, negotiations або, ще однією мовою програмування, або ще одною іноземною мовою.
Тому мій коментар був саме стосовно цього — якщо англійська абсолютно не обмежує вас в роботі (ви вільно спілкуєтесь з колегами/замовником письмово і усно) то скоріше за все є більш пріоритетні задачі (якщо у вас не лінгвістичний проект, накшталт Grammarly)

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

Нижче трохи критики (сподіваюсь, що конструктивної) і коментарів:
— Чим вам не подобається слово «скіл», якщо по тексту застовоуються «тул», «скоуп», «естімейт», «сорі», «геп»?

— Назва розділу «Автоматизоване тестування» не досить влучно відображає його зміст. Скоріше ви розмовляєте про «доречність автоматизованого тестування» або " ROI AT«.

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

— Було б добре, якщо на кожну з вказаних навичок ви порекомендували б книжку або курс.

— про взаємодію сеньора і менеджера

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

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

— про автоматизацію

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

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

— Гарно зазначили, що автоматизація полягає не тільки в написанні автотестів, але й автоматизації повсякденних процесів і задач. Автоматизація комунікації в Slack, роботи з Google Suite, Jira та іншими популярними інструментами — ключ до підвищення ефективності праці QA взагалі і Senior зокрема. Досить часто складається ситуація, коли інженери ігнорують можливостi API-інтеграції вказаних систем між собою та власне з тестувальними фреймворками.

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

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

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

— Міф про мавп банан і воду нажаль не знаю.

— Наприкінці дуже добре, що ви показали, як вирощувати сеньора на прикладі того, як це робиться в Global Logic. Але якщо, людина не проявляє ініціативи? А якщо вона не знає куди рухатись, і навіть не знає кому задати питання? А якщо в потенційного сеньора нема тімліда взагалі? Що робити в таких кейсах? Зі статті не зрозуміло.

Дякую вам за статтю і гарного вам дня!

.

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

Але я впевнений, що щодо роботи, то рівень знань мови цілком може бути на рівні upper-intermediate — advanced у більшості IT працівників. Власне, словник для повсякденного мітингу навряд чи перевищує 3-5 тис. слів, конструкції і речові оберти сталі, тому для роботодавція і колег — ви advanced, оскільки спілкуєтесь по роботі на рівні advanced. І насправді здати англійську мову на рівні Advanced за тим же CEFR не так вже і складно.

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

Про вищу освіту інформація виглядає нерелевантною. Оскільки суттєва частка з тих 96% має НЕпрофільну вищу освіту. Тож не думаю, що цей розділ зробив правильний висновок, і це — must have. По відчуттях як раз навпаки. В моїй компанії спеціалісти з профільною вищою освітою — це меншість. Тому я б сказав що вища освіта — whatever

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

гарний жарт :) це цілі індустрії. Наприклад банківський домен

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

Та хрін його знає, понавидумували усіляких там GDRP, HIPAA, PCI-DSS і чіпляються потім. Є й такі клієнти, що в офіс приходять і дивляться чи у вас на столі чисто, не те що б там код до LLM-ки відправити.

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

Як ваш Information Security ставиться до того, що робочий код відправляється в OpenAI? Чи знають про такі практики ваші клієнти?

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

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

Стаття буде корисна для розробників, вийшло у вас досить непогано. Але, щоб була взагалі цукерка, я б:
1. Щось зробив би з назвою, бо та що зараз — максимально неконкретна
2. Надав би причину, чому треба читати цю статтю — чому саме розробники повинні знати про тестування
3. Дав би вичитати статтю вашому знайомому QA — є невірно розставлені акценти (наприклад, чому саме unit-тестів багато) та трохи впадають в око неточності в термінології (наприклад, unit та component тести — це одні і ті ж самі тести, як і system та е2е).