×

Senior у пошуках роботи. Як я пройшов 15 технічних співбесід і що про це думаю

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

На мій подив, попередня стаття про співбесіди з рекрутерами та HR викликала неочікуваний інтерес: усього більш, ніж 100 000 переглядів по всіх джерелах. Я отримав купу позитивних відгуків у приватні повідомлення: мені написали колишні колеги, котрих я останній раз бачив 5 років тому; героїні деяких історій зі статті; хлопець, якому я кілька тижнів тому продавав системник через OLX; барабанщик, з яким ми минулого року грали метал у гаражі, та, як це не дивно, дуже багато рекрутерів, які поцікавилися моєю думкою щодо того чи іншого. 250 людей додалися до мене у LinkedIn — не знаю, правда, навіщо :)

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

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

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

Рекомендую прочитати перед пошуками роботи.

Кілька думок щодо рекрутингу

Я в жодному разі не даю порад рекрутерам, як їм робити їхню роботу. Я не професійний рекрутер і не знаю, як працює їхня внутрішня кухня. Коли мені доводилося шукати собі персонал (не проводити технічні співбесіди, а саме шукати і наймати — повний цикл), то це були junior-позиції, відповідно, в мене не було особливих проблем.

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

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

Також рекрутинг — це продаж вакансії кандидату. Чим швидше ви це зрозумієте та почнете прокачувати свої навички продажів — тим краще. Ой, я ж казав, що не буду давати порад :)

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

Також я переконаний, що під час пошуку роботи кандидатам треба братися за всі вакансії, які більш-менш підходять, тому що насправді з’ясувати, про що вакансія, можна лише в розмові з технічними спеціалістами. У своїх пошуках я майже не зважав на те, що написано у вакансії, і з’ясовував усі потрібні деталі вже на етапі технічної співбесіди. Вважаю, що цей спосіб є найбільш правильним, тому що так ви збільшуєте свої шанси знайти крутий проект, який може ховатися за стандартним описом. Мій досвід тільки однозначно підтверджує цю тезу. Жодного разу у вакансії не було написано конкретно, що треба робити. Лише загальні фрази типу «кодити код, тестити тести, деплоїти деплоймент».

Винайматися у компанію чи на проект

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

Як обирати собі тайтл

Я позиціював себе як кандидат рівня Senior Software Engineer та вище — Team/Tech Lead, Principal Engineer, Software Architect, Project Manager, People/Group Manager і так далі. Саме це «вище» малось на увазі під «+» у Senior+.

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

Отож, пані та панове, перейдемо до технічних співбесід.

Етап другий. Технічні співбесіди

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

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

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

Тестові завдання

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

«Виконайте проект з нуля (можливо, використовуючи конкретну технологію), та викладіть його на GitHub» — як на мене, найгірший варіант. Ви можете багато часу витратити на бойлерплейт, на інфраструктуру навколо рішення, а інтерв’юера будуть цікавити, як правило, декілька дрібних деталей, які закладені в умовах задачі. Добре, коли у вас є під рукою, припустимо, шаблони проектів і ви можете за 5 хвилин підняти сервер і швидко закодити, що там потрібно. Інакше доведеться якось те все згадувати і вручну піднімати. Також погано, коли в завданні є вимога використати зовнішні залежності, наприклад, не-embedded базу даних.

Позиція DevOps Engineer. Мені надіслали завдання зробити Vagrant конфігурацію з декількома інстансами, серед яких мали бути веб-сервери зі статикою, балансер для них і Jenkins. Усе це треба було встановлювати за допомогою Chef. А тепер уявімо: я ніколи не користувався Vagrant, Chef та не налаштовував ті веб-сервери, яких вимагали у тестовому завданні. Я приблизно розбираюся в тому, як воно все працює, мав справу зі схожими інструментами, але ніколи не використовував саме ці конкретні.

Мені довелося за одну ніч сісти, встановити це все, наступити на купу грабель, але врешті-решт виконати завдання. Основна складність полягала в тому, що в мене старий MacBook Pro 15-го року, який фізично не встигав рестартувати ті контейнери, і в тому, що я не мав досвіду з Vagrant.

На суть задачі — розібратися, як там що встановлювати, — у мене пішло може з півгодини. Решту часу (7 з гаком годин) я витратив на встановлення всього інструментарію, рестарти-ребути, тикання по конфігах в намаганнях зрозуміти, чому воно не працює, і так далі. Те саме на Docker Compose я би зробив, напевне, за годину, може, навіть менше. Чи можна було б у задачі не обмежувати кандидата інструментами? На мою думку, можна.

