Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Робота у Twitter: розповідь українського програміста

Львів’янин Арсен Костенко переїхав до США 6 років тому, де спочатку працював у Sony, а останні 2 роки займає позицію Software Engineer в компанії Twitter. У інтерв’ю Арсен розповів про те, як влаштовані робочі процеси у Twitter, наскільки комфортно працювати в компанії, які навички та знання потрібні для того, щоб приєднатись до команди розробників соцмережі.

— Арсен, як ви потрапили до Twitter?

На той момент я вже 3 роки жив у США, працював у Sony. У Twitter мене запросили у 2015 році. Порядок найму на роботу доволі схожий між українськими та американськими компаніями: рекрутер пише потенційному кандидату щось на кшталт: «Привіт, я такий-то, працюю в Amazon/Google/Twitter, може вас цікавить поговорити з нами, у нас є пара актуальних позицій».

У мене був дзвінок з рекрутером, після цього дзвінок з менеджером. Ми придивились один до одного, вирішували, чи цікаві мені проекти, якими я буду займатися, і чи цікаві їм мої знання. Потім був дзвінок із техлідом компанії, з яким ми провели простеньке завдання на написання коду і розуміння основ комп’ютерної грамотності. Після цього запросили на онсайт. Між цими двома етапами мене попросили написати код і надіслати їм. Після цього була технічна співбесіда в офісі Twitter: це було 8 інтерв’ю, з яких 6 технічні і 2 не технічні. І все.

— 8 інтерв’ю — це досить багато.

Так, це багато роботи: після цього виходиш виснажений, вже не хочеться дивитись місто, а бажаєш просто лягти поспати і не пропустити літак назад. Але це не є щось надзвичайне: таким чином працює багато різних компаній, і переважно люди розуміють, що під вечір людина вже виснажена. Тому дуже часто під кінець розмови стають все більш загальними — наприклад, вас не будуть просити написати код для знаходження відстані Левенштейна між двома послідовностями на останньому інтерв’ю. Переважно вас запитають, як працюють Hash table в загальному або щось таке.

— А що ще питають на співбесідах?

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

Щодо програмістів, потрібне ідеальне розуміння комп’ютерних основ. Все те, що викладають на другому курсі інформатики, повинно відскакувати від зубів. Комп’ютерні основи повинні бути на такому рівні, щоб людина могла вільно знати, чим відрізняються, допустимо merge sort від quicksort, і за яких умов треба використовувати один або інший. Це повинні бути знання, які не потребують згадування, затримки, ніяких двох секунд, щоб подивитись на стелю, нічого такого. В цьому плані рівень повинен бути високий.

Ніхто не вимагає чіткого розуміння того, як працюють конкретні системи в конкретних компаніях. Треба лише загальні знання, основи комп’ютерних алгоритмів. Не треба чіткого розуміння, як працює Memcached — треба загальне розуміння того, як працює абстрактний тип даних LRU cache.

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

В офісі Twitter, Сан-Франциско

— Як влаштована кар’єрна драбина в компанії?

Драбина виглядає так: Software Engineer (SWE), SWE II, Senior SWE, Staff SWE, Senior Staff SWE, далі не пам’ятаю. Всього їх 8 рівнів. Найвищий рівень — Engineering Fellow. Є ще інтерни, але вони не вважаються постійною робочою силою.

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

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

— За скільки років зазвичай розробники досягають підвищення від початківців до Senior?

Все залежить від індивіда. Є компенсація платні і зріст по відповідальності. Тобто, є люди, які отримують класну компенсацію, при цьому вони перебувають на рівні Senior SWE, хоча виконують роль Senior staff SWE і всяке таке. Тут важливо розуміти, що просування по кар’єрній драбині є можливим мотиватором, але якщо людині подобається розбиратися в технічних деталях — вона може організувати своє життя таким чином, що компенсація роботи буде дуже достойна без необхідності рости вгору.

Щодо того, скільки часу треба — якщо людина достатньо амбітна, може за три роки дорости з SWE до Senior staff SWE. Це чотири щаблі.

— Чи є позиції Software architect або щось таке?

— Такої виділеної позиції немає. Є поняття «тімлід», але тімлідом може бути і Staff SWE, і Senior staff SWE.

— А як взагалі структуровані команди?

Команда структурована таким чином: є програмісти, в програмістів є як мінімум один менеджер команди — Engineering manager. Роль цієї людини найбільш схожа на Скрам-мастера в Agile. Її задача — не приймати самостійно технічні рішення, а займатися тим, щоб в команді не було ніяких перешкод.

