Data Science fwdays — спікери зі Stanford, ДонорUA, Grammarly, Neuromation, Київ, 7 вересня

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

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

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

Попередній досвід

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

Як на мене, питання досить нерелевантне, тому що, як правило, інтерв’юер буде очікувати саме технічних проблем, тоді як у нашій роботі більшість складнощів пов’язані якраз із людьми. Навряд його задовільнить відповідь: «Ми вперлися в обмеження системи. Щоб порефакторити, треба було 3 місяці проводити купу мітингів з іншими відділами, щоб переконати їх, що ця робота повинна бути виконана саме зараз» (це, напевне, більше про менеджерський досвід). Або «у нас хаотичний замовник, і ми 4 рази переписували якусь частину системи. Вже на третій раз мені було дуже складно себе мотивувати».

Натомість усі чомусь будуть очікувати прохолодних історій про те, як ви перемелювали петабайти даних на кластерах, які коштують тисячу баксів за годину роботи. Як ви ковбасили 300kk req/sec на чистому Netty. Як ви застосовували consistent hash ring для шардування терабайтів даних і подібні байки.

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

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

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

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

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

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

Ще мав співбесіду в лідера ринку на техліда. У них на проекті є AWS. І в мене у CV теж написано, що я щось тямлю в тому. Ну і вони давай мене питати: а перелічіть усі сервіси, які ви використовували, а чому оце не взяли, а чому оце взяли, а які проблеми були, а що таке ось ця штука і так далі. Наостанок програм-менеджер(!) у мене запитав: «Чим відрізняються лямбди, написані на Java та інших мовах?» :)

Потім запитують щодо проектів. Щось у стилі: «Розкажіть про ваш останній проект, як там все було, що ви там зробили корисного, які були складнощі».

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

Щодо проектів під NDA, я особисто таких не мав. Але мені здається, що можна розказати деталі технічної реалізації, не вдаючись у значущі деталі бізнесу. У будь-якому випадку я би не відмахувався NDA-лейблом від таких запитань. Це навряд чи додасть вам плюсиків.

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

Задачі на проектування і системний дизайн

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

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

Співбесіда на Java-помідора у дрібну аутстаф-контору. Їхній інженер розповідає, що в них мікросервіси на Spring Boot та Go, щось там якось крутиться, задає мені кілька дефолтних питань. Далі ми переходимо до фронтенд-частини, потім повертаємося знову до бекенд. І тут інженер у мене питає: «А от як би ти вирішив задачу, яка у нас стоїть? Мікросервіси і все це». Я не довго думав і відповів: «Взяв би Spring Boot і не парився», тобто віддзеркалив їхнє рішення :) Смішно було.

У ту контору мене не взяли, бо знань з фронтенду було мало.

Співбесіда на Java-техліда у лідера ринку. РМ-ом проекту виявився мій колега з попередньої роботи, який мене добре знав та був готовий брати мене фактично без співбесіди, але треба ж було дотриматися усіх формальностей. Отож, розмовляло зі мною аж троє людей (чомусь лідери ринку дуже люблять побільше людей напхати у переговорку). Одразу перейшли до запитань щодо розподілених систем, Spring Cloud Netflix, тестування АРІ.

Основним запитанням, як і на багатьох інших співбесідах, була організація RPC, як забезпечити уникнення проблем з версіонуванням API, як це тестувати, документувати та перевіряти дотримання контрактів. Тут я трішки дав маху, тому що був не в курсі трендового зараз gRPC, який, наскільки мені зрозуміло, всі ці задачі з успіхом вирішує. Довелося відбріхуватися рестом та JSON-Schema. Далі були запитання про побудову стійких систем і ще чогось такого. Трішки зачепили AWS, але я не знав потрібного їм сервісу.

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

Тут мені очікувано дали офер, але менше грошей, ніж я хотів, тому відмовився.

Ще я мав реально хардкорну співбесіду на позицію SRE в аутстаф-контору. По скайпу зі мною розмовляли двоє людей — технар та менеджер. Продукт у них досить складний, хайлоадний та супер-секурний — його не можна в клауди, все бер-метал і т. д. Судячи з усього, найбільші вимоги у них були до мережевих файлових систем та сховищ даних, от по ним мене і почали питати. Шкода, що я практично ні в зуб ногою ні про такі системи (типу Ceph), ні про внутрішні деталі їхньої реалізації, ні про складнощі, які виникають при експлуатації таких систем. Завжди мав S3 і не парився, а тут виявилося, що ще є люди, які самі те все менеджать.

Отже, мене почали питати про те, як шардувати дані. Які є варіанти, які є протоколи для того, щоб це все правильно робити (щоб не було brain split наприклад), які є варіанти генерації ключів для шардів. Тут я мав би розповісти про consistent ring hash, про який я щось колись читав, але майже не пам’ятав, що воно таке. Хлопці все намагалися мене наштовхнути на це рішення, але я занадто далеко від цих штук (веб-макака ж!), щоб на ходу придумати рішення. Майже 40 хвилин ми вирішували задачу, яким чином побудувати надійне сховище даних, і крутилися навколо схем хешування. Ще трішки торкнулися баз даних і базових команд юнікса, на тому й розійшлися. Вердикт мені дали очевидний: «Далі не пускати».

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

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

Зв’язуємося по Zoom. Інтерв’юер довго вивчає моє CV (очевидно, що мітинги-мітинги, і не було часу підготуватися), і в нас відбувається такий діалог:

— Скільки у вас років досвіду з Java?
— 11 + ще з інституту пару років.
...
— Скільки у вас років досвіду роботи тімлідом?
— Подивіться в CV, там є абсолютно точні терміни.
— Скільки у вас років досвіду роботи тімлідом?
— ??? Я ж кажу — в CV все є.
— Скільки у вас років досвіду роботи тімлідом?
— Вам що, формочку якусь треба заповнювати, що ви такі питання задаєте?
— Ні, я просто хочу для себе розібратися, який у вас був досвід.
— Окей, якщо не хочете в CV дивитися, то 2 роки.

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

