Як розпізнати недосвідченого розробника

Привіт, мене звати Костянтин Колесниченко. Я Desktop Lead у компанії ENESTECH Software, що входить до холдингу TECHIIA. Поділюся досвідом, як у пошуку досвідчених розробників знаходити «своїх» людей і відсіювати недостатньо підготовлених. Стаття розрахована на лідів-початківців і тих, хто планує стати керівником. Кандидати ж можуть підглянути, чого чекати на співбесідах. А досвідченим колегам-менеджерам буду вдячний за відгуки та кейси у коментарях.

В IT я працюю з 2004 року. За плечима — КІбцентр (Інститут проблем математичних машин та систем Національної академії наук України), геймдев і розробка софту для мобільних телефонів. Останні роки працюю в ENESTECH Software, де збирав команду, будував робочий процес і очолював різні департаменти. Наш головний продукт — SENET — SaaS-сервіс для комп’ютерних клубів і кіберарен, який використовують у 60+ країнах світу. У команді розробки зараз понад 20 людей.

Поговоримо про те:

  • яка ціна помилки найму;
  • що та навіщо вказувати у вакансії;
  • на що дивитися в резюме, pet-проектах, на зустрічі;
  • чи примушувати писати шматки коду на аркушику, та як взагалі побудувати співбесіду;
  • що робити в разі неспівпадіння.

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

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

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

Є два етапи, на яких можна виявити недосвідченого розробника. Перший і найважливіший — власне пошук і співбесіда. Другий і малоймовірний — під час роботи, якщо раптом ви проґавили «симулянта».

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

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

  1. Менеджер витрачає час на пошуки та узгодження. Замість виконання прямих поточних обов’язків, він чи вона готує вимоги, читає вхідний потік резюме від рекрутерів, бере участь в інтерв’ю, дає фідбеки, перевіряє тестові. Таких циклів може бути декілька.
  2. Нова людина проходить адаптацію. Наприклад, ми працюємо над продуктом, тому шанси взяти з вулиці людину, яка за тиждень почне видавати результат, майже нульові. У кращому разі вистачає місяця, у реалістичному — двох-трьох. Весь цей час компанія платить за те, щоб розробник:
    • прочитав документацію;
    • розібрався в нюансах продукту/проекту;
    • поговорив з технічними та іншими менеджерами;
    • налаштував процеси;
    • влився в команду.
  3. Менеджер, який має свої завдання, витрачає час на навчання новачка. Через це продуктивність команди протягом онбордингу може навіть зменшитися. У середньому лише з третього-шостого місяця спеціаліст і команда виходять на той рівень продуктивності, заради якого і брали новачка. І це нормально.

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

Як готувати вакансію

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

Приклад. Коли ми набирали команду для SENET, на бекенд нам була потрібна людина з трирічним досвідом на Python Django, яка одразу включиться в роботу. На мою думку, за три роки людина якраз встигає пройти купу різних завдань і навчитися їх самостійно виконувати.

Але недостатньо сказати рекрутеру: «потрібен пітоніст з трирічним досвідом Django». Бо такий кандидат може і веб-сторінки для магазину робити, і складний бекенд. У кожного — своя спеціалізація. Комусь подобається працювати з базами даних, а хтось пиляє сек’юріті або пише мегаоптимальний код для роботи з мережею. Тому ми вказуємо рекрутеру предметну сферу і частини проекту, для яких шукаємо кандидата.

Далі йдуть додаткові побажання:

  • Освіта. Бажано вища профільна. Такі спеціалісти, згідно з моїм досвідом, зазвичай мислять більш системно. Винятки також є: у нас є розробник без базової IT-освіти, але це компенсується талантом та величезною зацікавленістю.
  • Мова. Англійська хоча б на рівні швидкого читання та розуміння.
  • Технічні нюанси. Умовно, якщо шукаємо людину на Django, треба розуміти SQL, бази даних. Для C++ — вміти працювати з WinAPI, застосовувати сучасні технології та патерни.

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

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

Перші фільтри: базові питання, резюме та пет-проекти

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

Простий приклад вхідного питання: «Що таке масив, що таке список, і чим вони відрізняються?». Ми допомогли рекрутерам самим зрозуміти різницю, щоб вони одразу розпізнали, коли кандидат видає нісенітницю.

Під час опитування базової теорії відпадає до 90% безперспективних кандидатів, особливо «senior’и з річним досвідом».

