Чи варто виконувати тестові завдання. Думки розробників

💡 Усі статті, обговорення, новини про HR — в одному місці. Приєднуйтесь до HR спільноти!

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

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

Аргументи проти

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

Тестові завдання, відірвані від життя

Олександр Левінсон, ASP .NET Developer

У 2014 році, коли почалась війна, я втікав з Донецька і втратив роботу. Досвіду в мене багато: я почав програмувати в 15, а зараз мені 50. Я оселився в невеликому місті, став шукати роботу віддалено, і на той час це було викликом.

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

Іноді тестове дають «приблизно на 4 години», але коли робити його на совість, то не факт, що вистачить 2–3 дні. Навіть у тому, що ти знаєш, бувають речі, на які спочатку не звернув уваги. Ніхто не може сказати, що вміє все. З’являються нові мови, технології, підходи. Був випадок, коли відповів, що можу взятися за завдання, але виконуватиму його довше, бо треба розібратися в кількох незнайомих технологіях. На мої умови погодилися, але вже наступного дня HR запитала, коли буде робота. Я відповів, що, мабуть, вже ніколи, раз такий підхід. На мою думку, ІТ в Україні сьогодні — це переважно «галерна промисловість», власники компаній не завжди зацікавлені в хороших фахівцях. Часто вони шукають просто певний набір навичок, аби «веслувати далі».

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

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

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

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

Дивні аргументи в інтерв’юерів

Анна, Middle .NET Developer

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

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

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

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

Роботодавці та кандидати можуть обманювати

Тимофій Воробйов, Senior freelance PHP Developer

Якось до мене звернулася одна компанія, якій необхідно було доопрацювати свою систему. Та піддалася хакерській атаці: базу порушили, пароль адміна змінили. Виправити це було нескладно. Мені відповіли, що якщо впораєтеся, то працюватимемо далі разом. Тобто це стало моїм тестовим завданням для отримання постійної роботи в компанії.

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

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

Невелике завдання краще пропонувати виконати в реальному часі, ніж давати його додому. Особливо в умовах, коли деякі початківці роблять їх, як в університеті: знаходять фахівця, у якого немає грошей, і пропонують йому виконати завдання замість себе. У мене був схожий випадок. На співбесіду прийшла дівчина, яка претендувала на позицію адміністратора вебсайту. Їй необхідно було володіти базовими навичками HTML. Резюме було хороше, але коли я запропонував написати на місці простенький HTML-код, вона відмовилася. Сказала, що завжди працювала з якимсь онлайн-редактором, який те робив сам, а тому не розуміє, навіщо їй цим займатися. Це очевидно був блеф«.

Це приниження для програмістів

Артем Комісаренко, Software Developer у Zultys

У 2009 році, коли почалася фінансова криза, я опинився без роботи. Досвіду в мене було років зо два, довелося відсилати резюме куди тільки можна. Пам’ятаю, в одній з компаній тестове було елементарне, на рівні «продемонструвати володіння мовою і стандартною бібліотекою». Я вилизував його кілька годин, надіслав і отримав у відповідь: «Погано». Коли спробував перепитати чому, мені відповіли, що там є memory leaks. Їх там не було, та в мене є певні здогадки, чому так подумали, але який сенс сперечатися? Я взагалі доволі гоноровий: доводити, що не верблюд, тим, кого не поважаю, мені не цікаво. І це ж мої потенційні майбутні колеги, я хотів би у них чогось повчитись, а не оце ось все.

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

Коли я шукав роботу наступні рази, у 2012 та 2013 роках, моє резюме вже було цікавішим і позиції фільтрував. Усіх з тестовими я відправляв у кінець списку, до якого так і не доходив. Нині я вважаю тестові завдання елементом приниження програмістів-початківців. Коли тобі кажуть «ми вам передзвонимо», а насправді зворотного зв’язку не дають. Крім того, тестові ще й неефективні, якщо дивитись з боку тих, хто наймає. Я сам проводив співбесіди й розумію, що коли ви не Google і людина погодилася виконувати тестове, значить, її більше ніхто не хоче брати, що є поганим знаком.

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

Аргументи за

До тестових завдань часто прихильно ставляться ті, кому в такий спосіб вдалося знайти першу роботу, особливо без попереднього досвіду в ІТ.

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

Добре для тих, хто боїться співбесід

Ігор Янішевський, Software Developer в Eyeo GmbH

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

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

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

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

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

На мою думку, тестові необхідні розробникам усіх рівнів. На співбесідах ставлять типові питання, їх можна вивчити, а коли людина приходить на роботу і в неї від початку все складається погано через те, що ніхто не перевіряв, як добре вона пише код чи взаємодіє з іншими — такого нікому не хочеться. І що з того, що у резюме написано Senior? Сьогодні сеньйорами стають у 23. Попередня компанія могла підвищити спеціаліста до цього рівня, лише щоб продати клієнту, а не через відповідний досвід. Я і сам так робив: підписувався сеньйором у своєму резюме, якщо мав цей статус у минулій компанії, хоча може й на надто дотягував. Звісно, так не всюди, але явище досить поширене. Та й сеньйори бувають різними, все одно потрібні тестові.

Тестові — це досвід, що можна вказати в резюме

Денис Гришко, Junior Front-end Developer

У мене було багато тестових, за півтора місяця я відгукнувся на понад 250 вакансій. Усі зробити я не міг, тому обрав найцікавіші. Я знав, що основою є JavaScript, і розумівся на одному з фреймворків — React. Та на ринку популярні ще два — Vue.js та Angular, тому подавався і туди. Як на мене, якщо знаєш основу, з усім можна розібратись. У таких випадках я просто просив трохи більше часу. Для мене це був виклик, вихід із зони комфорту.

Спробувавши, я вже записував собі в резюме, що вмію працювати з тими технологіями. Чому ні? Якщо застосовував їх на практиці, значить, орієнтуюся і можна зазначити це. Сьогодні багато людей боїться подаватися на вакансії, бо надто багато критеріїв та вимог. У сучасних реаліях ідеального кандидата не знайти. Тому якщо розумієш, що на 50–70% це твоя вакансія, то варто відгукнутися. А за тестовим уже зрозумієш, зможеш працювати чи ні.

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

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

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

Не факт, що, якби я про себе не нагадував, мене б не забули. І тепер усім раджу: коли надіслали резюме, завжди намагайтеся взяти контакт, бажано прямо телефонувати.

Шанс потрапити у професію

Василь Жук, Senior Back-end Developer у Digital Pulp

Якби не тестове, я б не потрапив у професію. Так, я з дитинства цікавився комп’ютерами, на третьому курсі створив перший сайт. Робив сайт і для Могилянки, де вчився, але просто тому, що міг. Коли ж вчився на фінансиста і почав шукати першу роботу, то й не знав, що можу зайти в серйозний ІТ-світ. Вперше мені це підказали на співбесіді в конторі, що займалася впровадженням ERP, системи управління підприємствами. Фінансовий тест я завалив, але на інтерв’ю звернули увагу на мій досвід програмування і запропонували спробувати себе програмістом.

Я пропустив це повз вуха та надумав піти у тестувальники — у багатьох моїх друзів вийшло. Та коли прийшов найматися, голова ІТ-відділу сказав: «Слухай, ми можемо взяти тебе тестувальником за 800 баксів на місяць, але душа в тебе лежить до іншого, тому в результаті матимемо нещасного програміста». Та круто, але як бути з тим, що я не маю професійної освіти? Він мені відповів, що якщо складу тестове завдання, то нікого це не хвилюватиме.

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

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

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

Тестові бувають різні. Можуть попросити за допомогою рекурсії написати піднесення числа в степінь — це легко загуглити, але такої можливості немає. А буває і завдання на день-два, коли треба зробити цілу програму. Колись читав історію хлопця, якому як тестове завдання запропонували створити 3D-змійку, повноцінну гру, де можна перемикати камеру в першу особу змійки та спостерігати за нею з різних ракурсів. Усе це прикольно, але звучить підозріло. Потім хтось може розмістити цю гру на App Store, тож хлопець сказав «до побачення».

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

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

Ще один підхід — запропонувати описати архітектуру (або підхід) під конкретний кейс. Мені цей варіант подобається, коли я сам інтерв’юю. Комбінуючи код, за допомогою «гугла та якоїсь матері», програмувати можна легко, а розробити архітектуру для нестандартної задачі — це вже інша річ. Висновок: джуніорів можна перевіряти за знаннями API, мідлів — за вмінням алгоритмізувати, а сеньйорів — за побудовою архітектури".

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному5
LinkedIn



Найкращі коментарі пропустити

Половина потенциальных работодателей дает тестовое «на 4 часа», в котором надо поднять БД и API сервис, написать какой-нибудь клиент, предусмотреть валидаци данных, добавить несколько тестов, сгенерировать документацию.
Какой смысл в таком подходе, если:
1. делать хорошо — значит несколько дней и сильный соискатель не будет тратить свое дорогое время
2. делать плохо — какой стороне это надо?

А со стороны компании они еще какого-то разработчика выдергивают от основных задач и заставляют проверять. Фидбек чаще всего не валидный, замечания слабо относящиеся к тестовому.

Час общения ценнее «4-часового» задания. Отказаться через месяц от неквалифицированного сотрудника лучше, чем регулярно упускать хороших людей глупым подходом.

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

Стал бы я выполнять тестовое задание сегодня? Разумеется! Если бы до этого все другие компании на рынке дали бы мне отказ. Вероятна ли такая ситуация на практике? Конечно нет.

Со стороны же интервьюера, помимо демонстрации знаний и опыта, мне гораздо интереснее увидеть snippet или, если позволите, sneak peek того, как человек работает. В идеале — сессия парного программирования минут на 40-60. Посмотреть вживую как человек в любимом IDE делает наброски кода, чистит его, пишет один юнит тест. На примере простой задачи типа «1. прочитай текстовый файл с диска 2. Замени в тексте фразу на другую 3. Сохрани файл на диск. 4*. Добавь минимальную обработку ошибок.».
Это полезно, потому что есть немало людей, которые мнят себя «выше кода» и попросту забыли как кодить. Такая простая сессия выведет их на чистую воду и отправит их в следующую дверь, где ищут Solution Architect’ов и прочих Principal UML Artist’ов. Тоже нужные люди.

Уже мульйон страниц измарано и сотни Горшков побито вокруг вопроса который не стоит выеденного яйца.
Ответ на который помещается в одно предложение «Если можешь попасть туда куда хочешь и получить столько сколько хочешь без тестового — не делай»

Для джунов нормальное требование, для сеньойров лучше не надо злоупотреблять. Из свой практики могу сказать что из 5 тестовых за которые брался, положительно закончился только один кейс, и то потом у заказчика что там случилось и я принял оффер другой компании пока те думали, но потом они вернулись было поздно. В итоге я буду делать тестовое только в том случае когда реально жрать нечего будет, а так все в лес.

Є люди, які проти тестових завдань. Я за свою довгу кар’єру розвинув такі правила:
1) Тестове завдання припустимо, якщо у компанії є сумніви щодо кваліфікації/навичок співробітника. Наприклад, якщо це junior/trainee.
2) Якщо його виконання займає 2 години і менше, його можна робити безкоштовно, якщо більше — то за гроші. Особливо якщо це тестове «на тиждень».
3) Тестове завдання містить в собі роботу з технологіями, які використовуються на проекті
4) Але найчастіше тестове завдання можна замінити на live coding/design прямо на співбесіді, адже тут можна і поспілкуватися, і обговорити рішення, зважити всі «за» і «проти», тобто зрозуміти як людина думає. Але інтерв’юери зазвичай лінуються це робити і замінюють тестовим.

298 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Предствьте себе грузчика, которому дают тестовое задание — разгрузить вагон )
Если он без работы, то это может быть и норм подход.
Но если вы его пытаетесь «схантить» — то так себе )

Когда устраивался джуном, то в одной компании задали сделать тестовое, в итоге потом на собеседовании ничего не спросили и даже не заикнулись о нём (ну хоть скилы качнул и то хорошо). В другой компании задали наверстать 5 скринов под андроид (возникло подозрение, что мне хотели спихнуть часть работы, чтоб сделал в качестве тестового). Я бы конечно сделал их, но решил принять оффер в другую компанию, где меня готовы были уже сразу взять, мне тогда ещё сам СТО сказал, что зачем тестовое задание, если можно взять на испытательный срок, дать реальную таску и посмотреть, потянет ли.

Ну неудержусь от моей историй об этом — У меня есть манька каждый год задротить чтот новое тип языка или подхода. Посмотрел я года два назад на дарт с флаттером. И думал что ж запилить для интересу. И постучался ко мне рекрутер с предложением гор золотых и берегов покрытых стейками. Скинул мне ТЗ на тестовое, и на вопрос, на чем писать то можно, ответил пиши на чем хош, и за время оплатят. О, класс и думать не надо на чем запилил на флаттершай. Скинул сладкоголосым гит репу — а рекрутер ответил, что на том конце особо и проверять некому. И слился. Так у меня начальный стаж работы с флаттер оказался некоммерческим, и я получил что хотел на шару ) Рекрутер представлял какой то банк

Если я отозвался, то те кто поумнее и активнее выхватывают меня сразу. О лохах предлагающих тестовое даже лень думать. Глупые отпадают сами. Работаю с умными.

А якщо ваш реальний рівень далеко не сіньйорський?

Реальный уровень определяет только рынок путём голосования баблом среди работодателей.

Це велика помилка думати, що ваш рівень прямо пов’язаний з розміром винагороди.

Тре собі дописати тоді мастер, чи гуру =)

А яких рівень винагороди характеризує тебе як сіньора? Озвучте сітку, будь ласка...

Немає сенсу. Гітхаб розкаже про рівень красномовніше.

Гітхаб розкаже про рівень красномовніше.

Что именно расскажет гитхаб, если весь написанный человеком за карьеру код раскидан по приватным репозиториям?

Месье знает толк в извращениях. Линкед то чего не угодил то? Он по идее только в России и в Северной Корее и в Китае под запретом. Но то не моя ЦА

Так не моя CV там лежить.

Ну приватные со временем прорастают в публичные. Там другая проблема если для себя/проверка концепции то там многое ~~без бутылки~~ пояснений не разобрать и выглядит оно как ДичЪ

Ну приватные со временем прорастают в публичные.

Ничего подобного. Так и умирают приватными. Энтерпрайз код никогда в паблик не пойдёт. Разве что сэмплы для использования какого-то фреймворка.

А только они и могут задержатся как прайвит в репе у разраба. Остальное — в репах фирмы

Судя по вашему гитхабу у меня сомнения насчёт умных...

Головне гучніше кричати про свій виключний рівень ;)

Если кандидат не хочет потратить время и сделать тестовое, то у него нет мотивации работать в компании. Если человек не хочет тратить свое время, какой смысл компании тратить время на человека, который через пол года перейдет на +500 через дорогу? В Украине почти все компании это галеры, где программисты работают над «проектами» для абстрактных «заказчиков». Оттуда искаженное восприятие реальности.