Продовжуємо:
— Розкажіть мені щось про Spring.
— Що конкретно розказати?
— Ну, щось.
— ???
— Розкажіть, навіщо потрібен Spring Boot.
...
— Розкажіть мені щось про JVM.
— Що?
— Щось.
— Ви знаєте, я не Шипильов, щоб вам тут про JVM розповідати. Давайте, може, якесь конкретне питання?
...
— А тепер, м-м-м, у нас буде питання про дизайн. Треба задизайнити систему. Ось є фейсбук, гугл, ютуб, твіттер, ще щось високонавантажене. Виберіть собі щось та задизайніть.
— Що саме?
— Ну, щось зі списку, що вам подобається.

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

Відповідаю:
— Окей, я вибираю Hacker News. Це високонавантажений проект, він крутиться на одному сервері та зроблений на LAMP. От його і будемо робити )))

Додаю:
— Ви знаєте, я бачу, що з якоїсь причини у нас розмова дуже складно йде. Чи то я не можу вас зрозуміти, але мені якось складно без конкретних питань давати відповіді, тому що мені незрозуміло, що ви хочете з’ясувати. Сформулюйте задачу нормально, і будемо вирішувати те, що вам потрібно, а не те, що я собі придумаю. Давайте задачу з вашої роботи.

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

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

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

Ще була співбесіда у аутсорс-контору на Java-помідора. Там хлопців теж сильно цікавило, яким чином побудувати RPC, тестувати контракти і оце все. Відповідь я вже мав — gRPC :) Зараз усюди мікросервіс через мікросервіс, тому ці речі точно необхідно знати.

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

Інтерв’ю в highload стартап на Java-техліда. Там, де мені треба було на співбесіді за півтори години написати робоче рішення. Отож, я мав розмову з головним архітектором, і він почав мене питати по задачі. Як зробити, щоб тут було більше даних? А от якщо в нас буде даних забагато і буде ООМ, то що робити? А як можна попередити таку ситуацію? У цілому всі питання були спрямовані на те, щоб розібратися, як кандидат буде вирішувати більш складні задачі, які виникають при значному збільшенні обсягу даних.

Цю співбесіду я успішно пройшов і отримав офер.

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

Менеджерські та фінальні співбесіди

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

  • Кому я буду репортити?
  • Хто відповідальний за мій розвиток (якщо він є)?
  • Яка використовується методологія розробки?
  • Як організована комунікація? Які є канали, як вони використовуються? Що більше, що менше (пошта, Slack, Skype)?
  • Скільки часу витрачається на мітинги та іншу комунікацію?
  • Яким чином організовується документація на проекті?
  • Чи мають інженери доступ до продакшн-систем?
  • Як часто система деплоїться?
  • Як робиться DevOps?
  • Як організований контроль якості?
  • Скільки людей у команді? Хто є на боці замовника?
  • Які плани по проекту? Коли продакшн, коли саппорт? Які взагалі перспективи?
  • Які найбільші складнощі на проекті прямо зараз?
  • Чи бувають овертайми?
  • Яким чином ухвалюють ключові технічні рішення?
  • Які є можливості зростання на проекті?
  • Хто стейкхолдери, яка структура власності (якщо це стартап або продукт)?

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

Якихось цікавих співбесід на цьому етапі в мене не було. Лише зачеплю тему переговорів.

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

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

Ще мав офер на позицію Java-техліда. Там мені запропонували на $300 менше, мотивуючи це тим, що в них по грейду більше не можна. Але якщо ось я пройду внутрішні курси на архітекта і стану архітектом, то дадуть більше. Я теж відмовився — ще чого. Невідомо, чи буде та позиція через півроку, невідомо, чи дадуть більше грошей і т. д.

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

Бонусні співбесіди

Ще я мав співбесіди у три різні компанії на позиції відповідно Solution Architect, Group Manager та VP of Engineering. Тут вже питання та підхід трішки інші, ніж на девелоперів та тімлідів. Розповім і про це, щоб розбавити нашу одноманітність технічних співбесід.

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

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

Щодо того, хто такий архітект, є крута стаття від Єгора Бугаєнко Are You an Architect?. Я з його концепціями повністю погоджуюсь.

В принципі я це все знав, але вирішив спробувати.

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

І ось ці всі люди мене по черзі починають питати, який у мене досвід в архітектурі, які документи я готував, як працювати з функціональними-нефункціональними вимогами, як робив планування навантаження та ресурсів (capacity planning), чи я це все якось захищав. Власне технічних питань не було: наприклад, як організувати read-heavy рішення, коли можна, а коли не можна NoSQL різних сортів та видів і т. д. Лише запитали про AWS, які сервіси я знаю.

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

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

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

У вердикті, крім того, що я нічого не знаю, написали: «He has very Technology Centric thinking». Думаю, що можна з натяжкою вважати це таким собі компліментом :)

До речі, щодо вердикту — я запросив у HR фідбек і рекомендації, і, на диво, мені їх надали досить розгорнуто. Щоправда, я зрозумів, що точно не хочу працювати Solution Architect :)

Друга співбесіда в мене була вже в іншу компанію на позицію Group Manager пари-трійки команд (загалом 20-25 голів). Їм потрібен більше менеджер, ніж технар. Враховуючи, що на аналогічній позиції з такою самою кількістю людей я вже відбатрачив у минулому кілька років, то мене розглянули. Сам я вирішив піти туди зі спортивного інтересу: дадуть офер — буду думати. Але великого бажання працювати менеджером у мене не було.

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

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

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

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

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

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

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

Третя співбесіда у мене була в компанію на 50 людей на позицію VP of Engineering. На мене вийшли через лінкедін, і я погодився піти поговорити. Хто знає, що там. Може, дійсно цікаво.

