Live Coding без 6 годин Leetcode щодня

Більшість порад про підготовку до live coding зводяться до одного: "реши 300 задач на Leetcode і все буде добре". Окей. А якщо в тебе є 2 тижні, повний робочий день і ще стрес від того, шо взагалі незрозуміло в якому форматі буде технічна? Тоді цей підхід не дуже. Коротше, давай по-іншому.

Чому формат важливіший за кількість задач

Є принципова різниця між тим, шо тебе просять зробити на Codility, і тим, шо відбувається на парному програмуванні в CoderPad. Перше - це автоматична перевірка, таймер, нікого поруч, треба здати тест-кейси. Друге - це жива людина, яка дивиться на тебе, хоче почути твій хід думок і взагалі не так переймається чи ти написав ідеальний O(n log n).

Готуватись до них однаково - приблизно як тренуватись до марафону, бігаючи спринти. Ноги ті ж, але логіка різна. Тому спочатку розберись який формат у конкретної компанії, а потім уже вирішуй шо тренувати.

Codility і HackerRank: що тут реально важливо

Ці дві платформи - асинхронні. Ти один, таймер цокає, нікого немає. Вони найбільше схожі на класичний Leetcode-режим, але є нюанси.

Codility любить задачі на масиви, рядки і базові алгоритми. Рівень - переважно medium, рідко hard. Їхні задачі з розділу "Lessons" - це буквально те, що з'являється на реальних тестах. Пройди їх всі хоча б раз. Там 17 розділів, кожен займає від 20 до 40 хвилин. Це не 6 годин щодня.

HackerRank трохи різноманітніший - там буває SQL, regex, навіть питання на знання конкретної мови. Якщо компанія використовує HackerRank, обов'язково дізнайся яку саме секцію: coding challenge чи domain-specific test. Це різні речі.

• Тренуй читання задачі швидко - 2 хвилини максимум перед тим як почати писати
• Завжди пиши edge cases вручну перед сабмітом: порожній масив, від'ємні числа, один елемент
• Не витрачай більше 10 хвилин на оптимізацію якщо базове рішення вже є - часто воно вже дає 80%+ балів
• На Codility є демо-тести, проходь їх в умовах реального таймера, не в "навчальному" режимі

CoderPad і парне програмування: тут все інакше

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

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

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

• Тренуй "думати вголос": поясни підхід перед тим як писати, навіть якщо він очевидний для тебе
• Якщо застряг - не мовчи, скажи "окей, я розглядаю два варіанти, ось чому я схиляюсь до цього"
• Читай чужий код вголос і коментуй що він робить, це корисна навичка саме для CoderPad сесій
• Запитуй про вимоги до рішення: є обмеження по пам'яті? потрібна конкретна складність? Це не слабкість, це правильний підхід

Що тренувати, а що можна пропустити

Якщо в тебе є, наприклад, 10 днів - ось де є сенс витрачати час, а де немає. Чесно кажучи, більшість компаній не попросить тебе реалізувати AVL-дерево або написати власний heap з нуля. Але масиви, рядки, хеш-мапи і базовий обхід графу трапляються постійно.

Тренуй це

• Масиви і рядки: two pointers, sliding window, базова маніпуляція. 80% задач рівня medium - це сюди
• Хеш-мапи і сети: майже будь-яка задача на "знайди пари" або "підрахуй входження" - це hashmap
• Стек і черга: дужки, монотонні стеки - з'являються частіше ніж здається
• BFS/DFS на графах і деревах: не складна теорія, просто треба вміти написати шаблон не думаючи
• Базова динамічна програмування: fibonacci, knapsack в простій формі. Не exotic DP, просто розуміти ідею

Можна пропустити якщо часу мало

• Складні структури даних з нуля (segment tree, trie, fenwick tree) - якщо тільки компанія не FAANG-рівня
• Бітові операції - зустрічаються рідко, і якщо не знаєш, краще часу не витрачати
• Математичні задачі на теорію чисел - прийміть їх як сюрприз, якщо трапляться
• Hard задачі на Leetcode взагалі - якщо тільки це не спеціалізована позиція де це явно вказано

Реальний план на 10 днів без вигорання

Слухай, 6 годин щодня Leetcode - це не підготовка, це тортури. І ефект від них після дня третього падає суттєво. Краще 1-1.5 години щодня, але регулярно і з конкретною темою на сесію. Ось приблизна схема:

1. 1День 1-2: масиви і рядки, 5-6 easy/medium задач, просто розігрітись
2. 2День 3-4: хеш-мапи і сети, 4-5 задач, цього достатньо щоб відчути патерн
3. 3День 5: стек і черга, 3-4 задачі плюс потренуй "думати вголос" на одній з них
4. 4День 6-7: дерева і графи, BFS/DFS шаблони, запиши їх і вивчи як таблицю множення
5. 5День 8: базова динаміка, просто зрозуміти ідею меморизації і таблиці
6. 6День 9: мок-інтерв'ю в реальному форматі, той самий платформ що буде на справжньому
7. 7День 10: відпочинь. Серйозно. Повтори 2-3 задачі які не виходили і все

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

Як підготуватись психологічно, а не тільки технічно

Live coding - це стрес навіть для людей які добре знають алгоритми. Реально, знаю людей з 7 роками досвіду які ступоріють на простій задачі тому що хтось дивиться. Це нормально. Але з цим можна щось зробити.

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

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

По-третє, використовуй AI Coach від Trackr щоб потренувати поведінкову частину - чому ти вибираєш такий підхід, як ти пояснюєш технічні рішення простою мовою. Це м'яз, і він теж потребує тренування.

Коротко про що не варто турбуватись

Ідеальна складність рішення. Більшість компаній не вимагають O(n log n) якщо ти написав O(n^2) але воно правильне і ти розумієш чому. Краще написати щось що працює і пояснити як оптимізувати, ніж 20 хвилин мовчки оптимізувати і нічого не здати.

Синтаксичні помилки в CoderPad. Там є виконання коду, можна запустити. Якщо пропустив крапку з комою - не трагедія. Якщо логіка правильна - це важливіше.

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