Також у команді є людина, яка відповідає за продукт — Product manager. Він розмовляє з користувачами, з потенційними партнерами і дає відповідь на питання, що саме ми робимо.

Паралельно стоїть гілка дизайну. Дизайн сприймається як окрема внутрішня структура, до якої люди приходять, щоб запитати: «А як нам краще це зробити?» або «Як нам побудувати UX, якщо бажаним ефектом є такий ефект?»

Щодо ролі тімліда, це людина, яка очолює якийсь певний проект. Наприклад, я є тімлідом, будучи SWE другого рівня. Я тімлід в двох проектах і якраз займаюсь тим, щоб з’єднати все до купи. Я на цих проектах навіть не найстарший за рангом, адже там є і Senior SWE. Але вони займаються інженерією якогось одного модуля, який потребує дуже зональних знань, а я займаюсь тим, щоб це все разом запрацювало. Роль тімліда — не постійна, вона асоціюється з проектом, а не з командою. Одна команда може робити декілька різних проектів.

— Скільки в середньому людей у командах?

Є таке поняття, pizza-size team. Тобто, максимум 8-12 людей. В моїй команді нас шестеро.

В офісі Twitter, Сан-Франциско

— Чи можуть інженери вільно переходити між проектами?

— Так. Кожну чверть відбувається так званий «branch out fest», коли всі команди виходять і одночасно розповідають, які в них є відкриті позиції, що вони хочуть робити, яка в них дорожня карта. І вони дають можливість всім працівникам компанії прийти, з усіма поговорити. Якщо цікавить щось інше, а не те, чим я займаюся зараз, то достатньо домовитися з менеджером тієї команди, в яку я хочу піти.

Проектів всередині компанії дуже багато. У Twitter кожна найменша штучка робиться як окремий сервіс і організується як окремий проект.

— Наскільки прийнято всілякі Agile методології?

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

— Розкажіть, а чим саме ви зараз займаєтесь? Над чим працюєте, який стек технологій використовуєте?

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

Класичний для Twitter стек технологій — це Linux, Mesos, Aurora, Scala.

Ті команди, яких було придбано компанією, можуть працювати на інших стеках. Наприклад, є команди, де використовують AWS + Linux + якийсь там Docker + Go.

Сан-Франциско

— На спеціалістів з яких технологій зараз найбільший попит?

— Знаєте, найбільш хибне враження, яке складається з України: за рахунок того, що в Україні домінує аутсорсинг, всіх підбирають на основі стеку — чи знає людина Java, Ruby чи ще щось. Звичайно, таке питання звучить — «А з чим ти раніше працював?», але воно звучить в розрізі того, щоб кандидату було комфортно писати код. Для написання коду на інтерв’ю не використовують прототипну мову, пишуть конкретною мовою. В ідеалі — код, написаний на дошці, повинен бути без помилок запущений. І переважно у кандидата запитують, якою мовою він хоче написати.

А якихось гарячих стеків... Вони, звичайно, є, але це приблизно як шум в тій самій стрічці новин Twitter: з’являється і проходить. Google до сих пір працює на С++. Google розробив Go — ця мова дуже кльова, мені дуже подобається, але в самому Google вона не прижилася. Twitter свого часу перейшов на Scala. Uber працює на Java, здебільшого, Amazon працює на багатьох різних технологіях, але Java там 60%.

І знов таки, це ніяк не впливає на процес найму на роботу. Наймають за знанням алгоритмів. Через те що людина буде тут загально довго, її найбільший вплив буде по тому, наскільки вона добре вміє працювати з комп’ютером — неважливо, якою мовою.

— Серед співробітників компанії багато українців? Представників яких народів найбільше?

Знаю двох українців, які вже пішли, та трьох, які ще тут. Зокрема, працює дівчина із Запоріжжя — менеджер всіх core сервісів, які відповідають за юзерів і твіти. Кількість таких серверів вимірюється десятками тисяч.

Щодо етнічного складу, в мене в команді з шести чоловік двоє американці та по одному з Індії, Китаю та В’єтнаму. Twitter нещодавно публікував результати дослідження стосовно компенсації і присутності різних меншин (національних, етнічних, сексуальних), і цей результат доволі крутий.

— Як вважаєте, наскільки Twitter є комфортною компанією для роботи?

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

