Вопросы для собеседования разработчика, тимлида, PM
2 декабря 2008 в 20:26

Вопросы для собеседования разработчика, тимлида, PM

Пока писал пост в ответ на тему ( https://professionali.ru/Topic/149431 ), лента обновилась и стало понятно, что автор темы хочет нанять толкового ИТ-руководителя а не разработчика или тех лида. Но пост получился большой, выбрасывать жалко.

Надеюсь что кому-то пригодится. Выкладывается для всеобщего использования и работодателями и соискателями:)

Буду рад, если мы, обитатели профессионалов, вместе расширим этот список вопросов.
Приветствую дополнения и конструктивную критику.

Буду благодарен, если при копировании этого поста в ЖЖ, форумы, сайты, вы оставите ссылку на источник и авторство, спасибо.

Сага о том как мы проводим технические собеседования.
(в трех частях, с прологом и эпилогом)
;-)

Ниже преведены в основном вопросы для ОБЩЕТЕХНИЧЕСКОГО собеседования на должности программиста, тестировщика, тимлида, руководителя проекта.

Кроме этих вопросов, мы проверяем:

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

В начале собеседования обязательно минут 10 расскзываем о себе: чем мы занимаемся, куда движемся, что сделали, что умеем.
Обязательно просим человека рассказать о себе: что он сделал, что он умеет, что он хочет добиться, что ему интересно и важно (в профессиональной сфере, естественно).

Общее правило работы с резюме. Соискатель имеет шанс быть спрошенным по каждой позиции его скиллов, которая указана в резюме. Более того, мы можем спросить и по теме, которая не указана в его резюме:) Но все, что нам интересно, все что (как мы считаем) соискатель на требуемую позицию должен знать, мы спросим. Причем если сами не знаем о чем-то (например если мы нанимаем проектировщика процессоров), то мы просто попросим рассказать нам о его области деятельности. По реакции, горящим глазам, бойкости и внятности изложения понятно очень многое. Зачастую даже можно не задавать больше вопросов из этой сферы. Часто с первых фраз становится понятно, насколько человек разбирается в теме.

Мы не «валим» соискателя, мы просто определяем потенциал. Собеседование НАДО проводить в дружеской и открытой манере, отвечать на встречные вопросы, давать пояснения. Собеседование — это не монолог соискателя. Это диалог, где каждая из сторон пытается определить насколько ей симпатичен собеседник с профессиональной и психологической стороны.

