0,2
рейтинг
21 августа 2013 в 10:14

Управление → Интервью как процесс с точки зрения собеседующего

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

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

Отработав в компании более 4х лет в нескольких смежных больших проектах я участвовал в собеседовании более чем 50 человек, из которых было нанято только 5.

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

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

Зачем?!


Среди первых всегда возникает вопрос — почему решили именно работать в нашей компании? Что вы о ней знаете, зачем и почему. Почему не Google, не Яndex или любая другая крупная компания. Дежурный вопрос помогает завязать разговор, но может и “выстрелить”: один кандидат, который вылил гору маркетинговых материалов, рассказал про вселенский заговор и свои желание его познать изнутри. Мы пожали ему руку и пожелали удачи.

Резюме.


Конечно же смотрим, но есть свои особенности — первое, что интересует, что оканчивал и окончил тот или иной вуз или нет — но не более, чем интересно. Где работал, как часто менял работу, почему. Какими темами и областями занимался. Вряд ли кандидату, занимающемуся data mining или web 2.0 будет интересно у вас, хотя … who knows?

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

J-фактор.


Типичный полупроводник в новую компанию — это рекрутер, с одной стороны он хочет найти специалиста, но с другой стороны, сам не являясь техническим специалистом не способен хорошо оценить реальный вес кандидата и поэтому ищет резюме с использованием buzz words. Ой-вей! Да это же Java! А вот у кандидата есть Log4J — должно быть что-то для Java. Поехали!

Для себя мы определили т.н. J-фактор, как количество технологий, упомянутые кандидатом, содержащие букву J, например: jsp, jdbc, j2se, ejb и т.д и т.п.

Как правило, чем больше J-фактор, тем разговор унылей. Есть поговорка The Jack of all trades, которую можно перевести как «Мастер на все руки», только у неё есть и продолжение — and master of nothing — перевод излишний. Словом, если человек уже зрелый инженер и он знает, что он сам хочет делать, в резюме это тоже явно отражается. И, разумеется, с такими и общаться приятнее, и берем мы их гораздо чаще.

Но не стоит воспринимать всё слишком буквально — в каждом правиле бывают свои приятные исключения: однажды человек с перегрузкой в 9J (это очень большое число) был не просто взят на работу, а в виде исключения смогли сделать так, что он может начать работать раньше, чем позволяет окно найма.

Реакция HR.


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

У меня зазвонил телефон.


Случаются ситуации, когда либо резюме человека не вызывает полный восторг, или человек живёт очень далеко — в таких случаях проводится небольшое телефонное интервью, скажем на 30 минут. Такого телефонного собеседования (или “пре-собеседования”), как правило более, чем достаточно, чтобы понять, стоит ли с человеком дальше общаться или нет. Если стоит — приглашение на очное интервью. И не важно откуда человек — из Москвы, Питера, Тамбова или Находки — компания оплачивает поездку кандидата, помогает с билетами и прочими вопросами.

Бывает и так, что пообщавшись по телефону мы даём человеку домашнее задание из разряда модельных задач или алгоритмов. Здесь можно увидеть очень многое — и любовь человека к той или иной платформе для сборки — ant, maven и т.п, любовь к unit test-ам, способность сделать дизайн / построить архитектуру, понимание работы классических алгоритмов и вкус оформления кода.

Ближе к телу.


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

Sprechen Sie Deutsch?


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

Ошибаетесь если думаете, что, например, для описания быстрой сортировки будет достаточно рассказать о нахождении опорной точки, разделении на два подмассива и рекурсивный вызов. Вопрос обладает большой глубиной — стоит пояснить деградацию быстрой сортировки до O(n2) и как один из способов решения проблемы — т.н. проблема национального голландского флага.

Standard Library and Design


Не беспокойтесь: всё, что вы знали и знаете о стандартной библиотеке будет спрошено: и какие бывают коллекции, и какие контракты использования. Рассуждая о плюсах или минусах того или иного подхода предлагаем кандидату спроектировать / задизайнить решение, если бы он мог делать, например, свой новый язык программирования. Если вы не слышали, что такое Gang of Four, вероятность, что будет трудно общаться, велика.