Коли резюме потрапляє до мене, насамперед я дивлюся на відповіді щодо бази. Потім — на освіту. Потім — на досвід. Скажімо, кандидат працював у банку, потім півроку займався QA, після чого став програмістом. Тут буде багато питань. Або, наприклад, написано «10 років С++, 15 років Python», але при цьому людина була сисадміном. Обов’язково перепитаю рекрутера про професійний шлях кандидата та зроблю собі помітку.

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

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

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

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

Блоки питань на співбесіді: від базового до глибокого (але теж базового)

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

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

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

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

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

Досвідчена людина насамперед має розуміти базові речі. Де використовуються списки, а де — масиви. Чому в одному разі сортувати краще «бульбашкою», а в іншому — «пірамідою». Необов’язково, щоб спеціаліст умів це все робити руками, але повинен знати та розуміти, коли та як застосувати.

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

У випадку С++ та C# мені цікаві знання з ООП. Людина може на автоматі видати три принципи: поліморфізм, інкапсуляція, наслідування. А поліморфізм — це віртуальні функції. Тут я можу спитати: «А як взагалі працюють віртуальні функції?». Якщо людина знає і розповідає про таблиці віртуальних функцій, це вже великий плюс. Це означає, що спеціаліст розбирається в механізмі, а не просто його використовує. Такий підхід показує розробника більш високого рівня, ніж початківець.

Іноді С++ розробникам можу ставити начебто дурні питання на кшталт «як мінус один буде представлений у двійковій або шістнадцятковій формі?» або «скільки буде 2 у 8-й ступені?», «а чому саме так?», «що там про прямі та додаткові коди?». Це дасть змогу побачити, наскільки людина орієнтується у «бітовій магії», яка для C++ актуальна і сьогодні.

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

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

Досвідченого спеціаліста питаю за тим самим принципом, тільки глибше за кожним параметром. Щодо Python-Django можна поцікавитись, як людина працює з Object Relations Model. Після кількох питань видно, чи людина знає, в якому разі генерується мегазапит до бази, а в якому — все швидко пропрацюється з кешуванням даних.

Мій колега практикує ще один підхід. Після кількох стандартних запитань він ставить таке, на яке людина, найімовірніше, не знає відповіді. Але сама відповідь — другорядна. Важливо, як спеціаліст буде мислити та рухатись до рішення, що буде згадувати, на що спиратися. І чи взагалі візьметься. Наприклад, як Python-програміст зорієнтується в завданні про управління пам’яттю, яке більше властиве для С++?

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

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

Якщо ж людина може пояснити чи хоча б розуміє, куди копати, це вже добре. Навіть якщо каже, що піде в Google або на Stack Overflow, це вже активність. Є в мене приятель, який на співбесідах так і відповідав, не пам’ятаючи про деталі «бульбашок» чи дерев. І його наймача це влаштувало. Людина встигла попрацювати в Lukas Arts, а нині — на senior-позиції в Microsoft.

Тут можна спитати — а де ж межа занурення в нюанси?

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

Що зайве на співбесіді

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

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

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

Ви робили ігри? А як працювали з персонажами? Як використовували моделі? Ага, тобто у вас була загальна модель, а з неї ви наслідували людей, коней, котів?

Використовували список? А чому? Якби замість списку взяли дерево, що було б?

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

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

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

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

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

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

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

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

Якщо вам здається, що я дуже багато пишу про базові знання, вам не здається :) Можливо, це суб’єктивізм. Але він зовсім не заважає.

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

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

База, зокрема, допомагає проводити співбесіди за різними спеціалізаціями. Наприклад, на старті SENET ми шукали бекенд-програміста на Python Django, а фронтенд — на Angular. Я не маю досвіду ні в тому, ні в тому. Але перевіряючи базові знання, можу зробити висновок: людина розуміє основи, які можна застосувати абсолютно до всього, отже, далі вона розбереться.

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

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

Проте це не стосується співбесіди. На неї обидві сторони приходять не мірятися характерами.

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

Для мене діє маркер — «як на співбесіді, так і в роботі».

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

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

Колеги іноді питають: «Що робити з тими, хто зумів справити враження, а в роботі виявився майже нульовим?»

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

Що робити в разі неспівпадіння

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

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

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

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

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

👍ПодобаєтьсяСподобалось22
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Доу!? Когда введут дизлайка для статей? Или это для пятницы?

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

Як розпізнати недосвідченого розробника

кидаєш рушник на підлогу на порозі переговорки:
якщо кандидат переступає — недосвічений

