ABC: Always Be Coding (не переставай программировать)



Как получить работу инженера?

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

# x = количество компаний, в которых ты проходил собеседования

# y = количество предложений о работе, которые ты получил

рейтинг = 100 * log(x) * y / x



Если твой рейтинг < 90, обязательно прочти это. Если > 120, возможно, тебе это не нужно, но, все равно прочти.



Кто я такой?



У меня нет университетской корочки об образовании. Программирование стало для меня профессией в 19 лет, когда я переехал из Чикаго в Южную Калифорнию. Все мое имущество с легкостью поместилось в машину. 400 долларов в кармане и предложение о работе джуниором за безумные 40 000 долларов в год — вот все что у меня было. С тех пор прошло 12 лет… Но это уже совсем другая история.

Я работал в Double Helix, Namco Bandai, Google, Obvious и Square.* Получал предложения о работе от таких компаний, как Naughty Dog, Activision, Riot Games, Blizzard, Pinterest, Goldman Sachs и многих других. Если кому интересно — мой рейтинг по формуле, что я привел выше — 132.

За свою жизнь я провел, по меньшей мере, 500 интервью с соискателями на должность инженера. Приблизительно 10% из них получили предложения о работе. Менее 3% я считаю “звездами” и запомнил каждого из них.

Нет ни одного способа, который бы гарантировал тебе успешное получение работы. Слишком много переменных в этом уравнении. Особенно в компаниях вроде Google. Тебя сажают с 5-7 случайно выбранными инженерами и списком вопросов, которые они будут задавать. На таких собеседованиях обычно приходится писать код на доске от руки. Некоторые инженеры — ужасные интервьюеры. Они любят вопросы с подковыркой и предвзято тебя оценивают. Ничего страшного — это случается и с лучшими из нас. Обычно, разрешается завалить одно интервью из серии.

Лучшее, что я могу сделать в этой ситуации — это рассказать тебе, как подготовиться. Перейдем к делу — вот мои советы.


Технические советы



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

  2. Стань профессионалом, как минимум, в одном из мультипарадигменных языков программирования. Изучение языка даст тебе хорошее видение перспективы. Чтобы достичь этого, ты должен писать огромное количество кода и еще больше — читать. Изучи подводные камни и лучшие практики. В идеале, выбранный тобой язык должен быть достаточно популярным и обладать динамично развивающимся сообществом, которое производит огромное количество кода. Хорошие кандидаты — это C#, C++, Java, PHP, Python и Ruby.
    Самый частый вопрос, который любят задавать на собеседованиях по С++: “По шкале от 1 до 10, где 10 — самая высокая оценка, как бы вы оценили свои знания С++?”. Я ненавижу его. И да поможет бог любому, кто ответит 9-10. Его разорвут за это на части. Бьярн Страуструп оценивает свои знания, как 8 или менее. Этот язык слишком сложен, слишком обширен, с очень продолжительной эволюцией. Я опять отвлекся.

  3. Узнай свои слабые стороны. Прочти этот список, а затем оцени свое понимание работы всего этого. Реализуй базовые вычислительные алгоритмы, такие как Dijkstra's algorithm, Floyd-Warshall, Traveling Salesman, A*, bloom filter, breadth-first iterative search, binary search, k-way merge, buble/selection/insertion sort. in-place quick sort, bucket/radix sort, closest pair и так далее. И не прекращай программировать. Вот еще одна очень хорошая статья.

  4. Изобретай колесо. Ты должен вручную реализовать базовые структуры данных на своем языке. Не полагайся на стандартные библиотеки. Реализуй и напиши тесты для следующего: вектор (динамический массив), связанный список, стек, очередь, замкнутая очередь, hash map (хэш-карта), set (набор), очередь с приоритетами, дерево бинарного поиска, и т.д. Ты должен уметь их быстро реализовать, когда понадобится.

  5. Реши свои языковые проблемы. Забудь вопросы вроде этого. Все сводится к фундаментальным концепциям программирования. Потрать не менее 40 часов на кодирование решений для различных задач. Одним из лучших ресурсов для этого я считаю TopCoder. Прочитай это. Попробуй решить задачи. Выбирай такие, которые проверят твою способность реализовывать рекурсивные, pattern-matching, жадные алгоритмы, динамическое программирование, и задачи с графами…
    Просмотри список задач из архива.
    Я уверен, основная причина того, что меня наняли в Google — это мои две недели одержимости TopCoder. Я мог написать алгоритм Дейкстры с закрытыми глазами и с одной рукой за спиной. Я мог решить все задачи с графами на свете. Эта была моя репетиция. Как говорит Eric Schmidt: “Репетиция молитвы не портит.”

  6. Относитесь к программированию проще. По-крайней мере, сделайте его простым с виду. Конечно, не сразу — со временем. Я считаю, что кодинг — это самый честный и простой способ быть инженером. Я часто называю его “простейший этап программирования”, потому что сложнейшая его часть — это до и после написания кода. К примеру, разработка того, что вы собираетесь закодировать и проверка того, что код готов к поставке и выполняет свои задачи. Заставь своего интервьювера понять, что программирование — всего лишь средство для достижения цели.
    Так же, обрати внимание, что кодирование может быть наиболее пугающим этапом. Постарайся попрактиковаться в написании кода руками на доске и в парном программировании. Google часто использует оба этих подхода.
    А еще — прочти статью моего друга и бывшего коллеги Dan.