Сравните с компаниями на западе, где бывает что люди тратят по пол года на leetcode для того чтобы пройти собеседование. Или как люди ищут работу для переезда в другую страну — учат язык, получают сертификаты, подтверждают документы и т.д.

то у него нет мотивации работать в компании.

Именно. Им ваша компания интересна как способ получения опыта и денег в обмен на время. Вы им интересны как источник технических решений в обмен на деньги. Вполне честная сделка, что не так?

какой смысл компании тратить время на человека, который через пол года перейдет на +500 через дорогу?

Если вам так важен этот человек, дайте ему на 500 выше рынка и никуда он не пойдёт.
Если он через полгода уходит на +500, вы просто мало платите. Всё просто.

В Украине почти все компании это галеры, где программисты работают над «проектами» для абстрактных «заказчиков». Оттуда искаженное восприятие реальности.

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

Сравните с компаниями на западе, где бывает что люди тратят по пол года на leetcode для того чтобы пройти собеседование.

Когда будете платить в своей компании фаанговскую зарплату и главное — будете давать работникам акции своей компании, то есть, долю в бизнесе, тогда будет уместным разговор за литкод, конкурс и продукт. Без этого всего — вы не более, чем ещё один кастомер, выкупающий жопочасы на проекте. И не надо мнить о себе лишнего.

Если кандидат не хочет потратить время и сделать тестовое, то у него нет мотивации работать в компании.

Человеку нужна работа. Что должно мотивировать его работать именно в этой компании, если у других компаний аналогичные вакансии с аналогичным стеком технологий?

Сравните с компаниями на западе, где бывает что люди тратят по пол года на leetcode для того чтобы пройти собеседование.

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

Или как люди ищут работу для переезда в другую страну — учат язык, получают сертификаты, подтверждают документы и т.д.

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

Если кандидат не хочет потратить время и сделать тестовое, то у него нет мотивации работать в компании.

Тестовое оплачиваемое? Если нет, значит компания хочет что бы человек работал бесплатно в виде овертаймов.

Если человек не хочет тратить свое время, какой смысл компании тратить время на человека, который через пол года перейдет на +500 через дорогу?

А собеседование это не потеря времени

Сравните с компаниями на западе, где бывает что люди тратят по пол года на leetcode для того чтобы пройти собеседование.

На FAANG-ы, с какого времени наши галеры приблизились к ним? Сидеть под года на leetcode что бы потом делать CRUD-ы, или клепать формы? Звучит как издевательство.

Сравните с компаниями на западе, где бывает что люди тратят по пол года на leetcode для того чтобы пройти собеседование.

«компаниями на западе» это сильно растяжимое понятие.

Или как люди ищут работу для переезда в другую страну — учат язык, получают сертификаты, подтверждают документы и т.д.

Это оффтоп

На FAANG-ы, с какого времени наши галеры приблизились к ним? Сидеть под года на leetcode что бы потом делать CRUD-ы, или клепать формы? Звучит как издевательство.

Насколько я понимаю (тут на доу проскакивало), тех кто идут в фаанги через литкод часто как раз и садят на хлеб и воду формочки и круды. Потому что такой работы там тоже жопой жуй, и её и надо делать.
Те же, кто пишет какую-то заумную хрень (в хорошем смысле), переходят просто по знакомству.
Могу быть не прав.

Написанное выше является просто ремаркой насчёт фаангов и никак не влияет на тот факт что собесы в юа галеры это другой мир.

Мда.

Если человек не хочет тратить свое время, какой смысл компании тратить время на человека, который через пол года перейдет на +500 через дорогу?

Хм, а про бас фактор не?

Сравните с компаниями на западе, где бывает что люди тратят по пол года на leetcode для того чтобы пройти собеседование.

Вот чего взяли у гугла -это собесы. До зп и соц пакета как то еще ход дошел

Читав коменти, багато думав, часом несамовито іржав. Врешті решт зрозумів, що випустив хіба не найважливіший аргумент з приводу того, чому спеціалістам міддл+ навряд варто пропонувати будь-які тестові завдання. Якщо людина пропрацювала в індустрії хоча б 5 років і є насправді талановитою, в неї повинні вже бути певні здобутки. Проект(и) який вийшов в продакшн завдяки цій людині, якась вагома участь в open source проектах, рекомендації від колег та/або клієнтів (в LinkedIn, або будь-де), досить високий success rate на певному фрілансрському сайті, або хоча б неабияка репутація на Stackoverflow, наприклад. Якщо щось подібне є в кандидата в CV (і це зазвичай легко перевірити, або взагалі немає необхідності перевіряти), навряд будь-яке тестове завдання надасть Вам більше інформації про людину, ніж перевірка актуальності її реальних здобутків.
Якщо цього немає, це не обов’язково є ознакою того, що людина взагалі ні для чого не придатна, але знову ж таки, співбесіда тут скоріш за все дасть набагато більше інформації що до причин, чому людина досі не має помітних досягнень ніж будь-яке тестове завдання. Бо причини можуть бути геть різні: нестача знань або хисту, слабкі soft skills, невміння правильно обирати работодавців та/або колег, ще багато чого, включно із складними особистими обставинами, та будь-яка комбінація декількох причин. Тестове тут щось допоможе зрозуміти хіба що якщо Ви маєте справу з людиною, яка невірно обрала професію. У всіх інших випадках — навряд.
Насправді оцінити performance розробника на короткій дистанції зазвичай неможливо. І на довгій складно, бо є багато звичок, навичок, та рис характеру, які можуть спрацювати в обидва боки. А на короткій неможливо взагалі, бо performance це і є різниця між вирішеними та створеними проблемами на довгій дистанції. Тому, на мій погляд, першим і головним критерієм найму спеціалістів міддл+ мають бути попередні досягнення. Звичайно, якщо работодавець потребує дійсно спеціалістів здатних розробляти ПЗ, а не просто будь-яких індивідів, яких можна продавати замовнику за певний рейт, вищий за той, за який вони погодились працювати.
Звісно це не виключає можливості давати тестові завдання початківцям (а може і досвідченим працівникам, якщо вони на це згодні, або навіть хочуть цього), і тут вже все залежить від якості тестових та якості фідбеку. Але це вже зовсім інша розмова.

Якщо людина пропрацювала в індустрії хоча б 5 років і є насправді талановитою, в неї повинні вже бути певні здобутки.

скажем так 80%+ реальных кандидатов из «реальных досягнень» максимум могут предоставить «работал работу» плюс обобщённо указать не стек даже но «условный язык программирования» и уже в этом месте приходится копать чтобы просто понять что конкретно человек вообще делал и вынужден признать что не редки случаи когда либо ничего либо понять никак нельзя

за то чтобы говорить «что конкретно человек _с_делал» речи здесь даже не идёт

або хоча б неабияка репутація на Stackoverflow, наприклад

давайте всё же ж говорить реалистами и сколько таких человек среди оценки там грубо 250 тыс программистов Родины может 5 человек? может 15? ну хорошо пусть 20

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

о ну я уже знаю ответ на этот вопрос )) и простите это таки менталитет и исторически сложившаяся культура селяви просто Родина и дальше можно даже не продолжать

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

фактически принципиального смысла давать тестовое начинающим нет никакого просто потому как это начинающие и надо самом себе ставить вопрос а что именно мы хотим протестировать в начинающих

ЗЫ: но вообще да лично у меня самое первое начинающим было тестовое )) и зная тогдашнее своё окружение «первых начинающих» могу прямо говорить что я был один из не многих кто вообще мог его сделать в принципе и даже просто оценить об чём оно

и отсюда начинается интересный обратный момент почему вообще не начинающего может заинтересовать посмотреть на тестовое так это потому что тестовое в свою очередь очень многое может сказать об компании

... а может и не сказать но тогда снова не ясно а зачем вообще иметь с такой вообще дело ))

это таки менталитет и исторически сложившаяся культура селяви просто Родина и дальше можно даже не продолжать

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

Нормальные компании, не дающие тестовое, идут на осознанный риск что без тестового ок, если затем можно безболезненно избавиться от «опытного» на испытательном. Для типичных галер тоже ок, поскольку там может работать закон больших чисел — 20 штук опытных взял, из них если 7 ответили ожиданиям то ок, остальных за борт. И так на перманентном конвеере.

для типичных галер сложно давать тестовое просто потому как реальное тестовое по проекту может дать максимум один человек на проекте а в более общем случае даже такого нет и таких вообще максимум 1-2 на 10 проектов селяви ничего личного просто бизнес ))

Да если вы джуниор, и вам нужен опыт что бы попасть ну хоть в какую-нибудь галерку и войтивайти

Интереснее тогда уже запилить свой пет-проджект. Даже если он никому нафиг не сдался, это не важно. Важен сам факт разработки чего-то самому, что можно показать другим. Я так первую работу нашёл. Кастомер аппрувнул на основании этого даже без интервью с ним.

Воот! Это моя рекомендация всем джуниорам, а наши стажеры запросто могут записать все что со мной делали себе в копилку, еще и рекомендацию получить в линкедин. Профит же!

Чи варто виконувати тестові завдання

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

Тестове завдання красномовніше за CV, знання алгоритмів та вміння красиво розповідати на інтерв’ю. Але давати його треба не всім без огляду, а тільки тим, хто погано зміг себе показати під час зустрічі.

Да. Есть такой стартап Surprise. Там алгоритм прохождения интервью точь-в-точь как Панк Флойд описывал в топике Тореадор из Заточки в Долине. И ливкодинг, и систем дизайн, и бихевиорал и всё остальное. Я как только об этом услышал от рекрутера, сразу пожелал успехов. Теоретически, у них можно потренироваться проходить долиновские интервью, кому интересно. Но я думаю, у них там всё же облегчённый вариант этого всего, т.к. здесь — это вам не там.

Долиновское интервью ИМХО лучше практиковать с FAANG-ами. Сейчас это можно сделать из дому.

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

Тестове завдання красномовніше за CV, знання алгоритмів та вміння красиво розповідати на інтерв’ю.

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

А поки казочка:
Якось в універі я робив тестове замість одного чувака. Інтрев’ю було по тестовому, тому він легко пройшов співбесіду (знав усі теми) і пішов працювати.
Через кілька місяців зустрів одного з його колег (як виявилось ми знайомі), у розмові прозвучала десь така фраза:
— А ти знаєш Х? Він типу з твого факультету. Чувак зробив тестове так класно (на рівні мідла) і норм співбесіду пройшов, а в роботі взагалі не шарить. І код пише значно гірше ніж тестове зробив. Ми думаємо його звільняти.

озкажіть яку інформацію ви можете отримати з ДЗ і чому немає ефективніших способів її отримати?

1) Вміння уважно прочитати завдання
2) Вміння реалізувати його не в цейтноті
3) Вміння комунікувати з умовним бізнес-овнером

1) Вміння уважно прочитати завдання
3) Вміння комунікувати з умовним бізнес-овнером

1) Обидва пункти — 5-45 хв на співбесіді
2) Як ви зібрались перевіряти навички комунікації? Скільки сесій з продукт-овнером у вас заплановано на 1 ДЗ? Як ви плануєте їх проводити, адже ваші працівники навряд чи працюють по вечорам і вихідним

2) Вміння реалізувати його не в цейтноті

Ну ок задача нехай на 1 робочий день (але краще було б дати щось на 3-4).
Ви вже відсіяли більшість адекватних людей, хто не хоче витрачати вихідні на ваше ДЗ.

А ще у вас крута контора, адже вам так важливо перевірити, як людина працює на розслабоні.

1) Обидва пункти — 5-45 хв на співбесіді

З опосередкованим результатом, якщо кандидат хвилюється та тупить що чортяка.

Як ви зібрались перевіряти навички комунікації?

Це ж очевидно. Завдання дається не «зробити реалізацію фічи», а «зробити красиво». Що саме людина вважає за красиве та чи цікавить її думка протухт-овнєра буде з’ясоване під час додаткових запитань, які виникнуть в кандидата під час реалізації завдання.

Скільки сесій з продукт-овнером у вас заплановано на 1 ДЗ?

Нуль. Пошта для цього підходить краще за все.

Ви вже відсіяли більшість адекватних людей, хто не хоче витрачати вихідні на ваше ДЗ.

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

А ще у вас крута контора, адже вам так важливо перевірити, як людина працює на розслабоні.

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

З опосередкованим результатом

А з яким потрібно? Підходи до покращення рішення, якраз круто обговорити після кодінгу, щоб кандидат розповів чому він вважає ту чи іншу зміну покращенням.

Це ж очевидно. Завдання дається не «зробити реалізацію фічи», а «зробити красиво».

Красиво — це не правильне слово. «Робителі красиво» не потрібні, потрібні люди які розуміють трейдофф між зробити вчасно і досягти інших атрибутів якості (перформанс, розширюваність і тд).

Нуль. Пошта для цього підходить краще за все.

dou.ua/...​ks-pros-and-cons/#2076057

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

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

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

І як ці 2 твердження попали в 1 абзац?
У вас через всю аргументацію проходить 1 аргумент "комфортність умов"/"не в цетноті".
В реальному світі трапляються продакшн інцеденти, треба хотфікси, бизнес їде на виставку через 2 місяці і треба змінювати плани.
Людина, що не може мобілізуватись, нікому не потрібна. Ні, в принципі потрібна на суппорт проект, де треба просто білитись і не виступати.

А з яким потрібно?

Ви писали код в стресових ситуаціях? Ви зможете потім їм пишатися?

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

Щоб щось обговорювати, треба мати результат. Але який ви очікуєте результат за годину лайв-кодінгу?

Щоб такий кандидат хотів працювати саме у вас, йому треба щось запропонувати. Що ви можете запропонувати?

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

Гроші — ви сказали, що це не ваш варіант

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

Людина, що не може мобілізуватись, нікому не потрібна.

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

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

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

Ви писали код в стресових ситуаціях? Ви зможете потім їм пишатися?

Так можу, бо цей код вирішив бізнес проблему.

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

Трейдофф.
Замовник впевнений, що отримає ліцензію на процесинг фін інформації від регулятора. Система розробляється з цим припущенням. За 1.5-2 місяці до виставки, виявляється, що ліцензії будуть через півроку і тепер весь процесинг по грошовим операціям має бути в зовнішній системі з якою треба інтегруватися.
Запитання:
чи треба було закладати це в архітектуру і збільшувати скоуп проекту на декілька людино-місяців (система лоулейтенсі, тому оптимізації мають також бути враховані)?

Ви хочете сказати, що в стресових ситуаціях ви можете написати не гірший код, ніж в звичайному режимі?

Стресова ситуація — це як у фільмі «Риба-меч», але в реальності так ніхто не проводить співбесіду.
Якщо людина в стресі від розмови з іншим спеціалістом, то dou.ua/...​ks-pros-and-cons/#2074836