always know where your towel is

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

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

отпуск можно брать только через полгода

Скотиняки. Должны ведь давать на следующий день, минимум недели на 4.

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

ФОП на стероїдах:

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

Конкретно те условия, что Вы пишете, в разных компаниях разные, и о них вполне себе рассказывают.

In addition „Medical insurance after 6 months of work”
So some magic happens only „after 6 months” ;)
На такое можна прогнуть только какого-то мидла (и то не очень опытного)

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

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

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

Можно продолжать бесконечно....

Іноді С++ розробникам можу ставити начебто дурні питання на кшталт «як мінус один буде представлений у двійковій або шістнадцятковій формі?»

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

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

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

Для плюсовика эти вопросы сильно ближе чем мне.

Ну я плюсовик с 15 летним опытом, а иногда и в С embedded участвовал, в разработке драйверов под Linux где как бы с битовой арифметикой иногда стыкался — регистры там, маски итд.
Не скажу, что я гениальный программист, но худо-бедно задачи выполнял всегда.
Сказать, сколько раз я имел дело с бинарным представлением вещественных чисел? 0.
А с бинарным представлением отрицательных чисел? Тоже 0.
Т.е. со студенчества я помню, что-то там битово инвертируется и еще что-то делается, на этом память моя заканчивается.
Если потребуется, то эта память восстанавливается за 5 минут гугленья.
Но на кой черт это на собеседовании спрашивать, не понятно.
В плюсах есть 100500 других более актуальных вопросов, которые выявят конкретный опыт у человека.

Также надо понимать, что у всех людей память работает по-разному.
У меня например не используемые знания задвигаются в далекий-далекий ящик и на 95% стираются, что не мешает их восстановить, приложив время и прочитав литературу заново — главное понять в какую сторону надо копать, для чего и служит этот остаток 5%. Я б наверно умом двинулся, если б помнил все 100% со всех проектов в которых работал.
А жена моя помнит школьные стихи спустя 20 лет.

Ну про вещественные ты сам добавил, я знаю ответ потому база у меня на плюсах и ассемблере, работаю только с дотнетом уже 12 год и хайлоад на нем требует глубокое понимание всего этого бо по дефолту будет тормознутое приложение, а не хайлоад. А на вопрос ТС’а ты ответ знаешь и написал, вероятно этого бы хватило

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

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

хайлоад на нем требует глубокое понимание всего этого

А что, сильно пригодилось понимание как бинарно представлен double или −1 для решения проблем .NET хайлоад?

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

Да, вот мой оч древний ответ на со stackoverflow.com/a/13493771/1477076 такое и более вычурные варианты мне приходилось применять для того чтобы добиться скорости

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

не скажи )) вот я начал писать не железяки даже а так финансовый софт для разных больших дядек для которых все эти интернеты ваши выглядят вот так

youtu.be/qdjRwpYM-Kw

youtu.be/iDbyYGrswtg

угадай на когда столкнулся с представлением бинарных вещественных чисел? (тут трывожна мовчанка) буквально на второй день )) потому что у 64-битного целого числа 63 значащих бита а у 64-битного double всего 53

upd: actually господин соврамши привычка заглядывать в википедию )) не 53 а 52 бит мантиссы

и дядечки имея преобразование туда сюда в какой-то момент озадачились а куда деваются «хвостики» и что вообще происходит

youtu.be/yms1SCV7rtA

Если потребуется, то эта память восстанавливается за 5 минут гугленья.

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

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

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

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

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

У меня например не используемые знания задвигаются в далекий-далекий ящик и на 95% стираются

а зачем тебе вообще этих на 95% не использованных знаний? зачем ты вообще их набрал? ))

А жена моя помнит школьные стихи спустя 20 лет.

и я помню )) только не 20 лет конечно может ты просто стихи в школе прогуливал всё так же ж рассчитывая погуглить если 20 лет то интернет уже 146% был ))

скажи дядічкам, хай переходять на Гошечку, і використовують пакет Decimal
можеш не дякувати

у них навіть на джаві біг децімал є ))

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

Ну я помню 5% информации по этой теме, а именно что:
— битовое представление положительных и отрицательных чисел отличается
— представление вещественные чисел отличается от целых
— что вещественные числа имеют ограниченную точность.
Этого хватает для 99% задач.
Остальное я не помню и пойду гуглить.
Очевидно, что этого недостаточно для внятного ответа на собеседовании на вопрос о битовом формате отрицательных чисел.