Отож, спочатку мене чекав скрінинг по скайпу с HR. Були дефолтні питання про те, про се. Потім домовилися про ще один скрінинг вже з їхнім техдиром. Знову поговорили про те, про се. Їх дуже цікавив CI/CD ланцюжок чомусь — тут я трішки щось розумію, тому мене покликали поговорити вже очно.

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

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

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

Fin

На цьому все! За результатами проходження співбесід у 16 різних компаній за два місяці (жовтень та листопад) я провів 35 сесій, не враховуючи деяких співбесід з рекрутерами, які нічим не закінчились. Я витратив приблизно 40 годин чистого часу + 10 годин на вирішення тестових завдань. Отримав 3,5 офери (менше ніж 25% конверсії, що, як на мене, малувато). Від усіх відмовився з тих чи інших причин та залишився там, звідки й почав. Але вже краще розумію, що є на ринку, як скоротити час на проходження усіх кіл співбесід, як себе ефективніше поводити та як готуватися. Також мені залишилася купа своїх думок щодо цього всього, якими я з вами і поділився.

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

Як основний висновок цієї подорожі співбесідами я би хотів зазначити таке: хорошому інженеру з солідним досвідом немає ніякого сенсу працювати в українських аутсорс/аутстаф/offshore devcentre посередниках. Ви будете далі від кастомера, отримуватимете менше грошей, витрачатимете більше часу на комунікацію та політику, матимете менше перспектив. Шукайте віддалену роботу у стартапах та продуктових компаніях — там і гроші будуть серйозніші, і можливостей може бути більше. В ідеалі знайти віддалену роботу напряму від замовника із зарплатою інженера з Silicon Valley :)

Якщо вам сподобалась моя писанина, то не забувайте долучитися до мого Telegram-каналу.

Всім хорошої роботи та продуктивних співбесід у новому році!


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

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

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

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

LinkedIn

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

Ми шукаємо таке питання, на яке б ти не відповів

Украинский аутсорс — бессмысленный и беспощадный :)

Вы проделали большую работу и статьи годные. Понравились все)

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

131 комментарий

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

«Завжди мав S3 і не парився, а тут виявилося, що ще є люди, які самі те все менеджать.»
є, і таких багато
але менеджити це все в нормальних компаніях — окрема позиція, часто на декілька спеціалістів))

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

незрозуміло, чому у вас таке ставлення до цих чуваків
ніби все вказує на те, шо там має бути весело)

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

якшо все це (запитання) не прості понти

спасибо за статью! вспомнилось как я один раз специально запорол собеседование, чтоб его закончить, потому что мне уже надоело. сказал честно что на собес я согласился just for fun, и ваш оффер меня не интересует. после этого интервьювер закончил разговор, и наверное я у них в черном списке :-))))

сказал честно что на собес я согласился just for fun, и ваш оффер меня не интересует

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

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

У меня так было. Сначала ставишь джина на поиск, потом проходишь собеседования, потом идёшь поработать, потом надеешься на новый проект. И все j 4 fun 😅

Хто відповідальний за мій розвиток (якщо він є)?

як хтось інший може відповідати за ваш розвиток?

Мається наувазі людина яка приймає рішення щодо мого підвищення. В великих конторах це може бути якийсь лінійний менеджер, в дрібних — СЕО.

якщо він є

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

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

ну насправді там усе одно може бути чогось «смачненького» як то отримання якогось сертифікату або там практичний тренінг онсайт десь у більш менш цікавих місцях так що тут такоє ))

В стартапах і всяких продуктах вже більш цікаво, можна вирости до якогось менеджерка або архітекта.

ну насправді там якраз навпаки цілком можуть бути «пусті дульки» коли це «вирости» означає лише «зміну назви кабінету» та ще може +500 до з.п. (і то у дуже вдалому випадку) більш ніяк це «вирости» не вдасться «монетизувати».

ЗЫ: ну от тебе на співбесідах питали про «якогось менеджерка або архітекта» а воно оказується ні того ні другого насправді у тому досвіді нема (тут узагальнення) а так одна назва лише ))

Отримав 3,5 офери (менше ніж 25% конверсії, що, як на мене, малувато).

Цікаво, а яка була конверсія у кожному типі компаній (аутсорс, аутстаф, продукт, стартап)?

1.5 в аутсорс
2 в аутстаф (обидва рази це були стартапи але через наші прокладки)

окремо
1 в продукт, там де готові були офер робити але в них найм заморозили. Я його не додав у загальний залік.

Також додам що я сам роботу не шукав. Просто відповідав на всі пропозиції підряд. Якби я аплаївся в цікаві мені контори то там напевне були б одні стартапи.

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

— Скільки у вас років досвіду роботи тімлідом?
— ??? Я ж кажу — в CV все є.
— Ви знаєте, я не Шипильов, щоб вам тут про JVM розповідати. Давайте, може, якесь конкретне питання?

После таких ответов любой нормальный интервьюер должен был закончить собеседование.

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

Кстати, если без шуток и пафоса, то очень часто бывает как со стороны кандидата так и со стороны интервьюера:
ты просто понимаешь что найма не будет через 10-15 мин собеседования, но прирывать интревью как-то не красиво, а если не прирвать то рискуем получить разговор по типу того что вы описали в статье.

ты просто понимаешь что найма не будет через 10-15 мин собеседования

Було в мене таке не раз (з точки зору інтерв’юера), з точки зору кандидата я сам обривав, але таке один раз тільки було з рубі пацанами.

а если не прирвать

Прервать.

разговор по типу того что вы описали в статье

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

И что в этом некрасивого? Секономили друг-другу время. У меня было собеседование 3 минуты — я отказался, ну очень глупые хрюши у них были.
Так же и я собеседовал за 5 мин и отправлял людей с тем, что они не подходят на вакансию.

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

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

Следовательно, так как вы продолжили интервью, вы сами себя нормальным кандидатом не считаете (что есть правда).

Біг дата аналітик в треді, всі в хадуп кластер!

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

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

А може то було тіпа стресс інтервью ))

