Як допомагають навички спортивного програмування на співбесідах
Як допомагають навички спортивного програмування на співбесідах?
Це питання хвилює хлопців, які досягли успіху в спортивному програмуванні, які мають першу співбесіду в IT-компанії. Про це замислюються і початківці — вирішувати завдання контестів правильно виходить далеко не відразу, і в перервах між вивченням алгоритмів вони шукають мотивацію подолати страх невдач і продовжувати.
На Quora порівнюють складність завдань із співбесід у Google із завданнями другого дивізіону та стверджують, що завдання із співбесід Facebook простіше завдань контестів. Об'єднує усі обговорення на цю тему одна думка — спортивне програмування допомагає дізнатися алгоритми, вчить швидко розуміти та передбачати можливі варіанти розвитку подій.
Цікаво дізнатися про думку програмістів, які через етап співбесід уже пройшли. Розкажіть нам, що допомогло, що здивувало, чого не вистачило - інформація "від своїх" сприймається куди приємніше :)
Ідею цієї посади запропонував Емілбек Емілбек Сулайманов. Спасибі тобі!
Нагадую, що чекаю на ваші пропозиції про новини в особисті повідомлення :)
Як правило, на співбесідах завдання справді простіше, ніж на контестах. Думаю, це можна пояснити тим, що на співбесіду приходить багато кандидатів, які взагалі не стикалися з олімпіадним програмуванням раніше. Рідко тематика завдань виходить за межі сортувань, пошуків (в т.ч. бінарного) та структур даних.
Досвід участі у змаганнях із програмування допомагає швидко вигадувати хороші рішення, що явно грає на руку кандидату, справляючи дуже позитивне враження на співрозмовника.
Інше питання в тому, що іноді на співбесідах запитують питання щодо мов програмування, і тут олімпіади не завжди можуть допомогти: якправило, на контестах використовується дуже обмежений набір всіх функцій, фішок та можливостей мови.
Крім того, олімпіади, на жаль, часто розвивають навички написання коду, що погано читається, частково тому що навряд чи доведеться повертатися до цього коду після отримання OK за завданням. Цей чинник теж, швидше, відіграє негативну роль співбесідах, якщо писати код у тому стилі, як і контестах.
Як відучитися писати код, що погано читається? Це приходить з часом і поза змаганнями?
Дійсно, завдання на співбесідах у великі компанії (МС, ФБ, гугл. ) зазвичай на рівні див 2 B, C так що олімпіаднику їх вирішити нічого не варто) плюс крім самої ідеї рішення зазвичай потрібно закодувати на дошці (в блокноті) і на все це хвилин 25-30. Як мені здається, щоб успішно пройти співбесіду достатньо знати: покажчики, динаміку, сортування, бінпошук, структури даних (set, map, hash_set, hash_map, queue, stack, segment tree), обробка рядків.
у невеликих компаніях частіше запитують за тонкощами мови, алгоритмами дуже слабко. наприклад, мене пробували завалити питанням: "Що таке бінарний пошук"))
segment tree на співбесіді? хочу подробиць)
один раз попалося крутому знайомому, він дуже швидко вирішив завдання і йому вирішили ускладнити:) точну умову не пам'ятаю, але щось на зразок:
заданий лінійний масив позитивних чисел, потрібно вміти виконувати на запити:
1) знайти твір на відрізку
2) змінити число
Слід вважати, що у нас є готовий БігІнт.
А потім твоєму знайомому сказали, що хотіли почути відповідь за лінію? :)
Так, бінарний пошук знаю. Здається, мої шанси знайти роботу різко зросли:)
Як уже написали вище, є два типи компаній:
Великікомпанії рівня Google, Facebook, Yandex та компанії, де важливі алгоритмічні навички.
Інші, тобто. ті, де саме алгоритмічні навички важливі негаразд (більш важливе знання конкретних мов, патернів проектування, досвід роботи у команді тощо.).
У компаніях другого типу все доволі випадково. Зазвичай у алгоритмічному плані питання цілком тривіальні. В цілому, не дуже зрозуміло, навіщо спортивному програмісту йти в ці компанії (коли він може піти до Google :)
Складність завдань у компаніях першого типу – щось на рівні Div1 A/B, Div 2 B/C. Але треба розуміти, що час обмежений ще сильніше ніж на олімпіаді, до того ж часто доводиться писати рішення не на комп'ютері, а на листочку/дошці/. Ще важливий аспект, на відміну від олімпіади, зазвичай потрібно обґрунтувати коректність рішення.
Відповідаючи на запитання в заголовку: одна з важливих навичок, що дає спортивне програмування, — це вміння писати коректний код у психологічно напружених умовах (через жорсткий дефіцит часу, змагальність тощо). Ця навичка, безумовно, корисна (причому на будь-якій співбесіді).
На жаль, є навички, яким спортивне програмування не вчить (скоріше навіть навпаки), які корисні на співбесідах, а ще більше — у процесі реальної роботи. Мова про написання виразного коду (неоднолітерні імена змінних, відсутність копіпасти тощо).
P.S. Все написане - з особистого досвіду проходження співбесід в Яндекс/Google/декілька менш відомих компаній.
У якій компанії співбесідуватися було найцікавіше? :)
Я б не порівнював співбесіди із завданнями другого дивізіону. Це зовсім різні області та досвід участі у спортивному програмуванні допомагає лише частково. Підхідучасника у спортивному програмуванні полягає у вирішенні нового завдання будь-яким доступним способом, причому під рішенням завдання розуміється проходження її тестів. Успішний підхід проходження інтерв'ю полягає в умінні точно з'ясувати завдання зі співрозмовником, розповісти алгоритм її вирішення, дохідливо пояснити свій код у міру написання її на дошці, знову пройтися по ходу алгоритму після завершення її написання, показати її роботу на прикладі, розглянути крайові випадки, та при цьому показати себе прекрасним командним гравцем, і в жодному разі, зарозумілим.
В одному випадку на завдання другого дивізіону, для здачі якого мені знадобилося б не більше 10 хвилин, на співбесіді на неї пішло мінімум пів-години, при цьому я припустився досить дурних помилок. А на закінчення мені співрозмовник сказав, що він чекав від мене більш простого рішення.
Або навпаки, одного разу на співбесіді я отримав завдання з обмеженнями на все int32, і єдиний алгоритм, до якого я зміг додуматися був O(n^3). Я швидко накидав це рішення на дошку і провів більше 40 хвилин розмовляючи зі співрозмовником (який при цьому швидко все, що відбувалося, записував на своєму ноуті), намагаючись здогадатися до кращого рішення. Наприкінці співбесіди я запитав його, чи існує рішення краще, а він відповів, що не знає, і що він бачить це завдання вперше.
При цьому велике значення відіграє, чи співбесідуєтеся з BigCorp або SmallCorp.
Допустимо, це BigCorp. Тоді:
Досвід участі у спортивному програмуванні реально допоможе пройти співбесіду. Завдання BigCorp - знайти людей, які розуміють. У них часто свій власний закритий стек технологій, і їм у принципі байдуже, з якими технологіями людина працювала раніше. Перевірка людей за допомогою співбесід наалгоритмічні завдання - далеко не ідеальний, але досить хороший спосіб відсіяти людей.
Популярні теми при цьому: binary search, trees, graphs, sort-related algorithms, linked lists, string-related algorithms.
Знання O(n) асимптотики є обов'язковим, включаючи time complexity & Memory complexity. Із цим у спортивних програмістів проблем немає.
У міру написання алгоритму на дошці можна показувати знання патернів, можна писати псевдомовою, у багатьох випадках просто припускаючи, що подібна функція є.
Хешування - слизька тема, до якої потрібно обережно ставитися. Застосування хешування там, де можна застосувати КМП – не добре. Твердження, що запити до хеш-сету мають О(1) складність — не добре. З іншого боку, написання алгоритму з O(n * log(n)) складністю, тоді як з допомогою хеш сета можна домогтися O(n) — теж недобре.
На співбесідах у BigCorp мене жодного разу не запитали жодного питання на багатопоточність, але onsite interviews містять 1-2 design problems, де може знадобитися знання distributed systems.
Якщо ж ви поговорите зі SmallCorp, то
Можете чекати чого завгодно. Кожна компанія має свої методи потбору співробітників. І якщо вас не взяли, це не означає, що ви провалили співбесіду. Це зазвичай означає, що в даний момент ви їм не потрібні.
Знання певних технологій, мов та принципів розробки відіграє істотну роль.
Вказівка успіхів у спортивному програмуванні в CV може відігравати важливу роль.
Багато SmallCorp-и проводять співбесіди на алгоритмічні завдання. Паралельно вони можуть запитувати нюанси мови та багатопоточність.
Найпопулярнішою темою є різні структури даних для написання кешів. Причому це чудовийплацдарм для перевірки знань парелелізму.
Бувають дуже неприємні казуси:
1) Співбесіда пройшла просто добре. На наступний день повідомляють regrettably. Запитую, як це так, співбесіда була на відмінно. Відповідь: ну так, співбесіда була на відмінно, але ми шукаємо людину зі знаннями інших технологій/з іншим досвідом. Висновок – HR погано роблять свою роботу.
2) Отримуючи деякі специфічні питання від співрозмовників і бачачи задоволені їхні особи, вони напевно думають: "Ха-ха-ха, я знаю відповідь на це цікаве питання, а він не знає". Так, я не можу написати відразу формулу для комбінаторного питання, якого ніколи раніше не чув, не знав, що це має таке велике значення для компанії, що займається розробкою internet of things. Ще це питання: "Вам дам масив з n + 1 чисел від 1 до n, одне число повторюється 2 рази, як швидке його знайти", а потім відразу наступне: "n + 2 чисел, 2 числа повторюються 2 рази", і при На цьому чекають відповіді практично відразу, як на перший. Начебто мають перевіряти вміння здогадатися до гарного рішення, а натомість перевіряють знання відповіді.