а зачем тебе вообще этих на 95% не использованных знаний? зачем ты вообще их набрал? ))

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

Ну и наперёд неизвестно, какие знания тебе пригодятся.
Недавно пригодились 5% от того что помнил по курсу DSP — ухватиться за понятие «спектр» и понять и подпатчить алгоритм основанный на спектральном анализе.
Хотя изначально я уже не помнил ни теорему Найквиста, ни всех этих window функций, и мне потребовался 1 месяц чтоб повторно разобраться в теории, которую изучал 20 лет назад.
И то, я восстановил в памяти только ту минимально требуемую часть теории, для решения текущей задачи.

Ну я помню 5% информации по этой теме, а именно что:

именно )) а я помню принципы

— битовое представление положительных и отрицательных чисел отличается
— представление вещественные чисел отличается от целых
— что вещественные числа имеют ограниченную точность.

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

Этого хватает для 99% задач.

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

Остальное я не помню и пойду гуглить.

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

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

Ну и наперёд неизвестно, какие знания тебе пригодятся.

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

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

Ну и наперёд неизвестно, какие знания тебе пригодятся.

что видимо даже не подозреваешь на сколько точно ты попал в реальность т.е. да это суровая реальность «наперёд неизвестно какие тебе понадобятся» но постой как чувак (здесь обобщение) у тебя же ж есть план вот проект дома вот проект ремонта ты сейчас пытаешься сказать что ты (здесь обобщение) не можешь даже составить план «какие тебе пригодятся» по уже готовому проекту ну я с этим ок )) я с этим живу вот уже последних 5 лет и ничё так хорошо живу только конечно местами интеллектуально больно но селяви ))

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

как и прочие формы интеллектуального не равенства ))

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

я понятно объясняю?

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

Делить людей на какие-то касты — это порочная практика в принципе.
А по каким-то эфемерным признакам, вроде способности помнить детали бинарного представления чисел — тем более.

я понятно объясняю?

Давай я не буду отвечать на этот вопрос :-)

Делить людей на какие-то касты — это порочная практика в принципе.

youtu.be/5zMG_k2P2rY

у 64-битного целого числа 63 значащих бита а у 64-битного double всего 53

upd: actually господин соврамши привычка заглядывать в википедию )) не 53 а 52 бит мантиссы

Перший біт завжди вважається 1 і тому не пишеться, 0 записано у експоненті.
Тому 52 біт мантісси, але 53 значущих біти і це — різні речі! Вікі шарить і треба їй було вірити)
Significand precision: 53 bits (52 explicitly stored)

масиви та списки

ArrayList vs int[] серйозно?

Lukas Arts

пс LucasArts

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

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

То давай, розкажи, як часто тобі знадобилося поняття «алгоритмічна складність» в реальному програмуванні? Не те, що можна до цього поняття привести, а саме поняття для пояснення чогось? Бо «базові речі» — це те, що потрібно щодня, на що треба спиратися. А не те що «треба» визубрити «для общєґо развітійа».

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

От ти особисто — скільки разів у житті сортував пірамідою? І чому не можна на цю цифру ділити :)

І чому не можна на цю цифру ділити

Чому?

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

Наноль делить нельзя.

так ведь можно же... (+/-)inf, nan ?

Класна стаття!

Перечитав статтю, респект автору, вставлю і свої 5 копійок.

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

З приводу завдання на співбесіді в ріалтаймі я абсолютно солідарний з автором, бо 100% знаю, що в стані схвильованості людина не здатна думати адекватно. Знаю, бо я сам страшенно туплю в такій ситуації ... пам’ятаю, на одній з останніх співбесід, котрі я проходив, мене попросили написати фукнцію, котра отримує в якості вхідних параметрів 2 числові масиви і повертає масив, котрий складається з елементів, котрі є в обох вхідних масивах ... ви скажете «лєгкотня»!!!! .... і я погоджуся з вами у випадку, якщо я сиджу собі у звичайній робочій обстановці і пишу код ... але на співбесіді я настільки розгубився, що не зміг написати такої функції ... коли я намагався трішки розслабитись і зконцентруватись на завданні — кожен комент/слово/підказка від рев’ювера ще більше мене вводила в ступор ... і єдине, що я казав собі в той момент — «чувак, давай!!! збирися!» .. але далеко не завжди це вдається зробити!

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

