Як перемогти на співбесіді. Кілька дуже корисних порад для розробників

Від автора: я розробив і провів десятки співбесід з програмування. Тут я розповім, як мене обіграти



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

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


Ти більше, ніж просто машина для кодинга

Частина 1. Програмування на дошці
Хто взагалі в цьому світі програмує на дошці? Справді, серйозно. Тим не менш, я попрошу вас зробити це. Не хвилюйтеся, я не зійшов з розуму. Я знаю про Google і що дошка погано справляється з автодополнением. Мене це не хвилює. Я перевіряю не те, наскільки красивий код ви пишете на дошці, а дещо інше.

Коли ви отримаєте роботу, вам ніколи не доведеться програмувати на дошці. Але я гарантую, що настане момент, коли ми всі будемо ламати голову над проблемою перед дедлайном, коли ми вимотані в край, на нас всі зляться, а на кону стоїть наша робота і репутація. Коли настане такий момент, ми підемо в переговорну, столпимся біля дошки і будемо з'ясовувати, що робити. Швидко.

«Я перевіряю не те, наскільки красивий код ви пишете на дошці»
Хоча мені не потрібен програміст, який пише красивий код на дошці, але мені потрібен той, хто здатний швидко думати на ходу, під тиском, в одній кімнаті з іншими. Проблема в тому, що якщо ви не розумієте, що саме я перевіряю, то все зробите правильно. Ви збираєтеся довести, що ви справжній ніндзя в програмуванні на дошці. Це нерозумно. Нікому не потрібен ніндзя в програмуванні на дошці. Ось як мене перемогти:

1. Вербализуйте свої припущення і постарайтеся їх підтвердити

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

2. Думайте вголос

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

3. Не бійтеся попросити допомоги

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

4. Чесно покажіть свої здібності і досвід

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

Частина 2. Програмування на комп'ютері


На відміну від дошки, якщо я запрошую вас за комп'ютер і прошу написати код, то я справді перевіряю, як добре ви програмуєте. Точніше, я перевіряю ваше вміння дотримуватися правила.

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

Паліндром — це число, буквосполучення, слово або текст, однаково читающееся в обох напрямках. Дозволяються коригування до прописних буквах, пунктуації і прогалин. Деякі приклади англійською: «A man, a plan, a canal, Panama!», «Amor, Roma», «race car», «stack cats», «step on no pets», «taco cat», «put it up», «it Was a car or a cat I saw?» і «No 'x' in Nixon».

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

Ваша функція повинна приймати рядок як параметр і повертати логічне значення (true, якщо рядок є паліндромом, і false, якщо він не є).

Припускайте, що цей код буде поставлений в реальну систему на робочому сервері, пишіть відповідно з цим.
Коли я пропоную таке завдання на співбесіді, першим ділом я дивлюся, ви мені задасте додаткові питання чи ні. Як я вже говорив раніше, кращі програмісти розуміють, що допущення — це саме те, що вбиває вас в цьому бізнесі. Моя порада кожному, хто отримав інструкції для написання коду, — зробити паузу і подумати, які допущення слід зробити для того, щоб виконати завдання (вони завжди є) і знайти спосіб підтвердити або прояснити ці припущення. Я розумію, що під час виконання завдання, люди йдуть у «тестовий режим» і думають, що їм заборонено говорити. Я ж вважаю, що ви почнете з питання інтерв'юера: «Мені дозволено поставити вам одне або два питання, щоб прояснити деякі припущення?» (Я завжди відповідаю «так»), і тоді ви отримаєте ВЕЛИЧЕЗНУ перевагу.

Хороші питання для цієї конкретної задачі:

  • Тут клієнтський JavaScript або на стороні сервера?

  • В контексті даної задачі може вважатися порожній рядок валидной рядком на вході?

  • Потрібно обробляти символи Unicode?
