Hot Positions, Cool Company! NeoGames
×Закрыть

Хороші та погані практики найму. Поради для роботодавців і кандидатів

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

Певний період я часто ходив на співбесіди. Не тому, що шукав роботу, а тому, що процес був цікавий. Це допомогло мені прокачати навички, адже я отримував фідбек про свій рівень і чув нові «незнайомі слова», тобто про нові технології, які пізніше вивчав. Наприклад, так я ознайомився з Docker’om, коли про нього ще ніхто не чув (це був приблизно 2014-й).

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

У статті я виділив погані та хороші практики. Докладніше про це розповідав на конференції QA DAY 2020.

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

Ілюстрація Аліни Самолюк

Що не треба робити

Отже, погнали. Уявіть, що ви техексперт на співбесіді.

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

Запитайте про різницю між лоад- і стрес-тестами. Ставити питання з першого-ліпшого списку Top-100 QA interview questions — тупо. Ці питання настільки заїжджені, що достатньо вивчити перші 15 — і вдасться пройти співбесіду в багато компаній. Часто ті самі питання ставлять як на Junior-рівень, так і на Senior. І відповіді очікують ті самі.

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

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

  • помилка на фронтенді;
  • помилка на бекенді;
  • кнопка закрита іншим елементом, відповідно клік не відбувається;
  • інші варіанти, про які напишуть у коментарях.

Інтерв’юер проігнорував ці відповіді та сказав: «Там, напевно, event handler на клік не додали». І ось що виходить: з-поміж усіх можливих варіантів він очікував лише відповідь про event handler. І тільки її вважав правильною.

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

Що треба робити

Інтерв’ю — не іспит, не варто проводити його як совковий викладач місцевого політеху. Мені нерідко траплялись співбесіди у стилі обміну визначеннями: «Що таке HTTP?» — «HTTP — це hypertext transfer protocol, протокол передачі гіпертексту!» — «О, молодець. Шариш».

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

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

Окремо я хотів би виділити те, що варто робити інтерв’юеру та рекрутеру.

Готуйтеся до кожного інтерв’ю. Ознайомтеся з наявною інформацією про кандидата: резюме, сторінка у LinkedIn, GitHub. Повірте, там можна знайти багато даних за короткий час (10–30 хв буде достатньо). Угу, всі завжди зайняті, дедлайни, мітинги та термінові проблеми на проді... Але ви не можете виділити 15 хвилин на ознайомлення з кандидатом і хочете, щоб він у вас працював декілька років? Нелогічно якось.

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

Досвід у роках — неважливий. Мені доводилося шукати автомейшн зі знаннями Python. І на одну й ту саму вакансію були два кандидати з двома роками досвіду. Перший вирішував багато задач на проєкті, і його знання Python були достатніми для цієї позиції. Другий два роки займався Ctrl+C та Ctrl+V і взагалі не знав Python. Але формально двоє відповідали цим критеріям. Також досвідченому інженеру нескладно змінити мову програмування, особливо в автоматизації тестування. Тож висновок з цього такий: краще напишіть, які саме фічі мови програмування ви використовуєте, так можна краще зрозуміти, чи кандидат підходить.

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

Якщо кандидат не розуміє питання, спробуйте пояснити, що ви очікуєте почути у відповідь. Наприклад, я чув такі питання: «Що відбувається після того, як користувач введе назву сайту у браузері?». Інтерв’юер очікує почути про модель TCP/IP, які протоколи використовуються, як вони взаємодіють тощо. Не завжди кандидату вдається зрозуміти, що саме ви хочете почути. Це нормально, коли люди з різних компаній та оточень іноді трактують одне й те саме по-різному. Оскільки у кожного власний попередній досвід і сприйняття.

Якщо ви — кандидат

А тепер — ви кандидат у пошуках. Або не в пошуках, але вам написав рекрутер і підкинув пропозицію. Що варто знати й робити?

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

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

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