Ведь мы же любим спрашивать всякие красивые подходы, которые были применены в каком-то известном framework-е. Или например, почему Дональд Кнут настоятельно требует, чтобы поиск в hash структурах делался с использованием простых чисел, а инженеры Sun, а ныне Oracle, делают совсем по иному? Они не только читали Кнута, но и знают ещё кое-что.

Вообще о hashCode-е можно общаться очень долго: и откуда он берётся, и почему это не адрес, а если бы это был бы адрес, то что тогда — кому было хорошо, а кому плохо и как работает GC.

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

Coding.


Это всё слова! Хорошо бы посмотреть как человек кодит, и кодит на бумажке — этот принцип известен как white board coding. Конечно же, в жизни мы все кодим в той или иной IDE — будь то Eclipse или Idea, ОС Emacs или vi. Ведь все инструменты, которые есть у нас в распоряжении, они упрощают и ускоряют процесс, но не заменяют нас самих.

Типичный вброс на эту тему — написать функцию, возвращающую N-ый член ряда Фибоначчи. Как правило, в начале кандидат пишет рекурсивную реализацию. Хорошо. Уточняем области применимости и какие побочные эффекты возникают. Логическим продолжением служит итеративная формула. Мы не унимаемся — хотим ещё быстрее, лучше, красивее — вспомнит кандидат или нет — мы делаем вброс с точной формулой N-го члена ряда через золотое сечение. И опять же рано или поздно встаёт вопрос о границах применимости. Один кандидат буквально убил меня — он не помнил сколько бит выделяется под мантиссу в числе с плавающей точкой с двойной точностью — но как только он узнал через пару секунд резюмировал — где-то 15 значащих цифр умещается в double. Как? Он пояснил кратко и понятно, что очень немаловажно.

Беглость математического счёта и Brainteasers


Приятно, когда человек умеет бегло считать и очень печально, когда человек не может что-то простое оценить — будь то длительность вклада при известной начальной сумме и проценте, сетевую задержки между Токио и Лондона или просто корень из 42. C какой точностью? С какой легко справитесь на пальцах.

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

И здесь важна не беглость счета или умение решать головоломки как таковое — а то, насколько человек умеет свободно перемещаться между уровнями абстракций. Вот минуту назад он рассуждал о сложностях алгоритмов в терминах нотации Big-O, а сейчас должен оценить, когда закончится стек у рекурсивной процедуры — с конкретными числами — хороший инженер строит модели не в вакууме, а в реальном мире. Где гарантия того, что человек, который насчитает 100 бензозаправок в Москве, точно также ни капли не удивится, получив сетевую задержку в 500 мс между двумя дата-центрами в одном городе?

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

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

Chapter 17.


Отцы из [concurrency-interest] тонко намекают, что concurrency никто не знает, разве, что DL и все прочие толкуют сие писание как только могут. Удивительно, когда приходит человек, который заявляет, что он-таки знает concurrency и даже указывает список книг, которые он прочитал, среди которых не только Java Concurrency in Practice, а простой вопрос про wait/notify (из серии “как может нить выполнения захватить монитор, чтобы сделать notify(), если другая нитка, захватила монитор и ждёт в вызове wait()”) ставит его в тупик. Посложнее вопросы касаются устройства COWAL, CHM в её базовом виде jdk 1.6, причинно-следственные связи типа HB, почему нужно трогать volatile и т.п.

Но как бы то ни было.


Подводя итог интервью, хочется для себя понять — готов ли ты работать с таким человеком в одной команде, бок-о-бок на протяжении долгого времени, сможешь ли ты рассчитывать на то, что он будет способен заменять тебя на время отпусков, болезней, да и просто приятно поболтать за чашечкой утреннего кофе или вечерней пинты. По сути это выражается в некотором уровне комфорта работы с человеком — как много ему придётся объяснять, как много исправлять за ним (прямо или косвенно, через процесс ревью кода). Порой смышлёный и сообразительный junior вписывается в команду намного лучше, чем упёртый и несговорчивый senior с большим багажом знаний.

P.S.


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

Мотив более чем прост: на данный момент рынок качественных специалистов почти исчерпан. С другой стороны, много людей в IT среде, которые могли бы ими быть.

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

p.p.s Спасибо за помощь и содействии в написаннии данной статье cheremin, Александру Кусургашеву, Славе Царёву, и конечно же, 23derevo.
Владимир Долженко @vladimir_dolzhenko
карма
10,0
рейтинг 0,2
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

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