Чи було це завдання корисним для мене? Однозначно так! Я тепер буду знати, що від Vagrant та Chef треба триматися якомога далі :)

Витрачено часу — 8 годин.

На жаль, більше історій про цей тип завдань у мене немає, тому що тестових давали в цілому не так багато :(

«Ось посилання на сайт з тестами, пройдіть їх» — дуже класний варіант. У чому суть? Є SaaS, які дозволяють сконфігурувати набір практичних та теоретичних питань та для вирішення надають REPL та редактор коду прямо там в них і можливість запустити верифікаційні тести. Далі ви просто йдете по завданнях, фіксите або пишете код, запускаєте його і дивитися результати. Самі тести від вас приховані, ви бачите тільки результат (passed/failed) та короткий опис тесту, який одночасно є підказкою. Чому це варіант мені подобається найбільше? Тому що є однозначний критерій якості виконання завдання і кандидат точно знає, скільки балів він набрав, чи його рішення працюють і так далі. Мені особисто навіть цікаво було проходити ті завдання. Єдине, що я не бачу змісту в теоретичних питаннях типу «що буде, якщо виконати цей код» — вони легко гугляться.

Позиція Ruby Software Engineer (пам’ятаєте історію про місяць очікування? Це звідти). Мені присилають лінку на сайт TestDome, звісно, кастомний тест. Я клікаю, потрапляю до власне тестів. Мені дається 2,5 години на проходження всього набору, по 5-20 хвилин на кожне питання. Насправді мені дуже сподобалося, я вже давно не проходив такі штуки. Особливо мені сподобався TDD-підхід: закодив, запустив, подивився, що в тебе впало, кодиш далі. Пройшов із великим задоволенням.

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

Я впорався із завданням на 93/100 балів усього за годинку з гачком. Шкода, що це мені зовсім не знадобилося на подальших етапах. TDD допомагає у вирішенні, не потрібно витрачати час на підйом інфраструктури, репл прямо у браузері — коротше кажучи, дуже круто. Заради такого можна було і місяць почекати — адже я отримав свою порцію допаміну (я круто все зробив!) та адреналіну (таймер працює, часу все менше!).

Витрачено часу — 1 година.

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

«Ось репозиторій, там завдання, надішліть Pull Request з рішенням» — такий варіант мені не траплявся, але його використовували мої колеги. Мені він не дуже подобається, тому що можна подивитися, як виконували те саме завдання інші люди (якщо вони були).

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

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

На мій превеликий жаль, ніхто більше не давав тестових завдань, тому статистика у мене зовсім невелика. Хіба що можу згадати ті тестові, які я робив багато років тому. Вони всі були першого типу — потрібно було написати проект. Цікаво, що я їх робив у ті часи, коли GitHub не був таким популярним і треба було пересилати вирішення у zip-архіві поштою :)

Мої рекомендації щодо тестових завдань:

  1. Не подобається — не робіть. Якщо завдання, припустимо, заверстати цілий сайт або написати круд — ну його в баню. Завдання мають бути короткими і сфокусованими на створенні контексту для подальшого обговорення, а не просто тестом на те, як ви вмієте скафолдинг робити.
  2. Якщо завдання першого типу — додайте до репозиторію readme, де в деталях опишіть інструкцію для запуску, чому ви зробили таке рішення, які ви бачите в ньому недоліки, що вам сподобалося, що не сподобалося, як би ви вирішили завдання, якби у вас було більше часу, і так далі. Не знаю, чи це реально допомагає, але як інтерв’юер я б однозначно звернув увагу на це.
  3. Пишіть нормально, але не варто витрачати купу часу на вилизування деталей. Як на мене, достатньо просто перелічити в readme все, що ви б реалізували, якби це був бойовий код.
  4. Обов’язково подумайте, які питання до вас можуть виникнути щодо реалізації, та почитайте додатково документацію про те API, яке ви використовували. Припустимо, я давно не працював з concurrency. Одна з задач, яку я вирішував на наступних етапах, була пов’язана с concurrency. Я вже давно не практикувався у цьому, тому після вирішення я швиденько пробігся по всім пов’язаним темам, пригадав усі типові запитання і був готовий до розмови.

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

Технічна співбесіда. Інтро