Це — не здраво. Я б це пояснював і посилав із підбором: «тому спочатку заведіть це у спринт, в мене увесь час зайнятий». Тоді вони у відповідь підуть у адекват, або у неадекват. Загалом мені здається, це — проти практик того самого agile через які ті спринти взагалі є.

в стані схвильованості людина не здатна думати адекватно

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

Несколько советов, что я поменял бы в процессе технического подбора.
Основано на личном опыте проведения техсобесов :)
1.

Менеджер витрачає час на ... перевіряє тестові

Я бы давал это на откуп техлиду / синьору в команде. У менеджера может быть опыт, оторванный от реальности, особенно если его последний коммит был с полгодика назад.
2.

Перед першою розмовою HR-менеджер узгоджує з замовником вакансії вхідний опитувальник.

Не надо сваливать на рекрутеров те задачи, в которых они некомпетентны. В лучшем случае, они могут сверить заученный книжный ответ с полученным. Если же кандидат читал другую книгу или вообще самоучка — его ответ может быть абсолютно правильным, но рекрутер просто это не поймёт.
Что может (и должен) проверить рекрутер:
а). Общую адекватность кандидата (навыки общения, хамство, поведение в конфликте, если рекрутер продвинут в психологии — построить базовый портрет кандидата по любой из систем);
б). Fit to the team (например, если вся команда приходит в 12 и уходит в 8, то жаворонок, начинающий в 7 утра — не лучший выбор, уменьшаем окно взаимодействия);
в). Инглиш. Были реальные кейсы, когда кандидат по скиллам подходил норм, но инглиш оказался на A1/A2. С учётом необходимости общения с заграницей — увы...;
г). Откровенное враньё в CV типа дописанных лет опыта. На его уровне можно распознать не всегда — но можно попытаться.
А вот попытки рекрутеров задать технические вопросы выглядят откровенно жалко и лично мне многое (в основном негативное :)) ) говорят о конторе.
3.

А я читаю резюме, трохи занурююся в конкретику.

По моему опыту, это лучше сделать за полчасика до интервью, наметить базовый список вопросов к кандидату. А на этапе, когда он рассказывает про свой опыт, посмотреть, как то, что он рассказывает, коррелирует с тем представлением, которое возникло на этапе прочтения CV. Это может дать дополнительные вопросы и пищу для раздумий. Если же слушать и читать в параллели — то первичное впечатление сложиться не успеет и будет смазанным. Это приведёт к тому, что начинаешь «бить по площадям» вместо того, чтобы целенаправленно копнуть то, что вызывает сомнения. А значит, снизит точность и эффективность интервью.
4.

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

Уже писали, повторюсь:
а). Во-первых, это маркер овертаймов. Притом, оч возможно, неоплачиваемых. Овертаймы — маркеры жлобства конторы и / или некомпетентности менеджмента. Огромный красный флаг для миддлов и выше. НИКОГДА не называйте этот критерий в числе главных для отбора, если не хотите получить ответ «спасибо, ваш проект мне не оч интересен». Можно сказать в ответ на вопрос про овертаймы «ну да, бывают, как и у всех». Но низзя говорить «нам важен кандидат, готовый к овертаймам». Это означает, что личное время сотрудника для конторы — ничто.
б). В последние несколько лет work-life balance начинает приобретать большее значение. Наверное, связано со смещением среднего возраста синьоров вверх. А это означает семьи, детей. А значит, no-life подход постепенно исчезает и значение развлекалок в офисах типа глобаловского G-Club перестают иметь настолько большой вес. Особенно в период удалёнки.
в). Оч многие ставят границы между рабочим и личным. И вопросы «чем ты занимаешься в свободное время» могут оказаться красным флагом, попыткой залезть в личное пространство. С ожидаемым ответом «спасибо, ваш проект мне не оч интересен». Вместо этого лучше спросить «какое у тебя хобби».
5.

Наприклад, якщо я візьму програміста на C#, який поза роботою любить пиляти фронтенди, є ризик, що одного дня він туди й піде

Ну и пусть себе пиляет. У вас в конторе нет позиции фулстека? На крайняк, оговорите «минимум год пиляешь бек, а затем перейдёшь в фулстеки, если будет желание». Главное — понять, как можно утилизировать навыки кандидата с максимальной пользой для проекта, а не зациклить человека на 1 позиции навечно. Такого всё равно не будет. Люди развиваются, и это — нормально. Наоборот — если я знаю, куда развивается кандидат, я буду понимать, что и как ему предложить, чтобы получить win-win, вместо того, чтобы через год услышать «я тут потихоньку выучил N, тут его применить негде, так что я пошёл потихоньку».
6.

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

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