Пишіть про технології та підходи, з якими ви безпосередньо працювали. «Ну, Jenkins був у нас на проєкті. Я там іноді натискав на велику зелену кнопку», — каже кандидат, який нібито займався Jenkins. Хоча не має жодного поняття, як він працює чи як налаштувати простеньку Job’у. І це поширений приклад.

Погрупуйте назви інструментів за відповідними категоріями. А всяки утиліти типу WinSCP та TotalCommander взагалі би не додав до резюме.

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

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

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

Яку ціну ставити за тестове завдання

Колись я побачив дискусію на форумі DOU про платне тестове завдання. За такою логікою можна вимагати гроші за відвідування співбесіди. Можна було б заробляти лише походами на інтерв’ю. Якщо вам не подобаються тестові завдання, одразу кажіть, що не будете їх виконувати.

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

Я дуже підтримую тестові завдання. У них можна побачити, як кандидат думає та пише код. Що вищий рівень спеціаліста, то більше ви очікуєте побачити у коді (обробка помилок, логування, структурування коду, навички користування Git: чи є бінарники у репо, чи використовує .gitignore, робить один коміт чи є якась історія, а може, ZIP-архів).

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

А тепер невелика статистика, за моїми спостереженнями. З десяти кандидатів, тестове:

  • п’ятеро не виконує;
  • у двох код не білдиться;
  • у двох код падає або не робить те, що потрібно;
  • в одного код працює, як очікується.

Коротенький підсумок

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

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

Успіхів у пошуках.

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

Дякую, що дочитали!

👍НравитсяПонравилось30
В избранноеВ избранном10
Подписаться на тему «собеседование»
LinkedIn

Похожие статьи




Підписуйтесь: iTunes | Google Podcast | YouTube


35 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хороша стаття!)

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

Це Ви ще не були на співбесідах в FAANG. :)
Там і крапку треба правильно поставити на листочку і дужку закрити і так далі.
І на пам"ять знати всі абревіатури, технології, як пам«ять (всі її типи) працює і загалом бути ходячою «вікіпедією» )))

Це Ви ще не були на співбесідах в FAANG. :)
Там і крапку треба правильно поставити на листочку і дужку закрити і так далі.

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

Готуйтеся до кожного інтерв’ю. Ознайомтеся з наявною інформацією про кандидата: резюме, сторінка у LinkedIn, GitHub. Повірте, там можна знайти багато даних за короткий час (10–30 хв буде достатньо).

Оцініть витрати часу на такий бекграунд чек? Базово погуглити можна і за 5 хв. Але яку корисну інформацію ви можете звідти отримати?
ГітХаб. Продакшн код відрізняється від пет-проджектів на гітхабі (і добре якщо то пет-проджекти, а не якісь тести технологій і тд). Знову ж, якщо мова йде про більш-менш серйозні проекти, то там і за 30 хв не впораєтесь.
Це все ті речі, які можна з’ясувати за 5 хв на співбесіді (ще й закрити «перевірку англійського»).

Запитуйте лише те, що потрібно для вакансії.

Запитання «не по вакансії» задаються (адекватними інтервьюерами) не «на перспективу», а щоб зрозуміти наскільки людина зацікавлена у своїй спеціальності, наскільки прагне розвиватись. Ще у великих компаніях часто співбесіди проводять, щоб зрозуміти на який проект людину краще взяти.
У випадку з неадекватами, про «цікаві топіки» (типу перформанс тестінга) будуть питати, щоб почесати ЧСВ.

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

Мене просто спитали: «Зробить зможеш?». «Скільки грошей хочеш?». «Ок».
Лисак, здається, теж про таке писав.
Оце — найліпший варіант найму.

Це звичайно класно. Якось пропонували платити по 50$ за кожну годину витрачену на співбесіди(бо їх було кілька). Але тільки у випадку найму.

Якось пропонували платити по 50$ за кожну годину витрачену на співбесіди(бо їх було кілька). Але тільки у випадку найму.

