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

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

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

Обговорення виконаних тестових завдань

З минулої частини ві пам'ять пам'ятаєте, що я робив аж два тестові завдання: перше на Devops Engineer, друга — на Ruby Розробників. Розкажу, що ж було далі.

Співбесіда на Ruby Розробників — інтерв'ю юер навіть не подивився на моє тестове, не задавши по ньому жодних запитань, не зробив мені комплімент (я виконав завдання найкраще з усіх минулих кандидатів, принаймні так мені полестила рекрутер). Таке враження, що він про нього й не знав. Це мене трішки засмутило, адже потім мене почали питати теорію і врешті-решт через теорію і зареджектили. Співбесіда на DevOps Engineer — інтерв'ю юер подивився завдання, зробив комплімент (сказавши, що я досить якісно його виконав) і задавши декілька контрольних запитань по рішенню: навіщо тут оцей рядок? якщо змінити умову на вісь таку, в якому файлі і що треба буде замінити? чому тут використано таке рішення? і так далі. Як мені передала рекрутер, деякі кандидати робили задачі не самі та не змогли відповісти на такі питання. Тому тут я впорався без проблем.

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

Задачі на співбесідах

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

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

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

У якості інструментів, які застосовуються для розв'язків язання, найкраще підійде редактор коду + Repl + можливість колаборації. Зі всіх варіантів, що є на ринку, мені найбільше подобається CoderPad . Створюється кімната, туди ви підключаєтеся та інтерв'ю юери, ві можете разом редагувати та запускати код і бачіті результати його виконання. Дуже зручно. Якщо немає грошей на кодерпад, тоді в бій іде repl.it та шарінг екрану — в принципі ті саме, тільки без можливості колаборації.

Мав я співбесіду в одну компанію на позицію Java Developer . Компанія робить щось типу CRM-ів та пише купу інтеграцій. Я зв'язку язався з технічним спеціалістом по Zoom і він каже: «Почнемо з алгоритмічної задачі». Я відповідаю: «Ок, завдання я зроблю, але в мене одне питання: у вас в роботі знадобляться ці знання, вам потрібно вирішувати схожі завдання?». На що отримую феноменальну відповідь: «Ми пишемо рест ендпоїнти і ганяємо туди-сюди json-чікі, але ж про це нецікаво говорити, тому давай вирішувати завдання». Тобто сам інтерв'ю юер зізнався у своїй некомпетентності. Не знаю, як хто, а я вже з цього моменту зрозумів, що мені там буде ловити нічого. Проте зі спортивного інтересу розмова продовжилася.

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

Я повторивши умову задачі інтерв'ю юеру, щоб переконатися, чи правильно я її зрозумів, на що отримав ствердну відповідь і почав працювати. Через 5 хвилин з'єднання ясувалося, що умову я зрозумів неправильно, і потрібно було знайті не сам підрядок, а його довжину (це було простіше). Але я сказав: «Ну раз почали, то давайте вже вирішувати завдання із зірочкою, а не просто так». Інтерв'ю юер був трішки збентежений, тому що в нього там десь були на готові тести саме для його умови, але я вирішив, що задню давати не буду і спробую зробити, як є. Я живити, скільки в мене є часу (близько 40 хвилин) і почав кодити. Зауважу, що, хоча я знав, що будуть давати задачі, я спеціально не готувався.

Отож, я відразу написавши тести і почав шаманити з i, j та k індексами :) Циклами в циклах і так далі. Десь через 15-20 хв вже мав наполовину робоче рішення, але не проходили едж-кейсі, які надав інтерв'ю юер. Ще 20 хв пішло на едж-кейсі, і в результаті, здається, я таки правильно зробив цю задачу. Інтерв'ю юер ніби задовільнився рішенням і далі живити мене про структури даних. Виявилося, що для вирішення тієї задачі, яку він планував даті спочатку, можна було б застосувати хешсети чи щось таке, і він ніби очікував такого рішення, але я все зламав.

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

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

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

Ще мав співбесіду на позицію Ruby Розробників. Після знайомства і дефолтних питань мені дали завдання написати each_slice метод. Для тих, хто не знає, — це така штука, яка ділить масив на підмасиви заданого розміру і виконує для шкірного підмасиву блок, який ми передали, або повертає ітератор. Ну я сів писати, і тут у мене увімкнувся тупінг. Проблема в тому, що на Ruby я досить довго та успішно займався тільки веб-макакінгом і, як еталонний вайтішник, не знав деяких базових конструкцій мови. А саме не знав, що індекс в циклі for є іммутабельним (на відміну від якоїсь Java, де з цим немає проблем).

