Как да се подготвите за техническо интервю - съвети и трикове, които да ви помогнат да се представите най-добре

А, интервю за кодиране.

"Ужасявай го. Бягай от него. Съдбата пристига все пак." - Танос 2018

Добре, може би това е малко драматично, но не познавам никого, който е развълнуван да премине през процеса на интервю. Процесът на търсене на работа / интервю е изтощителен в най-добрия случай и много други неща в най-лошия.

Много хора изучават трикове и тактики за интервю (и аз ще ви дам и няколко от тях), но повечето хора не мислят за мисленето си, за да отидат на интервюто.

Вашето мислене задава тона на това как ще видите и оформите вашата ситуация. Влезте с правилното мислене и ще можете да разберете и да се ориентирате във всичко, което ви е хвърлено. Влезте с разпръснат или плах ум и ще се окажете разтърсени и очукани.

Вие сте и интервюиращия

Едно нещо, което повечето хора често забравят, е, че вие ​​сте и интервюиращия.

Да, интервюирани ли сте в тази компания, но също така интервюирате компанията, за да видите дали те са подходящи за вас.

Какви са ценностите на тази компания? Каква е тяхната работна етика? Какво ценят хората?

Преминаването на събеседването е важно, но искате ли да работите в тази компания, ако преминете?

Понякога просто се нуждаем от работа - всяка работа - и затова не искам да минимизирам само получаването на работа. Но ако можете, направете крачка назад и помислете как тази работа ще повлияе на кариерата ви в дългосрочен план. Да кажеш „да“ на работа означава да кажеш „не“ на дузина други - плащаш големи алтернативни разходи, като кажеш „да“.

Така че това е първото нещо, което трябва да запомните: това не е еднопосочна динамика на мощността. Понякога може да се чувства така, но тук имате някакъв контрол и имате опции. Това дава възможност.

Видове интервюта

Добре, така че ние също оценяваме компанията въз основа на хората, с които взаимодействаме в процеса на интервю, така че какво правим с тази информация?

Е, има няколко различни вида технически интервюта. Тези типове интервюта ни казват много за мисленето на компанията и какво е да работиш там. Разбивам различните видове по този начин:

  • Бяла дъска
  • Предизвикателство на кода (въпроси или алгоритми за компютърни науки)
  • Предизвикателство на код (разумен проблем с кодирането)
  • Вземете проект у дома

Страшната бяла дъска

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

Не че кодирането на бяла дъска е лошо само по себе си, но че бялата дъска е толкова далеч от работата, която всъщност вършим като програмисти, които работят на компютри всеки ден. Бялата дъска е непохватна за писане, редактиране и не ви дава обратна връзка - няма автоматично довършване, няма подчертаване на синтаксиса и не можете да отворите Google, за да търсите референциите на стандартната библиотека.

На всичкото отгоре много места, които използват интервюиране с бяла дъска, също задават определен набор от въпроси за интервю, които, честно казано, са безполезни за 99% от програмите там. Това са страховитите алгоритми за компютърни науки: обръщане на двоично дърво, намиране на най-краткия път в графика и т.н.

Проблемът с тези въпроси е, че те просто не се появяват в реалния живот като програмист. Ако интервюирате в Amazon или Facebook, разбира се, може би те имат някаква стойност там, но по-голямата част от хората никога няма да се сблъскат с този проблем в кариерата си. И ако го направят, те просто ще използват някакъв пакет или библиотека, които вече са внедрили тази функционалност.

И така, какво можем да направим с дъските? Е, ето какво бих направил: направете всичко възможно, използвайте съветите и триковете, описани по-долу, и сериозно преценете дали тази практика на интервю е симптом на по-голям проблем с манталитета в компанията.

Кодекс предизвикателства

Ако имате достатъчно късмет да избегнете бялата дъска, повечето места ще (и вероятно би трябвало) ще ви помолят да направите някакво предизвикателство за код. Отново това може да изглежда като еднопосочна динамика на мощността, но това кодово предизвикателство всъщност е добро за вас. Това е мястото, където можете да блеснете и да покажете своята техническа компетентност и според моя опит това драстично се отразява на способността ви за преговори, когато става въпрос за длъжност и заплащане.

Преди да влезем в конкретните съвети, трябва също така да сме наясно, че това, че сте избегнали бялата дъска, не означава, че все още няма да получите въпроса за алгоритъма на компютърните науки тук - само на компютър. Ако случаят е такъв, просто поемете дълбоко въздух и използвайте съветите и триковете по-долу. Ще го преминете.

Ако имате достатъчно късмет, за да избегнете бялата дъска и въпроса за CS, вероятно сте получили разумно предизвикателство за кодиране. За мен това са въпроси като:

Напишете функция, която приема брой цента (USD) като цяло число, по-малко или равно на 100, и отпечатва най-малкото количество монети, необходимо за представянето му.