Компанія цінує співробітників, і це помітно. Один із наших старших програмістів, австралієць, мав таку історію, що він 4 роки працював у Twitter у Сан-Франциско, але його дружина не змогла переїхати з особистих питань. І вони в результаті вирішили, що він повертається назад. І тоді компанія сказала: «Окей, у нас є в Сіднеї офіс, будеш працювати з ними». Тобто вони дуже йдуть на зустріч.

— Овертайми бувають?

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

Проте, є таке поняття — on call: кожен з інженерів певний час є основним по підтримці, це перехідна роль. Якщо в мене з тої або іншої причини падає сервіс, а я є інженером on call, то хоч серед ночі — я прокинуся і буду це робити, поки не вирішу проблему. Так як це не робочі години, то де-факто поняття «овертайм» існує, але немає такого, що менеджер стоїть з нагайкою і змушує, щоб всі лишалися на роботі, поки щось не відбудеться. Це вирішується в інший спосіб.

— В українських компаніях, переважно аутсорсингових, співробітники здебільшого не задоволені менеджментом. А що у Twitter в цьому плані?

Є така золота формула, що люди приходять в компанію через місію, а йдуть через менеджмент. Менеджмент для конкретної людини — це уособлення самої компанії. Особисто я не стикався з поганим менеджментом. Проте, я знаю, що такі випадки є, коли люди не можуть порозумітися з менеджером. Чи жаліються люди на менеджмент? Так, жаліються, але жаліються вони на це всюди.

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

— Що вам подобається в роботі, а що ні?

Те, що подобається — це вплив. Попри всі негаразди зі зростом користувачів, в Twitter близько 300 млн користувачів, а це близько 6 Україн. І все, що я роблю — впливає на цих людей. Тобто, розмах вражає. Взагалі, кількість відповідальності обернено пропорційна до розміру команди. Якщо команда дуже велика або дуже багато команд пишуть один і той самий проект, то відповідно один конкретний програміст пише мало. Тут такого немає. Людина переважно відповідальна за величезні куски, за величезні частки. І це частковий ризик, але це приємно самому виконавцю.

Що не подобається... Мені здається, що в Twitter є деякі проблеми з існуючим і функціонуючим технічним багажем, який вже важко поміняти і з яким постійно доводиться рахуватись. Його неможливо просто так взяти і відкинути. І це означає, що треба дуже часто копатися в коді, дуже часто займатися тим, щоб пройти по десятку різних команд, зрозуміти, чому ця річ працює саме так, а не інакше, і знайти всякі вузькі місця і крайні випадки для того, щоб повністю зрозуміти, як треба щось зробити.

Арсен виступає на Lviv IT Arena

— Як стати стажером у Twitter? Багато людей беруть на стажування?

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

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

Кандидату на стажування треба ідеально знати основи — це мінімум. Треба бути автономним і розуміти, як приблизно функціонують компанії такого розмаху. Ця вся інформація є на Quora, Glassdoor, також є блоги самих компаній, де вони розповідають, про те, як функціонують. Треба розуміння того, до чого саме ви хоче долучитися. Не просто: «Я хочу працювати у Twitter».

— Який конкурс середній на стажера?

Він доволі великий — може бути 5-10 людей на місце. Раніше було ще більше.

— Скільки з тих, хто попадає на стажування, стають співробітниками компанії?

Я думаю, що це закрита інформація, але це не так важливо. Маючи стажування у Twitter, можна продовжити працювати у Twitter. Але зі стажуванням у Twitter вас залюбки візьмуть і в Google, і в Facebook, і в Snapchat, і в будь-яку іншу компанію подібного рівня. Ці компанії мають між собою таке джентльменське розуміння, що планка у них всіх доволі висока, і якщо людина пройшла цю планку хоча б раз — це достатній сигнал для того, щоб на цю людину звернути увагу.

— Які у вас враження від життя в Сан-Франциско? Наскільки комфортне це місто?

Якщо людина готова змиритися з тим фактом того, що із платні приблизно половина буде йти на оренду і комунальні послуги — все решта доволі комфортно.

Ще є такий момент, що у Сан-Франциско дуже толерантно ставляться до всіх, і тому тут дуже багато безхатченків в центрі, приблизно так само, як було в Нью-Йорку до 2004 року. Зараз Сан-Франциско допомагає цим людям, влаштовує їм місця, де можна переночувати, поїсти, отримувати замінники наркотиків. Я часто в переході бачу, як люди користуються цими замінниками наркотиків з одноразових шприців. Це не дуже приємно. Але, якщо дивитися на це взагалі — це, мабуть, краще, ніж намагатися прибрати їх в якісь закриті території.