Одні думають та відповідають. Інші намагаються змінити тему розмови або переходять до атаки: "Не знаю, ніколи не думав, хто цим взагалі зараз користується?"

Вы получите, если кандидат почувствовал себя им. Для QA собесов (а я провожу именно их) я задаю обычно задачки по процессам на этом этапе.

Надеюсь, будет полезно :)
Как Вам, так и остальным, кто проводит техсобесы.

Похоже у многих статья вызвала разрыв шаблона. И это не удивительно — большинтсво сейчас не видело другого ИТ, кроме галер! Да и редко работало где-то дольше 3х лет подряд — ведь для роста надо «прыгать» по галерам.
Совсем другое дело, когда девелопера себе ищет продуктовая компания. Ведь нужен не просто «гребец», а человек, который будет воспринимать продукт как свой и стремится его развивать. Такой сотрудник — уже сам по себе капиталовложение: его развитие и его креативность будет двигать вперед компанию. Ведь по большому счету продуктовая компания — это люди, которые строят продукт как свой.
Поэтому да — на собеседованрии вопрос даже не про технические знания, а про отношение к работе, про ценности и цели человека. Если ищут сотрудника на годы вперед — то он успеет подтянуть любые скилы. Вот это только если он то же хочет развиваться и готов посвятить эти годы одной компании и одному продукту. А таких людей сейчас не просто найти! Галеры их испортили ...
«Парадокс українських IT-компаній: чому культивуються посередні програмісти?»
dou.ua/forums/topic/34724

Галеры их испортили
для роста надо «прыгать» по галерам

Тут вже неодноразово розповідали простий рецепт успіху аби люди не тікали:
1. Давати розробнику ринкову зп, ту, яку він зможе отримати в конторі через дорогу, промоутити 1-2 рази на рік без необхідності отримання сертифікату на сертифікат.
2. Дійсно вкладатися в розвиток софт і хард скілів своїх колег, навіть якщо ці хард скіли зараз незатребувані на проекті. Адже не секрет, що багато хто тікає через те, що боїться, що його знання застаріють і він потім не зможе знайти роботу.
3. Опціональний але дуже важливий пункт: Частка в компанії і/або 4-денний робочий тиждень або 6-ти годинний 5-ти денний.

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

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

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

Парадокс українських IT-компаній: чому культивуються посередні програмісти?

Оцю коротеньку казочку 1951 року має прочитати кожен, хто так чи інакше працює з людьми (або працюють із ним). Уильям Тенн. Нулевой потенциал

Если ищут сотрудника на годы вперед — то он успеет подтянуть любые скилы.

а что не успеет отдадим на аутсорс чистый профитЪ ничего личного селяви ))

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

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

З приводу хоббі — не запитую і сам не люблю відповідати на такі запитання.
Тема питань по CV не розкрита.

З особистого досвіду — декілька років хайрю на DS/ML Python та деякі суміжні технології для SaaS/PaaS (так що зважайте на проф деформацію у зв’язку з ds роботою :/ ), на рівні від джунів до лідів та використовую схожий принцип:

1. Скрін питання для HR, 5-10 простих концептуальних запитань. Достатньо просто переглянути потім записи HR / прослухати шматок розмови (якщо кандидат дав згоду на запис). В США такі опитувальники є у багатьох компаніях по всьому спектру розміру компанії, включаючи FAANG.
False Negative коштує дешевше ніж витрачати час на 5х+ кількість співбесід.

2. Take home завдання на 1 вечір (після підписання NDA). Якийсь простий / найпростіший датасет з тих, з якими ми працюємо, з поставленною задачею та декількома requirements — 1. EDA, 2. проста модель та 3. її оцінка. Тут дивлюся не на те наскільки гарно зроблене завдання / крута модель, а радше на кількість відвертих фейлів. Зазначаю кандидату, що час виконнання (кількість витраченних днів) також має значення. Гарне проксі до зацікавленності, хоча не завжди вірне. Серед найчастіших фейлів — кандидати пропускали якийсь з пунктів requirements, наприклад оцінку (!). Також можна глянути на стиль коду та наскільки уважний кандидат. Зазвичай релевантний досвід відчувається в такому завданні. Треба зважати що виконання take home може бути не індивідуальне.

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