Так можу, бо цей код вирішив бізнес проблему.

Тобто вас не цікавить вартість розробки взагалі ніяк. Це неприпустима розкіш для продуктових компаній.

чи треба було закладати це в архітектуру і збільшувати скоуп проекту на декілька людино-місяців (система лоулейтенсі, тому оптимізації мають також бути враховані)?

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

Стресова ситуація — це як у фільмі «Риба-меч», але в реальності так ніхто не проводить співбесіду.

В реальності люди нервують набагато більше, ніж показують.

Якщо людина в стресі від розмови з іншим спеціалістом

То значить людина недостатньо впевнена в результаті співбесіди.

Тобто вас не цікавить вартість розробки взагалі ніяк. Це неприпустима розкіш для продуктових компаній.

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

Це риторичне запитання як на мене.

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

В реальності люди нервують набагато більше, ніж показують.

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

Якщо людина в стресі від розмови з іншим спеціалістом
То значить людина недостатньо впевнена в результаті співбесіди.

Ок, сходіть за посиланням яке я навів :)

Чого б це спеціаліст був недостатньо впевненим у результаті?
Фактично ми знову повертаємось до

У вас через всю аргументацію проходить 1 аргумент "комфортність умов"/"не в цетноті".

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

Судя по комментариям, большей части людей достаточно просто комменты друг друга почитать что бы понять что вместо работать они не захотят. А вы тут про тестовое на n часов/дней

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

То есть вы сначала наняли человека (пусть и на ИС), а потом дали ему тестовое задание? А смысл в чем?

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

бо помилки досить типові

Как много кругом идиотов. Все делают неправильно. Один я умный.

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

що мені треба не помічати меморі лік у рішенн

Мемори лик — это очень генерализированное понятие. Я встречал программистов, который любой статический класс называли мемори ликом. Да, в них потенциально могут накапливаться данные, но для этого должно совпасть очень много условий, а отказаться от их использования — практически нереально.
Но это не мешало многим называть их мемори ликом.

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

Заведіть краще окремий топік, напишіть там, що рахувати меморі ліком, буде цікаво

Вполне возможно. Но это гарантированная дискуссия на 100500 комментов.
И весь мой поинт в том, что такие дискуссии в процессе разработки софта — излишни. Именно поэтому над одной кодовой базой должен работать в идеале только один человек и сам выгребать все проблемы, которые создаст себе своим талантливым стилем. Когда появляются советчики — начинается битва ЧСВ. Я только по одним мемори ликам гарантирую простынь на месяцы с переходом на личности. Но это Доу, тут общаются и это нормально. А на проекте нужно деливерить фичи, а не языком молоть.

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

Ну якщо розгорнуто, то реальний проект для випробувального терміна зовсім не підходить.

Это что-то новенькое.

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

Чтобы начать что-то полезное и осмысленное делать не нужно знакомиться со всем проектом — достаточно ознакомиться со скоупом задачи. Которую, по логике, подобрали так, чтобы ньюкамер в принципе мог ее осмыслить (это уже ответственность лида/ментора/... — того, кто конкретно отвечает за онбоардинг) — в беклоге любого мало-мальски крупного живого проекта найдется 100500 несложных низкоприоритетных задач, до которых так руки не доходят. Тестовое задание ни о чем после приема на работу — это какая-то жесть.

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

«Сперва добейся», я правильно понял суть ответа? :)

«Прежде чем осуждать кого-то, возьми его обувь и пройди его путь...» ;)

Димитрий, а вы не хотите попробовать обсудить _суть_ вопроса, не скатываясь в пошлятину в стиле «кто ты такой»? Вы не находите немного странным считать, что вы тут единственный человек, который нанимал людей за свои деньги?

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

Аргументов хоть отбавляй:

1) Нанимая человека, которого вы уволите через месяц, вы теряете деньги как прямо (вы же правда заплатите человеку за его время?), так и косвенно — вам нужно начинать поиск сначала (скорее всего остальные приемлемые соискатели, от которых вы отказались в пользу нанятого-уволенного, вас не ждали и уже нашли работу). Ну и да, все это время работа, для которой вы нанимаете человека, все еще стоит.

2) Ни одно тестовое задание не гарантирует того, что человек не нафакапит в дальнейшем. Да осспади, все лажают рано или поздно. Так что без полноценной системы обеспечения качества (код ревью, тесты, you name it) вам все равно не обойтись. А раз так, то чем вы рискуете, давая ньюкамеру реальные задачи? Говнокод все равно не пройдет ни ревью, ни тесты (а если пройдет, то ваша проблема куда глобальнее, чем накосячивший новобранец).

3) Сам формат «я тебя нанимаю, но по результатам тестового могу уволить» (а вы же честно говорите об этом соискателям, не правда ли?) однозначно отсекает от вас мало-мальски профессиональных соискателей — зачем им ввязываться в эту удивительную лотерею, если есть полно работы кроме?

Гаразд, давайте я поясню свою позицію

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

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

Тобто, задача стоїть — дати кандидату максимально нафакапити за мінімальний термін і з мінімальними
наслідками для команди та замовника.

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

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

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

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

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

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

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

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

Щодо відповіді на ваші аргументи, Констянтин:

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

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

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

На все добре

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

Да мне можно — я вообще не настоящий сварщик, а маску на свалке нашел. У вас-то, в отличие от, все очень профессионально:

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

Не процесс — мечта просто. «Тестить задачи сложо, потому что проект сложно собрать».

Скажите, а когда через месяц вы выпустите бедного неофита из песочницы и датите ему взрослую лопатку — он начнет не с той же точки, с которой мог начать месяц назад? Что, хорошо сделанная тестовая задачка как-то гарантирует отсутствие косяков в боевом коде? А как вы обезопаситесь от этого, если у вас «проект собрать сложно»? Все это риторические вопросы, которые даже задавать неловко, не то что отвечать на них.

А вообще, учитывая некоторые особенности риторики, я думаю, что реальная причина такого необычного процесса рекрутинга одна и сформулирована вами вот тут

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

а все остальное понаписанное — дымовая завеса.

Якщо ви не працювали на складних проєктах, то це не означає, що їх взагалі не буває.

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

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

Що ж, каюсь ви мене викрили, занавіс.

Що ж, каюсь ви мене викрили, занавіс.

Вы и без меня отлично с этим справились, а я просто спросить зашел.

Ставил, педалили норм, перформили, клиент был доволен.
Может, кто-то технические собеседования проводить не умеет?

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

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

Скільки платите?

Ну DOU за пости не платить, мабуть щось знає, і я не буду

Ну DOU за пости не платить, мабуть щось знає, і я не буду

1) Платить
2) ДОУ не втрачає гроші, як це робите ви (свої, або свого роботодавця)

Ну коли заплатить, я з задоволенням почитаю

Ну коли заплатить, я з задоволенням почитаю
2) ДОУ не втрачає гроші, як це робите ви (свої, або свого роботодавця)

2) Я розумію що це вимога пояснити, чому я нераціонально витрачаю свої гроші?

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

2) Я розумію що це вимога пояснити, чому я нераціонально витрачаю свої гроші?

Ні, це нагадування, що ви знаєте до кого звернутись, коли зрозумієте що щось робите не так.

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

Ееее? Ну наприклад я набираю людей в команди.
Після того як людина виходить на роботу, «вправи» їй не дають, їй дають роботу. Щоб переконатись, що погана робота не попаде замовнику є такі механізми як організація комунікації в команді (ревью від інших девелоперів) та КуА процес.
Забезпечення якості — це постійний процес, виконання тестового розробником не гарантує якості делівері на постійній основі.

Ок, тут важливо, якщо ви наймаєте, ви втрачаєте власні гроші, коли щось пішло не так? Тобто, хто оплачує ризики, і хто зацікавлений них мінімізувати?

Тобто, хто оплачує ризики, і хто зацікавлений них мінімізувати?

Оплачує клієнт мого клієнта (ви їх назвали «ваші замовники»).
Зацікавлений у мінімізації ризиків я, бо від якості найнятих людей залежать мої бонуси і репутація в компанії/у замовника. Для компанії 1-2 місячні ЗП — це копійки.

Гаразд давайте може змінимо термінологію, скажімо, що це не «вправа» а самостійний проект для однієї людини, де я є замовником, а також я роблю ревью та QA, щоб не заважати процесу на основному проєкті?

Гаразд давайте може змінимо термінологію

Вам пора в українську політику: замість вирішення проблеми ви змінюєте назву.

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

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

А що робити коли ти продуктова компанія? А якщо іще мала? А якщо взагалі стартап з малим бюджетом?

Так і видно, як в таких умовах всі готові витратити 1-2 місячні зарплати бонусу за найм рекрутеру і іще 2 місячні за прекрасних два місяці розробника у режимі «пісочниця».

P.S: погоджуся тільки якщо ви берете якогось джуна/трейні, але є багато практик вводу їх і в реальний проект одразу.

Дивіться, ви всі мабуть не зовсім зрозуміли ідею «пісочниці».

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

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

Ну я бы на его месте тоже так поступил. Если чужой код хороший, почему бы его не использовать?

Как говорили классики: Whenever possible, steal code.

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

А, ну і таке, він же ще його спотворював, щоб я не впізнав :)

Я ж наймав програміста, а він виявився бізнесменом, звісно, чиє тут ЧСВ витримає, я ж теж бізнесмен..

Дивний підхід — це не в мене, а в нашої вищої освіти. Тому вона й ніяка не освіта взагалі, а бізнес

З чого це витікає?

діком по ліпс вже добряче наводили)

и оформление по кзот..? или все таки фоп сотрудничество?..)

Не бачу, яке це має значення у контексті цієї дискусії

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

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

Не дивно, що на Ваш бік ніхто не стає. 99% програмістів спочатку шукають готове рішення і тільки якщо нічого не знайдуть, пробують писати самостійно.
Мабуть найбільш зрозумілим буде приклад використання CMS чи фреймворків для проектів, замість того щоб писати їх на голій мові програмування.
Якщо рішення тестового мало бути унікальним і вірним, саме тестове мало бути таким якого ще ніхто не бачив, відповідно його було б ніде «позичити».

Ліричний відступ:
коли я був початківцем, пробувався на позиції провідних спеціалістів, де перед інтерв’ю були тестові завдання — які я не лінувався робити по 4-ри дні. Після перевірки завдання, з ахами та охами, мені пропонували пройти інтерв’ю, де я себе дуже впевненно почував, до того моменту коли мене питали про портфоліо та досвід. Якщо б мені стало духу навішати макаронів і набити портфоліо проектами яких я не робив, мене б точно прийняли.

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

Не дивно, що на Ваш бік ніхто не стає

ну я ще над цим попрацюю :)

99% програмістів спочатку шукають готове рішення

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

Але давайте не робити підміну понять. Мета цього завдання для кандидата була не виконати тестове, а отримати роботу.

коли я був початківцем, пробувався на позиції провідних спеціалістів

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

Як на мене, тестове показує лише працелюбство — а не вміння

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

Та й взагалі працелюбство — то зовсім непогана риса для робітника, як на мене

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

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

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

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

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

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

Наостанок прохання до кандидатів, особливо джуніорів — пишіть цікаві pet проекти. CRUD можна по більшості згенерувати і він не дає ніякої інформації з того, який ви програміст. Додайте математики, алгоритмів, конкурентності, розгалуженості, безпеки/шифрування, інтеграції. І не забувайте про readme.md будь ласка — не залишайте те, що за вас зробив starter. Додайте інформацію про вимоги, реалізацію, відомі проблеми, збірку та запуск, налаштування, авторизацію, пару скріншотів. I ще, будь ласка, тримайте свої рішення при собі, не діліться з іншими кандидатами, бо нагадаю, що вигадати цікаві завдання досить складно — дозвольте вашим друзям вирішити завдання самостійно, вони також у цьому зацікавлені.

У цій дискусії помітно що ті, хто відповідає за найм у більшості своїй кажуть, що без тестового не обійтись.

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

Ну наприклад:

«На мою думку, тестові необхідні розробникам усіх рівнів»
«Это полезно, потому что есть немало людей, которые мнят себя „выше кода“ и попросту забыли как кодить» (про парне, але і до тестових відноситься також)
«Как человек, который регулярно проводит технические собеседования, могу сказать, что тестовое задание очень упрощает процесс найма»
«приходилось собеседовать людей, так вот из тестового понятно куда больше чем из интервью как по мне»
«Тестовое можно десять раз спокойно перечитать, вникнуть, погуглить итд , а если непонятно спокойно сформулировать вопросы»
«имею опыт разработки более 20 тестов по R...Как по мне, тесты нужны.»
" я как манагер не принимаю практически ни единого кадрового решения по результатам собеседования без тестового задания"
«Если человек не может за часовую сессию накодить черновое решение типовой задачи, типа тех, что я описал выше, то этот человек может идти домой. »
«Коли наймаєш і людей без досвіду, то без тестового завдання нікуди.»

Звісно, ще порахувати я не візьмусь, тому може і не більшість

Звісно, ще порахувати я не візьмусь, тому може і не більшість

Рахувати не рахували, але видали свою думку за думку бильшості.

«Если человек не может за часовую сессию накодить черновое решение типовой задачи, типа тех, что я описал выше, то этот человек может идти домой. »

А це взагалі цитата про задачу на співбесіді, а не про тестове :)

«Коли наймаєш і людей без досвіду, то без тестового завдання нікуди.»

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

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

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

Тільки :)
Все інше легко вирішується на співбесіді довжиною 45-120 хв. А те що не вирішується, так само не вирішується тестовим.

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

Наведу приклад із життя котрим пересікся — шукали middle/senior фронта. Було тестове з близько 50 кандидатів на етапі проговоорення деталей відпало близько 40. Решта ж погодилась, а потім просто зникла і не відповідала. Через місяць, тестове вирішили забрати, і кандидата знайшли вже до кінця тижня. Він працює вже майже рік і жодних нарікань.

Звісно, я розумію чим таке бажання може бути викликане. Хіба не простіше на етапі самої співбесіди розібрати якийсь кейс. Можна взяти декілька прикладів які вже у вас проектували і запропонувати розібрати цей кейс. Дзінатися, які практики, техніки, шаблони використовувати. Погодьтесь, якщо кандидат напише ідеальний код з розмеженою бізнес логікою, намапить на будь-яку інфраструктуру, та іще напище прекрасний readme.md з документацією — після найму він буде писати у стилі всього проекту, який встановила команда/архітектор/сто/somebody.

На жаль на співбесіді часу дуже замало, треба ще й питання задати

Якраз на співбесіді часу для цього достатньо. В іншому разі, завжди можна пояснити, що вона буде в два етапи, наприкад. Можливо три. Але варто донести це до людини. По власному досвіді і сам був на декількох етапах, і якось доводилось наймати де було три етапи (скринінг не враховувався в ці три): Techlead проекту, Product Owner проекту, Engineering manager в компанії.

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

Я так поміркував, маю ще щось додати

