Tech Lead із Bolt про ресурси для вивчення алгоритмів і запитання на співбесідах

Tech Lead із Bolt про ресурси для вивчення алгоритмів і запитання на співбесідах

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

Деякі айтівці вважають, що алгоритми та структури даних потрібні лише для інтервʼю у FAANG-компанії й що на практиці від них небагато користі. Проте ті розробники, які вміють оптимізувати код за допомогою структур даних, здатні вигадувати нестандартні рішення в складних задачах на проєкті, а не тільки парсити Stack Overflow у надії знайти чуже готове рішення.

Ми поспілкувалися з Артемом Верещакою, Tech Lead у Bolt і лектором курсу «Алгоритми та структури даних», про можливості алгоритмів, запитання на співбесідах і корисні ресурси для опанування теми.

Досьє:

  • Артем Верещака 4+ роки працює над розробкою високонавантажених систем із застосуванням алгоритмів та структур даних у Bolt та керує командою Rental Micromobility.
  • Написав із нуля backend для оренди самокатів та велосипедів, спроєктував та запустив систему каршерингу [в тестовому режимі в Таллінні, Естонія].
  • Любить свою професію за те, що вона дозволяє творити й застосовувати свої знання в абсолютно різних сферах: від автоматизації виробництва до Computer Vision.

Поясни в кількох словах, що дозволяють робити з кодом алгоритми та структури даних.

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

Тобто розробникам потрібно бути креативними?

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

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

Наскільки відрізняється застосування алгоритмів залежно від мови? Чи шаблони однакові для всіх мов?

Підходи та ідеї скрізь однакові. Багато напрацювань із відомих алгоритмів і структур даних датуються пʼятдесятими роками минулого сторіччя. Математика не змінилася з того часу.

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

Але головне ― розуміти принципи та ідеї, за якими працюють алгоритми. Ці знання можна застосовувати в будь-якій мові.

Чи є «‎зірки» серед алгоритмів та структур даних? Тобто ті концепції, які застосовують найчастіше?

Дуже залежить від того, де це застосування. Різні сфери мають різні підходи, свої структури та свої алгоритми.

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

Який твій улюблений алгоритм чи улюбленець серед структур даних?

Важко виділити конкретний, бо вони мають різні цілі та сильні сторони.

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

Алгоритми на деревах виглядають класно та мають структуру, яка дозволяє писати гарно. Водночас майже завжди є дуже оптимальними в плані перформансу. Треба просто шукати елементи з відносними запитами ― ось простеньке дерево пошуку. Треба проаналізувати текст ― ось варіанти для natural language processing. Потрібна будь-яка ієрархічна система ― базове дерево її вже дає. Треба мати точну мапу діалогів для гри та що до чого призводить ― теж тримай дерево :)

Знання з алгоритмів та структур ― це про «‎один раз вивчив і використовуєш»? Чи потрібно їх «‎освіжати» через деякий час?

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

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

Що б ти порадив тим, хто лише починає вивчати алгоритми?

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

Чи важливо читати книги з алгоритмів і структур? Які можеш порекомендувати?

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

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

Які ресурси ти сам використовуєш, щоби попрактикуватися?

Я використовую LeetCode, HackerRank, InterviewBit, Codewars ― залежно від настрою.

Перші три ― це більш як підготовка до інтервʼю, LeetCode ― основний наразі. Там зібрана купа задач, вони оновлюються і додаються.

HackerRank та InterviewBit простіші, щоби почати: вони самі «ведуть» темами, їх зручно та приємно використовувати.

Codewars ― це скоріше пазли. Дуже цікаві задачки як на логіку, так і на алгоритми. Дуже допомагає тренуватися на мовах, які просто цікаво спробувати.

Де брати кейси застосування алгоритмів та структур даних на практиці, якщо поки немає реального досвіду?/h3>

Зазначені вище платформи ― це квінтесенція застосування алгоритмів та структур даних.

Також дивитися в готові продукти. Наприклад, реалізації пошукових двигунів та баз даних. Подивіться, як працює DynamoDB/Cassandra/Elasticsearch всередині. Чи, може, вам цікава організація геопошуку ― Geohash/R-Tree. Також Redis ― це збірник гарного використання різних структур для отримання швидкого інструменту.

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

Які запитання про алгоритми та структури даних найчастіше задають на технічному інтервʼю?

Якщо не брати до уваги саме задачі, то із запитань це зазвичай деталі з реалізації. Використали хеш-таблицю ― очікуйте запитань, як вона працює та чому вона швидка (без усіх деталей, у цілому принцип роботи). Ні я, ні компанії, куди я проходив співбесіди в останні років 5, не ставлять просто запитання на якісь теми. Зазвичай це практична частина + follow-up запитання.

А які найпоширеніші помилки кандидатів?

Не слухати підказки :) Також ― неуважно аналізувати умови задачі, не ставити уточнюючих запитань, робити свої здогадки, не питаючи інтерв'юера, так це чи ні.

Що робити, щоби справити хороше враження на інтервʼю?

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

Розуміння основ, підхід до розв'язання проблем, комунікація та сам код (як оптимальність, так і його стиль) ― це основні моменти на кодинг-співбесіді.

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

Чим відрізняється інтерв’ю в українську IT-компанію та компанію за кордоном?

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

Я б сказав, що компанії за кордоном мають очікуванішу структуру зазвичай (кодинг + system design + культура). Це певний стандарт, якого більшість дотримується.

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

В нас, наприклад, весь бекенд працює на Node.js, пишемо на TypeScript. Більша частина розробників не писали на такому до того, як приєдналися, але вони швидко все освоїли ― і це головне.

Які поради ви б дали тим, хто готується до технічного інтерв’ю?

  • Більше тренуйтеся, приділяйте увагу діалогу під час інтервʼю.
  • Слухайте, що каже інтерв'юер, бо він зазвичай намагається допомогти.
  • Уважно дивіться на умови задачі.
  • Не забувайте тестувати як свої ідеї, так і фінальне рішення.
  • Уточнюйте ціль та таймінг.
  • Не витрачайте час, якщо у вас ще не готове рішення. Завжди краще «брудне», але працююче рішення, ніж маленький гарний шматок, який не працює.
  • Не стрибайте в код через 10 секунд після початку.
Ещё статьи
Как разработчику упростить код с помощью шаблонов.
Віктор Шитюк, Lead Data Engineer з 12 річним досвідом у IT сфері, про робочу рутину інженера даних, must-have інструменти та перспективи професії