Сам метод я написавши більш-менш швидко, але він не працював, і я ніяк не міг зрозуміти чому. Тут я почав трошки панікувати, стер всі і написавши заново, але знову мій код не працював. «Не склалося», — подумав я і сказавши моїм співбесідникам: «Хлопці, знаєте, я вісь добре вмію веб-макакінг і роблю проекти, альо з вашими дурними завданнями в мене щось не виходить. Хоча я розумію, що то проста завдання і людина з 10 роками досвіду просто зобов'язана її швидко вирішити. Так що давайте я не буду вас більше тримати і ми розійдемось». Хлопці погодилися, і на тому розійшлися.

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

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

Ще я мав співбесіду на позицію Java Developer. Цього разу вона проходила трішки в інакшому форматі. Мі зв'язку язалися за Zoom, і інтерв'ю юєр каже: «Давай свій e-mail, я тобі надішлю завдання, почитаєш, скажеш, чи все зрозуміло. У тобі буде дві години, я буду на базі юті та не буду дивитися, що ти там робиш (екран не шаримо). Через дві години виходимо на зв'язок, шариш екран і дивимося, що ти там зробив. Користуватися можна чим завгодно». Я почитавши умову задачі, промовивши її ще раз з інтерв'ю юером, відключив відео (тому що кодування відео їсть CPU) та ставши на базі ють. Відкрив IDE та розпочав роботу.

Завдання було пов'язаність язане з I/O — треба було зробити API для запису текстових даних у файл на диску, так, щоб все було thread safe і швидко, і ще написати юніт-тести, які бі то все перевіряли. Давно не працював з concurrency та I/O, тому довелось швиденько пробігтися по доках і згадати, що там до чого. У результаті я сів і написавши рішення в лоб, перевірив, що воно thread safe і так далі. На все про все у мене пішло десь півтори години. Я пінганув мого інтерв'ю юера, сказавши, що я вже типом готовий. Залишилося тільки всілякі дрібниці доробити, може, будемо дивитися? На що він відповів: «Давай ще півгодинки посидь, дороби все, що не доробив». Ок, я сів і довів до ладу всі дрібнички, дописавши джава-доки, ще раз прочитавши все, що міг про I/O, і подумавши, які недоліки є в мого рішення.

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

Мені співбесіда та процес дуже сподобалися. Я зміг показати, що не тільки fizz buzz умію вирішувати, а ще й щось розумію в архітектурах. Інтерв'ю юер переконався, що перед ним сидить не джун, а спеціаліст, який щось відстрілює. Думаю, що то було найкраще технічне інтерв'ю з усіх, що я мав. Думаю, ви вже здогадалися, що інтерв'ю юер був не з наших :) Додам тільки, що я його успішно пройшов, а потім ще два етапи та отримав офер. Але то вже інша історія.

Чим було хороше це завдання?

Наближеність до реальної роботи, до того, чим займаються в тій конторі.
Обмеження за часом.
Відсутність спостереження.
Можливість користуватися чим завгодно, а не перевірка пам'яті.
Створення підґрунтя для подальшої розмови.
Завдання, як на мене, непогано перевіряло вміння кандидата кодити, користуватися пошуком та IDE та думати в цілому.

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

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

Типові помилки та недоліки таких завдань

Завдання ніяк не стосується реальної роботи. Це мене найбільше трафляє. Дають вирішувати алгоритми, хоча насправді круди клепають. Давайте релевантну завдання, зроблю вам круд! Навіщо вам людина, яка вміє рядки в підрядках шукати?
Організаційно — відсутній нормальний інструмент для розв'язків язання. Один раз мені показали код google doc, один раз я шарив екран в repl.it . Один раз був кодерпад.
Завдання не створює контексту для подальшої розмови — це наслідок з першого пункту. Навіщо давати завдання, якщо потім не будемо про неї говорити?
Не всі люди можуть впоратися із завданням під наглядом. Відповідно, хороший кандидат відсіюється.

Теоретичні питання

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

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

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

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

