За свою багаторічну кар’єру я отримав багато відмов від різних компаній з різними формулюваннямя, а також взагалі без жодних пояснень. І здається вже звик до всього. Але та відмова, яку я отримав нещодавно від компанії [ParTech|www.partech.com] здається все ж таки заслуговує на відгук. Формулювання було таке: «Просто ми шукаємо кандидатів з більшим досвідом і знаннями в SQL, які відповідають нашим потребам в даний момент.» Тобто я отримав досить непрозорий натяк на те, що я недостатньо добре знаю SQL для того, щоб працювати в команді ParTech. Такого в моїй більше ніж 25-річній кар’єрі досі ще не трапилося, тому мені стало цікаво, з чого саме було зроблено такий висновок. Повний текст листування можна подивитися якщо завантажити файл, доступний за [цим|github.com/...​ommunication_Djinni.mhtml] посиланням. Я розумію, що фраза вирвана з контексту може створювати трохи хибне враження, тому даю можливість всім бажаючим ознайомитися з перепискою цілком. У дужках зауважу, що в цілому пані Ольга Солдаткіна спілкувалася дуже професійно та абсолютно коректно. Фраза, яка приведена вище, — єдина до якої в мене виникли питання.
То ж спочатку все відбувалося абсолютно звичайним чином. Я відгукнувся на вакансію, мені призначили скрінінг. В процесі скрінінгу з’ясувалося, що компанія просить виконати ніби-то невеличке тестове завдання з SQL. Зазвичай я не погоджуюся виконувати тестові завдання, але зараз ситуація на ринку складна, до того ж, наскільки я зрозумів на співбесіді, досвідченому розробнику мало б вистачити пари годин, то ж я погодився.
Коли я прочитав постановку завдання, в мене одразу ж виникли сумніви. Ось [тут|github.com/...​/main/Test_07_17_2023.sql] можна подивитися, що я отримав. Справа в тому, що якби я отримав таке саме завдання вже працюючи в компанії, я ні в якому разі не почав би кодування доки не отримав би дуже чіткі пояснення що до алгоритму врахування перерв, бажано з прозорими та зрозумілими прикладами, в яких саме випадках які саме перерви варто чи не варто враховувати. Бо той текст, що я отримав в якості завдання точно можно інтерпретувати кількома різними способами. Але з мого досвіду подібні уточнення/перемовини можуть зайняти кілька днів. Тобто це точно не пара годин роботи, тому я зробив припущення що враховуються тільки перерви які сталися між TakeBreakWithin і BreakRequiredAfter годин, починаючи з першого виходу на роботу протягом поточної доби і які тривали не менш ніж MinBreakMinutes. Я розумів, що це може бути не зовсім те, що мав на увазі, той, хто писав ТЗ, тобто це тільки одна з можливих інтерпретацій, але ми з пані Ольгою розмовляли про пару годин. Завдання не оплачуване. Тому я вирішив, що зважаючи на обставини, таке припущення цілком притомне.
Я написав код, і для того, щоб перевірити що він правильно працює для моєї інтерпретації ТЗ, навіть додав свій власний тест-кейс, яких дозволив переконатися, що принаймні happy path працює саме так, як я розраховував. Тобто, для робітника, який отримав за добу всі належні (на мій погляд) перерви, мій запит ніяких даних не поверне. [Ось|github.com/...​est_07_17_2023_Edited.sql] посилання на код, який я повернув у якості відповіді. Особливо варто зауважити, що оскільки ТЗ припускало кілька інтерпретацій, я додав до свого рішення логування (за допомогою оператора PRINT) логіки роботи коду, щоб було однозначно зрозуміло, де саме які перерви я очікую знайти і чи знайдени вони в таблиці.
Звісно, коли я отримав інформацію, що з точки зору компанії я недостатньо добре знаю SQL, я попросив хоча б якихось пояснень. Дійсно, стало цікаво, з чого саме був зроблений такий висновок. І [ось|github.com/...​/Answer_to_Alexander.docx] посилання на файл, який я отримав у відповідь. З неї я зрозумів дві речі.
1. Завдання я звісно зрозумів трохи не так, як його розумів співробітник ParTech, який його перевіряв. Я це передбачав і саме для цього зробив логування.
2. Мій код ніхто навіть не намагався розібрати і зрозуміти його логіку. Тим більше ніхто не дивився на логи. З запуску цього коду перевіряючий отримав тільки інформацію про те, що код працює не так, як він очікував. З цього здається і було зроблено висновок про те, що я недостатньо добре знаю SQL.

