Статья :
Искусство интервью

Автор(ы): Джоэль Спольски (Joel Spolsky)

Авторы :
Joel Spolsky

Аннотация :
Нанимать нужных людей крайне критично. Для нашей фирмы чрезвычайно важен поиск толковых сотрудников. В нашей отрасли работают три типа людей. На одном конце шкалы находится серая масса, не обладающая даже базовыми навыками этой работы. Их просто распознать и отсеять, часто для этого достаточно просмотреть резюме и задать пару простых вопросов. На другом же полюсе находятся суперзвезды, пишущие для забавы по выходным компиляторы Lisp для Palm Pilot на ассемблере. А между этими крайними случаями находится большое количество "maybes", которые, возможно, что-то могут. Сложность в отделении суперзвезд от maybes, поскольку нанимаем только суперзвезд. Вот какая техника используется для этого...

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

>На другом же полюсе находятся суперзвезды, пишущие для забавы по выходным компиляторы Lisp для Palm Pilot на ассемблере.>

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

1: Lisp-у компилятор нужен как пятая нога потому что специфика этого языка делает бессмысленной компиляцию (в традиционном понимании) написанных на нем программ.

2: Написать Lisp-машину совсем не сложно и быть "звездой" для этого не обязательно.

3: Писать на ассемблере при наличии современных оптимизирующих компиляторов это изврат, хотя Lisp-машина на ассемблер ложится очень хорошо. В конце концов сам Lisp это списочный ассемблер Lisp-машины.

Я знаю реальную компанию, в которой используется именно эта методика приема на работу. Причем вопросы типа: "Сколько настройщиков роялей в Москве" могут задать как в ходе самого первого письменного тестирования, так и на последнем — у президента! Задачки типа перевернуть строку на месте и реализовать стандартную f() тоже весьма в ходу. Я лично через это прошел не далее как пару месяцев тому назад.

По-моему статья неплохая. Но — увы! — она слишком малоприменима к российским реалиям. Если бы все наши работодатели ТАК проводили интервью... Разумеется, не надо слепо копировать методику, но есть над чем задуматься ;)

Когда буду руководителем — воспользуюсь ;)

С уважением,
Сергей

Что бы там ни говорили, статья конечно хороша (нужно уметь делать выводы;). Но я вобщем не совсем об этом. Я не буду с кем то спорить и кого-то убеждать. Я касательно функции подсчёта количества двоичных едениц в переменной — задача эта дается скорее что б проверить природную сообразительность и, тем самым оценить способности претендента. Я знаю очень красивый алгоритм:
int function (unsigned value)
{
int count;
for (count = 0; value; count++) value &= (value — 1);
return count;
}
считаю что он самый эффективный, могу поспорить что лучше никто не знает....или знает ?;)

Мне вот интересно, как это на БУМАГЕ можно сначала поставить {}, а потом между ними чего-то писать?! :)

Первое, что меня удивило это задача на Си. Работа на уровне битов настолько редка, что кроме работы с аппаратурой ее и негде применить. Да и остальные вопросы дурацкие — "нарисуте домик". Человек задавший этот вопрос полный придурок, и вы сделавшие акцент на этот вопрос(квадратный).Я уверен на сто процентов, что если бы этот вопрос вы задали умным людям при собеседовании (Королев,Циолковский, и многие другие), то под словим домик они бы поняли стандартный домик для дачи и начили рисовать с квадрата. Все ответы на вопросы сильно зависят от характера человека, кроме одного "Вопрос о последнем проекте". В конечном счете играет роль его знания опыт примеры разработак и факты. Все остальное это проверка его общительности и предприимчивости, ничего не говорящие о его реальных знаниях.

Интересно... А главное-очень утешительно, если при приеме на работу просят что-либо написать на С и др.

Наем по родственному признаку уходит в прошлое, однако и в нем были плюсы (рекомендация) Что в этой технике отточено? — самолюбование кадровика? -бесспорно
Вопрос о зарплате более чем логичен, первое что я спрашиваю — Чем предстоит заниматься и сколько за это платят, если это я умею (и хочу делать) и зарплата подходит — тогда продолжаем разговор. Насчет команды, какому руководителю нужны сотрудники, считающие что превосходят по знаниям его? — у нас — Н И К О М У
Десять "звезд" в команде растащат проект на десять разных частей (хорошо если проект, а не фирму) Случаи известные кстати

