войти зарегистрироваться

human resources whois

индекс
81,96

Собеседование глазами собеседуемого


Набросаю несколько мыслей по тому, каким я вижу правильное собеседование на вакансию software developer.


На собеседовании работодатель должен предложить кандидату чашечку кофе/чая. Это обязательно! И с этого нужно начинать. Кофе располагает к беседе. Кандидат чувствует себя комфортней, мозг начинает работать лучше. За одной чашкой можно предложить другую, третью, в зависимости, как пойдет беседа. Удивительно, но в силу недоразвитости культуры проведения собеседования, работодатель игнорирует это элементарное действие… Я уже молчу про то, что в идеале бы угостить бокалом вина. =). И далее, соответственно, как пойдет ). Таким образом, из скучной рутины мы превращаем процесс в увлекательное действие. Это первый сценарий.

  • Не нужно кандидату взрывать мозг хитроумными задачками. На собеседовании его мозг уязвим и откровенно высосанные из пальца задачи только навредят.
  • Идиотские вопросы, типа что такое стек, сколько бит в байте, маразматические – можете ли написать демона под линукс – оставьте себе. Это может обидеть кандидата.
  • Если это C++ вакансия – всю сиплюсплюсную лажу оставьте при себе. Вы испортите впечатление о конторе, спросив, можно ли вызвать чисто виртуальную функцию и сказав, что у нас такое часто бывает, выскакивают разные предупреждающие ассерты.
  • Все вопросы по COM – держите при себе. Вы устарели. Кандидату неприятно будет это осознавать.
  • Хардкорные вроде того, что как узнать, является ли число степенью двойки за O(1) это конечно клево, но кто способен сходу, не зная, родить решение? Зачем это спрашивать?

Ок, что же тогда спрашивать? Элементарно. Никаких заготовок, тестовых заданий, задач на бумаге за отведенное время. Спрашивать нужно о том, что сделал кандидат на предыдущих работах. Конкретно. Никаких абстрактных задачек на поиск пути (хотя можно =), а просто, приближенно к реальности, что и как и почему им было сделано.

Создать контекст и быть внутри этого контекста. Это сложно? Нет. Так почему же лишь единицы это понимают? (единица! =).

И только уже исходя из предпосылок – сделанной кандидатом работы – можно спрашивать связные по теме вещи.

Как-то так. Навеяно ).

Ваша задача, как работодателя, найти, понять, что интересно кандидату. Интересен ли он вам? И смотреть, пересекаются ли ваши интересы, в каких областях и насколько.
+12
25 января 2010, 18:09
9
rwxrwxrwx