Стресс-интервью этот чувак с успехом провалил бы.

мы же ж не знаем критериев прохождения ))

В данном случае нужно просто попросить пересказать свое резюме по памяти :)

в американской компании так и будет )) причём с акцентом! ))

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

скільки конкретно років я працював з тією чи іншою технологією.

це доречі дуже популярне запитання воно навіть у вигляді анкет є ))

І беззмістовне. Ось у мене приблизно 5 років досвіду на Delphi і по 2 роки на Scala і Python. Тільки на Delphi програмував давно і вже не пам’ятаю синтаксису, а Scala і Python використовую останні роки і відчуваю себе з ними впевнено.

Это, к сожалению, украинские реалии (на безрыбье и рак рыба). В нормальную зарубежную компанию вам с такими гонором путь закрыт.

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

нормальную зарубежную компанию

и готов спорить многие воспринимают «зарубежное» как страну эльфов и самые правильные и вообще в мире и конечно же ж без мудаков! ))

более приземленная реальность же ж сильно ближе к тому классическому анекдоту где «одного не пойму зачем вам в цирке программист?» (к) (тм)

В нормальную зарубежную компанию

ЗЫ: где-то вроде уже писал таки статистически «в нормальную зарубежную компанию» стоит очередь в 60-70 человек на место правда есть один маленький нюанс это не факт что среди них вообще есть те кто реально могут таки программировать... ))

В нормальную зарубежную компанию вам с такими гонором путь закрыт.

Ага, саме тому один з оферів на техліда я отримав в іноземну контору (через українську аутстаф прокладку), але ось незадача, всі співбесіди (4 штуки) в мене були виключно з людьми тієї компанії (vp of eng, chief arch, tech lead, vp of eng знову), бо вони шукали ліда щоб стартанути команду тут.

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

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

Хоча вам з безосівщини напевне краще видно що я можу що не можу і які у нас тут розклади )))

Конечно видно, я 36 лет прожил в Украине и 13 из них проработал в украинском IT. Вообще, пройти собеседование в иностранную компанию через украинскую «аутстаф прокладку» и напрямую — это две большие разницы. И с ресурсами у многих иностранных компаний действительно проблемы: при огромном количестве кандидатов на рынке, найти профессионала очень трудно.

ообще, пройти собеседование в иностранную компанию через украинскую «аутстаф прокладку» и напрямую — это две большие разницы.

Ага дядь, через рік я принесу матеріал як я літав в фаанги офери отримувати так ти будеш фекати що позиція SDE II а не SDE III, на SDE II беруть студентоту з вулиці і взагалі фаанги норм компаніями не вважаються )))

Вот когда принесешь, тогда и говорить будем :)

Біг дата аналітик в треді, всі в хадуп кластер!

Да уж известно — не «веб-макака» :)

Тут встречный вопрос : а почему не читают резюме до собеседования?

CV було в інтерв’юера перед очима на момент питання. Поки він там питав я відкрив лінкедін і подивився скільки років я працював тімлідом, бо то було досить давно.

проблемы логистики. бывает что не донесли до собеседующего

это только на собеседовании так будет или дальше тоже так будет? )) «непередастЪ» (к) (тм)

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

Не, там менеджер-передаст вероятнее всего будет.

Ты визу американскую получал? Пишешь им там, а потом они тебя переспрашивают за это же. Отвечать «Чекай CV» как некрасиво, так и не профессионально.

то есть, «подловить на несовпадении» — нормальный формат для собеседования? что дальше? полиграф, кредитная история, проверка родственников, симуляция похищения?

Це напевне ті самі люди які готові проходити стрес-інтерв’ю )))

то есть, «подловить на несовпадении»

ты смотри а ведь логичный ход! я не подумал ))

ЗЫ: кстати да мериканцы всякие потом ещё и полгода «бэкгроунд чек» делать будут обзванивать всех включая учителя математики high school ))

Мне однажды интервьюер подсунул свой код вместо моего (который я им писал как «задание на дом») для обсуждения . А было это уже недели через две после того, как я им отправил этот код. Но подловить не получилось, т.к. мы использовали совершенно разные подходы.
Это все делается, потому что много хитроделанных соискателей, которые не только в резюме пишут неправду, но еще и другие за них проходят интервью.

Ты визу американскую получал?

так то віза, її мені треба (до речі в мене є амер. віза, отримав без проблем)
а на роботу то не тільки мені треба то ще й їм треба.

Очень часто соискатель в резюме пишет, что он д’Артаньян, а на поверку оказывается, что он просто что-то когда-то про эти технологии читал.

Как вариант, может и использовал в предыдущей работе ,но не в том объёме,что нужно для будущего проекта.Поэтому, техинтервьюер и спрашивает это в ходе собеседования.
Собеседование-это же диалог)
ЗЫ: есть требования к вакансии.Поэтому, техинтервьюер до того,как решит, что опыт кандидата
отвечает требованиям и стоит его приглашать на интервью, может попросить уточнить нюансы чз рекрутера.

Часто бывает, что hiring manager резюме видит впервые уже на самом интервью (сказывается загруженность в работе и неимоверное количество кандидатов), но в итоге диалог получался отличным.

в резюме пишет, что он д’Артаньян

а в «нормальную зарубежную компанию» (к) (тм) как раз и надо «пересказать резюме» так чтобы сразу было видно что «он дартаньян!» даже если «он просто кофе в команде подносил» ну впрочем как и все остальные «в команде» а «про эти технологии» ну так просто на коробках с оборудованием они были написанные ))

а на поверку оказывается, что он просто что-то когда-то про эти технологии читал.

Только это выясняетс не вопросами «расскажите что-то» и «повторите то что написано в резюме».
Чтобы понять уровень и практический опыт можно спросить «вот у вас написано ... что вы делали с применением этой технологии», «какие проблемы/неудобства возникали при работе с ...» или «как бы вы решали такую вот задачу» (это если реальный опыт кандидата не интересен).