Навіщо у відгуку запитання 3-7 я взагалі не зрозумів. Я зрозумів би, якби щось подібне в мене спитали на співбесіді. Але на співбесіду мене не запросили саме через те, що я ніби-то недостатньо добре знаю SQL. Я навіть з цим не сперечаюся, можливо і недостатньо добре, але робити такий висновок просто з того, що мій код працює не так як очікується було, скажімо так, трохи передчасно. І, нажаль, у відгуку я не знайшов ніякої цінної інформації з приводу того, що і як варто було б покращити. Доречі, якщо хтось знає, що таке курсори в C#, будь ласка, поясніть мені. Бо я не зрозумів взагалі, про що йдеться.

Побажання команді ParTech. Будь ласка, наступного разу перед тим, як робити будь-які висновки що до hard skills кандидата, а тим більш перед тим як переказувати кандидату ці висновки, переконайтеся будь ласка, що ви дійсно маєте підстави це робити. Бо якщо діяти так я ви зробили в моєму випадку, є шанс образити людину, або завіть викликати в неї зневіру у власних силах. Будь ласка, давайте розгорнутий відгук кандидатам ЗАВЖДИ. Людина, яка погодилася робити безоплатну роботу заради того, щоб ви могли переконатися, що вона вміє робити саме те, що вам потрібно, заслуговує принаймні на притомний code review. Якщо ви не хочете брати людину на роботу, але не впевнені чому саме, краще не посилайтеся взагалі на hard skills, краще придумайте якийсь менеджерський bullshit на кшталт неспівпадіння стилю роботи чи щось подібне. Помилитися що до оцінки hard skills іншого розробника доволі легко, навіть у разі якщо сам маєш доволі високу кваліфікацію в галузі про яку йдеться. Не завжди легко зрозуміти, як мислить інша людина (тим більше, якщо бачиш тільки код), тому тут дуже легко потрапити в неприєму ситуацію. Краще не давати поганий відгук про знання кандидатом конкретної мови/технології якщо немає стовідсоткової впевненості. :) А стовідсоткову впевненість не завжди легко отримати навіть протягом випробувального терміну.

Порада кандидатам. Якщо ви не готові витрачати багато часу на запитання, уточнення, перемовини і таке інше, не беріться виконувати технічні завдання для ParTech. Щоб вашу роботу оцінили, ви маєте переконатися, що зрозуміли ТЗ саме таким чином, як мав на увазі той, хто його написав. І це може бути досить неочевидною річчю і потребувати певних зусиль і часу само по собі. Крім того ви маєте точно зрозуміти, за якими саме критеріями будуть оцінювати вашу роботу. Бо, судячи з відгуку, від мене очікували production quality code. Тобто я мав не просто реалізувати певний алгоритм, а ще й переконатися що він буде швидко працювати на великих об’ємах даних. :)

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

