×Закрыть

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

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

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 та думати в цілому.

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

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

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

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

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

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

Чомусь так сталося, що найбільше в мене теорію питали на позиціях 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. Усього (ха-ха) 5-10 років тому буквально на кожній співбесіді питали знання патернів. Я з того часу їх майже всі напам’ять знаю та ще й можу реалізувати. Відтак, цього року я не отримав жодного питання по патернам. Ruby-програмістів ще можна зрозуміти — вони, напевне, про них нічого і не знають (у них є патерн MVC та ActiveRecord, і їм того досить). Але відсутність питань з патернів на Java-співбесідах мене дуже здивувала.

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

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

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

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

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


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

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


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

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

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

LinkedIn

Лучшие комментарии пропустить

-Большинство- Много проблем на собеседовании от того что интервьюер не понимает зачем нужен человек, которого собеседуют. Одним из результатом этого является то что интерью превращается в сдачу экзамена в универе. Второй момент который ведет к такому же результату — это не умение проводить интервью (человек банально не знает чего спросить). Это решается, в основном, через введение «обучаемых интервьюеров» вторыми номерами на интервью.
Еще есть ЧСВ, но тут все намного сложнее, и как правило интервьюер с завышеным или ущемленным ЧСВ — это только проявление орг проблем в компании.

Некоторым людям, чтобы улучшить качество интервью и поиска людей, помогает поменять вопрос «Что может кандидат?» на «Как конкретный кандидат может быть полезен для компании/проекта?»

Сразу пролистал в конец, чтобы убедиться в том, что эта "звичайна веб-макака без претензій"© не ведëт свои курсы имени себя самого (канал в телеграмме не считается) по программированию себя самого на успех.

Молодец, не ведëт.

84 комментария

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

Не в обиду топикстартеру, но я не понимаю, как можно хвастаться непониманием структур данных и основ алгоритмики.

В моем понимании, это базовые и необходимые навыки для любого программиста, претендующего на позицию даже джуна. Иначе потом может начаться массовое использование вложенных циклов (где достаточно поменять используемую структуру данных и решать задачу за один проход) или поиск в БД по неиндексируемым полям )-:

По мне, так это понимание в целом имеет большее значение, чем знание SOLID. Возможно, даже именно по этой причине Вам и не задавали вопросы по паттернам и SOLID: «Раз он здесь сыпется, то по паттернам и спрашивать нечего»

Посему глубоко убежден, что спрашивать про структуры данных и основы алгоритмов на собеседованиях обязательно нужно (-:

Не в обиду топикстартеру, но я не понимаю, как можно хвастаться непониманием структур данных и основ алгоритмики.

Дядь, де я цим «хвастався»? Більш того, де я написав, що не знаю алгоритмів та структур? Ще й як знаю )))

Сорян, якщо неправильно зрозумів
Зробив такий висновок через фразу

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

Смешно, когда тебе на интервью задают алгоритмические задачки, а в итоге в конторке говнокодят круд без тестов. Ну, амазон и фб почему такие задают? Да потому что могут. И мурыжат по 4 часа на интервью, потому что могут :) А для себя — по-моему, просто интересно порешать алгоритмические задачи. Может, на этой работе тебе это не пригодится, но никогда не знаешь какие задачи ты будешь решать в будущем. И такие знания, как говорят классики, за плечами не носить.

О, ти ба. Привіт )))

Да потому что могут.

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

И такие знания, как говорят классики, за плечами не носить.

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

Щодо фаангів — можна звичайно нити і скаржитися на їх процеси, але як на мене, якщо є мета туди попасти, то треба "забити на все що ти знаєш"™© і тупо готуватися під їх процеси та їх підходи якими би абсурдними вони не видавалися.

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

Дія 2: Через деякий час цей самий Вася/Петя/Ваня сам в пошуках роботи стикається з таким непрофесійним "технічним інтерв"ю". Все коло замкнулось.

Наслідок: Вася/Петя/Ваня тепер боїться шукати роботу, то розуміє, що логіка "інтерв"юєрів" далека від практики і знайшовши нарешті роботу тримається за неї.

Тепер Вася/Петя/Ваня боїться шукати іншу роботу, бо маховик розкручений...

У кого профіт?
У галер :)

Обговорювали з товаришем цю статтю і дійшли такого несподіваного висновку:
...
У кого профіт?
У галер :)

А кто на галерах? Правильно — аннунаки!
А откуда пришли эти галеры? Правильно — с планеты Нибиру!