Общие советы



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

  1. Знай зачем ты здесь. Если тебе предстоит собеседование в компании, о которой ты ничего не знаешь — лучше не приходит на него вообще. Люди отвечающие за найм работников чуют это за версту. Такое сойдет тебе с рук только в больших компаниях, в маленьких — даже не пытайся.

  2. Интересуйся. Если тебе все равно, остальным — тоже. Будь увлечен чем-то. Как на счет того, чтобы сделать программирование своим увлечением? Тебе нравится разрабатывать компиляторы в свободное время? Собираешь квадрокоптеры? Не важно — если ты увлечен чем-то, сможешь сделать это интересным для себя.

  3. Не делай предположений. Задавай вопросы, если неуверен. Если все равно не уверен на 100%, что разобрался после того как задал вопрос — спрашивай снова. Много раз я наблюдал за тем, как соискатель молча движется по неверному пути. В итоге он тратит время на решение не той задачи.

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



Как я уже говорил, не существует серебряной пули, которая гарантирует получение работы. Лучшее, что ты можешь сделать, как инженер — не переставать программировать.

*В настоящее время, я работаю на себя, создавая что-то новое.

Спасибо за внимание! Хорошего настроения, удачи в карьере и вообще!
Это был перевод. Оригинал: ABC: Always Be Coding by David Byttow (A pirate building things)
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 58
  • –1
    рейтинг = 100 * log(x) * y / x

    1) По какому основанию логарифм?
    2) А если рейтинг отрицательный, то всё очень плохо?
    Если я ни разу не был на собеседовании, то при делении на 0 получим inf, логарифм от 0 тоже в принципе в принципе даст -inf. Бесконечно отрицательный рейтинг. Надежды нет)
    • 0
      Да, подтверждаю, формула не идеальна. Даже в случае если человек уже работает (x == 1), но предложений от компаний не получал (сам нашел работу и устроился (y == 0)) — получается 0 / 1. Но вроде же и так понятно, что она написана «от балды».

      Жаль нет идеальной формулы для приема на работу. Хотя может и наоборот — хорошо :)
      • +9
        но предложений от компаний не получал (сам нашел работу и устроился )

        Т.е. вы нашли компанию, компания не сделала вам предложение, но вы в ней работаете? Магия…
        • 0
          Я думаю, в посте имелось ввиду предложения от компаний, которые сами нашли тебя и предложили работу (возможно даже без собеседования).
          • +2
            А мне показалось что это соотношение прошел/не прошел собеседование…
            UPD точне взяли/взяли на работу, если вдруг собеседования не было
            • 0
              Хм. Теперь я запутался.
              • +5
                Давайте ещё раз:
                x — количество собеседований, x >= y. При приёме на работу всегда есть хотя бы одно, хотя бы формальное собеседование (даже если работодатель очень хочет этого работника),
                y — количество job offer-ов. Т.е. предложениий о работе. Трудоустройство == принятие job-оффера работником.

                Так понятней?
        • +6
          Есть:
          if(Вы_подходите && Хватает_денег)
          {
          Вы_приняты!
          }
          • 0
            Определите «Вы_подходите» — обычно именно с этим пунктом проблемы :-)
        • +1
          1) По какому основанию логарифм?
          Ну это видно, что перевод. log «по-ихнему» — это lg по-нашему.
          • 0
            Зависит от области. В математике, например, log обычно обозначает натуральный логарифм, т.е. ln. А вообще, утверждается такое:
            x = log y often means x = loge y in mathematics texts.
            x = log y often means x = log10 y in science and engineering texts.
            x = log y often means x = log2 y in computer science texts.
        • +1
          Я на втором собеседовании устроился, так что у меня все зависит от основания логарифма.
          Тоже первым делом обратил на это внимание. Либо натуральный, либо десятичный (скорее натуральный). Но уточнить стоило бы. Жаль статья переводная, у автора уже не спросишь.

          Перевод хороший.
          • 0
            Почему же не спросишь?
            Нет ничего невозможного.
            Если у кого-то есть реальный интерес в этом — я постараюсь связаться с автором и выяснить это.
            • +2
              Было бы неплохо. Потому что основание логарифма меняет формулу в разы, получается либо у всех будет
              • 0
                Написал автору. Если ответит — обязательно отпишусь.
                • +2
                  Там в комментарии к формуле на этот вопрос ответил автор. Десятичное основание)
                  • 0
                    Всё верно. Натуральный логарифм принято обозначать ln, а log без указания основания — десятичный.
                    • +7
                      Десятичный — lg
                    • +5
                      а log без указания основания — десятичный

                      Всю жизнь считал, что десятичный алгоритм — это lg
                      • –2
                        Натуральный логарифм тоже порою обозначают как log(x)
                        пруф даже в википедии:
                        Натуральный логарифм обычно обозначают как ln(x), loge(x) или иногда просто log(x), если основание e подразумевается.
                        • +2
                          А теперь прочитайте на википедии про десятичный логарифм. И о боже!

                          В зарубежной литературе, а также на клавиатуре калькуляторов встречаются и другие обозначения десятичного логарифма: log, Log, Log10.


                          пруф даже в википедии:

                          Это вообще смешно звучит.
            • +9
              Там десятичное основание.

              • +3
                И что это, получается при моих показателях «4 собеседования, 5 предложений работы» — я получаюсь лох полный с рейтингом 75? А должно быть как — 1 собеседование и 10 предложений?
                • +2
                  В идеале каждая компания, где проходили собеседования, если будет предлагать работу, то рейтинг выше 100 будет только при 10+ собеседованиях. Но такое маловероятно.

                  Если мыслить логически: человек идёт на собеседование в компанию, в которой хочет работать. И если они предлагают ему работу, то он скорей всего согласится. Так что, большое количество собеседований при большом количестве предложений маловероятно. Мы, конечно же, отбросим тех, кто по фану ходит на собеседование и остальные случаи, а будем говорить в целом.

                  Скажем, что каждое второе собеседование заканчивается предложением о работе, тогда чтобы рейтинг был >100, нам необходимо сходить на >100 собеседований. Фантастичные цифры )
                  • 0
                    У меня было чуть больше 100, когда в последний раз искал работу :-)
                  • +4
                    Уровень опытности инженера обратно пропорционален его зависимости от внешних оценок и формул :)
                • +11
                  Искать работу, на самом деле, интересно. Думаю многим знакомо несколько гнетущее чувство когда по какой то причине остаёшься без работы. Но когда начинаешь искать и тебе уже на первых собеседованиях говорят что берут, причем сразу в нескольких местах, надо признать (чего уж там греха таить), что тебе нравится и хочется испытать это чувство ещё раз. Но надо останавливаться и начинать работать, доказывая что в тебе не ошиблись. Безусловно, базовые знания важны но важно и иметь возможность показать что ты до сих пор делал и как. Причем, именно то что я уже сделал, снимало все вопросы и меня готовы были сразу брать. За всю историю меня никто никогда не пытал вопросами на знание алгоритмов или сообразительность. Возможно это немецкая специфика, но было именно так. Если у человека есть базовое образование и опыт то что то освежить не составит труда, в Германии это понимают. Не раз уже писал что надух не понимаю всех этих тестов и вопросов с подковырками. Зачем? Открой код написанный человеком и поговори о том что там написано, довольно быстро все станет понятно. Поговори о семье увлечениях, это гораздо важнее, т.к. позволит оценить уживчивость человека в коллективе. Опять же, если у человека есть хоть какой то опыт в конкретном языке (на котором предстоит писать) то гораздо большее значение имеет знание предметной области где предстоит кодировать, Согласитесь, глупо мучать вопросами из области распознавания образов человека которому предстоит программировать бухгалтерию. Мне кажется это болезнь, присущая некоторым крупным компаниям, не является какой то общей тенденцией в отрасли и говорит скорее о несовершенстве системы набора персонала в таких компаниях. Небольшие или средние фирмы могут себе позволить более предметный разговор с соискателем нежели прогон его по тестам и каверзным вопросам зачастую предвзято настроенными сотрудниками (дескать меня мучали я тебя тоже помучаю).
                  п.с. извиняюсь что тут немного поякал, просто нужно было как то веско обосновать сказанное, а что может быть более веским нежели личный опыт.
                  • +7
                    Алгоритмы еще ладно, вот теорему Коши о вычетах спрашивать при устройстве на позицию Android разработчика это по-моему ненормально. А случай был.
                    • +3
                      Ух ты, я всегда надеялся, что когда-нибудь это мне пригодится!

                      Жаль что это единичный случай. Хотя если подумать — то не жаль :)
                    • +5
                      Наблюдал ситуацию когда ребята которые хорошо шарят в алгоритмах на деле больше ничего и не умеют, т.е. даже не могут банально соблюдать code conventions, не говоря уж о какой-то базовой архитектуре и разбиении на модули.
                      И как мне показалось даже не пытаются все это постигнуть, т.к. считают себя крутыми программерами только потому что они знают стопицот алгоритмов на красночерных деревьях и графах, которые, как ни странно, используются крайне редко…
                      • +1
                        Они-то используются каждый день, только слава богу все это скрыто за удобным API stdlib, или любой другой стандартной библиотеки, которая покрывает потребность в алгоритмах на 99%.
                        • +1
                          Я имел ввиду повседневные задачи, безусловно мы все это используем, но никто ж не пишет для прода свой вектор/список/дерево :)
                          • +1
                            Никто не пишет, но обязан знать как на самом деле его программа работает… так ведь?
                            • +7
                              Знаю, что это прозвучит очень неканонично, но я в данную секунду наверное и базовых алгоритмов в точности написать не смогу. Каких-то из них я не знал никогда, какие-то знал, но за ненадобностью и неиспользуемостью они подзабылись.

                              И за мои почти 10 лет опыта работы разработчиком на С++ я если и страдал от этого незнания, то лишь в начале карьерного пути, когда не обладал иными достоинствами. Такими как знание/умение разбираться в стандартных (и не очень) библиотеках, умение в непонятных ситуациях формулировать и задавать вопросы, а также самостоятельно искать на них ответы, и, главное, ответственный подход к делу и стремление не делать говна. И все мои работодатели, кроме самого первого, были мной довольны и счастливы иметь со мной дело.
                              В тот единственный раз, когда я сам выступал в роли работодателя, я пытался подобрать исполнителя исходя из его знаний и умений. Подобрал, как мне показалось. И через несколько месяцев мне пришлось разорвать с ним сотрудничество, потому как он имел ужасную привычку тупо класть болт на поставленные задачи, не вчитывался в их формулировки и в конечном счёте делал не то, что от него требовалось, а то, что ему самому приходило в голову. Я долго пытался найти к нему подход, от почти полного делегирования всех деталей реализации на его усмотрение до почти полной формализации задач до каждой мелочи, но всё оказалось без толку.

                              Так что знание алгоритмов — это не панацея и даже, мне кажется, не самое главное. Наверное, в разных коллективах лучше всего работают разные стратегии подбора кадров, но лично я скорее возьму человека, который не знает вообще ничего, но имеет голову на плечах, способен логически мыслить и умеет слушать других и говорить сам, нежели того, кто всё знает, но при этом при коммуникации с ним ощущение, что говоришь с каким-то инопланетянином.
                              • 0
                                Ну понятно, что этого знания «про дело» нужно вагон и маленькая тележка. Но я просто к тому, что что-бы правильно проектировать программы из тех компонентов, которые предоставляет ОС и стандартные\не стандартные библиотеки нужно иметь представление как и что компонуется и какие имеет характеристики. Моя точка зрения чисто с такой архитектурной стороны, что если не иметь какого-то базового представления о том какие принципы заложены в них, то можно налажать с там, к примеру, int hashCode() { return 5; } и потом городить кеши, да всякие подпорки. Ну а когда требования к производительности возрастают, то и структуры данных должны быть лучше подобраны, что в результате, например, может означать для программиста, что просто нужно под определенный запрос создать индекс в БД.
                                • +2
                                  я вот, например, знаю что такое индекс, зачем и как влияет. Но понятия не имею как его реализацию написать на доске на собеседовании.
                                  • +1
                                    Вот вы и сами ответили: важно — знать, «что компонент делает», а не «как он это делает». Безусловно, если вы ещё и понимаете, как он внутри работает, то это огромный плюс. Но на производстве часто сроки не позволяют разобраться досконально в используемых компонентах.
                                  • +2
                                    Алгоритмы важны, безусловно. Для определённого круга задач, в первую очередь. Если в твоём проекте идёт стадия тотальной оптимизации и борьбы за вычислительные ресурсы — или если она хотя бы прогнозируется в будущем — то руководителям проекта будет целесообразно подбирать команду с учётом наличия подобных знаний, либо же провести ликбез по этой тематике. С учётом того, что специалисты в целом должны быть подготовленные и сообразительные, подобную акцию можно не растягивать на несколько месяцев, которые длится обычный вузовский курс по алгоритмам, а дать в виде небольшой брошюры, в которой были бы срезюмированы абсолютно необходимые и обязательные к написанию «с закрытыми глазами одной рукой за спиной» вещи, плюс что-то ещё для расширения кругозора, плюс ссылки на годные источники информации по теме — для собственного интереса и самообразования. Ну и пару коллективных Q&A после этого провести — для закрепления пройденного материала.

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

                                    Понятно, что есть системные архитекторы, которые создают скелет проектов с чистого листа. И вот от их способности построить этот скелет грамотно, в том числе с использованием правильных алгоритмов, зависит то, получится ли в результате полноценный продукт или же какой-нибудь уродец. Таким людям, понятное дело, алгоритмы знать положено по статусу. Но далеко не каждый программист, даже в Google, может похвастаться полномочиями уровня архитектора. По большей части, работа программиста сводится к рутинному кодированию вещей, незатейливых с точки зрения алгоритмов, но требующих хорошего понимания в структуре проекта. И тут усидчивость, хорошая память и добросовестность становятся куда ценнее, чем знание алгоритма Дейкстры =).
                        • +4
                          В точку, все верно, люто плюсую. Насчет алгоритмов — я слабо представляю, как умение написать алгоритм Дейкстры во сне (подразумевается, тупо заучив его) поможет в написании UI для gmail. Чем, обычно, и грешит Гугл (Яндекс, Epam) на собеседованиях — набирают лучших инженеров, задают вопросы по выученным алгоритмам, и садят за адаптивную верстку продукта 100500-й важности
                          • +2
                            Делают, потому что могут себе позволить :) От желающих отбоя нет.
                            • +1
                              Отбоя нет от неопытных джуниоров.
                              Люди с >10 годами опыта не очень-то ломятся забыть о семье и увлечениях в пользу педаленья за компом по 12 часов без выходных, пусть даже и хорошо оплаченного.
                        • +2
                          Круто написано! Получился хороший толчок для джуниоров =)
                          • +1
                            У меня разорвался шаблон, когда в первой формуле я начал делить на ноль
                            • +4
                              А когда логарифм ноля считали ничего не рвалось?
                            • +1
                              А что там про олимпиадников на позиции «промышленных» программистов писали, кто помнит? :)
                              • –3
                                Смешная статья.
                                Если автор программирует, что бы зарабатывать, мне его искренне жалко.
                                Я программирую и от этого я просто в нирване, а деньги, как доп. бонус.

                                И стартовая формула, как сейчас модно называть «для неудачников».
                                Считать нужно компании которые ТЕБЯ устраивают. Нужно быть хозяином положения, даже когда ты наемный работник, а не пресмыкающимся. «Ой, меня не взяли, я наверно плохой» :)))
                                Правельная формула: «Я выбрал из ХХХ компаний только Х, потому что только они меня устраивают».

                                Нужно автору из точки зрения раба, перейти в позицию хозяина. Не ведитесь, не примеряйте его маску, она негативная :)))
                                • +3
                                  Если автор программирует, что бы зарабатывать, мне его искренне жалко.

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

                                  Что мешает наслаждаться программированием на работе? Вот я люблю программировать: и на работе программирую, и когда есть время свободное программирую.
                                  • +1
                                    Да, Вы правы, на попечении родителей :))))
                                    За одной маленькой неточностью, я сам родитель уже не один десяток лет и многодетный папа. Программирую тоже несколько десятков лет.
                                    Я фанат программирования.
                                    А эта статья навязывает рабское мировозрение и ничего более.
                                    Я читаю тех. литературу по выходным, в свободное время что то изучаю не потому что я «прокачиваю скилы, что бы меня взяли на работу», а потому что мне это интересно.
                                    Я на работу устраивался ВЫБИРАЯ работу, а не делал подсчеты, на сколько я плох/хорош по собеседований от разосланых резюме.
                                    Ей богу смешно.
                                    То что минусили меня, это явно студенты или начинающие программеры. Те у кого программирование — призвание, а не работа, кто выбирает работодателя ставя свои условия, те меня понимают. :))
                                    • 0
                                      Так всё-таки, деньги-то вам нужны или нет? :)
                                      • 0
                                        В одной хорошей книжке было написано: «Вы работаете не за деньги? Тогда отдайте их мне!» :-)
                                    • +1
                                      Если бы мне не платили, я бы программировал своё и для себя. Но мне платят. И там не всегда такая уж нирвана. Бывает и откровенный шлак.
                                    • 0
                                      по-моему автор исходит из предположения, что интервьюирующий лучше тебя (кандидата) разбирается в теме. По моему опыту, это скорее наоборот. Не знаю, как там с гуглом, но маленькие компании ищут сантехника, потому что сами не умеют, и тут важно объяснить человеку почему ты хотоший сантехник, и желательно на доступном уровне и без лишней терминологии. как-то так.

                                      ПС: в 99-м году проходил интервью в достаточно большой фирме. Искали человека который знает java. Показали листинги и спросили, «что делает код?». где они правильные ответы брали я не знаю. но это так — элюстрация.
                                      • +3
                                        в 99-м году проходил интервью в достаточно большой фирме. Искали человека который знает java. Показали листинги и спросили, «что делает код?».

                                        Знаете, какое в вакансиях часто встречающееся требование к соискателю? «Умение разбираться в чужом коде».
                                        В этом плане показать кусок кода собственного написания и попросить в нём с ходу разобраться — неплохой тест для соискателя. Потому как, в отличие от теоретизирований на тему алгоритмов, структур данных и особенностей языка, а также попыток сходу без привычных инструментов накреативить какой-нибудь работающий код на заданную, умение разбираться в коде у хорошего программиста развивается до уровня рефлексов и регулярно эксплуатируется в обычном рабочем процессе при стрессовых условиях («надо срочно пофиксить»), так что волнение будет вносить не столь сильные искажения в демонстрируемый результат.

                                        Понятное дело, что многое зависит от того, насколько хорошо структурирован и оформлен код, а также от того, смотришь ли ты его на экране компьютера в знакомой IDE, или же в распечатанном виде. Но, тем не менее, по ходу рассуждения и по задаваемым соискателем вопросам можно составить неплохое впечатление о его адекватности и способностях. А не это ли главная цель собеседования?
                                        • +1
                                          «что делает код?». где они правильные ответы брали я не знаю. но это так — элюстрация.

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

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