Интервью глазами интервьюируемого
June 12th, 2008 Posted in Бизнес
Летом 99 я проходил интервью на рабочую визу в американском посольстве в Москве. Средних лет женщина наряду с другими вопросами спросила меня и кое-что о программировании (а вдруг я террорист, который хочет въехать в страну под видом программиста).
- (глядя в бумажку) Что такое С++?
- «С++ это С с классами», бодро начал я и растекся мыслью по древу.
Через минуту-другую она сказала «достаточно» и выдала мне визу.
Это было первое и последнее интервью по программированию, которое мне удалось пройти. Было еще несколько неудачных, а потом меня взяли на работу по знакомству. Через какое-то время я перешел на темную сторону и начал нанимать сам.
Допустим вы устраиваетесь на работу. Чтобы бы вы хотели и не хотели услышать на интервью?
Что я не хотел бы услышать:
- вопросы, на которые я не знаю ответа
- вопросы по технологиям не указанным в моем резюме и в описании работы
- вопросы-головоломки, которым место на математической олимпиаде
- «справочные» вопросы, такие как имя или параметры определенной функции. На нахождение ответа требуется ровно 30 секунд, но держать такое в голове не имеет смысла.
Что я хотел бы услышать:
- вопросы, на которые я знаю ответ
- вопросы, которые позволяют показать мой опыт, знание технологий, предметной области или мои человеческие качества, такие как нацеленность на результат
- вопросы связанные с написанием какого-то алгоритма прямо на интервью или анализ предложенного куска кода.
А вы что хотели бы услышать на интервью?
------------------
В тему номера:
Макс Крайнов: Нужно ли финансово поощрять сотрудников? #3
"человек, приходящий к тебе за деньгами, покинет тебя за деньги".
17 Responses to “Интервью глазами интервьюируемого”
By Juda on Jun 13, 2008
вопросы связанные с написанием какого-то алгоритма наверно тоже стоит выкинуть, ибо смысл в написании алгоритма сортировки пузырьком отсутствует, а к примеру алгоритм TTH не сильно по времени для интервью подходит.
By Sans on Jun 13, 2008
согласен с Juda, вопросы по имплементации какого то алгоритма да ещё у на доске, как любят делать на некоторых интервью, это из области ителектуального онанизма IMHO.
Т.е. к этим вопросами можно подготовится, при том все они опубликованы в online, перелистать книжку/website по алгоритмам и структурам данным, чтобы потом так же легко выкинуть все это в мусорку после интервью.
Реально за всё то время которое я работаю в отрасли мне понадобилось имплементировать какой-то алгоритм самому может пару раз от силы. В большинстве же случаев есть уже готовые библиотеки. Пожалуй оговорюсь, что опять же это зависит насколько наукоёмкий продукт предстоит разрабатывать , бывают и исключения.
Я согласен что на интервью надо выяснить личные качества человека, технический кругозор, желательно что бы он был шире чем знание определенного языка или течнологии, читай здесь http://fritzmorgen.livejournal.com/117231.html про “Узких Специалистов”.
Надо конечно оценить что человек имеет основные знания об алгоритмах и структур данных, например, чем список отличается от массива или map-a, чтобы знать в каких случаях что лучше использовать и по каким названиям искать в библиотеках.
Вместо кодирования алгоритма на доске, я бы пожалуй задал бы реальную задачку, может парочку, на дом за недельку до интервью, чтобы в ней присутвовали возможность использования каких-то алгоритмов и pattern-ов.
И потом вместе с человеком просмотрел бы его код и оценил подход к решению. Можно на ходу поменять начальные условия задачки и оценить действия человека, чтобы исключить возможность списывания, оценить гибкость решения и ход мысли интервьюируемого.
Как говорится “my 2c”
By Victor Ronin on Jun 13, 2008
Насчет того, чего я не хотел бы услышать.
>вопросы, на которые я не знаю ответа
Я бы уточнил. Я не хотел бы услышать вопросы на которые я не знаю ответа, но исходя из своего опыта должен был бы знать.
100% согласен с нежелание услышать справочные вопросы.
Хотелось бы услышать вопрос:
“Когда вы можете приступить к работе?” и
“Согласен ли я начальную зарплату … ну скажем $1M”
By Sans on Jun 13, 2008
2 Виктор:
Хе-хе , ну если про $1М фантазировать
то тут вообше неограниченные возможности для стёба:)
“а как насчет того что бы не работать, а зарплату получать?” по моему просто отличный вопрос … что то мне, правда, никто его задавал пока
By Сергей Корнилов on Jun 13, 2008
2Victor:
да, “Когда вы можете приступить к работе?” – хорошее дополнение. Что же касается дольшой зарплаты – тут уже не наниматься нужно, а самому нанимать
By Сергей Корнилов on Jun 13, 2008
2Juda&Sans:
тут требуется пояснить о каком алгоритме речь и для чего это нужно.
Сам алгоритм роли не играет. Чем проще тем, тем лучше, чтобы человек мог сразу в уме прикинуть весь алгоритм и начать писать. Сортировка пузырьком это как раз тот самый случай, а можно може и еще проще, например FizzBuzz.
http://www.codinghorror.com/blog/archives/000781.html
Глядя на то, как человек пишет я могу оценить следующее:
- насколько быстро и уверенно он пишет.
- стиль программирования, форматирование кода
- имена, которые он дает переменным
Это говорит о его опыте применения конкретного языка. В конце концов я могу понять тот ли он, за кого себя выдает.
Для иллюстрации, что можете сказать о человеке, который написал вот такой код. Задача: вывести на экран двухмерный массив 10 на 10. Допустим все переменные определены заранее.
for(xRowIndex=0; xRowIndex<10;xRowIndex++)
{
for(yRowIndex=0, yRowIndex<10; yRowIndex++)
{
cout << arr[xRowIndex, yRowIndex] << ” “;
}
cout << “\n”;
}
By Sans on Jun 13, 2008
2 Сергей:
Когда я учился в университе на началных курсах, то был у нас предмет по алгоритмам, не помню уже сейчас название. Компьютеров всем не хватало а если и хватало то не часто.
Проходили кучу разных алгоритмов включая книжку Ершова, ну и естественно примеры писали все на C/C++ (реально С++ -ом тогда ещё и не пахло) чаше на бумажке.
Екзамен по предмету состоял из теоретической части и практического задания: написать один алгоритмов (обозначенный в вытянутом билете) на бумажке за ограниченное время. По молодости ето дело очень хорошо в голове оседало и в общем совершенно не проблема оказалось писать, я бы сказал, хрестоматийный код на бумажке.
Если бы по этому критерию мой будуший работодатель брал меня на мою первую работу, то он был бы неприятно удивлён позже, когда узнал бы что весь красивый код на доске ето просто результат тренировки памяти и логики, а не решения реальных задач.
Можно провести аналогию с ново-испеченным архитектором , у которого еше свежи знания сопромата, который может спроектировать мост или здание на бумаге, но ни разу еще ничего сам не построил.
Ещё я,например, встречал достаточно подкованных людей , которым нравится писать всё самим с нуля , memory allocators, custom thread pools, run-times, rendering engines, databases, но если это не является продуктом который ты собираешься продавать, то брать такого человека на работу – это большой вопрос, если ты хочешь получить продукт, а не завязнуть в разработках каких нибудь уникальных библиотек которые в перспективе могут делать всё, но когда не известно.
By stussy on Jun 14, 2008
милый пост
By Роман on Jun 15, 2008
Соглашусь с другими комментаторами, что давать пример реализации какого-то алгоритма глупо. Недавно работали у одного клиента с его ИТ отделом. Программисты там такие, что если им объяснить суть решения, они её реализуют без проблем и довольно быстро. А если придёшь к ним с вопросом как решить какую-то проблему – то это не работает. То есть народ думать не привык.
Так что Санс прав – надо давать реальную проблему для решения. Может быть не на недельку, а на час-другой. Все новые технические дела можно выучить и понять, а вот понять как человек подходит к проблемам – дело более полезное.
By Янка on Jun 15, 2008
А мне плакатик понравился! Я б порадовалась если б мое интервью начиналось так)) Сразу и опыт продемонстрируешьи смекалку. А то написать о себе можно все, что угодно, а вот реализовать…
Я терпеть не могу вопросы о себе. Почему-то сразу хочется отшутиться или нахамить. Что чаще одно и то же.
By Victor Ronin on Jun 15, 2008
2Роман & Sans:
Выбирая из двух людей:
а) Программист который умеет решать проблема (но применяет это черезчур часто)
б) Программист которому надо объяснять суть решения.
Я бы выбрал бы первого. Гораздо легче обучить, когда НЕ нужно выдумывать велосипед, чем научить, как выдумывать велосипед, когда это надо.
By Игорь Бойко | Блог о заголовках on Jun 17, 2008
Хотел бы услышать на интервью: “Вы нам подходите!”
By SatMan on Jun 18, 2008
Да на собеседовании можно наговорить много… к примеру заранее вспомнить теории и пр.. тебя примут, а потом на практике зависнешь. Думаю прохождение тестового задания есть правильное решение в подборе сотрудника.
By HRMan on Jun 18, 2008
2SatMan: Дык не всегда на интервью есть достаточно времени и возможностей, чтобы тесты проводить. А так с мыслью согласен.
By Андрей on Jul 10, 2008
Я достаточно часто беру на работу людей с небольшим опытом, так как много рутинной работы, а “кабаны” ее делать не хотят. Так как стараюсь отбирать лучших, то они достаточно быстро матереют и приходится искать новых юниоров. Так вот, 70 – 80 % студентов, которые хотят получить место с оплатой 800 – 1000 долларов валятся на задаче: “Напишите функцию вычисления факториала”. Даже когда я объясняю им что такое факториал.
Самое интересное, что до начала решения задачи, многие из них выглядят достаточно хорошо и убедительно.
By Juda on Jul 19, 2008
2Андрей
шокирован. что, это реальность такая, что не могут написать функцию вычисления факториала в лоб? (то, что я не шокирован, а ох… от того, что они не знают что такое факториал, это уже другая история
By Саша on Aug 25, 2008
Почему-то все неявно исходят из того, что вопрос про алгоритм единственный. Если так – нафик его. Но в 99% случаев это только один из многих вопросов и тогда он очень полезен.