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

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

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

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

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

Внутри «Совести» мы работаем по гибким практикам (agile), в продуктовых командах, поэтому для нас важно, чтобы кандидаты не только имели глубокие знания в своей области, но и обладали гибким мышлением, были готовыми к сложным задачам. Чтобы понять ход мыслей, логику, мы предлагаем на собеседовании решить несколько кейсов.

Примеры задач на SQL 

Задача 1:
Есть таблица, в которой записаны 9 не повторяющихся чисел от 1 до 10. Нужно написать скрипт, который вернет недостающее число.

Подсказка: можно написать, как это можно сделать с помощью создания таблицы (что создать, с какими данными и как написать итоговый селект).

Задача 2:
Нужно написать скрипт, который вернет id заявки и фио (ID) клиентов, которым на момент обращения в банк (то есть заведения заявки) было менее 18 лет.

Есть 2 таблицы:
Applications c полями
app_id — номер заявки,
app_dt — дата заведения заявки,
status,
client_id — id клиента,
empl_id — id сотрудника,
credit_id — id договора (если он был оформлен, иначе — пусто).

Clients
Client_id,
Surname,
Firstname,
Middlename,
Birth_dt,
Passport
Pass_dt
Update_dt – дата занесения записи.

Подсказка: использовать функции с данными.

Примеры задач из алгоритмического теста (начинающим программистам)

Задача 1:
Объявлены две числовые переменные a и b. Необходимо сделать так, чтобы без объявления других переменных в результате работы алгоритма значения переменных поменялись местами. (Например, если изначально a = 3, b = 5, то в результате алгоритма стало a = 5, b = 3). Применять можно только операции присваивания и арифметические операции с числами и значениями переменных.

Задача 2:
За один цикл вычислить значение функции, используя только элементарные арифметические операции (+ — : *)
F(n) = 1! * 2! * 3! * … * n!, где n!= 1*2*3*…*n.

Задача 3:
Дано натуральное число n. С помощью рекурсивной функции и не используя циклы, выведите все числа от 1 до n.

Примеры задач на логическое мышление

Задача 1:
Я вошел в комнату, чтобы взять из шкафа свои ботинки и носки. В комнате спала сестра, и было совсем темно. Я хорошо знал, в каком месте шкафа находятся мои три пары ботинок — все разных фасонов, и 12 пар носков — черных и коричневых. Мне не хотелось зажигать свет, чтобы не разбудить сестру. Действительно, как ботинки, так и носки я обнаружил на своих местах, но, должен признаться, в беспорядке — просто груду из 6 ботинок и кучу из 24 носков. Сколько ботинок и сколько носков (самое меньшее) мне надо вынести из темной комнаты в светлую, чтобы обеспечить себя парой ботинок одного фасона и парой носков одного цвета, при этом фасон обуви и цвет носков мне были безразличны?

Ответ: четыре ботинка и три носка. Среди 4 ботинок, взятых из шкафа, 2 обязательно будут одного фасона; среди 3 носков два будут одного цвета. Если же взять только 2 или 3 ботинка, то может случиться так, что они все окажутся разных фасонов, и если взять только 2 носка, то эти носки могут оказаться разной окраски.

Задача 2:
Имеется 9 одинаковых монет, но одна из них легче остальных. Необходимо за два взвешивания на весах найти эту монету. Весы — обычные с двумя чашкам,  т.е. рычажные.

Мы в компании чаще всего проводим кейсовые интервью. При этом собеседование разбиваем на две, иногда три части.
В первой предлагаем соискателю стандартную рабочую ситуацию: даём вводные, описываем условия работы и дальше предоставляем ему слово. И мне как HR-специалисту, и моим коллегам из отделов в этом случае интересна сама логика действий потенциального сотрудника. Такая смоделированная ситуация помогает понять, может ли он мыслить стратегически, как планирует распределять свои ресурсы и ресурсы коллег. Кроме того, уже на этом этапе мы можем увидеть, командный к нам пришел человек или нет.

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

Наконец, последний этап – разыгрывание «фантастического», заведомо нерешаемого кейса. До него доходит не всегда: если мы видим, что человек «плавает» даже в стандартной ситуации, нет смысла предлагать ему что-то из ряда вон выходящее. Но, когда с предыдущими кейсами соискатель справляется хорошо, «фантастический» открывает перед нами многие двери. Здесь мы проверяем мотивацию кандидата, его креативность, можем задавать уточняющие вопросы, в том числе на морально-этические темы. Правильных ответов может и не быть. Но то, как человек держится, какие альтернативы решения проблемы предлагает, практически точно дает нам понять, стоит ли его принимать на работу или нет.

Конечно, при найме в IT-индустрию одни кейсы не помогут. Мы не забываем и о специфических, профессиональных задачах. Но практика показывает, что техническими интервью нельзя злоупотреблять. Они отнимают много времени у соискателей и часто только нервируют их. Поэтому важно «считывать», какой человек пришел на собеседование и какой формат интервью с ним станет наиболее эффективным.

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

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

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

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

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

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

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

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

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

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

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

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