3. ​Перші 3-5 хв коротко розказую про компанію, кого ми шукаємо та чим я займаюся, щоб кандидат краще зрозумів контекст проєкту, про які скіли їй розповідати і приблизний бекграунд інтерв’юера.

4. Далі близько 15 хв запитання по резюме. Хоч і коротка, але дуже важлива секція. Зазвичай оцінюю глибину та ширину, вибириаю 2-3 проєкта, та даю запитання про те чому приймалися конкретні рішення. Якщо в резюме вказано 2+ років на проєкті, але глибини або ширини немає, то це викликає підозри. Питання про чому приймалися якісь рішення може слугувати проксі до широти знань та софт скілів.

5. 20-25 хв 5-7 категорій по декілька запитань кожна. Відносно прості питання по теор базі; прикладні аспекти ML; прості концептуальні питання по software engineering / Python з deep dive в теми знайомі кандидату (виходячи з CV). Більш досвідчених можу запитати якісь архітектурні або MLOps запитання.
З приводу fundamentals — якщо людина не знає що таке власні вектори та власні значення, або не знає різницю між лінійними та афінними перетвореннями (можна без складних слів) — червоне світло для мене. Якщо людина і зможе розв’язати якусь більш-менш нетривіальну ML проблему — це буде радше всупереч, а не завдяки. (декілька разів наймали норм кодерів з не дуже теор базою на DS/ML позицію — і кожного разу звільняли, людина просто не розуміє де дебажити алгоритм і за 0.5-1 рік важко на норм рівень вийти, якщо ще хоч якісь таски робити окрім навчання) (я не кажу про SE ML позиції).
Окрім деяких випадків, коли кандидат добре знається на якійсь темі, не витрачаю більше 2-3 хв на 1 запитання, цього зазвичай достатньо щоб приблизно зрозуміти знання у цьому піднапрямку. Але так, багато покрити за 20-25 хв не вдасться.

6. 5-10 хв невеличке код завдання рівня easy leet code, без жодних складних алгоритмів. Глянути на швидкість, стиль написання коду, знання основних Python’s built-ins і базове логічне мислення.

7. 5 хв питання від кандидата. Може заробити невеликий плюс або мінус («умовна» зацікавленість проектом, темою, що саме важливо кандидату) — тут все більш менш ясно, але і суб’єктивно також. Не раджу задавати зовсім шаблонні питання.

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

Після співбесіди формую профіль кандидата по 7-10 параметрам за 5 бальною шкалою (очевидно, суб’єктивною, яка годиться тільки для порівняння кандидатів між собою, але не в абсолютному вимірі). Далі обговорюю подальші дії / «софт» співбесіди з керівництвом компанії (а також з лідами проєкту).

Зазначу також, що погані софт скіли — наприклад offensive поведінка чи хамство для мене це великий червоний флаг. Часто senior кандидати можуть мати в деяких піддоменах досвід більше, ніж інтерв’юер, але це не привід поводитися по хамськи. Можете розраховувати, що в роботі буде так само.

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

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

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

Мені також потрібно до психоаналітика чи куди там коментатори відправляють? :D

Які ваші зауваження до такого підходу?

Позволить себе такой FAANG-like многоступенчатый подход вы себе можете из-за специфики (

DS/ML

) — многим хочется в эту область по разным причинам.
Пересичных же WEB/CRUD проектам это не подойдет, так как кандидат отморозился бы на первом же этапе, потому как проектов сейчас больше, чем кандидатов.

Дуже неоднозначне враження про статтю.

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

З профілю автора, він володіє C++, C#, .NET, Python, WinAPI, embedded devices, але тут же в статті пише:

Це стосується і напрямів. Наприклад, якщо я візьму програміста на C#, який поза роботою любить пиляти фронтенди, є ризик, що одного дня він туди й піде.

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

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

«як мінус один буде представлений у двійковій або шістнадцятковій формі?» або «скільки буде 2 у 8-й ступені?», «а чому саме так?», «що там про прямі та додаткові коди?». Це дасть змогу побачити, наскільки людина орієнтується у «бітовій магії», яка для C++ актуальна і сьогодні.

