Pull to refresh

Comments 46

У меня, почему-то, при прочтении подобных текстов, возникает чувство, что соискатели это некие бедные крестьяне, которые пришли испросить милости у графа. Отношения работник — работодатель больше партнерские, я думаю.
UFO just landed and posted this here
Да, хоть это и немного цинично
C «винтиками» обычно интервью проще в разы, советы не нужны эти.
Не понимаю, почему у вас возникает такое чувство.

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

Просто мое личное мнение — если человек что-то умеет, ему нет нужды в подобных советах, не умеет — воспользоваться не сможет)
Вот вам 31 вопрос, который можно задать работодателю: megamozg.ru/post/13704
Когда проходил последнее собеседование — проверял, выяснил из этого списка все, что мне было важно.
Не стесняйтесь задавать вопросы, это же партнерские отношения.
2 часа — это какое-то халявное интервью.

У меня есть знакомые, которые много что умеют, но не проходят интервью. Я тоже что-то умею и я завалил много интервью.
И именно поэтому надо тренироваться и тренироваться. Ну и задачки ещё разминают мозги =)

Кстати, вопросы работодателю надо тоже задавать — он должен видеть, что вы тоже заинтересованы в работе у него, а не просто пришли «а вдруг больше заплатят».
Конечно, если на бодишоп работать — там заинтересованность показывать может и не надо, больше инертность (что вы сюда до пенсии)
UFO just landed and posted this here
Не совсем. Ищутся люди, которые будут полезны в компании на протяжении лет.
Если искать знания подходящие к текущему проекту (фреймворк и т.д.) — что потом с этим человеком делать по завершении проекта? Может быть тогда эти знания уже не нужны будут?

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

Чтоб определить это, задаются алгоритмические задачки. Благо, что времена «почему люки круглые» и «как выжить в миксере, если вас уменьшили» давно прошли.
А алгоритмические задачки полезны и могут пригодиться в любую минуту — всё базируется на них. Умение их решать подготавливает мозг и держит в тонусе. Откладывается алгоритм решения: посмотреть данные, проверить граничные условия…

Меня на телефонном интервью спросили как отсортировать массив из нолей и единиц — это был устный вопрос, без кода.
Можно решить вызвав стандартную библиотеку — O(n*log n) + расход по памяти, если вызовется сортировка слиянием.
Можно посчитать ноли и создать отсотрированный — два прохода.
Можно итерироваться с обеих сторон и перекидывать ноли в начало, единицы в хвост — один проход и никакой доп. памяти.
За 3 минуты видно, что человеку не чужда оптимизация и когда у него возникнет что-то подобное в проекте он подумает использовать ли стандартную библиотеку или написать свой метод. В Java хватает библиотек, которые дублируют стандартные и оптимизируют их, но которые не следует использовать везде.

Конечно, не на всяком проекте надо реализовывать что-то вычурное. Где-то достаточно получить данные и отобразить. Потом считать ввод и записать в БД. Но там быстро становится скучно. Но следующий проект будет интереснее и он может быть связан с чем угодно: видеопотоки, хранение данных, работа со внешними устройствами… мало ли чего.

В Амазон, Гугл, Фейсбук и пр… обычно не спрашивают язык программирования — можно писать на чём угодно (только надо на этом чём угодно правильно писать). Язык, а уж тем более фреймворки — это дело вторичное. Хороший инженер освоит язык довольно быстро. А команда может работать над каким-то веб-приложением на Java, а завтра для оптимизации надо будет написать/дописать сервис на C, чтоб всё летало, — своего сишника нет, искать долго.

Вот такое моё видение в интервьюировании в продуктовые компании. В сервисных компаниях (а-ля бодишоп) подход может быть другим. Им платят за человека, желательно, чтоб этот человек сидел на этом проекте долго, никуда не ушёл и не требовал повышения ЗП.
UFO just landed and posted this here
Нет, люков там не было.
Я не присутствовал там — не могу сказать. Я могу предположить почему я некоторые не прошёл. И то не всегда. Но всегда можно себя потешить, что они ищут на более низкую позицию, чем ты себя показал :D