Є дуже велика проблема з паркуванням. Це просто жах. Воно коштує великі гроші, займає скажену кількість місця і робить місто не дуже приємним для проживання. Затори на в’їзді в місто гігантські, люди витрачають на це по декілька годин щоденно, і це величезна трата часу. І нормального, хорошого метро немає. Немає електрички, яка б їздила довкола цієї затоки. Частково через те, що її в одну сторону провели, а коли почали проводити в іншу сторону, люди з сусідніх міст просто сказали: «Ви знаєте, ми не хочемо тут ніякої електрички, ми хочемо садочок коло хати». І все.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Схожі статті




58 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Дякую за чудове інтерв’ю!

стаття класна,
П.С.блін як ці срачі і піськомірялки в коментах дістали, пардонмайфренч

Ой та нічого страшного там не наміряли 😀. Нічого особливо складного потиснути штангу 120кг немає. Я за два роки до цього дійшов, сам був 78кг. Головне — бажання 😋

Арсен, а какой у вас уровень английского? Были ли проблемы с пониманием собеседника во время собеседований или у него вас?

«як шум в тій самій страчці новин в Twitter....»

Нужно исправить эту досадную опечатку :)

Ой, и правда досадная :(
Спасибо, исправила

Компанія цінує співробітників, і це помітно. Один із наших старших програмістів, австралієць, мав таку історію, що він 4 роки працював у Twitter у Сан-Франциско, але його дружина не змогла переїхати з особистих питань. І вони в результаті вирішили, що він повертається назад. І тоді компанія сказала: «Окей, у нас є в Сіднеї офіс, будеш працювати з ними». Тобто вони дуже йдуть на зустріч.

Ну это уровень. Ого, как на встречу пошли.

Знаю двох українців, які вже пішли, та трьох, які ще тут.

;)

Картинка с распределением полов крута. Не смотря все усилия, technical women — 15%

+ якийсь там Docker + Go.
щас в тему набежит Валялкин и начнется))

Нет, его расстроило, что

Google розробив Go — ця мова дуже кльова, ... але в самому Google вона не прижилася.

ой, как я этот жыр пропустил-то?))

да там вообще весь абзац убийственный для мировоззрения гоферов, полагаю, если он когда бросал курить, он взялся за эту привычку вновь.

LRU cash
-> LRU cache
як працює абстрактний тип даних LRU cash.
Наверное, имелось ввиду LRU cache :)

Я думаю, взагалі ніколи. Це просто сатндартний стек знань, які має знати програміст.

При этом, неопытный программист может заюзать обычную пузырьком, не зная скорости или существования той же QS или MS и т.д.

И в итоге, приведу пример. На 100.000 рандомных double QS работает в 620 раз быстрее, чем пузырьком(Личный небольшой тест на Java, точно таких же результатов у каждого не будет). Такое естественно недопустимо на проде глобальных проектов))). Так почему бы не перестраховываться и не гонять пацанов по алгоритмам и структурам данных, чем нанимать формошлёпщиков, которых везде хватает.

Я не настолько больной сейчас этим заниматься :D
но недавно игрался с алгоритмами и наблюдал за скоростью.

Тем не менее, вы бы предпочли в команду обычного разраба или такого же разраба по уровню, но еще и со знанием Алгоритмов)?

Могу привести вполне неисскуственный пример, чуть упрощенный:
У вас есть скажем 10 миллионов или может 10 миллиардов пар userId, deviceId
Например:
(userA, devA), (userA, devB), (userB, devA), (userB, devC), (userC, devC)
Вот тут мы видим, что userA, userB, userC имеют общие (и транзитивные) пересечения.

Ну и задача — найти все такие группы юзеров.

У Арсена в Сан-Франциско сейчас 5.40 утра. Так что он немного позже сможет ответить

Т.е. знание сортировки ему в этом не помогло так и запишем... ))

Даже зная про наличие QS и MS, можно нарваться на отличие в сортировке одинаковых ключей

Тут скорее идея в том, что сортировка уже реализована во всех стандартных библиотеках.

Там был вопрос, каким методом в каких случаях пользоваться.

Обычно пересичный неопытный будет юзать стандартную из библиотеки а там как раз быстрая сортировка :) ваш пример мимо

Java Arrays.sort — для примитивов dual-pivot quicksort, для объектов mergesort, что в общем-то правильно для защиты от «неопытных»)