Далі я дивлюся, наскільки добре ви прямуєте інструкцій. Наприклад, я визначив рядок як параметр і логічне значення як результат. Це те, що видає програма?

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

  • В коді повинні бути коментарі.

  • Потрібно передбачити обробку помилок або хоча б ведення логів.

  • Програму слід обкласти тестами.

  • Програма не повинна давати збої ні в якому разі.

  • Код повинен бути легко читаємо і говорити сам за себе (легко зрозумілі імена змінних, гарне форматування, в ідеалі — без складних конструкцій і дефектів («lint free»)
Якщо ви раніше бачили код тільки в підручниках і посібниках, то не знаєте, що означають перераховані вище речі. Моя порада: подивіться на код популярних open source проектів. Особливо тих проектів, які розвиваються вже давно і стабільні. Для JavaScript цілком хорошим прикладом буде код jQuery на GitHub.

Далі, мені цікаво подивитися, як ви розумієте слово «ефективний» в поєднанні з «продакшн системою». Якщо у вас є досвід, то ви розумієте, що поняття «ефективний» для програми в продакшне означає три речі:

  1. Швидко працює.

  2. Не займає пам'ять, коли вона їй не потрібна.

  3. Стабільна і легко підтримується.
Ви повинні розуміти, що пункт № 3 іноді означає деякий шкоди для пунктів № 1 і № 2.

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

Щодо тестів я хочу побачити, що ви передбачте багато тестів, але всі вони будуть перевіряти дійсно різні сценарії. Перевірка «mom», «dad» і «racecar» надлишкова, це все один і той самий тест. Я також очікую побачити, що ви включите тести на міцність (краш-тести); тести яких-небудь рядків, які не є паліндромами. Розглядайте прикордонні випадки, перевіряйте нуль або число. Перевіряйте порожній рядок або набір спеціальних символів.

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

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

Для розробників середнього рівня хочеться бачити якісь коментарі та хороший стиль програмування. Хочеться бачити ефективне рішення і, можливо, якийсь тест.

Для провідних програмістів хотілося б бачити оптимальне рішення, чистий і підтримуваний код, обробку помилок, коментарі, повний набір тестів. Наприклад, якщо ви застосовуєте console.log() JavaScript на стороні клієнта, то додайте коментар, який дає зрозуміти, що ви знаєте про необхідність підтримки логгирования також на стороні сервера.

Ось приклад хорошого коду, написаний на JavaScript.

'use strict'; // avoid ambiguity and errors sloppy

/**
* Tests wether or not a given string is a Palindrome
* @param {string} stringToTest - the string to test.
*/
function isPalindrome(stringToTest) {
var start = 0,
end;

// make sure we have a string.
if (typeof stringToTest !== "string") {
// throw if we didn't get a string
throw new TypeError("isPalindrome() expected a string, but got " +
Object.prototype.toString.call(stringToTest) + " instead!");
}

// normalize string by lowercasing and removing non-word characters
stringToTest = stringToTest
.toLowerCase()
.replace(/[^a-z0–9]/ig, ");

if (stringToTest.length === 0) {
// warn if we have no valid characters to test
console.log("No valid characters to test, treated as empty string" +
"\nStack: \n" + new Error().stack);
return true; // an empty string is a palindrome.
}

end = stringToTest.length - 1;
// compare characters from outside in. stop when we get to the middle.
while (start < end) {
if (stringToTest[start] !== stringToTest[end]) {
return false;
} else {
start++;
end--;
}
}

// if we get here, it's a palindrome
return true;
}

// tests (should be in a окремі file using a test framework)
console.log(isPalindrome("something that is not a palindrome") + " = false");
console.log(isPalindrome("something that is \n not a palindrome") + " = false");
console.log(isPalindrome("race \n car") + " = true");
console.log(isPalindrome("") + " = true + warn");
console.log(isPalindrome(" ") + " = true + warn");
console.log(isPalindrome("1221") + " = true");
console.log(isPalindrome("0") + " = true");
console.log(isPalindrome("racecar") + " = true");
console.log(isPalindrome("No 'x' in Nixon!") + " = true");
console.log(isPalindrome("~~!~!~") + " = true + warn");
console.log(isPalindrome("Momsie") + " = false");
console.log(isPalindrome(12)); // blow up
console.log(isPalindrome(undefined)); // blow up
console.log(isPalindrome(null)); // blow up

Очевидно, є інші способи написати відповідну програму, але це дає уявлення, про що я кажу.

Якщо я даю завдання на будинок, то очікування ще вище.

Частина 3. Алгоритми


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

Тим не менш, оскільки інтерв'юери попросять це, краще освіжити знання в пам'яті перед співбесідою. На Khan Academy є відмінний безкоштовний курс.

Частина 4. Не здаватися без боротьби
Якщо ви не здатні вирішити запропоновану завдання, завжди є деякі речі, які можна зробити, щоб зберегти шанси отримати посаду.



1. Не здавайтеся занадто легко

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

2. Псевдокод

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

3. Назвіть відомі невідомі

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

Частина 5. Практика, практика, практика
Мабуть, найважливіше для успішної співбесіди з програмування — хороша підготовка. Найкраще практикуватися зі стандартними питаннями знову і знову, поки ви не вивчіть їх напам'ять. Якщо багато тренуватися, то ви зможете відповідати на питання, які не зустрічали раніше. У вас з'явиться впевненість і ви зможете зв'язати будь-яке питання з чимось іншим, що зустрічали раніше.

Я склав великий перелік онлайн-ресурсів з прикладами питань та порадами з програмування для 50+ різних мов програмування та технологій, включаючи C#, JavaScript, Mongo, Node і так далі…

Список тут (підписка на розсилку) і нижче в pdf.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.