Жест з розрахунком на лохів. Виглядає красиво, а по суті неповага до роботи виконаної кандидатом.

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

Хто сказав «тестове завдання»? :)
Ключове питання:
Для чого було витрачати ваш час на реалізацію тестового, свій час на його перевірку і ваш та їх час на обговорення, якщо за 45-60 хв можна було зробити все те саме? (Інтервью до 2 годин — це або кандидат тупить, або просто з ним цікаво розмовляти). Матеріал для самостійного опрацювання dou.ua/...​signment-for-job-seekers

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

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

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

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

Для чого було витрачати ваш час на реалізацію тестового, свій час на його перевірку і ваш та їх час на обговорення, якщо за 45-60 хв можна було зробити все те саме?

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

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

Тут напевно ви не зрозуміли. Питали ЯК, а не ЯКІ. Йшлося про контретні фічі, запропоновані інтервюверами.

А питання про комунікацію між сервісами — це самі стандартні і заїзджені питання.

окей, одне заїжджене :-)

Хоч про шаблон сага або якийсь СіКуРС не питали?

ніт, не питали.

Та й на співбесіді ви не бачите всю команду і часто навіть співбесідуючі можуть бути з інших команд.

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

У вас звісно можуть бути інші вподобання.

Також часто зустрічається цей мисконсепшн:
Співбесіда — це не про вподобання кандидата чи інтерв’юера, а про ефективність процесу.

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

І як це вам допомагає оцінити

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

1) Бекендери ок. А ФЕ, БА, КуА?
2) Звати на співбесіду всю (навіть лише БЕ) команду не масштабується. Та й з мого досвіду добре якщо 3 людини активно приймають участь у співбесіді, зазвичай 1 проводить інтерв’ю, 1 інколи задає доп запитання, інші сидять і слухають.

Тут напевно ви не зрозуміли. Питали ЯК, а не ЯКІ.

Тоді це стандартне флоу дизайн частини більшості інтерв’ю і не потребує витрат часу на ДЗ.

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

Знову ж питання ефективності:
Що вам дає розуміння того що ви готові витратити час на ДЗ? Конторі це дає багато у розумінні __поточного__ стану кандидата. Але якщо у контори немає завдання нажухати кандидата, то ці знання не потрібні.
Для кандидата важлива відповідь на запитання «Чи готовий/хочу я йти працювати в цю конкретну компанію?». І дати відповідь на це питання треба __до__ того як погоджуватись на співбесіду.

---

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

Про яку б це ми компанію могли говорити? :)

Але тут цікавий момент, стратегічно так має бути побудована кожна співбесіда:
Навіть з ДЗ і генгбенгом від усієї команди, люди які оцінюють кандидата мають розуміти що саме потрібно оцінювати. Якщо інтерв’юер 1 (або спрацьована пара), то не потрібно формального списку, якщо багато, то має бути системний список, щоб можна було порівнювати кандидатів, а не вгадувати «ось цей шарить Х, а інших ми про це питали?»
Щодо онлайн редактора, тут треба розуміти, що він накладає обмеження на задачу — немає сенсу просити описати спрінговий контролер. А от якщо людина не може написати без ІДЄ метод на 10 строк, то виникають питання до того чи така людина взагалі інженер. І, доречі, 10-30 хв такого кодінгу замінюють 1-4 години ДЗ.

Тут звісно є інша проблема: недосвідчені інтерв’юери не завжди можуть перейти від «опишіть структуру хеш мапи» до більш глибоких запитань.

Однак важливо розуміти, що резюме — це ще не вердикт. Багато хороших інженерів забивають на резюме і погано його оформлюють.

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

Запитайте про різницю між лоад- і стрес-тестами. Ставити питання з першого-ліпшого списку Top-100 QA interview questions — тупо. Ці питання настільки заїжджені, що достатньо вивчити перші 15 — і вдасться пройти співбесіду в багато компаній.