Ну це класика того, як приходять на інтерв’ю посамостверджуватися, а не найняти)
Якщо вас питають на співбесіді щось подібне або просто відчуваєте, що питають якусь дічь — відразу задавайте два запитання: А з якою метою це запитання? Чи будемо ми щодня на проекті це використовувати?
Якщо йде невнятний пасаж про «ну це ммм база це треба знати», «що за девелопер який напам’ять незнає таблицю двійкових кодів» то перед вами два варіанти:
1. Прийшов хтось із універа який звик проводити екзамени і невміє/нехоче питати щось нормальне.
2. Людина прийшла посамостверджуватись, по-простому повийожуватись і ви тут нафіг нікому не треба, принаймні нетреба персонажу навпроти вас.
Можна або спробувати пояснити людині, що ви прийшли робити робочі задачі і варто визначити наскільки саме їх ви будете здатні виконувати або ж просити завершити співбесіду.
Аналогічний підхід якщо вам дають шматок дічайшого гавнокоду і просять розповісти що тут відбувається:
1. А ви на проекті теж так пишете?
2. А чому питаєте, якщо на проекті цього нема?

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

Окремий пункт про роботу з пам’ятю. Ви не вказали, що саме ви питаєте, але судячи з контексту статті, робите упор на особливості роботи new, maloc, delete, placement new, дибільні шматки коду по типу `delete this` і подібне.
Тема потрібна але знову ж таки, більше 5-10 хвилин на неї витрачати не варто.
Куди важливіше в контексті роботи з пам’ятю запитати про пули потоків та смарт поінтери і роботу з ними, ось тут вже можна розвернутися і перевірити як знання так і банальну логіку.

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

«Що таке масив, що таке список, і чим вони відрізняються?».

Ничем © Python

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

Інші намагаються змінити тему розмови або переходять до атаки: «Не знаю, ніколи не думав, хто цим взагалі зараз користується?». Для мене це погана реакція.

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

Якщо ми маємо сторінку, написану на чистому HTML, відправляємо з неї форму, то в якому вигляді приходять дані на бекенд?

Оскільки я претендував на роботу зі стеком Angular + Node.js, то ясно що я працював би із JSON у 99,9%, а у тому малоймовірному 0,1% я проглянув би що там приходить через консоль, за 30 хвилин знайшов би хороший парсер і підключив би його, і з цим проблем немає. Але інтерв’юер вирішив зайти у ці непотрібні дебрі з чистим HTML. Як мені реагувати на таке? Кажу що з моїм стеком це взагалі ніколи не було потрібно. Це погана реакція?

Выросло поколение, что не знает как браузер собирает данные с формы)

А ви знаєте як саме браузер це робить? Чи ви хотіли сказати «не знають в якому вигляді браузер передає ці дані»?

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

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

Так а хіба є такі люди, що сидять тільки у вашій компанії по 10 років? Це по-вашому нормально?

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

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

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

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

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

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

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

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

Четвертому скажешь, что нет ни детей, ни спорта, ни проектов — подумает, что безответственный (а, возможно, еще и алкаш).

Короче, нефиг давать простор для фантазий.

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

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

>> Короче, нефиг давать простор для фантазий.

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

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

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

Явно вы не на галере работаете.

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

Зато денег больше станет если его продали клиенту! И пока клиент готов платить за людей (а не за результат) — то будут брать всех, кто «попадет в дверной проем».

Явно вы не на галере работаете.

На ней родимой, 500+ штыков

И пока клиент готов платить за людей (а не за результат)

Да ну

И пока клиент готов платить за людей (а не за результат) — то будут брать все

Первое правило галер.

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

Я даже увольняю людей, некоторых, например

То вас можна привітати? Позбулись того депресивного?

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

Вы отправились искать вторую работу, а на одном из интервью на том конце провода оказался ОН?

Мне попадались рекрутеры, для которых джава и джаваскрипт одно и то же. Ладно это баян, мне попадались те, для кого сиквел и с++ одно и то же. Это вообще как? И самое смешное, это рекрутеры, которые хантят тебя в ту компанию, в которой ты сейчас работаешь. Но есть и те, что шарят, да.

Ха, я так программировать начинал, первые 3 месяца учил JavaScript вместо Java, хорошо умные люди подсказали... А так был бы...

P.S. Попадались рекрутеры которые на слух воспринимали isPalindrome, или max element in BST. Сложность базовых алгоритмов знали и тд.

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

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

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

Це дуже корисно. Згадуючі свої невдалі інтерв’ю, я рідко коли можу згадати, щоб надавали фідбек взагалі :)

під жорсткими NDA. Тоді можна надіслати приклади напряму.

OK...

Холдинг может гордиться тем, что потом его код разлетится по миру «напрямую»).

Натрехбуквенная трактовка трехбуквенной аббревиатуры.

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

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