Продовжуємо говорити про технічні співбесіди. Цього разу ще більше суб’єктивного досвіду, мінімум порад, а також трішки про тестові задачі та теоретичні питання. Поїхали.
Disclaimer: автор — не турбодевелопер, а звичайна веб-макака без претензій. Тому наведені задачі та рішення можуть викликати у вас посмішку, баттхерт та бажання вказати автору на його некомпетентність. З нетерпінням чекаю вас у коментах! :)
Обговорення виконаних тестових завдань
З минулої частиниви пам’ятаєте, що я робив аж два тестові завдання: перше на Devops Engineer, друге — на Ruby Developer. Розкажу, що ж було далі.
Співбесіда на Ruby Developer — інтерв’юер навіть не подивився на моє тестове, не задав по ньому жодних запитань, не зробив мені комплімент (я виконав завдання найкраще з усіх минулих кандидатів, принаймні так мені полестила рекрутер). Таке враження, що він про нього й не знав. Це мене трішки засмутило, адже потім мене почали питати теорію і врешті-решт через теорію і зареджектили.
Співбесіда на DevOps Engineer — інтерв’юер подивився завдання, зробив комплімент (сказав, що я досить якісно його виконав) і задав декілька контрольних запитань по рішенню: навіщо тут оцей рядок? якщо змінити умову на ось таку, в якому файлі і що треба буде замінити? чому тут використано таке рішення? і так далі. Як мені передала рекрутер, деякі кандидати робили задачі не самі та не змогли відповісти на такі питання. Тому тут я впорався без проблем.
У першому випадку я не запитав у мого візаві, чи дивився він узагалі моє виконане тестове і що він з цього приводу думає. А треба було! Якщо у вас виникне така ситуація, то обов’язково вкажіть на це інтерв’юеру та викажіть своє незадоволення.
Задачі на співбесідах
Продовжимо тему тестових завдань з попередньої частини та розглянемо задачі на кодинг на співбесідах.
Задачі на співбесідах можуть бути декількох типів: реалізувати якийсь алгоритм, написати рішення на псевдокоді, щось відрефакторити і так далі. Наші інженери найбільше люблять алгоритмічні задачі.
Багато людей, у тому числі і я, вважають, що такі задачі показують лише те, як кандидат може вирішувати саме такі задачі і зовсім не показують, як він впорається з реальними робочими завданнями, які, як правило, є більш високорівневими. Чому їх тоді досі дають? Я думаю, причина проста: інтерв’юери просто не здатні придумати щось краще. А раз не можемо придумати нічого краще — давайте візьмемо старі добрі інверсії рядків, сортування і так далі.
У якості інструментів, які застосовуються для розв’язання, найкраще підійде редактор коду + Repl + можливість колаборації. Зі всіх варіантів, що є на ринку, мені найбільше подобається CoderPad. Створюється кімната, туди підключаєтеся ви та інтерв’юери, ви можете разом редагувати та запускати код і бачити результати його виконання. Дуже зручно. Якщо немає грошей на кодерпад, тоді в бій іде repl.itта шаринг екрану — в принципі те саме, тільки без можливості колаборації.
Мав я співбесіду в одну компанію на позицію Java Developer. Компанія робить щось типу CRM-ів та пише купу інтеграцій. Я зв’язався з технічним спеціалістом по Zoom і він каже: «Почнемо з алгоритмічної задачі». Я відповідаю: «Ок, задачу я зроблю, але в мене одне питання: у вас в роботі знадобляться ці знання, вам потрібно вирішувати схожі завдання?». На що отримую феноменальну відповідь: «Ми пишемо рест ендпоїнти і ганяємо туди-сюди json-чики, але ж про це нецікаво говорити,тому давай вирішувати задачу». Тобто сам інтерв’юер зізнався у своїй некомпетентності. Не знаю, як хто, а я вже з цього моменту зрозумів, що мені там ловити буде нічого. Проте зі спортивного інтересу розмова продовжилася.
Ми відкрили кодерпад і перейшли до задачі, умову якої мені було озвучено усно: «Знайти максимально довгу послідовність з унікальних символів у рядку». Після того інтерв’юер сказав, що «можна було б дати задачу на динамічне програмування, але обмежимось більш простим варіантом». Я хочу подивитися на людину, яка буде давати на співбесіді задачу на динамічне програмування, серйозно.
Я повторив умову задачі інтерв’юеру, щоб переконатися, чи правильно я її зрозумів, на що отримав ствердну відповідь і почав працювати. Через 5 хвилин з’ясувалося, що умову я зрозумів неправильно, і потрібно було знайти не сам підрядок, а його довжину (це було простіше). Але я сказав: «Ну раз почали, то давайте вже вирішувати задачу із зірочкою, а не просто так». Інтерв’юер був трішки збентежений, тому що в нього там десь були на готові тести саме для його умови, але я вирішив, що задню давати не буду і спробую зробити, як є. Я запитав, скільки в мене є часу (близько 40 хвилин) і почав кодити. Зауважу, що, хоча я знав, що будуть давати задачі, спеціально я не готувався.
Отож, я відразу написав тести і почав шаманити з i, j та k індексами :) Циклами в циклах і так далі. Десь через
15-20 хв уже мав наполовину робоче рішення, але не проходили едж-кейси, які надав інтерв’юер. Ще 20 хв пішло на едж-кейси, і в результаті, здається, я таки правильно зробив цю задачу. Інтерв’юер ніби задовільнився рішенням і далі запитав мене про структури даних. Виявилося, що для вирішення тієї задачі, яку він планував дати спочатку, можна було б застосувати хешсети чи щось таке, і він ніби очікував такого рішення, але я все зламав.Далі зовсім небагато поговорили про їхній проект (форми, круди). І тут він каже: «Після цього буде інтерв’ю про системний дизайн. Я не бачу змісту його проводити, тому що ми тут такими задачами не займаємося і знання такі нам не потрібні, але порядок є порядок, тому наступний етап такий». Ну ви зрозуміли — дві(!) співбесіди проводяться, щоб з’ясувати чи кандидат вміє робити речі, які не застосовуються в повсякденних задачах. Тут я трішки дозволив собі висловитися щодо безглуздості таких співбесід. Інтерв’юер зі мною погодився, але знову увімкнув делегацію відповідальності і сказав: «Не я вирішую, якими мають бути порядки, тому робимо те, що робимо». Наостанок додам, що друге інтерв’ю на системний дизайн я теж пройшов, і воно було приблизно таким самим беззмістовним :)
Яку помилку зробив інтерв’юер — він не зафіксував умову задачі в тексті. Коли я проводив такі співбесіди сам, то я просто копіпастив умову задачі у редактор коду, тому в кандидата не лишалося жодних запитань.
Яку помилку зробив я — відразу кинувся писати код, не уточнивши три рази, чи правильно я зрозумів умову. Якщо вам будуть давати такі задачі на співбесідах, то відразу відключайтеся від чату і знайдіть собі більш цікаві справиуточніть декілька разів, чи правильно ви зрозуміли умову, напишіть у редакторі тест і отримайте в інтерв’юера підтвердження, що все так.
Ще мав співбесіду на позицію Ruby Developer.Після знайомства і дефолтних питань мені дали завдання написати 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 Developer, було якраз те, де треба було виконувати тестове завдання, але, як виявилося, нікому воно не було цікавим. Тімлід, який мав зі мною розмовляти, не прийшов (у пробці стояв чи щось таке), тому мені видали іншого. Після знайомства інтерв’юер каже: «У мене є правило — я всі співбесіди проводжу англійською мовою, тому переходимо на англійську». І тут мої вуха скручуються у графенову нанотрубку, бо мій інтерв’юер має потужний акцент. Це мене трошки вибило з колії, але я якось зміг налаштуватися.
Далі пішли питання: що таке модуль, що таке блок, що таке yield, — і я почав фейлити. Замість визначення «як за книгою» я почав теревенити: «Ну, я не знаю точного визначення, але, напевне, це отака штука, я її застосовував отак». Інтерв’юер був незадоволений, я це почав відчувати і тоді подумав, що, напевне, все, приїхали.
Потім були питання про конкретні методи, а саме: «Як називається метод, який фільтрує всі ніли в колекції?». Тут я вже увімкнув троля і сказав: «Якщо ви перевіряєте мою пам’ять на ці методи, то я не зможу вам відповісти про те, чого не використовував нещодавно. Я пишу на багатьох мовах та платформах, я не пам’ятаю всі методи SDK». Інтерв’юера це не задовільнило, і наступним питанням було щось типу: «Що таке Enumerable? Назвіть, які там є методи та хто його екстендить». «Дядя, ти шо, не поняв?», — подумав я про себе, але вслух сказав: «Не знаю точно, думаю, що якісь методи типу map/reduce/slice і т. д.». Це йому теж не підійшло, судячи з усього.
Потім він задав мені дефолтне питання з MVC і куди пхати логіку. Я відповів, що в моделі, а якщо в моделі не влазить, то в якісь інакші класи. Виявилося, що правильною відповіддю були так звані Service Objects (невже ця зараза і сюди дісталась). Я щось буркнув у відповідь, типу, ну можна і так назвати, але мені це не подобається.
Далі він мені задав якісь питання ще про SQL, на які я вже грамотно зміг відповісти, потім запитав про RSpec, який я не дуже використовував, та й усе. По Rails (а в них якраз Rails був) жодного питання я не отримав. Про мій попередній досвід теж не було жодного запитання.
Далі він запитав, що я думаю про daily стендапи. Тут я вже вирішив не давати соціально очікуваних відповідей, а сказав що це марнування часу та практикується в командах, у яких менеджер не може створити прозорість та зручність репортингу. А ще додав, що Scrum — це фігня на пісному маслі, і ніхто в нас нормально по скраму не працює, а всі тільки роблять вигляд. Думаю, що тут я ще нахапав собі мінусиків.
Далі він запропонував задавати вже питань йому, і я, на свою голову, запитав про процес, архітектуру і т. д. Те, що я почув, мені не сподобалося, тому що для якихось рішень вони не використовували потрібні технології, а робили свої велосипеди. І я хотів дати йому зрозуміти, що я не просто програміст, а вмію трішки більше, але все було марно, і невдовзі тімлід сказав, що йому пора на мітинг, і пішов.
Наступного дня написала рекрутер і повідомила, що мені відмовили. «І слава Богу», — подумав я, але все-таки трошки підгоріло. Ще в мене склалося враження, що інтерв’юер з самого початку був упереджений щодо мене, не знаю. До речі, це була та сама контора, яка тягнула місяць від першого контакту до технічної співбесіди.
Отож, мені відмовили, тому що я не знаю основ мови. Гаразд, їдемо далі.
Ще одна співбесіда на Ruby Developer,уже двоє інтерв’юерів. Добре, що хоч розмовляють один російською, інший — українською, тому не доводилося ламати собі мозок. На диво, починається та сама історія: що таке модулі, що таке блоки. Я тоді ще не прочитав книгу, тому знову плавав у відповідях. Далі запитали про види асоціацій у Rails-моделях. «Нарешті хоч щось», — подумав я і назвав три види з пам’яті. Інтерв’юерам це не сподобалося (бо їх є більше — я всі не пам’ятав), як і те, що я сказав: «За іншими лізу в доку». Далі вони мені дали ту задачу на each_slice, про яку я написав вище. Після цього, як ви вже знаєте, я запропонував закруглятися. Один з інтерв’юерів сказав: «У мене тоді останнє питання, чи ви колись писали Rack middleware?». Я не знаю, що він хотів почути. Я сказав, що не писав, але знаю, що воно таке (типу фільтрів у Java, middleware в Laravel або якомусь Express), та можу швидко розібратися за потреби. І знову це їх не влаштувало, тому наша співбесіда завершилась.
І знову, нікого не цікавив ні мій досвід, ні мої знання в побудові рішень чи в суміжних галузях. Я не засуджую тих хлопців. Можливо, їм дійсно треба програмісти, які ось уже знають, як треба писати ті міддлвари, але думаю, що насправді вони просто не вміють проводити співбесіди.
Після двох провалів я зрозумів, що так не має бути і треба прочитати теорію. Раз її питають, то треба знати. Ніхто не хоче вірити просто так, що я хороший програміст, і давати нормальні задачі. Тому я сів, почитав підручник, і...
Третє інтерв’ю на Ruby Developer.Тімлід знову десь у відпустці, тому зі мною говорив просто девелопер з команди. Ті самі питання про модулі та блоки, але я вже підготувався, тому одразу даю коректні відповіді. Інтерв’юер іде далі і питає мене, що таке 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. Усього (ха-ха)
Про SOLID запитали, здається, два рази: один раз на Ruby-позицію, іншого разу — на Java. Про DRY не питали :)
Які можна зробити з цього висновки?
- Теорію досі люблять питати, особливо наші з вами співвітчизники.
- Знання теорії не гарантує знання практики, тому до теорії люблять долучати задачки.
- Ні знання теорії, ні здатність вирішити задачку не гарантує, що людина вміє програмувати.
- Незнання теорії та фейл з вирішенням задачки не значить, що перед вами поганий розробник.
Тому, яким би безглуздим це все не було, але раджу вам:
- Перед співбесідами прочитати типові набори питань з вашої мови/платформи та добряче їх завчити. Знати неоднозначні питання, відповіді на які просто так не виведеш. Моє улюблене: який є недолік використання проксі-AOP порівняно з AspectJ у Spring :) Це потрібно, щоб легко проходити співбесіди з інтерв’юерами, у яких немає фантазії на нормальні запитання.
- Повирішувати типові алгоритмічні задачки на LeetCodeта подібних ресурсах, щоб бути до них готовим.
Наразі все, знову багато тексту, сподіваюсь, що вам було цікаво. У наступній частині будемо говорити про питання щодо минулого досвіду, питання на системний дизайн, питання на «подумати» та інші речі, що вже більше схожі на правильну технічну співбесіду.
Не забувайте долучатися до мого каналу у Telegram, заходьте почитати мій блог, і до наступної статті!
Попередні частини:
Senior у пошуках роботи. Як я пройшов 20 співбесід з HR і що про це думаю
Senior у пошуках роботи. Як я пройшов 15 технічних співбесід і що про це думаю