50 => 2 четвърти

11 => 1 стотинка и 1 стотинка

7 => 1 никел и 2 стотинки

Получих и въпроси, които изглеждат като въпроси за CS, но всъщност не са толкова лоши. Например „внедрете двойно свързан списък“. На пръв поглед това изглежда като проблем с CS поради частта "двойно свързан списък", но това, което интервюиращият всъщност искаше, беше код, който реализира същото поведение като двойно свързания списък - не използвах указатели и адресиране обекти в паметта - просто имитирайки същото поведение. В този случай това се оказа доста просто предизвикателство.

И това ме води до първия ми съвет:

Съвет №1: Задайте уточняващи въпроси

В предизвикателството на двойно свързания списък ми беше даден празен файл на Ruby (интервюирах за работа в Ruby) и празен тестов пакет. Нещо като това:

class DoublyLinkedList end 

(Ако не сте запознати с Ruby - не се притеснявайте. Кодът тук ще бъде лесен за разбиране. Той е тук, за да илюстрира цялостните точки.)

И така, двойно свързан списък, а? Може би знаете какво е това, или може би не. Ако не го направите: задайте въпроси. Това е първата клопка, която трябва да избягвате. Ако не разбирате проблема или какво искат, продължете да задавате въпроси, докато не го разберете.

Виждал съм интервюирани да слизат по грешната заешка пътека и интервюиращият просто им е позволявал - през цялото време мълчаливо ще ги проваля. Въпреки че не съм съгласен с тази практика, уверете се, че работите с правилния проблем.

Аз идвам от компютърни науки, така че знаех, че двойно свързан списък означава списък, който има указател към a headи tailвъзел - където всеки възел също сочи към своя nextи previousвъзел.

Сега, въпреки че знаех това, какво направих? Казах го на глас и попитах дали това е вярно. Въпреки че си мислех, че знам какво да правя, бях абсолютно сигурен, че го знам.

След като мислите, че разбирате проблема, повторете разбирането на интервюиращия, за да може той да ви коригира или насочи.

Следващото нещо, което направих, беше да задам друг въпрос: „Мога ли да използвам масив за възлите?“ И написах нещо подобно:

class DoublyLinkedList def initialize @nodes = [] end end 

(Ако не сте запознати с Ruby, това е просто инициализатор или конструктор, в който правя нова променлива, наречена @nodesset to a empty array.)

Но, интервюиращият ми каза, не, не можех да направя това - което има смисъл. Ако бях използвал масив, щеше да победи цялата цел на упражнението, което изгражда фалшивите "указатели" между възлите.

И момче, радвам ли се, че попитах. Не исках да рискувам интервюиращият да ми позволи да използвам масива и след това да ме провали.

Така че няма масив - добре какво да правя сега? Ето съвет №2:

Съвет # 2: Твърдо кодирани -> Тъпи -> По-добри

Когато се сблъскате с предизвикателство за кодиране, работете с проблема в следния ред: твърдо кодиран -> тъп -> по-добър -> още по-добър (ако времето позволява).

В моя опит, когато съм интервюиран и интервюирам други разработчици, откривам, че повечето хора се опитват да правят твърде много наведнъж.

Когато правите твърде много наведнъж, лесно е да направите грешки (които няма да хванете поради наличието на InterviewBrain ™). Така че започнете просто - най-простото, което всъщност можете - кодирано - и продължете напред.

И така, имам празен клас Ruby, как мога да кодирам нещо, за да продължа напред? Погледнах празния си тестов пакет и видях, че има функция, headкоято връща първия възел в списъка, така че нека опитаме това:

class DoublyLinkedList def head 'A' end end 

Направих headфункция и кодирах с главна буква "А" като низ и проведох този тест. Мина.

Това супер лесно ли е? Прекалено очевидно ли е? Да! Но този код прави две много важни неща:

  • Позволява ми да стартирам тестовете и да тествам, че моята настройка работи (елиминиране на глупави или синтаксични грешки)
  • Получава ми бърза победа - което повишава самочувствието ми

Има безброй интервюта, които съм виждал, когато някой прави малка грешка в началото, развълнуван е и след това прекарва по-голямата част от интервюто, опитвайки се да се възстанови и да поправи всичко, което не е наред.

Не подценявайте стойността на бързите печалби за вашата увереност. Натрупването на малки печалби ще ви подтикне през интервюто.

Добре, имаме кодиран низ 'A'. Сега как да превърнем това в тъпо решение? Е, какво ще кажете да направите тази буква "А" в хеш (или карта)?

class DoublyLinkedList def head { value: 'A' } end end 