комментарии (154)

  • > Перенести в тематический блог не хватает кармы.

    После этой фразы может очень долго не хватать.
  • Здрасьте -> ча(й||ко)фе -> brainbench -> и снова здравствуйте! -> а как вы думаете...?
    • не уловил вашу мысль)
    • Похоже на Лабораторию Касперского.
      • Скорее на любую компанию, которая сначала проверяет претендента на знание основ его профессии (через тесты на Brainbench.com) и уже после этого, убедившись, что претендент приемлемо знает свою область, проводит с ним один-три раунда собеседования, выясняя его личностные качества.
        • Логично, если эти раунды не начинаются с «А расскажите нам зачем используются виртуальные функции… ».
          • Но если вы сдали тесты Brainbench (то есть знаете зачем они), но не можете объяснить это словами (то есть не умеете выражать знания словами), то в команде работать вам будет сложно. Это не смертельно и навык будет со временем приобретен, но если будет претендент обладающий навыкам, по уровню сравнимыми с вашими, но умеющий работать в команде — возьмут его.
    • sse
    • sse
    • 25 января 2010, 18:48
    • #
      • +11
    Вы там пьяный, что ли?
    • кажется, трезвый ).
      • А чего тогда такую ахинею городите? Бухать на собеседовании, COM устарел — бред полный. По Вашей схеме можно отправить курить бамбук талантливого вчерашнего выпускника вуза, не имеющего опыта работы и при этом принять человека, который вообще не может «хеллоу ворлд» написать на том лишь основании, что он когда-то в прошлом был в команде какого-то проекта (пофиг кем, любовницей менеджера) и представляет из каких модулей тот проект был сделан и на каких технологиях написан.
        • Талантливый выпускник с удовольствием расскажет про свой диплом. Поэтому «курить бамбук» он будет уже в рамках конторы ).
          • Если продолжить вашу мысль, то собеседование должно быть таким: приходишь устравиваться, тебя поят кофе/вином, ты спрашиваешь про проекты и если тебе понравился офис, проекты и зарплата интересная, то соглашаешься. А работадатель ничего спрашивать не должен, а то обидит своими тупыми устаревшими вопросами.

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

            Лично я обязательно спрашиваю вопросы самые простые вопросы, даже если уверен что этот кандидат уж точно знает ответ. Сколько раз натыкался на то что человек с хорошим резюме, бэкраундом и производящим впечатление опытного разработчика не может объяснить что такое виртуальные функции или еще что-нибудь из самых основ.
            • А что вы понимаете под объяснением виртуальной функции? Я могу нарисовать как будет vtable выглядеть в памяти, но право хоть убейте, затрудняюсь дать словесное определение.
              • Ну люди либо понимают как работает виртуальные функции, либо нет. Если есть трудности с формулировками, то понимание проверяется на примерах на листочке.

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

                Тут скорее был общий вывод сделанный мною для себя: нужно задавать простые вопросы.
  • Только у меня ощущение что пост целиком это сарказм и стеб? Что-то не очень вериться что автор серьезно так может излагать свои мысли?
    • А мне вот нравится точка зрения автора)
      • Просто рад интереса — вы нанимали на работу людей, интервью проводили?
        • Нет, только сам нанимался, и мне бы понравилось проходить такое собеседование вместо того, чтобы писать 5часовой тест.
          • Не загнули про 5-ти часовой тест? Именно тест — вопрос и выбрать один из вариантов ответов?

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

            Вот только думаю после того как вы перейдете на другую сторону стола, вам резко перестанет нравится.
            • Нет, не загнул. Девочкой из HR была выдана пачка листов с тестами, именно тестами (вопрос и выбрать вариант ответа), и было сказано, что в среднем тест займет 4-5 часов.
              • Ясно — печально что могу сказать, это дейсвительно какой-то ненормальный варант. А вакансия была на что? Как называлась?
                • совершенно обычная вакансия .Net разработчик
                  в требованиях C#, MsSQL, владение ООП
                  в общем, станадартнее некуда)
                  • А девочка была из HR агенства, или это было собственный HR отдел компании?
                    • Собственный отдел
                      • Спасибо за ответы.
                      • Вы прошли очередной тест.
  • > Идиотские вопросы, типа что такое стек, сколько бит в байте, маразматические – можете ли написать демона под линукс – оставьте себе. Это может обидить кандидата.

    > обидить
  • >> Спрашивать нужно о том, что сделал кандидат на предыдущих работах.
    Если убрать все остальные фразы — информационная наполненность топика не изменится.
    • всё предыдущее — из личного опыта
  • А я как-то пришёл на собеседование и мне предложили чай, кофе, вискаря отведать, ну то было в маленькой студии, в крупных обычно какие-то хмурые люди, задают тупые вопросы… больше всего бесит вопрос «Ну. расскажите что-то о себе!», обычно после это начинаю нести заучиную в школе фразу «Хеллоу, май нэйм ис Дэнис, ай лив ин Одесса.Одесса ис э вери бьютифул сити»… и дальше по тексту… по достали >_
    • Во-во точно! Ужасный вопрос!
    • А я люблю данный вопрос. И задавать на собеседовании в том числе.

      Ибо он очень наглядно показывает как человек может говорить. Сможет ли он потом на конференс коле сделать нормальную краткую презентацию текущего состояния проекта, сможет ли обрисовать общую картину проблем в проекте. И вообще — может ли нормально общатся. В данном вопрос практически не важно ЧТО человек говорит, важно КАК он это говорит.

      ИМХО обязательный вопрос, если конечно соискатель претендует на что-то большее чем просто кодер.
    • А мне как-то в большой и уважаемой, и даже настаивали…
      • Ну не знаю. Мне лично приятно рассказать о себе любимом, когда собеседуют меня. Это говорит о том, что компания хоть немного думает о том, какого ЧЕЛОВЕКА они собираются брать. И опять же, когда собеседую я — мне не нужен кодер «от звонка до звонка». Мне нужен член команды, с которым я и команда сможет нормально общаться не только на рабочие темы.
        • Уважительное отношение всегда приятно. Но любое собеседование для приема на работу — это торг, так или иначе. Если стороны помнят об этом, то, как мне кажется, особых проблем и недопонимания не должно возникать.
          • Безусловно.
  • ИМХО есть 2 типа собеседований:
    1. приходит шеф к совему специалисту «завтра придет человек напиши 20 вопросов для него, а я поспрашиваю, ну и сделай правильные ответы для меня на отдельном листике»
    2. «завтра в 13-00 прийдет человек, никуда не уходи, будем собеседовать, ты по специальности я орг-вопросы»

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

    П.С. я «проводил» оба типа собеседований
  • Могу про хардкорные задачки сказать, часто их задают не для того, чтобы получить правильный ответ, а чтобы посмотреть, как кандидат может размышлять и искать решения. Иногда даются невыполнимые задачи или человеку ставится неразрешимая ситуация, по той же причине. ИМХО это правильно, если конечно тот, кто дает такие задания, сам понимает их цель, а не ждет всегда правильного и точного ответа.
    • в частности, на одном собеседовании для меня было важно услышать от человека через минуту размышлений «я не знаю», это лучше чем 5 минут «ну э… ну может так… а нет… точно не так, но вот может так, а?»… для этих целей из мана была выдрана абсолютная глупость и не нужность… просто скажи «я не знаю», это будет ответ на «4 из 5»
      • Это хорошо, когда человек готов сказать «я не знаю». Но гораздо важнее, если затем следует не точка, а запятая.

        «я не знаю, но я бы сделал так...»

        Пример вопроса: 'что будет, если вызвать метод new File(«foo.txt»).delete()' для залоченного файла?"

        «Я не знаю» — достойный ответ, 3 балла.
        «Я не знаю, но думаю, что возникнет исключение» — неправильный ответ, но 5 баллов, поскольку именно так и должен был бы вести себя метод, если бы не головотяпство разработчиков из Sun.

        Просто незнание — хреново. Незнание + честность — приемлемо. Незнание + мышление — то, что нужно. Доучить — не проблема.
    • Согласен полностью. Задачи на собеседовании необходимы для того, чтобы понять как мыслит человек. Нужны они или нет, зависит от конкретной вакансии.

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

      Это так просто. А всякие глупые вопросы спрашивают те, кто не заинтересован в кандидате совсем и не будет драться за закрытие вакансии.
      • Системы багтрекинга знает?
        Вы риальне берете на работу людей, которые не могут освоить новую систему багтрекинга за один день?
        • Если это будет маркетолог, то да. Ему не нужны такие сложности.
          • Вы пишете «если я беру на вакансию кодера»…
            • ааа, про этих. Кодерам обязательно знание конкретных инструментов.
              • Нормальный кодер должен осваивать нужный инструмент.
              • Если завтра PM решит сменить систему багтрекинга, всех выгоните, новых возьмете?
        • Есть конторы, которые ищут кодеров подешевле — пять копеек за пучок.

          Само собой, что таких нет смысла дообучать — проще нанять новых.

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

      … и если он начинает при этом вставать в позу «да как вы вообще посмели спрашивать меня про виртуальные функции и вообще ваш COM давно устарел» — это самый лучший момент напомнить себе, что дешевле не брать, чем потом увольнять.

      Есть у меня, к примеру, в арсенале типовые вопросы про JDBC. И есть опыт принятия на работу двух человек, которые не стали про него рассказывать — первый сходу сказал, что это устаревшая фигня, а второй честно сказал, что никогда с JDBC не работал и использовал только iBATIS. Первый был уволен через 3 месяца ко всеобщей радости (оказалось, что кроме изучения новых технологий ничего делать не может), второй работает уже больше двух лет.

      ИМХО это правильно, если конечно тот, кто дает такие задания, сам понимает их цель, а не ждет всегда правильного и точного ответа.

      Эт' да, самый страшный кретинизм интервьюера — жесткое бездумное сравнение с эталонными ответами. Написано у него в опроснике, что правильной оценкой для функции вычисления факториала int f(int n) будет O(n) и за решение с O(1) сразу ставит минус. К сожалению, встречается такое сплошь и рядом.
      • Не знаю, что подразумевается под «решение с О(1)», но само по себе O(n) — вообще имхо неудачный ответ для факториала int f(int n), потому что математически эта оценка неверна, а практически — бессмысленна :)
        • Классическое «из книжки» решение (итерация или рекурсия) дает время выполнения формально O(n), но ввиду очень быстрого роста результата имеет смысл применять выборку их предварительно вычисленной таблицы значений, что дает нам независимость времени исполненния от значения параметра.
          • Если учитывать ограниченность параметра (а не говорить про абстрактный факториал), то классическое решение даёт так же О(1), как и решение с табличкой, просто с другой константой.
            Понятно, что абстрактное время выполнения зависит линейно от n, но если уж говорить про сложности алгоритмов и асимптотики, то О(n) здесь как-то бессмысленно.
            • Классический книжный вариант решения, работающий без контроля переполнения, дает начиная с некоторого порогового аргумента неверные ответы и вычисляет их именно за O(n) :)
              • Это да. Но опять же, с практической точки зрения это «О(n)» имеет мало смысла, потому что ответы неправильные :)
                • Оценка правильности и времени работы — две разные оценки. ;)

                  Что забавляет — так это маниакальное упорство, с которым неприменимые для какого-либо разумного использования примеры кочуют из книжки в книжку…

                  P.S. Кстати, у правильной реализации, считающей факториал для любого «int n», оценка будет существенно хуже O(n).
                  • Оценки-то разные, но только до тех пор, пока они не связаны. Про О(1) не я первый начал ;) Без учёта ограничений О(n) в О(1) не превратится…

                    Ага, я тоже подумал про факториал для длинных чисел :) По моим прикидками что-то вроде O(n^2 log n) получается.
          • Т.е. подменяем вычисление поиском по упорядоченному массиву — почему же это O(1)? ;)
            • Если программист ищет i-й элемент массива итерированием от начала — это первый признак смерти мозга.

              Время прямого обращения по индексу не зависит от длины массива, соответственно это O(1).
  • >Хардкорные вроде того, что как узнать, является ли число степенью двойки за O(1) это конечно клево, но кто способен сходу, не зная, родить решение? Зачем это спрашивать?

    А по-моему, не так уж тяжело и додуматься — вопрос ведь скорее на логическое мышление.
    Я бы предложил, скажем, вариант ((a^(a-1))>a).
    А есть какие-то другие?
  • (a & (a — 1) == 0), но дело в другом. Вы полагаете, что это на логическое мышление? Я не знаю ни одного человека, ответившего на этот вопрос, с условием, что он не знал ответа.
    • Я не знал ответа, решение придумал на ходу буквально за минуту. хотя ваш вариант изящнее ;-)

      Да, это явно вопрос на логическое мышление. Другое дело, что его для отвлечения собеседуемого можно преподнести под видом «словесной головоломки» или какой-нибудь простенькой геометрической задачки (ну, скажем, знаменитой Гарднеровской с дыркой в шаре длиной 6 см)
    • > Я не знаю ни одного человека, ответившего на этот вопрос, с условием, что он не знал ответа.
      Возможно, вы с неправильными людьми общаетесь :)

      Это не хардкорный вопрос. Это в принципе совершенно тупой вопрос.
      Любой человек, умеющий думать головой, способен пройти цепочку «Надо за О(1) -> надо в несколько операций -> битовая арифметика -> чем отличается степень двойки от нестепени? -> тем, что в ней ровно один единичный бит -> за одну операцию можно его убить -> маска n — 1, получим ноль»
    • Да, я полагаю что это на логическое мышление и набор базовых знаний.
      Впервые я на него ответил не зная ответа.

      Логика мышления была простая:

      0. O(1) т.е. простые преобразования и сравнение
      1. 2^x это 1 и x нулей в двоичной системе — рисуем это на бумажке
      2. Раз перешли к двоичной системе -> битовые операции
      3. Как можно убедится что у нас и 1 и 0 на месте точно -> AND
      4. С чем нужно сделать AND -> c 0 в начале и (x-1) единичек -> рисуем это на бумажке
      5. Ой, да это же у нас 2^x-1
      6. Ответ

      На все примерно минута, собеседования я проходил на втором курсе.

      Более того, на другом собеседовании когда мне спросили как лучше сохранять двухцветные картинки я предложил построчное RLE, еще не зная о таком.
      • Афигеть, примерно минута, я так не догадался :( С другой стороны, не такая это нужная операция.

    • По моему опыту здесь необходимо знание того, что «отнимание единицы — полезная операция в битовых преобразованиях». Я пока не знал этого, не мог придумать решения всяких задач на тему подсчёта единичных битов. Когда узнал решение одной такой задачи, стало всё понятно. Теперь «вычитание единицы» автоматически входит в пул перебираемых в голове операций :-)
    • И в чем вопрос? При каких a это возможно что ли? Просто интересно.
    • Согласен с вами. Я, например, не знаю (или знал, но забыл :) про вычитание единицы. Поэтому начал бы с того, что рассказал, что особенностью степеней двойки является то, что в двоичном виде они содержат только одну единицу. После чего спросил бы, нет ли в процессоре, под который ми разрабатываем инструкции, которая подсчитывает количество утановленных бит в слове (я когда-то видел описание процессора, который содержал некоторое множество хитрых инструкций для работы с битовыми операциями).

      Если нет (ах, какая жалость, ах, какой сюрприз:), то предложил бы считать количество единиц выполняя побитовый сдвиг и операцию and с единицей. Поскольку, для работы целыми числами в современных процессорах мы используем слово в 32 бита или 64, то количество выполняемых операций будет C*32 либо C*64, таким образом, сложность нашего алгоритма О(1).

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

      В любом случае, был бы удивлен, если бы отказали в работе из-за того, что не нашел точного решения. Формалисты, ну их нафиг, будут и работать требовать по свистку. Хотя в моей практике такого, конечно, никогда не было, с той стороны сидят точно такие же люди, и им важно не столько решение задачи, сколько отношение к ситуации (главное, без паники, всего знать все равно не возможно, для этого есть интернет/коллеги о чем и нужно разъяснить интервьюерам:)
    • Я бы скорее всего тоже не догадался до a xor (a-1), но только говорит ли это о чём-либо?

      Вообще, формулировка задачи какая-то странная. Что вообще имеется в виду под О(1), независимость от чего? Если, например, от числа бит, то ответ про (a-1) — неправильный, потому что эта операция будет O(n) от числа бит. А если число бит ограничено, то получится О(1) даже если просто двойку в цикле в степень возводить. Может, имелось в виду решение «в одну строчку», а О(1) для красоты нарисовали?
    • a&&(1!=a)&&(a&(a-1)==0) если точнее.
      • 1 — вполне так себе степень двойки :)
        • А если еще точнее то это степень много чего ;)
          • Точно :) Но всё же когда говорят, например, «разложение по степеням двойки», 1 автоматически включается, т.е. неправильно её откидывать.
            • Согласен, можно оставить в качестве рояля в кустах.
  • А я как-то искала сотрудника — молодого и амбициозного, в небольшой коллектив с хорошим тимбилдингом. Когда очередной кандидат зашел в кабинет не с портфолио, а с чашкой чая (у секретаря узнал, где можно налить чай) — сразу стало понятно — наш человек! Все профессиональные данные тоже подошли, очень удачно вышло

  • Вам никогда не задавали правильных вопросов, поэтому вы не хотите чтобы вам вообще задавали какие-либо вопросы. Вы не правы.
    • я не говорю, что я не хочу, чтобы мне не задавали вопросов ), вопросы должны быть «в тему».
      • ОК, вот вам вопрос по Си++ в тему: в чём особенность обработки типа char или производных от него типов, при выборе перегруженной функции? Сможете ответить?
        • ммм, это не в тему. в тему — это когда, например:

          — реализовал инвертированный индекс
          — ух ты, а что это? как это работает? как реализовали? почему так? какой дизайн? и тд. почему решили сделать «так», ведь «вот так» же эффективней, не? а что с многопоточностью? и тд.
          • Знаете сколько людей как вы рвались в бой, а на деле не знали элементарщины? Нет, я буду проверять с нуля. Большинство программистов самоучки без систематического образования и часто незнают простых вещей. Такая бомба всегда взрывается в неподходящий момент. Не-хо-чу. Задача процедуры найма вовсе не состоитв том чтобы нанять лучшего. Некоторые наивные люди верят в эту чушь, но это совсем не так. Задача процедуры найма отсеять всех тех кто гарантированно или с большой вероятностью навредит. Поэтому, да, я буду спрашивать пять ключевых слов, десять функций stdlib и прочий бред, чтобы отсеять самоуверенных людей без систематических знаний. Они опасны для бизнеса.

            Вот вы упомянули многопоточность, вы точно уверены что разбираетесь в ней? Можете назвать три главные проблемы, объяснить их суть так чтобы поняла моя мама, которая едва разобралась с мобильным? Точно можете? А перечислисть примитивы синхронизации и описать назначение каждого? А то же самое, но опять для мамы?
            • Как я понимаю, «собеседование Баткина» для тебя является идеалом :)
              Все же мне видится что это другая крайность.
              • Оно очень большое от беспомощности. Я не считаю это правильным путём. Проверять надо не только знания, но и навыки.

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

                Я не спрашиваю напрямую о сложных вещах, а обрисовываю жизненную ситуацию, предлагая решить её, опять таки, в рамках истории далёкой от IT. Это позволяет проверить не вызубренные формулировки, а навыки решения проблем.

                Кроме того, ставить кандидата в стресс, в том числе заумным вопросом, в зависимости от должности (старший разработчик), может быть вполне нормально. Впадёт ли человек в панику или постарается упорядочить процесс решения? Будет тратить время на безуспешные попытки или потратив заранее определённый лимит времени остановится? Эта разница гораздо важнее правильного ответа.
                • У Баткина если абстрагировать от геймдева интересны первые два блока вопросов. Причем интересны с обоиъх столов стола.

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

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

                  Вот такой диссонанс.

                  На последнем моем собеседованияя меня в ступор поставил вопрос битовое представление -1 в float. Я неожиданно для себя понял что с битовыми операциями и представлениями не работал уже лет пять (ну исключая сдвиги). Все что я выдавил из себя это то что там отдельный бит на знак. Так же я еще завалили парочку подобных вопросов. Впрочем, я прошел интервью в результате.
                  • Самое смешное — есть представления float, где за знак отвечает отдельный бит. Не знаю только, использует ли это кто-то сейчас. :)
                    • Ээээ, конечно есть, и он называется IEEE 754

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

                      Или я вас не понимаю… и вообще не очень могу вспомнить представление float без знакового бита.
                      • Вы правы, я выразил свою мысль невнятно. Я имел в виду представления, где мантисса хранится не в дополнительном коде. Соответственно, к примеру, мы можем иметь +0.0 и -0.0.
            • Вот! Так ведь никто не мешает уйти к базовым вещам. Я к тому, что нужно от чего-то отталкиваться, чтобы к чему-то прийти. Я упомянул про многопоточность, вы начинаете спрашивать про соответствующие подводные камни. Соответственно, становится виден уровень собеседуемого (он коснулся этой темы, а как он это понимает?).
            • Мне понравилось, когда я устраивался в одну фирму, мне между чисто между делом просто в лоб спросили «2^7?». Больше особо ничего не спрашивали (наверно потому, что ответ был чисто машинальный — 128), кроме общих вещей об опыте работы и какие задачи выполнял.
      • В тему для чего? Интервью это не только способ понять технические навыки. Это еще и способ понять что за человек.

        Пускай он технический геней — но если он внятно не может разговаривать, не может поддержать беседу, не имеет чуства юмора и т.п., то он в команде не желателен. И все это нужно проверить на интервью.
        • Таких можно брать на отдельную работу и периодическим контролем. 90% программистов не умеют разговаривать и писать не код.
          • Практика использования wiki и внутрипроектных блогов показывает, что не менее половины программистов в состоянии писать связные тексты.

            Практика применения agile-техник показывает, что 100% программистов умеют полноценно вербально общаться.

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

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

            Т.е. в идеальном случае гений все же не нужен… в реальности да — как правило ему место находится. Но это только потому что делать все идеально дорого, а не от того что так хочется.

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

                Плюс правильно решенная задача с точки зрения гения это не всегда то что хорошо поддерживается. Он элементарно может применить алогоритм который он считет очевидным, но потом когда потребуется модификация кода с этим алгортмом простой программист будет разбиратся долго. И вот тут очень тонкий баланс — а стоит эти 0,2% ускорения в общей системе от сложного алгоритма, если потом его модификация занимает человеко-месяцы.
                • А давайте взглянем на ситуацию с другой стороны.
                  Сроки нарисуем исходя из того, что у нас средненькая по уровню команда, а гений нам поможет эти сроки сократить. Разве это плохо? Раньше закончили проект, раньше взяли другой — в единицу времени заработали больше денег. А если уж неразговорчивый гений нас неожиданно покинул, то просто сделали задачу в срок.
                  И обращу Ваше внимание, я сверху написал «не будет лишним в большой команде».

                  А насчет того что задачку никто не сможет поддерживать.
                  У нас было заведено (когда я работал в офисе) решения сложных задач описывать. Даже если этот гений с трудом поддерживает беседу на отвлеченные темы, в профессиональных терминах он решение объяснить сможет. Ну не видел я людей которые не умеют рассказать как они это сделали. Описывается это и в коде и в документации, а для особо интересных задач можно провести семинар, где докладчик расскажет что и как сделал — поднимет эрудицию всей команде.
      • Не помню, кто сказал, что вопросы бывают двух типов — плохие и хорошие. Хорошие — это те, на которые знаешь ответ :-) Складывается ощущение, что автор просто хочет хороших вопросов :-)
    • x64
    • x64
    • 25 января 2010, 19:27
    • #
      • 0
    Неплохой способ проведения интервью. Но все же главная цель собеседования не провести непринужденную беседу с обоюдным пусканием пыли в глаза, а продать себя подороже и оценить, как можно точнее, сколько стоит оппонент.

    Хотелось бы подетальнее узнать, как вы предлагаете выяснить уровень подкованности кандидата в тех или иных областях.
    • Ок, такой сценарий: кандидат упоминает, что, реализовал свой мемори менеджер.

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

  • Как-то мой знакомый пришёл на собеседование в компанию ОТР. Долго сидел в комнате и ждал кого-нить из отдела кадров. Пока время шло, он стал листать все журналы в области досягаемости.

    И… в очередном номере «Новости ОТР» под обложкой нашёл последний номер Playboy. Это правильное собеседование?
    • Неправильное. Служба внутренней безопасности должна была его выгнать за то что трогал вещи без спроса.
      • Журналы лежат для ознакомления в переговорной. Они необходимы, точно так же как и фломастер для рисования на доске.
  • > маразматические – можете ли написать демона под линукс
    Что Вы имели в виду, когда это написали?
    • «можете ли написать демона под линукс» — это вопрос из серии — «умеете ли вы компилировать» ).
      • Вы не поверите, сколько людей, приходящих на собеседование, не знают, как демонизировать приложение. Это может быть как случайностью (человек не знает ответ только на этот вопрос), так и показателем (он вообще ничерта не знает). Пяток таких вопросов, и уровень кандидата начинает проявляться.

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


          Имхо, грамотный человек на вопросы с подобной формулировкой должен отвечать «могу» не задумываясь, даже если он не делал такого раньше ни разу.
          • И тут возникнет допвопрос: «И что будете делать, чтобы ваша программулина запустилась как демон?»
            • "(Возмущённо) Я что, всё константы наизусть помнить должен?" :)
    • «можете ли написать демона под линукс» — это вопрос из серии — «умеете ли вы компилировать» ). Он ни о чем.
      • Реакция на него отлично позволяет понять, может ли человек работать в коллективе и можно ли допускать его общение с заказчиком.

        Один лично мне знакомый человек каждого спрашивает про оператор присваивания. Начинающие — путанно рассказывают, профессионалы — просто рассказывают, юные гениальные дарования, непригодные для работы — встают в позу. Сам этим вопросом не пользуюсь, но идея мне нравится.
  • Вы думаете все могут ответить на вопрос сколько бит в байте и почему?
    Молодой человек, вы еще очень мало собеседований провели сами.
    • А вы думаете, человек не знающий сколько бит в байте не срежется на других, более «жизненных» задачах?
      • Я так подозреваю, что если человека спрашивают, сколько бит в байте — его резюме не произвело особого впечатления на принимающую сторону.
        У яндекса в свое время был вопрос в онлайн-тесте для перлистов о том, что вернет функция defined для пустой строки, и несколько вариантов ответа, из которых надо выбрать правильный. Функция настолько часто используемая, что неправильно ответить на нее может только полный чайник. Оказалось, что половина пришедших людей не может ответить на этот вопрос или объяснить решение хоть как-нибудь! Половина!
        • > Я так подозреваю, что если человека спрашивают, сколько бит в байте — его резюме не произвело особого впечатления на принимающую сторону.

          Я к тому, что собеседование нужно начать «как с умным человеком». А на вопросы про биты в байте скатываться уже позже.
          • Именно. Прежде всего — чтобы не тратить свое время.

            Так что если дошли до битов в байте — это явно идет анализ «ну может хоть помощником младшего кодера взять?»… :)
            • Не факт. Если ответит «восемь» — то да, помощник младшего кодера. Если расскажет про отличие байта от октета — то… :)
    • а что, есть какая-то глубокая причина для количества бит в байте?
      • Байт
        • И что? Какой правильный ответ на вопрос почему в байте 8 бит? «Так сложилось исторически»?
        • Надо сказать, что ответ на вопрос почему совсем не очевиден. Если он вообще есть.
  • Ну и еще.
    Кандидату приятно чтобы ему принесли кофе, спросили что он делал раньше, и, независимо от ответа, сказали «берем!».
    Если вы такой обидчивый кандидат — покатайтесь в общественном транспорте.
    Ах, да.
    Кандидату это неприятно :)

    Удачи в поисках работы
  • Вы мне явно понравились :)))
    3й коммент.
    А что вы делали на предыдущих работах?
  • Однако… Спасибо, что на наглядном примере объяснили, что такое «юношеский максимализм» и «звезданутость».
    «Если это C++ вакансия – всю сиплюсплюсную лажу оставьте при себе».
    «Все вопросы по COM – держите при себе. Вы устарели.»

    Налейте мне чаю и ничего не спрашивайте…
    • И вообще, вопросы здесь задаю я. Я что, на ваши вопросы тут пришел отвечать, или на собеседование?!

  • Тоже примерно так думал, пока не стал сам собеседовать людей. Вы будете удивлены как много кандидатов не могут ответить на вопрос «Сколько будет 2 в 8-й степени?» Телефонное собеседование из подобных «быстрых» вопросов эффективно экономит время.
    • Двое из оракловых программеров, с которыми я с удовольствием работал в проектах, ответили на этот вопрос неправильно. Один сказал, что 1024, другой — 255(!). К счастью, никто не спросил этого на интервью.
      • Что ж, ваши оракловые программеры не подходят на вакансию программиста C++ :)
        • А теперь вопрос: где та же ошибка навредит программисту, пишущему на C++? Случай кретинов, которые пишут код и сразу после компиляции деплоят его в ядерный реактор рассматривать не будем. :)

          Учтем, что у нас есть хотя бы модульное тестирование. Буду признателен за пример.
          • Этот вопрос (и другие подобные) задаётся не для того, чтобы удостоверится, что человек знает сколько будет 2 в 8-й степени, а для того, чтобы быстро определить степень «осведомлённости» человека в той или иной области знаний из предмета собеседования. Конкретно этот вопрос относится к битовым операциям и размерам типов данных.
            Есть и другие вопросы. Некоторое количество ошибок (в том числе и на этот в общем-то простой вопрос), естественно, допустимо. Всё по-доброму :)
            • а если человек просто быстро умножает в десятичной системе? :)

              Я так понимаю, что кошерный кандидат должен сразу при цифре 8 представить в голове байт, и количество возможных значений каждого бита в двоичной системе?
              • Кошерный кандидат так много раз видел эти числа в своей работе, что особых вопросов типа «зачем они это спросили» скорее всего не возникнет.
                • Т.е. играет роль не подход к решению поставленного вопроса, а моментальность «подсознательного» ответа?

                  • А что вы тут собираетесь решать?! Если готового ответа нет, какие подходы Вы предлагаете — «принесите калькулятор, щас все будет»? Это просто один из простых вопросов, которые можно использовать для проверки кандидата на минимальную опытность. Если человек не пройдет первичный тест из серии таких вопросов, нет особых причин общаться по более серьезным задачам. Я не представляю себе, при каких условиях специалист, проработавший, скажем, два года, не сможет назвать сколько будет 2^8. Он что, два года хуи пиннал? На чем бы ты не программировал, за это время ты ни один раз вспомнишь об этом числе.
              • > а если человек просто быстро умножает в десятичной системе? :)

                Молодец, в таком случае.

                > Я так понимаю, что кошерный кандидат должен сразу при цифре 8 представить в голове байт, и количество возможных значений каждого бита в двоичной системе?

                Я вам гарантирую, что кандидат, который плотно программировал на C (или чём-то настолько же низкоуровневом) нечто большее чем лабы в университете, может неправильно ответить на этот вопрос исключительно по рассеянности или другой подобной причине чисто психологического характера (волнение и т. п.).
                • Само собой понятно, что число 256 называешь сразу автоматом — не думая. НО…
                  Вот нас в группе три человека: два программиста ассемблер+С и электронщик.
                  Электронщик тоже навскидку называл 256 автоматом, хотя программировать он не умеет вообще никак и ни на чем.
                  Просто если начинаешь задумываться «а почему 256?», то мы оба программиста вспомнили в первую очередь про десятичную математику (я — 16*8*2, он помнил что 2^10 это 1024 и два раза на два поделил) и только во вторую мы вспомнили про байт и т.д.
                  Мне интересно, говорит ли это о том, что мы ошиблись с выбором профессии или еще о чем-то?

                  P.S. Я просто увидев ваш комментарий, представил себя на месте человека которому задали вопрос про 2^8 степени, ну и немного меня смутило что байт пришел в голову именно во вторую очередь.
                  • Да ни о чём это не говорит, раз ответили. Этот вопрос же не ставится в центр вселенной. 15 минут телефонного собеседования из таких вопросов и плохой кандидат сразу отсеивается, а с хорошим идёт дальнейший разговор, вот и всё. На основании обладания знанием 2^8 никто никого сразу нанимать/не нанимать не собирается.
  • У меня есть давно испытанный способ найма программистов.
    С порога кандидату даются 6 задачек, совершенно несложных, которые надо решить за любое (разумное) время.
    У нормального претендента задачи вызывают плохо скрываемую улыбку и на них уходит минут 15 времени.
    У ненормального претендента эти же задачи вызывают напряжение и попытку объяснить, что «тут есть стопицот вариантов решения и надо точнее формулировать условия».
    Собственно говоря, решение этих задач определяет дальнейший ход разговора. Если они не решены, или решены неправильно, то и говорить особо не о чем. И время не потрачено, и усилий не приложено.
    А если все сделано более-менее верно, то тогда можно и прошлых заслугах разговаривать, и о жизненных интересах.

    Потому что часто на собеседование прорывается такое количество откровенного шлака с «прекрасными» резюме, что кофия на всех не напасешься.
    • Куда интереснее давать среди обычных задач такую, которая выглядит нормальной, но не имеет разумного решения, и смотреть что будет делать претендент.
    • если это кандидат на вакансию тестера, то определения нормального и не нормального кандидата следует поменять местами :)
  • >Идиотские вопросы, типа что такое стек, сколько бит в байте

    После того, как какой-нибудь кандидат будет утверждать что два, вы поймете, что вопрос все-таки не теряет актуальности :-)
    У меня на собеседовании такое было :-)
    Вопрос правда не напрямую задавался, а кандададат спросили почему он такой-то путь решения задачи предложил. Ну, он и говорит — что в этих восьми разрядах может быть только еденица или ноль, два положения :) Вопрос несколько раз переспросили… Кандидат стоял на своем :) Меня до сих пор терзает вопрос — что так могло кандидата сбить с понталыка?..
  • Как хорошо, что я никогда не проходил собеседований…
  • Как вариант можно предложить:

    1. бутыль шнапса
    2. вопрос: «Ты меня уважаешь?»

    А вообще топик клевый, чего уж там…
  • Если учитывать пожелания автора топика, то можно всё сократить:
    -Хай, я к вам на работу.
    -Хай, ок принят, через месяц выпнем.
  • если честно, несколько удивляют такие вопросы на собеседованиях… у меня вот привычка из головы выкидывать всё, что не нужно…

    на мой взгляд надо смотреть опыт и возможность найти и использовать нужную информацию… или ваши программисты должны сами все изобретать? не должны… значит, они должны либо вспоминать то, что уже использовали, либо быстро усваивать новый материал…

    программист это вообще не знание какого то языка, а знание возможностей его… при таком подходе программисту будет по барабану, на чем писать… за месяц что угодно усвоит. не на супер уровне, но…
  • Из моих похождений по собеседованиям — 90% работодателей хотят, что бы я знал, какие параметры надо передавать в стандартную функцию. например в fputcvs

    int fputcsv ( resource $handle, array $fields [, string $delimiter = ',' [, string $enclosure = '"' ]] )

    Какая разница, если человек знает что есть такая функция и это дело 3 секунд посмотреть в справочнике. Тем более редакторы подсказывать умеют :-)
    • Что, серьезно? По-моему, полный бред, я бы в таком случае усомнился в адекватности собеседников и постарлся по-быстрее закончить и уйти, нафиг работу с такими людьми.
      • Серьезнее не бывает. а еще делают недовольный вид, если им сказать, что есть функция для преобразования строки вида «2002.10.11 12:49:00» в unixtime :-)

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

        Написал за 40 минут. В итоге выяснилось что я не правильно задание понял.
        • Но ведь написал же код и работающий :)
          Но ведь не переспросил же «а правильно ли я понял?» :)
  • Я постоянно набираю на работу и собеседую людей. Вот кратко несколько мыслей.

    Некоторые критерии, которые я применяю на практике.

    1) Не стоит делать один шаблон под всех людей и все типы вакансии. Для вакансий старшего разработчика и помощника старшего разработчика стиль беседы и тесты могут очень сильно отличаться.

    2) Большинство критичных для найма на работу вещей можно узнать и до собеседования. А именно:

    — я прошу прислать пример кода. Можно небольшой кусочек. Очень часто по примеру присланного кода можно вообще не встречаться, т.к. присланное не соответствует озвученному в резюме. И наоборот — студент(редко) может прислать очень хороший код.

    — я прошу рассказать кратко о 2-3 крупных проектов. Статистически чудеса редко бывают. Если до 30 лет(в пик работы мозгов) разработчик не сделал ничего интересного, например, разрабатывая и суппортя пару мелких проектов для туристической компании, то вряд ли его амбиции и профессионализм будут полезны при серьезной разработке.

    — я прошу прислать информацию о рекомендациях от предыдущих работодателей. Если таких нет, то это весьма странно. Например, при 5-7 летнем опыте.

    3) Собеседование для меня это в первую очередь просто общение с человеком. На основные нужные мне скилзы и качества я уже его\ее проверил. На собеседовании я просто общаюсь с кандидатом, проверяя общий кругозор, комфортность общения. А также рассказываю кандидату про компанию и работу. Решение в первую очередь принимается о том, насколько комфортно будет работать с человеком и впишется ли он в команду.
  • А таки сколько бит в байте (имеется же ввиду char ?)? На какой архитектуре?
  • Один раз меня собеседовали по телефону. Просто бегло поспрашивали знаком ли я с понятиями некоторыми, спросили про назначение. Вот такое предварительное собеседование мне понравилось. На другом конце провода было 3-4 человека.
  • Есть такая фраза 'Past Performance Does Not Guarantee Future Results' и по моему сугубо личному мнению, на ворпос о прошлой работе тратить более 5 минут бесполезно. Во время интервъю надо выяснить принесет ли он пользу на новом месте (что знает, что умеет) и подходит ли он команде и компании.

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

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

    Вопросы про разработку архитектуры приложения, системы или сервиса спрашиваю только достаточно толковых/опытных. С остальными это как правило выброшенное время, да и с более слабыми кандидатами на это редко хватает отведенного на интервъю времени.
  • Говорите непростые и обидные вопросы могу обидеть и огорчить уязвимого и ранимого человека, которого собеседуют? А нафига нужен такой обидчивый и пальцезаламывающий сотрудник? Чтобы уже будуи работником всем утверждать, чтобы читали гугл/вики/блоги, а его время на простые мелочи не отвлекали? Это и есть культура, которую надо начинать с кружки чая/кофе/ВИНА?

    Собеседование — это проверка на прочность. Чем больше тебя «отдерут», тем лучше. Я вспоминаю свое собеседование на текущую работу. Это было самое сложное и приятное событие. Без всех этих что любите/умеете/хотите/мечтаете, а конкретно по делу — как работает/исправляется/делается.

    А домашняя работа для соискателя — это было бы, во-первых, интересно, во-вторых, проверяло бы, готов человек работать вне рабочего времени сперва на себя, а потом на работодателя. Не хотите такое делать? Ну так не приходите на собеседование и не делайте. Правила устанавливает тот, кто ищёт себе хорошего работника, а не наоборот. При этом не стоит потом друзьям говорить о «сволочах, которые моим неоплаченным трудом хотят заработать», к которым вы в итоге из гордости и глупости не пошли.
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.