Не могу понять как вы пришли к «люкам» в статье — у меня сложилось впечатление, что там только про алгоритмтческие задачки говорилось.
UFO just landed and posted this here
Самому пришло голову нечто подобное ) Это как можно учить годами Карнеги и подобных и не уметь общаться, а можно родиться(или быть воспитанным не знаю что точнее ) так что эти знания уже есть на подсознании с рождения и никакой Карнеги не нужен.
Если описанный здесь человек — он, то он может просто не уметь об этом рассказать. Статья о том, как показать то, кто есть вы, что вы умеете, и как именно вы делаете свою работу. Далеко не все могут это показать.
Из статьи не понял зачем мне нужно писать код на бумажке в 2015. А вообще большинство советов: как вам вести себя на собеседовании у НАС в компании. Имхо.
UFO just landed and posted this here
Кажой задаче свое средство
— нужно написать решение какой то неизвестной задачи? дайте нормально средство, например IDE где я смогу проверить разные варианты и сделать как надо
— вам нужен ход моих мыслей? мне не нужна бумага, я вам и так скажу
— вы ждете что я и так знаю решение(в случае с алгоритмами)? тогда варианта 2, я его знаю и я его не знаю, поэтому бумажка мне почти никогда не поможет

Я знаю что на собеседование часто есть лист бумаги для собеседуемого, но я не считаю правильным давать писать код на нем. Порисовать квадратики в процессе размышления — да, выделить основные мысли чтобы не мешались в голове — да, нарисовать граф или массив — да, так мы часто делаем на работе. Для остального могли бы и ноутбук с IDE дать.
UFO just landed and posted this here
По моему личному мнению, человек который может писать код на бумажке знает о языке гораздо больше того человека который знает только IDE. Точнее даже не знает, а скорее больше уверен в своих знаниях.
Плюс бывают ну очень редкие случаи когда код надо срочно поправить в vim(nano, Блокнот), например. И я поставлю на того кто смог написать минимум на бумажке и не возьму того кто начал требовать IDE. (Да я знаю что это плохо править код на живую и тд и тп, но все бывает в нашем несовершенном мире)

Согласен что писать там больше чем один класс, наверное бессмысленно. А вот например попросить тот же самый синглтон описать я думаю очень даже хорошая идея(предчувствую споры о его нужности. Это другой вопрос, но теорию знать надо).
Как понять знает только IDE? Для Java разработчика IDE это 30% сэкономленного времени. Вы наверно думаете что разработка это только знание конкретного языка программирования? Это не так, разработка это много много всего еще и знание IDE это не самый последний скил которым должен владеть разраб.
Но на собесах нас упорно заставляют писать код на бумажке, который даже нельзя оттестить, а ведь еще батюшка Фаулер писал что почти нереально сразу написать правильно работающий код.
В 2015 пора уже использовать какие то новые практики собеседований, перестать воспринимать соискателя как мышку над которой можно ставить эксперименты.
Ну вам врядли ставят задачу на 100 строк кода. И обычно эти задачи тестируются на доске легко.
Написать правильно работающий код уровня интервью на Амазон, Гугл и т.д. реально.

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

А вы как проводите интервью? Я пока что ничего не нашёл лучше чем collabedit для телефонного интервью и доски для очного. Да и многие другие компании тоже не нашли.

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

Если вы не можете писать код на бумажке — скорее всего вы не пройдёте интервью в компании типа Гугл, Амазон (думаю Яндекс в их числе). Я полностью понимаю, что может быть ваши цели могут быть совсем иными, но эти компании вы потеряли.
Я в таких случаях вежливо отказываюсь. Меня реально бесят такие задачи. Ход мыслей можно и словами объяснить, а кодить на бумажке это издевательство какое-то. Я пишу как курица лапой, мне действительно неудобно и неприятно писать от руки. Думаю я не один такой.

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

То же самое касательно кода на бумажке. Хотите посмотреть мой код? Пожалуйста его можно увидеть на моейм github профиле, с которым вы могли ознакомится перед собеседованием. Там прям по коммитам виден ход мыслей.

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

Плюс я перед интервью стараюсь даже в резюме не смотреть — чтоб «зачётка не работала на студента».

З.Ы. про приведение типов не спрашиваю, хотя это просто показывает знание языка.
UFO just landed and posted this here
Это мне даёт уверенность только в том, что его закоммитил этот человек.
Студенты курсовые чужие сдают, например.
UFO just landed and posted this here
Слишком дорого будет нанимать — интервьюерам надо ещё и работать.
А тут потратить время на изучение коммитов, найти интересные.
Потом как понять это он сам придумал или ему сказали сделать так.
Потом вникнуть в суть проекта и прикинуть как сам бы сделал + ещё пару альтернативных вариантов. Хотя это надо сделать ещё до интервью — чтоб иметь возможность обсудить разные варианты.
У меня на код ревью иногда уходит больше времени, чем человек писал изменения. И я этот проект знаю.