Потім були питання про конкретні методи, а саме: «Як називається метод, який фільтрує всі ніли в колекції?». Тут я вже увімкнув контролю і сказавши: «Якщо ви перевіряєте мою пам'ять на ці методи, то я не зможу вам відповісти про ті, чого не використовував нещодавно. Я пишу на багатьох мовах та платформах, я не пам пам'ятаю всі методи SDK». Інтерв'ю юера це не задовільнило, і наступним питанням було щось типу: «Що таке Перечіслімого? Назвіть, які там є методи та хто його екстендить». «Дядя, ти шо, не зрозумівши?», — подумав я про себе, але вголос сказав: «Не знаю точно, думаю, що якісь методи типу map/reduce/slice і т. д.». Це йому теж не підійшло, судячи з усього.

Потім він задавши мені дефолтне питання з MVC і куди пхати логіку. Я відповів, що в моделі, а якщо в моделі не влазити, то в якісь інакші класі. Виявилося, що правильною відповіддю були так звані Service Objects (невже ця зараза і сюди дісталась). Я щось буркнув у відповідь, типу, ну можна і так назвати, але мені це не подобається.

Далі він мені задати якісь питання ще про SQL, на які я вже зміг грамотно відповісти, потім живити про RSpec, який я не дуже використовував, та й усе. За Rails (а в них якраз Rails був) жодного питання я не отримав. Про мій попередній досвід теж не було жодного запитання.

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

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

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

Отож, мені відмовили, тому що я не знаю основ мови. Гаразд, їдемо далі.

Ще одна співбесіда на Ruby Розробників, вже двоє інтерв'ю юерів. Добре, що хоч розмовляють один російською, інший — українською, тому не доводилося ламати собі мозок. На диво, починається та сама історія: що таке модулі, що таке блоки. Я тоді ще не прочитавши книгу, тому знову плавав у відповідях. Далі подали напругу про віді асоціацій у Rails-моделях. «Нарешті хоч щось», — подумав я і назвавши три віді з пам'яті. Інтерв'ю юерам це не сподобалося (бо їх є більше — я всі не пам запам'ятав), як і ті, що я сказавши: «За іншими лізу в доку». Далі вони мені дали ту задачу на each_slice, про яку я написав вище. Після цього, як ви вже знаєте, я запропонував закруглятися. Один з інтерв'ю юерів сказавши: «У мене тоді останнє питання, чи ви колись писали Rack middleware?». Я не знаю, що він хотів почути. Я сказав, що не писав, але знаю, що воно таке (типу фільтрів у Java, middleware в Laravel або якомусь Express), та можу швидко розібратися за потреби. І знову це їх не влаштувало, тому наша співбесіда завершилася.

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

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

Третє інтерв'ю на Ruby Розробників. Тімлід знову десь у відпустці, тому зі мною говорив просто девелопер з команди. Ті самі питання про модулі та блоки, але я вже підготувався, тому одразу даю коректні відповіді. Інтерв'ю юер іде далі і питає мене, що таке Proc, але і тут я даю правильну відповідь :) Тоді він вирішує, що годину застосовувати важку артилерію і задає питання: «Назвіть порядок пошуку методу для виклику, якщо в нас є клас, він екстендиться від іншого, а ще є модуль і ще щось там». Тут я вже не знав 100% правильної відповіді, тому спробував якось нафантазувати та методом дедукції з'єднання з'ясувати, який же там порядок. Вгадав половину.

Далі було ще одне питання на зразок цього: яким чином працює require. У цих хлопців вже було не Rails, а Grape, тому, вочевидь, для них це було актуально. Я сказавши, що «сходу не знаю, але, напевне, працює воно отак». Здається, не вгадав. Далі ще були якісь питання-пазлери типу: шматочок коду, що тут буде. Потім трішки поговорили про ActiveRecord — я майже на все правильно відповів, крім валідацій, бо ніколи їх не писав, зате з іншим мав хороший досвід.

Потім він мене починає питати про concurrency (тут мені вже смішно стало). Я не знаю точно, яка модель concurrency в Ruby — так йому і сказав. І додав, що я знаю про примітиви синхронізації, атомітки, м'яка ютекси і т. д. Намагався якось натякнути, що ваше конкаренсі — тухла риба порівняно з Java і зараз я вам розкажу про моделі пам'яті, різницю між volatile та synchronized і буду цитувати Шипильова, альо інтерв'ю юеру ті не зайшло. Крім того, він зізнався, що в проекті вони (та не може бути!) concurrency не використовують. Навіщо тоді питати?

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