там как раз быстрая сортировка
В некоторых ситуациях еще mergesort). В принципе, да, вы правы, но есть же уникумы, которые захотят выпендриться и заюзать свой велосипед на основе чего-то слабого или чему их на Г курсах обучали))).

Автор ответил в следующем предложении:

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

Я понимаю о чем вы :) просто как по мне автор немного погорячился, ну или его слова были неверно истолкованы ;)

Привіт, перепрошую за спізнілу відповідь. Чесно — самі алгоритми сортування я з того часу не писав. Знання знадобились пару разів коли дебажили відтворення послідовності відео фреймів за послідовностями PTS/DTS індексів

Осмелюсь предположить, что вопрос заключается не столько в проверке знания отличий алгоритмов, сколько в привычке задаваться вопросом, как сделать лучше. При разработке высоконагруженной системы очень нежелательно использовать менее подходящие алгоритмы, архитектурные решения, библиотеки, поскольку в дальнейшем это может влетать в копеечку как в виде необходимости содержать больше железа, так и в затратах на человекочасы дальнейших исправлений. В итоге людей опрашивают на износ, чтобы увидеть, как они принимают решения.

Технические интервью — это то еще дерьмо. Эта четверка проверяет, в основном, навыки прохождения технического интервью, так как вопросы одни и те же и все есть в сети. Но если в «почти во всех компаниях» очередь занять вакансию достаточно скромная, им переберать позволительно, но очень осторожно, то GATF (google, amazon, twitter, facebook) могут отсеить кандидата, который вызывает какие-либо сомнения не беспокоясь, что очередь закончится быстро.

Практически, знать алгоритмы конкрентно

QS & MS
важно на уровне понимания их Big O min, avg, max и при каких обстоятельствах достигается min, а при каких — max. Важно не столько иметь знания фактические, сколько иметь понимание того, как оно работает. Просто алгоритмы сортировки заезжены уже до дыр и это самый простой способ оценить базовые знания алгоритмов.

Отсутствие такого понимания повышает вероятность написания неоптимального кода, что сказывается на производительности систем. И, как следствие, на ценности сотрудника.

Эти 4 компании — это те, кто могут перебирать, и те, кто следует принципу «лучше не нанять хорошего спеца, чем нанять плохого».

Однако, по опыту скажу, что из этой четверки самая адекватная компания — Facebook, они проверяют более или менее релевантные позиции знания и навыки.

В довесок мне недавно попалась занимательная статья про собеседования технические: blog.interviewing.io/…​-the-technical-interview

Подозреваю, им вполне может такое понравиться. Статистики-то у нас нет.

А не важно. Просто сейчас алгоритмические задачки — это «state of the art» в интервьюировании, когда основная цель — не сделать неудачный найм. Когда-то головоломки были, если помните.

Интервью с алгоритмами — это industry-specific IQ test. Не прямой замер профпригодности, конечно, но лучшей аппроксимации при заданных ограничениях пока что не придумали.

якщо на інтерв’ю просять реалізувати стандартну структуру даних (список, хеш таблицю, дерево) або стандартний алгоритм (сортування, bfs) — тобі не пощастило, твій інтерв’ювер упоротий, спробуй іншим разом.

задача цих інтерв’ю оцінити problem solving і вміння користуватись існуючими знаннями cs (знати, що bfs існує і на пальцях пояснити як працює і чому підходить краще інших для заданої проблеми, а не закодити його з пам’яті), не до всіх інтерв’юверів в топ конторах це доходить і це проблема, тому процес і є таким рендомним, багато залежить від удачі і інтерв’юверів, а не від тебе

Расскажите как работает quick sort?
Где вы такой вопрос видели?

на собеседованиях, редко, но его задают

В какой компании?

Мене таке мимохідь питали колись на скрінігу nVidia, і до того ж як порахувати big-O для quick sort.

если ничего не путаю, то в плариуме и в сигме

Сам придумал вопрос, сам возмущается :)
Могут спросить что-то вроде «напиши функцию чтобы отсортировать связанный список». Нужно сравнить разные методы сортировки, выбрать наилучший и закодить — тут нужно головой думать, просто заучить не выйдет.
Когда есть какая-то база, которая воспринимается как должное (алгоритмы, сортировки и т.д.), то появляется куча задач чтобы относительно надежно проверить кандидата на сообразительность и навыки кодирования.

Підписатись на коментарі