Ещё вопросы
Некоторое время назад я написал небольшой пост под названием "Хорошие вопросы", в котором рассказывал про вопросы, которые, как мне кажется, стоило бы задавать на собеседованиях. Там же были некоторые мысли почему именно подобные вопросы стоит задавать, а другие не стоит.
С тех пор уже прошло довольно много времени и у меня появились ещё вопросы, которые вполне можно добавить в тот список.
- Что такое тип (предложено Iv) ?
- Что такое тестирование? (взято из http://www.techinterviews.com/?p=64)
- Почему нельзя запустить под Windows программу для Macintosh? (имеется ввиду без применения специальных ухищрений; впрочем ухищрения тоже можно обсудить)
- В чем разница между "оперативной памятью" и "жестким диском"?
- Что такое язык программирования? Зачем нужна подобная сущность? (в обсуждении можно коснуться и ассемблера и машинных кодов)
Вопрос такой: 2^8 - это сколько?
Нужен ли такой вопрос и что именно он проверяет - это отдельная беседа. Но у меня на эту тему возник другой вопрос:
6. А почему собственно степени двойки так важны? Почему проверкой вменяемости программиста является "отскакивающий от зубов" ответ на вопрос сколько будет 2^8? А не скажем 3^7 :-)
И как и раньше хочу сказать: цель вопросов - спровоцировать разговор на "базовые" темы, а не получить "правильный" ответ.
blog: 
LinkedIn
Мой Круг
9 комментариев:
> Что такое тестирование?
Спросите еще "что такое добро и что такое зло". :)
Вы кого нанимать собираетесь? Секретаршу в девелоперскую контору?
Знание степеней двойки это как проверка на пассионарность. С другой стороны упомянутой статье «глазами пострадавшего» интервьюируют в game-dev контору.
Там частенько напрямую с байтами работать приходится, а они как назло 8-ми разрядные!
А я считаю, что описаный подход имеет право на существование. Если человек с ходу не сможет внятно объяснить таких простых вещей - ему не место в профессии.
2semka: На самом деле вопрос о знании степеней двойки я и не предлагал задавать, он просто навёл меня на мысль о другом вопросе.
2sergey rozovik: Все правильно, вопросы общие и сильно размытые. Их цель спровоцировать дискуссию, а не проверить проштудировал ли человек перед собеседованием книгу по подготовке к собеседованиям :-)
Вообще, я много об этом писал в первой части. Вопросы на мой взгляд должны проверять понимание человеком своей профессии, а не знание некоторых частностей.
эх.. такими вопросами. Я вот сейчас собираюсь найти себе новую работу и просто не хочу идти на собеседование. Не хочу потому, что меня там сядет собеседовать какой-то мальчик, который ни одного проекта в своей жизни не сделал, и спрашивать будет всякую лабуду, к делу не относящуюся. Программирую еще с калькулятора MK 62, но если спросить когда я последний раз сдвигал биты - не отвечу - т.к. реально это никогда не понадобилось...
Читал что-сто связанное с Фудзи про головоломки - если будут спрашивать - буду отправлять к первоисточникам.
Мне это напоминает одного моего преподавателя в ВУЗe, который 20 лет преподавал структуры данных и не заметил ни стандартов, ни мультимедиа, ни интернета.
Сейчас не биты нужны, а быстрая адаптация к новым возможностям.
> если человек не сможет внятно объяснить таких простых вещеей
Каких простых вещей!? Все они просты и сложны одновременно.
кстати, вопрос
>>"что такое добро и что такое зло".
Очень не плох для беседы и попытки понять как чел думает :)
А вот такая задачка..
Допустим вы берете программиста на C#, есть например такой вопрос - http://blogs.msdn.com/ruericlippert/archive/2009/07/06/color-color.aspx
А что думаете Вы по поводу задать его на собеседовании ? :)
ЗЫ Кстати, правильный ответ не так уж и важен... но с другой стороны - если каждый день писать на C#- должен ли человек на него ответиь ?
Я бы такую задачку не задавал. Я вообще не думаю, что какие-то специфические знания являются интересными. Важно, в состоянии ли человек осваивать новые знания, а не знает ли он какие-то тонкости языка или платформы (ну кроме конечно разных спец. случаев).
По самой задачке: Приведенная конструкция в реальном проекте просто никогда не должна появиться и если она появится, то правильно не разбираться с тем как она работает, а переписать её. Об этом собственно и автор пишет в конце:
"В реальных ситуациях статические и экземплярные методы обычно имеют разные имена, так что в типичном сценарии вы никогда не сталкиваетесь с вызовом экземплярного метода, ожидая вызвать статический, или наоборот. Представленный мной сегодня случай коллизии имен между статическим и экземплярным методом относительно редок. "
Ну, с диагнозом я в общем не спорю... не должны такие коллизии встречаться, а если уж встретились – исправляться. Но вопрос не совсем в этом. Я согласен, что любой ответ на этот вопрос, точнее его правильность, не решающая .. но почему бы его, вопрос этот , не использоваться как провокацию? Ну хотя б для того, что б получить встречный вопрос – “а вы реально считаете, что мой ответ на этот вопрос важен в ходе нашей беседы?” . Ведь никто не спорит, я надеюсь, что вопросы могут, а иногда и должны быть, с обеих сторон…. А ?
Это можно конечно. Но мне кажется не нужно когда нанимаешь программиста. Зачем провоцировать человека? Обычно провокацию на собеседовании (т.н. "стресс-тестирование") применяют при приеме на "нервную" работу или на работу, требующую от человека эмоциальной устойчивости. А разработка программ не должна быть стрессовым занятием - если программирование создает стресс для программистов, то это скорее всего проблема управления.
Отправить комментарий