Суть мого коменту:
гноблення повертається до гнобителя.

Замкнуте коло.
Що посієш, те й пожнеш...

тепер боїться шукати роботу

та ну фігня якась )))

Я би не сказав що мене «гнобили». На другий або третій або четвертий раз я би проходів ті співбесіди на раз два. Питання в практиці.

Я би не сказав що мене «гнобили». На другий або третій або четвертий раз я би проходів ті співбесіди на раз два. Питання в практиці.

якщо для Вас таке

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

нестрашно, ну тоді ок :)

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

По Рубі інтеврвю часом не з такою конторою як ThreadUp ?

Thread

в рубі немає тредів )))

Богдане, то несправжні, у нас вже нижче була дискусія.

я питав про контору а вони срач про рубі треди хочуть почати

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

Крім того, якщо ви не помітили, то моя перша відповідь була таким собі каламбуром — тому що контори з назвою ThreadUp немає, так само як і тредів в рубі.

Возможно вам задавали этот вопрос в прошлых статьях.
Java, Ruby, Devops... Если по первым двум понятно — вы достигли момента, когда уже не важен язык разработки, то вот Devops, как мне кажется — это шаг в сторону, шажище.
В чем причина того, что вы апплаились(или отвечали на предложения) в разных областях?
Получить опыт прохождения разных собеседований? И что бы вы делали, если бы вам выкатили офер на Devops-a?

И что бы вы делали, если бы вам выкатили офер на Devops-a?

А мені і викатили, я відмовився.

как мне кажется — это шаг в сторону, шажище.

Ну, мені от так не здається.

А ше я на менеджера ходив на співбесіди і навіть на VP of Engineering :)

А ше я на менеджера ходив на співбесіди і навіть на VP of Engineering :)

Получил офер?

Получил офер?

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

А по позиції технічного манагера (там треба було менеджети 4 команди по 5 людей чи шось таке причому їм треба було людину з сильним технічним бекґраундом, тобто оболтуси-гуманітарії не підходять) мене зареджектили бо я не показав достаньої мотивації (читай не дуже сильно хотів працювати), тут знову абізяна сіла за руль і сказала «нафіг-нафіг братішка, нашо тобі той гємор, ти шо не наменеджився ше? ну його в сраку, го ше пару мікросервісів в соляного напишем на golang». Хоча по скілам проходив ок.

Напишу в наступній частині детальніше.

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

Да, мне тоже неоднократно отказывали в позиции тех. лида в виду отсутствия формальной лычки в прошлом. При этом приглашали ахитектом и настойчиво предлагали рассмотреть позицию CTO. Любопытный у нас рынок.

Ну знаєте, СТО в маленькій компанії це як девлід в великій ))) Крім того людей на такі позиції мені здається просто нереально знайти. Треба місяцями просіювати ринок в пошуках хоч якихось релевантних людей з яких 1% буде адекватним а ще 0.1% погодиться працювати. Тому і нас з вами (без формальної лички, наприклад) беруть до уваги.

На солюшн архітекта мене теж були зареджектили, але дали офер на девліда з пропозицією за півроку вийти на архітекта.

Але мене то шось обламало і я не пішов )))

СТО в маленькій компанії це як девлід в великій

81...200 сотрудников, уже, наверное, не маленькая, а так, да. Я, вот, главный инженер в своем пэт-проете 😊.

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

Відмовляли до собєсу чи після?

Бо мене реджектили вже після скрінінгу та після розмови з техдиром/турбоменеджером (читай тех інтерв’ю).

Відмовляли до собєсу чи після?

В одной компании — до, во второй — после успешного тестового и собеса. С одной стороны, я мог недостаточно раскрыть скил выяснения требований, а с другой — могли быть другие кандидаты, которые просили меньше денег 😊.

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

клепать формы, мб. Я хз как дойти к КМП имея желание и время на собеседовании.

І як цю задачу вирішити за допомогою КМП?

алгоритм кадана, но опять хз как такое помнить на собесе

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

А дійти до цього розв’язку просто

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

Знаходження самого підрядка нічим не відрізняється від знаходження його довжини.

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

Тоже один собес напомнило.
В конце была какая то задачка по структурам данных.
Я какуе то херню написал, в итоге оно даже как то работало.
А потом как вышел от них, так сразу как осенило правильное решение.

Я с ними связался, но ответ был что то типа — «спасибо, но паровоз уже ушел....»

Может и хорошо, что ушел. Ты подождал чего приличнее и поехал на нем.

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

Походу на все должности спрашивают плюс минус тоже самое.