Очень часто соискатель в резюме пишет, что он д’Артаньян, а на поверку оказывается, что он просто что-то когда-то про эти технологии читал

+ добавлю: это же проверяется всё на интервью.Обычно,как это бывает, задаются уточняющие вопросы по опыту,что использовали, почему именно это использовали итд.
Или там какой-то внешний кейс на знание этих технологий: а как бы Вы решили вот такую задачку/кейс и почему

что использовали, почему именно это использовали итд.

аутсорс отечественный бессмысленный и беспощадный )) всякий джун не меньше как Архитектор и сам решает «что использовали почему именно использовали и т.д.» )) ну и «спрашивают» соотв. якобы кто-то что-то там решал и вообще рядом сидел когда «почему использовали» ))

Я бы так не отвечал, это правда. Но к примеру, если бы вопросы продолжались, уже бы указал на CV.

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

может хочет просто поговорить :-) я думаю что обе стороны уже задалбывает спрашивать и отвечать одни и те же вопросы «почему equals и hashcode». меня реально уже бесит. ну неужели они думают что человек с 5+ опытом в джаве и 10+ в программировании вообще, не знает что такое хеш-код? а за поговорить я всегда за.

может хочет просто поговорить

Щоб просто поговорити мене хлопці з аутсорсу питали що я думаю про Scala, що я думаю про функціональщину, про Java 11, про мікросервісні підходи і так далі. Питання хоч і широкі були, але досить конкретні, а не просто «що-небудь».

меня реально уже бесит. ну неужели они думают что человек с 5+ опытом в джаве и 10+ в программировании вообще

я стал забивать )) т.е. это инословно написанная рекомендация «забей» )) я вон грёбаный эксперт в си+плюсах меня относительно недавно «спрашивали» «что такое указатель?» х.з. чего ожидали услышать ))

мог бы ответить «это хрень, которая указывает направление для идущих на х*й» :-))))

ну я как раз вспомнил что в ios указатели на самом деле 64-битные а памяти у него чисто физически не больше 2 гиг и соотв. полные 64 бита не нужны и они взяли и сделали хитро и сложили прямо в «условный указатель» также всякую другую служебную информацию ну или например вообще тупо поместить прямо в него данные на которые якобы «указывает указатель»... ))

... но я полагаю они не оценили. Может они хотели знать об страничной модели об кешировании процессором об преобразовании адресов об виртуальной памяти с подкачкой х.з. )) может хотели что-то услышать об неоднородной модели оперативной памяти... )) а может хотели поговорить об отличиях архитектуры Неймана от Гарвардской и какая именно применяется в арм-286 в каком режиме ))

Из своего скромного опыта программистом единственное что могу точно сказать такие вопросы вовсе не однозначный фейл самого «собеседования» но однозначный «флажок» «некоторых особенностей» также и в уже в работе в команде и в задачах и в их решениях ну а дальше всё бросто «берёшь свои деньги и не делаешь себе нервы» и вот последнее таки самое тяжело и самый суровый «софт-скилл» профессии.

Витя, ты знаешь, почему я всех спрашиваю про equals и hashcode? Потому что абсолютное большинство собеседуемых не знает, правил для них, как результат не понимает, как работают хеш таблицы, и лепят черти что в equals и hadhcode в разных говноОРМах и везде подряд.

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

Таки не знают, а те кто знают на собеседовании забывают при реальной работе. Поэтому есть простое правило: не переопределять equals и hashCode. Такое правило проще запомнить чем контракт этих методов.

Если уж попалась задача где надо для оптимизации работы мапы переопределить, то контракт equals/hashCode будет самой маленькой проблемой (особенно с учетом того что даже в хеш-мапе не все время хеш-таблица :) )
Та и в случае с ОРМ, equals/hashCode — это наименьшая проблема (так же решаемая правилом описанным выше).

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

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

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

И вот тут проявляется очень популярное заблуждение:
Глубокое знание коллекций (хорошо если вы тут имеете ввиду структуры данных, а не джава АПИ :) ) не является необходимым условнием для того чтобы считать человека синьором. Тем более таковым не является знание контракта equals/hashCode. Кстати, про упомянутое вами требование неизменяемости хеша вообще мало кто знает.

Попробуйте все-таки ответить на оба вопроса которые я озвучил выше (особенно на второй).

Как это можно не знать, как же у них все работает?

Так и работает. Это типично, когда в оба метода лепят все поля, это можно увидеть в каждом втором проекте с jpa. Плюс так делает автогенерация в идее. Плюс ломбок лепит все по умолчанию. А потом все эти трудности героически преодолеваются.

Я бы спросил про бизнес-ключ или обджект айдентити тогда.

Это типично, когда в оба метода лепят все поля, это можно увидеть в каждом втором проекте с jpa. Плюс так делает автогенерация в идее. Плюс ломбок лепит все по умолчанию. А потом все эти трудности героически преодолеваются.

А что с этим подходом не так? Так работает дефолтное поведение для языков, где основные рабочие типы идут с поддержкой с structural equality(в основном функциональные, но в императивные тоже уже постепенно внедряется именно таким образом). Может в java когда-то такое появится. Трудности вызваны самой семантикой языка в этом случае и неудобной системой типов, которая требует написания тон бесполезного boilerplate кода.

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

Так это ж разные вещи совершенно

когда в оба метода лепят все поля,

и

что hascode immutable и единожды вернув значение, он должен возвращать его всегда

понимаете? если есть первое, это не значит, что у вас гарантированно второго не будет.

Если ты добавляешь не финальное поле в hashcode, то hadhcode по определению перестает быть immutable. Если ты вычислаешь значение по этим полям, сохраняешь, а потом продолжаешь использовать их в equals, то ты ломаешь контракт между equals и hashcode.

Если меняться что-то в объекте — меняется и сам обьект и скорее всего(значение ключ). Наверное поэтому в ключах даже в ООП языках максимально стараются использовать простые из коробки иммутабельные или, при необходимости, создавать таковые.
Для какой задачи вам нужен обьект с сайд эффектами и что бы этот обьект был ключем в хеш сете?