На жаль, така поведінка «крутих кандидатів» здається мені досить інфантильною та нелогічною.

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

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

Ну смотрите.
Вот я кандидат. Мой час стоит 100 баксов.
У меня три проекта, на всех платят одинаково, но на одном хотят еще и тестовое на 5 часов.
С какого перепугу я должен подарить им 500 баксов? Шанс, что они наймут — не 100%, тестовое не окупится никогда.
Считаете, что окупится? Окей, а если проектов 6 и из них 4 — с тестовым? все еще окупится?
Я, как фрилансер, тоже отбрасываю сразу проекты где просят тестовые или видеозвонок «чтоб все точно показать». Пробывал, только трата времени это.

О, та ви поважна людина, з таким рейтом. Навіть ніяково вам тут щось розповідати.

Дивіться, окупиться чи ні — то вам вирішувати, розповім нижче.

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

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

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

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

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

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

Ну але не всі люди однакові.

Не не не. Несколько часов — это если только ваша крутая компания выдала тестилово.
А если таких 3,4,5?
Тут уже можно и неделю времени набрать.
Просто вы почему-то считаете, что вы предлагаете средние условия с тестовым, другие НЕ предлагают, но кандидат будет считать что ок делать вам тестовое.
Какой-то очень странный подход.
Обучение применимо ко всем следующим наймам. А это тестовое — только к вам и вы можете еще и не нанять по его итогам.
Почему это в компаниях без тестового — ваших конкурентах — будет «не цикаво»?

Я как «больше бизнесмен» могу вам сказать, что отменяются постоянно даже контракты где сказали «ок, нас все устраивает», «давайте договоримся по скайпу», по скайпу тоже «ок, начинаем работать завтра» и потом контракт не заключается.
Более того, есть какое-то(значительное, порядка 30%) количество клиентов, кто использует разговор для получения информации и потом идет к кому-то другому( и мне в чат пишут колеги типа «вот нас наняли, сказали сделать вот так лучше и сослалися что ты сказал»)
Что уж тут говорить про найм, если количество компаний которые вам подходят БОЛЬШЕ ОДНОЙ.

Почему это в компаниях без тестового — ваших конкурентах — будет «не цикаво»?

Я такого не казав, почитайте уважніше, що я кажу:

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

Тобто, я кажу, що відкидати компанію тільки тому, що вона дає тестове — нелогічно. Є більш суттєві критерії.

могу вам сказать, что отменяются постоянно даже контракты

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

Тобто, я кажу, що відкидати компанію тільки тому, що вона дає тестове — нелогічно.

это просто бизнес ))

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

можно конкретную арифметику как именно это выглядит будет?

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

Час змінюється, люди також

боюсь вы и тут заблуждаетесь )) весь обозримый час ваши люди и были именно такими

Логично -нелогично.
С моей точки зрения нелогично тратить 20 часов на 5 тестовых, в результате пройти в другой проект, где тестового нет. Тут тупо выкинуты в трубу 20 ваших часов.

Конечно, я откидываю. Поскольку не могу позволить себе все свое время тратить на выбор лучших, мне же еще работать когда-то надо.
Факт, что все самые длительные контракты ничего даже похожего не требовали и заходили по референсам.
А там, где куча общения и многочасовые интервью было всегда 10-20-40(в одном случае за 15 лет) часов и на этом досвиданья, на следующее задание еще 4 часа интервью и согласований, неоплачиваемых, да. И да, эти же люди пытаются понизить рейт, ну и что, что у вас есть контракты по 120, а нам сделайте за 20 в час, пожалуйста. И еще и ограничте сверху 10 часами, а мы вам доп требований накидаем. И сделайте обязательно нам прям сейчас. Ну и что, что мы согласовываем месяц! А почему вы несогласны? Ну у нас же интересно!
Потому да, нормальный специалист будет таким товарищам либо ставить условия на оплату х2 или х3, либо пошлет их лесом кроме случая «сейчас скучно, почему бы и нет».

С моей точки зрения нелогично тратить 20 часов на 5 тестовых, в результате пройти в другой проект, где тестового нет. Тут тупо выкинуты в трубу 20 ваших часов.

Ну я й не казав, що так розумно робити. Розгляньте всі пропозиції, поспілкуйтесь вживу, отримайте інформацію, оцініть. Відкиньте неадекватних, жадібних, ітп. Подивіться на тестові і на умови. Відкиньте знов неадекватних та нецікавих. Може тестових вже й не залишилось — то гарно. Якщо залишилось — погодьтеся зробити ті, що вам більше до вподоби, але попросіть щось з їхнього боку — обов’язкову рецензію або аванс. Скажіть, що у разі підписання контракту аванс зарахуєте у вартість послуг (або не кажіть). Якщо не погоджуються — посилайте. Люди більш охотно жертвують відношеннями, у які вони не вкладаються, тож вимагайте якось вкластися і з їхнього боку. Наприклад, ретельно виписана специфікація на тестове — також «вкладання»

Факт, что все самые длительные контракты ничего даже похожего не требовали и заходили по референсам.

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

Дмитрий, поймите, вы так поймаете тех, кто готов «вложится» а не «работать».
Если у меня есть хотя бы два предложения одно из них с необходимостью «влаживаться» больше, и похожими условиями (а оно так и бывает обычно), то с какого перепугу я должен тратить свое время?
Я понимаю, что ВАМ лично это выгодно. Но исполнителю — нет. Вам все тут говорят, что если вы не супер-компания вы будете задвинуты подальше, на год-два. Потому, что так и будет, 5-10 предложений и надо выбрать.

З моїм бізнесом все ок поки що, дякую.

Я тільки хотів спитати про ваш прогноз, чому на рік-два? Ви щось знаєте? Що зміниться через рік-два?

Ну через год-два просто выкинут в корзину.

Ок, чекатиму на вас у корзині :)

Тобто, я кажу, що відкидати компанію тільки тому, що вона дає тестове — нелогічно. Є більш суттєві критерії.

Есть всего две причины чтобы не отбрасывать сразу компанию с тестовым заданием:
— Оплата более чем на X% выше чем по рынку
— %COMPANY_NAME%, доменная область либо стек технологий которые по каким-либо причинам очень интересны
К Украине второй пункт применим достаточно редко.

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

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

или видеозвонок «чтоб все точно показать»

это вообще 146% адище

Это недавно было, недели две назад. В результате на звонке ходили по кругу в виде «пока не предоставите хоть что-то, оценить не могу — ну нам проект достался так, доков нет, мы ничего не знаем», договорилися начать и на этом потерялися.

На жаль, така поведінка «крутих кандидатів» здається мені досить інфантильною та нелогічною.

Чому? Людина, яка повідомляє, що не робиттиме тестове з будь-яких власних причин економить час обом — і собі, і вам. Інша справа мабуть, коли людина погоджується і пропадає. Я б іще зрозумів, якби через, наприклад день, людина б написала, що не буде чи не може виконати. Просто пропадати без фідбеку не ок. Це міжіншим і рекрутерів стосується, котрі після співбесіди можуть «зникнути».

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

Погоджуюсь.

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

А ось тут ні :)

Вашою ж аналогією:

Нагадують тих самих студентів, яким здається, що вони краще влаштуються у житті, якщо будуть перездавати СВОЇ лаби, тому викладачу, який не буде після них давати обов’язкове завдання із зірочкою.

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

Людина, яка повідомляє, що не робиттиме тестове з будь-яких власних причин економить час обом

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

А ось тут ні :)

Ну я головне хотів донести, що одні ставлять собі мету — здати лаби, а інші — отримати знання. Думаю тут ми з вами згодні.

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

Є люди, які проти тестових завдань. Я за свою довгу кар’єру розвинув такі правила:
1) Тестове завдання припустимо, якщо у компанії є сумніви щодо кваліфікації/навичок співробітника. Наприклад, якщо це junior/trainee.
2) Якщо його виконання займає 2 години і менше, його можна робити безкоштовно, якщо більше — то за гроші. Особливо якщо це тестове «на тиждень».
3) Тестове завдання містить в собі роботу з технологіями, які використовуються на проекті
4) Але найчастіше тестове завдання можна замінити на live coding/design прямо на співбесіді, адже тут можна і поспілкуватися, і обговорити рішення, зважити всі «за» і «проти», тобто зрозуміти як людина думає. Але інтерв’юери зазвичай лінуються це робити і замінюють тестовим.

Але найчастіше тестове завдання можна замінити на live coding/design прямо на співбесіді,

Сложновато при этом проверить навыки работы с конкретными технологиями, используемыми на проекте.

Технічна співбесіда триває 1 годину (або 1.5 години).
Я вважаю, що якщо за цей час інтерв’юер не зміг зрозуміти, наскільки добре кандидат знайомий з тією або іншою технологією, то він просто профнепрігоден(інтерв’юер).
Принаймні це легко перевіряється питаннями і use-case типу:
1) Як би ви вчинили (вирішили задачу) в разі таких умов?
2) Які best/worst practices/design patterns існують для тієї чи іншої технології?
3) Які переваги та недоліки у такого підходу?

Абсолютно не сложно. Как показывает практика, хватает 15 минут, чтобы понять, стоит ли продолжать или можно сворачиваться, при этом даже не дойдя до какой-либо задачи. Все остальное от Лукавого. Западные товарищи — они вообще не устраивают таких стресс-интервью, как у нас. У нас вообще какое-то сборище танцоров на костях и не самоутвержившихся (эпитет можно выбрать по вкусу и в меру воспитанности) господ-интервьюверов. В общем — начинай со сложного и к простому для Senior и от простого к сложному для Junior.

Категорически не согласен с пунктом 3: низкоквалифицированный кандидат у которого эта технология была на прошлом проекте покажет по крайней мере неплохой результат на задаче уровня тестового задания. Высококвалифицированный кандидат который работал с аналогами, если не потратит день времени, покажет не очень хороший результат. Знания технологий с намного меньшими искажениями проверяются в разговоре на тех. интервью. А тестовое задание должно быть разрешено выполнять на том стэке который кандидат знает лучше всего. Если тестовое задание предполагает что с технологией с проекта «можно по ходу разобраться», то с аналогом проверяющий тоже может «разобраться по ходу». Если резюме кандидата читали перед тем как выдать тестовое то и после получения решения ничего удивлять не должно

Лично я не против тестовых с одним условием: обозначать временные рамки, а не давать тестовое которое нужно сидеть и делать неделю. А там уже соискателю решать стОит ли тратить время на тестовое или просто забить.

Как человек, который регулярно проводит технические собеседования, могу сказать, что тестовое задание очень упрощает процесс найма. В основном это:
1) фильтр красивых резюме, за которыми ничего не стоит
2) возможность обсуждать технические темы на самом собеседовании, привязывая их к решениям из тестового задания

Вопрос в том нафиг мне тратить на тебя время, если в очереди ещё десять собеседований, без тестового? Работать в нашем банке большая честь?

Я понимаю, что таким образом определенные кандидаты к нам просто не доходят. Тем не менее, преимуществ мы имеем с этого больше.
Я полагаю, что тестовое можно будет убрать, когда будет совсем уж мало кандидатов приходить. Пока мы имеем обратную ситуацию и делать каждому техническое собеседование весьма времязатратно

Я полагаю, что тестовое можно будет убрать, когда будет совсем уж мало кандидатов приходить

Вот.
Подобные извращения появляются от избытка кандидатов, когда работодатель уже не знает как сформировать шорт-лист.
Именно поэтому в своё время и послал этот энтерпрайз и пошёл в Андроид. Чем меньше таких же как ты, тем меньше морочат голову на собеседованиях и потенциально больше заплатят.

А ви не думали, що може все навпаки, і в ті компанії тому і важче попасти, що вони кращі, тому і шорт-лист.

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

в ті компанії тому і важче попасти, що вони кращі

Чем эта компания может быть лучше, ну например, моей нынешней или прошлой?
Даже если там зп выше рынка — это не повод.
Т.к. за доп зп всегда будут доп обязанности, а они мне не нужны.

Перспективами професійного росту

Перспективами професійного росту

Конкретизируйте, плиз. Куда и зачем этот рост нужен?

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

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

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

На співбесіді хвилюється, а коли треба доводити свою думку ліду — спокийний?
На співбесіді неправильно зрозумів питання і не перепитавши відповів неправильно, а тестове завжди розуміє і робить рівно те що очікували?

Так же приходилось собеседовать людей
да и говорить легко, с вот что то путное сделать не каждый может

dou.ua/...​ks-pros-and-cons/#2074303

З вашим досвідом співбесід, ви не бачите «говорунів»? Тих хто вміє лише заливати видно в перші 15 хв.

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

Тестовое можно десять раз спокойно перечитать, вникнуть, погуглить итд , а если непонятно спокойно сформулировать вопросы

У меня лично опыт не большой, а вот более опытные люди пропускали говорунов только так )

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

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

если непонятно спокойно сформулировать вопросы

И коли на них вам дадуть відповідь? Ви будете робити тестове в неробочий час, а команда буде в неробочий час — не працювати :)

Тестовое можно десять раз спокойно перечитать, вникнуть, погуглить итд

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

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

Ну по поводу ответов на вопросы по ТЗ как ответят так ответят , всегда когда давали ТЗ говорили задавайте вопросы без проблем )

Гуглить можно мануал на библиотеку что не использовал или забыл уже итд а на собесе — забыл и все на выход )

мне как то везёт значит — ни кто не кусает и не думает что за дурачка взяли,

А чого тоді ви хвилюєтесь на співбесіді?

Гуглить можно мануал на библиотеку что не использовал или забыл уже итд а на собесе — забыл и все на выход

Вийшли і сказали дякую, що не попали до людей які на таке звертають увагу на співбесіді :)

Ну я лично не особо то волнуюсь я скорее экстраверт, но все равно затупить могу, но люди разные, видел многие волнуются аж заметно.

«Вийшли і сказали дякую» — ну раньше так и делал, но это ж большинство собеседований ± такие время убивается тьма, но это правда наши местные галеры, с иностранными у меня лично позитивный опыт

Вы серьезно спрашиваете вплоть до названия API??? Бог ты мой, если это так. Я, на пример, могу помнить какие-то классы и как они работают в той или иной системе. Но досконадлно всех методов не помню. Да и зачем? когда все это с каждой версией фреймворка может измениться? Я тут уже писал коммент о решении задачи в привязке к API. Так вот, сейчас когда IDE лучше знает названия методов/функций/переменных — то зачем это вообще держать в голове. При этом, что они как бы имеют свойство устаревать. Да еще, если не одну технологию свичнули.

Ну вот представь себе прихожу на собес а меня спрашивают как в каком-то сдк классе код внутри работает что там куда записывается а память итд и методы перечислять тоже было ... и на листике код писать и компилировать вот тоже норм практика ))

Я то не спрашиваю, я предпочитаю в код смотреть