Почнімо з того, що зараз уже досить рідко запрошують до офісу на технічні співбесіди. В офіс мене запросили тільки декілька разів — для інтерв’ю на позиції Solution Architect, Tech Lead та одного разу — на менеджерську позицію. Усі інші співбесіди проходили по Skype, Zoom, Hangouts. Як і на попередній співбесіді з рекрутером, поради ті самі — хороша камера, хороша гарнітура. До цього обов’язково додамо умову шарити екран. Тому переконайтеся, що ви не маєте відкритих робочих проектів (якщо це важливо) та інших персональних речей, які не потрібно показувати людям з того боку. Майте під рукою чистий браузер без табів та REPL для кодингу про всяк випадок (IDE або відкритий сайт).

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

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

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

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

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

Перед співбесідою обов’язково ще раз пройдіться по вакансії, зауважте вимоги, які пред’являються до кандидата, та підготуйте промову. Я проходив співбесіди на Tech Lead, DevOps/SRE, Ruby/Java Software Engineer і у кожному випадку говорив різні речі, які б, на мою думку, зацікавили інтерв’юерів найбільше. Намагайтеся не заглиблюватися в деталі, а надати ту інформацію, яка створить вектор для подальшої дискусії. Не варто детально говорити про те, що ви робили 5 років тому (якщо це не було щось екстраординарне).

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

А тепер несподіваний факт.

Ваше резюме ніхто не читає

Чесно кажучи, це виявилося для мене великим відкриттям. Ну добре, рекрутери не читають профіль у LinkedIn, тому що він може бути не up-to-date, HR має навичку проглядати CV і просто виділяти для себе основне. Але от люди, які проводять співбесіду, вже точно не будуть читати ваше резюме. Жодного, підкреслю, жодного разу я не відчув, що люди хоча б одним оком глянули на те, що я там детально порозписував. Я підозрюю, що, як правило, вони дізнавалися про те, що потрібно проводити технічну співбесіду, попереднього дня, і вирішували почитати CV за 5 хвилин до дзвінка, а там вже буде як буде.

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

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

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

Ви нікому не потрібні

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

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

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

Ви не будете розмовляти зі своїм майбутнім босом чи тімлідом

Це є наслідком з попереднього. На моє глибоке переконання, ви повинні говорити з тим, кому ви потім будете підпорядковуватися, формально чи неформально. В усіх організаціях є якась ієрархія, хоч це Scrum-команда, хоч кривавий ентерпрайз. Усюди є людина, яка буде приглядати за вами (як мінімум на старті).

На жаль, ви нічого не можете з цим зробити. Єгор Бугаєнко у своєму дописі «Why I Don’t Talk to Google Recruiters» дуже добре описав цю ситуацію. Якщо ви будете вимагати розмови зі своїм майбутнім босом — ви просто не підете ні на яке інтерв’ю.

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

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

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

Долучайтеся до мого каналу у Телеграмі, і до наступної статті!

Попередня частина:

Senior у пошуках роботи. Як я пройшов 20 співбесід з HR і що про це думаю

Наступні частини:

Senior у пошуках роботи. Про задачі на технічних співбесідах і теоретичні питання

Senior у пошуках роботи. Про питання на системний дизайн та фінальні співбесіди

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

Схожі статті




71 коментар

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

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

Проходил недавно собеседование. Работу не ищу, just for fun, полюбопытствовать что нынче модно спрашивать. Было немного обидно что я такой вот офигенный, ожидал вопросов про транзакции в распределенных сервисах и паттерны интеграции, а меня про какие-то хеш-коды спрашивают. Скуукааа :-( После часа потраченного времени, ответил собеседующему что в вашей позиции не заинтересован, а на собеседование согласился только, чтобы рекрутер от меня отстала. Через 2 дня рекрутер написала что эта компания больше не будет рассматривать мою кандидатуру. Наверное в черном списке :-)))

Вова ты не понял суть задания с репником, вёрстку тестами не проверишь.

Позиція DevOps Engineer. Мені надіслали завдання зробити Vagrant конфігурацію з декількома інстансами, серед яких мали бути веб-сервери зі статикою, балансер для них і Jenkins. Усе це треба було встановлювати за допомогою Chef. А тепер уявімо: я ніколи не користувався Vagrant, Chef та не налаштовував ті веб-сервери, яких вимагали у тестовому завданні.

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

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

В результаті ми маємо зоопарк фреймворків навіть в межах однієї компанії (30+ девелоперів).

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

