Найм инженеров-программистов, если точнее…
За свою карьеру программиста я помню ровно один раз, когда я успешно прошёл техническое собеседование, это было в 2002 году, через два года после моего выпуска. После этого все попытки делать это "правильно" неизменно проваливались, и меня в итоге брали на работу люди, которые меня уже знали или по совету других или по моим публичным свершениям. После того, как совсем недавно я не прошёл очередное собеседование, я естественным образом пришёл к заключению, что у нас в индустрии есть проблема: компании и люди не умеют нанимать инженеров.
Несмотря на то, что к своему заключению я пришёл естественно, я понимаю, что не для всех может быть очевидно, отчего это я так уверен, что проблема не во мне (видите, я умею смотреть на ситуацию критически). Что ж… Последние лет двенадцать я разрабатывал бизнес-софт под Windows, проектировал и реализовывал веб-сервисы, писал тьюториалы (до книг, правда, так и не дошло), делал доклады на международных конференциях, управлял проектами и выпускал их, руководил маленькими и не очень группами разработчиков, нанимал инженеров, преподавал курсы, вёл open-source проекты. И не только я один считаю, что многие из этих вещей получались в целом неплохо. Не стану и дальше утомлять вас самолюбованием, скажу только, что я давно перестал мерять свою квалификацию по результатам часового собеседования.
В любом случае, достойны внимания слова́, а не тот, кто их произносит. Вот вам моё мнение о том, что не так с наймом, и как это исправить.
Что не так
Кажется, сейчас уже в компаниях ушли от головоломок в стиле "как подвинуть Фудзи" и дают таки программистские задачи. Это хорошо! Однако эти задачи обычно или из базовой информатики или абстрактные задачи на теорию графов, теорию множеств и т.д. Неплохо, если кандидат умеет переворачивать связный список и может оценить алгоритмическую сложность своего решения. Но это не говорит ничего о тех навыках, которыми инженеры пользуются для собственно работы: понимание задач из реального мира, оценка компромиссов, нахождение и изоляция багов, оптимизация производительности, тестирование кода, подбор инструментов, чтение документации.
Есть ведь целый отдельный класс "задачек для собеседования". Таких, как всеми нежно любимая с полем из клеток 3×4 и маркером в левом нижнем углу, который умеет двигаться направо и вверх, и где надо посчитать количество разных маршрутов до правого верхнего угла. Или любая задачка про числа Фибоначчи, которые иногда маскируются под робота, шагающего по лестнице на одну или две ступеньки…
Судя по своим собственным ощущениям, я могу сказать, что мозги работают совершенно по-разному, когда я решаю такие задачи, чем когда работаю над чем-то практическим. Практические задачи обычно не ограничены искусственными условиями, призванными сделать их более заковыристыми, или набором инструментов, разрешённых для их решения. Также у них часто не бывает одного правильного ответа. И я лично знаю вполне состоявшегося программиста, который периодически практикуется в решении этих задач, чтобы "не терять полезный навык". Да что там, есть даже отдельные книги, посвящённые конкретно этой теме!
Неплохим с инженерной точки зрения решением задачи с полем 3×4 может быть захардкоженный ответ 10. А если её надо решать для поля произвольного размера, то ваше классическое тупое решение через рекурсию заткнётся довольно быстро, в зависимости от способностей вашего рантайма. И на этом моменте, чтобы иметь возможность предложить полезное решение, уже стоит начать интересоваться, какую, всё таки, конечную задачу мы решаем.
Один инженер из Google однажды поведал мне, что там считается, что существует корреляция между теми, кто хорошо умеет решать такие задачки, и теми, из кого потом могут получиться хорошие инженеры. Может, оно и так. Но оно совсем не учитывает инженеров, которых вы не наймёте, используя такой фильтр. Большинство компаний просто не могут позволить себе роскошь раскидываться талантами таким образом (сомневаюсь, на самом деле, что и Google может себе это позволить). Также этот подход не учитывает того, что нет в природе такого обобщённого понятия, как "инженер-программист". Разные вакансии требуют разного уровня квалификации и разной специализации. Нет смысла требовать от новичка понимания компромиссов между бизнес-требованиями и реализацией, так же, как нет смысла требовать от опытного ведущего разработчика умения не задумываясь написать из головы перевод инфиксной нотации в префиксную. То же справедливо и для разных областей: разработчики игр часто не слишком дружат с исключениями, а большинство JavaScript-программистов — с управлением памятью.
Меня однажды позвали на собеседование на Java-позицию, чтобы поспрашивать кандидата про Питон, так как тот обмолвился, что с Питоном знаком. Поговорив с ним немного, я узнал, что он ещё студент, интересуется ещё и Эрлангом, а также работает с ребятами из группы над веб-сайтом для кафедры. Я также задал несколько технических вопросов на темы, с которыми он, по идее, ещё не должен был быть знаком, просто чтобы грубо оценить уровень подготовки. Дальше я выдал ему задачку Пола Грэма про аккумулятор (промотайте до "Appendix: Power"), которая в Питоне решается нетривиально: нужно знать о некоторых неочевидных деталях реализации CPython.
Он не смог её решить сам, но после достаточного количества подсказок с моей стороны мы, в итоге, до решения добрались. Что интересно, это то, что мы с собеседователем из Java-команды пришли к совершенно обратным выводам. Он сказал: "Он ни на что сам не ответил, мы его не берём", на что я сказал: "Тогда дайте я возьму его к себе!"
Я, конечно, и не ожидал, что студент должен знать подобную бесполезную муть. На самом деле, я был практически убеждён, что парень грамотный, уже к тому моменту, когда он рассказал про тот веб-проект, который они делали с друзьями в свободное время. Чего ещё нужно-то от человек без какого-либо опыта, кроме страсти к программированию и базовых навыков для занятия им? Единственным, зачем я вообще дал ему ту задачку, было убедиться, что он умеет строить гипотезы, проверять их и анализировать результаты.
Я в итоге действительно нанял его к нам, и насколько я знаю, он до сих пор счастливо работает в Яндексе.
Кстати, дайте-ка ещё я раскрою ту штуку про "не задумываясь написать из головы"…
Типичное собеседование — это напряжённый разговор между кандидатом и одним или несколькими собеседующими. Напряжённый он потому, что кандидат по сути находится в стрессовой среде. Людям вообще обычно не нравится, когда их пристрастно оценивают, а для программистов это особенно болезненно, потому что большинство из нас к тому же интроверты. Но хуже всего то, что кандидат чувствует необходимость решать задачки как можно быстрее. Даже если времени больше, чем достаточно, он всё равно предполагает, что чем быстрее он справится, тем лучше будет выглядеть. Наличие такой предполагаемой "награды", как оказывается, самая большая помеха для когнитивной деятельности (вы, скорее всего, уже видели этот ролик, но посмотрите ещё раз).
Во время последнего собеседования у меня получилось выйти из ступора и придумать решение для довольно простой задачки практически сразу, как я вышел из комнаты на 5 минут в туалет. И это невозможно сымитировать.
И с обратной точки зрения, один довольно толковый кандидат как-то прислал мне два интересных варианта решения задачи, которую он никак не мог победить за полчаса до этого, когда сидел со мной в комнате. Всего-то и надо было — доехать до дома и расслабиться.
Как это делается
Основной посыл, который я попытаюсь здесь донести: спрашивать правильные вопросы — это только полдела, важно ещё и правильно интерпретировать ответы. Я даже возьму на себя смелость утверждать, что собеседующий больше ответственен за то, чтобы раскрыть способности кандидата, чем тот — за их демонстрацию. Помните, вы ведь не специалиста по продажам нанимаете, не ждите от гика, что он будет "зажигать".
Теперь — к сути.
Как говорит Джоэл Спольски с своём Guerrilla Guide to Interviewing, вы должны начать с представления компании и себя, а затем поспрашивать кандидата о его последнем проекте. И это всё правда, и работает ровно по тем причинам, которые Джоэл красноречиво изложил в статье. Также, хотя совсем устранить стресс собеседования не получится, таким образом его можно по крайней мере уменьшить.
Ваш собственно технический вопрос должен быть упрощённой задачей из реальной жизни. Он должен быть практическим по всем тем причинам, о которых я только что говорил, и он должен быть упрощён, потому что возня с мелкими деталями занимает слишком много времени, а ваше собеседование длится не неделю.
В качестве примера, вот одна из моих любимых задач:
- У вас есть текстовый лог IP-адресов с количеством байт, которое они скачали. Формат строчек простой —
xxx.xxx.xxx.xxx \t <number>.- Лог размером в несколько гигабайт, достаточно большой, чтобы не помещаться в память комфортно.
- Также у вас есть таблица диапазонов IP-адресов, выданных различным странам. Формат строчек —
<integer>-<integer> <country code>. Целыми числами представлены IP-адреса.- Размер таблицы порядка 100 000 строчек.
- Вам нужно вывести top-10 стран по количеству скачанного контента.
Задачка, хоть и простая, но в ней, как оказалось, достаточно тонких мест, которые могут рассказать вам о кандидате довольно много.
После того, как вы выдали задачку, уйдите из комнаты минут на 15. Нет, правда, не сидите у людей на голове, когда они пытаются думать. Пусть закроют глаза, погрызут ручку, походят туда-сюда или вокруг стола, засунут голову под стол или пусть читают описание задачи нараспев — всё, что умные люди могут делать, чтобы сосредоточиться.
Я знаю человека, который буквально пел строчки кода во время отладки. Похоже, это помогало, так почему бы и нет?
Ещё вы должны обязательно уточнить, что вы не ожидаете никакого готового решения к моменту, когда вернётесь. Скажите, что у задачи вообще нет какого-то правильного ответа, и вам больше интересен общий подход к решению. Помимо прочего, отсутствие требования иметь работающий код, даёт вам возможность писать его на чём угодно: на листах бумаги, на доске или на лаптопе. Пользуйтесь тем, что у вас есть.
Если кандидат таки решит задачу без особых проблем, то в этом нет ничего хорошего. Потому что это ни о чём не говорит. Возможно, он действительно очень умный, а возможно, ему просто повезло и решение "вдруг" пришло к нему в голову, или у него просто есть склонность решать задачи именно такого типа. Но дело в том, что основное занятие инженеров — решать проблемы, на которые они не знают готовых ответов. И ваша задача на собеседовании состоит в том, чтобы поставить их как раз в такое положение и наблюдать, как они из него выходят.
Во время этого процесса совершенно нормально вести дискуссию. Именно так и решаются реальные проблемы. В разговоре хорошо видно, как человек рассуждает. Делает ли он обоснованные заключения или перебирает варианты в надежде, что вы сами подскажете правильный? Зацикливается ли на незначительных деталях или умеет посмотреть на задачу целиком? Задаёт ли полезные вопросы? Может ли абстрагироваться от уже решённых частей задачи? Эта часть собеседования — самая продуктивная, она даёт вам наилучшее представление о специалисте.
Важно также помнить, что инженерные навыки не располагаются по линейной шкале, и вы не должны пытаться посчитать какую-то кумулятивную оценку, которая поместит кандидата слева или справа от воображаемой "точки найма". У людей разные склонности и разный опыт, и не нужно ждать, что у всех в голове один и тот же набор знаний, которые вам кажутся "базовыми" и "обязательными". Другими словами, не списывайте людей со счетов только потому, что они неверно оценили алгоритмическую сложность, не знают какой-то конкретный метод сортировки или не помнят задержку поиска данных на вращающемся диске в миллисекундах. Хотя, конечно, если человек не слышал вообще ни про одну из этих вещей, это уже подозрительно.
Ещё отдельное примечание про найм программистов с большим опытом на ведущие вакансии. Не доставайте их слишком усердно своими дурацкими задачками! Короткая задачка пойдёт в качестве разогрева, но больше всего информации вы получите, просто разговаривая об их собственном опыте. Просто, потому что у них его больше, чем "крутых скиллов" и знаний из учебника. В конце концов, именно этим они и ценны. Поэтому погружайтесь в детали их прошлых проектов, старайтесь с ними спорить, играйте роль адвоката дьявола, чтобы они объясняли вам, почему именно они принимали те или иные решения. Таким образом вы сможете увидеть, действительно ли они занимались чем-то конкретным или же просто числились в команде. А в лучшем случае вы можете узнать что-то полезное и сами :-).
Также смиритесь с тем, что вы будете время от времени нанимать и плохих специалистов. Такие вещи, как, например, способность сохранять продуктивность в течение долгого времени, просто невозможно оценить на собеседовании. Человек может быть толковым, но через пару месяцев окажется, что он невыносимый лентяй. С такими проблемами надо бороться другими методами, и это уже совсем отдельная история.
Кто должен этим заниматься
Этот вопрос, вообще-то, относится к разделу "что не так", но я решил оставить его на десерт, потому что он представляется самым спорным.
Я глубоко уверен, что оценка качеств других людей — суждение о людях, если хотите — это особый навык. Хороший инженер не обязательно будет хорошо собеседовать. И эта работа тоже творческая, поэтому её не получится формализовать по пунктам и просто дать всем инженерам их выучить. Если вы спросите человека, который умеет хорошо нанимать, как у него это получается, вы часто можете услышать что-то вроде: "Я просто разговариваю с человеком и вижу, хорош он или нет". И всё.
Так что, вместо того, чтобы заставлять каждого инженера из вашей команды проводить собеседования по очереди, как своего рода повинность (это я про вас, Google), постарайтесь заметить тех людей, у кого нанятые ими чаще оказываются хорошими работниками, и пусть только они этим и занимаются.
Ссылка
На этот пост меня вдохновила чудесная статья "How I hire writers" Хитеша Сарды. Особенно её предпоследний абзац.
Комментарии: 44
Яндекс как раз этим и грешит. Проходил собеседование буквально месяц назад, и то эмоциональное давление буквально вводло меня в ступор. Да и задачки которые задавали ребята только очень отдаленно касались той должности на которую я устраивался…
Огромные проблемы с рекрутингом в Google – факт, об этом все интернеты говорят последние лет 5 наверное. У средненького студента какого-нибудь Стенфорда намного больше шансов туда попасть через internship, чем у сложившегося специалиста по "стандартному пути". А если он ещё и отличник (в классическом понимании этого слова) так вобще – а потом именно они проводят собеседования со случайными кандидатами, естественно есть желание потешить своё ЧСВ за счёт теоретических (а также часто малорелевантных) знаний, т.к. других у них по сути нет и быть не может.
А ещё вас могут купить в гугл, как часть команды какого-нибудь приобретённого стартапа. Т.е. грубо говоря, чтобы попасть в Гугл, нужно либо вобще ничего не делать, а просто оказаться в нужном месте в нужное время, либо с точностью наоборот – после чего трижды подумаешь, куда я попал.
Опять же сам факт, что банально часто даже не отвечают на аппликейшон, отправленный через веб-форму, уже о многом говорит (или, например, отвечают через год, т.е. когда нужно будет им, а не вам, конечно же; хотя на текущем рынке, последние пять лет нужнее как раз именно им, но понимают это не все).
Печально другое – методику интервьюирования Гугла перенимают многие другие, т.к. почему-то считают, если так делает Гугл, то так и надо (ну а также потому что бывшие сотрудники продолжают нести Гугловскую "культуру" и в другие компании).
Вобщем непонятно что – пока они бегают за студентами из всяких стенфордов и прочих беркли, опытные специалисты, которые могут делать продукт, чуствуют что их окунули в дерьмо.
Но это так, мнение. Мне вот просто не ответили на моё резюме, но я так, средненький Java/Python инженер, всё вышесказанное – скорее на основе ресёрча и общения с очевидцами.
Этим везде грешат. В Яндексе нет какого-то стандарта на проведение собеседований, так что всё зависит от конкретного человека, который его проводит. В Яндексе я работал с одним руководителем, который любил в середине процесса водить кандидатов в буфет на кофе с печеньками :-).
Кстати, вот Google я бы не стал огульно клеймить. Их найм отличается от многих других тем же, чем и другие их задачи — масштабом. Я готов принять, что они также не могут себе позволить прогонять толпы кандидатов через "гуру-собеседователей", потому что последние просто не справятся. Я уверен, что в Google знают про эту проблему, на самом деле, лучше всех нас, но просто нормальной альтернативы пока ещё никто не нашёл. Я, вот, тоже не знаю ответа на вопрос "как нанять тысячу человек за один месяц".
Я готовлюсь к разговору с фейсбуком, куда скорее все равно не попаду, потому что алгоритмы честно прогуливал фриланся по ночам. Так вот судя по всей собранной информации там именно так, и в кафе сходить, и башни ханой переставить. Даже, вроде как, не совсем инженерных позиций :)
Ох как в тему! Сейчас как раз "развлекаюсь" хождением на собеседования, ни на одном пока практических вопросов не спросили. Зато абстрактной, безумной теории полным полно. Особенно забавно, когда, спрашивающие, сами толком знают о чем спрашивают. Задашь так встречный вопрос по теме, глядь, а собеседователь и поплыл...
Честный собеседователь на этом моменте заканчивает интервью с вердиктом "берём"!
Отличная статья.
Сам пару раз пробовал находить работу путем "собеседования с порога" но понял, что идиотизм социальной ситуации вместе с дискомфортом у людей по другую сторону вряд ли является началом для чего-то хорошего. В итоге почти все приглашения получал от людей, с которыми вместе доводилось решать какую-либо практическую задачу.
Уже в качестве рекрутера признал, что в людях разбираюсь очень плохо. Так что просто стал больше внимания уделять коду из реализованных проектов: понимает ли человек, то, что он сам написал, нет ли переоптимизации и прочих сложностей с дальшейшим изменениям кода, тяги к компактификации выражений и использованию экзотических структур языка. Какая связанность у кода, как организованы вложенные структуры, насколько быстро получается читать код и т.д.
Еще мне кажется важным видение "технологической карты": какие технологии по мнению собеседуемого будут развиваться более активно и почему, какие аспекты в создании ПО наиболее важны, как за это время изменятся технологии с которыми он работает и прочие общепрофессиональные суждения. Несовместимость этих карт может стать источником постоянных трений в команде, создавать ощущение, что проект движется не туда, складывать с себя ответственность за него или, наоборот, облегчать взаимодействие очень специфических людей.
Согласен с Ильей - "Talk is cheap. Show me the code." Но это подходит для уже состоявшихся программистов. А для junior - теоретические вопросы и проверка на способность рассуждать.
Написал небольшую заметку на тему.
Петр, я неудачно собеседовался в Facebook (хотя сейчас даже рад, что туда не попал). Собеседуют очень долго. Я прошёл около четырёх собеседований с нарастающей сложностью и уровнем стресса за три недели. Завалился уже на последних этапах. Хотя тут точно не знаю, завалился ли, потому как координатор всех этих собеседований просто ушёл в режим игнорирования.
Башни (или аналог) будут. На скорость. С кодом в браузере и пожеланием оптимального решения.
Ilya Kutukov, взяв идеального в техническом плане специалиста тоже можно обжечься. Он может быть не сильно ответственным как дело доходит до неинтересных задач, он может писать идеальный код, но делать это в три раза дольше, чем нужно. А может просто усложнять настолько, что остальные члены команды не смогут разобраться.
Сэм да про браузер тоже слышал. А язык С? Им надо чтобы прям без проверок компилировалось? :)
Тема довольно не простая, спасибо за заметку.
Тут уже несколько раз говорили про так называемое "чутье". Мол, чувствую что человек хорош, но почему не знаю. Я считаю, в таких моментах надо останавливаться и пытаться понять чем же он хорош, что в нем такого. Мы иногда хаем кандидатов за отсутствие "системного мышления" и четкой позиции по тому или иному вопросу, а сами полагаемся на "чутье". А ведь это и есть ни что иное как отсутствие четкого осознания положительных качеств кандидата, отсутствие четкой позиции по вопросу: почему этого кандидата надо взять. А этих положительных качеств помимо технических может быть много. Например, коммуникативность. Его способность адекватно общаться с другими членами команды. Способность воспринимать идеи заведомо противоречащие его точке зрения ("адвокат дьявола" хороший прием, да). Вобщем время одиночек прошло. И игнорировать коммуникативные способности кандидата на собеседовании тоже нельзя.
Спасибо за статью.
Это же отлично, что у гуло-фэйсбуков такая ситуация складывается с наемом сложившихся инженеров-программистов. Это означает, что их можете нанять вы :)
http://www.stratoplan.ru/free/hpm-books/
там есть небольшая брошура про собеседование. Больше про очеловечивание сего процесса, чем про инденеров, но тем не менее может быть полез для собеседователей.
А статья - хорошая. Спасибо
Петр, нет, почему же без проверок? Используется сервис Interview Street. Можно запускать. Есть unit-тесты, которые нужно пройти. Проблема чаще не в этом а в диком ограничении по времени и довольно сложных задачках. После решения обычно ещё 3—4 часа трясёт :)
Вот еще ссылка почти в тему: http://www.quora.com/Job-Interview-Questions/What-are-effective-ways-to-assess-if-someone-is-good-at-getting-things-done/answer/Yishan-Wong
@coffeesnake, странный у Вас опыт после общения с очевидцами. Я в Гугл устраивался около года назад, и мне никто не задавал малорелевантных вопросов. 90% задач были прикладные, либо просто говорили про разнообразные инженержные подходы к решению практических проблем связанных с перформансом, масштабируемостью, багами и т.п. Несмотря на то, что у меня бэкграунд состоит из околонулевого CS образования, слабой "академическая" подготовки и менее чем десятка лет опыта работы, собеседование я прошел, и ни в какую грязь меня никто не макал. В то же время устраивался ряд моих знакомых - опыт у них был разный, но скорее ближе к моему, чем к Вашему.
Отличная сказано.
Дать пару задачек для решения в спокойной обстановке, посмотреть как написан код, и многое станет ясно. Потом обсудить нюансы решения, почему так а не иначе, т.е. предметно поговорить. Сразу будет более менее видна логика принятия решений.
забавно, когда валят алгоритмами несколько циклов собеседований, а потом приходишь - и все тот же кодинг по "а клиент хочет вот такие фишечки на вчера"... математику можно оценивать, способность думать - нужно, а тупой зубреж никому еще мозги не заменял, к сожалению
Вань, Привет! Спасибо что поделился своими мыслями, тем более такими личными!
Кстати я задачку со ступенями в яндексе так и решил через фибоначчи, а там оказывается есть какой то умный алгоритм, который позволяет в 5 строчек решить :)
I also don't understand the purpose of asking one-timed questions about algorythms. It googles for 5 minutes. But talking about previous projects, wins and fails, problems and insights gives much more information about candidate
P.S. Picture made my day
Какая прекрасная задачка про логи; спасибо!
Да, по нынешним временам проблема рекрутинга распадается на три вида: - рекрутировать тех, кого видать на интернетах; - рекрутировать студентов; - рекрутировать тёмных лошадок, которых на интернетах не видать
С первыми понятно - никаких задач им давать не надо, а просто посмотреть, пошли ли бы вы с этими людьми в поход (нафиг разведку, это для военных).
С третьими наиболее тяжело - таких я бы пытал самого разного рода вопросами.
А студентов, как раз, можно интервьюировать и в гугловском стиле. Я, будучи в гугле, наинтервьюировал больше сотни человек. Нет, я не фанат гугла, но интервью там нормальное... ну в смысле лотерея - на кого попадёшь.
Я любил задавать, особенно во время телефонного скрининга, вопросы с отрицательными ответами. "Напишите регулярное выражение для проверки парности скобок в арифметическом выражении". Если кандидат начинает смеяться - можно не продолжать, наш человек. Если кандидат говорит - а фиг ли ж, в перле можно и в переменную счётчик складывать - тоже наш человек. Если же начинает искать варианты или гнать пургу - тоже можно не продолжать.
Спасибо за Ваш пост. Хороший.
Я бы выделил это как одну из главных идей поста - "Но дело в том, что основное занятие инженеров — решать проблемы, на которые они не знают готовых ответов."
Сэм, спасибо :) То есть можно пользоваться интернетами во время решения?
А вот я бы не стал списывать человека, который начнёт искать варианты. Любой вопрос когда-то встречается каждому из нас впервые, и это может быть как раз тот случай. Если человек покопается и потом скажет, что не видит решений, то я также не вижу проблемы явно попросить его подумать над тем, а существует ли оно вообще. У него ведь нет оснований догадаться самостоятельно, что регулярная грамматика этого не позволяет. Всё, что он знает к этому моменту, это то, что лично он не нашёл решения. Может, конечно, и озарение на него снизойти, но, опять таки, озарения — это не то, чем инженеры делают работу.
Вообще, в собеседованиях не должно быть "золотых вопросов", по которым 100% берём или не берём.
Иван, а как вы представляете хорошее решение про логи на питоне? Мне сходу кажется, что достаточно построчно прочесть файл, держа хэш страна-количество. А при считывании очередного адреса проверять его по хешу страна-диапазон, который по идее в память войдет.
Большие конторы подобные Google решают проблемы найма "простых инженеров" при помощи вендоров и контракторов. Для них всегда будет работа. Всегда есть проекты которые скучны "настоящим инженерам", но их тоже кто-то должен делать.
Да и уволить их проще, если очередная лихая година прийдёт ;)
Я не хотел её публично разбирать, потому что тогда её в таком виде невозможно спрашивать будет. А так, вдруг кому пригодится.
Петр, для подсказки: http://docs.python.org/library/bisect.html
Петр, да, но на это нет времени. За 15—45 минут нужно вникнуть в предметную область, формализовать её, решить задачу, закодить, добиться прохождения юнит-тестов и потом ещё и причесать.
Zart, для чего? Сортировать надо только хеш с результатами, что не сложно
Петр, ну тогда удачи строить хэш для стран.
причем сериалайзить этот хеш в json генератором =)
Отличная статья, универсальных решений конечно же нет. Лучше всего смотреть как человек работал, а если нет, то как у него с энтузиазмом.
Еще очень часто бывает, что человек является чистым практиком, без глубокого знания теоретических аббревиатур и прочего. Он просто умеет быстро и качественно решать поставленные задачи, пользуясь технической литературой, и, что немаловажно в наше время, применять уже готовые решения. При этом он может и не задумываться, что вот то, что он сейчас применил, называется полиморфизмом, а вот тут инкапсуляция, а тут оказывается, паттерн Заместитель(Proxy) ну и так далее. И неужели он будет хуже, чем такой же программист, но со знанием всей теории?
А в задаче про страны и айпишки вхождение айпи в cidr нужно было бы считать самостоятельно или предложение использовать iplib приветствовалось?
Приветствуется любое здравое решение, про которое человек может внятно рассказать, почему его использует. В этом и суть: у задачи не должно быть каких-то необоснованных искусственных ограничений.
Сам недавно собеседовался второй раз в яндекс, понял на себе фразу "на кого попадешь". Первое раз проходил собеседование года два назад. Собеседование шло 4 часа, тогда и опыта не было никакого, просто пришел с тем что было в голове: и по структурам данных в Java не мог толком сказать как устроен ArrayList, сортировки какие то знал, но их преимущества кроме скорости не знал. Человек который собеседовал, немного поговорил за текущую мою работы, что делаю, что нравится, что нет. Минут через 10-15 я уже в принципе не особо волновался. Пощупав мои технические навыки перешел к задачкам, по возрастающей сложности, первую решил на половину, вторую быстро решил, на третьей подвис, генерировал варианты, предлагал решения, но в итоге решения не нашел... В общем все закончилось оффером на junior java developer, но по личным причинам тогда пришлось отказаться, хотя впечатления остались крайне приятные. Кстати по пути домой, осенило второй половиной решения первой задачки.
Прошло два года, сменил работу, чтобы набираться опыта необходимого для яндекса. Решил попробовать еще раз на java developer. Первая секция из 4 при собеседовании была очень печальна. Все началось с общения на "ты" без моего согласия, и без формального знакомства. В смысле: "мы вот видим по резюме как вас зовут, а вот как нас зовут не очень важно", вводную для разгрузки напряжения тоже пропустили. Поехали: структуры данных и алгоритмы отвечал практически все вопросы на ура, так как серьезно изучал и копал. Кое-где были промахи, в тонкостях, пару раз это неприкрытый внезапный смех со стороны собеседующих, хотелось провалиться сковозь землю, потому что казалось сморозил ерунду. Как оказалось в одном месте не все правильно было понято, в других было не все так критично. В общем то в чем я лучше всего разбирался по своему мнению, оставило у меня крайне негативное впечатление. В итоге 3 следующих секции было в рамках хорошего диалога и собеседники оставили положительное впечатление и многими ответами я остался доволен, все равно ощущение было, что все уже провалено. Ну и не обманулся, оффера не последовало.
Кстати, интересный вопрос. Иван, как вы считаете, если на заданную задачку вы уже РЕШИЛИ на других собеседованиях, как лучше поступить: говорить что уже решалось или не говорить, а выдать ЧЕСТНО полученный ответ в предыдущих собеседованиях?
Я всегда честно говорил, что видел задачу. У меня уже давно нет цели во что бы то ни стало попасть на работу, поэтому в моих интересах облегчить интервьюёру задачу по поиску границ моей комфортной зоны. Ну и кроме того, обычно хорошо видно, когда человек знает ответ, поэтому, пытаясь это скрыть, скорее всего он просто будет выглядеть глупо.
I disagree with the blog post, with the opinions, and with the comments because although you have presented certain instructions, you are missing any higher-level theory, or model to describe the problem and identify its core entities. In addition to that, you are missing any data that could be used as an empirical evidence to support your (missing) theory.
Now the question I ask is how can you blindly give others instructions without understanding the problem?
Так в Гугле и нет хороших программистов. И в Микрософте нет, я верю Балмеру, он врать не будет. И в ИБМ нет. Они все по стартапам, потому их целиком покупают всю дорогу. Потом правда они уходят, и делают новый стартап. Потом выходят из возраста хороших программистов после 30-35 лет, а кто-то и раньше.
Уверен, что не смогу толком пройти ни одного собеседования, но за плечами успешная реализация более 10 крупных проектов, про всякую мелочь даже не говорю. Думаю что нашему мозгу свойственно просто забывать все ненужное и когдато нужное ... остается только опыт который можно представить как ориентацию в темном, неровном пространстве, где раскиданы например грабли :) Он(опыт) и позволяет выбрать наиболее подходящие инструменты для решения задачи.
I always fail interview tasks :) But last time I got an offer anyway.
Personally I used to think that interview tasks are not reasonable because there is no time to solve a complicated task (may be only by chance) and solving a simple one just has no sense.
But recently I've got several proofs that they are necessary. I've interviewed a couple of very good guys with a decent experience and nice personality, but they had dramatically failed basic technical assignments.
My current strategy is to not ask for a working code (and yes, leave people alone) but for algorithms and ideas. At least it brings some sense how they approach the problems and what do they know.