Какие задачи дают кандидатам на собеседовании?

Наш подписчик интересуется:

Поделитесь, пожалуйста, задачками с собеседований, которые вы задаёте кандидатам.

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


Всеволод Шмыров, разработчик в команде API Яндекс.Карт

Немного базовых вопросов, немного хитростей языка. Прошу показать проекты и рассказать о своем участии в них.


Игорь Цупко, эксперт IT-конференции «Стачка»

Я сейчас активно ищу тимлидов, поэтому большая часть задач на проектирование и широту кругозора. Например, очень хорошая тема для разговора — такая задачка:

У вас есть два сервера А и Б. На сервере А по адресу urlA есть скрипт, который с помощью curl тянет данные с сервера Б по адресу urlB. Когда мы открываем urlA в браузере, видим пустую страницу. Когда мы открываем urlB в браузере — «Hello world». Расскажите, как будете производить отладку в формате «зайду на сервер X, посмотрю там-то, если увижу такое-то значение, то проблема в этом направлении, если другое значение, то проблема в том направлении».


Степан Чельцов, эксперт IT-конференции «Стачка»

Мы ищем программистов не просто так, они нужны для вполне конкретных задач. Если мы знаем ответы на вопросы, которые должен решать будущий разработчик, мы даем соответствующие проверочные задания. Например, нам предстоит делать много запросов к базе данных, сортировать файлы, переназначать файл различным сущностям. Соответственно, мы даем задачу таким образом, чтобы проверить понимание программистом системы на нагрузку на базу от того кода, который он напишет. То есть: «Сравните файлы, которые лежат в определённой папке и выведите на экране список проделанных работ».

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

Или, например, другой вариант задачи. Нам предстоит интенсивно проработать интеграцию с другими сервисами. Важно ли нам знать в данной ситуации, какие у нас есть права доступа? Конечно, важно. Важно ли нам учитывать не только право доступа конкретных людей и разделение на проекты, на контрагентов, на финансовые ограничения манипуляций? Конечно, важно. В этом случае мы дадим задачу нашему будущему программисту максимально широко, например: «Напишите форму авторизации в системе из 10 проектов и пяти ролей. В каждом проекте укажите, что будете проверять в случае ошибки, сделанной пользователем в различных ситуациях».

Зачем нам здесь упоминать пользователей, которые ошибаются? Тут я как работодатель хочу видеть логику мышления программиста. Если он выведет какую-то строчку кода просто как ошибку, мне это неинтересно: мне придётся учить этого человека дополнительным знаниям. Но если он сделает красивое оформление или хотя бы понятно оформленный ответ и причину проблемы для пользователей, нам будет, о чем с ним поговорить.


Алексей Бородкин, эксперт IT-конференции «Стачка»

Я отвечаю за продуктовый дизайн и инженеров-проектировщиков, поэтому делюсь задачей для кандидатов в специалисты по продукту:

Нужно сделать прототипы интерфейсов сайта, который торгует фотообоями. Количество прототипов на ваше усмотрение. Всё делать не надо, достаточно ключевых, на ваш взгляд, страниц (и вообще недостающую информацию и вводные данные можно смело придумывать. Речь идет не про боевое применение, интересно посмотреть на ход мыслей).

Вот рефы разной степени убойности:

— http://www.fotooboi.ru
— http://wall-photo.ru
— http://paperhanger.ru

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

Знаю, задача получилась размытая, но это тоже часть испытания. Работать в дефиците информации и со странными вводными нам приходится постоянно.

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


Алексей Зверев, руководитель направления образовательных программ СКБ Контур, партнёр международной олимпиады «IT-Планета»

Для собеседования я, как правило, даю короткое тестовое задание на 15-20 минут по написанию кода автотеста rest api сервиса http://httpbin.org/.
Помимо этого мне интересно услышать и поговорить о решении тех или иных задач из практики кандидата. Это позволяет мне узнать как особенности и подходы по реализации решения проблем, так и сравнить их с моим опытом и узнать что-то новое для себя.
Из шуточных задач для расслабления мне нравится такая: «Представьте, что вы едете в двухместном автомобиле по дороге, окруженной лесом. Вокруг идёт дождь. На обочине вы видите трех человек: вашего лучшего друга, бабушку и девушку вашей мечты. Предложите наилучшее развитие дальнейших событий, которое удовлетворило бы всех участников истории». Но я не рассматриваю ее как основополагающую при принятии решения.


Алла Клименко, эксперт IT-конференции «Стачка»

Задачки кандидатам у нас готовят программисты и дизайнеры (в зависимости от того, на какую позицию ищем кандидата). В целом же основное, на что мы смотрим при приеме на работу, это аккаунт на GitHub либо портфолио (в случае с дизайном). Это главные критерии, по которым мы решаем, нанимать кандидата или нет.


Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на admin@tproger.ru, мы расскажем как это сделать.