Для себе маю такий висновок:
там де людина дійсно потрібна на проект, там питання на технічному інтерв"ю відповідають заявленій тематиці в описі вакансії.

Якщо ж інтерв«юєр виходить за рамки вимог по вакансії, то можливо він просто не хоче собі конкурента :)

Стосовно кодінг тестів:
у 90% коли я казав «Ви знаєте я тільки за, але зараз дуже завантажений, то кодінг тест відміняли зі словами — це не принципово :)»

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

Это тот случай когда спрос рождает предложение :)

Гарна стаття, та схоже не в той день опублікована

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

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

Комп после майнинга?

Комп после майнинга?

Після джуніор джава девелопера. В мене ще дві штуки є, core i7-4770 та 3770, можу продати:
www.olx.ua/...​70k-12gb-ram-IDA5gF8.html
www.olx.ua/...​4770-8gb-ram-IDA5hjU.html

Той шо продав то був феном х6. Чесно кажучи велика вдача що він комусь знадобився. Віддав здається за 5500 грн.

а навіщо тобі стільки системників ?

У нас була власна аутсорс контора: 2 мобільщика, 3 бекендера, три фронтендера, два дизайнера та один РМ, 4 системники core i7 з 16 гігабайтами пам’яті, монітори делл 2408, 2410 та 2412, мак міні для айосників та дизайнерів, а ще мишки, клавіатури, коврики, бутилі з-під води, столи, стільці, термопот, якщик вівсяного печення а також три десятки сортів чаю та кави і це все розташовувалося в офісі на 40 кв. м. Єдине, що мене непокоїло, це відсутність місця. Ніщо в світі не є більш безпораднім та безвідповідальним, ніж джуни набиті в опенспейсі як кільки в банці. Але я знав, що рано чи пізно нам доведеться розширити штат. Коли ти починаєш аутсорсити, то вже не можеш просто так зупинитися.

Обязатєльно бахнєм. Но потом.

можу дати дружню пораду по стаціонарам?

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

По объявлению на первом не хватает видеокарты? Или ещё что-то отсутствует? Моей домашней машине уже 10 лет, так что даже это — обновление :)

По объявлению на первом не хватает видеокарты?

там інтегроване відео

Непогана стаття. В цілому все вірно відображає.
Але мене вразило оце.

Позиція DevOps Engineer. Мені надіслали завдання зробити Vagrant конфігурацію з декількома інстансами, серед яких мали бути веб-сервери зі статикою, балансер для них і Jenkins. Усе це треба було встановлювати за допомогою Chef. А тепер уявімо: я ніколи не користувався Vagrant, Chef та не налаштовував ті веб-сервери, яких вимагали у тестовому завданні. Я приблизно розбираюся в тому, як воно все працює, мав справу зі схожими інструментами, але ніколи не використовував саме ці конкретні.

Розумієш, я тепер вкурив , чого мене футболили . Бо я чесно казав, що не знаю добре всіх тих тулзів, але розберуся — але мені швиденько відфутболювали -"НАМ ПОТРІБЕН СПЕЦІАЛІСТ З ДОВГИМ ДОСВІДОМ РОБОТИ !"..і все. Тобто-таки треба дурити . А втім — чи треба ?

Тобто-таки треба дурити

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

То мені на кожній позиції девопса таке казали. Брехати — так, розкусять за мить, я сам, коли працював з таким зустрічався на співбесідах, як течлід, коли людей співбесідував і сам того не люблю..але за ніч розібратися з усім тим Das Zoo Palast — то або треба й справді супермозка мати, або хз...

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

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

не знаю добре всіх тих тулзів, але розберуся

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

А я як роблю ? 8-) Так само. Хіба тільки ще курси довбаю. 8-)

Трішки детальніше про це написав у себе в Telegram-каналі.

Линкедин аккаунт прокачал.
Телегу прокачал.
В следующей статье будет инстаграмчик? :)

В следующей статье будет инстаграмчик? :)

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

Алгоритмы и структуры данных?

Solution Architecture, RFP та Fluent English!

Эта статья и предыдущая, похоже потверждает факт, что для получения высоких результатов просмотров, один из важных факторов — это наличие цифры в названии. Действительно встречал её лично на хабре и ain, казалось, что она заполонила Интернет)

Клікбейт ніхто не скасовував, зараз часи такі.

10 правил як пройти інтерв’ю на ... ©