(Следующий абзац — не мой, источник: http://lib.aldebaran.ru/author/paundstoun_uilyam/paundstoun_uilyam_kak_sdvinut_goru_fudzi/ )
К вопросам, задаваемым на интервью, предъявляются простые требования. Вопрос должен показать уровень знаний и опыта. Вопрос должен показать, как кандидат умеет решать неожиданные проблемы. Самое главное — ответ (а точнее говоря, размышления вслух в процессе решения) разных кандидатов можно сравнивать между собой. Нужно также оценить интерес к работе (работники, отбывающие повинность, не нужны) и желание добиваться результата. Коммуникабельность не на последнем месте. К кандидатам на «высокие» позиции предъявляются, естественно, и другие требование умение «разрулить» конфликт, быстро принимать жесткие (но правильные) решения даже неприятные, хорошее понимание того, почему нужно делать именно так, а не иначе, и т.д.
конец цитаты

Общее время первого собеседования порядка 1 часа. Для высоких позиций — больше. С нашей стороны обычно участвуют 3 человека (тех. лид, department или project manager, HR).
Задача тех.лида — оценить техническую внятность и подготовленность кандидата.
Задача PM — понять насколько хорошо человек впишется в команду, насколько он сможет в ней работать.
Задача HR — оценить общие качества — целеустремленность, искренность, сообразительность, усидчивость и т.д.

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

——————————————————
Итак, общепрограммистские вопросы:

Вопросы разбиты по группам, если надо, добавьте новые группы. Не задавайте вопросов из нерелевантных групп. (Например, можно не спрашивать тестера про С++). Обычно мы тратим на общетехнические вопросы минут 15 в режиме блица. Плюс минут 15 уходит на задачи и написание кода.

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

Список не претендует на оригинальность. Частично вопросы свои, частично тянутые из интерента.
Изначально в основе лежал список вопросов отсюда: http://blog.gamedeff.com/?p=64

Азбука

  • 2^8 (проебавших конкретно этот, обычно шлю лесом сразу).
  • 2^16, битовое представление.
  • −1, битовое представление.
  • Скалярное произведение.
  • Векторное произведение.
  • Как выделить 2 младших бита в int32?

Алгоритмы и структуры данных, CS

  • Tree супротив list, как структуры данных.
  • Что такое очередь и что такое стек? Приведте пример использования в реальной программерской жизни?
  • Hash как структура данных.
  • Производительность, что такое и про что O (N). Как оценить сложность алгоритма и когда в этом вознкает * практическая надобность?
  • N*log (N) в дереве, и почему оно так.
  • Какие алгоритмы сортировки на массиве вы знаете?
  • Как работает компилятор?
  • Какие типы языков Вы знаете? (императивные, декларативные, функциональные, логические). Расскажите о них вкратце.

CS, Высокая сложность:

  • Что такое NP-полная задача?
  • Что такое Генетические алгоритмы?
  • Что такое Fuzzy Logic?

Операционные системы и многопоточность

  • Что такое OS? Ее основное предназначение? (с точки зрения прикладного прогаммиста)
  • Что такое процесс, поток?
  • Что такое приоритет потока и как оперционна система выделяет потокам процессорне время.
  • Что происходит при переключении процессора между процессами?
  • Какие способы синхронизации потоков и процессов вы знаете?
  • Что такое dead-lock?

C++

  • Всё о наследовании за 3 минуты (зачем нужно, множественное, виртуальное, публичность).
  • Что такое pure virtual function (зачем надо). «Контракты» в качестве бонуса.
  • new супротив malloc в C++.
  • Чему равно i?
    int i = (1, 2, 3);
  • Конструкторы, деструкторы, порядок создания и удаления.
  • Виртуальные функции в конструкторах.
  • Шаблоны (зачем нужны, что такое специализация, что с производительностью).
  • Исключения (зачем нужны, производительность, особенности реализации).
  • new супротив new[] — зачем нужны, особенности реализации.
  • STL (зачем). Бонус за историческую справку. За 3 минуты о производительности основных типов.
  • Что такое итератор?
  • std::vector и эквиваленты. Зачем нужен. Производительность.
  • std::map и эквиваленты. Зачем нужен. Производительность.
  • Что такое умные указатели?
  • Что такое lazy evaluation и как его можно реализовать на С++. Зачем он нужен.
  • Vtbl, vptr, и прочие детали реализации. Бонус за множественное наследование. Бонус за виртуальное наследование.

.NET

  • Что такое CLR, CTS?
  • Что такое сборка?
  • Что такое домен приложения?
  • Что такое атрибуты, какие атрибуты вы применяли?
  • Режимы работы ADO.NET и как с ним работать.
  • Что такое событийное программирование.
  • Как асинхронно вызвать функцию в.NET?
  • и т.д.

PHP и Web, скиптовые языки

  • Чем PHP отличается от Java и C++ его сильные и слабые стороны.
  • Если работал в PHP4 и 5 — в чем отличее 5-го от 4-го?
  • Что такое динамическая/статическая типизация сильная/слабая типизация. Как это применимо к PHP?
  • Чем отличается модель работы Web приложения от модели работы обычного? Отсутствие сохраняемости сеансов, необходимость неоверия к даным, вводимым пользователем, большее количество конкуррентных запросовк системе, необходимость думать над масштабированием системы и так далее….
  • Чем отличаются POST и GET запросы?
  • Какие способы взлома web-приложения Вы знаете. как с ними бороться при разработке сайта?
  • Что такое cookies?
  • Как происходит обработка HTTP-запроса страницы на PHP?
  • Структура HTTP-запроса?

HTML, XHTML, DHTML, XML 

  • Что такое HTML, XHTML, DHTML.
  • Какие способы верстки веб-сайтов Вы знаете?
  • Что такое AJAX?
  • Какие сложности при разработке дизайеа сйтов вы считаете наиболее значимыми?
  • Какие способы индексации в CSS вы знаете?
  • Что такое валидный XML?
  • Что такое пространство имен XML?
  • Что такое, и для чего нужны XSLT, DTD, XML Schema, Xpointer …

Базы

  • Что такое реляционная БД?
  • Что такое первичный ключ таблицы?
  • Что такое внешний ключ? (foregin key) Для чего он нужен?
  • Как узнать сложность выполнения SQL запроса, при помощи самой СУБД?
  • Что такое вложенные подзапросы в SQL?
  • В чем различие между WHERE и HAVING в запросе SELECT?
  • Что такое 3-я нормальная форма базы. Бонус за другие нормальные формы.
  • Просим написать запрос с WHERE и JOIN на примере какой-нибудь таблицы (таблицу даем мы).

Системы и архитектура

  • Что такое схема MVC (model-view-controller)? Приведите примеры.
  • Что такое паттерны проектирования, приведите примеры.
  • Расскажите за 3 минуты про UML.
  • Что такое ORM-диаграммы, CRC-карточки?
  • Что такое связность системы? Как ей надо управлять при разработке ПО?
  • Что такое рефакторинг? Для чего он нужен?
  • Приведите основные признаки плохого кода.
  • Даем распечатанный пример кода (обозримого размера). Просим указать недостатки и предложить улучшения.
  • Что такое монолитные, 2х звенные, 3х звенные N-звенные системы?
  • За что отвечает каждый из слоев в 3-х звенной системе?
  • На что может разделяться слой бизнес-логики и слой UI в 3-х звенных системах? Когда это разделение оправдано?
  • Опишите, какими Вы видите архитектуру системы автоматического управления воздушным движением в аэропорту. (Тут проверяется что человек не боится сложных задач и может их эффективно раскладывать на составляющие и внятно рассуждать о архитектуре ПО).

Управление проектами

  • Что такое waterfall модель и итеративная модель разработки?
  • Опишите жизненный цикл проекта за 5 минут. (этапы разработки с постановки бизнес-задачи и до сдачи проекта)
  • Опишите кто должен входить в команду разработки ПО среднего размера. Как эти люди должны взаимодействовать? Зоны ответственности этих людей.
  • О каких методологиях разработки ПО вы слышали? Какие из них лучше применять в случае больших, маленьких проектах и в критичных, некритичных?
  • Что такое управление рисками? Назовите основные риски для типичного проекта в IT.
  • Что такое Agile — методики. Назовите несколько из них. Чем они отличаются друг от друга?
  • Вы — менеджер проекта. Вам дан карт-бланш. Как бы Вы организовали работу над проектов в условиях ограниченности людских ресурсов, бюджета и времени?
  • Плюсы и минусы территориально распределенных проектов? Как организовать управление в них?
  • Что делать, если проект проваливается? Тут придумывается на ходу ситуация с вымышленным проектом. Просим указать на причины провала и предложить план действий по проекту.

Тестирование

  • Назовите основные цели тестирования.
  • Какие различные типы, методологии. подходы вы знаете? Постарайтесь вкратце описать максимум за 3 минуты.
  • Что такое Юнит-тестирование, функционаьное тестирование, нагрузочное тестирование?
  • Расскажите как бы Вы тестировали диалог Save File в Notepad. (или в любом другом тестовом редакторе/приложении по выбору экзаменатора)
  • Расскажите как бы вы тестировали автомат для продажи кофе? Напишите test-cases.
  • Что такое integration tests?
  • Напишите функцию которая вычисляет простые числа от 1 до N. Напишите для нее test-cases.
  • Что такое black-box тестирование?
  • Что такое smoke-tests?
  • Как должна,по Вашему мнению, быть организована работа группы тестирования?

Задачи на разработку.
*Здесь я прошу придумать и описать алгоритм для какой нибудь хитрой задачки.
Тут не надо программировать, надо внятно описать основные идеи алгоритма.
Например:
описать как алгоритм для автоматической игры в тетрис.
предложить разработать алгоритм игры в шашки (крестики-нолики, кости, покер)
Как написать хорошего чат-бота?
Время на ответ 5 — 10 минут.
Если человек не смог решить задачу, не страшно. Главное чтобы у него были внятные идеи по решению. Если в процессе решения он «зависает» то мы подталкиваем его наводящими вопросами. Важно увидеть, насколько он легко их подхватывает.
Суперкруто, если он предложит лучшее решение чем известно нам:)