Отож, який висновок можна зробити з цих трьох співбесід? Між ними минуло по декілька днів. За цей час я не зробив нового проекту, не набув нових знань або досвіду, не ставши кращим програмістом. Я яким був, таким і залишився! Знання теорії на практиці не додало мені абсолютно нічого (вибачте за каламбур). Просто замість того, щоб заздалегідь прочитати Cracking Ruby Interview я вирішив наступити на всі граблі сам. Думаю, ще два-три таких інтерв'ю, і моя «сеньорність» не буде викликати ні в кого ніяких сумнівів. Не зважаючи на те, що насправді я якою макакою був, такою і залишився :)

Ще кілька історій, і з чистою теорією будемо зав'язувати.

Мав також інтерв'ю на Fullstack Java Developer. Мене попередили, що воно буде складатися з двох частин: бекенд та фронтенд. Останній я знаю не дуже добре і сказавши про це рекрутеру, альо смороду вирішили йти далі. Ну що ж, зв'язку язуємося з хлопцями, починаємо з Java.

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

Перейшли до фронту. На тому кінці був чисто фронтендер. Він почав мене питати про минулий досвід, а потім перейшов до пазлерів, типу що буде, якщо undefined порівняти з null, як працюють області видимості. Ще кілька дефолтних питань із JS і знову перейшов на WAT-питання. Я одразу сказав: «Слухайте, я з вашими WAT ніколи в житті не мав справи. Якщо дуже треба буде, то погуглю, але я думаю, що ці знання нема куди застосовувати, окрім як посміятися на мітапчиках». Інтерв'ю юер зі мною погодився, альо все одне продовжив задавати пазл-питання. Урешті-решт він порекомендував мені прочитати книгу «JavaScript: The Good Parts», після чого я ще мав розмову з менеджером і на тому розійшлись.

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

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

І ще я мав співбесіду на DevOps Engineer , де я робив тестове завдання. Перейшли ми до розмови, і тут інтерв'ю юер питає: «А що таке маска підмережі?». Тут я і посипався :) Сказавши, що це кількість чисел, які значать адресу підмережі, а всі інші циферки — то діапазон. Але що з тим треба робити, вже не пам пам'ятаю, бо давно не налаштовував мереж. Добре, що інтерв'ю юер виявився адекватним, підвів мене до правильної відповіді і не зважав на ті, що на таке просте запитання я не зміг одразу дати вірну відповідь. Далі співбесіда вже проходила без теоретичних питань.

На мій подив, абсолютно перестали задавати питання про патерни проектування, окрім того випадку, коли мені подали напругу про MVC. Усього (ха-ха) 5-10 років тому буквально на кожній співбесіді живили знання патернів. Я з того часу їх майже всі напам'ять ять знаю та ще й можу реалізувати. Відтак, цього року я не отримав жодного питання по патернам. Ruby-програмістів ще можна зрозуміти — вони, напевне, про них нічого і не знають (у них є патерн MVC та ActiveRecord, і їм того досить). Але відсутність питань з патернів на Java-співбесідах мене дуже здивувала.

Про SOLID подали напругу, здається, два рази: один раз на Ruby-позицію, іншого разу — на Java. Про DRY не мали :)

Які можна зробити з цього висновки?

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

Тому, яким би безглуздим це все не було, але раджу вам:

Перед співбесідами прочитати типові набори питань з вашої мови/платформи та добряче їх завчити. Знаті неоднозначні питання, відповіді на які просто так не виведеш. Моє улюблене: який є недолік використання проксі-AOP порівняно з AspectJ у Spring :) Це потрібно, щоб легко проходити співбесіди з інтерв'ю юерами, у яких немає фантазії на нормальні запитання.
Повирішувати типові алгоритмічні задачі на LeetCode та подібних ресурсах, щоб бути до них готуємо.

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

Не забувайте долучатися до мого каналу у Telegram , заходьте почитати мій блог , і до наступної статті!

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

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

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

Опубліковано: 03/12/18 @ 08:52
Розділ Блоги

SEO Блог