До речі можете придумати назву для наступної частини. Мені самому не дуже подобаются клікбейт назви, насправді я хотів то все назвати «Цікаві досліди», але цю назву зареджектили (((

Типа Подеревянский в суд подаст?

Подеревянский

Подерв’янський

Ні, просто тут так не прийнято.

Senior без Vagrant’а — странно (данная статья потеряла ценность после такого высказывания), а MacBook 15-го года весьма шустрый несмотря на свой год выпуска

Ваше резюме ніхто не читає

 — вам попадались странные вакансии. очень часто интервьюверы проходятся по резюме как план интервью

MacBook 15-го года весьма шустрый несмотря на свой год выпуска

ні

Senior без Vagrant’а — странно

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

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

радий що вам попадались норм пацани, в мене якось не склалось, крім того

У цій частині буде більше мого суб’єктивного досвіду та філософії
Senior без Vagrant’а — странно (данная статья потеряла ценность после такого высказывания)

Это какой-то стандарт, принятый международной ассоциацией сениоров?

Senior Devops Engineer який не користувався Vagrant, то дійсно якось дивно)

І добре шо не користувався! Чур мене чур ще раз його ставити собі.

ок, чим будете піднімати тестовий енвайромент, якщо це не докер, а вм?

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

На своем аккаунте aws или там gcloud

нє пацан ти не поняв, «ЧИМ БУДЕШ ПІДНІМАТИ ТЕСТОВИЙ ЕНВ ЯКЩО ЦЕ НЕ ДОКЕР А ВМ І АВС В ТЕБЕ НЕМА І ГКЦ ТЕЖ НЕМА І ВЗАГАЛІ ПІДКЛЮЧЕННЯ ДО ІНТЕРНЕТУ НЕМА???!!!НЕ СІНЬОР ШОЛЄ?»

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

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

>>

«пили на вагрант плюс шеф и только так»,

а на собеседованиях бывает, что кто-то придумал одно тестовое и они его годами гоняют не меняя)

зачем сейчас Vagrant если есть докер?

Ще один не-сеньор в треді. Шановний, ваш коментар втратив цінність після даного висловлювання. Вам місце на шхуні юнгою.

чьорт! пойду работодателю сообщу что мне переплачивают

Іване, повірте, окрім докера існує великий всесвіт засобів віртуалізації

да пускай, но зачем вагрант вместо докера?

Вздыхает--- ну вам не нужно — и ладно.
А мне нужно.
Хотите кораблик ?

Это тоже самое что сказать «зачем сейчас автомобиль, если есть пароход?» Это абсолютно разные тулзы для разных задач, но видимо автор статьи не осилил вагрант, так же как не осилил ответить на мой вопрос в комментариях. Не любой енвайромент можно развернуть в докере, а потому писать такую чушь, что нужно подальше держаться от vagrant и chef может только синьйор-балабол. Хотя можно конечно списать на то, что автор не является devops-инженер, а есть разработчик.

автор статьи не осилил вагрант

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

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

Вагрант не мій, срав так срав, шановний сіньйор-копрофіл, більш питань нема, думка зрозуміла.

Не любой енвайромент можно развернуть в докере

Например?

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

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

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

Ще раз. Мені дали тестове завдання. Я його зробив з використанням потрібного інструментарію. Це доводить мій скіл (відносно) швидко розбиратися у всіх тих інструментах. Я пройшов інтерв’ю, отримав офер і пішов собі далі. Ринок оцінив мої знання, а це найкраща оцінка (поза офіціною сертифікацією).

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

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

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

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

то як мінімум н професійно

Я там в попередній серії написав рекрутеру «скала фу мерзость не люблю».

Просто мені подобаються гіперболи та й все.

Вот я запускал FreeBSD под Virtualbox на линуксовом хозяине.
Да, через vagrant как управлялку.
А коллега аналогично запускал Ubuntu под MacOS.
Докер по определению на такое не способен.

Хорошо. А я запускаю Windows и MacOS с гуями под Ubuntu. Без вагранта, напрямую из VirtualBox. Значит ли это что что всем нужно так делать? Я думаю нет, у меня просто бывают такие задачи. Но бывают и такие когда докера хватает, причем чаще чем задачи для которых нужна полноценная вм.

Ну, допустим, докер не работает на Виндоус -_-

Та работает. Некоторые фичи не очень в зависимости от версии ОС хоста, но смертельного ничего не заметил.

Некоторые это дебаг и форвард портов. Бывает критично

Pro 2015 может быть и на i5-5257U. И даже i7-4770HQ почти в 2 раза хуже 8700к.

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