Ці не здаецца вам дзіўным тое, што калі вы збіраецеся памяняць месца працы і ўзнікае неабходнасць прайсці інтэрв'ю, то ў першую чаргу вы думаеце "трэба падрыхтавацца да інтэрв'ю". Вырашаць задачы на HackerRank, пачытаць Crack the coding interview, вызубіць як уладкованы ArrayList і чым яна адрозніваецца ад LinkedList. Ах так, яшчэ сартавання спытаць могуць, і відавочна будзе непрафесійна сказаць, што quick sort хутчэй за ўсё будзе лепшым выбарам.
Але чакайце, вы ж праграмуеце 8 гадзін у дзень, вырашаеце цікавыя і нетрывіяльныя задачы, і на новым месцы працы будзеце рабіць плюс-мінус тое ж самае. Але тым не менш, каб прайсці інтэрв'ю неабходна неяк дадаткова рыхтавацца, нават не навострываць штодзённыя навыкі, а вывучыць тое, што вам не спатрэбілася ні на бягучым месцы працы, ні наўрад ці спатрэбіцца на наступным. На вашы пярэчанні аб тым, computer science у нас у крыві, і разбудзі нас пасярод ночы мы абавязаны напісаць з зачыненымі вачамі на навалачцы абыход дрэва ў шырыню нават не прыходзячы ў прытомнасць, я адкажу, што калі я буду ўладкоўвацца ў цырк, і маім галоўным трукам будзе менавіта гэта - то мабыць так, я згодзен. Трэба гэты навык праверыць.
Але навошта правяраць нерэлевантныя бягучай працы навыкі? Толькі таму, што гэта стала модна? Таму што Google робіць так? Або таму, што вашаму будучаму тымлід прыйшлося вывучыць усе метады сартавання перад праходжаннем гутаркі і зараз ён лічыць што "кожны добры праграміст абавязаны ведаць на памяць рэалізацыю знаходжання паліндром ў радку".
Дык вось, вы не Google (з). Што можа сабе дазволіць Google, звычайныя кампаніі не могуць. Google, прааналізаваўшы дадзеныя сваіх работнікаў прыйшоў да высновы, што вось менавіта ў яго, менавіта яго задачамі добра атрымліваецца займацца інжынерам з алімпіядным мінулым. Больш за тое, будуючы працэс адбору, яны могуць сабе дазволіць закласці рызыку таго, што яны могуць не наняць некалькіх добрых інжынераў з-за таго, што яны не ўмеюць так лёгка пстрыкаць матэматычныя задачы. Але для іх гэта не бяда, ахвочых працаваць у Google шмат, пазіцыя закрыецца.
Зараз давайце выглянем у акно, і калі перад вашым офісам яшчэ інжынеры, якія жадаюць у вас працаваць, не разбілі намётавы лагер, а вашы распрацоўнікі гушчару шукаюць на stackoverflow якую чарговую Спринговую анатацыю трэба паставіць, а не тонкасці алгарытмаў ранжыравання, то, па ўсёй бачнасці, вам час задумацца над тым ці варта капіяваць Google.
Добра, калі ў гэты раз Google падвёў і не даў адказу, што ж рабіць? Правяраць роўна тое, што распрацоўшчык будзе рабіць на працы. Што вы шануеце ў распрацоўшчыках?
Складзіце крытэры каго вы хочаце наняць і распрацуйце тэсты, якія правяраюць менавіта гэтыя навыкі.
ThoughtWorks
Пры чым тут ThoughtWorks? Менавіта тут я для сябе знайшоў прыклад узорнай гутаркі. Хто такія ThoughtWorks? Калі коратка, то гэта High-End кансалтынгавая кампанія c офісамі па ўсім свеце пачынаючы ад Кітая, Сінгапура і заканчваючы Амерыканскімі кантынентамі, якая займаецца кансультаваннем у сферы распрацоўкі каля 25 гадоў, мае свой Science падраздзяленне, якое ўзначальвае Марцінам Фаулер. Калі вы пашукайце спіс з 10 кніг, якія must read для Software Engineer, то, мабыць, 2-3 з іх будуць напісаны рабятамі з ThoughtWorks, як напрыклад Refactoring By Martin Fowler і Building Microservices: Designing Fine-Grained Systems 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 з'яўляецца для выезду з NASA на аркуш на Марсе. Гэта пляцоўка, якая з'яўляецца сур'ёзна rectangular, мусяць быць навігацыі па кайданах з тым, што іх на board-камерах можна атрымаць дастатковы выгляд навакольнага тэрыторыя да аднаго да яго. Rover's position and locale is represented by combination of x and y co-ordinates and letter representing one of the four cardinal compass points. Платэза складаецца з ланцугу да ёмістасці навігацыі. У аналагічным становішчы можа быць 0, 0, N, які спосаб раскладу з'яўляецца ўнізе левы беражок і ручная вобласць. У сістэме кіравання стрэлкамі, NASA мае прамыя плацяжы. Можна выкарыстоўваць letters 'L', 'R' and 'M'. 'L' і 'R' мяркуюць памер 90 градусаў ніжэй або ладна адпаведна, без пераходу ад яго бягучага пункта. 'M' means move forward на адзін шнур point, і maintain the same heading.
Аб'ём таго, што квадратарны directly North from (x, y) is (x, y+1).
УХОД:
Першая лінія ўводу з'яўляецца найвышэйшым кіруючым парадкам, нізкім-ліфтам саветаў з'яўляецца 0,0.
Rest of input is information pertaining to rovers that have been deployed. Яе раўнікі маюць дзве лініі з паездкі. Першая лінія дае нам вялікае становішча, і дзвенныя лініі з'яўляюцца шэрагам убудаванняў імкнучыся шлях, каб explore plateau. Пазіцыя складаецца з двух integers і letter separated by spaces, corresponding to x and y co-ordinates and rover's orientation.
Усе стрэлкі будуць спыненыя ў той жа час, якія меры, што другі сярэдняга пачынаюць працаваць, каб запоўніць першую, чым было выканана.
Выхад:
Адукацыя для ўсіх аматараў павінна быць яе фінальнае ordinates and heading.
Заўвага:
Simply implementant requirements abo prove a vacuum cleaner works by writing unit tests for it.
Ствараючы любую форму карыстача, гэта не ад scope.
Адказваць, што праблема прытрымліваецца TDD (Test Driven Development).
У хуткім часе існуючы, мы больш з'яўляецеся аб якасці цвёрдых.
*Я не магу выкласці заданне, якое мне даслалі, гэта старое заданне, якое давалася некалькі гадоў таму. Але паверце, прынцыпова ўсё засталося гэтак жа.
Асобна жадаецца звярнуць увагу на крытэры адзнакі. Колькі разоў вам даводзілася сутыкацца з сітуацыяй, калі важныя для кандыдата рэчы, зусім не важныя пры праверцы і наадварот. Не ўсе думаюць гэтак жа, як вы, але многія могуць прыняць вашыя каштоўнасці і прытрымлівацца іх, калі іх дакладна прапісаць. Такім чынам, з крытэр адзнакі адразу зразумела што найважнымі навыкамі на гэтым этапе з'яўляецца
- 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, and 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 to mitigate bias. У Thoughtworks парнае праграмаванне - стандарт дэ-факта. І калі гэтую практыку можна прымяніць у іншых сферах, TW імкнецца гэта рабіць. На кожным этапе сумоўе праводзяць 2 чалавекі. Такім чынам, кожнага чалавека ацэньвае мінімум 8 чалавек, і TW імкнецца падбіраць інтэрв'ювераў з розным бэкраўндам, розных напрамкаў (не толькі тэхнароў) і падлогі.
У канчатковым выніку рашэнне аб прыёме на працу будзе прынятае на падставе меркавання як мінімум 8 чалавек, і ні ў каго няма права вырашальнага голасу.
Attribute-based hiring Замест таго, каб прымаць рашэнне на падставе "падабаецца не падабаецца" кандыдата, для кожнай ролі і для кожнага этапу распрацавана форма, якая ўключае ацэньваныя атрыбуты. Пры гэтым пры адзнацы вельмі раяць ацэньваць не досвед у вызначаным навыку, а здольнасць ужываць яго. Такім чынам, калі ў кандыдата не было магчыма ўжываць якія-небудзь скілы, як TDD, але тым не менш ён яго імкнецца прымяняць, слухае парады па правільным выкарыстанні - у яго ёсць усе шанцы прайсці інтэрв'ю.
Education Certificates не патрабуецца TW не патрабуе ад кандыдата абавязковых сертыфікатаў ці адукацыі ў Computer Science. Ацэньваюцца толькі ўменні.
Гэта першае інтэрв'ю, з тых, што я праходзіў у замежныя кампаніі, да якога мне не прыйшлося рыхтавацца. Пасля кожнага этапу я не адчуваў сябе выціснутым як лімон, а наадварот, я быў рады, што я магу прымяняць лепшыя практыкі, што людзі па той бок манітора цэняць гэта, і гэтак жа ўжываюць іх кожны дзень.
Па сканчэнні некалькіх месяцаў, магу сказаць, што чаканні апраўдаліся цалкам. Чым ThoughtWorks адрозніваецца ад звычайнай кампаніі? У звычайнай кампаніі вы зможаце знайсці добрых распрацоўшчыкаў і прыемных людзей, але ў TW іх канцэнтрацыя зашкальвае.
Калі вы хочаце далучыцца да ThoughtWorks, адкрытыя вакансіі можна паглядзець
Таксама прапаную звярнуць увагу на цікавыя вакансіі:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Інжынер-праграміст: , ,
Senior Data Engineer:
Аналітык якасці:
Infrastacture: , ,
(Хачу шчыра папярэдзіць, што спасылка реферальная, калі вы пройдзеце ў TW, то я атрымаю прыемны бонус). Выбірайце офіс па душы, не абавязкова абмяжоўвацца толькі Еўропай, у рэшце рэшт, кожныя 2 гады TW будзе шчаслівы перавезці вас у іншую краіну, т.я. гэта частка палітыкі ThoughtWorks, такім чынам культура распаўсюджваецца і ўсярэдніваецца.
Не саромейцеся задаваць пытанні ў каментарах ці прасіць мяне парэкамендаваць вас.
Калі тэма падалася цікавай, я напішу пра тое, як працуецца ў ThoughtWorks і як жывецца ў Сінгапуры.
Крыніца: habr.com