Написать код.
Если человек идет на должность девелопера, то иногда мы его просим написать функцию (класс, метод и т.д.) сортировки массива или дерева (например). Он может использовать любой из известных ему языков программирования. Задачка должна решаться в 5 минут (как нами, так и им:)) ) Если з 5 минут не справился -проверяем что сделал, спрашиваем что планировал дальше писать в этом коде и идем к следующим вопросам.

Задачи на сообразительность.
Иногда, если время и силы еще есть (то есть скиллов у человека немного, и опросили его быстро) а соискатель нам кажется перспективным, то мы задаем ему общие задачки на сообразительность. Список большой. Жедающие могут посмотреть подобные задачки в книге «Как сдвинуть гору фудзи.»

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

13834
Комментарии (13)
  • 3 декабря 2008 в 03:02 • #
    Игорь Цесельский

    А как будете PM оценивать?

  • 3 декабря 2008 в 19:43 • #
    Игорь Цесельский

    Так в заголовке темы)

  • 3 декабря 2008 в 08:05 • #
    Игорь Цесельский

    Интересны критерии оценки РМ. Если бы их осветили так же подробно, было бы отлично.

  • 3 декабря 2008 в 20:14 • #
    Михаил Дьяконов

    Я постараюсь :)
    Готового документа для собеседования PM у нас нет. Поэтому, как сформулирую в письменном виде свои разрозненные записки и мысли на эту тему то сразу выложу их в эту ветку.

    Обычно мы при собеседовании PM (технического PM) делаем больший упор на вопросы из групп управления проектами, тестирования. Добавляем вопросы по управлению требованиями, предлагаем за 10 минут разработать схему управления проектом и накидать календарный план для него.

    Средний размер команды в нашей компании достаточно маленький 5-15 человек. Так что PM должен быть хорошо подкован технически. По этому задаем ему и технические вопросы в количестве.

    А главное для PM - умение управлять людьми и двигать проект. В основном мы оцениваем эти качества интуитивно. Потом эта оценка проверяется практикой.

    Еще одна беда состоит в том, что в нашем городе на рынке труда очень мало толковых PM (в области софтверных проектов). Так что даже нужды создавать отдельный список вопросов для PM не было. Обычно на должность PM vs растим людей внутри компании. По этому на собеседовании мы не проверяем хороший ли PM к нам пришел, а стараемся ответить на вопрос: "Вырастет ли этот кандидат до тимлида или PM-а".

    Встречный вопрос Ирине и Игорю:
    А что бы вы предложили для собеседования PM?
    Кого вы понимаете под PM в своих компаниях?

  • 3 декабря 2008 в 19:34 • #
    Кирилл Васильев

    Большинство моих знакомых считают, что я много знаю, после ваших вопросов, у меня возник комплекс неполноценности. Я уверенно знаю ответы только процентов на 60. Правда по всем разделам.

  • 3 декабря 2008 в 20:00 • #
    Михаил Дьяконов

    Учиться, учиться и учиться :)

    Если серьезно - 60% неплохой результат. Это уровень программиста с опытом работы 3-4 года.

    Но обычно знания распределены неравномерною Где-то народ знает больше а где-то меньше. У тех кто пришел в программирование из смежных областей обычно низковаты знания по алгоритмам и основам IT. У ребят после профильного вуза обычно слабы знания в управлении проектами, тестировании, и системной архитектуре. Люди с опытом хорошо знают свою технологию(например Web + PHP + Java) но могут не знать смежные области (например С++).

    Для усугубления комплекса неполноценности рекомендую ознакомиться с матрицей компетентности программиста:
    Часть 1: http://docs.google.com/View?docid=d28gm4q_55n35dkht4
    Часть 2: http://docs.google.com/View?docid=d28gm4q_56hmv6f72z

    Дает хороший стимул к развитию :)

  • 3 декабря 2008 в 20:12 • #
    Кирилл Васильев

    Спасибо. Я в ИТ с 1989 года. Семь лет руководства проектами внедренческие и разработки. Конечно я изрядно отстал по C , лет пять туда не заглядывал и .NET там же.
    Ссылки посмотрю спасибо.

    Посмотрел, меня эта таблица сильно не удивила, в отличии от Ваших вопросов.

  • 3 декабря 2008 в 20:19 • #
    Михаил Дьяконов

    Да, тогда отличный результат :))

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

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

    Матрица компетентности программиста дает отличную перспективу.
    Уровень 1 - то что нужно уметь и знать в обязательном порядке.
    Уровень 2 - что должен специалист знать в своей области.
    Уровень 3 - что нужно знать чтобы быть великим ядерным программистом :)

  • 4 декабря 2008 в 01:26 • #
    Андрей Чистяков

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

  • 4 декабря 2008 в 02:26 • #
    Михаил Дьяконов

    Я не понял, почему не найдем?
    А как надо искать? Предложите способ.

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

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

    1) Такими вопросами мы определим границы знаний и умений программиста (по крайней мере в там, где мы пресекаемся по знаниям и умениям).
    2) Если человек не отвечает на наши вопросы, то это значит что
    - либо он гений и мы просто пыль под его ногами не способная спустить его мысль с горних высей.
    - либо он считает выше своего достоинства отвечать на 'дурацкие' вопросы.
    - либо он настолько застенчив, что не может общаться с незнакомыми людьми.
    - либо он просто не знает ответы.
    В любом из этих случаев этот человек нам, скорее всего, не подходит.
    Да, мы можем ошибиться. Но лучше упустить хорошего кандидата, чем взять на работу негодного. Негодный будет разлагать нам коллектив.
    3) Нам и нужны единомышленники. По крайней мере, на уровне команды. Если команда просто не может понять человека, не может с ним эффективно общаться, то , видимо, этот человек нам не подходит.
    4) Обычно умных и талантливых людей видно. Даже если он не может ответить на многие вопросы, мы ,при возможности, предложим ему другую должность.
    5) Если человек плавает в базе, не знает основ - Вон из профессии :)
    Мы не требуем чтобы человек был селен во всех сферах. Но спец по базам, должен знать базы. С девелопер - С и основы ОС. И все разработчики должны понимать как работает компьютер. Как пишутся алгоитмы. А не так, что знаю 1000 классов из библиотеки и все. Если подходящего класса не нашлось - задачане решается в принципе.

    Прогрммист должен любить думать!

  • 4 декабря 2008 в 13:27 • #
    Андрей Чистяков

    1) Нет, вы просто определите проекцию его знаний на свою плоскость мышления.

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

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

  • 9 декабря 2008 в 11:28 • #
    Николай Евгеньев

    Хм. так вот по списку вопросов я бы сделал вывод что основная задача -- подготовить базу для существенного понижения зарплатных ожиданий кандидата :) .. Понять есть у человека голова или нет и умеет ли он ей пользоваться можно существенно быстрее.. У нас на собеседовании человек пишет тест 1час.(2x10 вопросов) , после чего если результаты показывают что человек в адеквате, происходит собеседование 1 час. На котором как правило получается спросить 3-4 задачи (в той области в которой человек считает, что разбирается).

    К примеру, что такое дедлок говорят почти все, а задачу на его устранение, как правило не решают. Кандидатов с j2ee про двухфазный коммит спрашивать я уже и не пытаюсь :)

    fuzzy logic, genetic algorithms? ну знаю я их что? у вас часто встречаются задачи на оптимизацию? если нет зачем спрашивать? как-то повлияет на зарплату? т.е. задач нет, на на зарплату повлияет? :) не верю. А разобраться с ними может любой человек за 20 минут с книжкой при необходимости.

  • 9 декабря 2008 в 12:52 • #
    Михаил Дьяконов

    К сожалению, многие из тех кто называет себя разработчиком, не знают что такое дедлок, или что такое O(x), или чем INNER JOIN отличается от RIGHT JOIN. Часть приходящих кандидатов даже умудряется запутаться в объяснении что такое наследование. А о рефакторинге и о том чем плохой код отличается от хорошего имеют представление меньше половины.

    Я и не призываю всех знать что такое fuzzy logic. Если я собеседую человека на должность девелопера, то этот вопрос он получит только если мне покажется что знания в CS у него высоки.

    Я не задаю все вопросы из этого списка. Боже упаси! Всего задается 10-15 вопросов из тех тем где человек, как он заявляет, силен. После переходим к специальной части по технологиям. Просто, по моему опыту, случайная выборка этих вопросов (средняя сложность вопросов кореллирует с резюме и впечатлением о человеке) позволяет достаточно адекватно оценить его знания и то, насколько у него завышена/занижена оценка навыков в резюме.

    Бывает так что человек указывает Oracle (intermediate), хотя просто писал для него SQL запросы. Или не указывает знание J2EE только потому, что работал с ним меньше года.

    Не стоит рассматривать этот список как формальный тест!
    Это просто шпаргалка для проведения собеседования, не более того.


Выберите из списка
2018
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
1970