Ты это серьёзно спрашиваешь или ты искренне не понимаешь? Как только ты положишь объект в хеш сет и изменишь ему хеш код, ты его потеряешь, и сгенерируешь утечку памяти. При том что в entity идентити объекта является ключ в базе, и при изменении любого поля ты пооучишь массу интересных сайдэффектов.

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

Для этого есть дефолтное поведение по ссылкам, которое не следует менять без надобности.

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

Так в чем задача — выбрать уникальные обьекты по ключу в java? Это уже можно делать просто без переопределения equals/gethashcode и использования hash set напрямую. Использовать для этого equals/gethashcode будет так же небезопасно и неправильно.

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

Вот тут теория сталкивается с практикой: в теории вы правы, на практике в хешсет складывают value objects.

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

Так может лучше поговорить про эти сайд эффекты, а не надеялся что человек сможет применить свои знания джавадока equals/hashCode на реальную задачу?
Кстати, на практике эти файд эффекты так же возникают редко (но когда возникают то очень больно :) ), потому что как правило сущность читается из БД и протаскиевается серез весь транзакшинал скрипт. Сценарии когда сущность в рамках сессии (и тем более транзакции) перечитывается несколько раз не так уж часто встречаются, и как правило там есть еще куча проблем помимо вызваных такими вот чтениями.

Когда я собеседовал кандидатов и хотел просто поговорить, я задавал вопросы типа: «Каковы цели и задачи QA?», а не: «Расскажите что- нибудь про QA». Очевидно, что оба вопроса подразумевают растекание мыслёй по древу, но в случае 1- го вопроса понятно направление растекания.

человек с 5+ опытом в джаве и 10+ в программировании вообще, не знает что такое хеш-код

Та легко. Видал неоднократно.

Как бы полностью диалог:

— Розкажіть мені щось про JVM.
— Що?
— Щось.
— Ви знаєте, я не Шипильов, щоб вам тут про JVM розповідати. Давайте, може, якесь конкретне питання?

ЗЫ:
— Ви знаєте, я не Шипильов, щоб вам тут про JVM розповідати. Давайте, може, якесь конкретне питання?
Можно ,как совет,просто сказать: конкретизируйте,пжлст,Ваш вопрос. Тут еще зависит в каком формате,тональности шел диалог.Понятно,что хамить не стоит при любых вопросах)

Как бы полностью диалог

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

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

обычно на вопрос «расскажите что-нибудь о ххх» я начинаю с определения «ххх — это...». Таким образом можно откусить 5мин интервью цитированием документации, а интервьювер там уже по ходу придумает где спросить уточняющий вопрос

Понятно,что хамить не стоит при любых вопросах)

сперва хамишь потом просто привыкаешь и начинаешь «рассказывать щось...» на темы на которые спрашивающий начинает быстро вянуть и вспоминать что же ж таки спросить конкретного из того что он хотя бы б знает об чём речь ))

Но проблема там в том что «относиться с юмором» практически всегда придётся не только на собеседовании а в реальной работе это уже реально тяжело в т.ч. «хамить не стоит при любых вопросах» увы.

начинаешь «рассказывать щось...» на темы на которые спрашивающий начинает быстро вянуть и вспоминать

А вот тут отличие архитектора от просто разработчика: если «спрашивающий» просто вянет и ничего не вспоминает, то вы можете претендовать на должность архитектора :)

то вы можете претендовать на должность архитектора :)

могу )) а толку? думаете кто-то слушать станет? )) см. п.п.

бросто «берёшь свои деньги и не делаешь себе нервы»

это работает я проверял ))

Ну можно и по другому. Говорите интервьюверу не перебивать и начинаете лекцию на часа 2-3 по JMV и главное не отпускаете его пока не закончите.
Ну а после говорите, что эта контора вам не подходит и прощаетесь.
Правда это только в том случае, если в ближайшие 2-3 часа вам совсем нечем заняться.

Любую технологию можно описать на high-level уровне в течении пары минут (если знаешь конечно). Если интервьюер видит, что ты знаешь и готов утроить лекцию на 2 часа, он сам попросит остановиться :)

И вообще двумя словами х..як-х...як.

Если интервьюер видит, что ты знаешь

а сразу он не «видит»? а как он «увидит» без лекции на 2 часа? вдруг кандидат специально 5 минут «вступления» вызубрил и просто читает на память в расчёте на то что «интервьюер увидит и сам попросит остановиться» ещё до того как записанная речь закончится? ))

откуда вообще «интервьюеры» берутся? а они «знают»? а если нет? чисто статистически они точно такое же ж люди и родились не в компании а откуда-то взялись там причём тем же ж путём «кандидатом» откуда надо знать что в своё время это прошло точно так же ж или наоборот _точно_ так же ж просто тогдашний «интервьюер» решил вопрос «знает не знает» по-своему и технической части там и вообще не было?

вопрос именно в том что обсуждаемая «проблема» эта такая «игра» но обязательно с двумя участниками и вопрос в том что полных фактов об оппоненте нет ни у того ни у другого ну разве что один из них «особо известен в узких кругах». В остальном же ж любые попытки как-либо эту игру «объяснить» особенно «эйчар-популярными терминами» вроде «любую технологию можно описать» (к) (тм) это именно та ерунда которую следует высматривать и избегать потому как она как раз очень чётко характеризует «сторону-участника» ))

Любую технологию можно описать на high-level уровне в течении пары минут (если знаешь конечно).

=>

Big Data Architect

опиши двумя абзацами. Можно одним.

Big Data Architect
опиши двумя абзацами. Можно одним.

ЕТЛ где данные лежат на сетевых распределенных хранилищах :)

UPD. Посмотрел что человек работает в Амазоне:
Консультация какие продукты Амазона вожно впихнуть в контору «кастомера» :)