Я пропрацював в компанії приблизно півтора року на позиції ведучого розробника (.Net) на одному з проектів. Незважаючи на те, що клієнт на цьому проекті був доволі складний, це був чи не найцікавіший досвід в моїй кар’єрі. Керівництво компанії дуже гнучке та розумне в усьому, що стосується постановок завдань, графіка роботи, використання тих чи інших технологій/фреймворків/підходів. Все, що добре працює і дозволяє вписатися в термін, може і повинно використовуватися. Всі питання, які виникають в процесі роботи, обговорюються вирішуються таким чином, щоб врахувати, наскільки можливо, інтереси кожного та всі нюанси кожної задачі чи ситуації. Це мотивує працювати в повну силу та шукати найкращі способи впоратися з тими чи іншими викликами. Винагородження виплачується точно і в оговорений термін.
Єдина причина з якої я пішов з проекта — це те, що клієнту з часом стало вже занадто складно поратися навіть з виключно бізнесовою частиною постановок завдань. Тому мені стало не вистачати суто технічних викликів, і я став відчувати недозавантаженість. Я особисто не дуже люблю занадто глибоко занурюватися в бізнес. Бізнес анализ не є моєю найсильнішою стороною, мені більше подобається суто технічне проектування та розробка.
Не виключаю, що якщо в майбутньому з’явиться така нагода, я можу знов почати (продовжити) працювати з цією командою. Це був той рідкий випадок, коли співпраця виявилася одночасно досить комфортною (принаймні для мене) і плідною. В будь якому разі, я вдячний компанії за співпрацю і бажаю усіляких успіхів. Це команда, з якою легко и цікаво працювати.

Вчора запросили на співбесіду в цю компанію. Ну, я нібі погодився, але без жодних обіцянок. Сьогодні виявилось, що спочатку треба підтвердити рівень англійської. Я спитав, який рівень потрібен, сказали щонайменьш Intermediate. Я надав сертифікат FCE (en.wikipedia.org/wiki/B2_First), який ніби-то підтверджує Upper Intermediate. Сказали, що цьгого недостатньо, бо існує процедура, яку неможна ігнорувати, тому все одно треба пройти співбесіду з їхнім викладачем англійської мови. Дивно. Upwork визнає сертифікат FCE, проте DataArt цього сертифіката не визнає. Вочевидь, DataArt є крутішим за Upwork. Крутезна компанія, дуже рекомендую. :)

Працював в цій компанії віддалено як .Net розрорбник трохи більше за рік в 17-18 роках. Працював на проекті з online financial management. Перші декілька місяців, поки працював в українській команді, було досить цікаво, відчував що приносив проекту певну користь, потім відбулася «реорганізація», мене, незважаючи на те, що я був досить успішним розробником, вислали в глухий саппорт, де мені стало незрозуміло, чим я взагалі мав займатися. За пару місяців втік, оскільки відчув, що мене використовують не за призначенням та я вже почав втрачати кваліфікацію.

Світлі сторони. Здобув неабиякий практичний досвід роботи з певними досить цікавими технологіями, наприклад, LinqToDB. Переробив на більш сучасний лад досить складну та цікаву машинку пошуку по базі MS SQL, яка підтримує формування та збереження з можливостю подальшого використання досить гнучких критеріїв пошуку. Непогано підтягнув LINQ, Expressions etc. Було ще декілька досить цікавих завдань, виконання яких приносило задоволення та користь для професійного зростання. Винагородження виплачувалось у строк та згідно домовленностей, з цим на той час жодних проблем не було, принаймні в мене. Навіть в певний момент отримав невеличке підвищення. Ще компанія сплатила мені компенсацію за покупку більш потужного лептопу, бо мій тодішній був занадто слабким для того здоровезного проекту.

Темні сторони. В компанії на той час працювало досить багато (більщість) розробників з Росії та Узбекістану. Досить специфічний менталітет більшості з цих людей не додавав жодних радощів, певний рівень «азіатчини» відчувався майже постійно. Американське керівництво проекту на той час не розуміло в достатній мірі ані технічних викликів, ані методів організації роботи. На той час на досить великій базі кода (декілька сот тисяч рядків), яка зберігалася в єдиному репозиторії та технично являла собою два «моноблочних» рішення на C# (front-end & back-end) працювало десь трохи більше за 20 розробників умовно поділених на 4-5 команд. Це чомусь звалося Скрамом. Звісно така організація процесу не додавала ефективності, постійні конфлікти між командами були практично неминучі. Зворотнього зв’язку з керівництвом проекту майже не було, тобто деякі ліди команд мали певний вплив, інші — ні. Всі недоліки зазвичай притаманні корпоративному середовищу мали місце так само, як деякі специфічні саме для цієї компанії не дуже приємні особливості робочих відношень.

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