Комментарии (74)

  • +3
    А что за компания или чем вы занимались?
    Требования и вопросы сильные, и, хотя, вряд ли они были заданы джуниору-мидлу, но востребованы ли они родом деятельности?
    • +1
      Стоит отметить, что это не полный список вопросов, который задаём, и не факт, что будем задавать вообще что-то из какой-то темы.

      Задаём вопросы и junior-ам, и отвечают, и здесь больше хочется понять, как кандидат ведет себя тогда, когда попадает за границы области своей компетентности.

      Что касается востребованы — что-то непосредственно востребовано, что-то скорее модельное в виде сильно упращённого тем, чем занимались.
    • +2
      Могу предположить: Deutsche Bank.
      • +3
        Да, ЛинкедИн выдал человека с потрохами :)

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

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

          Я бы не сказал, что знания алгоритмов и прочей теории востребовано на 100% каждый день, но такие задачи возникают периодически — будет как-то неловко, когда надо решать какую-то проблему, а знаний и понимания нет. С другой стороны мы не спрашиваем педантично как именно, допустим работает j.u.HashMap как солится hashCode, скорее в общих чертах.
  • +12
    «Среди первых всегда возникает вопрос — почему решили именно работать в нашей компании?»
    потому что _Вы_ меня позвали? я никогда не понимал этот идиотский вопрос.
    • 0
      Я бы тоже понял вопрос, если бы это была компания уровня Гугла, Фейсбука, или любого другого гиганта в своей области.
      • +1
        Развивая эту тему — много ли вы можете перечислить компаний подобного уровня, которые имеют свои центры разработки в России? И удельная доля людей из сектора IT, которая работает там?
        • +1
          Я из Украины, но сразу в голову приходят Google, Яндекс, Mail.ru, Вконтакте.

          Я ни в коем случае не пытаюсь унизить компанию, в которой вы работали, но собеседование — это диалог, и ожидая различных вопросов на собеседовании, хотелось бы, чтобы компания имела аргументацию задавать такие вопросы, не считая желания выбрать кандидата посильнее для перекладывания данных из формочки в базу данных и обратно(да-да, именно этим я занимался большую часть своей карьеры разработчика).
      • +3
        Если вы ходите по собеседованиям просто потому что «позвали» — то это и есть ваш честный ответ на такой вопрос. Если же вам кажется, что это не тот ответ, который добавит вам плюсов в глазах собеседующих — возможно, это и так, а возможно и нет — все зависит от того, кого люди ищут.

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

        Нет ничего плохого в том, что вы ищете работу просто по критерию «где я буду продавать свое время за деньги». Но и больших плюсов в глазах работодателя в этом тоже нет (как правило). Действительно сложную работу невозможно делать хорошо только за зарплату — нужно, чтобы у человека была какая-то внутренняя мотивация эту работу делать. Поэтому на сложную задачу предпочтут взять пассионария, ясно понимающего зачем для самого себя он это хочет делать — нежели карьериста.
        • 0
          Логично. я знаю где я хочу специализироваться. Мне приходит отклик. Я смотрю вакансию. Написано то что мне интересно. Я иду. Но эта конкретная компания мне не известна. Попал так на свою нынешнюю работу. Оказался крутой интегратор, интересные проекты по тем направлениям что мне интересны. чяднт?
          • +1
            Если вы шли в эту компанию потому, что увидели направление А, Б и Жо в их вакансии, а вы ищете работу как раз с этими направлениями — разве это не является ответом на вопрос «почему именно к нам»? «Я ищу такие-то вещи, у вас они — по крайней мере в вакансии — есть, вот и пришел к вам сориентироваться на месте».

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

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

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

          Это я прежде всего по своему собственному опыту говорю — я считаю себя довольно неплохим problem solver-ом, но я несколько раз сталкивался с ситуацией, когда мозг просто отказывается даже начинать решать задачу «как починить этот адовый пи#$ец». Это происходит тогда, когда, по моей личной интуитивной оценке (которая, конечно, может не совпадать с оценкой руководства проекта) починка этой конкретной проблемы просто пустая трата времени, потому что ситуация в целом настолько поганая, что ложка меда только ухудшит общий вкус бочки дегтя.
    • +2
      Лично я — никак не проверяю.

      Мне кажется, если человек показал себя умеющим думать, но не может разобраться в незнакомом коде/среде/продукте — это вопрос мотивации а не способностей. Человек не хочет этим заниматься, вот и все. Вопросы мотивации — это вопросы project screening-а больше, хотя, конечно, мы на tech-screening стараемся примерно обрисовать кандидату возможные области работы.
  • +3
    1) Я, конечно, не ваш кандидат, но можно поподробнее про проблему голландского флага?
    Вроде бы у Дейкстры это «просто задачка», без философии глубинной проблемы быстрой сортировки.

    2) А почему вы настойчиво спрашиваете про справочные данные? И живой опыт.
    Справочные данные скорее знают джуниоры («свежебывшие» студенты), а живой опыт — сеньоры, почти что взаимоисключающие параграфы.
    Паркинсона почитали?
    • +1
      «Сколько будет 2*2? — Я что, все константы помнить обязан?»

      Что для вас «справочные данные», которые помнят только юниоры?
      • +6
        «т.н. проблема национального голландского флага.»
        «и какие бывают коллекции, и какие контракты использования»
        «поиск в hash структурах делался с использованием простых чисел,»
        «Gang of Four»

        Я всем эти интересовался только в студенчестве. А в бою было проще — почему не пользовать TTable, как тестировать, взаимоотношения блокировок, правила VISA, как заставить DAC работать в филиале на Win95, какие ошибки ввода пользователя к чему приводят в конкретных ситуациях, как структурировать поток заявок подрядчику, нахера нам X.25, и прочие критичные и некритичные знания, которые в универах не проходят, и универы вообще не знают. Зато очень ценилось умение быстро разобраться на практичном уровне. К слову, пятитомник правил VISA я и не читал «от корки до корки». Времени не было.

        И поток практики быстро и напрочь смывает универскую справочную инфу из головы.

        Остаётся только тщательно воспитанная универом вера в то, что справочники, солюшны и кейсы «где-то есть» и умение раздобыть и усвоить инфу в требуемые сроки.
        • +7
          Всё больше прихожу к выводу, что программирование / информатика разрозлись к нынешнему моменту настолько, что подобное собеседование может разве что выявить степень близости интеллектуальных путей собеседующего и собеседуемого. Ну и отсечь полных обалдуев, которые не знают, чем регистр отличается от реестра, а хэширование от кэширования.

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

          Причём планомерное развитие всё больше отдаляет от фундамента. Ну да, хорошо бы помнить, что быстрая сортировка может «провалиться» до O(N*N), а хэширование по умолчанию тоже не всегда годится. А чему нас учат книги «для продвинутых»? Не оптимизируй раньше времени! Сначала профилируй. Я вот не помню, когда в последний раз у меня бутылочным горышком оказалось хэширование или быстрая сортировка. Соответственно, и думать о них не приходится. Ну или мониторы в Java. Добрый день, с какой радости мне в 2013 году пользоваться мониторами из Java 1, если в Java 5 появились высокоуровневые средства работы с потоками, да и раньше сторонние библиотеки существовали.
          • 0
            Согласен, и злостных обалдуев тоже надо отсчечь, и всё же понять насколько фундамент прочен — я уже приводил аналогию про инженера-автомобилестроителя.

            И давайте про мониторы не будем, не о том статья — ведь на дворе 2013 год и ой как многое было сделано.
            • +4
              Согласен, но всё равно сложно. Вот взять ваш пример с сортировкой очень большого файла. Мне никогда не приходилось заниматься сортировкой такого файла, который не влезет в современную оперативную память.

              Соответственно, моих инженерных навыков и информации с подкорки студенческих времён хватит на то, чтобы сообразить:
              1) Нельзя просто взять и применить quicksort.
              2) Если нет серьёзных ограничений, проще взять готовую базу данных, сунуть свои данные туда и пусть сортирует как умеет.
              3) Если (2) не годится, надо почитать книжку Вирта «Алгоритмы и структуры данных», в которой такой пример разбирался. Но в чём конкретно был алгоритм — не помню. Что-то связанное с лентами.

              Может, вас такой ответ и устроит. А может, скажете, что фундамент слаб. Тоже не поймёшь, чем интервьюер удовлетворится :)
              • +2
                Побойтесь бога!

                Какие ещё базы данных. Зачем атомной бомбой гвозди-то забивать?
                • 0
                  0) Да, файл неимоверно большой 64Гб, оперативки 16Гб
                  1) Какие у quick sort есть ограничения? В чём его слабость, если мы говорим о его специфике применения к данной задач?

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

                  Если же домашнее задание… когда у человека есть и google, и wikipedia, и всё на свете — и он не может решить — я с вами согласен — он обалдуй и оболтус — и таких надо гнать.
                  • 0
                    А дополнительное место на диске есть (и сколько)? Или надо сортировать прямо по месту?
                    • 0
                      Кстати, спасибо за идею. То, что можно в этих условиях применить quicksort, двигаясь по файлу двумя окнами, я пока не осознавал — думал, что без многих файлов и слияния не обойтись.
                      • 0
                        А не утомиться ли дисковая система бегать туда-сюда в начало-конец файла перемещая элементы относительно опорной точки?
                        • 0
                          Прочитаю 6 ГБ с начала, и столько же с конца. Выберу из них какой-нибудь разделяющий элемент и начну тасовать элементы в памяти. Когда дойду до конца одного из этих буферов — скину его на диск и загружу следующие 6 ГБ — пока окна не сольются. Итого, на один проход уйдёт 11 чтений/записей буфера. Если на следующих этапах надо будет сортировать кусочек меньше 12 ГБ — сделаю это прямо в памяти. В общей сложности каждый фрагмент файла придётся прочитать/записать 4 раза (если не будет большого невезения) — не такая уж большая нагрузка.
                          • 0
                            Ok. И что это за сортировка?
                            • 0
                              Обычный quicksort. С ручной реализацией дополнительного уровня кэш-памяти (её роль играет RAM).
                              • 0
                                А теперь можете оценить его сложность? либо мне кажется, либо пахнет O(N2)
                                • +1
                                  Оно полностью эквивалентно quicksort, все элементы перемещаются, как если бы массив целиком находился в памяти. Так что действительно, в худшем случае O(N^2).
                                  Можно, конечно, считать файл кусочками по 13 ГБ, отсортировать, записать в 5 отдельных файлов, а потом сливать их. Но писать такое слияние, с буферизацией и на входе и на выходе — не самое приятное занятие. Объём общения с диском будет вдвое меньше, но потребуется дополнительное дисковое пространство.
                  • +2
                    Если задача разовая, я не постесняюсь сунуть всё в БД и получить на выходе результат.
                    Согласитесь, использовать Excel для большинства ежедневных задач вроде подсчёта суммы чисел в столбце — это тоже атомная бомба.

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

                    Как технарь я вообще иногда думаю, что задача отбора кандидатов — это по сути ранжирование, то есть отображение сложной суммы знаний и умений человека на одномерную координатную ось. И какой бы алгоритм не применялся, его всегда можно раскритиковать.
              • +2
                Почему это нельзя применить quicksort?

                mmap-им файл целиком, при помощи madvise говорим системе не кэшировать результаты чтения (MADV_RANDOM), и сортируем на здоровье. А дальше ядро само разберётся, что держать в памяти, а что не держать.
                • 0
                  Опять же — как при таком подходе будет себя вести дисковая подсистема. Данные никак не умеющатся в памяти — т.е они буду выгружаться на диcк. Т.о. будем бегать взад-вперёд по всему диску и убивать время именно на нахождение нужного куска.
                • 0
                  Я с удовольствием приму такой ответ, если кандидат сумеет объяснить, как примерно работает mmap, как будет ОС кэшировать содержимое файла, как согласуется страничная организация памяти со структурой обхода данных quicksort-ом, и сколько примерно «лишних» операций доступа к диску будет сделано.

                  И отдельный плюс если сумеет рассказать, как все это масштабируется до файла в 1Tb при наличии памяти в 1Gb.
                  • +4
                    Я готов обсудить этот вопрос с адекватным работодателем.

                    Адекватным — т.е. не тем, у которого этот вопрос — всего один из 50 вопросов собеседования. Иначе это не оценка профессионализма кандидата, а стресс-интервью.
                    .
                    С устраивающими стресс-интервью для программистов я не готов обсуждать даже погоду.
                  • +1
                    И отдельный плюс если сумеет рассказать, как все это масштабируется до файла в 1Tb при наличии памяти в 1Gb.

                    И что вы выберете в такой ситуации? Миллион раз читать по мегабайту (прямым доступом), или 20000 раз по полгигабайта? Или знаете более эффективное решение?
                    • 0
                      Ну вот в этом и состоит вопрос:
                      1. Понимает ли кандидат инструменты, которые использует — или для него они просто «магия»?
                      2. Сможет ли он понять, какой на самом деле у него получится алгоритм сортировки — если убрать условные границы абстракций? Что получится, если quicksort реализовать поверх страничной организации памяти?
                      3. Как следствие из 2 — как будет масштабироваться решение?

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

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

                      Если мы говорим о яве — там есть свои тонкости использования отображения файлов, и всяких новомодных технологий IO…

                      Вот так вот из одной-единственной «справочной» задачи можно кучу всего узнать про то, кто из себя кандидат как инженер.
                      • +2
                        А потом, послушав кандидата, сообщить ему, что в данной файловой системе скорость обращения к далёким секторам файла при прямом доступе линейно зависит от их смещения в файле. И посмотреть, как он будет выкручиваться…
                        • +2
                          Это одна из причин, по которой я предложил делегировать всю возню с памятью ядру.

                          Оно знает, в какой файловой системе оно лежит (привет, tar-подобные), и кэширует соответственно.

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


            geek-and-poke.com/geekandpoke/2013/7/13/foodprints
        • 0
          Во-первых, я не понимаю противопоставления «либо основы либо практика». Лично я считаю, что должны быть и твердые основы, и наличие обширной практики. Но если уж выбирать, то я категорически не согласен с тем, что наличие кучи практических знаний при давно забытом фундаменте предпочтительно — для меня все как раз наоборот, и тому есть масса причин.

          Во-первых, есть вопрос собеседования как такового. На нем предпочтительнее интересоваться фундаментом, потому что это такой общий знаменатель. Про VISA и X.25 человек может знать или не знать — это ровным счетом ничего не говорит о его способностях, а только лишь об истории его карьеры (я, например, совершенно не понимаю о чем вы :). А вот с основами человек не мог не сталкиваться за годы работы — и отсутствие знаний в этих областях действительно говорит о человеке — об отсутствии любопытства, например, отсутствии дотошности и желания разбираться в деталях.

          Кроме того, мне кажется очень показательным что вы называете этот фундамент «справочными данными» — т.е. чем-то статическим, что надо просто зазубрить. Для меня это вовсе не тупая информация для зазубривания, а кладезь идей, методов решения задач. «Математику уж затем учить следует, что она ум в порядок приводит» — вот примерно то же самое я могу сказать про те «справочные данные» о которых мы спрашиваем: они формируют определенный — инженерный --способ мышления. Дело ведь не в том, знает ли человек уже готовые ответы — дело в том, сможет ли он решить указываемые проблемы. Если он сможет генерировать сильные идеи сам, прямо из воздуха — отлично, может, ему и правда не нужно учить основы раз уж он такой гений. Только такие гении совсем не часто встречаются.

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

            Я, признаюсь, Дейкстру не читал. Нам по верхам классические алгоритмы дискретный математик прочёл — и этого мне стало достаточно, чтобы знать «алгоритмы изобретать не надо. Есть монстры до меня, которые уже вложили в них кучу математики. Главное — знать на каких полках библиотеки они находятся». Да и то, всё равно дважды накололся, изобретая самостоятельно «подсчёт площади участков диаграммы Вороного» и «интеграл по контуру для вычисления принадлежности точки полигону». Что послужило дополнительным сигналом, что гуглить надо тсчательнее, а вести себя внимательнее и скромнее.
            • 0
              ваша названная позиция оказалась мягче… нежели она поставлена в статье

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

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

              алгоритмы изобретать не надо

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

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

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

      Модельная задача? Модельная, хорошо изученная? Да.

      Что пишут кандидаты? Пишут и quick sort поверх огромного файла, кто-то выдаёт спагетти, а не код.

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

      Так, что прежде всего это уровень образования и остаточные данные.

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

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

      Чем инженер-программист сильно отличается от другого инженера?
      • 0
        Приведу в пример. Я знаю, как устроен ДВС «в общих чертах». Равно как и в общих чертах все авиадвигатели: турбореактивный, турбовинтовой, прямоточный, двухконтурный, турбовентиляторный, турбовальный, твердотопливный ракетный, ракетный на жидком топливе на давлении, на насосе, и, по случаю, даже импеллерный. Чем фенестрон лучше или хуже. Зачем нужен компрессор, чем он отличается от турбокомпрессора, для чего интеркулер и что делает закись азота или водометанола в цилиндрах. В курсе, что кроме цикла Карно для любых названных двигателей есть свои термодинамические циклы. Какой от этого толк на вакансию?

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

        Но, всё-таки, не проще ли как-то побыстрее вывести уровень диалога с собеседником на его потолок компетенции? Не более одного-двух вопросов на каждый уровень, и, выяснив точный уровень разойтись уже вширь. Выяснение уровня можете организовать дихотомией. Она логарифмической сложности.
        • 0
          Поясните — зачем в ширь?

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

          Или взять ещё шире — web? Но у нас его тоже почти нет.

          Мы определили для себя широту используемых у нас знаний для кандидата — как хороший уровень java core — т.к. это у нас используется. Смысл спрашивать его узкоспециализированные вещи из нашей области, или какие-то хитрые продукты, которые мы используем — тоже не вижу смыла.

          Так, что мы в общем-то и так стараемся пройти по тем темам, которые нам интересны.
          • +2
            Затем, что вы своём повествовании не прояснили профиль и технологии тех проектов, но заглавие выбрали универсальное (для среднестатистической по больнице программистской фирме во всём многообразии фирм и проектов).

            Если бы вы назвали статью «создаём на java realtime mmo rpg с использованием готовой графлибы и сетевой либы, БД используем NOSQL-имярёк, в ядре игры приходится применять классические алгоритмы для обеспечения игровой механики и т.д. и т.п., и как мы на эту специфику нанимаем людей» — вот тогда я бы и не заикался.
        • 0
          Уровень наверняка будет неровным, и его придётся выяснять в каждой точке. За очередной логарифм…
          • 0
            Верно. За K*log(Nk), где K — количество техник и принципов, набранных в этом данном проекте. Кому-то STL, кому-то Spring, кому-то EE; кому-то потребуется хорошо знать DDL и проектирование хранилищ, а кому-то планировать DML, и не знать DDL, причём знать исключительно в специфике мускула или сайбейса. Другие пользуют Qt, третьи Unty3D, а есть даже апологеты wxWidgets.

            Сейчас любое рыночное решение в 60% случаев сборная солянка личных предпочтений древних архитекторов данной конкретной программерской конторы, и почивших на момент.
            (40% конфигурируют или просто поддерживают чужое интегрированное решение, типа сиськи, оракула, маздая, 1С, R/3 и иже. Там совсем другие критерии профпригодности, и там не спросят про «О большое», «задачу коммивояжёра» и «генерацию лексикографически упорядоченного списка счастливых билетов только с помощью операции перестановки». Да и за «три проблемы вычислимости» там никто не в курсе, очень подозреваю)

            K уменьшить нельзя, согласен. Именно поэтому.
  • 0
    (не в ту реплику)
  • 0
    Как у него получилось «15 десятичных цифр»?
    • 0
      ему сказали, что мантиса в double занимается 53 бита (52 бита явно, и 1 неявно) — вот именно посли этих данных он за 2 секунды и резюмировал.
      Его пояснение:
      253 почти того же порядка, что и 250 = (210)5 = 10245 т.к. 1024 это 3 => 250 ~15 знаков
  • +7
    image

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

    Проверка знания Gang of Four при приеме на работу в IT-отдел Дойче Банка?
    Кто тут говорил о неправильном распределении ресурсов АКА стрельба из пушки по воробьям?

    Не, все понятно. Тщательный отсев кандидатур, всегда приятней работать с профессионалами — это все ясно. Но мне кажется, крайности всегда неуместны, а метод золотого сечения, можно применять не только в поиске N-ного члена ряда Фибоначчи, но и в поиске специалиста подходящего конкретному рабочему месту.
    • 0
      Это ваше личное право, но вы серьёзно заблуждаетесь про момент власти — мы люди взрослые и нам люди нужны, с которыми мы хотим работать. Хотя это российская компания (юридически по другому не может быть), но фактически менталитет не российский, поэтому на кандидата изначально смотрим как на сильного и себе равного.

      Проверка знания GoF? Вы о чём? Явно же сказано:
      Если вы не слышали, что такое Gang of Four, вероятность, что будет трудно общаться, велика.

      Я не считаю, что вопрос рода Чем отличается Adapter от Wrapper может что-то сказать, как впрочем и то, что его вообще следует задавать.

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

      Общий посыл был примерно такой: что-то не знает — не беда, если знает другое или что-то не знал, но сообразил, смог подумав найти ответ, даже если ему дали подсказку и навели.

    • 0
      т.е. временно зависящем от прихоти вашего настроения человеком.


      А в чем именно человек зависит от моей прихоти? Собеседования, вроде, дело добровольное, с пистолетом у виска никто не стоит. Что-то не нравится — скажи. Кажется, что тебя спрашивают не о том, что ты считаешь своей сильной стороной — скажи. Кардинально не нравятся люди и атмосфера — скажи и уходи.

      Мне кажется, что вы просто перекладываете ответственность за свой комфорт на других людей. Собеседование — это обоюдный процесс. Да, есть определенные традиции — не принято, например, чтобы кандидат спрашивал собеседующих знают ли они quicksort :) — но смысл их именно в том, что компания-то покупает его навыки, поэтому имеет право товар посмотреть. А кандидат навыки продает — поэтому должен их показать, а покупает зарплату/соцпакет/возможность самореализации/общую атмосферу/т.п. — и про это он имеет полное право спрашивать, а мы стараемся отвечать.

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

      Знаете почему, кстати? Потому что у нас, программистов, власти и так хватает :)
  • +2
    Готовьтесь к собеседованиям. Не день, и не неделю. Работайте, решайте модельные задачи — на это может уйти и не один месяц, и инвестиции окупятся достойным местом работы.


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

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

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

    А разве он не прав? Может быть, что-то лучше есть, но найти это что-то действительно тяжело…
  • +2
    Пример вопросов в Deutche Bank на позицию .Net разработчика

    .NET/C#:
    Common language features (value types, exception handling, events)
    Nullable implementation
    GetHashCode() and Dictionary
    .NET memory model and garbage collection

    Multithreading:
    Synchronization primitives: locks, pulse/wait, mutex etc. Why is a bad practice to lock(this)
    What is the techniques to avoid deadlocks.

    GUI
    WPF, styles/templates, Dispatcher, Invoke/BeginInvoke.

    Design patterns (Singleton + implementation, decorator, explanation of MVVM and MVC/MVP)

    Задач на логику может и не быть.

    По ощущениям ищут идеального прораммиста, который пишет идеальный код. Если вы достигли уровня team lead или architect, то работать наверное вам будет не очень интересно, только если из-за денег.
    • +1
      > Если вы достигли уровня team lead или architect, то работать наверное вам будет не очень интересно, только если из-за денег.

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

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

        Да, и кроме того, ни я, ни месье Черёмин не являются team leader'ом — и уж точно не стоит цели измываться над кем-то. Я на все 200% согласен с Русланом, что очень неловко становится, когда приходит кандидат и говорит, что поиск в hash структуре имеет сложность O(log N) и предлагает вариант дерева. Мы же не священная инквизиция, чтобы засовывать под ногти горячие гвозди и спрашивать его о чём там писал старина Кнут? Побойтесь бога, милейший. Мы гуманные люди, мы стараемся понять, что человек в самом деле такой, или он просто случайно перепутул что-то от волнения.

        Как-то через чуз преувеличены слухи о «идеальном» программисте…
  • +1
    Ваше интервью можно сократить раз в 10 по времени — спрашивать только про Concurrency. Если человек не знает элементарных вещей вроде wait, notify и synchronized — прекращаете разговор. И всё :)
    • 0
      Именно на этот случай и делается телефонное интервью — оценить насколько не безнадёжен кандидат.
      • +1
        Нет, я говорю про основное интервью. Нет смысла спрашивать про Фибоначчи и сортировки. Просто спрашиваете про Concurrency. Либо человек знает, либо не знает. Такое техническое собеседование занимает всего 10-20 минут.
        • 0
          Провели телефонное — поняли, что вроде знает коллекции, wait/notify/HB и прочее по мелочёвке. На основном можно уже спрашивать о том как работает COWAL, CHM.

          Однако, если это junior то никто не требует, чтобы он знал Concurrency, а тем более хорошо. Этому вполне можно и научить(ся) за время работы у нас под чутким руководством.

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

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