Вариант — gracefully заканчивать это все. Это можно спросить в скоупе, если вот в каком-то ближайшем тайм-рейже человек с этим сталкивался, иначе — это все от Лукавого. Или кто-то пробует за счет кого-то самоутвердиться. Как вариация на тему, кто-то из интервьюверов прочитал что-то из книг для себя интересное и решил об этом спросить.

Моя улуюблена тема знову на ДОУ. Статтю не читав, тому сподіваюсь, що заголовки підібрані правильно.

Добре для тих, хто боїться співбесід

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

Тестові — це досвід, що можна вказати в резюме

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

Шанс потрапити у професію

А ось тут правда. Якщо ти ніхто і нафік нікому не здався, то роби тестове і не жужжи. Там вище писали про приниження, але будемо реалістами: більшість буде роботи тестове для умовного «Амазону на 150К і Х1Б», так само як і трейні без досвіду або синьйор з іпотекою і без роботи. Інше питання, чим обернеться такий найм через 6-12 місяців.

Але будь-яка думка будь-кого тут не має значення.
Тестове — це інструмент. Цей інструмент дуже ефективний для задачі «фільтрації великого вхідного потоку». Для всіх інших задач (процесу найму) є більш ефективні інструменти.

На правах реклами:
dou.ua/...​signment-for-job-seekers

Есть такие тестовые, которые делаешь с удовольствием, когда находишь чего-то новое
А есть такие, которые нафиг никому не нужны, особенно касающиеся оптимизации без понимания картины в целом

Если интересно — имею опыт разработки более 20 тестов по R для hackerrank.com, проверки тестов других разработчиков и прохождения тестов от крупных компаний, в которых половина тестов были «моими». Из полученного опыта могу сказать, что:

1. Хороший тест должен содержать «понятное» техническое задание, внятное описание результата на выходе, и «видение» основных действий как его можно достичь за конечное число операций.

2. Тесты сами по себе могут и содержат ошибки. Поэтому даже правильный код может показывать «неправильный» результат.

3. Ограничение времени выполнения тестов в он-лайн и наличие разных по типу заданий практически не позволяет получить качественный код. Нормальная практика в реальности — это разработка кода, который «работает» и затем его улучшение. Тесты — это тоже код, который можно улучшать бесконечно. Если разработчик не умеет улучшать свой код, а делает только «работающие» PoC — то на реальном проекте с ним могут быть проблемы.

Как по мне, тесты нужны. Но разные для разработчиков разного уровня. Например, на знание функций языка можно дать пять тестов, на знание решений доменных задач — два теста, а на знание каких-то специфических приемов и технологий — скажем, один максимум.

Отношусь негативно, обычно говорю что в текущий момент занят, обязательно напишу пожже как освобожусь от текущих дел/собеседований. Если компания с хорошей репутацией, пишу через некоторое время — что мол спасибо, поиск работы окончил, но в следующий раз свяжусь если будут вакансии.

Уже мульйон страниц измарано и сотни Горшков побито вокруг вопроса который не стоит выеденного яйца.
Ответ на который помещается в одно предложение «Если можешь попасть туда куда хочешь и получить столько сколько хочешь без тестового — не делай»

У меня как-то так получалось, что компании дававшие тестовое задание в итоге вели себя наименее порядочно. Так что нынче для меня не оплачиваемое тестовое — красный флаг.

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

У нас тестовое кандидаты делают до технического собеседования, это их возможность «выпендриться» в коде. Потом есть о чем поговорить на собеседовании.

вкратце ИМХО — тестовое делал только когда подавался на джун позиции. Сейчас если требуют тестовое — мы не подходим сразу(благо это происходит редко). Задачку во время собеса — можно, НО эффект волнения очень мешает и может дать неверное представление о человеке.

Задачку во время собеса — можно, НО эффект волнения очень мешает и может дать неверное представление о человеке.

Тут важливі моменти:
1) Зрозуміти (під час інтерв’ю), що кандидат не зробив задачу, бо хвилювався.
2) Розуміти, що така задача — це лише відправна точка. І перейти навіть з невиконаної задачі на ті теми які потрібно проговорити.
3) Напевне найважливіше і найскладніше — підібрати адекватну задачу, а не просто топ літкоду.

На протяжении своей с позволения сказать карьеры я практически постоянно работал и девом и манагером одновременно. Мое мнеие таково: на сегодня я как манагер не принимаю практически ни единого кадрового решения по результатам собеседования без тестового задания. Аднако :) речь ни в коем случае не идет о тасках на 4 часа (что пахарошему занимает 2 дня, как отмечено выше). Я даю задания на 15 минут максимум во время интервью (в исключительных случаях — домой с условием прислать ответ до конца рабочего дня). Потом вместе разбираем что так и что не так. Ессно учитываю фактор стресса. Зачем? главный ответ простой — девелоперам деньги платят за написанный качественный код (т.е. такой который работает так как ожидает заказчик) а не за знание теории и умение ее презентовать. Во вторых, часто это те же или очень похожие задачи которые захочет на собеседовании поставить заказчик — таких клиентов еще много, и для US это нормальная практика.
Ну и в-третьих, было замечание про приниження для програмерів ... повірте, ніхто так не принижує кандидата як він самий коли пише код який ні на які компілєри не налазить :( На жаль немало є кандидатів, які мандрують з контори в контору і розповідають «я — гуру, я — учитєль! Несіть мені усі по три рубля...», але на практиці код писати не вміють, або вміли 5 років тому. Я їх називаю «трахарі-тєорєтікі», такі люди вносять суттєвий дискомфорт в команду, і невеличка тестова задачка для них чудовой фільтр у будь-якому разі: і тоді, коли вони відмовились її писати, і тоді коли написали брєд.

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

Це Ваша думка. А от один з ТС пише:

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

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

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

Стал бы я выполнять тестовое задание сегодня? Разумеется! Если бы до этого все другие компании на рынке дали бы мне отказ. Вероятна ли такая ситуация на практике? Конечно нет.

Со стороны же интервьюера, помимо демонстрации знаний и опыта, мне гораздо интереснее увидеть snippet или, если позволите, sneak peek того, как человек работает. В идеале — сессия парного программирования минут на 40-60. Посмотреть вживую как человек в любимом IDE делает наброски кода, чистит его, пишет один юнит тест. На примере простой задачи типа «1. прочитай текстовый файл с диска 2. Замени в тексте фразу на другую 3. Сохрани файл на диск. 4*. Добавь минимальную обработку ошибок.».
Это полезно, потому что есть немало людей, которые мнят себя «выше кода» и попросту забыли как кодить. Такая простая сессия выведет их на чистую воду и отправит их в следующую дверь, где ищут Solution Architect’ов и прочих Principal UML Artist’ов. Тоже нужные люди.

В идеале — сессия парного программирования минут на 40-60.

О, а вот это интересный поинт. Интересно, сколько синьоров-помидоров, топящих здесь за «тестовые не нужны», согласны взамен на часовую сессию парного программирования?

Почему бы и нет.

Вполне себе неплохая притирка, можно проявить «культуру» программирования, подход к решению задачи.
Тут же задавать уточняющие вопросы, отвечать на встречные.
Увидеть, как будущий коллега относится к чужому коду.
± подобное будут и во мне рассматривать.

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

Но чаще всего за тестовые задания не берусь.
Иногда лишь что-то можно добавить к себе в портфолио, как пример, который можно показать.

Так я не говорю, что нет (я бы, наверное, тоже этот вариант предпочел при возможности выбирать). Просто мне кажется (*перекрестился*), что у нас тут нарисовалась бы сильная положительная корреляция, и приверженцы позиции «никакого тестового» в основном так же не придут в восторг от лайв кодинга... Возможно, ошибаюсь.

Не соглашусь, на лайв кодинге можно задать вопрос, порассуждать вслух, уточнить на каком уровне абстракции достаточно остановиться и даже если ты где-то ошибся/запоролся — собеседующий вполне может оценить уровень, к тому же это обычно реально укладывается в 30-40 минут.

А оффлайн тестовые, как правило: хреново описаны, хреново заэстимированы и в 80% случаев из личного опыта — остаются без подробного фидбэка.

Если это лайв кодинг какой-то более менее приближенной к практике задачи, а не реализовать в коде какой-то высер из сдвига горы фудзиямы. Про лампочку и вагоны например.

не нужна никакая «часовая сессия» простой пример на 1-2 функции простого функционала можно набросать грубо за 5 минут для этого даже ide не нужна можно «на бомажке» или скажем на доске как посаны с фхтангов делают ))

толпа народу тупо не умеет в код как концепцию при этом сказать что они плохие ребята вроде как и нельзя а вот что с этим делать как это решать я пока х.з.

Со стороны же интервьюера, помимо демонстрации знаний и опыта, мне гораздо интереснее увидеть snippet или, если позволите, sneak peek того, как человек работает. В идеале — сессия парного программирования минут на 40-60. Посмотреть вживую как человек в любимом IDE делает наброски кода, чистит его, пишет один юнит тест.

За 8 лет в программировании в разных компаниях (от шлюпки на 40 человек до лидеров украинского аутсорса) я не видел ни одного программиста, код которого понравился бы любому другому программисту.
Всё, что может проверить интервьюер — это насколько корректно человек подходит к решению конкретной поставленной задачи. Писать для этого код, который никогда не будет запущен — пустая трата времени.

За 8 лет в программировании в разных компаниях (от шлюпки на 40 человек до лидеров украинского аутсорса) я не видел ни одного программиста, код которого понравился бы любому другому программисту.

Ну вот и увидели первого :) Мне нередко нравится код кандидатов, даже начального уровня, даже если бы я написал код иначе. Тут дело в культуре и майндсете — с чем в Украине, как известно, беда. Я изначально подхожу к оценке кода кандидата, или коллеги во время код ревью, если уж на то пошло, с позитивным отношением и даю человеку benefit of a doubt в субъективно спорных ситуациях.
«Я уверен, что ты напишешь хороший код, но постарайся не ударить в грязь лицом» вместо, «Я уверен, что ты напишешь говно, но попробуй меня переубедить».
Если кандидат, к примеру, для проверки переменной напишет цепочку if-else вместо switch, то я это подмечу и спрошу почему switch может быть лучшим выбором в данной ситуации и жопа у меня гореть не будет. Если кандидат согласится, то мы это исправим. Или аргументированно отвергнет предложение — я же тоже могу ошибиться или не понять ход его мыслей. Потому и сессия парного программирования.

Но это отступление, на самом деле цель такой сессии вовсе не в том, чтобы проверить, сможет ли человек произвести и запустить код который мне субъективно «понравится». Цель — понаблюдать за процессом кодинга. Конечный результат почти не имеет значения.

Всё, что может проверить интервьюер — это насколько корректно человек подходит к решению конкретной поставленной задачи.

Для этой цели существуют другие этапы, такие как техническое интервью по платформе или системный дизайн. Там можно всласть обсуждать различные задачи и подходы к их решению.
А я говорю про этап кодинга и здесь надо кодить. Что кодить — не имеет принципиального значения. Не нравится моя задача с файликом — откажись и предложи любую другую себе по душе. Нравится работать с сетью? Ок, давай напишем один запрос на Weather API и распечатаем в консоль декодированный ответ; и один юнит тест, который проверит, что декодирование работает правильно.

Писать для этого код, который никогда не будет запущен — пустая трата времени.

В корне с этим не согласен. Любой кандидат на позицию инженера, особенно с приставкой Senior должен виртуозно владеть хотя бы одним ЯП и одним доменом. Если человек не может за часовую сессию накодить черновое решение типовой задачи, типа тех, что я описал выше, то этот человек может идти домой. Или на позицию Solution Architect как я уже сказал — там кодить уже не нужно.

Если кандидат, к примеру, для проверки переменной напишет цепочку if-else вместо switch, то я это подмечу и спрошу почему switch может быть лучшим выбором в данной ситуации и жопа у меня гореть не будет.

Изи. Если проверяем только одно условие, то какой switch?
Там тогда будет if без вариантов.
Но потом у меня может добавиться проверка второго условия. Возможно, вообще в тестовых целях (в коммит не пойдёт). Я сразу же должен переписать решение на switch?
А если перепишу на switch и второе условие окажется потом ненужным?
А если не перепишу и окажется нужным?
Тогда будет некрасивая цепочка if-ов. Которую я перепишу на switch, когда определюсь с тем, какие условия мне будут нужны, а какие — нет.
И в этом случае подобный вопрос интервьюера не уместен — т.к. мы потратим очень много времени и усилий на объяснение ему всех этих перипетий мотивации того или иного решения. И это ещё элементарный случай. Бывают мотивации намного менее очевидные. А Вы уже хотите делать по этому какие-то выводы о кандидате.

Цель — понаблюдать за процессом кодинга.

На мой взгляд, в кодинге важен результат, а не процесс.
Например, нормальный процесс кодинга — это в случае затыка пойти поиграть в пинг-понг и выпить стакан лимонада на кухне глядя в окно, по ходу молча набрасывая ещё один вариант, который надо попробовать и посмотреть, что получится.

Любой кандидат на позицию инженера, особенно с приставкой Senior должен виртуозно владеть хотя бы одним ЯП и одним доменом.

Уровень владения языком — это уровень знания теории. Давить пальчиками на клавиатуру, зная что и откуда получается, уже несложно. Даже если подзабыл особенности работы с какой-то библиотекой, всё можно за минуту нагуглить.
А вот если человек не понимает, как к решению задачи подойти — тут уже да, он её не решит даже с Гуглом.

Изи. Если проверяем только одно условие, то какой switch?

Я сказал «проверяет переменную», а не «проверяет одно условие». if a == b else if a == c else if a == d и т.д.

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

И то и то важно. Поэтому есть этап для одного и есть этап для другого. Это не эксклюзивный выбор, и одно из другого не следует.
Уметь хорошо рассказать/написать/нарисовать «как решить эту задачу» — это крайне важный навык, особенно для тех, кто «над кодом» — архитекторов, лидов, инженерных менеджеров т.д. Сесть и в разумный срок и с разумным уровнем качества закодить это решение — это другой крайне важный навык, особенно для тех кто «в коде» — сеньоров. И простая типовая задача с файликом или запросом в сеть это покажет. А без постоянной практики этот навык очень и очень быстро загнивает.

Уровень владения языком — это уровень знания теории. Давить пальчиками на клавиатуру, зная что и откуда получается, уже несложно. Даже если подзабыл особенности работы с какой-то библиотекой, всё можно за минуту нагуглить.