Ну и не у каждого отличного программиста есть что-то на гитхабе.
А если надо будет сравнить 2х кандидатов, а у них разные проекты?
Вы правда хотите такого собеседника?
Попробуем сделать это вот так — не уверен, что это сработает.

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

Перечитал два раза, но так и не понял, что тут говорится.
После минимальной правки:
«Потому что» может включать в себя исключение других вариантов (при одновременной демонстрации того, что они имеют бессмысленные последствия), или сравнение с другими языками / другими задачами.
У нас в компании в последнее время набирают новых сотрудников (уровня Junior, пост-универ в основном). И некоторых программистов просят поучавствовать в такого рода собеседованиях в качестве технических специалистов (собеседование ведет менеджер). Для себя отметил, что короткое задание с кодом на бумаге на 10 минут работы говорит мне о человеке больше, чем все аморфные высоко-теоретические вопросы заданные коллегами.
Можно узнать пример такого задания?

У сотрудника «пост-универ» и у сотрудника с опытом работы даже три-пять лет разные знания.
У сотрудника «пост-универ» и у сотрудника с опытом работы даже три-пять лет разные знания.

Не спорю

Можно узнать пример такого задания?

Задание имеет вид plain-code на двух А4 листах. три маленьких класса, две-функции не считая main(). Нужно найти ЛОГИЧЕСКИЕ (утечки памяти, краши, неверные обращения к памяти и так далее). Их порядка 30 (я очень старался :) ). Найти все ошибки не требуется.
Когда я даю такой тест я смотрю на: как человек читает чужой код, в зависимочти от найденных ошибок — смотрю на области знаний, как человек рассуждает.
Спасибо, это пример хорошего задания на мой взгляд.
Ну так вы же не заставляете человека самого писать код на бумажке. Это разные вещи. Читать код с бумаги или с экрана — не велика разница. А вот писать — совсем другое дело.
Как я указал раньше — мы искали сотрудников уровня «пост-универ». Такие соискатели редко пишут хороший код. У нас большой и старый проект, в котором «пишут» код очень ограниченное количество людей проработавшие 10+ лет над системой. Поэтому в случае моей компании на начальных этапах важнее читать и понимать код. Кроме того я сторонник мнения, что без умения читать чужой код научиться писать хорошо самому очень сложно (стремиться к «невозможно»)
Наши Сишники тоже начали использовать такой подход.

А в одной из компаний мне на собеседовании открыли класс в репозитории, показали 4 метода и спросили можно ли их как-то отрефакторить.

Было весело =) Кстати, весь рефакторинг потом проходил у доски. Комп был только чтоб код посмотреть.
Используйте «мы» вместо «я», например: «если бы мы breadth-first поиск, то получили бы ответ за O(n)»

Это серьёзно так и работает? Я, например, иду в последний год в обратном направлении — стараюсь использовать почаще «я», чтобы показать (в том числе и самому себе), что решение принимаю я, исходя из своих знаний и представлений, и вне зависимости от результата ответственность остаётся на мне. Не издеваюсь, просто интересно понять, как это воспринимают с той стороны баррикад.
Частое «я» означает противопоставление себя команде. «я сам принял решение» — другие будут с этим жить и вряд ли будут счастливы по этому поводу. «исходя из своих знаний и представлений» — самоуверенность, далеко не факт, что вы самый информированный. «ответственность на мне» — звучит как «если это писал не я то я за это не отвечаю».

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

Коротко о себе: живу в Сиэтле, работаю в компании Nordstrom, регулярно провожу как телефонные, так и очные собеседования (где-то 1.5 в неделю). Сам, разумеется, побывал во многих компаниях в качестве кандидата (5 завершились успешно)

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

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

После на словах или схематично опишите возможные решения. Сравните их быстродействие и затраты по памяти ( ru.wikipedia.org/wiki«O»_большое_и_«o»_малое ) и спросите какой из них реализовывать.

Познакомьтесь с стандартными структурами данных языка. И не только что оно делает, но и как они реализованы внутри.

И тренируйтесь писать код от руки на доске. Очень загадочно выглядят программисты с опытом работы на Java в лет 10, которые не знают put или add в этой коллекции надо использовать.
Так что желательно натренироваться так, чтоб ваш код от руки скомпилился и отработал правильно.

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

Есть хорошая книжка — Cracking the Coding Interview www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X
Всё это положительно впечатлит будущего коллегу. Ведь очень часто интервьюер — это ваш коллега/начальник и он ищет людей с которыми ему будет приятно, комфортно и интересно работать. Которым не надо будет постоянно указывать на огрехи и ошибки.
Sign up to leave a comment.