Материалы, которые помогут подготовиться к техническому собеседованию

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

Постарайтесь перед собеседованием вспомнить или подумать о следующем:

Самые интересные ваши проекты с технической точки зрения или принесенной бизнес-пользы. Здесь важна ваша личная оценка, хочется увидеть, чем именно вы гордитесь.

О каких своих проектах вы готовы говорить подробно, включая архитектуру системы и обоснование, почему были выбраны конкретные технические решения? Нам хочется видеть ваш опыт в области проектирования, если он имеется.

Каков был ваш личный вклад в разрабатываемые продукты? За какую часть системы отвечали именно вы?

Может быть, были ситуации, в которых вы брали инициативу на себя и добивались успеха?

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

Большая часть продуктов, которые мы делаем в Контуре, является распределёнными веб-сервисами. Поэтому мы уделяем повышенное внимание пониманию и умению проектирования таких систем.

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

Ресурсы для подготовки:

System design primer на github

Мартин Клеппман «Высоконагруженные приложения»

Трилогия книг по Site Reliability Engineering от Google

Глубокая проверка знаний алгоритмов на собеседовании — спорная тема. И хотя мы уважаем алгоритмический кругозор и умение писать эффективный код (Контур, например, является спонсором студенческого чемпионата Урала по программированию, и у нас много разработчиков с опытом спортивного программирования), мы не считаем, что каждый разработчик должен писать по памяти алгоритм Кнута — Морриса — Пратта или искать максимальный поток в графе.

Тем не менее мы рассчитываем, что любой разработчик должен быть способен увидеть на ревью серьезную неэффективность реализации («этот метод переусложнён и работает за куб, хотя интуитивно кажется, что тут должно быть линейно — сервис будет тормозить»). А также понять, о чем речь, и всё исправить, когда эту неэффективность заметили у него.

Для этого нужно владеть общим базовым понятийным аппаратом (O-нотацией), даже если и не в строгом математическом смысле. Научиться и потренироваться можно, пройдя короткий курс:

«Оценка сложности алгоритмов» на ulearn.me

Кроме того, нужно иметь представление о базовых, ежедневно используемых, структурах данных (включая асимптотику основных операций с ними):

Динамический массив (Википедия)

Хеш-таблица (Википедия)

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

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

Чего мы ждем от каждого кандидата — так это умения читать и вносить правки в код на C# (мы даем готовый фрагмент кода для ревью), а также знания основных структур данных: List, Dictionary, HashSet. Если вы переходите с другого стека, то полезно познакомиться с основными методами работы с коллекциями в декларативном стиле (LINQ):

«Практикум по языку запросов LINQ» на ulearn.me

Также мы хотим видеть у будущего коллеги понимание принципов конкурентного и асинхронного взаимодействия. Рекомендуем почитать Стивена Клири:

Stephen Cleary — Async and Await

Stephen Cleary — There Is No Thread

И другие статьи из его блога или же его книгу «Concurrency in C# Cookbook»