Но это попросту не так. Приведу лично себя в пример. Я достаточно хорошо знаком с теорией и практикой работы компилируемых языков (ковыряюсь в LLVM на досуге) и в чуть меньшей степени — интерпретируемых, хотя опыт с Perl дал возможность познакомиться с большинством особенностей, которые его последователи себе забрали. И вот сейчас я взялся за Python. Я уже знал все, что мне нужно, чтобы решать с его помощью типовые задачи ещё до того, как закончил читать вступительную главу книги Fluent Python. Но у меня нет идиоматического мышления на этом языке и активного навыка его использования. Мой код работает, он решает задачу, но он не pythonic. Я могу с лёгкостью подготовиться к интервью в стиле 100 вопросов по Python и ворваться на собеседование на галеру. Могу с упоением рассказывать, как решать те или иные задаче (это language agnostic, anyway). И если меня не заставят вживую начать кодить, то есть огромный шанс, что я их проведу на мякине. А потом буду на работе проверять, сколько вкладок с запросом «how to do X in Python» может держать мой браузер открытыми, прежде чем он крэшанёт.
А, погоди, ведь именно так многие люди и вкатились на свои текущие должности!

a == b

Это одно условие.

a == c

Это — второе.

a == d

Это — третье.

Вот яркий пример, как 2 разных программиста по-разному видят один и тот же элементарный код.

Сесть и в разумный срок и с разумным уровнем качества закодить это решение — это другой крайне важный навык

Если человек это решение вывел сам, а не ему его спустили сверху, он абсолютно точно сможет его закодить в адекватное время.

А без постоянной практики этот навык очень и очень быстро загнивает.

Даже если такое происходит, за несколько дней всё отлично вспоминается.

А потом буду на работе проверять, сколько вкладок с запросом «how to do X in Python» может держать мой браузер открытыми, прежде чем он крэшанёт.
А, погоди, ведь именно так многие люди и вкатились на свои текущие должности!

До тех пор, пока человек понимает, что он делает и не создаёт проблем на будущее неочевидными и нерасширяемыми решениями, это вполне ок, что он гуглит какие-то частности. Да, чтобы понять идеологию конкретного языка, нужно с ним поработать и много, согласен. Но я не считаю это основной проблемой отрасли. А вот бизнес-логика во вьюхах и коллбэк хэлл — гораздо более страшные бичи индустрии, чем «неканоничный» код на условном Питоне.

a == b
Это одно условие.
a == c
Это — второе.
a == d
Это — третье.
Вот яркий пример, как 2 разных программиста по-разному видят один и тот же элементарный код.

Это 3 условия в одном паттерне. В языках, которые поддерживают pattern matching на алгебраических типах данных или range’ах такой код в 99% будет завёрнут на код ревью из-за 1) дублирования кода 2) отсутствия статической проверки на исчерпываемость условий со стороны компилятора. Это huge deal и здесь почти нет пространства для дебатов. Но повторюсь, если у человека есть причина по которой он не может использовать pattern matching, например он планирует добавить выбивающееся из паттерна условие, то он может об этом сказать и мы спокойно идём дальше. Парное программирование.

А вот бизнес-логика во вьюхах и коллбэк хэлл — гораздо более страшные бичи индустрии, чем «неканоничный» код на условном Питоне.

Мы начинаем ходить по кругу, так что предлагаю заканчивать. Для проверки этих вещей есть отдельный этап собеседования.

Да, чтобы понять идеологию конкретного языка, нужно с ним поработать и много, согласен.

И для проверки этих вещей — отдельный этап собеседования.
И то и то — важно. И то и то нужно проверять, если ты хочешь нанять человека, который не только сможет решать задачу, но и потенциально сможет поднять планку качества кода на проекте (одно из качеств, которые мы ищем у кандидатов сеньор уровня).
Никто не спорит, что освоить отдельный язык проще, чем целую доменную область или инженерные практики, но это тоже требует времени и усилий и тоже получается у разных людей сильно по-разному. Есть целая категория людей, которые очень хорошо разбираются в домене, лучших практиках и подходах, но которые посредственные кодеры. Такие люди ещё в первые 5 лет своей карьеры начинают двигаться в сторону архитектуры или инженерного менеджмента. Я лично знаю сразу несколько таких людей и уважаю их выбор.

P.S.

коллбэк хэлл — гораздо более страшные бичи

Интересное замечание, потому что именно для проверки этого момента ничего лучше сессии парного кодинга придумать нельзя. Любой дурак тебе скажет, что коллбэк хэлл — это неприятно, но сможет ли он его справить, есть дать ему кусок такого кода? Владеет ли человек на практике корутинами? А насколько комфортно он работает с функциями высшего порядка? А может там и асинхронность не нужна и он это предложит исправить? На словах то все всё знают и умеют.

Это huge deal и здесь почти нет пространства для дебатов. Но повторюсь, если у человека есть причина по которой он не может использовать pattern matching, например он планирует добавить выбивающееся из паттерна условие, то он может об этом сказать и мы спокойно идём дальше.

А если он не знает на данный момент точно, будет ли выбивающиеся из паттерна условие, или нет?
Это вполне можно переписать, когда будет точно ясно, что не будет. Почему именно это вообще имеет значение?
Я бы даже этому не посвящал этап собеседования.

Парное программирование.

Извините, господа будут друг другу сложные материи за чашкой кофе доказывать, или фичу деливерить?
Парное программирование — полностью мертворождённое направление. Эффект на перформанс от увеличения количества программистов в команде достигается только если их больше 3.
2 программиста будут дольше лясы точить и код мёрджить, чем педалить фичи.
Из того, что я видел, добавление второго программиста в проект ВСЕГДА замедляло разработку. Один человек ВСЕГДА работает быстрее двоих. Только от трёх и выше человек, работающих с одной кодовой базой могут обогнать одного человека по перфомансу. И то, при условии, что один из них будет лидом, а двое «оруженосцами». Иначе будет экранизация басни про лебедя, рака и щуку.

Из того, что я видел, добавление второго программиста в проект ВСЕГДА замедляло разработку. Один человек ВСЕГДА работает быстрее двоих. Только от трёх и выше человек, работающих с одной кодовой базой могут обогнать одного человека по перфомансу.

И на основании этих карликовых во всех смыслах проектов (где добавили АЖ второго кодерка и процесс встал) ты делаешь выводы об индустрии в целом? Это сильно.

И на основании этих карликовых во всех смыслах проектов (где добавили АЖ второго кодерка и процесс встал)

Это процентов 80 всех проектов под мобайл вообще-то.

Будь-який мобайл використовує певний бек-енд. Причому може бути й так, що мобільна аплікація — це дуже невелика частина досить великого проекту, який крім самої аплікації містить ще здоровезний бек-енд (будь-якого рівня складності, можливо інтегрований з кількома зовнішніми системами через API), адмінку для налаштування та підтримки роботи системи, а можливо ще й браузерну аплікацію, яка більш-меньш повторює функціонал мобільної. Навряд існують реальні проекти, де мобільна аплікація живе сама по собі. Мені такі точно не відомі. :) І розробка мобільної аплікації зазвичай залежить від розробки бекенда, який її підтримує, тобто більшість проектів — це НАБАГАТО більше ніж дві людини. :)

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

Обратите внимание, я имел ввиду количество людей, одновременно работающих НАД ОДНОЙ КОДОВОЙ БАЗОЙ. Бэкенд не входит в кодовую базу мобильного приложения. Фронтенд — тоже.
А то у меня был лид, который на полном серьёзе предлагал сделать в Гите 2 ветки, одну для Android, другую для iOS в одном и том же репо. А что? И то и другое — мобайл...
Я ему отвечал, что главное их случайно не смёрджить, а то аппка под Виндоус Фон получится.

НАД ОДНОЙ КОДОВОЙ БАЗОЙ

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

на полном серьёзе предлагал сделать в Гите 2 ветки, одну для Android, другую для iOS в одном и том же репо

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

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

Одна кодова база й один проект — суто різні речі

И быстрее будет вестись разработка той кодовой базы, где разработчик один. Именно по этой причине я всегда обгонял бэкенд разработчиков, хоть они и начинали раньше меня. Потому что когда над кодовой базой работает только один человек — уходит целый пласт проблем, связанных с мёрджем, код-ревью, аппрувами, изменения очень быстро попадают в новые билды, нет кучи формальностей. Вдвоём уже так не поработаешь.

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

Это было задолго до появления Kotlin Multiplatform и это была полностью нативная разработка. Никаких общих частей там не было и в помине. Просто человек был крайне далёк от мобайла и не понимал, чем кроссплатформа отличается от нативной разработки.

уходит целый пласт проблем, связанных с мёрджем, код-ревью, аппрувами, изменения очень быстро попадают в новые билды, нет кучи формальностей. Вдвоём уже так не поработаешь.

З цим складно не погодитись, особливо в ситуації коли доводиться працювати з досить великим об’ємом legacy code. Мені особисто теж комфортніше працювати з codebase один на один. Але зазвичай трапляється так, що легше найняти помічника, ніж довести менеджеру чи клієнту, що без нього буде швидше. ;) І, доречі, так буває не завжди. Інколи дійсно є можливість поділити завдання так, що вдвох виходить трохи швидше. І ще є момент. Я зараз працюю в парі з людиною набагато меньш досвідченою, ніж я, тим не меньш пару цінних зауважень за останній тиждень отримав (code review). Коли досить довго працюєш сам, нема в кого вчитися чомусь новому. Залишаються лише курси та книжки. Коли співпрацюєш з живою людиною, навіть віддалено, певні речі «заходять» набагато простіше. Бо це відбувається більш природнім шляхом. Коротше кажучи, я бачу певні плюси і мінуси в обох ситуаціях.

А если он не знает на данный момент точно, будет ли выбивающиеся из паттерна условие, или нет?

YAGNI.

Я бы даже этому не посвящал этап собеседования.

И это нормально. У всех разные стандартны и требования к кандидатам. Что могут себе позволить небольшие проекты на аутсорсе — не могут себе позволить большие продукты. Just get shit done — это идеально для фрилансера или контрактника/аутсорсера. Но когда нанимаешь человека в core команду, то ожидаешь и деливери и высокую инженерную культуру и очень уверенный кодинг. Да, можно искать человека месяцами, но мы никуда не спешим. Зато люди остаются в компании годами (реальная статистика).

Парное программирование — полностью мертворождённое направление.

YMMV. Кроме того, здесь обсуждается ПП не для разработки, а для интервью с целью максимализации потока данных между интервьюером и кандидатом.

Извините, господа будут друг другу сложные материи за чашкой кофе доказывать, или фичу деливерить?

Что говорит о том, что поспешили и наняли в команду кого попало (возможно всего одно часовое собеседование таки было не лучшей идеей?). Профи отлично понимают, что такое bikeshedding и умеют этого избегать. ПП в руках зрелых специалистов чуть менее, чем всегда ускоряет деливери, особенно там, где есть строгий процесс код ревью (а он всегда есть там, где есть зрелые специалисты), потому что ПП забирает значительную часть асинхронных обсуждений в комментариях к PR в синхронное обсуждение во время ПП.

Любой кандидат на позицию инженера, особенно с приставкой Senior должен виртуозно владеть хотя бы одним ЯП и одним доменом.

А что значит «виртуозно» владеть языком программирования? Разбираться во всех его возможностях? Один из моих начальников почти 30 лет назад сказал, что программисту достаточно знать язык на 20-30%, чтобы эффективно решать рабочие задачи. Тогда я был молод и с ним не согласился. Тоже думал, что владеть языком нужно «виртуозно». А сейчас я с ним согласен.

Что касается программистов, которые разбираются во всех тонкостях языка (Брукс в своей книге назвал таких программистов «language lawyer»), то их не нужно иметь много. Достаточно одного на 20 обычных программистов.

Для программиста главное не умение разбираться в тонкостях языка, а умение решать задачи.

А что значит «виртуозно» владеть языком программирования? Разбираться во всех его возможностях?

Это значит уметь бегло (не путать с быстро) писать идиоматический код используя встроенные возможности языка и средства его стандартной библиотеки. Для чего нужно быть интимно знакомым со значительной их частью. Значительной, но не всей, тут я полностью согласен с вашим бывшим начальником. Не уверен на счёт 20-30%, этого будет маловато даже для C++ или Java. Но 60-70% актуальной части языка (не считаем легаси для обратной совместимости) звучит более правдоподобно. Хотя считать проценты здесь — неблагодарное дело.

Для программиста главное не умение разбираться в тонкостях языка, а умение решать задачи.

Да, да, я уже слышал это красивое утверждение от предыдущего комментатора. Оставьте эту романтику. Для того, чтобы не только уметь решать задачи, но и решать их в разумный срок, с разумным качеством и минимальным количеством заворотов на код ревью, уверенное владение инструментом обязательно.
Не может человек так? Повторяю в третий раз: пусть идёт на должность Solution Architect или Engineering Manager и говорит другим, как он считает должна быть решена задача, а сеньоры для него это сделают качественно и в срок.
А так, я могу решить вам любую решаемую задачу на любом языке, только дайте и оплатите мне неограниченное время и выдайте команду ревьюверов, которые будут каждый мой пёрл проверять.

Да, да, я уже слышал это красивое утверждение от предыдущего комментатора. Оставьте эту романтику. Для того, чтобы не только уметь решать задачи, но и решать их в разумный срок, с разумным качеством и минимальным количеством заворотов на код ревью, уверенное владение инструментом обязательно.

Я тут хочу провести аналогию с естественными языками (теми языками, на которых люди разговаривают). Может ли человек, не очень хорошо знающий иностранный язык, написать на нем текст хорошего качества?

Ответ: да. В первые годы жизни в Голландии я знал голландский довольно плохо. Но, тем не менее, писал статьи по программированию для журнала компании, в которой тогда работал. Писал с большим количеством грамматических ошибок. Статьи потом редактировались голландцем и публиковались. Но главное в статьях была не грамматика, а содержание. Я смог сделать его интересным. А многие голландцы, для которых этот язык родной — не смогли бы никогда.

А по работе также написал много документации на голландском — функциональный и технический дизайн большой программной системы.

То есть, главное, это не знание языка, а иметь что на нем сказать. То же и в программировании.

Например, я в 2004 году нанялся на один проект, в котором надо было работать на ASP.NET, которого я не знал. На интервью я схитрил и сказал: «Я работал на ASP, а ASP.NET это почти то же самое» (на самом деле они сильно отличаются). Меня взяли, и ASP.NET я учил в процессе реализации проекта. Но программу успешно написал, потому что я точно знал, что она должна делать. И там была достаточно сложная функциональность, например, на одной форме был грид, который динамически конфигурировался в зависимости от настроек пользователя.

Или возьмем, к примеру, двух C#-программистов. Один знает язык очень хорошо, а другой похуже. Возникла задача — произвести миграцию большого приложения на более свежую версию .NET Framework и на новые версии используемых библиотек. Само приложение состоит из десятков проектов с сотнями ссылок, и этих приложений много.

Виртуозно владеющий .NET программист открывает каждый solution в Visual Studio и начинает вручную менять ссылки в проектах, одну за одной.

Другой программист замечает, что файл проекта с расширением csproj — это XML-файл. Ссылки — значения элементов в этом файле. А почему бы не написать программу, которая берет этот XML-файл и меняет все эти значения автоматически? И он сел и написал эту программу (в процессе написание еще и изучив, как работать с XML) и в результате закончил свою работу быстрее первого программиста.

