Вважається, що співбесіди призначені для вибору відповідних кандидатів на посаду. Відповідно, технічні співбесіди, ймовірно, потрібні для оцінки кандидатів на технічні ролі.
Проблема, як на мене, полягає в тому, що технічні співбесіди часто створюють хибний сигнал. Хоча потенційно вони можуть дати уявлення про технічні навички, на мою думку, частіше вони створюють хибнонегативні спрацьовування.
Я вважаю, що це має бути важливо для вас, адже ви, ймовірно, відсіюєте кандидатів, які могли б краще відповідати вашим вимогам. Кандидатів, які відповідають реальній посаді та повсякденній роботі на ній. До того ж ви, ймовірно, даремно витрачаєте на це зайві ресурси (час і зусилля).
Так думаю не лише я: кілька років тому Університет штату Північна Кароліна спільно з компанією Microsoft дійшли таких самих висновків: «Співбесіди в технологічному секторі оцінюють рівень стресу, а не навички розробки ПЗ».
У цьому пості я постараюся детально розповісти про свій погляд на технічні співбесіди. Про те, в чому, на мою думку, їхня реальна цінність і застосовність. Сподіваюся, до кінця статті ви зрозумієте, ому на посаді менеджера з найму я вирішив скористатися альтернативним підходом.
Мушу зізнатися: я жахливо справляюся з технічними співбесідами.
Для початку трохи контексту. Я працюю розробником ПЗ вже трохи більше сімнадцяти років. В організаціях, де мені довелося працювати, я створював проєкти високого рівня і займався їх керівництвом. В основному ж моя технічна робота полягає у міжкомандній взаємодії на рівні управління.
Ще важливо знати, що я також був менеджером з найму і успішно проводив раунди найму джуніорів, мідлів, сеньйорів та керівного персоналу.
Примітка: я не працював у найбільших організаціях. Великі масштаби проєктів відносні до розміру організації, де я працював. Тому мушу визнати, що масштаб і вплив інженера-управлінця в компанії з 800 осіб сильно відрізняється від масштабів у компанії з десяти тисяч людей. Тим не менш, я вважаю, що загалом представлені в статті твердження зберігають свою істинність, тому що в кінцевому підсумку проблема не в інструменті, а в тому, як його застосовують.
Ви можете запитати у будь-якої команди, в якій я був або якою керував, у будь-якого інженера, з яким я працював, або у будь-якого мого керівника: усі вони скажуть, що мої технічні знання ширші, ніж сказано в статті. (А потім вони, ймовірно, поспівчувають мені через синдром самозванця.)
Отже, якщо я так погано проходжу технічні співбесіди, то я, ймовірно, обманув усі організації та всіх людей, з якими працював?
Це дуже малоймовірно.
То чому ж я так погано проявляв себе на технічних співбесідах? Так, звісно, я відчуваю стрес, але це не пояснює, чому я так сильно на них провалююсь.
І перш ніж ви подумаєте, що я просто занадто суворий до себе, додам: коли я кажу, що показую погані результати, це не означає, що вони трохи гірші за ідеальні. Ні, я роблю найпростіші помилки, мимрю і іноді навіть повністю “зависаю”. Тобто я просто перестаю рухатися далі, без кінця вибачаюся і жахливо потію.
Як таке можливо? Чому ж при цьому на кожній посаді мої керівники казали, що я чудово справляюся з роботою? Чому я так погано проявляю себе на співбесідах і тим не менш мене постійно підвищують?
Давайте спробуємо відповісти на це запитання.
Я думаю, що настільки жахливо проявляю себе через дві взаємопов’язані причини. Ймовірно, до однієї з них варто поставитися серйозніше.
Перша і менш важлива причина полягає в тому, що мої навички не виключно технічні. Я не та людина, яка вирішує задачі лише заради їх вирішення. Я вирішую задачі для своєї команди, наших клієнтів (внутрішніх або зовнішніх) і/або для організації.
Для того, щоб справлятися зі своєю роботою, я накопичую контекст і розуміння задачі, що вирішується.
Причиною розвитку багатьох великих проєктів, якими я займався протягом багатьох років, були спостереження і висновки, отримані мною після того, як я зрозумів обмеження організації, технології та підтримуючої це все команди.
Так, я використовував для вирішення технологію X, алгоритми Y або навіть структури даних Z. Але все це з’являлося в ході справи. У мене ніколи не було такої ситуації, і я ніколи не чув про такі ситуації, щоб комусь у реальності доводилося реалізовувати рішення з префіксного дерева і пошуку за O(n) в рамках тридцяти хвилин.
Насправді, мені постійно доводиться стикатися з наступними задачами:
Як бачите, мої здібності щодо внесення вкладу в роботу залежать не лише від чисто технічних знань. Алгоритми, структури даних і масштабована архітектура — це лише деякі з інструментів і патернів, які ми використовуємо для виконання роботи.
Тому я приходив у кожну з компаній, практично нічого не знаючи про простір її задач, а потім швидко ставав фахівцем у тій чи іншій предметній області. Кожного разу я використовував лише небагато з того, що знав з попередньої компанії, тому що кожен новий простір був іншим і мав багато нюансів.
Але ж роки досвіду і навички повинні ж мені допомогти справлятися з якимись простими технічними завданнями, чи не так?
Ну… і так, і ні. Давайте поговоримо про другу проблему, щоб розібратися, чому все не так просто.
Найчастіше зустрічаються такі типи технічних співбесід:
Тут важливо зазначити, що багато організацій підкреслюють, що головне — це не остаточна відповідь. Замість неї оцінюється те, як кандидат працює і комунікує.
Все це звучить чудово, але досить очевидно, що більшість тих, хто проводить співбесіду, відхилять кандидата, який не виконав завдання. Ситуація стає ще гіршою, якщо кандидат ніколи не стикався з даною йому задачею — це може загальмувати його і призвести до провалу на співбесіді.
Хтось може сказати, що хороший кандидат буде мати наполегливість і подолає цю перешкоду, тому що саме цим йому і доведеться займатися в повсякденній роботі. Теоретично я можу погодитися: наполегливість і сміливість необхідні в розробці. Тільки оцінювати їх потрібно не так.
Мені здається, подібне “випробування вогнем” має сенс, якщо ваша організація — одна з тих, де розробники знаходяться під постійним тиском і де підтримується культура “зроби або помри”. Якщо ж це не так, то подумайте про різницю між відповідями на питання вікторини з друзями і відповідями на ті ж питання в умовах змагання з іншими учасниками в прямому ефірі ігрового телешоу. А, так, і приз за гру — це ваша посада.
Саме тут моя тривожність починає зашкалювати. Я можу і знати всі відповіді, але в подібних умовах згадати їх виявляється не так просто. Згадайте ті відео, де учасники телешоу давали найдурніші відповіді в умовах тикаючого таймера. Це якраз я. Я часто реалізую погане рішення і усвідомлюю це рівно в ту хвилину, коли співбесіда вже закінчена.
Також потрібно врахувати і ще один аспект. Як щодо різниці між кандидатами, які вже зустрічали цю задачу вікторини, і тими, хто ще її не зустрічав? Якщо сенс не просто у виконанні задачі і ви хочете оцінити лише їх навик вирішення задач, то чи не оціните ви швидше того, хто швидко вирішив її, ніж того, хто вирішив її з труднощами? Це означає, що у вас виникає перекіс у бік того, хто ВИПАДКОВО мав справу з цією задачею (або запам’ятав її). Більш того, з великою ймовірністю це не дасть вам ніяких якісних даних про придатність кандидата до роботи.
Але як говорилося вище, тривожність і досвід (або його відсутність) — не єдині причини поганого прояву моїх навичок.
Давайте розглянемо, який сигнал організації можуть отримати від цих співбесід.
На мій погляд, практично ніякого корисного.
Пошукавши онлайн, ви знайдете купу книг, відео, платних курсів і так далі для підготовки до таких співбесід. Усі вони підштовхують людей навчатися місяцями, проробляючи задачки і запам’ятовуючи їх рішення. Це стало схоже на підготовку до іспитів у виші. Це означає, що є висока ймовірність того, що за замовчуванням подібні типи співбесід насправді дають фору певному типу кандидатів.
Припустимо, люди запам’ятовують все це, але ж у цьому немає нічого особливо поганого? Згоден, само по собі це непогано. Знання — це чудово! Завжди варто прагнути отримувати їх.
Однак мета співбесід — оцінити кандидатів на відповідність посаді. Посаді, на якій вони будуть досягати результатів, а не вирішувати окрему граничну частину задачі цієї посади.
Примітка: часто я задаюся питанням, чи не тому організації виявляються такими надмірно ускладненими системами, коли достатньо було б більш простих. Якщо ті, хто потрапляє на посади, мають сильний стимул в основному робити упор на дрібні деталі, то, ймовірно, вони з більшою ймовірністю будуть реалізовувати складність, не замислюючись про її необхідність і те, чи зможуть команди/організації підтримувати такі системи.
Я читав про компанії і працював у таких організаціях, які роздають підготовчі матеріали до своїх співбесід. Як же так? Хіба багатьох років досвіду недостатньо для підготовки? Я готуюся до посади чи до самої співбесіди? Навіщо мені потрібна спеціальна підготовка… до співбесіди? Можливо, варто задатися питанням, а чи не оцінюємо ми щось не те?
Перш ніж рухатися далі, я б хотів розвіяти основну ідею, яку компанії закладають у ці співбесіди: ідею, що подібні типи співбесід нібито є симуляцією реального світу/роботи.
У реальній ситуації істинні багато з цих пунктів, якщо не всі з них:
І, що найважливіше: над якими такими задачами люди працюють, щоб від них очікували рішення за 30-40 хвилин (з урахуванням вступної частини і підготовки)? Виправлення опечаток? Можливо, виконання аналізу першопричин ось у такому коді?
should_crash_system = True
if should_crash_system:
crash_system()
У реальному світі у розробників є час на обдумування задачі, її проробку, а потім удосконалення рішення. Це чимось схоже на написання текстів. Ви створюєте приблизний план, редагуєте і вдосконалюєте чернетки, а потім поліруєте текст перед публікацією. Розробники зазвичай випускають удосконалену версію, а не заготовку “аби запрацювало”. Винятком може бути парне програмування або метод каченяти, коли процес більше стає груповим.
Умови співбесіди не дають ні цього простору, ні часу, ні, будемо реалістами, безпеки.
Аналогічно, високорівневі аспекти або типи елементів, що обговорюються на співбесідах про проєктування систем, завжди вимагають більше простору і часу.
Так, іноді буває так, що ви приходите на нараду керівників і з ходу повинні відповісти на новий запит. Я бував на багатьох таких нарадах з директорами, віцепрезидентами і навіть з вищим керівництвом. І мені ніколи не доводилося видавати план або щось більше, ніж можливе “так”/“ні”, приблизні терміни (X місяців) або оцінка складності, ну і, може бути, груба оцінка вимог до команди (X інженерів). На таких нарадах ми говоримо і спілкуємося максимум по п’ять хвилин.
Аналогічно, на сесії визначення масштабу/планування з продуктовою і дизайнерською командами ви можете задати приблизні терміни, але потім виділити час для більш ретельного дослідження і планування. Тобто в кінцевому підсумку ви скажете щось типу “думаю, ми зможемо це зробити за один-два спринти двома розробниками. Давайте створимо спайк-таск, щоб вивчити варіанти, уточнити ресурси і графік”.
Можливо, в деяких організаціях люди отримують запити виду “слухай, можеш спроєктувати систему, для створення сучасної реалізації якої знадобилося п’ятнадцять років, і яку створила одна з найталановитіших компаній у нашій галузі? При цьому ти повинен врахувати всі вирішені нею проблеми і ті, які належить вирішити. І ще — ця архітектура мені потрібна через 50, хоча ні, через 49 хвилин”.
Гаразд, з цим ми розібралися, давайте повернемося до розбору різних типів співбесід.
Оцінка кодування
Як говорилося вище, розробники не так часто стикаються із завданнями по структурах даних і алгоритмах, щоб запам’ятати їх. І не дуже часто їх потрібно використовувати тут і зараз. Найздібніші розробники розуміють концепції, плюси і мінуси, але не запам’ятовують сам синтаксис або структуру. Тобто, вони, швидше за все, можуть розповісти про структуру, але спосіб її реалізації їм уже доведеться шукати.
Є ймовірність, що на своїй посаді ви не стикаєтеся з цим регулярно. Тому подібні задачі на співбесідах хороші, якщо ви хочете знайти людину на посаду, де алгоритми і структури даних є критично важливим знанням. Наприклад, це може бути ключовий член команди, який працює з глибокими питаннями продуктивності при створенні якогось складного движка або великомасштабного рішення. Така посада, кандидат на яку насправді буде регулярно (50%+ часу?) глибоко аналізувати, реалізовувати і створювати структури даних/алгоритми. Але якщо це так, то вам, мабуть, варто провести цілий набір перевірок, а не лише одну.
Інша ситуація, в якій можуть використовуватися подібні типи співбесід — це відбір щойно випущених студентів (коледжів або буткемпів), а також позиції стажера/джуна/міда нижнього рівня. Причина в тому, що в цьому випадку ні за що інше практично неможливо зачепитися. Від кандидатів на такі посади очікується майже повна відсутність досвіду, тому необхідно проводити певну перевірку знань.
Розробка додатка
Проблема з задачами на розробку додатка полягає в тому, що часто вони починаються з чистого листа. У реальній же роботі розробники зазвичай не витрачають свій день на створення проєкту повністю. Крім того, деяким трохи складно зацікавитися завданням, що не має практично ніякої цінності. Розробників часто захоплює вирішення задач або реліз для якоїсь кінцевої сторони (команди/організації/користувачів і так далі). Однак у цьому випадку і той, хто проводить співбесіду, і той, кого співбесідують, знають, що це робота на викид. Найгірші в світі умови для хакатону!
Тим не менш, у таких співбесід теж є свій спосіб застосування. Такі задачі на написання додатків, ймовірно, хороші, якщо ви наймаєте розробників для прототипування/проєктів R&D. Це посади, на яких розробники повинні регулярно доводити проєкти з 0 до 1. Важливо уточнити, що я не маю на увазі стартапи. Стартап з більшою ймовірністю випустить додаток один раз, а не через кожен спринт.
Також потенціал для задач на створення додатків може знайтися в аутсорсингових компаніях. Там кандидати теж повинні регулярно випускати проєкти з нуля. Однак я мав досвід управління аутсорсинговою компанією і знаю, що в ідеалі розробники використовують певний початковий шаблон.
Проєктування систем
Співбесіди з проєктування систем цікаві головним чином тим, що, на мою думку, це спроба усунути деякі недоліки інших типів задач. На них розмова ведеться в більш концептуальному просторі з більшим упором на комунікації, міркування і вирішення задач.
Однак, по суті, ми говоримо про проєктування архітектури систем. У наявності архітектурних навичок, звісно, немає нічого поганого. Але сьогодні практично в будь-якому циклі співбесід є раунд того чи іншого проєктування систем. Ми що, дійсно очікуємо, що ВСІ будуть архітекторами? Крім того, більшість задач на співбесідах з проєктування систем пов’язані з фулстек-задачами, що мають великий масштаб. Не зрозумійте мене неправильно, я сам хочу, щоб навіть мід-розробники думали про те, як їхні зміни можуть вплинути на продуктивність, стабільність, масштабованість і розширюваність системи. Однак, судячи з цієї тенденції проведення співбесід, ми тепер стверджуємо, що кожен член команди повинен уміти вирішувати архітектурні проблеми фулстека, і це настільки важливо, що за цим критерієм потрібно відсіювати кандидатів?
На мій погляд, подібні типи співбесід повинні застосовуватися для посад високорівневих розробників. Таких посад, від яких очікується регулярна робота з подібними питаннями. У деяких організаціях є окрема посада архітектора. Ідеально! Інші переносять його обов’язки на провідного інженера. Теж непогано! Інженери-управлінці теж ідеально підходять для такого формату, враховуючи, що міжкомандні взаємодії повинні враховувати систему в цілому.
Можу сказати навіть більше: цей тип співбесід може застосовуватися і для найму сеньйорів. Однак він не повинен бути основним фактором їхнього вибору. Чому? Тому що можна цілком упевнено сказати, що якщо ти реалізуєш великомасштабні високорівневі системи, то ти вже знаходишся вище посади сеньйора.
Упевнений, що останній абзац може викликати нерозуміння. Спробую пояснити.
Для початку згадаємо, що ми обговорюємо співбесіди. Також варто пам’ятати, що я можу пошукати інформацію про те, як компанія Y створила великомасштабну систему. Я можу запам’ятати принцип і повторити його вам. Це справедливо для будь-якого випускника або того, хто щойно складав іспити.
Тим не менш, навіть якщо випускник медичного знає процедуру, це ще не робить його лікарем. Йому все одно потрібен особистий досвід. Він повинен зіткнутися з ситуаціями з реального світу.
Або, можливо, ви вважаєте, що відмінно склавший іспит випускник готовий стати провідним інженером? І навпаки: якщо співробітник рівня L7 великої технологічної компанії не пам’ятає другого параметра в функції map, скажете ви, що він не володіє технічними знаннями?
Думаю, не варто й говорити, що поза посадами початкового рівня запам’ятані знання не такі важливі. Розробники високого рівня знають, що з легкістю можуть знайти потрібну інформацію, і забувають її, тому що можуть її пошукати. Знання інженерів високого рівня багато в чому неосяжні. Ви отримуєте відповіді на питання типу: чого НЕ варто робити або що було б чудово, але не спрацює в ЦЬОМУ контексті. Ще ви часто будете чути «ні, вам це не знадобиться».
По суті, концепція того, як створити щось на кшталт мікросервісів, відносно проста, тому що інформація легко доступна. Справжня складність, однак, полягає в повсякденних тонкощах реалізації — написанні читабельного коду, забезпеченні розширюваності та створенні ізольованої функціональності. Більше того, потрібна велика мудрість, щоб зрозуміти, чи будуть подібні системи правильним рішенням у конкретному контексті, зокрема, виходячи з потреб організації, наявних у неї технологій і команди.
На мою думку, реальна проблема технічних співбесід полягає в наступному:
Технічні співбесіди використовуються і оцінюються так, ніби важлива лише технічна частина роботи. Крім того, багато людей помилково вважають, що такі співбесіди відображають ситуацію в реальному світі, хоча це далеко не так.
У мене претензії не до самих технічних співбесід, а до того, як їх застосовують. Кандидат проходить сім раундів, з яких два або три будуть технічними. У цих технічних раундах часто акцент робиться на несуттєві частини роботи, вони не відображають робочі умови, створюють непотрібний стрес, дають перевагу певним типам кандидатів і/або залежать від випадкових знань. Тим не менш, цим технічним раундам надається велика вага при оцінці кандидата.
Кандидат може майстерно справитися з усіма попередніми співбесідами, але на технічній зіткнутися з задачею, яку раніше ніколи не бачив. Попотівши, він придумує працююче, але неоптимальне рішення. У звичайних робочих умовах після відправки рішення він би його вдосконалив, але в цьому контексті його результати і рішення будуть порівнюватися з показниками інших кандидатів. Цих кандидатів, ймовірно, вважатимуть “більш підходящими”, незважаючи на їхні результати на попередніх етапах співбесіди.
Повторюся, можливо, це нормально. Можливо, такі вимоги для конкретної посади. Іноді чисто технічні результати, продемонстровані на льоту, мають першочергову важливість для вакансії. Якщо це так, то нічого поганого в описаному вище немає.
Однак я вважаю, що у більшості посад немає подібних вимог. Якщо це так, то подібні співбесіди не забезпечують організаціям тієї користі, на яку вони розраховують. Особливо коли такий сильний акцент робиться на цей критерій на шкоду іншим цінним властивостям, якими може володіти кандидат.
Кількість ресурсів, витрачених на ці співбесіди компаніями — само по собі велика проблема. Однак при кожному наймі ще й відфільтровується багато кандидатів, тобто організації витрачають час людей, у яких зазвичай його дуже мало.
Що ж можна придумати замість цього?
Особисто я знаю той внесок, який робив в організаціях. І ще я знаю, що тільки пару разів проходив далі технічних співбесід завдяки удачі або доброті того, хто проводив співбесіду.
Кумедна історія: я брав участь у останній технічній співбесіді на посаду, що передбачала роботу з NodeJS. Після вступної бесіди той, хто проводив співбесіду, сказав, що він розробник на GoLang, а тому практично ніяк не зможе оцінити мої знання. Я відзначив, що мені подобається його футболка з назвою музичної групи, і в результаті ми годину пробалакали про музику. Я отримав роботу і приніс велику користь цій компанії.
Саме тому я так сильно налаштований проти цих традиційних методів співбесід і говорю про це, коли випадає нагода. Варто розуміти, що такі співбесіди почали проводити, тому що на них, нібито, складно “імітувати” результати. Я вважаю, що це не зовсім так. Якщо у вас є час, терпіння і хороша пам’ять, то імітувати знання не так вже й важко.
Особисто я отримую більш якісний сигнал від співбесід у вигляді вільного спілкування або STAR (situation, task, action, result, тобто клішованих “розкажіть, що ви робили, коли…”). Подібні співбесіди не дуже високо цінуються, тому що кандидати можуть заздалегідь підготуватися до таких питань. Що, як ми знаємо, неможливо у випадку більш сучасних технічних співбесід.
Однак подібні типи співбесід можуть бути неймовірно цінними, якщо той, хто проводить співбесіду, володіє великою широтою знань. Я був свідком того, як ті, хто проводять співбесіду, задавали глибокі питання про зроблений вибір і про те, чи знає кандидат про X, або що могло б статися, якби Y.
Ще важливіше те, що розмовні співбесіди зазвичай ширше охоплюють soft skills. Вони починаються як бесіда, доходять до технічних подробиць, а потім переходять до ширших питань особистих умінь. Хм, дивно, адже це дуже схоже на те, як зазвичай і працюють інженери.
Саме тому я вважаю, що хорошим варіантом також є глибоке обговорення проєктів. Кандидат розповідає про виконаний ним проєкт і готовий відповідати на технічні питання про нього. У цьому випадку можна отримати ті ж результати, що й від питань про проєктування системи, якщо той, хто проводить співбесіду, знайомий з темою.
Але після численних розчарувань я зрозумів, що потрібно шукати інший шлях. Уявіть нічний клуб: усередині — ваша робота. Охоронець змушує стояти у черзі. Але стояти у черзі — простий, але неефективний шлях. Є ризик, що коли ви дочекаєтесь своєї черги, вам відмовлять або, що ще гірше, ви зрозумієте, що взагалі туди не варто було йти. Найкращий спосіб — зайти до клубу через VIP-вхід разом із супроводжуючим — спеціалістом, який вже працює в компанії.
Саме тому я прийшов до висновку, що варто шукати супроводжуючого — співробітника компанії, який може відправити ваше резюме безпосередньо керівнику, оминаючи HR і стандартні технічні співбесіди. Це не лише спрощує процес, але й дає можливість показати свої справжні навички та досвід без зайвих бар’єрів.
Примітка: мені б хотілося також згадати ідею про те, що кандидати повинні готувати повномасштабну презентацію. Враховуючи нестабільність у галузі, звільнення і тому подібне, люди шукають будь-яку посаду зі стабільною зарплатою. Пам’ятайте, що вони, можливо, шукають не тільки посаду, на яку подали резюме у вашу організацію, і у них може не бути вільного часу для створення презентації. В ідеалі варто ставити питання типу “розкажіть про проєкт, де…”, а не просити “презентувати проєкт”.
Особисто я дивлюся на співбесіди під тим же кутом, що і на будь-яке інженерне рішення. Я враховую плюси і мінуси наявних у моєму розпорядженні інструментів і застосовую їх, щоб отримати оптимальне рішення в поточному контексті.
Простіше кажучи, якщо мені потрібно оптимізуватися для пошуку архітекторів, я проводжу співбесіду з цією метою. Якщо для посади важливі виключно технічні знання, то я посилюю технічні аспекти співбесіди і надаю їм відповідну вагу.
Найчастіше для перевірки того, чи підходить кандидат, я використовую розмовні співбесіди. Темперамент, настрій, схильність, стиль спілкування і роботи, спосіб взаємодії з командою, гнучкість — усі ці особливості найважче натренувати. Тому я роблю найбільший акцент на них. Що ж стосується технічної частини, то кодити можна навчити практично будь-кого.
Як це виглядає?
Співбесіди на всі посади складаються з 3-4 раундів.
А що стосовно мене?
Я знаю, що погано справляюся з технічними співбесідами. Але водночас я знаю, що добре справляюся зі своєю роботою. Я знаю, що моя підтримка буває цінною для команди і організації, я ефективно взаємодію з іншими командами для вирішення більш масштабних проблем і тісно співпрацюю з продуктовою і дизайнерською командами, а також з керівництвом для забезпечення їх узгодженості. Я керую пріоритетами, частіше за все організовую, здійснюю керівництво і випускаю великі проєкти. Я розгрібаю завали і підвищую продуктивність. Я знаю, що можу прийти в організацію з практично будь-якою кодовою базою і після дуже короткого ознайомлення з нею почати вносити покращення. Я знаю, що приношу користь.
Після всіх цих роздумів і особистого досвіду я зрозумів, що традиційні методи пошуку роботи та проведення співбесід не завжди ефективні. Часом вони можуть бути перепоною для талановитих спеціалістів, які можуть принести велику користь організації. Тому я вирішив змінити підхід і робить “VIP-вход” — прямого контакту з тими, хто може оцінити мої справжні навички та потенціал:
Супроводжуючий — це співробітник компанії, який може відправити ваше резюме безпосередньо керівнику, оминаючи HR. Це відкриває двері до нових можливостей і дозволяє обійти складні та часто несправедливі етапи відбору.
З іншого боку, якщо ви вже працюєте в компанії, ви можете допомогти талановитим спеціалістам приєднатися до команди, рекомендуючи їх напряму керівництву.
Працюємо за напрямками:
Сподіваюся, тепер ви розумієте і, можливо, задумаєтесь про нашу платформу як старт пошуку роботи!