На конференциях часто на стендах раздают подарки. Обычно нужно решить какую-то задачку.

Невинная головоломка

Некоторые из задач предусматривают решение головоломки с кодом, вроде такой:

Каким будет результат выполнения следующего кода:

public class Sum {

    public static void main(String[] args) {
        System.out.println(0123 + 3210);
    }
}

1. 3293
2. 3333
3. Этот код не компилируется
4. Этот код приводит к ошибке IllegalArgumentException
5. Ничего из вышеперечисленного

Моя обычная реакция — или немедленно покинуть стенд, или, если время позволяет, набрать код на ноутбуке, чтобы посмотреть результат (или поискать в Google). Вы можете упрекнуть меня в лености, но я предпочитаю представлять себя экспертом по тайм-менеджменту.

tl;dr: Вопросы и задачи на собеседованиях по программированию кажутся излишне сложными. Иногда так и есть, что добавляет стресса. Это не единственный довод против них. Наши данные показывают, что более сложные задачи на самом деле хуже предсказывают конечный результат, чем более простые.

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

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