Обычно по работе с БД (oracle) + php. Три задания.
Одно из последних заданий, например было такое: Написать на php скрипт, который парсит список городов РБ из вики, сохраняет его в БД и выводит первую десятку городов с самым большим населением.
Ну тут не угадаешь. Хотя претендент вчера был уже немного в стрессовом состояни, когда пришел. Ну мы спросили насколько он оценивает свои знания C++, претендент сказал 7 из 10. НУ я спросил про RAII (я думал это простой вопрос) - и понял что напугал досмерти (хотя в общем для нашей команды сразу стало no go). Мой коллега сильно снизил уровень вопросов и начал спрашивать про паттерны. Там все стало лучше и диалог пошел.
Для себя понял что следующие разы буду начинать с простеньких вопросов и попробую больше примеров давать.
Паттерны много кто знает, если человек с плюсами знаком, то он знает что такое RAII, если нет - скорее нет. Надо было любимую тему vertexua спросить - DI & IoC :)
Вообще слишком короткое интервью у нас устраивают, пожалуюсь нашей HR'ке. Пусть длиннее делает, а то мой список из 14 пунктов, который мы набреинштормили с коммандой почти не пригодился.
Вообще слишком короткое интервью у нас устраивают, пожалуюсь нашей HR'ке. Пусть длиннее делает, а то мой список из 14 пунктов, который мы набреинштормили с коммандой почти не пригодился.
Полюбопытствую. Если первыми двумя пунктами оказались RAII и pattern'ы, то что дальше? Active Object, Reflection, циклы на шаблонах?
Как не вогнать в стресс и ступор претендента на должность, задавая ему вопросы по программированию?
Помнишь поговорку про проблемы индейцев и шерифа? В ней ответ на твой вопрос. При собеседовании непонятного кента, некоторый стресс более чем уместен и позволяет немного увидеть реального человека под маской претендента.
По темам: raii (я думал развернуть тему). shared/unique_ptr и где их использовать и где нет. TDD. Vector, list, deque, stl алгоритмы. Синхронизация. Колбэки, лямбды, обсервер. Кодировки (utf8 vs. utf16 vs. utf32 (vs koi8r) :D) и т.п.
я помню в универе баловался с 1цэ. причем баловался на плюсах, ибо rainbow (или как ее там). но даже это ушло куда-то «в продакшн», а не на гитхаб. цели вести гит хаб тогда не было, да и сейчас не особо.
Ну, если вы и работаете в стрессовых условиях, то позволит. Только не реальное (сколько развелось любителей истины, лел), а как поведет себя человек в стрессовых условиях.
А можно сэкономить своё время и нервы человека, и дать ему задачу, которая позволит раскрыть его умение применять эти технологии, навыки и компетенции. В конце концов, работа в чём будет заключаться? В рассказах про паттерны или в написании кода?
Я за последние пару месяцев проходил кучу собеседований, и в первый раз в жизни встретился с некоторыми паттернами, которые я совершенно неприемлю.
Даже такая крупная контора, как новелл, страдала этой, извините, хернёй.
Собственно, проблема: звонит по телфону девушка для изначального собеседования, бла бла бла, познакомились, принюхались, и тут девушка начинает.
«А теперь технические вопросы. А что делает [команда top | оператор lambda в питоне | еще какая-то чушь ]». Я отвечаю, девушка «подождите, помедленнее, я записываю».
Имхо, это полный треш, даже без учета глупости задаваемых вопросов. Теория, отскакивающая от зубов в интервью по телефону? Шиза.
Вместо этого, лично я бы предпочел тестовое задание на пару часов, отправляемое мне по емейлу после изначальной встречи.
В то же время, прекрасно проведенное интервью в компании, в которой я теперь работаю - состояло из 3 частей - мы поговорили о компании, что делают, зачем и т.п., потом меня спросили про то, в каких проектах я участвовал и могу ли показать их вживую, потом они неделю думали и попросили приехать еще раз с ноутом. На месте попросили показать код каокго-нибудь проекта, с которым я работал в последнее время, и объяснить что это за проект и зачем, плюс показать git history. Показал, поговорили еще раз, меня пригласили. Все. Имхо, это было идеальное интервью для меня, как для кандидата.
Как не вогнать в стресс и ступор претендента на должность, задавая ему вопросы по программированию?
это сложно если честно. проще всего дать задачу которая может вогнать в ступор, и если человек все-таки подвис - сказать мол «ладно, пофиг» и дать совсем простую задачку просто чтоб человек хоть немного поверил в себя и отвис
Как не вогнать в стресс и ступор претендента на должность, задавая ему вопросы по программированию?
Помочь ему наладить контакт с вами, освоиться и расслабиться. Для этого нужно вести себя также расслабленно и дружелюбно.
Мы обычно спрашиваем о том, какой у него самый любимый проект с прошлых мест работы, о котором ему самому было бы приятно поговорить. Просим описать архитектуру того решения (даем лист бумаги и ручку), стараемся вникнуть в рассказ.
Сами рассказываем о работодателе, и (очень поверхностно) о нашем проекте.
Спустя минут 10 такого общения, человек более-менее приходит в себя, и можно начинать задавать содержательные вопросы.
Впрочем, нельзя сказать, что мы офигенно преуспели с этой техникой, поскольку у многих wannabe сотрудников всё равно руки трясутся :D
Угу, всё правильно. Если человек пишет вменяемый код в промышленных объемах, у него всё это на кончиках пальцев. Также можно дать написать какую-нибудь совсем-совсем простую программку (уровня FizzBuzz), ибо бывает лютый неадекват. Писать содержательные программы (тоже неплохо, чтобы отсечь чистых теоретиков) лучше давать в качестве домашнего задания, из расчета чтобы задание можно было добротно сделать за 4 часа или меньше. Батхерт местного петушья всерьез не воспринимай =)
Забавно, что за всеми этими каверзными вопросами на собеседовании, тестами iq, вопросами о форме люков и тд следует, в случае успеха, обычная монотонная работа, где все эти знания не нужны и никогда не были нужны.