статьям нужен механизм лайков
immediately!

А вони колись були! Але потім Макс скасував цю політику, я навіть пам’ятаю був топік чому так.

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

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

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

Интересно, как бы вы проходили интервью в амазон например. Там (да и вообще в любой нормальной компании) все задачи даются с тем замыслом, чтобы кандидат задавал как можно больше вопросов. Таким образом проверяется, способен ли человек докопаться до сути задачи и убедиться, что понял он все правильно. Как часто в реальной жизни вы видите четко поставленную и прописанную задачу? Особенно если уровень чуть выше джуниора.

Интересно, как бы вы проходили интервью в амазон например.

Ніяк не проходив би, ото мені нема шо робити ніж в амазон йти працювати. Матеріали про українські контори. Про те шо робиться в ФААНГах в інтернетах і без мене понаписано, а cracking coding interview теж люди розумніші ніж я писали.

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

І шо? Мені озвучили умови, я повторив їх, почав робити, через 5 хв виявилося що роблю більше ніж треба, але зупинятися вже не хотів а інтерв’юєер був не проти. В результаті задачу я зробив, фідбек отримав, пішов на наступний етап по системному дизайну, там була ще більша дічь, але я і її зміг пройти і далі вже справа за офером була. Problems, officier?

да и вообще в любой нормальной компании

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

кандидат задавал как можно больше вопросов

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

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

а в чем дичь то? Имхо, системный дизайн — это чуть ли не единтсвенное, по чему нужно реально оценивать кандидата.

а в чем дичь то

в інтерв’юері та питаннях які мені задавали.

Имхо, системный дизайн — это чуть ли не единтсвенное, по чему нужно реально оценивать кандидата.

ну от мене оцінили і пустили далі.

в інтерв’юері та питаннях які мені задавали.

интрига!!! можно хоть один пример то?

Не можна, чекайте тиждень :-P

ну вот, кактеперьжить

Ви так кажете ніби у вас там в доліні немає де почитати кулсторі про вайтбордінг собєси.

не особо, тут никто не считает это дичью. Наоборот, в случае фейла все понимают что хреново подготовились
Я лично слышала только 2 недовольных фидбека — один на китайца с паршивым английским, и второй на интервьювера, который на все вопросы отвечал «да, все хорошо, продолжайте пожалуйста», а потом дал плохой фибдек, что мало деталей раскрыто.

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

в фб эту задачу дают на телефонном пре-скриннинге. Кстати, задача на нахождение максимальной последовательности и есть динамическое программирование

фб

Пані, ви шо, мене туди не візьмуть навіть якщо їм хабаря дати.

не ну чо, поготовиться с годик и возьмут

Ну тады пусть они там начинают готовиться а мы посмотрим ))

В мене немає мети там працювати. Хіба задля спортивного інтересу офер отримати, але на то треба дійсно витратити купу часу на підготовку.

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

Я б послухав. Ось вам jRuby и Java — розпишiть де тухла риба (ми ж говоримо про Ruby, як мову, а не iмплементацiю мови).

ми ж говоримо про Ruby, як мову, а не iмплементацiю мови

Ви говоріть про шо хочете, а я говорю про MRI (і інтерв’юер сумніваюсь що знав про JRuby попри того що воно просто десь є і хтось його використовує); крім того, в предметі особливо не розбираюсь.

Ну давайте Ruby MRI. Що саме не так з concurrency в Ruby MRI? (на всяк випадок нагадаю Вам, що «concurrency is not parallelism»)

concurrency is not parallelism

Ну от тут можна і закінчити бо я мав наувазі паралелізм і java.util.concurrent проти того шо є в рубі (а шо там є — я не знаю, бо я веб-макака і клепаю круди). Інтерв’юер мені розказав страшну таємницю про GIL ну і тут в мене народилась думка про тухлу рибу.

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

Я хотiв дiзнатися, що саме «тухла риба» з вашої точки зору і що саме ви хотіли донести на співбесіді. Але ви вже розписали, що мали на увазі інші речі.

Запрошуйте на інтерв’ю, будемо суші готувати. Зі свіжої риби )))

Интересная статья Вова, нравиться стиль в котором ты пишешь! Продолжай в том же духе :)

Что за контора в которой была задача на запись в файл ?

О, братішка, привіт, давно не бачились.

Что за контора в которой была задача на запись в файл ?

ООО «Вектор-М» )))

На мій подив, абсолютно перестали задавати питання про патерни проектування, окрім того випадку, коли мене запитали про MVC.

