Скільки технічних інтерв'ю було у вас у житті?
За останні п'ять років я побував на 35 технічних інтерв'ю всіх уявних видів та специфік — від казахстанських стартапів із колективної закупівлі м'яса на зиму до німецьких та американських фінтех-сервісів та банків; з ухилами в програмування, делівері та управління; віддалених та в офісі; обмежених та необмежених за часом; стресових та розслаблених, різними мовами.
Це, разом з ~20 співбесідами, які я провів сам як наймач — достатня кількість, щоб стати королем співбесід зробити наступне спостереження (спочатку зовсім неочевидне) і утвердитися в ньому: я переконаний, що багато в чому завдяки такій кількості співбесід, що починає бути схожим на маргінальну звичку я вивчив свій стек на професійному рівні і став конкурентоспроможним фахівцем при тому, що до цього вже працював 10 років у веб-розробці.
Ця стаття адресована програмістам, які знаходяться на початку шляху та ще не вичерпали глибини знань. У ній я хочу розгорнути тезу про колосальну освітню користь тестових завдань та технічних питань, що ставляться на інтерв'ю — і запросити всіх до мого свіжонаписаного телеграм-бота. , де, на мою думку, можна проходити технічне інтерв'ю хоч щодня, доки вони не закінчаться. А щоб вони не закінчилися — також можна поділитися цікавим технічним завданням, питанням чи корисною/веселою ситуацією, випробуваною на співбесіді.
Про бот я розповім детальніше нижче, давайте для початку розберемося, чому так важливо знати і розуміти відповіді на ці технічні питання та завдання, навіть якщо ви вже не перший рік успішно пиляєте проекти на фрілансі.
Чому якість наших фундаментальних знань бажає кращого?
Технічні інтерв'ю, якщо ви ще не стали королем співбесід — серйозний стрес для організму, як і пошук роботи в цілому — будь ви фахівець-початківець, світчер або довго (а за «довго» в наш час зійде і рік) розробник, що пропрацював на одному місці.
На багатьох співбесідах цей стрес має погіршуючий людський фактор. Вашим інтерв'юером може стати не Олена Володимирська, а рядовий програміст-якого-знайшли, від якого складно чекати адекватних завдань та їх оцінки або тимлід-хардкорщик, який чекатиме моменту щоб обрушити на вас всю свою суворість у погляді, запитуючи: Що для тебе agile!?
Одного разу, не давши потрібної, але, як ви розумієте, непередбачуваної відповіді на це запитання я залишився без оффера, чому радий.
Намагаючись уникати цього стресу та зайвих рухів взагалі, ми дистанціюємося не лише від гучного викриття нашого незнання деяких базових особливостей мови, а й від того, щоб це незнання хоч трохи зменшити.
Проблема в тому, що такий клас завдань практично мало де можна отримати.
Будь-який розробник, якому довелося попрацювати на кількох місцях, підтвердить, що фундаментальні чи творчі завдання, що ставляться на інтерв'ю, рідко мають відношення до того, з чим програміст має справу в реальному житті — жодних тобі рекурсій, графів та асинхронних систем керування ліфтами на планеті. негативною гравітацією в іншому рукаві галактики На жаль.
Що стосується мого рідного JavaScript є хороший приклад - якби не з'явився React.JS, 98% JavaScript-програмістів успішно продовжували б жити в блаженному незнанні про те, що таке bind - через 20 з лишком років після його появи - і продовжували б здивуватися , Отримуючи питання про нього на співбесідах, а працювати з ним продовжували б тільки ті, хто винаходить всі ці високоабстрактні бібліотеки, фреймворки та модулі. Сьогодні завдяки реакту це число вдалося скоротити, за відчуттями, до 97%.
Очевидно, бачачи «відірваність від реалій» цих завдань, багато розробників ігнорують їх або шкодують час на занурення в них і продовжують займатися щоденною рутиною, тобто, висловлюючись образно, йти по мінному полю розробки для продакшена не тільки без миношукача, але й не знаючи, що вони — на мінному полі.
Чим загрожує недолік фундаментального знання мови
Відповідь на це питання здається банальною, але чомусь у людській природі — завжди засувати його рішення в дальній кут — і це відіграє сумну роль у житті junior та middle програмістів, подовжуючи їхній шлях до вершин (і глибин) знання мови на пару-трійку років.
Прикладний код з використанням фреймворків та бібліотек, який вони звикли писати щодня, не може вважатися надійним, якщо вони пишуть його без достатнього розуміння різних аспектів його виконання. Хорошою ілюстрацією цього зі світу JavaScript служить доля бібліотеки JQuery, яка колись була двигуном прогресу, а сьогодні, будучи самозамкненою областю знання, відірваною від решти мови, займає своє природне місце на ринку — напівпрофесійні поспіхом написані і працюючі як доведеться скрипти в подарунок до такій же швидкій верстці на бутстрапі від недорогих фрілансерів.
Майбутнє проектів, що розробляються з таким, хай за незнанням, але безвідповідальним підходом, є прозовим і нетривалим: суттєві втрати часу на рівному місці, збої, фінансові та репутаційні втрати і, як наслідок, зниження ентузіазму до продовження співпраці.
З іншого боку, мало що для людини, яка обрала шлях програміста, порівняється із задоволенням від розуміння того, що він робить. Розумінням того, що він, як Барон Мюнхгаузен, гарцує по мінному полю верхи на коні. Чи варто говорити, що пристойному роботодавцю добре видно людей, які безрозсудно гуляють мінним полем і людей, які застигли в нерішучості зробити крок у ситуації, коли можна бігати і стрибати ні про що не замислюючись?
ActualizeBot
Побачивши користь від співбесід, а також розуміючи, що ходити на неодружені співбесіди це не зовсім етично, я подумав, що було б чудово створити бот, де початківець або пересаджується іншою мовою розробник міг би займатися лікнепом, не вдаючись до реальних співбесід у тому обсязі , У якому сталося мені. А згадавши, як програмісти люблять обговорювати та мірятися завданнями, які їм доводилося вирішувати — особливо якщо це було щось нетривіальне — я зрозумів, що все сходиться, відкинув усі сумніви та вуаля.
У роботі на даний момент є 3 простих функції:
- Підписка на ту чи іншу мову / фреймворк для того, щоб отримувати по ньому нові завдання. Ви підписуєтеся і в міру надходження, завдань, отримуєте їх у щоденному розсиланні
- Публікація завдання чи тестового завдання — In my book they say sharing is caring
- Чудовий генератор імен, за допомогою якого ви зможете підібрати оптимальний підпис для тексту завдання, що публікується вами, включаючи словники жіночого роду, не позбавлені фемінітивів
На даний момент на вибір пропонуються такі мови: JavaScript, Java, Python, PHP, MySQL. Вибір дещо обмежений через межі мого розуміння. Сподіваюся за допомогою хабраспівтовариства поповнити цей перелік.
Робот запущений у суто рок-н-рольному форматі, оплата за щось не передбачається.
Перейти в нього можна за посиланням:
Коротко про технічну реалізацію
Цей бот - один з декількох невеликих проектів на яких я доводжу першу публічну версію мого опенсорсного мініфреймворку для розробки роботів з комплексною структурою, любовно іменованого Hobot і доступного NPM для хардкорщиков.
Фреймворк побудований на базі Telegraf.JS та TypeScript, його нуль-нуль-першу версію, оснащену прикладом використання, можна подивитися на і одразу ж спробувати. Незабаром я вивантажу розширену та причесану для людини з боку версію 0.0.2 та присвячую їй (хоботу) окрему статтю. Буду радий, якщо для когось він виявиться настільки ж актуальним, як і для мене.
Отже, на скільки співбесід вам довелося побувати?
Впевнений, у вас є що розповісти!
Джерело: habr.com