UPD. Посмотрел что человек работает в Амазоне:

архитектором?

Big Data Architect — это вообще-то роль, а не технология :) Я понимаю, что человеку, программисту, который нечасто (или вообще никогда) публично не выступал, или не презентовал заказчику своих технологических решений, очень сложно компактно и емко осветить тот или иной топик. Но, если этим заниматься на постоянной основе, то можно увидеть, как много можно сказать за 2-3 минуты.

А по поводу Big Data Architect — например, вот так, в 2 абзаца:

— разрабатывает решения для систем управления данными, такие как хранилища данных (Data warehouses) и озера данных (Data Lakes). После оценки потенциальных источников данных компании (внутренних и внешних) архитектор разрабатывает план их интеграции, централизации, защиты и обслуживания. Также архитектор тесно сотрудничает с различными бизнес структурами — отделами, подразделениями — для разработки стратегии обработки данных и их визуализации, определения требований к конечным данным, выявления проблем бизнеса, которые можно решить с помощью вышеуказанных систем. В итоге, разработанные и внедренные решения позволяет сотрудникам компании на разных уровнях (от директора до рядового сотрудника) получать доступ к важной информации в нужном месте и в нужное время, что благоприятно сказывается на развитии компании.
Архитектор должен обладать глубокими техническими знаниями в области баз данных (relational, document, in-memory graph, etc.), облачных технологий (AWS, GCP, MS Azure), защиты данных, интеграции систем на различных уровнях, программировании, стратегиях деплоймента, сетевых технологий. Практический опыт работы (hands-on experience) очень важен, и по своему объему не должен уступать «теоретическому». Кроме того, архитектор должен обладать личными качествами (т.н. soft skills), используя которые, он может эффективно и гармонично коммуницировать с заказчиком, принимать непосредственное участие в принятии решений, брать на себя ответственность и риски, руководить разработкой, уметь обучать сотрудников заказчика.

Не думаю, что на данный текст нужно более двух минут.

— разрабатывает решения для систем управления данными, такие как хранилища данных (Data warehouses) и озера данных (Data Lakes).

=>

Любую технологию можно описать на high-level уровне в течении пары минут (если знаешь конечно).

ок дальше я не читал сорри ))

«А получилось как всегда» (к) (тм) — «А скажи что-нибудь по-архитекторовски!» (к) (тм)

ЗЫ: хм каюсь прочитал дальше ок а ты точно уверен что ты программист вообще? )) может эта роль ругательная и попрошу ко мне её не применять (к) (тм) скорее солюшин архитект вон недавно как раз была статья на доу.

Это вот как с циской (к) (тм) и сертификаты есть натурально подтверждающие и протоколы они знают лучше меня (ну ок это скорее «младшие архитекторы» которые постарше те уже конечно больше «руководить и обучать и софт-скиллз») не говоря уже об знании ассортимента оборудования и кто куда предназначен лучше но всё равно я программист а они нет причём от слова вообще ))

Я и не говорил, что я программист. Был когда-то давно, но в 2010 переключился на Data Warehousing и Big Data.

Не думаю, что на данный текст нужно более двух минут.

Но есть проблемы:
— вы ни слова не сказали про БигДату
— вы подмешали задачи БА к задачам архитектора
— вы подмешали задачи ПМа к задачам архитектора

Суммарно, то что вы описали в наших аутсорсерах называется Солюшн Архитект, а раньше на западе называлось Пресейл Инженер.

Любую технологию можно описать на high-level уровне в течении пары минут (если знаешь конечно).
Если интервьюер видит, что ты знаешь и готов утроить лекцию на 2 часа, он сам попросит остановиться :)

Тут дело не в знаниях, а в умении лапшать. Часто приходят люди которые очень классно (и даже не пару минут) рассказывают, а на вопрос «как вы решали такую вот проблему» отвечают «у нас ее не было», и после дальнейших распросов становится понятно что проблемы не было ибо технологию использовали без особой надобаности.

вы ни слова не сказали про БигДату

Ок, добавляем «Big Data» в первое предложение, получаем «разрабатывает Big Data решения для систем управления данными». Добавляем небольше пояснение:
«Big Data» — это термин, описывающий такие большие объемы данных, которые не могут быть эффективно обработаны существующими системами обработки данных.

— вы подмешали задачи БА к задачам архитектора
— вы подмешали задачи ПМа к задачам архитектора

Я описал обязанности Big Data Architect в Амазоне. Причем это уровень не сеньора. Сеньор уже принимает участие в pre-sales.
Но, если посмотреть на позиции архитекторов в продуктовых компаниях, то практически у всех есть такие обязанности, как
1) Demonstrated experience as a trusted advisor to customers
2) Collaborate with upstream sources and downstream consumers to come up with expandable data contracts
3) Continually coach on latest data architecture and technology
4) Train and mentor the team in data modeling and data quality related processes and standards
5) Work across teams to empower and lift the team’s effectiveness
И абсолютно везде надо:
1) Strong written, oral, presentation and interpersonal communication skills

«Big Data» — это термин, описывающий такие большие объемы данных, которые не могут быть эффективно обработаны существующими системами обработки данных.

Вы даже перевести не смогли правильно, не «существующими», а «традиционными».

Я описал обязанности Big Data Architect в Амазоне.

Здравствуйте, это Сем из Амазон. Мы можем организовать митинг с вашим руководством, чтобы наш продаван смог впихнуть вам 100500 сервисов, которые вам не нужны и вы будет за них нам платить 100500 денег.

После того как Сема послали пару раз, текст поменялся на:
Здравствуйте, это Сем из Амазон. Мы можем организовать митинг с вашим руководством, чтобы наш Big Data Architect смог Demonstrated experience as a trusted advisor to customers.

Но, если посмотреть на позиции архитекторов в продуктовых компаниях, то практически у всех есть такие обязанности, как
1) Demonstrated experience as a trusted advisor to customers

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

В одній з контор де я працював майже всі «архітектори» були вихідцями з бізнес-аналітиків та системних інженерів )))

