Современная разработка охватывает широкий диапазон от работы с алгоритмами до системного дизайна. По большей части разработка ПО укладывается в эти рамки. Основная масса разработчиков занимается созданием приложений, что ближе с системному дизайну, чем к низкоуровневым алгоритмам.
Большинство вакансий рассчитано на что-то между разработкой приложений и системным дизайном. Но при этом многие из тех, кто проводит технические собеседования, уделяют время только задачам на знание алгоритмов и системного дизайна – и ничему больше.
Такой подход основан на идее, что, если человек знаком с алгоритмами и системным дизайном, то и на разработку приложений ему хватит способностей. Это спорное утверждение. Создание приложений требует обширного набора навыков. Они не нарабатываются сотнями часов заучивания паттернов в решениях задач на алгоритмы. Да и рассматриванием сильно упрощенных версий системного дизайна Netflix, Uber или Twitter Threads делу не поможешь. Навыки разработки приложений оттачиваются путем… ну, разработки приложений. Но часто на технических собеседованиях они даже не принимаются в расчет.
Для ясности: я говорю о задачах на алгоритмы в духе LeetCode. Большая часть подобных собеседований, на которых мне приходилось бывать, включала задачи среднего и выше уровня с этого ресурса. Обычно их объединяют под названием «структуры данных и алгоритмы».
Как правило, собеседование на знание алгоритмов разворачивается таким образом: кандидату дают задачу, которую он должен решить и для которой должен определить уровень сложности при помощи нотации Big O максимум за тридцать минут. Само собеседование чаще всего длится дольше, но какое-то время уходит на приветствия и обсуждение прочих вопросов.
Предполагается, что кандидат начнет выполнение задания с устного разбора, а затем уже приступит к написанию кода. В процессе решения требуется объяснять свой ход мысли от действия к действию.
Вот несколько примеров таких заданий:
Подобные задачи довольно занимательны, когда можно поразмыслить о них без спешки. Однако в сценарии собеседования временное ограничение и давящее осознание, что от успешного решения зависит трудоустройство, может сильно бить по нервам. Чтобы не поддаться тревоге, кандидаты занимаются подготовкой – решают задачи заранее, чтобы ознакомиться с паттернами.
Книги вроде «Карьеры программиста» (которую рекомендует к прочтению Meta) в один голос говорят о том, что на такого рода подготовку необходимо потратить от нескольких недель до нескольких месяцев, в зависимости от того, какой у вас уровень и насколько хорошо вы знакомы со структурами данных и алгоритмами.
«Вводный курс для собеседований» от LeetCode включает более 93 примеров задач с решениями, более 67 курирующихся заданий для практики и 12 вопросников. На то чтобы одолеть все эти материалы, параллельно работая и пытаясь жить нормальной жизнью, как, полагаю, и обстоят дела у кандидатов, могут уйти месяцы.
И это подводит меня к следующей мысли.
Типичная серия собеседований включает две сессии, посвященные алгоритмам, и одну, посвященную системному дизайну. То есть 66% времени отведено под то, что разработчик, вероятно, будет использовать на протяжении менее чем 1% от всей продолжительности своей карьеры.
Я занимаюсь разработкой ПО больше двадцати лет. Алгоритмами я занимаюсь только в двух случаях:
Если же подобные задачи возникают в ходе реальной работы, я использую библиотеки (обычно встроенные), которые прошли с нами огонь и воду. Так как в этой области я не специализируюсь, вероятность того, что я смогу предложить что-то лучше, нулевая.
Очень немногие осваивают алгоритмы непосредственно в процессе работы. Нужно потратить многие часы, чтобы изучить их на уровне, достаточном для успешного прохождения собеседования, однако при этом они имеют мало отношения к рабочим обязанностям.
Задачи на знание алгоритмов на собеседовании показывают только одно: кандидат достаточно натаскан, чтобы узнавать паттерны и подбирать решения. Но об общем уровне подготовки разработчика они ничего не говорят – они требуют не умения решать проблемы, а умения выявлять знакомое и длительной практики.
Сосредоточившись на способности кандидата решать задачи на алгоритмы в искусственных условиях, вы пренебрегаете другими факторами, необходимыми при разработке приложений. Самый существенный из них сводится к тому, умеет ли кандидат преобразовать требования в решения, которые закрывают потребности бизнеса. Клиентов, приходящих с запросом отсортировать пузырьком лучше, чем у конкурентов, немного. Кроме того, ИИ уже сейчас справляется с этим успешнее, чем люди (AlphaDev предложил алгоритм, который производит сортировку на 70% быстрее, чем существующие, для библиотеки libcc++).
В лучшем случае вы отберете людей, которые способны с хорошей производительностью заниматься разработкой. В общем случае вы отберете людей, которые достаточно корпели над алгоритмами, чтобы справиться с заданиями на собеседовании. В худшем случае, вы оттолкнете многих кандидатов (например, нейроотличных) попытками подловить их незнании особо затейливых алгоритмов.
Так что же делать, вместо того чтобы прибегать к алгоритмам на собеседованиях? Создавайте задачи, которые в большей степени напоминают то, чем, по вашим ожиданиям, разработчику придется регулярно заниматься на работе, и которые связаны с навыками, необходимыми для этой работы.
Например, попробуйте сосредоточиться на сигналах такого рода:
Не знаете, с чего начать подобную проверку? Coding Challenges – отличный ресурс с задачами, подходящими под эти требования. Они будут хорошим подспорьем для подготовки к собеседованию, неважно ведете ли вы его или проходите.
Изучение алгоритмов в целом повысит ваш уровень как разработчика. Но это не значит, что вы обязаны уметь с ними справляться с ними за полчаса, параллельно объясняя свой ход мысли. Подобные умения не имеют ничего общего с проблемами, которые в реальности возникают при разработке ПО. Они имеют какую-то ценность только в искусственной среде собеседований, которая ущербна и нуждается в изменениях.
Советую вам начинать разбираться со сложными алгоритмами, когда у вас есть свободное время и на вас не давит необходимость как можно скорее найти работу. Самое полезное, что вы можете узнать в процессе их изучения – нотация Big O и сложность. Понимание Big O поможет вам выявлять излишнюю сложность при разработке приложений и систем.
Если вы хотите отправить резюме в компанию, которая использует задачи на алгоритмы для отбора кандидатов, то у вас только два варианта:
Только один из этих вариантов повышает ваши шансы получить работу. Если она вам нужна, идите по второму пути. У подобных собеседований есть серьезные недостатки. К сожалению, если вы хотите устроиться в компанию и не можете позволить себе роскошь настаивать на своем, вам придется справиться с заданиями, чтобы добиться желаемого.
Вот список ресурсов, которые помогут вам в изучении алгоритмов и Big-O.
Мне хотелось бы увидеть перемены в нашем подходе к проведению технических собеседований. Сам я не даю таких заданий на собеседованиях, которые организую.
Если вам предстоит провести собеседование, подумайте, каким образом будете оценивать технические навыки. Если та вакансия, на которую вы ищете человека, действительно предполагает работу с алгоритмами, то, разумеется, без колебаний проверяйте эти знания. Если речь идет о разработке и приложений или чем-то более абстрактном, то завязывайте с этим.
Большинство вакансий рассчитано на что-то между разработкой приложений и системным дизайном. Но при этом многие из тех, кто проводит технические собеседования, уделяют время только задачам на знание алгоритмов и системного дизайна – и ничему больше.
Такой подход основан на идее, что, если человек знаком с алгоритмами и системным дизайном, то и на разработку приложений ему хватит способностей. Это спорное утверждение. Создание приложений требует обширного набора навыков. Они не нарабатываются сотнями часов заучивания паттернов в решениях задач на алгоритмы. Да и рассматриванием сильно упрощенных версий системного дизайна Netflix, Uber или Twitter Threads делу не поможешь. Навыки разработки приложений оттачиваются путем… ну, разработки приложений. Но часто на технических собеседованиях они даже не принимаются в расчет.
Собеседования с алгоритмами
Для ясности: я говорю о задачах на алгоритмы в духе LeetCode. Большая часть подобных собеседований, на которых мне приходилось бывать, включала задачи среднего и выше уровня с этого ресурса. Обычно их объединяют под названием «структуры данных и алгоритмы».
Как правило, собеседование на знание алгоритмов разворачивается таким образом: кандидату дают задачу, которую он должен решить и для которой должен определить уровень сложности при помощи нотации Big O максимум за тридцать минут. Само собеседование чаще всего длится дольше, но какое-то время уходит на приветствия и обсуждение прочих вопросов.
Предполагается, что кандидат начнет выполнение задания с устного разбора, а затем уже приступит к написанию кода. В процессе решения требуется объяснять свой ход мысли от действия к действию.
Вот несколько примеров таких заданий:
- Максимальная площадь (средний уровень сложности на LeetCode): Дана бинарная матрица m x n, заполненная нулями и единицами. Нужно определить наибольшую по размеру область, которая содержит в себе только единицы, и рассчитать ее площадь.
- Самая длинная подстрока без повторяющихся символов (средний уровень сложности на LeetCode): дана строка s, нужно рассчитать длину самой длинной подстроки без повторяющихся символов.
- Слияние отсортированных списков в количестве k (высокий уровень сложности на LeetCode): даны связные списки в количестве k, каждый из них отсортирован в порядке возрастания. Нужно слить все связные списки в один отсортированный.
Подобные задачи довольно занимательны, когда можно поразмыслить о них без спешки. Однако в сценарии собеседования временное ограничение и давящее осознание, что от успешного решения зависит трудоустройство, может сильно бить по нервам. Чтобы не поддаться тревоге, кандидаты занимаются подготовкой – решают задачи заранее, чтобы ознакомиться с паттернами.
Книги вроде «Карьеры программиста» (которую рекомендует к прочтению Meta) в один голос говорят о том, что на такого рода подготовку необходимо потратить от нескольких недель до нескольких месяцев, в зависимости от того, какой у вас уровень и насколько хорошо вы знакомы со структурами данных и алгоритмами.
«Вводный курс для собеседований» от LeetCode включает более 93 примеров задач с решениями, более 67 курирующихся заданий для практики и 12 вопросников. На то чтобы одолеть все эти материалы, параллельно работая и пытаясь жить нормальной жизнью, как, полагаю, и обстоят дела у кандидатов, могут уйти месяцы.
И это подводит меня к следующей мысли.
Не тратьте впустую ценное время кандидатов
Типичная серия собеседований включает две сессии, посвященные алгоритмам, и одну, посвященную системному дизайну. То есть 66% времени отведено под то, что разработчик, вероятно, будет использовать на протяжении менее чем 1% от всей продолжительности своей карьеры.
Я занимаюсь разработкой ПО больше двадцати лет. Алгоритмами я занимаюсь только в двух случаях:
- для собственного удовольствия – головоломки весьма увлекательны, когда некуда торопиться и не из-за чего нервничать;
- при подготовке к собеседованиям.
Если же подобные задачи возникают в ходе реальной работы, я использую библиотеки (обычно встроенные), которые прошли с нами огонь и воду. Так как в этой области я не специализируюсь, вероятность того, что я смогу предложить что-то лучше, нулевая.
Очень немногие осваивают алгоритмы непосредственно в процессе работы. Нужно потратить многие часы, чтобы изучить их на уровне, достаточном для успешного прохождения собеседования, однако при этом они имеют мало отношения к рабочим обязанностям.
Собеседования, построенные на алгоритмах, дают ложные сигналы
Задачи на знание алгоритмов на собеседовании показывают только одно: кандидат достаточно натаскан, чтобы узнавать паттерны и подбирать решения. Но об общем уровне подготовки разработчика они ничего не говорят – они требуют не умения решать проблемы, а умения выявлять знакомое и длительной практики.
Сосредоточившись на способности кандидата решать задачи на алгоритмы в искусственных условиях, вы пренебрегаете другими факторами, необходимыми при разработке приложений. Самый существенный из них сводится к тому, умеет ли кандидат преобразовать требования в решения, которые закрывают потребности бизнеса. Клиентов, приходящих с запросом отсортировать пузырьком лучше, чем у конкурентов, немного. Кроме того, ИИ уже сейчас справляется с этим успешнее, чем люди (AlphaDev предложил алгоритм, который производит сортировку на 70% быстрее, чем существующие, для библиотеки libcc++).
В лучшем случае вы отберете людей, которые способны с хорошей производительностью заниматься разработкой. В общем случае вы отберете людей, которые достаточно корпели над алгоритмами, чтобы справиться с заданиями на собеседовании. В худшем случае, вы оттолкнете многих кандидатов (например, нейроотличных) попытками подловить их незнании особо затейливых алгоритмов.
Альтернативы для рассмотрения
Так что же делать, вместо того чтобы прибегать к алгоритмам на собеседованиях? Создавайте задачи, которые в большей степени напоминают то, чем, по вашим ожиданиям, разработчику придется регулярно заниматься на работе, и которые связаны с навыками, необходимыми для этой работы.
Например, попробуйте сосредоточиться на сигналах такого рода:
- Способность переводить потребности бизнеса, функциональные и нефункциональные требования в эффективные решения
- Умение разбивать сложные проекты на доступные задачи и шаги
- Применение дизайн-паттернов
- Использование определенных принципов при построении архитектуры, например Event Driven Design, API First или Buy vs. Build.
- Способность определить, что стоит автоматизировать (например, билды и тесты при непрерывной интеграции)
- Умение результативно проводить инспекцию кода и понимание преимуществ этой процедуры
- Понимание плюсов и минусов использования корутинов async и threading при работе с серверами
- Умение выявлять возможности для оптимизации производительности кода
- Способность находить баги и устранять проблемы в предложенном фрагменте кода
- Умение проводить рефакторинг с прицелом на большую читабельность и простоту для поддержки
- Эффективная интеграция API в ПО
Не знаете, с чего начать подобную проверку? Coding Challenges – отличный ресурс с задачами, подходящими под эти требования. Они будут хорошим подспорьем для подготовки к собеседованию, неважно ведете ли вы его или проходите.
Стоит ли мне изучать алгоритмы?
Изучение алгоритмов в целом повысит ваш уровень как разработчика. Но это не значит, что вы обязаны уметь с ними справляться с ними за полчаса, параллельно объясняя свой ход мысли. Подобные умения не имеют ничего общего с проблемами, которые в реальности возникают при разработке ПО. Они имеют какую-то ценность только в искусственной среде собеседований, которая ущербна и нуждается в изменениях.
Советую вам начинать разбираться со сложными алгоритмами, когда у вас есть свободное время и на вас не давит необходимость как можно скорее найти работу. Самое полезное, что вы можете узнать в процессе их изучения – нотация Big O и сложность. Понимание Big O поможет вам выявлять излишнюю сложность при разработке приложений и систем.
Если вы хотите отправить резюме в компанию, которая использует задачи на алгоритмы для отбора кандидатов, то у вас только два варианта:
- отказаться делать задания такого рода
- изучить алгоритмы и отработать выполнение заданий в среде, близкой к условиям собеседования
Только один из этих вариантов повышает ваши шансы получить работу. Если она вам нужна, идите по второму пути. У подобных собеседований есть серьезные недостатки. К сожалению, если вы хотите устроиться в компанию и не можете позволить себе роскошь настаивать на своем, вам придется справиться с заданиями, чтобы добиться желаемого.
Вот список ресурсов, которые помогут вам в изучении алгоритмов и Big-O.
В заключение
Мне хотелось бы увидеть перемены в нашем подходе к проведению технических собеседований. Сам я не даю таких заданий на собеседованиях, которые организую.
Если вам предстоит провести собеседование, подумайте, каким образом будете оценивать технические навыки. Если та вакансия, на которую вы ищете человека, действительно предполагает работу с алгоритмами, то, разумеется, без колебаний проверяйте эти знания. Если речь идет о разработке и приложений или чем-то более абстрактном, то завязывайте с этим.