Това е малко по-добре. Сега вместо един символен низ нашият "възел" е представен като хеш със valueсвойство. Преминахме от твърдо кодиран до тъп. Сега как можем да го направим по -добър? Е, какво ще кажете да въведем нашия headуказател в списъка?

class DoublyLinkedList def initialize @head = { value: 'A' } end def head @head end end 

Какво променихме тук? Тук добавяме обратно нашия инициализатор и създаваме нова променлива, наречена @head, и използваме тази нова променлива в нашата headфункция. Това започва да изглежда като някакъв реален код.

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

Ако мислите, че този подход ще изглежда странен за потенциалния интервюиращ, ето следващия съвет и този е много важен:

Съвет # 3: Говорете. На глас.

През цялото време, когато правите предизвикателство за кодиране, трябва да говорите - на глас.

Кажете всичко, което мислите - всичко.

(Е, всичко свързано с програмирането.)

Ето какво е: достигането до правилно решение е важно да, но също толкова, ако не и по-важно, е да покажете своя мисловен процес. Интервюиращият иска да знае как мислите - как решавате проблеми. Можете да направите това, като споделяте всичко, което мислите на глас.

Всеки интервюиращ в даден момент е бил интервюиран - те знаят за InterviewBrain ™ и че дори прости неща могат да станат трудни в интервюто. Добрите интервюиращи не се интересуват, че сте получили решението на 100% правилно - те просто искат да знаят, че притежавате добри способности за критично мислене. Единственият начин да направите тези вътрешни мисли видими, е да ги кажете на глас.

Ако никога преди не сте правили това, може да искате да го практикувате, защото е жизненоважно за заковаването на интервюто.

За да ви дам няколко практически примера, ето няколко неща, които казвам всеки път, когато съм интервюиран:

„Добре, нека само да закодираме тази стойност и да се уверим, че настройката ни работи.“ „Нека първо вземем тъпа версия на тази работа и да я направим по-добра.“ „Засега ще го направя така и ако имаме време да се върне и правя. "" Добре, така че се нуждаем от функция, която приема масив, прави X и се връща. "

В някои сценарии тези интервюта могат да започнат да се чувстват като сесии за програмиране по двойки.

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

Ето важен съвет за това:

Съвет # 4: Останете в логичен поток

Сега ще призная: това понякога може да бъде трудно.

Ако сте на интервю и има проблем или грешка с кода ви, мозъкът ви отчаяно иска да разбере какво не е наред, но не бъдете прекалено отчаяни, че започнете да разбивате кода или мисловния си процес.

Виждате ли, точно както интервюиращият иска да види как разграждате даден проблем, те също искат да видят как отстранявате грешки в даден проблем. Това е също толкова важно, колкото и обяснението на вашия мисловен процес. Опитайте всичко възможно, за да останете в логичен поток и да избегнете разбиването на кода или вашите идеи.

Ако върви добре

Така че предизвикателството върви добре и вие нокаутирате проблема и всички лесни неща.

Сега какво? Как се преминава от преминал към смачкан?

Това е изключително важна част от интервюто, защото тук получавате по-голямата част от лоста си за договаряне на ниво работа и обезщетение. И съветът е:

Съвет №5: Покажете какво знаете

Работите с предизвикателството, говорите на глас и се справяте добре. Следващото нещо, което трябва да търсите, са възможности да покажете своите знания и опит.

Това ли е мястото в кода, където можете да изпратите имейл? Споменете, че вместо това трябва да се прави във фонов работник (вероятно дори няма да се налага да го прилагате).

Работите ли по логика за валидиране в модел? Говорете за това как бихте добавили и ограничения на базата данни, за да осигурите целостта на данните. Какви индекси бихте добавили? Как бихте внедрили миграциите, за да предотвратите престой?

След като получите вашето твърдо кодирано -> тъпо -> по-добро решение, говорете за това как бихте го рефакторирали, като му дадете повече време. Бихте ли създали модул за това? Ами обект на услуга? Какво ще кажете за поставянето на част от тази логика във фонов режим? Обсъдете компромисите.

Защо това е толкова важно?

Повечето въпроси за интервю са насочени към най -ниския общ знаменател - означаващ най-основните изисквания на работата. Предизвикателството или самите въпроси обикновено не са предназначени да тестват върха на нечие умение . Интервюто вероятно няма да извади информацията от вас, така че трябва да предоставите тази информация.

Така че, докато говорите през мисловния си процес, споменете всички неща, които бихте включили в реално приложение или кодова база, и ги обсъдете.

Допълнителни съвети и трикове

Така че трябва да подходите към интервюто си и да се справите с всяко предизвикателство, което сте получили.

Ето няколко допълнителни трика, които понякога могат да се използват за леки предимства.

Трик # 1: Познайте често срещаните проблеми

Има няколко често срещани проблема, които често се появяват в интервюта (особено на дъски). Трябва да сте запознати с тези проблеми, защото те са нещо като въпроси, за които знаете, че ще бъдат на теста.

