Як відповісти на інтерв'ю Whiteboard Coding англійською мовою

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

Ключовий словник

** Роз’ яснювальний запит** — запитання, яке ви задайте перед написанням будь- якого коду, щоб підтвердити точний обсяг, формат вводу і краї випадків, які очікує співбесідник, замість того, щоб вгадати і розв’ язати неправильну проблему.

• “Перед тим, як я почну, я б хотів задати прояснююче запитання: чи може вхідний масив містити дублікати, чи гарантовано, що всі елементи є унікальними?” *

** Роздуми уголос ** — розповідь про ваші думки під час роботи над проблемою, щоб співбесідник міг слідкувати за вашою логікою навіть до того, як на дошці з’ явиться якийсь код. “Я думаю вголос: мій перший інстинкт - це підхід грубим способом з вкладеними петлями, але це O(n²), тому давайте подивимося, чи геш-карта приведе нас до O(n).”

** Розмова через компроміс ** - явне порівняння двох підходів, назвавши їхні витрати і вигоди, а не мовчки вибирати один і сподіватися, що інтерв’юер погодиться.

• “Говорячи про компроміс: рекурсивне рішення є більш читабельним, але він ризикує переповненням стека на дуже глибоких вхідних даних, тому я схиляюсь до ітеративної версії замість цього.” *

** Розповідь про виправлення вади ** — опис того, що сталося не так і як ви це виправляєте під час зневаджування, замість тихого редагування коду доки він не запрацює. “Описуючи це: мій цикл виконується один раз більше, тому що я використав <= замість <, тому я виправлю граничну умову тут.”

Звичайні фрази

• «Дайте мені переконатися, що я правильно розумію проблему — чи можете ви підтвердити [деталь]?»
• «Мій початковий підхід був би [X], але дозвольте мені подумати, чи є щось більш ефективне»
• «Я почну з рішення грубими силами, а потім оптимізую, якщо у нас є час»
• «Дозвольте мені прослідкувати це з невеликим прикладом, щоб перевірити мою логіку»
• “Я думаю, що є кращий випадок, якого я не маю — дозвольте мені розглянути [порожній вхід / від’ємні числа / дублікати].”

Приклади висловлювань

Відкриваю з пояснюючим питанням:

• « Швидке питання для пояснення перед тим, як я занурюся у тему: чи має функція обробляти порожній список, чи я можу припустити, що вхідні дані завжди містять принаймні один елемент? » *

Вибір підходу: “Я збираюся використовувати тут підхід з двома вказівниками, оскільки масив впорядкований — це повинно привести нас до лінійного часу замість квадратичного підходу, який я спочатку розглядав.”

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

Завершуючи підсумком складності:

• “Так що, щоб підсумувати: цей процес виконується за O( n log n) часу через сортування, і використовує O( n) додаткового простору для геш- карти. Я думаю, ми могли б обміняти частину цього простору на час, якщо це потрібно — приємно обговорювати»

Професійні поради

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

Практичні вправи

1. Записати себе, як ви розповідаєте про розв’ язання простої задачі (наприклад, про те, як повернути рядок) повністю уголос, включаючи принаймні одне питання, яке пояснює цю задачу.
2. Напишіть два речення, у яких порівнюється рекурсивний і ітеративний підходи до однієї і тієї ж задачі, використовуючи мову компромісів.
3. Практикую фразу “дозвольте мені відступити і переглянути” доки не відчуєте, що це природно сказати під тиском часу.

Наприклад, мова опису: мова, що використовує описову лексику

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

Розглянемо цей сценарій: Вас попросили розробити систему кешування для веб-сайту електронної комерції. Замість того, щоб сказати: « Добре, я використаю геш- таблицю », що технічно правильно, але не має контексту, спробуйте щось на зразок: « Давайте розпочнемо з розгляду наших шаблонів доступу. Ураховуючи, що користувачі часто отримують інформацію про продукт на основі ID, геш-таблиця пропонує O (1) середній час пошуку - це значно зменшить навантаження бази даних і поліпшить час відповіді на звичайні запити. “Зауважте додавання “розглядаючи наші шаблони доступу” - обрамлення рішення з обґрунтуванням демонструє аналітичне мислення. Пізніше, під час написання коду, якщо ви вирішите використовувати правила вилучення кешу з найменш використовуваних (LRU), не просто скажіть: « Я використовую LRU ». Замість цього вкажіть * чому *: « Щоб зменшити час завантаження сторінок і забезпечити постійну продуктивність, ми реалізуємо стратегію кешування LRU, яка буде надавати пріоритет найчастіше завантажуваним елементам у пам’ яті ». Фрази на зразок « зменшити час завантаження сторінок » мають набагато більший вплив, ніж просто вказати алгоритм.

Іншою поширеною ситуацією є, коли вас просять обговорити потенційний компроміс - можливо, між використанням пам’ яті і швидкістю отримання. Замість того, щоб сказати: « Це може використовувати трохи більше пам’ яті », спробуйте сказати: « Ми спостерігаємо невелике збільшення сліду пам’ яті через більший розмір кешу, що безпосередньо пов’ язано з покращенням швидкодії читання. Ми можемо уважно стежити за цим і налаштовувати параметри кешу, якщо побачимо будь- який шкідливий вплив на інші компоненти системи. ” Підтвердження кореляції (« безпосередньо корелює ») показує, що ви думаєте про більш широкі наслідки для системи. Аналогічно, коли ви отримуєте коментар перегляду коду, наприклад, «Розгляньте використання більш описової назви змінної», відповідайте: «Зрозуміло - я ціную відгук. Я спочатку хотів бути коротким, але ти маєш рацію; ясність є найважливішою. Я перейменую x на productDetails, щоб поліпшити читабельність і підтримку. “Показуючи готовність приймати відгуки і пояснити свої міркування, будується відносини і демонструється професіоналізм.

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