По факту, однак, багато хто на співбесіді плутає ці поняття, навіть якщо завчив до того, тим більш якщо попросити пояснити на прикладовій системі і кейсах, що з цього лоад, а що стрес.
Але все ж, якщо Ви вважаєте моветоном ставити питання з Top-100 QA interview questions, які в основному взяті з CTFL силлабусу, які тоді питання Ви задаєте на співбесіді кандидатам на посаду джунів/трейні, якщо досвіду дуже мало?

Ви хочете почати займатися автоматизацією? Запитайте, чи вона планується.

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

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

Резюме SoftServe — тааак! Це біль. Цікаво як в самому Софтсерві ще на це не звернули увагу.

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

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

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

Резюме должно быть не больше двух страниц, что бы там ни было...

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

1) Я понимал с чем придется работать — различные серверные штуки
2) Я понимал свой уровень и мог его показать
3) HR понимал, что я понимаю — и выбрал меня

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

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

пан автор допускає існування шкіл, рівень випускників яких достовірно вищий за певну наперед задану планку?

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

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

цей момент я не зрозумів

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

погоджуюсь
дійсно, коли не відписують то це погано. Але це ознака поганого рекрутера
І погоджуюсь, про перевіряючого. Дійсно, все дуже індивідуально. Та впринципі як і співбесіда))
Взагальному радив би:
— дотримуватись основного code convention для мови програмування
— гарно і зрозуміло структурувати код
— Нормальний неймінг, без чогось типу var a
— Якщо є чіткі питання то одразу їх задавати
— тут у коментах порадили не робити більше ніж очікують. Це дійсно гарна порада. Але якщо вам не складно витратити ще трохи часу на покращення, то чому би і ні.

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

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

Колись було завдання, яке складалось із трьох частин: інтерфейсу, реалізації та дрібки тестів. Кандидату видавали інтерфейс (вихідний код) і еталонну реалізацію в вигляді бінарного файлу. Завдання полягало в тому, щоб написати реалізацію — код. Очікувалось, що кандидат буде дописувати test suite та проганяти через нього різні дані, щоб здогадатись, що всередині еталонної реалізації. Але трапилась людина, яка вміла розбирати асемблер, і просто відновила код еталонної реалізації з бінарного файлу. Таку роботу не зарахували.

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

Це добре і корисно, але побачити таке в резюме кандидата — мені б це здалось трохи диким, імхо.
А за статтю дякую, лайк!

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

Можливо краще зазначати, що користувався мовою Х для вирішення завдань Y.

Дякую за чудову статтю. Лайк.

дякую за фідбек !

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

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

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

Но получается, что его отсутствие — это все же минус, так как при равновыполненных в вакууме заданиях получит оффер тот, у кого есть гитигнор.
Тестовое на то и тестовое, что выполняешь только то, что просят и в максимально сжатые сроки. Неявные требования — это как вообще? А если чел назвал желаемую зп 5к, неявно подразумевая 5к в неделю?
Я не буду тратить свое семейное/рабочее время ради причесывания кода до состояния продакшена, иначе я могу упороться и CI/CD прикрутить, раз на то пошло.
Вообще про эти вот логирования и тд: можно разузнать про нюансы этого функционала на прошлых проектах. Со слов сразу будет видно, занимался таким или нет человек

Як тільки в тестовому завданні з‘являється .gitignore, його також починають оцінювати. Можу навіть уявити реакцію: «Фу, кандидат не витратив 5 хв, щоб його причесати, а машинально вкинув дефолтний. Мабуть, не розуміє для чого той файл треба». Така деталізація, як вірно зауважили інші, кінця-краю не має.

Пишу в резюме про ліцей.
На співбесіді в Cossack Labs запитали хто був вчителем інформатики і інтерв’юер знав можливі відповіді.
На співбесіді в ЛУН один з інтерв’юерів випускник ліцею та є спільні знайомі.

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

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