Комментарии 129
Мне кажется (и у меня есть положительный опыт), что самые лучше вопросы:
— Расскажите о себе?
— Какую задачу вы решали?
— Какие вопросы вам пришлось для этого изучить?
— Сколько вы потратили времени?
— Какой своей работой вы больше всего гордитесь?
— Какую книжку читали последней?
— Понравилась?
— Какая книга понравилась больше всего?
и тому подобные.
Все равно на работе человек столкнется самыми разными задачами. И нанимателю важнее знать на сколько быстро человек осваивает новое. На сколько творчески он подходит. На сколько глубоко въезжает. На сколько склонен к автоматизации рутины…
— Расскажите о себе?
— Какую задачу вы решали?
— Какие вопросы вам пришлось для этого изучить?
— Сколько вы потратили времени?
— Какой своей работой вы больше всего гордитесь?
— Какую книжку читали последней?
— Понравилась?
— Какая книга понравилась больше всего?
и тому подобные.
Все равно на работе человек столкнется самыми разными задачами. И нанимателю важнее знать на сколько быстро человек осваивает новое. На сколько творчески он подходит. На сколько глубоко въезжает. На сколько склонен к автоматизации рутины…
Это займет у вас очень много времени, а то что я предлагаю — это очень быстро.
Ещё раз напишу, я не пытаюсь заменить стандартные вопросы по определению предыдущего опыта работы, я стараюсь отсеять ненужных людей ещё до того как я полезу копать их прошлое. Всю рутину интервью вы можете оставить такой как есть, просто вствив вначале предлагаемый мной фильтр.
Ещё раз напишу, я не пытаюсь заменить стандартные вопросы по определению предыдущего опыта работы, я стараюсь отсеять ненужных людей ещё до того как я полезу копать их прошлое. Всю рутину интервью вы можете оставить такой как есть, просто вствив вначале предлагаемый мной фильтр.
Нет! Чтобы сделать выводы, достаточно немного. Можно же задавать наводящие вопросы, останавливать… Максимум — час. Это если видно, что человека надо брать и хочется с ним подольше поговорить.
Час о_О!!! Я не могу тратить столько времени на беседы с людьми, особенно учитывая что 90% из них даже не будут перезванивать.
Обычно задушевные беседы ведет у нас HR, я как руководитель не могу тратить столько времени, я должен выяснить уровень знаний претендента и то смогу ли я и остальные члены нашей команды с претендентом работать. На первое — я использую описаный в статье метод отсева, по остальному беседую только с теми кто остался и согласитесь, реальный профессионал легко пройдет тест описаный в статье. Здесь шанс пропустить «бриллиант» очень низок
Обычно задушевные беседы ведет у нас HR, я как руководитель не могу тратить столько времени, я должен выяснить уровень знаний претендента и то смогу ли я и остальные члены нашей команды с претендентом работать. На первое — я использую описаный в статье метод отсева, по остальному беседую только с теми кто остался и согласитесь, реальный профессионал легко пройдет тест описаный в статье. Здесь шанс пропустить «бриллиант» очень низок
Упс, я имел в виду что 90%-ам даже не будем перезванивать. (а то мою фразу можно прочитать по другому)
Этой статьей вы только разозлите эти 90% :)
не культурно обещать перезвонить и забить.
Но очень многие так делают :(
Это уже на совести HR'а, насколько он честно сообщает наши решения кандидату. Поверьте, меня и самого не раз так кидали. Почему-то практика не сообщать, что ты послан и не сообщать причину — это нормальное явление. Я как-то беседовал со знакомой руководительницей HR подразделения по этому поводу. Она мне плела что-то про какие-то судебные иски на опротестование решений и т.д. и т.п. в общем я не компетентен в этом вопросе (о поведении HR'ов) так что не могу нормально оправдать или осудить такое поведение.
человек должен уйти с собеседования с чувством что его приняли, как бы ни было на самом деле. это повышает лояльность к компании, он может порекомендовать ее знакомым и родственникам. А может и прийти еще раз.
А для этого всегда улыбаются, говорят, что перезвонят (и часто перезванивают).
А для этого всегда улыбаются, говорят, что перезвонят (и часто перезванивают).
Не буду спорить, вы правы… но это всё-же задача HR'а, а не технического специалиста или руководителя которые участвуют в собеседовании.
Я бы не стал считать людей за идиотов. Большинство знаю цену этим улыбкам и обещаниям.
Обратная сторона медали тоже очень хорошо себя проявляет. Каждый раз при смене работы ещё в течении как минимум месяца после окончания поисков звонят с предложением прийти оформить документы.
Обратная сторона медали тоже очень хорошо себя проявляет. Каждый раз при смене работы ещё в течении как минимум месяца после окончания поисков звонят с предложением прийти оформить документы.
Мне кажется оба подхода имеют место; вы скорее настроены найти узкоспециализированного подготовленного сотрудника, который сразу начнёт давать результат, но это не всегда то, что нужно. Иногда нужны консультанты/аналитики итп, которые могут а) не иметь формального опыта (что иногда плюс вообще) б) методология внедрения меняется от конторы к конторе, у Ораклов это одно у Сапов другое у Микрософтов третье…
Например, вопрос типа «каковы функции системного аналитика на первой фазе внедрения» вполне себе конкретен для Оракла но вообще смысла не имеет для остальных. А вот просьба написать короткий документик или рассказать о последней гниге мне дадут кое-что понять о человеке. Очень зависит от вакансии, не только от «новомодности эйч ар политики».
Например, вопрос типа «каковы функции системного аналитика на первой фазе внедрения» вполне себе конкретен для Оракла но вообще смысла не имеет для остальных. А вот просьба написать короткий документик или рассказать о последней гниге мне дадут кое-что понять о человеке. Очень зависит от вакансии, не только от «новомодности эйч ар политики».
Да я и не отрицаю методу которую написал мичурин, я просто перед ней хочу поставить фильтр который отсеет низкоквалифицированных сотрудников прежде чем я начну выяснять насколько человек команден, насколько стрессоустойчив, как подходит к решению сложных задач и т.п. На хабре уже поднималась тема «врунов в резюме» — людей которые пишут заоблачные сказки в своих резюме и сколько необходимо времени потратить, чтобы всё выяснить.
Вот из недавнего опыта, пришел человек устраиваться на должность системного архитектора, я его решил просто послушать… он мне нарасказывал какие замечательные проекты он строил и какие сервера проектировал и взаимодейсвтия с каими базами данных делал. А потом он мне просто не ответил о том что такое транзакция и что такое управляемый код.
Подумайте, что бы он мне спроектировал? Сервер работающий с базой где одна операция затирает другую? Или план развертывания приложения где нить на голой инсталляции Win2003 где нет .NET Framework 3.5 (а сервер будет написан под него).
Вот из недавнего опыта, пришел человек устраиваться на должность системного архитектора, я его решил просто послушать… он мне нарасказывал какие замечательные проекты он строил и какие сервера проектировал и взаимодейсвтия с каими базами данных делал. А потом он мне просто не ответил о том что такое транзакция и что такое управляемый код.
Подумайте, что бы он мне спроектировал? Сервер работающий с базой где одна операция затирает другую? Или план развертывания приложения где нить на голой инсталляции Win2003 где нет .NET Framework 3.5 (а сервер будет написан под него).
Это проблема более широкая чем кажеться. С одной стороны все хотят узкоспециализированных специалистов «под себя» чтобы сразу в команду и понеслось… а с другой как раз таки получают специалистов у которых нет базовых знаний. Ваш пример про общую архитектуру и что такое транзакция, тому подтверждение. И чем дальше тем хуже…
вы не знакомы с теорией и тем более практикой. как муж менеджера по персоналу могу ответственно заявить, что собеседования длиной более 45 не эффективны: устают и кандидат и hr
Гм. Затрудняюсь конкретно ответить на почти любой из этих вопросов.
— Расскажите о себе?
Э-э-э-э, что именно вас интересует. Моя профессиональная деятельность изложена в резюме. Рассказать про личную жизнь??? Вряд ли она вас касается.
— Какую задачу вы решали?
Э-э-э… Почти каждый божий день решаю штук по десять задач. Иногда наоборот, долго решаю какую-нибудь одну сложную задачу…
— Какие вопросы вам пришлось для этого изучить?
Те, с которыми не сталкивался при решении предыдущих задач или на которые не хватает знаний и банальной эрудиции. А какой вы ожидаете ответ на этот вопрос?
— Сколько вы потратили времени?
Столько, чтобы изучить вопрос, ещё немного, чтобы поэкспериментировать, если вопрос не совсем тривиальный.
— Какой своей работой вы больше всего гордитесь?
Всей.
— Какую книжку читали последней?
Гм. Сатанинские стихи Салмана Рушди. А что?
— Понравилась?
А зачем читать книжку, которая не нравится?
— Какая книга понравилась больше всего?
??? «Мама, ты кого больше любишь, меня или братика?»
>и тому подобные.
Вообще не понял, что вы хотите, а главное, что сможете, узнать из ответов на подобные вопросы…
— Расскажите о себе?
Э-э-э-э, что именно вас интересует. Моя профессиональная деятельность изложена в резюме. Рассказать про личную жизнь??? Вряд ли она вас касается.
— Какую задачу вы решали?
Э-э-э… Почти каждый божий день решаю штук по десять задач. Иногда наоборот, долго решаю какую-нибудь одну сложную задачу…
— Какие вопросы вам пришлось для этого изучить?
Те, с которыми не сталкивался при решении предыдущих задач или на которые не хватает знаний и банальной эрудиции. А какой вы ожидаете ответ на этот вопрос?
— Сколько вы потратили времени?
Столько, чтобы изучить вопрос, ещё немного, чтобы поэкспериментировать, если вопрос не совсем тривиальный.
— Какой своей работой вы больше всего гордитесь?
Всей.
— Какую книжку читали последней?
Гм. Сатанинские стихи Салмана Рушди. А что?
— Понравилась?
А зачем читать книжку, которая не нравится?
— Какая книга понравилась больше всего?
??? «Мама, ты кого больше любишь, меня или братика?»
>и тому подобные.
Вообще не понял, что вы хотите, а главное, что сможете, узнать из ответов на подобные вопросы…
— Отвечаете вопросом на вопрос. Не понимаете контекста. Не можете оценить что именно интересует собеседника.
— Вместо рассказа про задачу рассказали про их количество. Льёте воду, не отвечаете не вопрос.
— Книги читаете интересные, но только те, что нравятся. Склонны ковыряться в уже изученном и привычном.
Вы провалили собеседование :-)
На это нам с вами понадобилось 3 минуты (отвечая на).
— Вместо рассказа про задачу рассказали про их количество. Льёте воду, не отвечаете не вопрос.
— Книги читаете интересные, но только те, что нравятся. Склонны ковыряться в уже изученном и привычном.
Вы провалили собеседование :-)
На это нам с вами понадобилось 3 минуты (отвечая на).
— Отвечаете вопросом на вопрос.
А почему нет? :) Вопрос задан в более чем общем виде.
— Не понимаете контекста.
Контекст не задан, вопросы показывают, что либо к интерью _вы_ не готовились, даже не читали моё резюме, либо пытаетесь лезть куда вам не следует.
— Вместо рассказа про задачу рассказали про их количество.
Какую именно задачу? При условии пункта первого, где вы отказали мне в праве задавать уточнаяющие вопросы, это вообще не имеет смысла.
— Льёте воду, не отвечаете не вопрос.
Приведите пример как по вашему правильно ответить на этот вопрос? Ну, или, скажем, на вопрос, — «что вы ели?».
— Книги читаете интересные, но только те, что нравятся.
Я повторяюсь, но зачем читать те, что не нравятся??? Как правило, выбор настолько велик, что читать что-то плохое — верх безумства. Если только я не литературный критик. А я — не.
— Склонны ковыряться в уже изученном и привычном.
Хм. Пальцем в небо :). Обожаю ковыряться во всём новом.
— Вы провалили собеседование :-)
Взаимно :)
— На это нам с вами понадобилось 3 минуты
Вряд ли я согласился бы работать в компании, делающей настолько скоропалительные выводы на основании некоррекрных вопросов. У вас велика шаблонность мышления и зашоренность сознания. Это было сразу видно по вопросам, но интересно было уточнить детали… :)
А почему нет? :) Вопрос задан в более чем общем виде.
— Не понимаете контекста.
Контекст не задан, вопросы показывают, что либо к интерью _вы_ не готовились, даже не читали моё резюме, либо пытаетесь лезть куда вам не следует.
— Вместо рассказа про задачу рассказали про их количество.
Какую именно задачу? При условии пункта первого, где вы отказали мне в праве задавать уточнаяющие вопросы, это вообще не имеет смысла.
— Льёте воду, не отвечаете не вопрос.
Приведите пример как по вашему правильно ответить на этот вопрос? Ну, или, скажем, на вопрос, — «что вы ели?».
— Книги читаете интересные, но только те, что нравятся.
Я повторяюсь, но зачем читать те, что не нравятся??? Как правило, выбор настолько велик, что читать что-то плохое — верх безумства. Если только я не литературный критик. А я — не.
— Склонны ковыряться в уже изученном и привычном.
Хм. Пальцем в небо :). Обожаю ковыряться во всём новом.
— Вы провалили собеседование :-)
Взаимно :)
— На это нам с вами понадобилось 3 минуты
Вряд ли я согласился бы работать в компании, делающей настолько скоропалительные выводы на основании некоррекрных вопросов. У вас велика шаблонность мышления и зашоренность сознания. Это было сразу видно по вопросам, но интересно было уточнить детали… :)
НЛО прилетело и опубликовало эту надпись здесь
Я, в общем-то, и спрашиваю, а что, собственно, собеседник хочет узнать с помощью таких странных вопросов. Выясняется, что либо ничего, либо он начитался эйчарных недокнижек и мнит себя мегапсихологом, но при этом выводы делает «вселенского масштаба и вселенской же глупости» (ц). Как-то так.
НЛО прилетело и опубликовало эту надпись здесь
Не пойму. Где здесь агрессивная позиция? В том, что я попросил уточнить что именно их интересует? Или какую именно задачу они имели в виду? Они сразу стали в позу — а чего это вы вопросом на вопрос отвечаете. А то и спрашиваю, что вопросы дебильные. Ну-тко, вот вы, конкретно, ответьте, какой задачей вы занимались? Вообще. Какой задачей? Вы ведь, очевидным образом, за ваши лет 10 стажа занимались ровно одной задачей, ведь правда? Гайку номер шесть точили, наверное. Расскажите какие проблемы возникли при вытачивании гайки номер шесть. Что тут непонятного? Человек, нанимающий разработчика не понимает таких простых вещей??? Очено странно. Я ведь не сразу стал в агрессивную позицию. А только тогда, когда вместо уточнения что они имели в виду, задавая дебильные вопросы, они отказали мне в праве этого уточнения. Ну, и нафига мне у них (гипотетически) работать? Вы представляете себе моральный климат в этой, с позволения сказать, «команде». Я точно не игрок в «команде», которая для своих членов предоставляет настолько невыносимые условия. Я привык к другому. К хорошему. К тому, что я могу подойти к любому члену команды и попросить объяснить то, что мне непонятно. И любой другой член команды может подойти ко мне и я с удовольствием помогу в своей области компетенции. И у начальства без проблем уточню непонятные детали задания. По-вашему, это не командная работа? По-вашему, командная это как у них? «Переспрашиваешь — пошёл нах!» Тогда да, в вашем понимании я не командный игрок :) :).
НЛО прилетело и опубликовало эту надпись здесь
>«Вы, что резюме не читали? Остальное вас не касается».
Можно мои слова переврать даже матом и посыланием по матери. Но-то я не говорил ни матом ни в грубой форме. Особенности вашего восприятия — это особенности вашего восприятия, и сами с собою вы можете спорить сколько угодно, но я тут совершенно не при чём :). И… ведь действительно… разве остальное вас/их касается? Я ведь действительно удивлён этим вопросом — зачем пересказывать резюме, которое лежит у них перед глазами? Ну зачем???
>Получается, что проходящий интервью будет рассказывать именно про то, что ему действительно интересно.
Угу. «А вот если бы у рыбы была шерсть, то в ней водились бы блохи». Я, по какой-то странной причине, полагал, что меня приглашают на собеседования, чтобы узнать ответы на вопросы, которые интересуют работодателя. Наверное, я ошибался, да? Оказывается я должен его развлекать, при этом не задавая ни каких вопросов и предугадывая его желания? Пардон, он технического специалиста ищет, или наложницу в гарем?
>Вопрос про задачу можно рассматривать так
Можно рассматривать так, а можно и не так. Дело не в этом. Дело в том, что мне отказывают в праве задать уточняющий вопрос. Вы тоже считаете, что я не могу задать вопрос на интерью? А почему, собственно? Я делаю что-то неприличное, задавая этот вопрос? Оскорбляю собеседника в грубой форме? Вроде нет. Единственное моё разумное предположение — у собеседника в голове какие-то дебильные комплексы, зашоренность сознания и шаблонность мышления. Я из этого (а кроме как из данного разговора откуда мне брать информацию?) делаю весьма неутешительные выводы о том, что атмосфера в этой компании весьма и весьма некомфортна для работы. А после такого вывода зачем мне тратить цветы своей селезёнки на то, чтобы телепатическими способностями выяснять что именно не осилили сформулировать человечьим языком в вопросе интервьюеры? :)
Всё ведь просто. Интервьюеры считают, что делают мне одолжение своим интервью, а я должен от этого бегать на цыпочках и догадываться о том чего хочет их левая нога. Это не так. Интервью — процесс обоюдного составления мнения. Я тоже составляю о них мнение и самое в этом деле ценное то, что они, как правило (это видно из их ответов, да и из вашего тоже) не очень об этом подозревают, а значит, их реакции более естественные, чем у интервьюируемых (эти-то специально готовятся зачастую). Так-то вот. А то, что вы углядели агрессию там, где её нет — это ваше право, конечно, но у меня-то тоже есть право сделать из этого соответствующие выводы :).
Можно мои слова переврать даже матом и посыланием по матери. Но-то я не говорил ни матом ни в грубой форме. Особенности вашего восприятия — это особенности вашего восприятия, и сами с собою вы можете спорить сколько угодно, но я тут совершенно не при чём :). И… ведь действительно… разве остальное вас/их касается? Я ведь действительно удивлён этим вопросом — зачем пересказывать резюме, которое лежит у них перед глазами? Ну зачем???
>Получается, что проходящий интервью будет рассказывать именно про то, что ему действительно интересно.
Угу. «А вот если бы у рыбы была шерсть, то в ней водились бы блохи». Я, по какой-то странной причине, полагал, что меня приглашают на собеседования, чтобы узнать ответы на вопросы, которые интересуют работодателя. Наверное, я ошибался, да? Оказывается я должен его развлекать, при этом не задавая ни каких вопросов и предугадывая его желания? Пардон, он технического специалиста ищет, или наложницу в гарем?
>Вопрос про задачу можно рассматривать так
Можно рассматривать так, а можно и не так. Дело не в этом. Дело в том, что мне отказывают в праве задать уточняющий вопрос. Вы тоже считаете, что я не могу задать вопрос на интерью? А почему, собственно? Я делаю что-то неприличное, задавая этот вопрос? Оскорбляю собеседника в грубой форме? Вроде нет. Единственное моё разумное предположение — у собеседника в голове какие-то дебильные комплексы, зашоренность сознания и шаблонность мышления. Я из этого (а кроме как из данного разговора откуда мне брать информацию?) делаю весьма неутешительные выводы о том, что атмосфера в этой компании весьма и весьма некомфортна для работы. А после такого вывода зачем мне тратить цветы своей селезёнки на то, чтобы телепатическими способностями выяснять что именно не осилили сформулировать человечьим языком в вопросе интервьюеры? :)
Всё ведь просто. Интервьюеры считают, что делают мне одолжение своим интервью, а я должен от этого бегать на цыпочках и догадываться о том чего хочет их левая нога. Это не так. Интервью — процесс обоюдного составления мнения. Я тоже составляю о них мнение и самое в этом деле ценное то, что они, как правило (это видно из их ответов, да и из вашего тоже) не очень об этом подозревают, а значит, их реакции более естественные, чем у интервьюируемых (эти-то специально готовятся зачастую). Так-то вот. А то, что вы углядели агрессию там, где её нет — это ваше право, конечно, но у меня-то тоже есть право сделать из этого соответствующие выводы :).
НЛО прилетело и опубликовало эту надпись здесь
Давайте.
1а. Да, верно. Но давайте рассмотрим гипотетическую ситуацию, когда я прихожу на собеседование в грязной одежде, недельной щетине и воняя перегаром. У меня, как и у собеседника, вполне могут быть объяснимые и банальные причины этому. Просто десятки. Навскидку: грязный — обрызгала машина прямо перед входом, щетина — не болел в детсве ветрянкой, а тут подхватил (представте что такое побриться во время ветрянки), алкоголь — ну, может болезнь специфическая, бывает такое при обострениях. Разумно? Банально? Объяснимо? Но у собеседующего от гразного-небритого-перегарного меня сразу сложится вполне определённое мнение (минус сто в карму). И он имеет на это право! Как и я имею право составить отрицательное мнение о нём на основе его поведения.
1б, 1в — это ни как не объясняет причину по которой мне отказывают в уточнении что именно интересует собеседника. Согласитель, что если бы ему небыло что скрывать он совершенно спокойно мог мне это объяснить. Вот как вы сейчас. Что может быть проще? Но он повёл себя явно неадекватно. Мне нет повода сомневаться, что и в рабочей обстановке он не перестанет быть неадекватом. Уж если с незнакомым человеком он сразу начинает с этог, чего тогда ждать, когда он станет моим начальником? Вы считаете мои выводы неразумными? А, собственно, почему?
>Для этого особственно и определяют задачу.
Задача как раз не определена, а на наводящие вопросы работодатель реагирует подозрительно нервно. Я, собственно, об этом. Про задачи пусть спрашивает — это логично и закономерно, но я не обязан быть телепатом. В конце-концов я устраиваюсь не жопу ему лизать, а продаю свои знания, опыт и время за определённую сумму денег. Предугадывание мыслей начальника, по моему глубокому убеждению, не входит в круг моих должностных обязанностей. Если ему нужен жополиз, то нам обоим будет лучше, если он наймёт на эту должность не меня. ЧТД.
Про рыбу — это просто анекдот такой старенький. www.bestanekdot.ru/student/8.shtml третий сверху.
>Вы в реальной жизни тоже всегда спрашиваете по 100 раз прежде чем ответить? Достаточно одного вопроса.
О-хо-хо! Так вас смутили два моих вопроса подряд? :) Но ведь это же оффлайн! В случае адекватного ответа на первый, второй, разумеется, не задаётся. Но в оффлайновой беседе отразить это не просто. Для симметрии посмотрите же — собеседник тоже сразу вывалил пачку вопросов. Отчего же к нему у вас нет претензий? :)
1а. Да, верно. Но давайте рассмотрим гипотетическую ситуацию, когда я прихожу на собеседование в грязной одежде, недельной щетине и воняя перегаром. У меня, как и у собеседника, вполне могут быть объяснимые и банальные причины этому. Просто десятки. Навскидку: грязный — обрызгала машина прямо перед входом, щетина — не болел в детсве ветрянкой, а тут подхватил (представте что такое побриться во время ветрянки), алкоголь — ну, может болезнь специфическая, бывает такое при обострениях. Разумно? Банально? Объяснимо? Но у собеседующего от гразного-небритого-перегарного меня сразу сложится вполне определённое мнение (минус сто в карму). И он имеет на это право! Как и я имею право составить отрицательное мнение о нём на основе его поведения.
1б, 1в — это ни как не объясняет причину по которой мне отказывают в уточнении что именно интересует собеседника. Согласитель, что если бы ему небыло что скрывать он совершенно спокойно мог мне это объяснить. Вот как вы сейчас. Что может быть проще? Но он повёл себя явно неадекватно. Мне нет повода сомневаться, что и в рабочей обстановке он не перестанет быть неадекватом. Уж если с незнакомым человеком он сразу начинает с этог, чего тогда ждать, когда он станет моим начальником? Вы считаете мои выводы неразумными? А, собственно, почему?
>Для этого особственно и определяют задачу.
Задача как раз не определена, а на наводящие вопросы работодатель реагирует подозрительно нервно. Я, собственно, об этом. Про задачи пусть спрашивает — это логично и закономерно, но я не обязан быть телепатом. В конце-концов я устраиваюсь не жопу ему лизать, а продаю свои знания, опыт и время за определённую сумму денег. Предугадывание мыслей начальника, по моему глубокому убеждению, не входит в круг моих должностных обязанностей. Если ему нужен жополиз, то нам обоим будет лучше, если он наймёт на эту должность не меня. ЧТД.
Про рыбу — это просто анекдот такой старенький. www.bestanekdot.ru/student/8.shtml третий сверху.
>Вы в реальной жизни тоже всегда спрашиваете по 100 раз прежде чем ответить? Достаточно одного вопроса.
О-хо-хо! Так вас смутили два моих вопроса подряд? :) Но ведь это же оффлайн! В случае адекватного ответа на первый, второй, разумеется, не задаётся. Но в оффлайновой беседе отразить это не просто. Для симметрии посмотрите же — собеседник тоже сразу вывалил пачку вопросов. Отчего же к нему у вас нет претензий? :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
именно!
Человек ищется под конкретную позицию в конкретную контору. Если там COM, значит «до свидания».
А то что он, например, поёт красиво — пускай жена радуется.
Человек ищется под конкретную позицию в конкретную контору. Если там COM, значит «до свидания».
А то что он, например, поёт красиво — пускай жена радуется.
Если человек берется на должность COM разработчика он должен знать ответ на этот вопрос. Конечно нагуглить — это пара пустяков, но нагуглить он сможет если знает вопрос, а если он не знает вопрос и его последствия — то это будет долгая копотня с багами. Порой так бывает.
Вопросы задаются по существу вакансии.
Вопросы задаются по существу вакансии.
Хрен Вы за минуту нагуглите, что делает эта функция, лежащая в основе COM, со всеми нюансами её многопоточного использования. А уж какие виртуозные баги выдает программа иногда, когда для какого-то дочернего потока забудешь её верно вызвать — закачаешься. Так что вполне себе вопрос на знание основ технологии.
Ага, если ещё и забывать про маршалинг указателей между потоками — жесть. А ещё бывает когда перекрываешь у главного окна обработчик событий виндовых (на предмет блокировки) и у тебя перестает маршалинг работать вообще…
Эх ребята, я с вами вспомнил старые веселые времена когда работал программером :)
Эх ребята, я с вами вспомнил старые веселые времена когда работал программером :)
а не кажется Вам, что с такими вопросами вы возьмёте на работу заучку-ботана. который наизусть знает все формулировки, но не сможет решить нестандартной задачи.
Да бросьте, всегда видно, понимает человек, о чём говорит или нет. В ответе со сравнением строк, например, понимающий скажет что и так и так будет, зависит от компилятора, вообще говоря неравно и по уму сравнивать бы надо иначе и так далее. Вопросы — повод для разговора, не «да/нет» же на них будут отвечать.
Точно, про «да/нет » вы отлично подметили. Я именно и хочсу указать что мы даем простой вопрос и смотрим как человек на него ответил.
может быть. просто очень уж вопросы напоминают те, что выдавали нам в универе для подготовки к экзаменам. академические они какие-то.
ну статья не моя, а в универе тоже преподаватель всегда видит понимает ли человек что он несёт или считывает набор слов из подсознания.
ну у меня в универе задачи были не такие, но может у вас по другому. тут могу сказать только одно: «Всё новое — это очень хорошо забытое старое»
Дык они такими и должны быть. В универе задача такая, проверять знания, о чем в компаниях при найме новых сотрудников почему-то иногда забывают…
Вам так кажется? В универах то дают теоритические данные, лично меня как работодателя интересовал бы в первую очередь опыт. Простой пример. Допустим, вопрос "- Что такое файл?", многие смогут дать на него ответ, что называется с ходу? И в то же время все могут файлы использовать, копировать, удалять, создавать и прочее и прочее.
А ты отдашь механику чинить свою машину, если он тебе не скажет что такое гайка и для чего она нужна?
когда был на практике на заводе, был там один слесарь, жуткий пропойца. не увольняли, так как мастер был высшего класса, мог из болванки идеальный шар сделать, с точностью до микрон. так вот, все технические термины он заменял матерными синонимами, а названия некоторых инструментов даже не знал.
НЛО прилетело и опубликовало эту надпись здесь
думаю что дам
НЛО прилетело и опубликовало эту надпись здесь
И ещё раз повторю, я здесь описал первый фильтр по профессиональным навыкам, если человек его прошел, то мы выясняем остальное. Если нам нужен R&D специалист, то после его профпригодности мы будем вяснять как раз его подходы к решению проблем или самообучению.
>Вопрос: Приведем кусочек кода:
Ну «equal» напечатает. Интернирование сработает. В смысле сравнения строк не очень показательный пример.
Ну «equal» напечатает. Интернирование сработает. В смысле сравнения строк не очень показательный пример.
… опоздал я с комментарием… :)
ммм… сработает? Там же const char, однако.
Что мне помешает сделать так:
char* word1 = “Hello”;
char* word2 = “Hello”;
word1[2] = 'x';
if( word1 == word2 )
printf(“equal”);
else
printf(“not equal”);
?
Или мы говорим о шибко умных компиляторах?
Что мне помешает сделать так:
char* word1 = “Hello”;
char* word2 = “Hello”;
word1[2] = 'x';
if( word1 == word2 )
printf(“equal”);
else
printf(“not equal”);
?
Или мы говорим о шибко умных компиляторах?
упс. Следует читать «там же не const char, однако
Строковые литералы — константы, и могут хранится в сегменте только для чтения, и некоторые компиляторы так и делают.
компилятор, который был под рукой (Keil C) даже const char *s=«ABCD»; запихивает в секцию .data (эта та, где память RW). Что бы он гарантировано запихнул в секцию .conststring (она у меня хранится натурально в ROM)
упс, не дописал :(
Так вот, что бы компилятор запихнул в .conststring надо сделать вообще вот так:
static const char *s = «ABCD»;
Ибо в другом случае я могу по дурости передать ссылку на строку за пределы модуля, а что там будет с ней — одному Б-гу известно.
Немного параноидально, но в целом правильно. Это конечно же относится к C. В C++ было бы по другому.
Так вот, что бы компилятор запихнул в .conststring надо сделать вообще вот так:
static const char *s = «ABCD»;
Ибо в другом случае я могу по дурости передать ссылку на строку за пределы модуля, а что там будет с ней — одному Б-гу известно.
Немного параноидально, но в целом правильно. Это конечно же относится к C. В C++ было бы по другому.
Вот ты заморочился :)
вот о таких ответах я и писал, ты подумал о том что я идиот и расписал всё по полочкам :)
вот о таких ответах я и писал, ты подумал о том что я идиот и расписал всё по полочкам :)
… и ответил совершенно неправильно, ориентируясь только на поведение одного конкретного компилятора для одной конкретной платформы, а не на знание стандарта. Браво?
Указал и компилятор и то как программа себя поведет, т.е. аргументированно показал что будет. Так что всё нормально.
Вопрос не в том. Я сказал, что некоторые компиляторы согласно правилам стандарта размещают строки в ro секции. Как опровержение мне приводится аргумент что компилятор такой-то так не делает. Ну и что? Это не значит, что никто не делает.
«Существуют синие мячи» — «А у меня вот есть белый» — «И что?»
«Существуют синие мячи» — «А у меня вот есть белый» — «И что?»
Суть не в этом. И топик не про компиляторы, а про подбор персонала.
Ещё раз распишу:
я привел не удачный пример, который может трактоваться по разному на разных платформах и разными компиляторами, но это не меняет сути. Потому что я задам человеку вопрос «Почему?» (если мне он не ответит сразу развернуто) и по его ответу можно будет понять, насколько он в теме.
Ещё раз распишу:
я привел не удачный пример, который может трактоваться по разному на разных платформах и разными компиляторами, но это не меняет сути. Потому что я задам человеку вопрос «Почему?» (если мне он не ответит сразу развернуто) и по его ответу можно будет понять, насколько он в теме.
> Суть не в этом.
А в чём суть? В том, что вы можете согласиться с неправильным чисто-техническим утверждением относительно си, и в том, что не видите разницы между «есть такие компиляторы» и «все компиляторы обязательно так делают»?
Да и в том-то и дело, что не может трактоваться по-разному. Если на каком-то компиляторе допустимо писать в строку-литерал, то эта ситуация аналогична тому, что иногда может получиться записть n+1-й элемент в массив на n элементов. Что первое, что второе — UB.
Или вы серьёзно думаете, что от того, напишете вы const char *x = ...; или char *x = ...; то, что справа от знака равно будет иметь или не иметь квалификатор const?
А в чём суть? В том, что вы можете согласиться с неправильным чисто-техническим утверждением относительно си, и в том, что не видите разницы между «есть такие компиляторы» и «все компиляторы обязательно так делают»?
Да и в том-то и дело, что не может трактоваться по-разному. Если на каком-то компиляторе допустимо писать в строку-литерал, то эта ситуация аналогична тому, что иногда может получиться записть n+1-й элемент в массив на n элементов. Что первое, что второе — UB.
Или вы серьёзно думаете, что от того, напишете вы const char *x = ...; или char *x = ...; то, что справа от знака равно будет иметь или не иметь квалификатор const?
Не обязательно уходить на микроконтроллеры, чтобы нечто размещалось в ro-памяти. Самый обычный gcc 4.4.2 на Linux x86_64:
Ещё пример:
$ cat hello.c
#include <stdio.h>
int main(void)
{
printf("hello, world");
}
$ gcc -S hello.c
$ head -n 4 hello.s
.file "hello.c"
.section .rodata
.LC0:
.string "hello, world"Ещё пример:
$ cat hello.c
int main(void)
{
char *x = "hello, world";
x[0] = 'a';
return 0;
}
$ gcc -W -Wall hello.c
$ ./a.out
Ошибка сегментированияНе судите строго, я пример привел на вскидку.
Что будет напечатано в консоли после выполнения кода?
Очень хороший пример того, какие задачи не нужно давать — нормальный компилятор даст «equal» за счет интернирования строковых литералов. И это никак не поможет определить, понимает ли человек, как работают строки и указатели.
Это все очень правильно, то, что вы говорите. Именно понимание простых вещей и умение их донести до другого человека показывают то, насколько человек проник в суть предмета. К сожалению, сейчас множество людей на собеседованиях пытаются скрыть недостаток знаний за громкими словами о шаблонах проектирования, методиках разработки, супер-расширяемых и супер-устойчивых системах, когда на деле простые вопросы ставят их в тупик.
Однако, я считаю, что одной теорией дело ограничиваться не должно. На мой взгляд, чтобы еще больше сэкономить свое время, кандидата стоит попросить еще до личной встречи набросать самую простейшую программу, 10-20 строк, не более. Пусть она решает тривиальную задачу, вроде нахождения НОД или подсчета слов в тексте, ничего сложного. И тогда некоторое количество людей ( вы возможно удивитесь, но их будет не так уж и мало) отсеются в самом начале и спасут вам несколько часов времени, а может и компанию от неудачного работника.
P.S. Я понимаю, что возможно многие потенциальные кандидаты сейчас скажут — я ведущий разработчик, мое время стоит N долларов в час и я не буду тратить его на такую ерунду. Однако, если вы хотите работать в данной компании (а иначе, зачем вы туда устраиваетесь? ) — вы можете потратить 20 минут своего времени на то, чтобы попасть туда. Если нет — возможно, вам не так уж и нужна эта работа.
Однако, я считаю, что одной теорией дело ограничиваться не должно. На мой взгляд, чтобы еще больше сэкономить свое время, кандидата стоит попросить еще до личной встречи набросать самую простейшую программу, 10-20 строк, не более. Пусть она решает тривиальную задачу, вроде нахождения НОД или подсчета слов в тексте, ничего сложного. И тогда некоторое количество людей ( вы возможно удивитесь, но их будет не так уж и мало) отсеются в самом начале и спасут вам несколько часов времени, а может и компанию от неудачного работника.
P.S. Я понимаю, что возможно многие потенциальные кандидаты сейчас скажут — я ведущий разработчик, мое время стоит N долларов в час и я не буду тратить его на такую ерунду. Однако, если вы хотите работать в данной компании (а иначе, зачем вы туда устраиваетесь? ) — вы можете потратить 20 минут своего времени на то, чтобы попасть туда. Если нет — возможно, вам не так уж и нужна эта работа.
Гм понимание простых вещей остается в мозгах максимум пару лет после их узучения.
Потом наступает глубинное понимание и спинной мозг.
Это как писать ++i в циклах а не i++
в начале понимаешь смысл сей простой операции, потом привыкаешь использовать, потом забываешь.
Потом наступает глубинное понимание и спинной мозг.
Это как писать ++i в циклах а не i++
в начале понимаешь смысл сей простой операции, потом привыкаешь использовать, потом забываешь.
Некоторые кандидаты забьют на такое задание и пойдут в другую фирму. Что кстати никак не говорит, что они плохие
Отличный, кстати, способ найма! Браво! А то, бывало, приходишь, а тебя спрашивают что-то типа «каковы особенности использования третьего параметра в функции ААА класса БББ фреймворка ССС?». Три незнакомых названия в вопросе.
Ты говоришь, что не знаешь, на тебя смотрят как на дебила и ты уходишь. Потом дома оказывается, что фреймворк весь состоит из 200 строк кода, делает сущую мелочь, класс в нем всего один а метод ААА имеет третий параметр по умолчанию, которому никогда никакого другого значения передавать и не надо. И это и был ответ. А я не знал. И меня послали.
А вот спросили бы, что такое «фреймворк», «класс», «метод», «параметр по умолчанию». Спросили бы, как реализовать то, что этот метод делает.
Так нет. Надо сразу начать с непонятных заоблачных дебрей.
Ты говоришь, что не знаешь, на тебя смотрят как на дебила и ты уходишь. Потом дома оказывается, что фреймворк весь состоит из 200 строк кода, делает сущую мелочь, класс в нем всего один а метод ААА имеет третий параметр по умолчанию, которому никогда никакого другого значения передавать и не надо. И это и был ответ. А я не знал. И меня послали.
А вот спросили бы, что такое «фреймворк», «класс», «метод», «параметр по умолчанию». Спросили бы, как реализовать то, что этот метод делает.
Так нет. Надо сразу начать с непонятных заоблачных дебрей.
НЛО прилетело и опубликовало эту надпись здесь
Если человека берут конкретно на COM, то вопросы по нему вполне оправданы.
Но, увы, бывает так, что вопросы задаются, вроде, простые, но с какой-нибудь под… ковыркой… Например, «зачем нужно объявлять конструктор класса как private» или «что будет, если в структуре объявить поле как int a:32;». И сидишь, как дурак, и думаешь, какой смысл «создатели» вопроса в него вкладывали.
Но, увы, бывает так, что вопросы задаются, вроде, простые, но с какой-нибудь под… ковыркой… Например, «зачем нужно объявлять конструктор класса как private» или «что будет, если в структуре объявить поле как int a:32;». И сидишь, как дурак, и думаешь, какой смысл «создатели» вопроса в него вкладывали.
ну тут тоже нюансы, думаю если тебя берут на вакансию разработчика библиотек или API где сокрытие доступности или реализации — это важно. То можно и задать.
Может, то что вы не знаете ответов на эти вопросы, как раз показывает, что эта позиция пока что не для вас?
Возможно, это сигнал, что стоит взять дома в руки гугл и почитать что бы это могло значить.
Возможно, это сигнал, что стоит взять дома в руки гугл и почитать что бы это могло значить.
А какой ответ правильный? Тот, что по стандарту или тот, с которым в жизни сталкиваешься? Я ведь не зря написал, что вопросы с «подковыркой». Изначальный вопрос, правда, был про деструктор, и «правильный» ответ был: «Чтобы нельзя было объект создать на стеке, а можно было только в хипе», а на вопрос: «а удалять же его как» я получил ответ «а удалять его не нужно, сам удалится, когда программа работу завершит». Я бы, скорее, подумал про friend-классы, но до такого точно бы не додумался. А на второй вопрос правильный ответ зависит от компилятора, потому что gcc отработает правильно, а студия начнет во время выполнения путать поля в структуре, хотя по стандарту такая конструкция вполне допустима.
А, в третьих, речь шла о том, что такие вопросы часто задаются там, где они нафиг не нужны. Или специально так формулируются, чтобы стать непонятными. Я понимаю, что разработчику многопоточного приложения полезно знать, что такое критическая секция. Но даже он не обязан знать, что находится у нее внутри. Программиста под винду вопрос «чем отличается обычный мьютекс от рекурсивного» введет в ступор. А программера под линух в такой же ступор отправит вопрос про отличие мьютекса от критической секции.
Должен ли программер под винду знать терминологию линуха и наоборот? Должен ли программер знать о редких багах компилятора?
На «простые» вопросы отвечать сложно, с одной стороны, потому, что о многих базовых и фундаментальных вещах просто забываешь, потому что давным давно на автомате их выполняешь, а, с другой, потому что подвох ищешь. Ибо «не будут на собеседовании спрашивать, сколько будет 2+2 в десятичной системе».
И почему-то после подобных вопросов ощущение остается, что люди не меня интервьюируют, а самоутверждаются.
А, в третьих, речь шла о том, что такие вопросы часто задаются там, где они нафиг не нужны. Или специально так формулируются, чтобы стать непонятными. Я понимаю, что разработчику многопоточного приложения полезно знать, что такое критическая секция. Но даже он не обязан знать, что находится у нее внутри. Программиста под винду вопрос «чем отличается обычный мьютекс от рекурсивного» введет в ступор. А программера под линух в такой же ступор отправит вопрос про отличие мьютекса от критической секции.
Должен ли программер под винду знать терминологию линуха и наоборот? Должен ли программер знать о редких багах компилятора?
На «простые» вопросы отвечать сложно, с одной стороны, потому, что о многих базовых и фундаментальных вещах просто забываешь, потому что давным давно на автомате их выполняешь, а, с другой, потому что подвох ищешь. Ибо «не будут на собеседовании спрашивать, сколько будет 2+2 в десятичной системе».
И почему-то после подобных вопросов ощущение остается, что люди не меня интервьюируют, а самоутверждаются.
Ну вот из подобного развёрнутого ответа можно уже сделать какие-то выводы. Можно задать более конкретный вопрос, с учётом того, что вы сказали. Собственно об этом и написано в статье.
Кстати, из реакции на ваш ответ, вы тоже можете сделать свои выводы. Для этого собеседования и проводятся.
Кстати, из реакции на ваш ответ, вы тоже можете сделать свои выводы. Для этого собеседования и проводятся.
Кстати, насчет самоутверждения… знаете как бывает, я несколько раз был наблюдателем на интервью в которых человек который собеседует, понимая что канидидат overqualified и не подойдет, всё равно продолжал разговоры и выяснял детали работы разных библиотек (ну для собственного развития).
Гм, специально полез смотреть разницу между крит. секцией и мьютексом, честно говоря забыл эту разницу.
А вот такой хитрый вопрос — основываясь на этой разнице — сколько раз можно можно открыть крит секцию, и сколько раз можно открыть мьютекс.
А вот такой хитрый вопрос — основываясь на этой разнице — сколько раз можно можно открыть крит секцию, и сколько раз можно открыть мьютекс.
Если человек знает, что крит. секция это структура, которая ведет подсчет блокировок и внутри юзает мьютекс, то он всё ответит нормально
Вообще то, критическая секция — секция кода, в которой в один момент может находиться не более одного процесса. И это уже точно никак не структура :)
Почитайте пожалуйста wm-help.net/books-online/book/59464/59464-27.html, раздельчик «Критические секции: важное дополнение».
И еще, «механизм критической секции» работает только внутри одного процесса, не используя ядровой мютекс. Увольняйтесь.
Когда секция ждет, она упирается в объект ядра, с высокой долей вероятности именно в неименованый мъютекс. Прежде чем зайти упереться в мъютекс проверяются данные структуры о занятости секции, этим и избегается контекст-свитч при незанятой секции.
Да нет, всё-же увольняйтесь.
Джефри Рихтер, Microsoft Press, «Windows для профессионалов», глава 8, стр. 199:
"… Преимущество критических секций в том, что они просты в использовании и выполняются очень быстро, так как реализованы на основе Interlocked-функций."
Джефри Рихтер, Microsoft Press, «Windows для профессионалов», глава 8, стр. 190:
"… Как же работают Interlocked-функции? На компьютерах с процессорами семейства х86 эти функции выдают по шине аппаратный сигнал, не давая другому процессу обратиться по тому же адресу памяти..."
Никакой ереси и внутренних мьютексов. Как такое вообще могло придти в голову?
Джефри Рихтер, Microsoft Press, «Windows для профессионалов», глава 8, стр. 199:
"… Преимущество критических секций в том, что они просты в использовании и выполняются очень быстро, так как реализованы на основе Interlocked-функций."
Джефри Рихтер, Microsoft Press, «Windows для профессионалов», глава 8, стр. 190:
"… Как же работают Interlocked-функции? На компьютерах с процессорами семейства х86 эти функции выдают по шине аппаратный сигнал, не давая другому процессу обратиться по тому же адресу памяти..."
Никакой ереси и внутренних мьютексов. Как такое вообще могло придти в голову?
К стати, перечитал тут Рихтера — мы (как обычно в спорах) оба были неправы :).
Вы — в том, что «когда секция ждет — она упирается в объект ядра». Она упирается в спин-блокировку, которая работает в режиме пользователя. А только потом уже может уйти (или не уйти) в блокировку на уровне ядра. Причем и Рихте и МСДН говорят, что чаще всего не уйдет. И еще, если даже уйдет, то не в блокировку на уровне использования мьютекса, а на ожидания объекта «событие» (ивент).
А я был не прав в том, что думал, что оно в ядро вообще никогда не уйдет. Уйдет. На однопроцессорным машинах вообще всегда уйдет, на многопроцессорных — очень редко, но тоже может уйти.
Вы — в том, что «когда секция ждет — она упирается в объект ядра». Она упирается в спин-блокировку, которая работает в режиме пользователя. А только потом уже может уйти (или не уйти) в блокировку на уровне ядра. Причем и Рихте и МСДН говорят, что чаще всего не уйдет. И еще, если даже уйдет, то не в блокировку на уровне использования мьютекса, а на ожидания объекта «событие» (ивент).
А я был не прав в том, что думал, что оно в ядро вообще никогда не уйдет. Уйдет. На однопроцессорным машинах вообще всегда уйдет, на многопроцессорных — очень редко, но тоже может уйти.
Ох, не хотел бы я работать в компании, которая _так_ выбирает сотрудников.
Говорят, у великих математиков часто бывают проблемы с арифметикой. А выпускники математических классов часто испытывают сложности с решением задач из учебника геометрии за 7 класс.
Это я к тому, что грамотный человек может и не помнить примитивные вещи, потому что или понимает их интуитивно, или давно научился обходить.
Я последний раз с дедлоком сталкивался году в 2001, наверное. Хватило одного раза. Сейчас в компании мы используем одну небольшую, но чертовски эффективную библиотеку, применение которой устраняет проблемы синхронизации потоков как класс. Поэтому мне сейчас нарисовать схему дедлока было бы, хм, не так и просто, понадобилось бы время подумать. Я, видимо, плохой специалист.
Аналогичные возражения про IUnknown.
Про сравнение строк уже говорили. В debug и release режимах результат может отличаться. Вы бы еще попросили результат i++ + i++ + i++ предсказать.
На интервью очень часто сразу видно, стоит ли тратить на человека время. Кроме того, при поступлении на работу обычно принято писать резюме, а перед собеседованием- это резюме читать. А иногда к собеседованию не только резюме, но и тестовое задание имеется. И план интервью всегда можно скорректировать. За 10 минут можно проверить, читал ли человек Страустрапа, но понять, сможет ли этот человек работать в вашей команде- невозможно. Лично для меня это гораздо более важно. Можно сэкономить час на собеседовании, и взять человека, из-за которого половина команды разбежится.
Говорят, у великих математиков часто бывают проблемы с арифметикой. А выпускники математических классов часто испытывают сложности с решением задач из учебника геометрии за 7 класс.
Это я к тому, что грамотный человек может и не помнить примитивные вещи, потому что или понимает их интуитивно, или давно научился обходить.
Я последний раз с дедлоком сталкивался году в 2001, наверное. Хватило одного раза. Сейчас в компании мы используем одну небольшую, но чертовски эффективную библиотеку, применение которой устраняет проблемы синхронизации потоков как класс. Поэтому мне сейчас нарисовать схему дедлока было бы, хм, не так и просто, понадобилось бы время подумать. Я, видимо, плохой специалист.
Аналогичные возражения про IUnknown.
Про сравнение строк уже говорили. В debug и release режимах результат может отличаться. Вы бы еще попросили результат i++ + i++ + i++ предсказать.
На интервью очень часто сразу видно, стоит ли тратить на человека время. Кроме того, при поступлении на работу обычно принято писать резюме, а перед собеседованием- это резюме читать. А иногда к собеседованию не только резюме, но и тестовое задание имеется. И план интервью всегда можно скорректировать. За 10 минут можно проверить, читал ли человек Страустрапа, но понять, сможет ли этот человек работать в вашей команде- невозможно. Лично для меня это гораздо более важно. Можно сэкономить час на собеседовании, и взять человека, из-за которого половина команды разбежится.
Поведайте пожалуйста миру о сей «серебряной пуле» многопоточного программирования, а хотя возможно эта библиотека справляется с вашими задачами.
И ещё раз, я не задаю вопросов на выявление читал ли человек Рихтера, Страуструпа или Александреску, я пытаюсь прощупать фундамент его знаний. Насчет математиков — тоже не отнесу к своей статье, у меня есть жизненный принцип, его я применяю с своей команде и рекомендую всем: «Кто не делает ошибок, тот ничего не делает!», поэтому я лоялен к идиотским ошибкам в коде или опечаткам. Когда ты показываешь ошибку программеру и он бьет себя ладошкой в лоб и говорит: «А! Точно! Как же я это упустил» — это хорошо, когда он смотрит тупо на тебя и говорит: «Блин, а я и не знал что так делать нельзя» — это плохо.
И ещё раз, я не задаю вопросов на выявление читал ли человек Рихтера, Страуструпа или Александреску, я пытаюсь прощупать фундамент его знаний. Насчет математиков — тоже не отнесу к своей статье, у меня есть жизненный принцип, его я применяю с своей команде и рекомендую всем: «Кто не делает ошибок, тот ничего не делает!», поэтому я лоялен к идиотским ошибкам в коде или опечаткам. Когда ты показываешь ошибку программеру и он бьет себя ладошкой в лоб и говорит: «А! Точно! Как же я это упустил» — это хорошо, когда он смотрит тупо на тебя и говорит: «Блин, а я и не знал что так делать нельзя» — это плохо.
К стати да, очень интересно узнать о «одну небольшую, но чертовски эффективную библиотеку». Тут, блин, на многопоточном программировании ломаются тысячи копий, модифицируются компиляторы и процессоры, разрабатываются специально новые языки программирования, статьи в MSDN сотнями пишутся, в институте меня почти семестр этому учили…
А, оказывается, есть библиотека, раз и навсегда решившая проблему дедлоков. Ссылку в студию.
А, оказывается, есть библиотека, раз и навсегда решившая проблему дедлоков. Ссылку в студию.
Ссылки не будет, поскольку собственная разработка компании и за ее пределами не распространяется. Как справедливо заметил crashdumper, с нашими задачами (а это графика, звук, сеть, интерфейс- и все в одном проекте) она справляется. И- да, вы правы, чтобы ее написать, пришлось сломать тысячи копий, модифицировать некоторые стандартные библиотеки, разработать с нуля архитектуру, прочитать сотни статей в msdn и еще несколько лет учиться.
Я использую примерно такой же метод, вполне успешно. Особенно если проанализировать ответы разных кандидатов на один и тот же тест. Главное — придумать простые, но не тупые вопросы :) Ну и не ограничиваться только ими, конечно.
Кстати, на каждой серии собеседований всегда появляется (как минимум один) человек, который начинает с первого вопроса ржать в голос: «Да это же ведь детский сад, правда, вы издеваетесь!» Ответы таких крутых парней всегда ниже среднего.
Кстати, на каждой серии собеседований всегда появляется (как минимум один) человек, который начинает с первого вопроса ржать в голос: «Да это же ведь детский сад, правда, вы издеваетесь!» Ответы таких крутых парней всегда ниже среднего.
о сравнении строк как указателей — это не совсем бред, это просто ответ на вопрос — а не одна ли и та же строка word1 и word2
Хех, вопрос про управляемый код — квинтэссенция всего интервью. Нужно ли .NET разработчику знать конкретно это определение? Какой процент из разработчиков залезает так глубоко, чтоб это вообще стало важно?
По моему опыту, значительную часть неподходящих кандидатов можно отсеять простым вопросом — что ты сделал на предыдущем месте работы? И если человек начинает отвечать в духе «Я делал… » и идет большой список процессов и нерешенных задач без акцента на результата — это «программист в тапках». Ничего завершить не может и не нацелен на результат. Будет делать всю жизнь то, что другой сделает за 2 месяца. И за всю жизнь не сделает.
А вам не попадались экземпляры, которые на такой вопрос начинали длинную, минут на 10-15, руладу о своих программерских приключениях подмешивая туда как можно больше аббревиатур, пытаясь напрочь забить вам слуховой канал восприятия и полностью сбить вас с толку? И потом этот клубок вам долго распутывать цепляясь за мелкие вещички которые вам удалось разобрать в бесконечном потоке слов.
Каким образом такие личные качества и проявления, как «командность, лояльность к компании и профессиональные навыки» (статические характеристики) оказались вдруг KPI — ключевыми показателями эффективности деятельности (динамическими характеристиками человека в конкретном контексте)?
И какое это имеет отношение к дальнейшему тексту статьи?
И какое это имеет отношение к дальнейшему тексту статьи?
потому что по командности мы «примеряем» человека к нашей команде, пытамеся оценить как он туда впишется и насколько эффективно будет взаимодействовать с остальными членами, аналогично с лояльностью а к проф навыкам я для их динамичности прибавлю ещё и обучаемость.
К тексту статьи — на правах лирического отступления, ну и ещё из-за того что основной темой статьи является экономия времени на собеседованиях, ну и отступление про KPI было про то-же.
К тексту статьи — на правах лирического отступления, ну и ещё из-за того что основной темой статьи является экономия времени на собеседованиях, ну и отступление про KPI было про то-же.
Половина вопросов автора — на знание определений, которые вовсе не являются определяющими реальных проектах. На мой взгляд, такие вопросы как раз беда собеседований: они выявляют энциклопедиста, человека способно долго держать в памяти красивые, но часто бесполезные для практики знания. Как вы хотите с помощью таких вопросов выяснить творческие способности претендента, для меня загадка
Уже писал и ещё раз повторю, внимательнее читаем то что в статье помечено как Profit, мой коментарий-разъяснение: «Я не требую энциклопедических знаний, я смотрю на то что мне человек отвечает». Например, тот-же вопрос по объектам ядра, челоек, много лет успешно программивший малтитрединг обильно пользовался допустим эвентами и критическими секциями. Я не буду заканчивать интервью, если он не вспомнит про семафоры, я дальше просто спрошу с какими проблемами он сталкивался в подобной работе. Если человек упоминает критические секции и мъютексы — то я спрошу про их различие. Если человек программил базы данных, то я неприменно попытаюсь у знать о том как он пользовался транзакциями и т.п.
Это вопросы взятые не из книг, это вопросы реальной жизни, непонимание которых в короткой перспективе не несет особых проблем, но чревато страшными поседствиями в будущем.
Примеры? ловите:
1. Человек не знающий различий между мъютексом и крит. секцией может везде вам в коде напихать мъютексов. А потом вы будете сидеть неделю с Intel VTune в поисках того, почему пограмма так долго живет «в ядре».
2. Человек который не умеет пользваться IUnknow, а также шаблонами (типа ATL) для управления наследниками IUnknown вам наплодит кучу AV в коде когда пойдут обращения к объектам которые уже давно удалены. Или наоборот будут утечки памяти.
3. Человек, который не умеет работать с указателями в C++ вам наваяет столько проездов по памяти, что век будете его матом вспоминать.
Это вопросы взятые не из книг, это вопросы реальной жизни, непонимание которых в короткой перспективе не несет особых проблем, но чревато страшными поседствиями в будущем.
Примеры? ловите:
1. Человек не знающий различий между мъютексом и крит. секцией может везде вам в коде напихать мъютексов. А потом вы будете сидеть неделю с Intel VTune в поисках того, почему пограмма так долго живет «в ядре».
2. Человек который не умеет пользваться IUnknow, а также шаблонами (типа ATL) для управления наследниками IUnknown вам наплодит кучу AV в коде когда пойдут обращения к объектам которые уже давно удалены. Или наоборот будут утечки памяти.
3. Человек, который не умеет работать с указателями в C++ вам наваяет столько проездов по памяти, что век будете его матом вспоминать.
Творческие способности претендента тяжело выявить на собеседовании, для этого можно и нужно использовать испытательный срок. Конечно материал из статьи не подойдет если вы набираете в компанию джуниоров-студентов, которых будете обучать и растить (т.е. у вас на это есть время и деньги) я описал подход для поиска конкретных профессионалов на конкретные должности в софтверную компанию на существующий или новый проект который требует быстрого входя для получения отдачи.
По моему опыту самые большие проблемы возникают как раз тогда, когда работодатель задает вопросы, которые, как он думает, являются элементарными. Например, я знаю пару классных Java-программистов, которых ставил в тупик вопрос «Назовите методы класса Object».
И такие «простые» технические вопросы не позволяют оценить нетехнические критерии — исполнительность программиста, умение выдерживать сроки, умение учиться, коммуникабельность и т.д. и т.п.
И такие «простые» технические вопросы не позволяют оценить нетехнические критерии — исполнительность программиста, умение выдерживать сроки, умение учиться, коммуникабельность и т.д. и т.п.
А я и не считаю вопрос «Назовите методы класса Object» простым, я также как и вы считаю его книжным, не элементарным и тоже думаю что на практике знать все методы какого-нибудь класса — это ненужно и это вообще утопия. А вот знать для чего нужен «Object» — я думаю важно.
А про сроки, коммуникабельность и т.д. и т.п. я писал, в рамки статьи это не входит и это вопросы которые решаются уже после первичного отсева по техническим навыкам.
Писать «найм» вместо «наем» — это как писать «зайц» вместо «заяц».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Найм персонала: О важности примитивных вопросов