Просто все поняли, что их только на собесах спрашивают, а пишут как получится :)

-Большинство- Много проблем на собеседовании от того что интервьюер не понимает зачем нужен человек, которого собеседуют. Одним из результатом этого является то что интерью превращается в сдачу экзамена в универе. Второй момент который ведет к такому же результату — это не умение проводить интервью (человек банально не знает чего спросить). Это решается, в основном, через введение «обучаемых интервьюеров» вторыми номерами на интервью.
Еще есть ЧСВ, но тут все намного сложнее, и как правило интервьюер с завышеным или ущемленным ЧСВ — это только проявление орг проблем в компании.

Некоторым людям, чтобы улучшить качество интервью и поиска людей, помогает поменять вопрос «Что может кандидат?» на «Как конкретный кандидат может быть полезен для компании/проекта?»

Много проблем на собеседовании от того что интервьюер не понимает зачем нужен человек, которого собеседуют.

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

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

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

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

це ви так завуальовано кумовство описали?

В чому була проблема додати до експертів-інтерв’юерів менеджерів щоб вони ставили відповідні питання?

це ви так завуальовано кумовство описали?

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

Це скоріше типово для великих контор.

В чому була проблема додати до експертів-інтерв’юерів менеджерів щоб вони ставили відповідні питання?

Та можна додати, але коли потім 3-4 інтерв’юєри кажуть «ні», а 1-2 менеджери кажуть «так» то тому хто хотів найняти конкретну людину дуже важко пояснити усім чому результати співбесіди не важливі і треба все одно наймати.

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

Якось дивно що у вас процес pwned реальні потреби людей.

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

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

індекс в циклі for є іммутабельним (на відміну від якоїсь Java, де з цим немає проблем)

Якраз мутабельність індексу становить проблему. Не дарма в таких мовах, як Ruby, його зробили іммутабельним. У коді на Java я де можна, всюди вживаю константи (final variable), і біда в тому, що індекс циклу там не можна зробити константою.

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

И в чем проблема? В 2018 году если человек использует цикл с индексом, то он понимает что делает. Для других задач есть 100500 форичей по коллекции. А если сильно хочется иимутадельного индекса, то берем ИнтсСтрим.рендж

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

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

Aha, ну, то значить, я не на то відповів, про що йшлося, перепрошую. :)

А потом удивляются, почему так предвзято к тестовым относятся. Да прям 1в1 собеседование вспомнил, когда было техническое интервью по скайпу, потом тестовое. А потом следующий этап в офисе. И вот при личной встрече ни одного малейшего вопроса по тестовому (а я спрашивал за него), и какие-то абстрактные практические задачи на листочке, не имеющие ничего общего с реальностью, которые я успешно зафейлил, потому что так и не смог понять куда вообще интервьюер клонил, и что от меня хотел. Вот и вопрос, как это все соотносится с должностью, на которую претендует кандидат? Да вот никак... А самое смешное, что обычно такие собеседования чаще всего бывают в компаниях, которые и сами не так много предложить могут.

Как показала практика, контора где-то находит тестовое, потом дает кандидату, а потом задает вопросы вообще левые и проект на других технологиях. Профит:)

На що отримую феноменальну відповідь: «Ми пишемо рест ендпоїнти і ганяємо туди-сюди json-чики, але ж про це нецікаво говорити, тому давай вирішувати задачу».

Terrasoft что ли?)

Terrasoft це .NET контора, навіть я то знаю.

Сразу пролистал в конец, чтобы убедиться в том, что эта "звичайна веб-макака без претензій"© не ведëт свои курсы имени себя самого (канал в телеграмме не считается) по программированию себя самого на успех.

Молодец, не ведëт.

Ви шо, я серйозну працю затіяв, почитайте попередні дві статті.

Як називається метод, який фільтрує всі ніли в колекції?

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

— І для цього [тренування пам’яті], звісно, вкрай необхідно заучувати саме якусь дічЪ
— Поки не придумали кращого способу, хай хоч таке буде.

Невже ви сподівалися, що профдеформація, яка змалечку формується використанням хибних методик навчання та оцінки результатів, в подальшому ніде ніяким боком не вилазить? :)

Ага, а потім та натренована пам’ять видає тобі якусь ’дічь’, яка тобі нафіг непотрібна, замість того щоб щось корисне :(
Хто б підказав як ту пам’ять чистити від сміття

Хто б підказав як ту пам’ять чистити від сміття

Найкраще вогнище на дубових дровах ))

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

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