Чи не здається вам дивним те, що коли ви збираєтеся поміняти місце роботи і виникає необхідність пройти інтерв'ю, то насамперед ви думаєте «треба підготуватися до інтерв'ю». Вирішувати завдання на HackerRank, почитати Crack the coding interview, зазубрити як влаштований ArrayList і чим вона відрізняється від LinkedList. Ах так, ще сортування запитати можуть, і явно буде непрофесійно сказати, що quick sort швидше за все буде найкращим вибором.
Але заждіть, адже ви програмуєте 8 годин на день, вирішуєте цікаві та нетривіальні завдання, і на новому місці роботи робитимете плюс-мінус теж саме. Проте, щоб пройти інтерв'ю, необхідно якось додатково готуватися, навіть не відточувати щоденні навички, а вивчити те, що вам не знадобилося ні на поточному місці роботи, ні навряд чи знадобитися на наступному. На ваші заперечення про те, computer science у нас у крові, та розбуди нас посеред ночі ми повинні написати із закритими очима на наволочці обхід дерева завширшки навіть не приходячи до тями, я відповім, що якщо я буду влаштовуватись у цирк, та моїм головним трюком буде саме це — мабуть так, я згоден. Потрібно цю навичку перевірити.
Але навіщо перевіряти нерелевантні поточній роботі навички? Лише тому, що це стало модним? Тому що Google робить так? Або тому, що вашому майбутньому тимлід довелося вивчити всі методи сортування перед проходженням співбесіди і тепер він вважає що "кожний хороший програміст зобов'язаний знати напам'ять реалізацію знаходження паліндрому в рядку".
Так ось, ви не Google (с). Що може собі дозволити Google, звичайні компанії не можуть. Гугл, проаналізувавши дані своїх працівників дійшов висновку, що саме у нього, саме його завданнями добре вдається займатися інженерам з олімпіадним минулим. Більше того, будуючи процес відбору, вони можуть собі дозволити закласти ризик того, що вони можуть не найняти кількох хороших інженерів через те, що вони не вміють так легко клацати математичні завдання. Але для них це не біда, охочих працювати в Google багато, позиція закриється.
Тепер давайте виглянемо у вікно, і якщо перед вашим офісом ще інженери, які бажають у вас працювати, не розбили наметовий табір, а ваші розробники частіше шукають на stackoverflow якусь чергову Спрингову анотацію потрібно поставити, а не тонкощі алгоритмів ранжування, то, мабуть, вам час задуматися над тим чи варто копіювати Google.
Добре, якщо цього разу Гугл підвів і не дав відповіді, що робити? Перевіряти те, що розробник робитиме на роботі. Що ви цінуєте у розробниках?
Складіть критерії кого ви хочете найняти та розробте тести, які перевіряють саме ці навички.
ДумкаРоботи
До чого ж тут ThoughtWorks? Саме тут я знайшов собі приклад зразкової співбесіди. Хто такі ThoughtWorks? Якщо коротко, то це High-End консалтингова компанія з офісами по всьому світу, починаючи від Китаю, Сінгапуру і закінчуючи Американськими континентами, яка займається консультуванням у сфері розробки близько 25 років, має свій Science підрозділ, який очолює Мартін Фаулер. Якщо ви пошукайте список з 10 книг, які must read для Software Engineer, то, мабуть, 2-3 з них будуть написані хлопцями з ThoughtWorks, наприклад Refactoring By Martin Fowler і Building Microservices: Designing Fine-Grained Systems by Sam Newman або Building Evolutionary Architectures
by Patrick Kua, Rebecca Parsons, Neal Ford.
Бізнес компанії будується на надання досить дорогих послуг, але замовник платить за феноменальну якість, що складається з експертизи, внутрішніх стандартів та, звичайно, людей. Тому тут життєво потрібно наймати правильних людей.
Які ж люди правильні? Звісно ж для кожного свої. ThoughtWorks визначила, що для їх бізнес-моделі для розробників найважливішими критеріями є:
- Здатність до парної розробки. Саме здатність, а не досвід чи вміння. Ніхто не очікує що прийдуть люди, які практикують Pair programming ось уже років 5. Але бути сприйнятливим до чужої думки, вміти слухати це необхідна навичка.
- Вміння писати тести, а в ідеалі практикувати TDD
- Розуміти SOLID та ОВП та вміти застосовувати їх.
- Презентувати свою думку. Консультантом доводиться працювати з розробниками замовника, з іншими консультантами, і не так багато користі, якщо людина вміє щось робити добре, але нездатна донести це до інших членів команди.
Наразі важливо оцінити саме ці навички у кандидата. І тут я хочу розповісти про свій досвід проходження співбесіди ThoughtWorks. Скажу відразу, що я проходив у Сінгапур і пройшов, але процес рекрутингу уніфікований і не сильно відрізнятиметься від країни до країни.
Етап 0. HR
Як це часто і буває 20-хвилинна співбесіда з HR. На ньому зупинятись не буду, скажу лише, що я ніколи раніше не зустрічав HR, який міг би 15 хвилин розповідати про культуру розробки в компанії, чому вони застосовують TDD, чому парне програмування. Зазвичай на цьому питанні HR'и зникають та розповідають, що процес у них звичайний: розробники розробляють, тестувальники тестують, менеджери поганяють.
Етап 1. Наскільки ти хороший в ООП, TDD?
За 1.5 години до початку співбесіди мені надіслали завдання зробити симулятор Mars Rover.
Завдання Mars roverНа сході robotic rovers є, щоб бути landed NASA on plateau on Mars. Цей plateau, який є curiously rectangular, повинен бути нав'язаний роверами, що їх на комп'ютері камери можуть отримати повний перегляд земної зони до send back to earth. Рівень становища і місцезнаходження є репрезентованим по комбінації x і y координацій і повідомлень одного з чотирьох кардинальних комп'ютерних пунктів. Plateau is divided up in grid to simplify navigation. На прикладі становище може бути 0, 0, N, які способи загоряння є в нижній частині лівого торця і торкається North. У відповідь на контрольну лінію, NASA перебуває в прямому рядку повідомлень. Можливі Letters є 'L', 'R' і 'M'. 'L' і 'R' матимуть rover spin 90 градусів долі або праворуч respectively, безпереміщення від його поточної spot. 'M' means переміщується за один шнур, а maintain the same heading.
Assume that the square directly North from (x, y) is (x, y+1).
ВХОД:
Першу лінію введення є нижчим правом координатором мітингу, лівим-ліфтом орієнтирів буде прийнято до 0,0.
Зовнішній зв'язок є інформацією, що покладається на роги, які повинні були розбиті. Each rover has XNUMX lines of input. Перші лінії ведуть rover's position, і second line є рядами інструкцій telling rover how to explore the plateau. Політика є виконаною з двох integers і letter separated by spaces, відповідають x і y co-ordinates і rover's orientation.
Чому rover will be finished sequentially, which means that the second rover won't start to move until the first one has finished moving.
ВИХІД:
Запуск для кожного rover повинен бути його результатом co-ordinates and heading.
ПРИМІТКИ:
Докладно реалізовуючи вимоги до і віри в акумулятора робочих робіт, щоб записати unit tests for it.
Creating any form of user interface is out of scope.
Вирішення проблеми, що спрямоване на TDD (Test Driven Development), рішення буде preferred.
У короткий час можливий, ми більше впевнені про якість, яка повністювідповідна.
*Я не можу викласти завдання, яке мені надіслали, це старе завдання, яке давалося кілька років тому. Але повірте, важливо все залишилося так само.
Окремо хочеться звернути увагу на критерії оцінки. Скільки разів вам доводилося стикатися з ситуацією, коли важливі для кандидата речі, зовсім не важливі під час перевірки та навпаки. Не всі думають так само, як ви, але багато хто може прийняти ваші цінності і слідувати їм, якщо їх чітко прописати. Отже, з умов оцінки відразу відомо що найважливішими навичками цьому етапі є
- TDD;
- Вміння використовувати ООП та писати підтримуваний код;
- здатність до парного програмування
Отже, мене попередили, щоб я витратив ці 1.5 години на обмірковування того, як я збираюся робити завдання, а не написання коду. Код писатимемо разом.
Коли ми зателефонували, хлопці коротко розповіли, хто вони і чим займаються і запропонували приступити до розробки.
За весь час інтерв'ю у мене жодного разу не виникло відчуття, що я перебуваю на співбесіді. Є відчуття, що ти розробляєш код у команді. Якщо ти десь застряєш, вони допомагають, радять, обговорюють, навіть сперечаються між собою як краще зробити. На співбесіді я забув як у JUnit 5 перевірити, що метод викидає Exception - вони запропонували продовжити писати тест, поки один з них гуглил як це зробити.
Буквально за кілька годин після співбесіди я отримав конструктивний фідбек — що сподобалося і що ні. У моєму випадку похвалили за використання Sealed класів як альтернативи об'єктуnull; за те, що перед написанням коду написав псевдокодом як би мені хотілося керувати ровером, і таким чином отримав нарис класів, принаймні тих, які задіяні в API робота.
Етап 2. Розкажи нам
За тиждень до співбесіди мене попросили підготувати презентацію на будь-яку цікаву тему. Формат простий та звичний: 15 хвилин презентація, 15 хвилин відповіді на запитання.
Я вибрав Clean Architecture by Uncle Bob. І знову мене інтерв'ювала пара людей. Це був мій перший досвід презентації англійською, і, мабуть, якби я був у стресовій ситуації — я не впорався б. Але знову-таки, у мене жодного разу не виникло відчуття, що я на співбесіді. Все, як завжди, я розповідаю, вони уважно слухають. Навіть традиційна сесія питань та відповідей була не схожа на інтерв'ю, було видно, що питання задають не для того, щоб “потопити”, а ті, які їх справді зацікавили у моїй презентації.
За кілька годин після співбесіди отримав фідбек — презентація дуже корисна і вони отримали щиру насолоду від прослуховування.
Етап 3. Production Quality Code
Попередивши, що це останній етап технічних співбесід, мене попросили довести вдома код до production-ready стану, після чого відправити код на рев'ю та призначити співбесіди, на якій вимоги до завдання зміняться і код вимагатиме модифікації. Забігаючи наперед, можу сказати, що рев'ю коду проводиться наосліп, рев'ювери не знають ні позиції, на яку претендує кандидат, не бачать його CV, навіть не бачать його імені.
Здзвон, і знову-таки пара хлопців з того боку монітора. Все як на першій співбесіді: головне не забувати про TDD, розповідати, що ти робиш і навіщо. Якщо ви раніше не практикували TDD, то я рекомендую негайно почати це робити, не тому що це необхідно в компаніях, а тому, що це спрощує ваше життя, знижує рівень стресу якщо хочете. Пам'ятайте, як доводилося судомно шукати дебаггером помилку, яка відтворюється лише через браузер, а тестами ви її відтворити не можете? Тепер уявіть, що вам доведеться відловлювати таку помилку під час співбесіди - пара-трійка сивого волосся вам забезпечена. Що ж нам забезпечене із TDD? Змінили код і зненацька для себе зрозуміли, що тепер тести червоні, а в чому помилка зрозуміти з першого разу не вдається? Окей, говоримо інтерв'юверам "Упс", натискаємо Ctrl-Z і починаємо йти маленькими кроками вперед. І так, вміння розробляти з використанням TDD, треба в собі виробляти, вміння йти до мети так, щоб у вас тести були перманентно зеленими, а не червоними пів дня, тому що у вас великий рефакторинг. Це такий самий навичка, як уміння писати підтримуваний код, або продуктивний код.
Отже, наскільки добре ваш код піддається змінам, залежить від того, який дизайн ви спочатку заклали, наскільки він простий і від того, наскільки хороші ваші тести.
Після співбесіди я отримав фідбек за кілька годин. На цьому етапі я зрозумів, що практично пройшов і залишилося зовсім небагато до “зустрічі з Фаулером”.
Етап 4. Фінал. Достатньо технічних питань. Ми хочемо знати, хто ти!
Чесно кажучи, мене така постановка питання дещо спантеличила. Як можна зрозуміти, що я за людина за одну годину розмови? І вже тим більше як можна це зрозуміти, коли я розмовляю не рідною мені мовою, та й, відверто кажучи, дуже паршиво і недорікувано. На попередніх інтерв'ю особисто мені було простіше розповідати, ніж відповідати на запитання, і винен усьому акцент. Принаймні один із інтерв'юверів був азіат — а їхній акцент, ну скажімо так, дещо специфічний для європейського вуха. Тому я вирішив застосувати проактивний підхід — підготувати презентацію про себе та на початку співбесіди запропонувати розповісти про себе із цією презентацією. Якщо вони погодяться, то принаймні буде менше запитань до мене, якщо відхилять пропозицію — ну що ж, 3 години мого життя, витрачені на презентацію, — не така вже й висока ціна. Але що ж писати у презентації? Біографію — Народився там, тоді пішов до школи, закінчив університет, — та кому це цікаво?
Якщо трохи погуглити про культуру Thoughtworks, можна знайти статтю Мартіна Фаулера [https://martinfowler.com/bliki/ThreePillars.html], в якій описуються 3 Pillars: Sustainable Business, Software Excellence, і Social Justice.
Припустимо, що Software Excellence у мене вже перевірили. Залишається показати Sustainable Business та Social Justice.
До того ж наголос я вирішив зробити на останнє.
Для початку розповів чому ThoughtWorks – ще в інституті читав блог Мартіна Фаулера, звідси й любов до Clean code.
Проекти теж можна подати з різних ракурсів. Розробляв і для медицини ПЗ, яке спрощувало життя пацієнтам, і навіть по чутках врятувало одне життя. Розробляв і програмне забезпечення для банків, теж свого роду спрощення життя громадянам. Особливо, якщо цим банком користується відсотків 70% населення країни. Не про Ощадбанк і навіть не про Росію.
Бажаєте дізнатися про мене? Окей. Моє хобі – фотографія, так чи інакше тримаю фотоапарат у руках років 10, є фотографії, які не дуже соромно показати. Так само, у свій час, я допомагав притулку для кішок: фотографував кішок, яким потрібен постійний будинок. А з добрими фотографіями прилаштувати кішку набагато легше. Напевно, зняв із сотню кішок 🙂
Зрештою, 80% презентації у мене було заповнено кішками.
Відразу ж після презентації мені написав HR, що він ще не знає результатів співбесіди, але вже весь офіс вражений кішками.
Зрештою, я дочекався фідбека — я всіх задовольнив як особистість.
Але HR за фінальної розмови тактовно розповів, що Social Justice це дуже добре і потрібно, але не всі проекти такі. І спитав, чи не лякає це мене. Загалом, переборщив я трохи із Social Justice, буває 🙂
Підсумок
Як підсумок, я вже кілька місяців працюю в Сінгапурі в Thoughtworks, бачу, що і тут багато компаній переймають "найкращі практики співбесіди" з Google, використовуючи листочки та Whiteboard для коддингу, при тому, що знань далі Spring'а, Symfony, RubyOnRails ( потрібне підкреслити) у роботі не потрібно. Інженери беруть тижневу відпустку перед співбесідою щоб “підготуватися”.
У Thoughtworks ж, крім адекватних вимог до кандидата на чільне місце ставляться такі принципи:
Joy of Interviewing. При цьому для обох сторін. Справді, якщо ви хочете отримати найкращі кадри (а хто не хоче?), то співбесіда — це не ринок, де обирають рабів, а оглядини, де роботодавець і кандидат оцінюють один одного. І якщо у кандидата з компанією асоціюються приємні емоції — цілком імовірно, що він вибере саме цю компанію
Multiple interviewers до mitigate bias. У Thoughtworks парне програмування – стандарт де-факто. І якщо цю практику можна застосувати в інших галузях, TW намагається це робити. На кожному етапі співбесіду проводять 2 особи. Таким чином, кожну людину оцінює мінімум 8 осіб, і TW намагається підбирати інтерв'юверів з різним бекраундом, різних напрямків (не лише технарів) та підлоги.
Зрештою, рішення про прийом на роботу буде прийнято на підставі думки як мінімум 8 осіб, і ні в кого немає права вирішального голосу.
Attribute-based hiring Замість того, щоб приймати рішення на підставі “подобається” кандидату, для кожної ролі та для кожного етапу розроблено форму, що включає оцінювані атрибути. При цьому при оцінці дуже радять оцінювати не досвід у певному навичці, а здатність застосовувати його. Таким чином, якщо у кандидата не було можливо застосовувати будь-які скіли, як TDD, але він намагається застосовувати його, слухає поради щодо правильного використання — у нього є всі шанси пройти інтерв'ю.
Education Certificates не потрібна TW не вимагає від кандидата обов'язкових сертифікатів чи освіти у Computer Science. Оцінюються лише вміння.
Це перше інтерв'ю з тих, що я проходив в іноземні компанії, до якого мені не довелося готуватися. Після кожного етапу я не відчував себе вичавленим як лимон, а навпаки, я був радий, що я можу застосовувати найкращі практики, що люди з того боку монітора цінують це, і так само застосовують їх щодня.
Через кілька місяців можу сказати, що очікування виправдалися повністю. Чим ThoughtWorks відрізняється від звичайної компанії? У звичайній компанії ви зможете знайти хороших розробників і приємних людей, але в TW їхня концентрація зашкалює.
Якщо ви бажаєте приєднатися до ThoughtWorks, відкриті вакансії можна переглянути
Також пропоную звернути увагу на цікаві вакансії:
Lead Software Engineer: , , ,
Старший інженер-програміст: , , ,
Інженер-програміст: , ,
Senior Data Engineer:
Аналітик якості:
Infrastacture: , ,
(Хочу чесно попередити, що реферальне посилання, якщо ви пройдете в TW, то я отримаю приємний бонус). Вибирайте офіс до душі, не обов'язково обмежуватися тільки Європою, врешті-решт кожні 2 роки TW буде щасливий перевезти вас в іншу країну, т.к. це частина політики ThoughtWorks, таким чином культура поширюється та усереднюється.
Не соромтеся ставити запитання у коментарях або просити мене порадити вас.
Якщо тема здалася цікавою, я напишу про те, як працює у ThoughtWorks і як живеться в Сінгапурі.
Джерело: habr.com