Par Tech - Data Central

За свою багаторічну кар’єру я отримав багато відмов від різних компаній з різними формулюваннямя, а також взагалі без жодних пояснень. І здається вже звик до всього. Але та відмова, яку я отримав нещодавно від компанії [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. Тобто я мав не просто реалізувати певний алгоритм, а ще й переконатися що він буде швидко працювати на великих об’ємах даних. :)

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