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

Ах, інтерв'ю з кодуванням.

"Страшний. Біжи від цього. Доля все одно прибуває". - Танос 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і previousnode.

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

Коли ви вважаєте, що розумієте проблему, повторіть своє розуміння інтерв’юера, щоб він міг вас виправити чи направити.

Наступним, що я зробив, було задати ще одне запитання: "Чи можу я використовувати масив для вузлів?" І я набрав щось подібне:

class DoublyLinkedList def initialize @nodes = [] end end 

(Якщо ви не знайомі з Ruby, це лише ініціалізатор або конструктор, де я створюю нову змінну з @nodesнабором порожній масив.)

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

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

Тож немає масиву - ну що мені робити зараз? Ось порада №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функції. Це починає виглядати як справжній код.

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

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

Порада No3: Поговоріть. Вголос.

Увесь час, коли ви виконуєте завдання кодування, ви повинні говорити - вголос.

Скажіть все, про що думаєте - все.

(Ну, все, що пов'язане з програмуванням.)

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

Кожен інтерв’юер в якийсь момент був співбесідником - вони знають про InterviewBrain ™ і що навіть прості речі можуть стати важкими в інтерв’ю. Хорошим інтерв’юерам не байдуже, що ви на 100% отримали рішення - вони просто хочуть знати, що ви володієте хорошими здібностями критичного мислення. Єдиний спосіб зробити ці внутрішні думки видимими - це вимовити їх вголос.

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

Щоб навести кілька практичних прикладів, ось що я кажу кожного разу, коли я беру інтерв’ю:

"Гаразд, давайте просто встановимо це значення і переконаймося, що наше налаштування працює." "Давайте спочатку отримаємо тупу версію цієї роботи і покращимо її." "Я зараз це зроблю так, і якщо у нас буде час, повернемося і "." "Гаразд, тому нам потрібна функція, яка приймає масив, робить X і повертається."

У деяких сценаріях ці інтерв’ю можуть почати здаватися парними сеансами програмування.

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

Ось важлива порада для цього:

Порада No4: Залишайтеся в логічному потоці

Тепер я визнаю: це часом може бути важким.

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

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

Якщо це буде добре

Отже, виклик іде добре, і ви вибиваєте проблему та всі прості речі.

Що тепер? Як ви переходите від пройденого до подрібненого?

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

Порада No5: Покажіть, що ви знаєте

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

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

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

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

Чому це так важливо?

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

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

Додаткові поради та хитрощі

Тож саме так слід підходити до співбесіди та вирішувати будь-який виклик, який вам поставлять.

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

Фокус No1: Знайте загальні проблеми

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

Два з основних - FizzBuzz та вирішення послідовності Фібоначчі (переконайтеся, що ви їх знаєте).

Тепер слово попередження: ви не завжди хочуть , щоб придушити запам'ятали рішення в інтерв'ю. Це може піти лише погано (і я був свідком того, що це сталося). Однак ви хочете бути ознайомленим із рішенням - і мати можливість відтворити його з нуля.

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

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

У всіх інтерв'ю, в яких я брав участь або в якійсь із них, нікому не було байдуже, якщо ви шукаєте стандартну бібліотеку або пакувальні документи. Інтерв’юери не в порядку з тим, що ви шукаєте відповідь (тому я б уникнув StackOverflow), але консультування з посиланнями зазвичай є чесною грою. Якщо ви сумніваєтесь, див. Пораду №1 і попросіть пояснень.

Фокус No3: стежте за візуальними сигналами

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

Краєм ока я помітив, коли кодував, що інтерв’юер кивав їм головою. Ах ха! Трохи візуальної підказки, щоб знати, що я був на правильному шляху.

Знову ж це не багато, але це може бути корисно. :)

Хитрість No4: Якщо ви віддалений, гарне налаштування

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

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

Фокус No5: Будьте приємним!

Мій останній фокус для вас - бути привабливим.

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

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

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

Бонусний фокус №6: Виконайте всі інші підготовчі до співбесіди (якщо хочете)

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

Читайте такі книги, як Cracking the Coding Interview або практикуйте алгоритми та головоломки на HackerRank.

Прочитайте інші чудові публікації на News Developer про співбесіду.

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

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

Врешті-решт: це просто інтерв’ю.

Зрештою, це те, що воно є.

Ви будете виконувати те, що ви виконуєте.

З вами буде проводити співбесіду особа, з якою ви брали інтерв’ю.

Процес їх співбесіди буде процесом співбесіди.

Можливо, у вас був вихідний - можливо, інтерв’юер мав вихідний.

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

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

Це нормально нервувати

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

Раніше я думав про нервозність як про погану річ - про те, чого не хотів. І скільки б разів я не казав собі "не нервуй" - відгадай що: це просто мене нервувало!

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

Але, як ми вже говорили раніше: це просто інтерв’ю. У кімнаті для інтерв’ю тигр не підкрадається до мене. Ця первинна відповідь не потрібна.

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

Отже, обійміть нерви. Вони просто готують вас до найкращих результатів.

Співбесіда - це вміння

Зрештою, співбесіда - це вміння. Для засвоєння потрібно трохи навчання та багато практики.

Тож не бийте себе, якщо ви виконуєте не так, як сподівались. Продовжуйте вчитися і продовжуйте практикуватися - ви доберетесь!

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

Дякуємо за читання!

Джон