Что касается M$ — кто их заставляет плодить сырые продукты? — это не проблема программистов, а как раз менеджеров

Вы все совершенно не правы. Статья замечательная. Можно сказать — шедевр! В нашем родном отечестве зачастую принято набирать на работу по родственно-знакомому признаку. Это одна из причин явной деградации всего. Сам занимаюсь ИТ и набором людей к себе кстати тоже. Так вот — все это про меня. Иной раз хочеться взять на работу нового человека. Он нужен — просто позарез, но негде его взять. Приходят бараны, первая фраза которых — знаю все, сколько буду получать? Как только это словосочетание слышу — сразу прощаюсь. Уже устал даже от этой безисходности. Такая отточенная техника отбора — это конечно уровень. У меня все просто, и девиз несколько иной. Я считаю что работник должен быть стратегом. А тактике мы его сами обучим. А бредни про слаженную команду — это всего лишь признание своей некомпетентности, не более того. Каждый работник должен быть "звездой". А их совместная деятельность — это задача менеджмента, которая к их служебным обязанностям не имеет как правило никакого отнощения.
К слову о Микрософт. Если кто-то умеет писать программы лучше чем их пишут в Микрософт — пусть мне покажет, А то у нас в стране только и умеют что охаивать.

из личного опыта...
похоже в Европе эти правила стали внеглассным(а может и глассным)стандартом для менеджеров по набору специалистов...Это даже не смешно, потому, как програмистов среди них нет по определению(в их образовании сильная спецификация цениться больше, чем разносторонее мышление), а если и есть, то про Си они уже не слышали...И если им не люди нужны, а доказательство в собственной крутости,то шли бы они со своим домиком для слепых жирафов...

Из личного опыта — работодатель не всегда программист, у него другие обязанности, другое мышление и т.д. Общаться с такими людьми тяжело и не интересно. Поэтому и пытаются придумать методики "по отбору мозгов".
Вполне согласен с уже озвученным мнением — в коллективе должны быть все: те, кто рождает идеи; те, кто доводит их до ума..и те, кто вылизывает.
С уважением, SmAlex.

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

>>if((strlen(x)==iLen))
А о какой привычке сигнализирует использование двойных скобок? :)

Не стоит относиться к этой статье как к инструкции по приему персонала в фирму. Это тоже, в своем роде, розовые очки. Своя голова поди у каждого есть, поэтому просто мотайте на ус и думайте, думайте, думайте... :)

>Вы понимаете также, что без компилятора трудно писать код без >ошибок, и примете это во внимание.
Считаю, что 5 строк кода без ошибок можно написать(или даже нужно!!!)

Ребята, причем здесь "впервые опубликована"? Эта статья висит на сайте Joel Spolsky среди многих других уже очень давно и широко известна, 99.9% что Joel никогда не слышал о журнале "Технология Клиент-Сервер" и вы нарушили его права и должны ему денег.
http://www.joelonsoftware.com/stories/storyReader$20

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

Кажется это перевод статьи :)
Ибо то, что здесь описано действует где угодно, но не у нас :)
>>Однако, исходя из данной статьи, получается кандидатура явного лидера в >>коллективе, но тогда не понимаю, неужели могут ужиться в одной команде N-е >>количество лидеров.... мне кажется, тут неизбежны конфликты, так как у всякого >>программиста свой подход к решению той или иной проблемы, и наверняка оба этих >>подхода являются правильными...
В процессе разработки западных компаний программисту не надо принимать никаких судьбоносных решений. Он все делает по разработанной технологии и любое отступление от этой технологии он должен обосновать. Более того, указание на ошибки своего коллеги (или фраза типа "Я знаю как лучше сделать") является смертельным оскорблением. Поэтому общения между людьми внутри проекта в нашем понимании этого слова не присутствует :)