Ну да, когда возразить уже нечего, осталось только цепляться к словам :) Знаете, мне как то пофиг, мой английский все равно на порядок лучше вашего, так что можете язвить сколько хотите :) По продуктам Амазана — если кастомер хочет, то приглашают специалиста из команды разработки. Вот недавно приглашали из AWS Glue для прояснения некоторых моментов.

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

Вам настолько пофик, что вы даже начали искать способы показать свое превосходство (как человеку с развитыми софт-скилами вам должно быть понятно признаком чего это является), вместо того чтобы «за 2 минуты» показать весь свой опыт :)
Кстати, как это вы по фотографии уровень английского определяете?

По продуктам Амазана — если кастомер хочет, то приглашают специалиста из команды разработки. Вот недавно приглашали из AWS Glue для прояснения некоторых моментов.

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

Ну вы сами начали детский сад тут разводить, я просто «поддержал разговор».
И я тут не на работе, мои софт скилы сейчас отдыхают :)

Кстати, как это вы по фотографии уровень английского определяете?

Так само як і стресотривкість со софтскіли людей по двом друкованим фразам з оповідання.

не ну не скажи )) тут как с динозавром либо встретишь либо нет )) либо прилетела ответочка либо нет соотв. либо лояльный гребец либо бунтовщик понятно почему его с прошлой галеры за борт кинули ))

ЗЫ: ты вон послушай выступление чувака который в гугл прошёл «много учил алгоритмы решать задачи» там у него есть такой момент как раз «за лояльность на софт скиллах» очень чОтко прописанный ))

Правильно, пора переставать быть дикарями :)

вы путаете серые галеры с другими ))

youtu.be/YR5ApYxkU-U

Так не нужно даже и двух фраз бросать. Хамоватый «профессионал» никому не нужен, даже если он профессионал, ибо незаменимых нет.

ибо незаменимых нет.

вы путаете серые галеры с другими ))

youtu.be/YR5ApYxkU-U

Ок, добавляем «Big Data» в первое предложение, получаем «разрабатывает Big Data решения для систем управления данными».

не ответил ))

Добавляем небольше пояснение:
«Big Data» — это термин, описывающий такие большие объемы данных, которые не могут быть эффективно обработаны существующими системами обработки данных.

да вообще-то нет ))

Но так уж и быть ты архитектор тебе виднее однако следует признать твою же ж поставленную задачу

Любую технологию можно описать на high-level уровне в течении пары минут (если знаешь конечно).

ты провалил ))

Но опять же ж повторюсь конечно же ж ты архитектор ни разу не программист возможно на твоём уровне архитектора такое «описание на high-level уровне» это гут иначе бы б ты не работал бы б в гугле.

ЗЫ:

1) Strong written, oral, presentation and interpersonal communication skills

ахринеть довели страну неужели сегодня вайти никто непосредственно программ уже не пишет? чёт я аццкий ретроград однако ((

ахринеть довели страну неужели сегодня вайти никто непосредственно программ уже не пишет?

Пишут, но зовут их Раджеш, Иван или Пэтро :)

Так просили же описать не технологию, а роль — Big Data Architect :) На каждую технологию, используемую архитектором — ещё по 2 минуты :)
А по поводу soft skills — они и senior data engineer нужны, т.к. он обычно отвечает за разработку data pipeline от начала и до конца (end-to-end), начиная с получения доступа к источникам данных и заканчивая отчетами, попутно общаясь с командами, которые владеют источником (data source access) , бизнес юзерами (business requirements) админами (network access, IP whitelisting), администраторами баз данных (dB access), и т.д. И поверь, эти общения зачастую бывают совсем не дружеские :) Поэтому надо быть proactive и think out of the box :)

ты сейчас реально выдал кучу реально интересной инфы как вы там у себя реально работаете и как реально вся ваша работа включая «senior data engineer» к программированию не относится над этим надо подумать это реально интересно.

Кстати ко всем у кого пиетет перед словом «продуктовая компания» вы там уточняйте сперва вдруг там «продукты» это винишко и сырки так бывает ))

ЗЫ: тогда ещё один интересный вопрос остаётся для уточнения а ваш department это вообще engineering или как-то по-другому называется?

«продукты» это винишко и сырки так бывает

Что может быть лучше?)

Кстати ко всем у кого пиетет перед словом «продуктовая компания» вы там уточняйте сперва вдруг там «продукты» это винишко и сырки так бывает ))

А вот сейчас обидно было)))) www.aspose.com/holiday-offer-2018 Consume the whole case at once and boost your software development skills and performance by 25% forever!

А вот сейчас обидно было))))

почему? у волмарта между прочим достаточно большой вайти рнби центр )) конечно они торгуют только сыром и винишком... ))

наш департамент так и называется — «реальные пацаны» :)))))

а ну тогда конечно да ))

Ми шукаємо таке питання, на яке б ти не відповів

Украинский аутсорс — бессмысленный и беспощадный :)

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

Спасибо за этот цикл статей, было интересно почитать!

Их тех компаний в которые ты собеседовался, были топовые продуктовые?
Типа Grammarly, Ring, DataRobot ?

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

Тому, якщо вам не пощастило працювати в highload/adtech/fintech/gambling проектах, де є реально великі навантаження, то вашою найскладнішою проблемою, напевне, було розслідування якогось хитрого бага, який не давав нормально рендерити формочки або конвертувати один XML в інший.

Звучит грустно.

То надо искать такой проект. Хотя часто то, что подают как highload — то же самое из говна и палок, зато с автоскейлингом.

то же самое из говна и палок, зато с автоскейлингом

Та навіть щоб автоскейлінг норм зробити треба трохи мізками думати.

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

смотри на это проще

На що?

Отримав 3,5 офери (менше ніж 25% конверсії, що, як на мене, малувато).

Вы проделали большую работу и статьи годные. Понравились все)

Спасибо, было интересно почитать)

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