Или еще один пример, как на завод взяли молодого рабочего. Для начала его посадили клеймить готовую продукцию — какие-то детали. Работа простая — нужно взять деталь, приставить к ней клеймо и ударить по клейму молотком. То есть нужно хорошо владеть молотком. Он проработал так целый день. А на следующий день он перевыполнил норму в 30 раз. Что он сделал: где-то раздобыл трубу и поставил ее вертикально между первым и вторым этажами. Под трубой поставил клеймо. Потом поднялся на второй этаж и стал бросать в трубу детали одну за одной. Они бились о клеймо и отскакивали в стоящий рядом ящик.

Виртуозно владеющий .NET программист открывает каждый solution в Visual Studio и начинает вручную менять ссылки в проектах, одну за одной.

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

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

Поки той програміст буде вивчати як з XML працювати, я ті csproj sed’ом перепатчу. Тож шукайте краще лінуксоїдів на той .NET, проекти швидше патчитись будуть.

При написании кода можно посмотреть на стиль. Если человек не заботится о нейминге и форматировании в финальной версии кода — сразу досвидос. Даже если он отстрелялся на теор.вопросы хорошо — в работе он будет валить малочитабельные стены текста вместо структурированного кода, создавать год-обжекты и прочее.

С неймингом могу согласиться. С форматированием — вообще моветон в эпоху систем автоматического форматирования, не пропускающих PR без оного. Отформатирует, никуда не денется.
Год обджект — да спросите у человека на тех собесе, как он будет реализовывать ту или иную фичу, сразу будет видно любителя «создать универсальный синглтон». Займёт 5 минут.
Тестовое, которое бы имело достаточно функционала, чтобы там были видны подобные ошибки в дизайне, по-хорошему занимает больше одного дня.

Ах лол. Сонары, линты, и вся прочая шелупонь не вытягивает.
Если код написан безалаберно, он таки и останется. Я говорю не о пробелах и переносе скобочки, а о том, стремится ли человек к какой-то организации кода, соответствующей его внутреннему чувству логики/эргономики, или просто лепит шоб скомпилировалось.

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

Любое то или иное решение об организации кода должно иметь конкретные причины.
И не должно базироваться на личных чувствах. А то я видел и таких деятелей, которым лямбды не по вкусу.
И да, об этих причинах можно спросить на собеседовании. Если человек не может дать вразумительный ответ, почему так лучше, зачем, например, придерживаться SOLID, значит, он не знаком с последствиями тех подходов, когда его не придерживаются. Значит, не будет его придерживаться.
Блин, это же так просто.

Любое то или иное решение об организации кода должно иметь конкретные причины

Оо, знакомая песня.
Обычно она продолжается «не вижу конкретных причин, с кодом все ок». Стопицот раз слышал такое от «синьоро» чей код на проект все втихую считали нечитабельным говном.
И да, именно они любят втягивать сонары, линты, скрипты и прочий мусор, который свистит, пердит, периодически падает, но зато героически поддерживается, и тыкается всем вокруг как пруф «качества кода». Еще хорошо интегрировать все это с СИ/СД чтобы пуллреквест становился головоломкой. Та же самая тема что с код кавереджем. Можно написать нерабочее говно со 100%м покрытием тестами и ходить надувать щеки.

Стопицот раз слышал такое от «синьоро» чей код на проект все втихую считали нечитабельным говном.

Удалось выделить конкретные причины, почему их код было сложно читать?

Да. Они были очевидны.
Потому что код писался единой стеной, без мысли о том, что кто-то это будет читать. Лямбды, тернарки, переносы, вызовы внутри вызовов внутри вызовов, мойОченьДлинныйСервисНеймингПростоПотомуЧтоЯНеПереименовалИмя
ПеременннойОставивИмяКласса.методКоторыйПринимаетАргументыИяПеречислю
ВсеИменаКлассовВсехАргументов(а, б, в, г -> лябмду я тоже не перенесу потому что можно без переноса;
и дальше в таком же духе.
И да, технически — это все проходит кодстайлы и все это бесполезные линты. Потому что вопрос читабельности — это вопрос человеческого восприятия. И есть out there категория надутощеких синьоров которым в принципе ложить на то, чтобы их код читали люди.

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

нейминг — просто еще одна нотка пофигизма.
увы, яне смогу привести конретные примеры, а выдумывать и писать подобие впадло

просто еще одна нотка пофигизма

Пофигизм — нормальное и здоровое отношение к окружающей действительности.
Без конкретизации и паттернизации проблемы решить её не представляется возможным

У одних людей есть некое врожденное стремление к эстетике и рабочей этике, выражающееся в нашей профессии в стремлении к чистому, элегантному, читабельному коду.

У других людей его нету. Эти вторые прикрывают его отсутствие сентенциями про здоровый пофигизм, «таски для градла», бьютифаеры, линты-хуинты, стайлчекеры, «100% кавереж», сонарами и прочей шнягой. Потому что на самом деле им просто нужна отмазка, если кто-то мимопроходящий скажет «постойте, а что это за нечитабельное говно?!»

постойте, а что это за нечитабельное говно?!«

Простите, в Вашей IDE нет hotkey для автоформата?
Или он тоже «как-то не так» форматирует?
Дык его же настроить можно.

О, я пам’ятаю оці лінти на одному проєкті. Інкрементальна збірка проєкта після зміненого пробілу — 20 секунд, поки лінти відпрацьовують. Срались-срались, вимкнули. Інша проблема. Регулярно зламані білди, бо ж курва два пустих рядки підряд, як ти міг таке засабмітити?? Зрештою якось вирішили, але не пам’ятаю вже як, бо якраз тоді десь звільнився, мабуть, вимкнули.

Да, до слез.
Но всегда на таком проекте есть несколько надутых индюков которые все это втянули и делают вид что они крутые спецы.

Сонары, линты, и вся прочая шелупонь не вытягивает.

Вытягивает супер. Пишется таска для градла, которая сама всё форматирует по нашему вкусу. Дальше в CI добавляется проверка выполнения этой таски перед коммитом. Всё, вопрос на этом закрывается. Работал с такой штукой — идеал вообще. Форматирование по всему проекту идеальное и ни у кого голова не болит.

Да, а еще можно версии из текста коммитов вытягивать, написать целое говноподелие, интегрировать его всюду, а потом оно будет мешать как третья нога, но мы ходим и гордимся какое у нас все автоматизированное и кастомизированное.
Самый лучше способ просрать KISS — пойти по пути такой «автоматизации».

Встречный вопрос: вы проводили такого рода интервью? с парным программирование? и тд... если да то на какую позицию?
У вас на позицию сеньера предлагали сделать тестовое?

Встречный вопрос: вы проводили такого рода интервью? с парным программирование? и тд... если да то на какую позицию?

Почему встречный? Я не задавал никаких вопросов.
Да, именно так я и проводил все кодинг интервью до пандемии. На все позиции, от интернов до сеньоров: позиция кандидата в кодинг интервью роли не играет, только на архитектурном/системном дизайне и возможных bar raiser’ах. Сейчас почти то же самое, но уже используя инструменты для онлайн кодинга, типа кодерпада, что значительно менее удобно, безусловно. Ставить кандидату полноценный софт для удаленного парного программирования, типа Tuple, нецелесообразно.

У вас на позицию сеньера предлагали сделать тестовое?

За время, которое я в компании, мы никогда не практиковали тестовые задания ни для каких уровней.

Таск, что вы перечислили на 4 пункта без предварительной наработки за час не напишите. Я на пример не держу в голове весь этот файловый API, (да и IDE как-то развращает) потому что на С он один, на С++ он второй, на Java — вообще несколько вариантов, для Swift — file manager, можно и через С Unix, но это долго и не интересно. А потому — я обычно даю что-то проще, что объединяет и просто у и понимание структур данных, как найти view — если мы говорим о мобайл, просто и изящно, это как-то предложил мой коллега. В общем — в этом кейсе все станет на свои места. А файлы и прочая прикладная штука... это дело вкуса.

что есть немало людей, которые мнят себя «выше кода» и попросту забыли как кодить.

многие и не знали и даже просто не задумывались ))

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

Ну и конечно отсутствие гибкости в собеседовательнм процессе и тех же заданий.

Работодатель: какой у вас опыт?
Соискатетель: последние 5 лет наша команда занималась развитием медиа сервиса с нагрузкой 10 000 запросов в минуту и автоматизацией всех стадий разработки
Работодатель: сделаете todo приложение как тестовое?

наша команда

 — а может он кофе приносил?

Розумію, чому можуть дати невеличке тестове завдання на 1-2 години для джуна. Але коли, наймаючи сіньор розробника, вимагають він нього виконати тестові завдання, ще й об’ємом в 4-5, а то й більше годин, хочеться запитати менеджмент таких компаній — ви самі-то багато безкоштовно працюєте? Ще й над марною річчю, яка не несе в собі будь-якого сенсу.
Таким «фільтром» компанії наймуть тільки або тих, кому прям конче потрібна ця позиція, або розробників із «2-ю фізикою» (в термінах психософії), а це зробить колектив дуже специфічним. Не заздрю тим, хто потрапить в такий колектив.

В этой логике есть один изъян: ты (неявно) рассматриваешь только часть проблемы — интервью против тестового для оценки одного конкретного синьора-помидора. Но проблему нужно рассматривать шире — с того, что у тебя на одну позицию может быть от десятка до пары сотен соискателей. И поговорить с каждым (на должном уровне) — это очень амбициозная, а в некоторых случаях физически не решаемая задача. Тестовое задание (если хорошо продумано) в этом случае эффективно решает задачу фильтрации — часть не сделает вовсе, часть пришлет какую-то каку которая даже не соберется и т.п. Разумеется, это компромисс, и сам факт использования тестового может потерять по дороге пару годных кандидатов — ну так чуть менее чем все управление людьми это один сплошной компромисс (где-то недавно видел меткое «бизнес — это просто серия проблем, которая иногда генерирует прибыль»).

Но проблему нужно рассматривать шире — с того, что у тебя на одну позицию может быть от десятка до пары сотен соискателей. И поговорить с каждым (на должном уровне) — это очень амбициозная, а в некоторых случаях физически не решаемая задача.

Такое может быть только, если вакансия для джунов без опыта.

Тестовое задание (если хорошо продумано) в этом случае эффективно решает задачу фильтрации

Да. Оно очень эффективно отсеивает тех, кто занят на работе и не имеет на него времени.

Такое может быть только, если вакансия для джунов без опыта.

Все зависит от оффера и компании. Широко известная в узких хипстерских кругах Basecamp недавно на 2 открытых позиции получила больше 1000 резюме — в том числе потому, что компания официально не занимается онанизмом с «локализацией зарплат» и платит всем ремоут воркерам американскую зарплатку (под две сотни в год). Так что желающих набигает изрядно, и компания вынуждена (опять же, все прозрачно объявлено заранее) отсеивать овер 90% соискателей на первом этапе только на основе анализа резюме (можешь себе представить погрешность такого отбора — но увы, компромиссы неизбежны).

Все зависит от оффера и компании

Это частный случай. Там действительно компания формирует свой собственный рынок труда. В котором предложение рабочей силы многократно превышает спрос. Не хотел бы работать в подобной компании

Тот же angel.co раньше показывал сколько человек подалось на вакансию. В итоге там набегало за 2-3 недели больше сотни, но само собой на вакансии с хорошей зп, а не с

«локализацией зарплат»
Да. Оно очень эффективно отсеивает тех, кто занят на работе и не имеет на него времени.

Если ты ищещь работу — ты априори должен на этот процесс тратить время. Так что это только вопрос в какой форме — оффлайновой задачки или онлайновой задрочки. А если ты не ищещь работу — читай, не мотивирован — то ежу понятен результат...

Если ты ищещь работу — ты априори должен на этот процесс тратить время.

Да, 3-4 часа в день на интервью уходит, если активно ищешь. Это помимо 8 часов остальной работы. Как вписать в это ещё и тестовые — я хз.

А если ты не ищещь работу — читай, не мотивирован — то ежу понятен результат...

Ага. Чаще всего я менял работу, когда активно её не искал. Мне сами писали и предлагали.

Да, 3-4 часа в день на интервью уходит, если активно ищешь. Это помимо 8 часов остальной работы. Как вписать в это ещё и тестовые — я хз.

Ну смотри, все ж очень просто. Если у тебя 3-4 часа в день уходит на вьюхи — ты явно общаещься более чем с одной компанией, верно? Оффер от той, что хочет тестовое, чем-то сильно лучше остальных? Нет? Тогда нахер тестовое, сворачиваем эту линию переговоров и общаемся с оставшимися. Да, оффер заслуживает внимания? Ну тогда сам придумай где взять эти пару часов. Может в субботу посиди вечерком. Может сверни нахер остальные переговоры и сфокусируйся на этом оффере пока что...

Моя позиция очень простая — в тестовом самом по себе нет ничего плохого (как и хорошего). Это просто данность — иногда их хотят. Делать или нет зависит от степени моей заинтересованности и вменяемости самого тестового. Реже делаю, чаще нет.

На мой взгляд считать оффер априори не заслуживающим внимания только потому, что процесс предполагает тестовое — неверно.

Да, оффер заслуживает внимания? Ну тогда сам придумай где взять эти пару часов

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

На мой взгляд считать оффер априори не заслуживающим внимания только потому, что процесс предполагает тестовое — неверно

Что например может предложить вакансия такого, чтобы ради неё стоило его делать?
По моему мнению, тестовое имеет смысл делать, если на собеседования тебя даже не приглашают и оффер в противном случае тебе не светит. Иначе, на это просто нет времени.

Я кажу про середньостатистичну українську галеру, а не про FAANG і компанії такого ж масштабу.

Половина потенциальных работодателей дает тестовое «на 4 часа», в котором надо поднять БД и API сервис, написать какой-нибудь клиент, предусмотреть валидаци данных, добавить несколько тестов, сгенерировать документацию.
Какой смысл в таком подходе, если:
1. делать хорошо — значит несколько дней и сильный соискатель не будет тратить свое дорогое время
2. делать плохо — какой стороне это надо?

А со стороны компании они еще какого-то разработчика выдергивают от основных задач и заставляют проверять. Фидбек чаще всего не валидный, замечания слабо относящиеся к тестовому.

Час общения ценнее «4-часового» задания. Отказаться через месяц от неквалифицированного сотрудника лучше, чем регулярно упускать хороших людей глупым подходом.

Полностью согласен!
Как компромис лучше добавить 1 час на тех собес чем тратить «4 часа» на посредственно выполненное тз.

Меня продолжают умилять подобные коменты. Ребята, не хотите делать тестовое, покажите свежий github проект, не поросший мхом и имеющий чуть больше комитов чем один с коментом «Initial commit» и веток кроме master.

Час общения ничего не покажет кроме скилла соискателя проходить собеседования.

