Месье, ваши problem solving skills не на высоте, или как я провалил одно собеседование

    Предлагаю вашему вниманию небольшую историю моего провала и того как, порой, бывают безлики проверки на умение "решать задачи/проблемы" во время собеседований.

    image

    Начало


    Примерно месяц назад со мной связался охотница за головами из одной крупной софтверной компании. Она объяснила, что навыки и опыт, указанные в моем резюме, заинтересовали компанию, которую она представляет, и вкратце описала, какой профиль она разыскивает. Я ответил, что всегда мечтал работать на их компанию в принципе описанный пост выглядит заманчиво. После чего она сказала, что мой профиль будет рассмотрен их командой и в случае успеха она предложит мне пройти собеседование удаленно, по видео чату. Профиль мой приглянулся и мы договорились о дате собеседования.

    Собеседование


    Началось все довольно неплохо, мне была задана пара вопросов о подходах к разработке ПО, обеспечения качества ПО. Так же парочка по дизайну распределенных систем, и что-то еще на похожие темы. На все вопросы я ответил без особого труда, внятно, с чувством, с толком и расстановкой. После получаса общения мне предложили протестировать мои problems solving skills, я не возражал, поскольку мне казалось, что если мой профиль им понравился, то и спросят у меня тоже, что-нибудь профильное, да не тут то было.

    Задача


    Для простоты я буду использовать в этой статье javascript для описания кода. Итак, у нас имеется бинарное дерево

              1
             / \
            2   3
          /     / \
         4     6   7

    Нужно связать все узлы по горизонтали, слева направо, чтобы получилось:

              1-> Nil
             / \
            2-> 3-> Nil
           /   / \
         4 -> 6-> 7-> Nil

    Каждый узел может быть описан в виде:

    function Node(data) {
        this.data = data;
        this.left = this.right = null;
        this.neighbour = null;
    }

    Обстановка и условия для решения задачи


    Меня попросили решить данную задачу с использованием, своего рода, онлайн блокнота, где мой собеседник накидал задание и наблюдал за тем, как я набиваю мое решение. Скажу честно, блокнот, даже онлайновый, вышиб меня из колеи. Оригинал кода задания был сделан на псевдо C#, но я предпочитаю javascript.

    Провал и его последствия


    Скажу честно, я сглупил и решил зазвездить решение без рекурсии, на базе вертикального прохода дерева, слой за слоем. Я начал писать код но через 5 минут понял что этого не достаточно. Еще через 5 минут я понял что окончательно заблудился и начал паниковать. Мой собеседник давал мне подсказки, которые, из-за моего состояния вгоняли меня еще в больший ступор. В конце концов, после ~30 минут дырканья и мырканья, я сдался и сказал, что не могу решить задачу сходу. Это был полный провал.

    Продолжение


    В конце концов я попрощался с собеседником и после 5 минут обдумывания всего процесса, отходников и успокоения я открыл мой профессиональный ноут и запустил мой любимый, ламповый IDE, и тут понеслось.

    Решение 1, в лоб


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

    BinaryTree.prototype.findLinkedNeighbours = function (entry) {
        var links = [];
        var node = entry || this.root;
        var i, j, size;
        this.navigate(node, 0, links);
        size = links.length;
        for (i = 1; i < size; i++) {
            var link = links[i];
            var linkLength = link.length;
            if (linkLength < 2) {
                continue;
            }
            for (j = 1; j < linkLength; j++) {
                link[j-1].neighbour = link[j];
            }
        }
    };
    
    BinaryTree.prototype.navigate = function (node, level, links) {
        if (node === null) {
            return;
        }
        if(!links[level]) {
            links[level] = [];
        }
        links[level].push(node);
        this.navigate(node.left, level + 1, links);
        this.navigate(node.right, level + 1, links);
    };

    Данное решение не блещет ни оригинальностью ни быстродействием. Вердикт:
    Time complexity: O(n), Space complexity: O(n)

    Решение 2, маленькая хитрость.


    Вечером того же дня, когда я мыл посуду, меня озарило. Я вспомнил что бинарные деревья как и графы имеют две различные формы представления. Первая форма реализуется, как мы видели выше, через ссылки между объектами, а вот вторая строится на базе массива. Форма эта используется довольно редко, так как в некоторых случаях, попусту не оптимальна с точки зрения использования памяти. Вот как это выглядит на примере из википедии:
    image

    Для навигации по такому дереву используется следующий подход:

    Для узла i, индекс его левого потомка вычисляется по формуле: 2i+1,
    а индекс его правого потомка вычисляется по формуле: 2i+2.
    Индекс родителя узла находится по формуле: (i-1)/2

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

    BinaryTree.prototype.linkNeighbours = function(array) {
        var pace = 0;
        var level = 0;
        var limit = 0;
        var size = array.length;
        var previous = null;
        while (pace < size) {
            limit = (Math.pow(2, level) + pace);
            for (;pace < limit; pace++) {
                if (array[pace]) {
                    if (previous !== null) {
                        previous.neighbour = array[pace];
                    }
                    previous = array[pace];
                }
            }
            previous = null;
            level++;
        }
    };
    
    BinaryTree.prototype.printNeighbours = function(array) {
        var length = array.length,
            level = 0,
            left = 0,
            right = 0;
        while(right < length) {
            left = right;
            right = Math.pow(2, level) + right;
            console.log(array.slice(left, right)
                .filter(function(x) { return x != null;})
                .map(function(x) {return x.data;})
            );
            level ++;
        }
    };

    По поводу быстродействия можно сказать следующее:
    Time complexity: O(2^h), Space complexity: O(1)
    Просьба не обольщаться O(1) в плане памяти, так как, само по себе представление в виде массива, за частую, бывает не очень эффективно.

    Решение 3, то, к чему я стремился изначально.


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

    LinkedTree.prototype.traverseAndCountingLevel = function() {
        var queue = new Queue();
        var node = this.root;
        var result = [];
        var level = 0, pace = 1, capacity = 1, leafsFactor = 0;
    
        queue.add(node);
    
        while(queue.size() > 0) {
            node = queue.poll();
            if(pace === capacity) {
                result.push([]);
                level++;
                leafsFactor *= 2;
                capacity = (Math.pow(2, level) - leafsFactor);
                pace = 0;
            }
            result[result.length-1].push(node.data);
    
            if (node.left !== null) {
                queue.add(node.left);
            } else {
                leafsFactor += 1;
            }
            if (node.right !== null) {
                queue.add(node.right);
            } else {
                leafsFactor += 1;
            }
            pace += 2;
        }
        return result;
    };

    Сводка по быстродействию:
    Time complexity: O(n), Space complexity: O(n)
    В расчеты я не взял массив result, так как для решения задачи он в принципе не нужен. По поводу памяти могу сказать что в сбалансированном дереве это будет больше походить на O(log n) а в разбалансированном на O(n).

    Заключение


    Как можно догадаться, компания ответила мне отказом, мотивируя его тем, что мое умение решать проблемы не соответствует их требованиям. Я согласен, что это самое умение у меня работает гораздо лучше, когда я нахожусь под душем в спокойной обстановке, используя при этом конкретный IDE и конкретный язык программирования, вместо блокнота и псевдоязыка. Я ни в коем случае не пытаюсь оправдаться. Может быть, работодатель действительно искал человека способного быть продуктивным в стрессовой ситуации, поскольку стресс и тайм-прессинг это их родная среда. Даже, быть может они, в целях экономии решили отказаться от всех IDE и работают только в блокноте.

    Если вы работодатель и вы пытаетесь отбирать сотрудников используя подобную методологию, быть может, вы ошибаетесь? Если вы соискатель, вы теперь знаете, что примерно подразумевается под этим пресловутым термином — problem solving skills.

    Правки

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

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

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

    Можно ли вообще назвать такие проверки проверками на умение решать задачи/проблемы?

    Поделиться публикацией

    Комментарии 474

      +22
      Оба голосования неполны (и потому предвзяты). Отсутствует пункт «определяется спецификой выполняемой работы». IMHO, разумеется.
      Обида конечно понятна, но возможно действительно искали человека, способного решать такие задачи без любимой IDE.
        +7
        но возможно действительно искали человека, способного решать такие задачи без любимой IDE

        А мне вот интересно, какая работа предполагает такое требование, плюс стрессовые ситуации?
          +1
          Детали рассказывать не буду, но на одном проекте пришлось на JS писать скрипты для настройки оборудования Cisco.
          Из инструментов, по большому счёту, был блокнот.
            +1
            Кстати, процесс «собеседования» на этот проект был тоже… своеобразный
              +1
              Было бы интересно прочитать об этом
                +1
                Не могу, к сожалению
                  –1
                  Вы подписывали NDA до прохождения собеседования? Это невероятно!
                    +1
                    Кто Вам такое сказал?
                      +1
                      Это был вопрос. Мне никто не говорил. Но если NDA не подписан, то вопросами и ответами делиться никто не запрещает.
                        +1
                        Даже если я подписал после, не вижу возможности разглашать то, что происходило до подписания. И да, часто NDA подписывается до собеседования.
                      +3
                      Почти все крупные фирмы требуют подписать NDA до прохождения собеседования. Конечно обычно они не слишком серьёзно смотрят на то как этот NDA соблюдается: максимум чем вы реально рискуете — это попасть «в чёрный список» и потерять возможность устроится туда на работу в будущем. Тащить вас в суд, скорее всего, не будут, так как вы вряд ли услышите на собеседовании что-то настолько секретное, но всё равно: люди, подписывашие NDA обычно его потом стараются соблюдать…
                        +1
                        Мне не попадались такие фирмы. Поэтому я удивился искренне.
                0
                Но при этом за Вами же не следили, как вы пишете код? В добавок написание настроек это больше рутинная задача.
                  +2
                  Ох, поверьте, рутины там было мало. Вся работа — одно сплошное приключение, растянувшееся на год.
                  На собеседовании, не то чтобы следили. Общались очень плотно.
                  +1
                  Из инструментов, по большому счёту, был блокнот.
                  Из соображений секретности, безопасности и недоступности по сети?
                    +2
                    Из соображений глубокой костыльности. Не было там стандартных решений (именно по этому направлению).
                    Нельзя было, например, отладить код в какой либо IDE. Задача не позволяла.
                      +2
                      Интересно, почему всё же нельзя было поставить IDE, поддерживающую JS, или, в крайнем случае, Notepad++? Запрещалось ставить сторонний софт? Платформа была не Windows/i386 и вообще не i386? Не было физической возможности закачать на диск инсталлятор (или уже развёрнутую программу, если она не требовала инсталляции)? Почему нельзя было перенести скрипт на более удобную машину, там отредактировать, а потом перенести обратно?
                        0
                        Ставить можно было что угодно. В работе это не помогало. Notepad++ отдельные товарищи пользовали, я не любитель.
                        Просто задачка не очень традиционная. Не Web. Сложно объяснить не вдаваясь в детали. Всё было завязано на сторонний фреймворк.
                        Наверное можно было написать обвязку для отладки этого всего под IDE, но времени на эксперименты не было.
                          +3
                          Давайте я про свой случай расскажу, что ли. Исходники лежат в папке [условно] /src, куда смонтрирована кластерная файловая система, сколько тех исходников знает только Господь Бог и сисадмин (известно только что терабайтов там много, но петабайт, вроде как, пока нету). Как несложно догадаться никакого Windows/i386 нет и не планируется, собирается всё командой, условно, build (тоже где-то в облаке), общаться с программой можно через встроенный в неё web-сервер (сама программа при этом работает, опять-таки, в облаке — там где её поднимет условная команда run). Не так давно думали что делать с тем, что в кое-каких системах упёрлись в старое древнее ограничение в 2GiB кода в одной библиотеке под Linux'ом.

                          Ваши действия? С какой стороны прикручивать IDE? И как она вам поможет отлаживать код?

                          P.S. Кстати какое-то количество разработчиков у нас использует IDE. Eclipse, IDEA, CLion. Не могу сказать, что кода от них поступает заметно больше, чем от других.
                            +1
                            Если есть web-интерфейс, то всё не так плохо. Можно использовать либо Copy-Paste либо download-upload. Если скрипты на JS, то можно использовать Notepad++, чтобы совсем тупо не накосячить с несбалансированными скобками и незаконченными строками, и, наверное, как-то, ограниченно и с тупыми самописными mock'ами, консоль «хрома» или вообще node.js REPL.
                              +2
                              Notepad++ — это всё-таки не совсем IDE. Использовать IDE как «крутой текстовый редактор» — да, можно, но обычно под «использованием IDE» понимается что-то несколько другое.
                      0
                      «Настройки оборудования Cisco» звучит страшно. На самом деле вещь очень простая — текст.
                      Я думаю что 90 процентов цисковиков настройки циско в блокноте пишут и не жужжат.
                      Используя perl или python для разворачивания шаблонов.

                      В итоге — не убедили. Не нужны эти скилзы.
                        0
                        Я как бы и не стремился Вас убеждать. Меня попросили пример — я дал (настолько подробно насколько мог). Верить или нет — ваше дело. Разумеется, сложность была не в Cisco (я вообще не цискарь). Просто конкретно в этой работе IDE не помогало никак. И да, все пользовались блокнотом и не жужжали.
                        +1
                        А разве нельзя такой написать в удобной IDE с автодополнениями, подсветкой и отладкой, а потом скопипастить на Cisco, или даже просто переписать с экрана на экран, если нет никаких телнетов?
                          +1
                          Мы писали не конфигурацию Cisco, а JavaScript-код конфигурирующий Cisco. И сверху была ещё высокоуровневая обвязка на том же JavaScript, которая дёргалась из Java-фреймворка. Писать JavaScript код в IDE было конечно можно, но копипастить его было некуда.
                        +2
                        Стрессовые ли?
                        Сидя дома за своим компьютером, а не добираясь до офиса компании в людном метро или пробираясь через пробки на машине…
                          +12
                          Мне вот не совсем понятно, почему данная ситуация считается стрессовой? То, что для автора она была таковой, вовсе не значит, что собеседник этого и добивался. Мне даже кажется, что он давал подсказки, чтобы разрядить ситуацию и помочь. И возможно ждал бы решения еще полчаса, если бы автор попросту не сдался.
                          А само решение задач не должно зависеть от IDE или блокнота. Если в голове есть представление алгоритма, то описать его псевдокодом или js не должно составлять труда. Разве-что без IDE и autocomplete программист не помнит языковых конструкций, ну это не делает ему чести.
                            +6
                            почему данная ситуация считается стрессовой?

                            1. Отсутствие привычной среды разработки. Автора вывели из зоны комфорта, заставив писать не в любимой IDE.
                            2. Работа под присмотром. В комментариях ниже очень красочно описали, каково это
                            habrahabr.ru/post/276673/#comment_8764473
                            habrahabr.ru/post/276673/#comment_8764489
                            3. Академическая задача. Когда на собеседовании предлагают решать задачу не из списка часто практикуемых, то это тоже может выбить из колеи.
                              +14
                              1. На большинстве собеседований у кандидата на должность есть только листок и ручка и это стандартная практика, а не вывод из зоны комфорта.
                              2. Опять-же более чем стандартная практика для любого собеседования.
                              3. Во время работы задача не из списка часто практикуемых как мне кажется норма, если уж человек не является очень уж узким специалистом.

                              А вообще как мне кажется если бы человек вместо того чтобы сразу начать писать код в дискомфортной для него ситуации предложил бы начать с наброска блок-схемы решения ему врядли бы отказали и это сильно бы упростило процесс.
                                +1
                                Я согласен с Вами, что это обычная практика, я просто отвечал на вопрос: почему данная ситуация считается стрессовой?
                                  +9
                                  Ох уж эти «стандартные практики». Не счесть сколько неимоверных глупостей я слышал перед этой формулой. В итоге, собеседования проходят не те, кто лучше остальных соискателей, а те, кто либо больше других прошел собеседований, либо еще совсем не опытный и не понимает всей серьезности ситуации: первое свое (очень суровое) собеседование я прошел без запинки, а вот на последующих уже заметно волновался, хотя и профессиональные навыки были, разумеется, уже выше.
                                    +3
                                    Я даже на первом собеседовании довольно сильно волновался.
                                    То что проф. навыки были выше помогло бы избежать волнения только в случае если бы вы собеседовались на туже должность что и раньше, а не выше.

                                    Я говорю о том что какую бы глупость вы не увидели на собеседовании это не повод спадать в ступор из-за волнения, тем более если эта глупость считается нормой для 90% собеседований. Вот если бы он рассказывал о чём-то совершенно неожиданном (заставили бы его писать на А4 листе перьевой ручкой) это было бы вполне понятный повод для волнения.
                                      +5
                                      Есть навыки, полезные при программировании и есть навыки, полезные при прохождении собеседований. Если человек часто программирует, то он развивает одни навыки, а если часто проходит собеседования, то совсем другие.
                                      Тут я имел в виду эффект «второго прыжка»: прыгать с парашютом по-настоящему страшно во второй раз, а не в первый.

                                      Про стандартные практики — это не столько по поводу собеседований, сколько вообще в целом, я неоднократно видел ужасные вещи, которые оправдываются тем что «ну а че, все так делают».
                                      Есть весьма веские аргументы в пользу того, что «стандартные практики» при приеме на работу, о которых идет речь, попросту неэффективны.
                                    +1
                                    Обычная практика — ведь не означает — хорошая практика, так ведь?
                                      +1
                                      По умолчанию — означает. То есть обычная практика может быть и плохой (тогда она заменяется на другую «обычную практику»), но «по умолчанию» — она считается хорошей.
                                  +1
                                  Согласен с вам насчет проверки синтаксиса в IDE. Например в моем случае я его использую как, своего рода, REPL, в режиме отладки. Я не считаю что это обязательно, но согласитесь, как же это удобно.
                                    +11
                                    Если в голове есть представление алгоритма, то описать его псевдокодом или js не должно составлять труда.
                                    Но в том-то и проблема, что для нахождения алгоритма (элемнтарного, тривиального алгоритма) потребовалось больше суток! Это, я извиняюсь, вообще как, нормально?

                                    Кроме того в C# (как и в Java, как и в C++) очередь — есть. В JavaScript — нет. Это — тоже грабли, которые соикатель себе подложил сам.

                                    А как ешё должно выглядеть собеседование? Дать элементарную задачу, посмотреть что получится… как иначе-то?
                                      +1
                                      Вообще говоря, и очередь написать не должно составлять проблемы, так что есть она в фреймворке или нет — неважно. Как минимум можно сделать просто массив, пояснив интервьюеру недостатки такого подхода и какие есть более эффективные варианты.
                                        +2
                                        Дык можно и интерпертатор x86 на CSS при желании изобразить! Дело-то не в этом.

                                        Дело просто в том, что «писатели фронтэндов» вообще не думают в терминах очередей, стеков, деревьев. Вот пример. Они даже не осознают, что DOM-дерево — оно таки тоже дерево и при работе с ним могут возникать типичные задачи, связанные с деревьями!

                                        Ну и куда девать такого человека в компании, где на 100 строк кода на «фронтэнде» приходится 10'000 строк на «бэкенде»? Знание JavaScript'а при этом не помешает («бэкенд» тоже может JavaScript использовать… особенно если это, скажем, код для поддержи offine-работы в браузере), но куда ж тут без понимания очередей?
                                    +2
                                    Работа без любимой IDE — уже стрессовая ситуация =)
                                      +5
                                      А кто вам сказал, что у вас будет возможность использовать вашу любимую IDE в будущем? Нет, специально никто палки в колёса вставлять не будет, но если, скажем, проект собирается только под MacOS, то вашу «любимую IDE» может оказаться затруднительно использовать. Бонус — за проект, который собирается тремя системами сборки, две из которых работает под MacOS и две — под Linux (это я не из пальца высысываю, это реальный пример, с которым мы работали пару лет назад).

                                      Если вы без «любимой IDE» 20 строк написать не можете, то может вам и не стоит в подобную компанию собеседоваться?
                                        +4
                                        Как же легко вас можно в стресс вогнать. Берегите нервы.
                                          –1
                                          Все кто про стресс говорит, вы статью читали? У меня не нервы сдали и не стресс был, а была ситуация где я выпал из колеи привычного мыслительного процесса из-за того что слишком много внешних факторов изменились. Термины впасть ступор, got stuck, freeze the brain имеют мало общего со стрессом. Почему было такое окружение, по моим догадкам испытание на стрессо-устойчивость, хотя может мне показалось. Статья кстати не обо мне и о том какой я бедный и несчастный. На мой взгляд я поднял несколько важных вопросов такой статьей, хотя я могу ошибаться.
                                    +15
                                    Скажите спасибо что было онлайн собеседование и у вас был хотя бы онлайн блокнот. А то на листочке A4 писали бы карандашом.
                                      +4
                                      На мой взгляд тут особой разницы нет.
                                        +5
                                        Лично мне «на листочке карандашом» было бы намного комфортнее. Хотя бы в силу того, что при планировании решений рукописной формой пользуюсь регулярно, а эти онлайн-блокноты каждый раз новые и у каждого свои нюансы поведения и отображения.
                                          +1
                                          А кто-то ручку не держал в руках… лет 10-12. Ему заказан путь к собеседованиям?
                                            +3
                                            Как вы это себе представляете?

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

                                            Думаю что подобному уникуму будет несложно решить задачу вообще в уме и потом только вписать её в предложенный онлайновый блокнот…
                                              +1
                                              Я такой человек, приятно познакомиться. Использую планшет и десктоп для заметок и рисования схем. С момента расставания с институтом наверное и страницы в сумме не исписал ручкой.
                                                +1
                                                Я тоже много чего могу накодить не привлекая ручку и бумагу, но если задача реально сложная… Планшета и десктопа не хватает: мало влазит, сложно изменения вносить… за пять минут десять набросков не сделать…

                                                Так что сказанное вами, почти наверняка, обозначает, что вы давненько не решали реально сложных задач.
                                                Каковой, в частности, является любая простая задача на собеседовании. Проверить как вы с этим справитесь — будет вдвойне полезно.
                                                  0
                                                  Скорость создания схем на бумажке или в специализированном ПО — вопрос привычки и умения. Изменения вносить уж точно проще, чем на бумаге, где можно только дописать что-то сверху.
                                                    +2
                                                    Есть люди, которым и текст писать на бумаге удобнее и быстрее, чем набирать на клавиатуре компьютера.
                                                      +1
                                                      Возможно. Повторюсь: пока я таких не встречал. Встречал людей, которые плохо и медленно рисуют схемы на бумаге, таких кто хорошо и быстро делает это на компьютере — не видел.
                                                  0
                                                  Ну, есть к примеру Power Designer. Шариковая ручка — довольно таки неудобный инструмент.
                                                    0
                                                    У шариковой ручки пока ещё разрешение выше, чем у планшета и десктопа (в смысле количества текста и картинок, которые можно уместить на страницу и окинуть взглядом).
                                                      +1
                                                      А ещё она мажет.
                                                      +1
                                                      Смотря для чего. Набросать простенькую схему, обсудить и выбросить на листке бумажки — занятие на две минуты. Я ещё никого не видел, кто бы сделал что-то подобное в Power Designer'е за сравнимое время.

                                                      А вы, напоминаю, идёте работать в команду. Тут общаться как-то придётся. Это когда вы один — можете обдумывать решения в уме (в ванной, в туалете, где хотите) и сразу «набело» врисовывать решения в Power Designer. А когда вы с кем-то общаетесь ничего лучше листка бумаги или доски не придумано (доска чуть менее удобна, но позволяет общаться больше, чем 2-3 участникам).
                                                        +1
                                                        Я никуда не иду. Давно уже пришёл. Больше 20 лет уж как в команде. Ручка используется, да, но не чаще чем Power Designer, Visio и пр. В основном для себя, поскольку рисую и пишу от руки я из рук вон. У других участников команды ситуация с письмом от руки примерно аналогичная.
                                              +1
                                              Я порой могу решать задачки в уме, если достаточно вникну, или с помощью записей, если сложно представить конструкцию. Но это не в стрессовой ситуации, да. Впрочем, у автора аналогично, судя по статье.
                                                +2
                                                Как-то раз тоже в таком же ключе был на собеседовании. Сначала просто общение, потом онлайн общение с будущей командой, а потом онлайн редактор текста, без подсветки. Тоже путался, так как привык уже к vs+r#. В итоге минут через 20, когда я с горем пополам решил проблему, но мне сказали, что решение «в лоб», можно проще и изящнее.
                                                В итоге, потея и путаясь в переменных я завалил тест.
                                                  +5
                                                  Сочувствую Вам, сам бывал в подобной ситуации, когда решение вот здесь и сейчас не приходит в голову, хотя задача простая, а потом, когда успокоюсь решение приходит само (хотя вопрос — а сколько времени ушло на решение, возможно я обдумывал его все время после не удачи… я как-то не задумывался об этом).

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

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

                                                  А еще я сталкивался с ситацие когда требовалось написать рабочий код в онлайн блокноте, я примерно помнил синтаксис и в общих чертах набросал решение, на что мне сказали, что это не годится. :)
                                                    +3
                                                    Я тоже однажды столкнулся с таким. Попросили написать код на листке бумаги. Набросал примерное решение опустив проверки крайних ситуаций для краткости. На что начались придирки что мол тут вы на null не проверили, тут блок finally не написали, и т.п.
                                                    Вот это уже полный идиотизм, я все это опустил думая что проверяют в принципе понимание ситуации.
                                                      +15
                                                      А у меня было задание отсортировать массив в Java, ну я и написал Arrays.sort(<массив>). Собеседующий посмотрел на меня как на идиота и такой — ну это, как бы сортировку напиши какую-нибудь. Я подумал подумал и написал сортировку выбором. Оказалось собеседующий такой сортировки не знаел и пришлось ему доказывать что этот код отсортирует массив, в итоге он ушел вбил код на компе у него заработало. Дальше он попросил выбрать данные из двух таблиц в SQL связав по id. Я написал не через JOIN а через SELECT..WHERE. Собеседующий снова впал в ступор. Тут я ему снова доказывал что JOIN это просто сахар для такой записи. Корчое доказать удалось, но потом я сам не пошел к ним работать.
                                                        +2
                                                        Где можно почитать, что JOIN это сахар для SELECT..WHERE?
                                                            +1
                                                            Это синтаксический сахар потому что я могу получить нужный результат и без JOIN, но JOIN значительно упрощает и сокращает код.
                                                              +3
                                                              Простите, но сомнительный аргумент
                                                                +1
                                                                Эээ, что не так? Что для вас синтаксический сахар?
                                                                  0
                                                                  Практически всегда можно получить нужный результат другим путем, но реализуется ли оно в потрохах точно так же?
                                                                +2
                                                                А не наоборот ли, случаем?
                                                                select-where — это cross join плюс условия.
                                                                Если условие содержит соединение ключей, то cross join можно сократить до inner join.
                                                                  +2
                                                                  Если мы говорим о cross join или inner join запись select-where будет по понятности и краткости примерно эквивалентна. Если мы говорим о left join или full outer join то запись select where будет гораздо длиннее и сложнее.

                                                                  Соответственно когда не было джоинов лепили длинные сложные эквиваленты или бд зависимые запросы. Джоины появившиеся в спецификации SQL эту проблему решили. Поправьте если я не прав.

                                                                    0
                                                                    Профайлер в MSSQL, кстати, преобразовал WHERE в JOIN.

                                                                    Можно попытаться найти, как это решается в MySQL или Postgres — у них же открыты исходники?
                                                        +6
                                                        У меня однажды была обратная ситуация. Собеседование состояло из двух частей: с программистом и с руководителем.
                                                        С программистом вопросы были прикладного характера, на которые я практически на все ответил, потом еще несколько «практических» (код писать) заданий, с которыми я также справился что называется «на ура».
                                                        А дальше предстояло собеседование с руководителем. Я думал, что это будут чисто организационные вопросы, мол какую зарплату хочу, какой график и т.д. А руководитель оказался бывшим программистом и начал спрашивать меня как происходят те или иные вещи на нижнем уровне. Например, как организовано хранение данных в MySQL или как на нижнем уровне передается файл на сайт и т.д. И я «поплыл», поскольку мои знания по большей части прикладного характера, т.е. я знаю, что если по полю БД должен осуществляться поиск, его нужно сделать индексированным, а как это там внутри по кластерам или по страницам разбивается — в этом я не силен.
                                                        В общем, забраковали меня тогда, Было очень обидно, поскольку я обладал требуемыми им знания, но мои знания просто не были увидены.

                                                        А по вашему примеру: как мне кажется, вы должны были предоставить хоть какое-то решение. Пусть «в лоб», пусть громоздкое и плохое, но готовое работающее решение. Вы рано сдались. Поставьте себя на место работодателя: он дал кандидату не особо сложную задачу, а кандидат ее не выполнил. Естественно, он откажет данному кандидату и возьмет на работу того, который выполнит задание.
                                                          0
                                                          Такие навыки нужны только для компаний, у которых практикуется экстремальное программирование. Но в этом случае ни о каком качестве кода не может идти речь.
                                                            +2
                                                            Какие «такие»? Умение решить задачу в блокноте на псевдоязыке?
                                                              –2
                                                              Содержимое задачи здесь вообще не при чем. А вот условия ее решения — быстро, под наблюдением, в не комфортных для разработчика условиях — слишком смахивают именно на экстремальное программирование. Соответственно, именно это и тестируется таким образом.
                                                                +5
                                                                быстро

                                                                Обстановка и условия для решения задачи

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

                                                                Где тут сказано о том, что задача должна быть решена за максимально короткий срок?
                                                                под наблюдением

                                                                Тобишь, если к вашему рабочему месту подойдет коллега и постоит рядом минут 5 читая ваш код, вы не сможете работать?
                                                                в не комфортных для разработчика условиях

                                                                Это вы про «блокнот»?
                                                                  –4
                                                                  Собеседование подразумевает ограниченность по времени. Быстрота разработки в 99% случаев приводит к говнокоду. Под психологическим давлением — еще и к говнокоду, на который тратится много времени. Ну и каким нормальным компаниям нужны навыки медленного говнокодирования?
                                                                    +5
                                                                    Собеседование подразумевает ограниченность по времени

                                                                    Да не подразумивает. Одно из моих собеседований длилось 3 часа, 2.5 из которых мы с организатором обсуждали и вместе решали данные им задачи. Никакой спешки, дружественная атмосфера, подсказки, шутки, затупы.
                                                                    Под психологическим давлением — еще и к говнокоду, на который тратится много времени

                                                                    Так и не увидил психологического давления. Ткните носом, прошу.
                                                                    –1
                                                                    Если в ресторане к вашему столику подойдёт некто и будет стоять смотреть, как вы едите суп, вы будете комфортно себя чувствовать?
                                                                    Представьте, некоторые люди под наблюдением ощущают себя именно так.

                                                                    Это вы про «блокнот»?
                                                                    Это про наблюдение.
                                                                    Если судить по вашим комментариям, вы вряд ли это поймёте.
                                                                      +1
                                                                      Вы путаете «стоять над душой» и «парное программирование». Последнее — практика XP, которую применяют при работе над критически важными участками кода, сложными алгоритмами, когда один мозг хорошо а два лучше проверяют друг друга. И да, в рамках парного программирования принято меняться местами.

                                                                      Экстримальное программирование никакого отношения к «экстриму» не имеет.
                                                                        +1
                                                                        Если моя работа будет заключаться в поедании супов, то вполне комфортно.
                                                                        Если судить по вашим комментариям, вы вряд ли это поймёте

                                                                        Повторюсь, я против того, что разработчик боиться показывать процесс своей работы. Значит разработчик не уверен, значит что то не так с разработчиком.
                                                                          +2
                                                                          Процесс работы? а что такое «процесс работы»? Не буду говорить за всех, но я могу за 10 минут набросать костяк скрипта, а потом ещё неделю его обрисовывать проверками, рефакторить, тестить и читать логи.
                                                                          А могу и исписать полтора бумажных блокнота алгоритмами, связями, крайними ситуациями требующими уточнений и за неделю показать пару моделей, контроллеры к ним и десяток представлений, сделанных по быстрому, для тестов.
                                                                            +1
                                                                            Не буду говорить за всех, но я могу за 10 минут набросать костяк скрипта, а потом ещё неделю его обрисовывать проверками, рефакторить, тестить и читать логи.
                                                                            И каждый день будете показывать как идут дела, правильно?

                                                                            Ну вот и тут та же ситуация — только в миниатюре.

                                                                            А могу и исписать полтора бумажных блокнота алгоритмами, связями, крайними ситуациями требующими уточнений и за неделю показать пару моделей, контроллеры к ним и десяток представлений, сделанных по быстрому, для тестов.
                                                                            Та же самая ситация и здесь. Вы можете писать код прямо «в онлайн блокноте» или на бумажке, обсуждать его вслух или добавлять комментарии. Но к комцу собеседования код должен быть. Работающий, желательно.
                                                                              +1
                                                                              Процесс работы? а что такое «процесс работы»?

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

                                                                              Вы молодец, но к чему это было сказано?
                                                                                +2
                                                                                К тому, что у всех процессы разные. и протекать могут по разному.
                                                                                  +1
                                                                                  Правильно — но потому и собеседования разные. Впрочем оказывается что процессы (и, соответственно, собеседования) скорее зависят от того в каком мире живёт компания и меньше — от специфики самой компании. Facebook, Google и Microsoft гораздо ближе друг к другу, чем, скажем, SAP или .

                                                                                  Было бы странно если бы собеседующие подбирали на собеседованиях людей под чей-то чужой «процесс»?
                                                                      +9
                                                                      Умение не путаться в мыслях, когда прямо над душой стоит человек и пристально наблюдает через плечо.
                                                                      По-моему, это чисто социальный скилл, стрессоустойчивость, если хотите.
                                                                      С умением решать задачи ничего общего не имеющее.
                                                                        +3
                                                                        Я считаю, что хороший (именно хороший) специалист, не боится того, что кто то наблюдает за его работой. Обычно новички и разного рода шарлотаны бояться того, что клиент видит процесс его работы. Это хорошо заметно в сфере ремонта помещений, когда работники резко против присутствия клиента на объекте.
                                                                          +4
                                                                          Если на основе только одного этого задания формируется отказ — это неадекватный наниматель. У человека в момент собеседования и так присутствует волнение. А тут неожиданно создается еще более экстремальная ситуация и на ее основе принимается решение. На мой взгляд — крайне неудачный подход.
                                                                            +3
                                                                            Согласен. Собеседование не должно состоять из 1 вопроса и 1 ответа.
                                                                              +3
                                                                              Я так понимаю это был pre-screen: попытка проверить умение человека вообще программировать, в приниципе. Дальше — вопросов было бы больше.

                                                                              Задачка-то элементарная. То есть начать нужно с обходом в глубину, в ширину, дать потом эту задачу (она очевидно вытекает из обхода в ширину) — и всё.

                                                                              Очень тяжело оценивать всё это не зная какие именно подсказки давались.
                                                                                –1
                                                                                попытка проверить умение человека вообще программировать

                                                                                Обычно это очевидно из общения, совсем не обязательно для этого решать задачи. Я предпочитаю использовать задачи для оценки мыслительного процесса собеседника.
                                                                                  +2
                                                                                  В том-то и дело, что из общения это не понятно. Человек будет с умным видом рассуждать о том, как марсоходы бороздят просторы большого теарта, а потом не сможет развернуть односвязный список без потери элементов. Увы.

                                                                                  У нас вообще есть чёткое правило: после первого собеседования на позицию «Software Engineer» в отчёте должны быть 10-15 строк кода, написанных кандидатом. Всё остальное обсуждается, этот пункт — вообще без вариантов.
                                                                                    +3
                                                                                    Значит мы по разному понимаем понятие «вообще программировать». Я, обычно, просил у кандидатов их open source наработки. Такие проекты пишутся спокойно, качественно, потому они идеально подходят для оценки кода.
                                                                                      +4
                                                                                      Если кандидат вообще имеет какие-то «open source наработки», то он, во-первых, скорее всего про это скажет, а во-вторых его не испугает задача, которая буквально «убила» автора обсуждаемой статьи. Исключения — случаются (пришлось как-то нам отшить кандидата, который великолепно разбирался в таймингах разных железных протоколов, но не знаю алгоритмов от слова «совсем»...), но они крайне редки.

                                                                                      90% кандидатов за душой не имеют ничего, что можно было бы «пощупать».
                                                                                        0
                                                                                        которая буквально «убила» автора обсуждаемой статьи

                                                                                        Ну автор утверждает, что дело не в сложности задачи, а в накале страстей.
                                                                                          +3
                                                                                          Заметим, что он это утверждает в статье где первое приличное решение описано как «пример номер 3», придумано «на следующее утро», а хорошее решение не описано вообще.

                                                                                          Если бы то же решение было выдано в первые пять минут прямо на собеседовании, а после наводок собеседующего был бы написан код с O(1) затратами памяти (не такой и сложный, согласитесь), то никакого «накала страстей» и не было бы, а? А был бы ещё один новый сотрудник, скорее всего…
                                                                                            +1
                                                                                            Если бы то же решение было выдано в первые пять минут прямо на собеседовании… то никакого «накала страстей» и не было бы

                                                                                            Так наоборот ведь. Как утверждает автор, если бы не было никакого «накала страстей», то было бы дано идеальное решение на собеседовании.
                                                                                              +2
                                                                                              Как утверждает автор, если бы не было никакого «накала страстей», то было бы дано идеальное решение на собеседовании.
                                                                                              Притом что оно даже не приведено в статье? Ню-ню.
                                                                              +3
                                                                              Почему неудачный? С точки зрения работодателя — вполне удачный. Люди, способные решать задачи «под давлением» лучше людей, которые на это неспособны.

                                                                              Ну а что часть хороших кандидатов потеряется — работодателю-то какая разница? В случае если соискателей достаточно — это хороший подход. Если вы мелкая контора «Рога и копыта» и к вам никто не идёт — ситуация другая, тут, конечно, придётся действовать мягче.
                                                                                0
                                                                                Думаю, именно мелкие конторы заинтересованы в такого типа тестировании. Крупным более важно качество кода, а не скорость его написания.
                                                                                  +3
                                                                                  Опять двадцать пять! В этой задаче и планировалось обсуждать качество кода, а не время его написания. Ну там за десять-пятнадцать минут кандидат пишет какое-нибудь решение, потому вы его обсуждаем и улучшаем. Кто ж виноват что первый этам затянулся на два дня и окончился только на следующий день?

                                                                                  А такое «качество кода», когда 20 строк пишутся две недели даже крупные компании себе позволить не могут… пусть даже эти 20 строк будут супергениальными.
                                                                                    +1
                                                                                    Разные бывают ситуации. Иногда этих 20 строк приходится ждать два года, а то и больше. Другое дело, что значит, без них можно было обойтись, и были дела поважнее.
                                                                                      +1
                                                                                      Бывает, что и исправление на две строчки делается месяц. Всё бывает. Важно, чтобы это было не правилом, а исключением.

                                                                                      В данном случае речь идёт о 20 строчках, которые пишутся в пять минут и про которые можно доказать, что решение — ассимптотически оптимально. И это — типичный случай. И вот самое важное (как я уже говорил) — чтобы эти типичные случаи разруливались нормально.
                                                                            +2
                                                                            Вы правы не на 100%, а на все 200%. С умением решать задачи этот скилл связан слабо. А с умением работать в команде — очень сильно.

                                                                            Вы сколько времени планируете потратить перед тем, как послать код на ревью? День, два? Нет же, сорее речь будет идти о минутах. Ну о часах, от силы.

                                                                            Да, тут всё более «сжато» — но и задача ведь игрушечная, согласитесь.
                                                                              +2
                                                                              Дело ведь не в том, что код будут смотреть и критиковать, а в том, что само наблюдение выбивает из колеи и не позволяет сосредоточиться.

                                                                              Также не согласен со связью с умением работать в команде. Сужу по себе: я не испытываю проблем с прохождением ревью, обсуждением кода и общением с коллегами, но вот такие онлайн-блокноты на собеседованиях очень сильно досаждают.
                                                                                +3
                                                                                Они всех досаждуют, успокойтесь. После калибровки результат нужно умножать примерно на пять. То есть если твой коллега в спосойной обстановке в уголке решает задачу пять-шесть минут — её можно давать на собеседовании. И если кандидат её за полчаса решит — можно брать.

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

                                                                                Это-то как раз понятно.
                                                                              +1
                                                                              По-моему, это чисто социальный скилл.
                                                                              Да (точнее, психологический).
                                                                              С умением решать задачи ничего общего не имеющее.
                                                                              Ну как… Утверждение слишком сильное, из разряда «никогда», поэтому вынужден сказать «нет». В общем-то IRL нужда в подобных навыках иногда всплывает, и мера их нужности зависит от специфики места работы.
                                                                                +1
                                                                                Да, верно, псхологический.

                                                                                Я согласен со спецификой места работы, возможно, где-то этот скилл полезен или даже необходим.
                                                                                Но я лично ставил себя на место сферического разработчика в вакууме — когда есть возможность на несколько часов уходить в «поток».
                                                                                  +1
                                                                                  Интересно где это платять за работу, где можно всё делать «уходя в поток». Нет, я бы тоже так хотел. Но, увы, оказывается, что 90% времени занимает рутина, которую нужно делать «под давлением». Увы.
                                                                                    +1
                                                                                    Пусть рутина, это тоже неважно, главное, что за спиной никто не стоит.
                                                                                      +1
                                                                                      В том-то и дело, что стоит. Или за спиной или сбоку стоит. И просит показать. Вот прямо тут и сейчас? Что будете делать?
                                                                          +3
                                                                          Чем-то похоже на первое решение:
                                                                          static void Connect(Node x){
                                                                              Connect(x,new List<Node>(),0);
                                                                          }
                                                                          static void Connect(Node x,List<Node> rightLine,int level){
                                                                              if(x==null) return;
                                                                              if(level==rightLine.Count){
                                                                                  rightLine.Add(x);
                                                                              }else{
                                                                                  rightLine[level].neighbor=x;
                                                                                  rightLine[level]=x;
                                                                              }
                                                                              Connect(x.left,rightLine,level+1);
                                                                              Connect(x.right,rightLine,level+1);
                                                                          }
                                                                          

                                                                          Сложность O(size), память O(depth).
                                                                            +9
                                                                            Когда давно услышал фразу, что умение решать такие задачи говорит о том, что соискатель умеет решать такие задачи и ничего более. Никогда за 10 лет не сталкивался с тем, что вот такого рода задачи надо вот так на коленке решать.
                                                                            У сотрудника был опыт решение бековой проблемы на чужом ноуте, в другой стране через впн, но при этом всё равно, кофе, IDE, сначала сесть, успокоиться, разрисовать и решать.
                                                                              +1
                                                                              Мне так же не приходилось за последние 10 — 12 лет сталкиваться с чем-то подобным. Хотя попадались и задачи по машинному обучению. Не было ничего сложного, была нехватка знаний, иногда. Последняя покрывалась неплохим образованием, опытом и прочтением нужной литературы.
                                                                                +5
                                                                                Задача простая, решить ее можно хоть на коленке, хоть стоя на ушах. Не увидел причин для паники автора при решении этой задачи, видимо дело было в банальной спешке.
                                                                                +11
                                                                                Помыть посуду — один из моих любимых способов подумать )
                                                                                  0
                                                                                  А мне в туалет сходить. Закинуть голову к верху и подумать :)
                                                                                    0
                                                                                    Намотать пяток километров на велосипеде, как на меня вариант
                                                                                      +1
                                                                                      Я с собакой гуляю
                                                                                      +26
                                                                                      Смотреть за процессом решения задачи — очень плохая практика. Это как удар ниже пояса. Понимание того, что тебя оценивают по заведомо не готовому коду, не дает сосредоточиться на поиске решения. В итоге унижение неизбежно, даже если с задачей справляешься.
                                                                                        +14
                                                                                        Вы как будто в воду смотрите. С каждой написанной строчкой я думал, как бы не сморозить, как бы не написать откровенную чепуху, это просто ужасно блокирует ход мыслей.
                                                                                          +14
                                                                                          Значит собеседование выполнило свою роль фильтра, по параметру «не брать кандидатов, которые боятся сморозить чепуху и стесняются своего кода». а так же по параметрам алгоритмического мышления, ide-независимости, способностям к быстрому анализу и синтезу решения.
                                                                                          Является ли такой фильтр правильным при найме разработчика — вопрос дискуссионный. Мне кажется что все эти навыки необходимы в той или иной степени, возможно их не стоило смешивать в одном тесте. Вопрос такой системы фильтрации вы наверное могли бы обсудить с HR отделом компании если бы прошли собеседование. Но раз компания существует и нанимает разработчиков — значит такая система отбора имеет право на жизнь.
                                                                                            0
                                                                                            Последнее время задумываюсь о таком новом направлении на моем YouTube канале, как решение задач в реальном времени и демонстрация этого процесса зрителям. Меня не беспокоит лажа или откровенно глупые решения, как это не беспокоит игровых стриммеров. Отнеситесь к написанию кода в том же русле, думаю это не только позволит вам проходить такого рода собеседования, но и не бояться совершать ошибки.
                                                                                              +2
                                                                                              как решение задач в реальном времени и демонстрация этого процесса зрителям. Меня не беспокоит лажа или откровенно глупые решения, как это не беспокоит игровых стриммеров.

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

                                                                                                Сплошь и рядом.
                                                                                                  0
                                                                                                  обычно те кого не беспокоит глупые решения и лажа в собственном коде

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

                                                                                                  Вы намекаете на то, что я плохой программист?))
                                                                                                  Профессионал сначала оттачивает навыки до совершенство

                                                                                                  Навык чего, решения задач? Новичкам интересно посмотреть, как опытный программист «в живую» решает незнакомую ему задачу, спотыкается, ищет решения, использует различные подходы для отлавливания ошибок, рассуждает, а не смотреть как лектор записывает на доске изо дня в день одно и то же, без ошибок и запинок.
                                                                                                +1
                                                                                                Меня, кстати, почти всегда на анкетировании оставляли подумать — закончишь, дай знать.
                                                                                                +5
                                                                                                Так, собственно, процесс тут и интересен, само решение-то вполне стандартное. Как ещё можно оценить способность решать задачи, как не наблюдая и участвуя в процессе?
                                                                                                Каждая проверка в той или иной степени унизительна, с этим приходится считаться, это и есть профессионализм — оцениваешь ты, оценивают тебя. Это нормальная ситуация, а не повод для истерики.
                                                                                                  0
                                                                                                  Почему нельзя дать более объемную задачу на пару дней, чтобы соискатель мог спокойно ее решить?
                                                                                                    +2
                                                                                                    У объемной задачи другие цели. По моему скромному опыту это обычно следующий шаг собеседования. Но какой смысл давать объёмную, если соискатель не справился с простой?
                                                                                                    Да, кстати, мне в интервью на позиции, где алгоритмизация не была сильной стороной, давали сразу объёмные задачи.
                                                                                                      +1
                                                                                                      Так может быть он не справился с простой из за стресса, а в спокойной обстановке напишет ее легко. Зачем рисковать потерей кандидата, если можно дать объемную задачу?
                                                                                                        +3
                                                                                                        С чего вы взяли что это «потеря»? Очевидно, что у работодателя свои критерии полезности и стопы. И работодателю и ХРу и интервьюерам выгодней, если соискатель будет нанят. Если в такой ситуации его отсеивают, то можно почти точно сказать, что в этом конкретном случае он не подходит, несмотря на всю мудрость задним умом.
                                                                                                          0
                                                                                                          Если в такой ситуации его отсеивают, то можно почти точно сказать, что в этом конкретном случае он не подходит, несмотря на всю мудрость задним умом.


                                                                                                          Приведу пример, который сам встречал не раз. Кандидат проходит интервью в двух разных компаниях из одной отрасли.
                                                                                                          — В компании А ему предложили задачу на 5 минут, задача была академическая, которую кандидат раньше не решал и в результате он запаниковал и провалился.
                                                                                                          — В компании Б дали задание на пару дней, которое кандидат спокойно сделал дома и полностью удовлетворил требования работодателя.

                                                                                                          Объемная работа исключает фактор стресса, что позволяет не терять определенный процент кандидатов. Конечно, если работа заранее предполагает постоянный стресс, то тогда нужен устойчивый человек, но я в IT сфере еще не встречал таких требований.
                                                                                                            +4
                                                                                                            Очень хороший пример, в нём компания наняла подходящего ей соискателя, а он нашёл подходящую ему работу. Не вижу тут проблемы.
                                                                                                            Непонятно, как объёмная работа может исключить фактор стресса. Да, тебя не проверяют в реальном времени, но потом твой объёмный код будут оценивать несколько человек, и они уж точно найдут там косяки. В таком свете, мне кажется, простая задачка с подсказками вызовет даже меньше стресса. Фактор стресса при оценке невозможно исключить в принципе.
                                                                                                            боритесь со своим стрессом
                                                                                                            image
                                                                                                              0
                                                                                                              Непонятно, как объёмная работа может исключить фактор стресса.
                                                                                                              1. Вы пишете код в комфортной для себя обстановке, у вас есть возможность показать себя и учесть всё необходимое по ТЗ.
                                                                                                              2. Пока вы пишете код, вы не переживаете, считает ли интервьювер, что всё затянулось. И вообще, полчаса — это уже много? Ой, он начал зевать, у меня всё плохо?
                                                                                                              При объёмной задаче косяки идут в комплекте, да, но ничего страшного. Вроде как наоборот, у компании будет более полное представление о вас. Честно и справедливо.
                                                                                                                +4
                                                                                                                И вообще, полчаса — это уже много? Ой, он начал зевать, у меня всё плохо?

                                                                                                                Ну и фаза луны в день собеседования подкачала.

                                                                                                                А если в компанию требуются суровые кодеры, а не «комплексующие непризнанные гении»?
                                                                                                                  +1
                                                                                                                  А если в компанию требуются суровые кодеры, а не «комплексующие непризнанные гении»?
                                                                                                                  Я-то не против, пусть набирают кого считают нужным. Я старался объяснить, как объёмная работа может если не исключить, то минимизировать фактор стресса.
                                                                                                                  +2
                                                                                                                  Вы только что лишили всех фрилансеров отговорки, почему проект не сдан во-время. Это раз.
                                                                                                                  Два — простые задачи в первом круге интервью не исключают сложных во втором.
                                                                                                                  Другой вопрос — а зачем давать человеку сложную задачу, если он с простой не справился, и вообще дрожит как осиновый лист? Нет, конечно можно, если с кандидатами совсем всё плохо, но когда не справился один из десяти, проще продолжить с остальными и не тратить ресурсы.
                                                                                                                  И снова — стресс возникает не из за того, что вас о чём то спрашивает ещё 10 минут назад незнакомый человек. Он возникает в конечном счёте от страха, что могут не взять. И это никак не исключить.
                                                                                                                    +1
                                                                                                                    Я не совсем понимаю как страх и сильная дрожь связанны со ступором, с путаностью в мыслях? В моем случае я страха не испытывал, лишь ступор. Провалил я собеседование еще и от того что осознал, что не в состоянии решить задачу в данной обстановке хотя мой внутренний голос просто кричал что задача проста. Например я отчасти испытывал чувство злости на глупость ситуации и на себя.
                                                                                                                      +2
                                                                                                                      А ступор по вашему просто так, ниоткуда, взялся?
                                                                                                                      Ступор — это подсознательная реакция организма на опасность. Может вы лично и не испытывали страха, но ваше подсознание явно испытывало. А внутренний голос оказался на самом деле внешним :)
                                                                                                                      Как ещё можно объяснить ступор во вполне обычной ситуации?
                                                                                                                        +1
                                                                                                                        Обычной для вас. Страх это реакция организма на внешний раздражитель. Есть два типа реакции на такой раздражитель. Такого понятия как подсознание испытывающее страх быть не может. А вот раздражитель влияющий на способность логичиски мыслить это вполне реально. Для кого-то это шум, для кого-то это чавкающий коллега. Вы спутали состояние ступора и шока, его легкое проявление. Под ступором я понимаю состояние в котором вы got stuck, со всеми вытекающими и не более.
                                                                                                                +10
                                                                                                                Приведу пример, который сам встречал не раз. Кандидат проходит интервью в двух разных компаниях из одной отрасли… В компании Б дали задание на пару дней, которое кандидат спокойно сделал дома и полностью удовлетворил требования работодателя.

                                                                                                                Другой пример, когда подходящих компаний десятка два и каждая пытается дать задание на пару дней на самом первом интервью… Особенно, когда кандидат ещё не уволился с прошлой работы и у него полно других дел, кроме поиска работы. Нет, я понимаю, если это компания мечты всех кандидатов, аля гугл. Но удивляет уверенность работодателей особо ничем не примечательной компании, что их вакансия единственная на рынке и кандидат потратить неделю на объемные задания чтобы лишь попасть на второе интервью, вместо того чтобы за это время пройти десяток собеседований в других компаниях. Во многих случаях опытные разработчики просто забивают на такие задания.
                                                                                                              +5
                                                                                                              лучше не взять того, чем взять не того.
                                                                                                                +1
                                                                                                                С учетом нехватки высококвалифицированных кадров (я про IT сферу) чаще всего наоборот и испытательный срок никто не отменял.
                                                                                                                  +2
                                                                                                                  Вопрос поставлен правильно, но «правильный» ответ на него не столь однозначен и разнится от фирмы к фирме и от позиции к позиции.
                                                                                                                  +3
                                                                                                                  Зачем рисковать потерей кандидата, если можно дать объемную задачу?
                                                                                                                  Вы так говорите, как будто потеря кандидата — это катастрофа. Ну потеряем мы сколько-то, проблем-то. Если оставшихся хватает — всё в порядке, если нет — подходы нужно менять…
                                                                                                                +3
                                                                                                                Объемную задачу востребованный соискатель просто не станет решать, разве что это работа его мечты.
                                                                                                                  +1
                                                                                                                  В идеале можно дать соискателю выбор.
                                                                                                                +2
                                                                                                                Если человек способен решать необходимые задачи, каким образом он приходит к решению интересовать не должно, это уже личное дело разработчика. Понятно, что работодателю интересно поковыряться везде, но должны быть рамки. Разработчик в итоге справился с задачей — он способен решать такие задачи, все просто.
                                                                                                                +15
                                                                                                                Смотреть за процессом решения задачи — очень плохая практика.

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

                                                                                                                Понимание того, что тебя оценивают по заведомо не готовому коду, не дает сосредоточиться на поиске решения.

                                                                                                                Почему? В нормальной ситуации обе стороны понимают, что код заведомо не готов, что в этом унизительного?
                                                                                                                  +1
                                                                                                                  Смотреть на это может поучительно и увлекательно, но участвовать в этом в качестве кандидата — совсем нет.
                                                                                                                    +8
                                                                                                                    Вам лично — возможно. Но это не универсальное ощущение.
                                                                                                                      +6
                                                                                                                      Не знаю, я лично проходил недавно несколько таких собеседований. Ничего постыдного в этом не видел. Вполне нормально принял, хотя и не все задачи были решены сходу.

                                                                                                                      пс. никогда не учавствовал в олимпиадах.
                                                                                                                        0
                                                                                                                        Зависит от человека. Если ему не комфортно — это так же многое говорит о нем.
                                                                                                                        –1
                                                                                                                        как человек думает, какие решения он принимает, и почему он их отбрасывает.
                                                                                                                        А зачем это работодателю? Разве всё в конечном счёте не сводится к тому, чтобы работа была выполнена? Есть другие, более продуктивные (на мой взгляд, конечно) критерии оценки работы, нежели количество рассмотренных решений и причины их отбрасывания.
                                                                                                                          +3
                                                                                                                          А зачем это работодателю?

                                                                                                                          Чтобы понимать, как человек думает. В частности, глядя за процессом, можно пытаться оценить, какие вещи человек будет учитывать в повседневной работе, а какие — нет.

                                                                                                                          Разве всё в конечном счёте не сводится к тому, чтобы работа была выполнена?

                                                                                                                          Нет, для таких вещей аутсорсеры есть. Выставили условия, получили (или нет) результат.

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

                                                                                                                          «Почему сделано так» — это не критерий оценки работы, это критерий для включения результата в общий код.
                                                                                                                            +2
                                                                                                                            В частности, глядя за процессом, можно пытаться оценить, какие вещи человек будет учитывать в повседневной работе, а какие — нет.
                                                                                                                            Разве код сам не расскажет, что было учтено, а что нет? А если есть сомнения, почему не спросить: «Что вы думаете по поводу X вот здесь?»

                                                                                                                            Нет, для таких вещей аутсорсеры есть.
                                                                                                                            Что дополнительно требуется от собственных разработчиков, сотрудников?
                                                                                                                              +4
                                                                                                                              Разве код сам не расскажет, что было учтено, а что нет?

                                                                                                                              Не всегда. В частности, если человек учел какую-то побочную ситуацию, а потом отбросил ее как невозможную, то в коде об этом не будет ничего (особенно в коде на собеседовании).

                                                                                                                              А если есть сомнения, почему не спросить: «Что вы думаете по поводу X вот здесь?»

                                                                                                                              Эти вопросы как раз (а) занимают много времени и (б) их можно задавать только после завершения кода.

                                                                                                                              Что дополнительно требуется от собственных разработчиков, сотрудников?

                                                                                                                              Преемственность. Сегодня код писал один человек, завтра — уже другой.
                                                                                                                                +2
                                                                                                                                Эти вопросы как раз (а) занимают много времени и (б) их можно задавать только после завершения кода.
                                                                                                                                (а) Найм нового сотрудника — это серьёзное вложение, и будет очень странно, если у компании не окажется времени на вопросы. (б) Верно. В том и суть: дать кандидату задачу, назначить дедлайн и позволить решить её в комфортной обстановке, результат обсудить.
                                                                                                                                Преемственность.
                                                                                                                                Очень хороший поинт. Тогда выполненная работа плюс соответствие требованиям проекта (code style, покрытие тестами и т.п.)?
                                                                                                                                  0
                                                                                                                                  Найм нового сотрудника — это серьёзное вложение, и будет очень странно, если у компании не окажется времени на вопросы.

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

                                                                                                                                  Тогда выполненная работа плюс соответствие требованиям проекта (code style, покрытие тестами и т.п.)?

                                                                                                                                  Этого недостаточно. Ни то, ни другое не помогает для оценки design decisions.
                                                                                                                                    +3
                                                                                                                                    (а) Найм нового сотрудника — это серьёзное вложение, и будет очень странно, если у компании не окажется времени на вопросы.
                                                                                                                                    Закон Паретто никто не отменял. Из нашей статистики: на 100 кандидатов редко когда больше 2-3 будущих сотрудников. Говорить с каждым из них по многу часов — это элементарно дорого. Особенно с учётом того, что большая их часть программировать не умеет от слова «совсем». Потому хочется сделать «первычный отсев» максимально дешевым.

                                                                                                                                    (б) Верно. В том и суть: дать кандидату задачу, назначить дедлайн и позволить решить её в комфортной обстановке, результат обсудить.
                                                                                                                                    Это уже потом, когда процетов 80-90 кандидатов отсеяны. Если задача большая и сложная, то и смотреть на неё приходится долго. Это дорого.
                                                                                                                            0
                                                                                                                            Если вы нанимаете шоумена, то да.
                                                                                                                            А если программиста, то нужнее результат.
                                                                                                                              +2
                                                                                                                              При работе в команде «результат» выражается не только в коде.
                                                                                                                                +1
                                                                                                                                Talk is cheap. Show me the code
                                                                                                                                (с)
                                                                                                                                ;)
                                                                                                                                  +1
                                                                                                                                  Ну вот показали вам код, а к коду тому — девяносто вопросов. Помогло?
                                                                                                                                    +2
                                                                                                                                    И я их задам. Обсуждение — важная часть интервью.
                                                                                                                                      +1
                                                                                                                                      Вы считаете, что код, вызывающий вопросы — это хороший результат?
                                                                                                                                        +1
                                                                                                                                        Ответ на Ваш вопрос зависит от того, какие кванторы Вы в нём подразумевали:

                                                                                                                                        Существует такой код на интервью и существуют такие вопросы к нему, при том, что код хорош.
                                                                                                                                        Существует такой код на интервью и существуют такие вопросы к нему, при том, что код плох.
                                                                                                                                        Существуют вопросы, которые стоит задавать только если код плох.
                                                                                                                                        Существуют ли вопросы, которые можно задать только если код хорош — это я не знаю. но подозреваю что тоже да.
                                                                                                                            +2
                                                                                                                            Мне как-то предложили решить тестовое задание (не маленькое), с записью процесса работы на видео (скринкаст). Я ответил, что запись меня отвлекает и нервирует, но могу сделать запись только основных моментов. На этом потенциальный работодатель испарился. Хотя даже если бы я хотел сделать запись, мне было бы очень не комфортно работать, т.к. видеозапись вместе с запущенной IDE очень нагружает ноутбук. Предпочитаю с такими работодателями не иметь дела.
                                                                                                                              +1
                                                                                                                              Почти 10 тысяч часов с регистрацией рабочего времени скриншотами. Кажется я чудом выжил и сохранил рассудок.
                                                                                                                              +4
                                                                                                                              Собственно в этом коренное отличие практики собеседований у нас в ABBYY от описанной (которую используют, afaik, ещё и в Google, и в MS, и в booking). У нас любят дать задачу и выйти из комнаты (причём даже сказать, что на решение есть 100500 времени).
                                                                                                                              Таким образом мы даём лишний шанс талантливым, но не слишком самоуверенным кандидатам.
                                                                                                                              +4
                                                                                                                              Я тоже проваливал подобное собеседование с «блокнотом» и т.п. Плюс, интервью проходило на английском языке. Часть задачек решил, но на одной застопорился.

                                                                                                                              А потом погуглил чувака, который меня собеседовал и узнал, что он в прошлом ИТ-олимпиадник из СНГ. Отсюда и такой подход к собеседованию, как к олимпиаде :)

                                                                                                                              Может, и хорошо, что провалил, по крайней мере, сейчас от меня на работе требуется думать, а не решать задачки на скорость.
                                                                                                                                +24
                                                                                                                                Эта глупая игра под названием «собеседование». Мне кажется, это вечный бич айтишников.
                                                                                                                                Работодатель не знает чего хочет, точнее знает, т.к. начитался умных книжек и напридумывал (нарыл в инете) каких-то задач, которые в реальной работе почти никогда не встречаются.
                                                                                                                                А соискатель попадает в стрессовую ситуацию, пытаясь решить глупые задания из книги «9000 задач, которые вам никогда не пригодятся».
                                                                                                                                По факту получается, что ищут человека, который будет выполнять работу качественно и вовремя (с некоторыми вариациями), но по собеседованиям складывается впечатление, что им нужен тот, кто умеет решать такие задачки в блокнотике.
                                                                                                                                Исключения, когда ищут реально крутого программиста, которого разбуди посреди ночи и дай листик, он тебе напишет самую оптимальную реализацию самого сложного алгоритма, который лежит в основе какой-то крутой хардварной штуки, — только подтверждают правило ;D
                                                                                                                                  +23
                                                                                                                                  У меня было похожее собеседование. По скайпу. На .net программиста.
                                                                                                                                  Сказали пиши код прямо в скайп — никаких Visual Studio.
                                                                                                                                  Код написал, кое как, отправляя в скайп куски кода. Визуально все проверил — вроде правильно. Получаю ответ — у тебя прога мало того что не скомпилится, да и еще не вернет правильный ответ. Типо не справился, следующий вопрос.
                                                                                                                                  Меня разозлило это. Скопировал код в студию, запускаю — все ОК, собралось. Выводит правильный ответ.
                                                                                                                                  Кто меня собеседовал даже не стал слушать меня, мол он лучше знает и вообще, тут оценивают мои знания — а не его. Начальник умный, ты дурак.
                                                                                                                                  Потом тоже самое было с SQL кодом, мол напиши запрос. Написал, тоже я дурак. Проверяю на БД, накидал несколько таблиц, данных тестовых. Все верно вывелось! Не хочет даже смотреть.
                                                                                                                                  А потом как начал меня унижать, по каждой фигне. И за все собеседование я его на 3 буквы не послал, думал может проверяет стрессоустойчивость. А нет, оказалось просто он мудак, который самоутверждается за счет таких провенциальных соискателей, сам он типо «москвич» уже.
                                                                                                                                    +28
                                                                                                                                    В таких случаях стоит прерывать собеседования со словами «ваша шарага мне не подходит». Потому что работать в компании с такими вот «умниками» вам нервных клеток не прибавит.
                                                                                                                                      +1
                                                                                                                                      Не, зачем оскорблять, просто не вступать в спор и аккуратно выйти из диалога.
                                                                                                                                        0
                                                                                                                                        Выйти из диалога жертвой? Человек пришел на собеседование. Не за подачкой, это раз. Если сотрудник работодателя, который проводит собеседование, не в состоянии дать аргументированной оценки знаниям соискателя, а также проявляет какое-либо неуважение, презрение и т.д., то пусть катится куда подальше. К чему лебезить и раболепствовать?
                                                                                                                                          +3
                                                                                                                                          Всё зависит от настроя. Если вы чувствуете себя уязвимо и неуверенно, то агрессивное и непрофессиональное поведение весьма ранит.
                                                                                                                                          Если вы успешны в карьере и в социальной жизни, то вам легко не принимать идиотов на личном уровне и избегать тратить на них время и фокус.
                                                                                                                                            –1
                                                                                                                                            К чему я и призвал. Просто проявление уважения к тем, кто не был замечен в аналогичном деле, это сродни ответу добром на зло. Порождает новое зло. ;)

                                                                                                                                            Тем более, успешным вы быть и можете, но многие люди в IT (говорю за себя и многих моих друзей) после нескольких лет работы на одном месте начинают неуверенно чувствовать себя на собеседованиях, считая, что мало знают, что появился некоторый застой в знаниях.
                                                                                                                                              0
                                                                                                                                              А если вас собака облает — вы, наверное, встанете на четвереньки и залаете на неё в ответ?
                                                                                                                                                +1
                                                                                                                                                Не угадали. Все же я человек разумный, а не собака. И нахожусь в социуме. Но ваше право, если вам грубят, утереться и пойти дальше ))
                                                                                                                                      +1
                                                                                                                                      Скайп иногда в коде символы на смайлики заменяет и не очень понятно как оно потом у собеседника обратно скопируется.
                                                                                                                                        +4
                                                                                                                                        2 восклицательных знака в начале вставить надо
                                                                                                                                        !!
                                                                                                                                        function (y) {}
                                                                                                                                          +2
                                                                                                                                          Оформляешь в скайпе код в два тега {code} void SomeMethod(){} {code} и текст будет без смайлов и моноширинный.
                                                                                                                                        +5
                                                                                                                                        Рекурсивное решение с использованием стека.
                                                                                                                                        struct leaf {
                                                                                                                                            public:
                                                                                                                                                int value;
                                                                                                                                                leaf* right;
                                                                                                                                                leaf* left;
                                                                                                                                                leaf* neighbor;
                                                                                                                                        
                                                                                                                                                leaf(int v, leaf* r, leaf* l) :
                                                                                                                                                    value(v), right(r), left(l), neighbor(nullptr) {};
                                                                                                                                        };
                                                                                                                                        
                                                                                                                                        void find_neighbors(leaf* node, std::stack<leaf*> & stack)
                                                                                                                                        {
                                                                                                                                            if (node == nullptr) {
                                                                                                                                                return;
                                                                                                                                            };
                                                                                                                                        
                                                                                                                                            if (!stack.empty()) {
                                                                                                                                                node->neighbor = stack.top();
                                                                                                                                                stack.pop();
                                                                                                                                            };
                                                                                                                                        
                                                                                                                                            find_neighbors(node->right, stack);
                                                                                                                                            find_neighbors(node->left, stack);
                                                                                                                                            stack.push(node);
                                                                                                                                        
                                                                                                                                            return;
                                                                                                                                        }
                                                                                                                                        


                                                                                                                                        Сложность O(N), память O(logN).
                                                                                                                                          +1
                                                                                                                                          Не будет работать даже для тривиального случая дерева с двумя дочерними узлами.
                                                                                                                                          Даже если пофиксите, то память будет не O(logN)
                                                                                                                                            0
                                                                                                                                            Вы неправы, вот доказательство ideone.com/OjNWMU.
                                                                                                                                            Расход памяти вычисляется как максимальный размер стека, и равен он, как несложно догадаться, глубине дерева, которая для сбалансированного бинарного дерева равна log2N.
                                                                                                                                              +3
                                                                                                                                              В условии не сказано, что дерево сбалансированно.
                                                                                                                                          +2
                                                                                                                                          Аналогичная была ситуация, когда пытался на собеседовании с помощью ручки и листа бумаги написать структуру для хранения очереди на абстрактном языке без ссылок, указателей и динамических массивов. Промучился пол часа и сдался. Вышел из офиса и, пока переходил улицу, придумал решение, но возвращаться было уже как-то неловко.

                                                                                                                                          Собеседование было, к слову, на вакансию PHP-программиста. До сих пор не понимаю — нахрена?
                                                                                                                                            +2
                                                                                                                                            Крис Окасаки, чисто функциональные структуры данных?
                                                                                                                                            0
                                                                                                                                            Мне кажется, что второй вариант может быть использован для обработки уже готового дерева с каким-то произвольным размещением в памяти.
                                                                                                                                            В массиве достаточно разместить только один слой узлов (листьев), по памяти будет заведомо лучше чем O(N).
                                                                                                                                              –3
                                                                                                                                              Прямо вот бесят такие и подобные задачи, особенно когда надо решить за время без кофе и перекуров на «подумать». Даже если их можно решить за 20 строчек кода. Даже тот же «FizzBuzz» — элементарная задача, но, что она дает на собеседовании?
                                                                                                                                                +8
                                                                                                                                                Показывает, что соискатель хотя бы циклы и ветвления понимает. Я собеседовал много людей и как ни странно, многие не могут fizzbuzz написать, хотя рассказывают байки о большом опыте работы. Нафиг таких нанимать?
                                                                                                                                                  0
                                                                                                                                                  Честно, я не могу представить человека, который считает себя программистом и не способен написать задачу на 3 условия.
                                                                                                                                                    +1
                                                                                                                                                    Это значит, что вы никогда никого не собеседовали. Я таких видел (на собеседованиях) в изрядных количествах.

                                                                                                                                                    На что они претендуют, идя на вакансию программиста — науке неведомо.