Две от основните са FizzBuzz и решаването на последователността на Фибоначи (уверете се, че ги знаете).

Сега едно предупреждение: не винаги искат да потуши запомнени решение в интервю. Това може да върви само зле (и съм бил свидетел на това). Искате обаче да сте запознати с решението и да можете да го пресъздадете от нулата.

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

Трик # 2: Обикновено е добре да погледнете документите

Във всички интервюта, в които съм бил или в част от тях, никой не се е интересувал дали ще потърсите стандартната библиотека или пакетните документи. Интервюиращите не са добре, когато търсите отговора (така че бих избегнал StackOverflow), но консултирането с референциите обикновено е честна игра. Когато се съмнявате, вижте Съвет №1 и поискайте разяснения.

Трик # 3: Внимавайте за визуални сигнали

Това е може би любимият ми съвет / трик. Не е най-полезното, но е някак забавно. Едно от моите интервюта направих дистанционно и използвахме програма за споделяне на екрана и можех да видя лицето на интервюиращия в горния десен ъгъл на екрана си.

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

Отново не е много, но може да е полезно. :)

Трик # 4: Ако сте отдалечени, направете добра настройка

Говорейки за отдалеченост, ако сте отдалечени, опитайте се да направите най-добрата настройка, която можете. Това означава включена камера (ако е възможно настройка там, където гледате направо), добър интернет, включен компютър, тиха стая, чаша вода наблизо и т.н.

Тези неща не трябва да влияят на резултата от интервюто, но няма нужда да дразните интервюиращия или да си създавате допълнителен стрес от проблеми с интернет или шум.

Трик # 5: Бъдете персонажи!

Последният ми трик за вас е да бъдете персонализирани.

В интервюто си бъдете някой, с когото бихте искали да работите. Покажете им най-доброто си аз.

Интервютата могат да бъдат плашещи и разработчиците обикновено са по-тихи и по-резервирани хора, но трябва да покажете на хората, с които общувате, „Хей, аз съм забавен и приятен човек, с когото да работя“.

Не те моля да бъдеш някой, който не си. Но вие не искате да бъдете, според един от близките ми приятели, който непрекъснато интервюира хора, „морско същество“.

Бонус трик # 6: Направете всички други подготвителни интервюта (ако искате)

Ако се чувствате недостатъчно подготвени или това е първото ви техническо интервю, направете подготвителна работа, докато се почувствате комфортно.

Четете книги като Cracking the Coding Interview или практикувайте алгоритми и пъзели на HackerRank.

Прочетете другите страхотни публикации в News News за интервюиране.

Ако интервюирате за роля на пълен стек, бъдете готови да настроите нов проект или тестов файл с тестов пакет от нулата.

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

В крайна сметка: това е просто интервю.

В крайна сметка това е, което е.

Ще изпълнявате това, което представяте.

Ще бъдете интервюирани от човека, с когото ще бъдете интервюирани.

Процесът им на интервю ще бъде процес на интервю.

Може би сте имали почивен ден - може би интервюиращият е имал почивен ден.

След това, ако се чувствате смутени, победени или нещо друго - поемете дълбоко въздух и го оставете! Не позволявайте на мозъка ви с гущери да ви тежи. Лошото интервю не е краят на света. Кариерата ви не е съсипана, репутацията ви не е разрушена и животът ви не е съсипан.

Това е просто интервю. Учете се от него, адаптирайте се и бъдете по-добри следващия път.

Добре е да си нервен

Повечето хора (включително и аз) се изнервят преди неща като интервюта, беседи или презентации.

Преди си мислех нервността като нещо лошо - нещо, което не исках. И колкото и пъти да си казвах „не се изнервяй“ - познайте какво: това просто ме изнерви!

Научих се да преосмислям как гледам на нервите. Нервността е тялото ми, което се подготвя за битка - тази първична борба или реакция на полет.

Но както казахме преди: това е просто интервю. Няма тигър, който да ми се прокрадва в стаята за интервюта. Този първичен отговор не е необходим.

Започнах да се преквалифицирам, за да възприемам нервността като нещо добро. Това означава, че тялото и усетът ми се повишават, за да мога да постигна най-доброто представяне, което мога да събера.

Така че, прегърнете нервите. Те просто ви подготвят да се представите най-добре.

Интервюирането е умение

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

Така че не бийте себе си, ако не се представяте така, както бихте се надявали. Продължавайте да учите и продължавайте да практикувате - ще стигнете дотам!

Ако имате някакви въпроси или коментари, не се колебайте да се свържете с мен в Twitter и ако искате повече информация как да се подготвите за кариера за развитие, пиша такива неща в моя блог.

Благодаря за четенето!

Джон