На рынке появляется свободный специалист. За 2 недели он получает примерно 8 приглашений на собеседование. В 5 компаниях ему предложат сделать тестовое. Он выберет 1-2 задания и, может, найдёт время сделать их по минимальным требованиям. В других 3 компаниях с ним просто поговорят, в 2 из них будет ещё техническое собеседование с клиентом. 1 пригласит работать. В это время 2 тестовых задания будут ещё проверяться.
Так какую проблему решает тестовое в таком классическом для мидл+ сценарии?
Экономит время рекрутера отсекая совсем слабых претендентов попутно избавляя себя и от сильных?
Я, например, опытный, ответственный разработчик и надёжный член команды с развитыми софт скилами. С моей точки зрения, примерно половина компаний сделали практически все, чтобы я к ним не пришёл, а значит их подход для найма совершенно не работал.
Докажите мне обратное 🙂
Все компании, которые давали мне тестовое, затягивали с фидбеком на 2-3-4 дня, нарушая свои же оговоренные сроки. Некоторые из них откровенно врали. Может, я попадал на такие, а может, тут есть какая-то закономерность. Я не знаю точно.

опытный, ответственный разработчик и надёжный член команды с развитыми софт скилами

Обычно это говорит каждый первый мидл+. Но будем откровенными, это нужно проверять. Очень часто я подобное слышу и очень редко это совпадает по ожиданиям хотя бы на 90%.

Компании, которые не дали тестовые, пошли на осознанный (надеюсь) риск, явно спешили закрыть позицию либо в процессе формирования команды с нуля. Это ок, если тестовый период позволит в случае чего быстро отсеивать.

Мне жаль, что у вас сложился такой опыт. Если есть тестовое, не надо много времени чтобы назначить тех собеседование где это тестовое и сразу обсудить. Ведь и специалист сразу увидит с кем ему придется работать, какие подходы применяются, какой уровень будущих сотрудников и т.д. Что это как не win/win?

свежий github проект, не поросший мхом и имеющий чуть больше комитов чем один с коментом «Initial commit» и веток кроме master

Нормальное такое у вас тестовое, я смотрю

Для джунов нормальное требование, для сеньойров лучше не надо злоупотреблять. Из свой практики могу сказать что из 5 тестовых за которые брался, положительно закончился только один кейс, и то потом у заказчика что там случилось и я принял оффер другой компании пока те думали, но потом они вернулись было поздно. В итоге я буду делать тестовое только в том случае когда реально жрать нечего будет, а так все в лес.

Для меня основной + тестового — это до собеса понять, что человек может. Даже по простым заданиям уже можно что-то понять, дабы не тратить его и своё время. Так же по тестовому можно понять какие вопросы можно пропустить на собесе.

його і своє?))) Своє тільки, не треба лукавити.

Почему же только своё? Мне на время других людей тоже не наплевать.

якщо я (припустимо), робив тестове два дні, і мене не взяли на роботу. В якому місці я зекономив час?
Всі рази, коли мені пропонували тестове, то казали що воно на пару годин, але якшо його вилизувати і розбивати на мільйон абстракцій — то часу йде на порядок більше.

Если тестовое можно разбить на миллион абстракций, то оно не такое уж и простое. Моё тестовое даёт понимание о том, как человек знает сам язык, остальное — собес. Ну и требований сделать прям всё нет. Грубо говоря кандидат сам решает, что делать, а на что у него не хватает знаний/времени.

Если тестовое можно разбить на миллион абстракций, то оно не такое уж и простое

А иначе — оно ни о чём не скажет.

Моё тестовое даёт понимание о том, как человек знает сам язык

Для джунов такой подход — окей. Но не более того.

Проблема в том, что джуны (по скилам) идут на собесы на мидлов/синьёров. Именно здесь я и хочу фильтр.

Проблема в том, что джуны (по скилам) идут на собесы на мидлов/синьёров.

Их можно фильтрануть даже по резюме.
В случае с тестовым заданием ты просто наймёшь на миддла/сениора самого толкового джуна. Потому что реальные миддлы/сениоры даже не будут заморачиваться этим тестовым.

Предлагаешь, если человек отказался делать тестовое, то брать его на синьёра не глядя?

Предлагаешь, если человек отказался делать тестовое

Предлагаю даже не предлагать делать тестовое.

У меня нет столько времени. Если человек принципиально отказывается от тестового даже не глянув, то скорей всего его корона и так к нам в дверь не пролезет.

якщо я (припустимо), робив тестове два дні

Ошибка именно в этом месте. Тестовое не должно занимать больше пары-тройки часов. Если тестовое нужно делать два дня — то его не нужно делать, из этого все равно не получится ничего хорошего.

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

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

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

Звичайно, що якихось сеньорів-архітекторів, які хотіли $6k, я не мучив своїм тестовим завданням, а відразу казав, що це велика честь працювати в моїй компанії, але бюджету в мене на них зараз немає все одно :)

Ну це теж якось перебір, все ж варто спочатку хоч якийсь скрінінг проводити перш ніж просити виконати тестове.

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

В таком случае, все эти кандидаты сделали ошибку не в тот момент, когда согласились на тестовое. И даже не в тот момент, когда отправили резюме.
А в тот момент, когда выбрали направление.

Ну це не моя проблема, і я не епам, щоб брати джунів (чи взагалі будь-кого) десятками, в мене немає стільки роботи. Ринок великий, десь щось знайдуть.

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

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

Якщо кандидат ок по резюме, то так, мін 20 хв.

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

Цікавий досвід, дякую. Тобто для вас тестове завдання було ключовим у відборі?

Так. Звичайно, ще потім була співбесіда, де я розповідаю про те, чим ми займаємося і розпитую людей про їх досвід, що робили (якщо немає — як вчились), чому хотять програмувати, тощо. Можемо обговорити саме тестове завдання, але код писати не потрібно, чи відповідати скільки методів є у класу object

Зависит от того, какое задание и насколько сильно вам интересно туда попасть. Недавно делал тестовое в одну немецкую логистическую контору. Задание было намного интереснее того, что я обычно делаю на работе (крудошлепство на галере). Получил удовольствие.

Почему, если не секрет?

Сейчас на западе снова в моде или тестовые удаленно, или кодирование на расширенном экране удаленно. Потому что вся работа стала удалённой, а как еще оценить кандидата не видя его в лицо. Я предпочту тестовое задание оффлайн (такое например давали в Революте ) чем собеседование типа кодилити/хакерранк где у тебя над душой будет сидеть человек (Амазон, Спланк)

Сейчас на западе снова в моде или тестовые удаленно, или кодирование на расширенном экране удаленно.

Вот за это я не люблю все ваши Эльфии. Там прямая противоположность Украины — рынок работодателя, а не кандидата. Удалёнка это ещё и усугубила.

а как еще оценить кандидата не видя его в лицо.

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

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

Зачем?
Можно рандомно кинуть 95% резюме из пачки в шредер, создав за несколько секунд шорт-лист.

Тестовое задание олицетворяет такой разговор:
— Как это сделать?
— Могу рассказать.
— Рассказать -то и я могу, как сделать-то?

Плюс тестового задания в том, что человек на практике показывает как бы он подошел к решению задачи в реальной жизни, на боевом проекте. И тут такая фишка, что как бы у тебя на собесе не отскакивают от зубов всякие расшифровки SOLID, и т д, но по тестовому явно видно примерный уровень человека, пользуется ли он всякими phpcs / md или «и так сойдет», и так далее.

Минусы тестового заключаются в том, что 90 процентов претендентов не относятся к нему серьезно и делают одной левой ногой, оторванной от курочки Рябы — они воспринимают тестовое как просто один пункт на пути к офферу который надо сделать просто чтобы решить задачу.
И когда на техническом интервью начинаешь разбирать подобное тестовое, то у кандидата как правило округляются глаза и он говорит «А вы чо, реально его смотрели?!»

И по этой причине, к сожалению, на практике, тестовое не может дать объективную оценку кандидату. Гораздо проще на техническом дать скачать заранее подготовленный проект для тестового и попросить кандидата
1) Разобраться что тут происходит
2) Как можно улучшить тот или иной кусок кода ( заложив в код заранее подготовленные явные антипаттерны )
3)... добавить новый мини функционал, к примеру метод, читающий из БД.

И не мучить кандидата теми «интересными» вопросами из соседней темы про «250 вопросов как почесать свое ЧСВ об кандидата»

Гораздо проще на техническом дать скачать заранее подготовленный проект для тестового и попросить кандидата

Это проверит способность кандидата «соображать прямо на лету» и ничего больше. Мне, например, в первые секунды просмотра кусок кода ни о чём не скажет. Без понимания, зачем он написан, какую задачу решает, какие ограничения, какие критерии приёмки и т.п.
А на понимание всего этого нужно минимум пару дней.

Был у меня как-то такой опыт, дали тестовый проект, сказали, что надо было пофиксить тесты :)
пара моментов: я сидел, просматривал код, чтобы понять, что и как. Мне товарищ начал давить, что у нас тут такое за 20 минут делают... в одном месте я таки из-за этого ошибся — не на тот класс завязал лисенер. В общем-то я зафиксил все тесты, кроме одного, который требовал по симантике create, а не clone. Я сказал, что так нельзя — программист, который этим будет пользоваться, должен ожидать определенного поведения, на что мне сказали, что нельзя менять (рефакторить) интерфейс :) Но сказали, что я могу написать коммент и не фиксить данный тест. Что я и сделал. Спустя дня три мне отписали, что кастомер не утвердил моего тестового. На что я им ответил, что даже не расстроен. Что самое интересное, изначально об этой компании был невысокого мнения. Но слухи — это одно, когда в чем-то убеждаешься, это другое.
Из моих прохождений тестовых — сработало только один раз. После этого я поступаю так же, как тут было описано, компании с тестовыми идут в конец списка, до которого я не дохожу.
Если очень хочется узнать, как человек думает, то можно просто задать вопрос на интервью.

Плюс тестового задания в том, что человек на практике показывает как бы он подошел к решению задачи в реальной жизни, на боевом проекте.

Ви будете покривати одноразовий скрипт тестами на 100%? А будете його розбивати на слої і використовувати депенденсі інджекшн?

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

Любителям анологій:
Ви берете в команду з марафону на основі результатів у спринті.

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

У такому разі до власне виконання може справа і не дійти.

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

Підтвердження слів практикою.

Підтвердження слів практикою.

1) Ніт dou.ua/...​ks-pros-and-cons/#2074998
2) Яке підтвердження вам потрібно? На співбесіді людина трохи пописала код, може пояснити яку структуру компонентів створювала б для тієї чи іншої задачі. У яких саме навичках кандидити ще є сумніви після співбесіди?

1) у мене б такий не проскочив на техн співбесіді
2)

співбесіді людина трохи пописала код,

тут не всі можуть себе адекватно проявити, все ж сказується стрес кодити прямо на співбесіді.

у мене б такий не проскочив на техн співбесіді

Угу, ви кращий! ... А для чого тоді тестове, якщо батя так круто проводить співбесіди?

все ж сказується стрес кодити прямо на співбесіді.

Угу, для цього є інтерв’юер, який має розпізнати стрес і направити кандидата. Знову ж, а під час випробувального терміну не буде стресу? А на колі з замовником (який не розмовляє вашою рідною мовою)?

Тестове і є якраз приводом для спілкування на техн співбесіді.

Ок, я розпізнав стрес, і що? І у мене і у кандидата обмежений час на синхронне спілкування. Звісно у практиці колись був варіант зробити формат воркшопу, але на це треба мін 3-4 години і майже ніхто на таке не погоджується. А отримавши тестове можно вдома спокійно сісти порозбиратись. Випробувальний термін ж це вже зовсім інша історія, до нього ще треба дійти.

А отримавши тестове можно вдома спокійно сісти порозбиратись.

Ну ок, навіть не намутив тестове, а сів, порозбирався (питання з чам саме розбиртись?).
І що? Яку інформацію ви отримали? Найпростіше: кандидат на задачу на 4 години витратив всі вихідні 2 дні по 12 годин, але ви про це не знаєте.

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

І для чого потрібен випробувальний термін?

Ок, я розпізнав стрес, і що? І у мене і у кандидата обмежений час на синхронне спілкування.

Так, тому задача має бути не складною.
А далі вам вирішувати, чи потрібна вам людина яка не може вирішити обрану вами задачу за 5-30 хв, і чи потрібна вам людина у якої обрана вами задача викликає «стрес».

1 — клас, значить він витратив свій час дарма. правильна відповідь: перед виконанням розповісти свій план, який у тому числі може включати у себе «хочу розібратись з X, Y, Z, додати кривавого ентерпрайзу, тому мені потрібно 2 дні по 12 годин на ось такий підхід». Після цього скоріше за все ми обговоримо що він реально встигне за один вечір і відповідно скоригуємо скоуп завдання. Тут же важливий діалог, а не виконання завдання для галки.

2 — для перевірки взаємодії у команді і придатності вже у конкретному проекті

3 — стрес викликає не власне завдання, а умови виконання (критичне обмеження по часу, хтось стоїть над душею етц).

еред виконанням розповісти свій план
Після цього скоріше за все ми обговоримо
Тестове і є якраз приводом для спілкування на техн співбесіді

Так співбесіда ж після тестового. Кому розповідати?

2 — для перевірки взаємодії у команді і придатності вже у конкретному проекті

Якщо 2 — це було про випробувальний, то на те що ви описали потрібно 1-2 тижні, але чомусь випробувальний зазвичай 1-3 місяці. Не занєте чому?

3 — стрес викликає не власне завдання, а умови виконання (критичне обмеження по часу, хтось стоїть над душею етц).

Задача на 5 хв на яку дають 30, при тому не озвучуючи обмеження часу. Обмеження немає.
Над душею теж ніхто не стоїть. Тут навіть цікавіше — перевіряються ті самі навички «взаємодії в команді», що ви вказали вище.

1 — письмово
2 — робити випробувальний більше одного місяця взагалі немає сенсу.
3 — задача на 5 хв показує лише скіл вирішення задач на 5 хв. можна звичайно взяти гіпотетичну підсистему з проекту і задати по ній завдання, але це навряд чи гарантовано покаже наскільки кандидат відповідає очікуванням.

there’s no silver bullet. Це FAANG можуть собі дозволити овер 9к етапів і завдань, у нас же кожен викручується як може.

задача на 5 хв показує лише скіл вирішення задач на 5 хв.

А тестове на 1 вечір показує лише скіл вирішення на 1 вечір

1 — письмово
Після цього скоріше за все ми обговоримо

Скільки у вас в середньому листів в 1 треді з обговоренням завдання? Скільки вашого часу витрачається на 1 такий тред?

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

3-4 листи, до 4 годин макс на тред і весь цей етап.

3-4 листи, до 4 годин макс на тред і весь цей етап.

Супердос! А можна було зробити за 1-2 год співбесіди (де ще купа моментів перевірити можна).

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

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

dou.ua/...​ks-pros-and-cons/#2075705

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