Как вы берете интервью у кого-то с большим опытом, чем вы? [закрыто]

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

Может ли кто-нибудь порекомендовать несколько технических вопросов для интервью, которые являются хорошим средством для оценки навыков программирования более высокого уровня, но все же остаются теми, которые я могу понять?

Я бы сказал, что я прошел младший. уровень программиста, но далеко не старший. Большая часть того, что я сделал, - это создание небольших приложений (веб-и настольных), некоторые из них довольно сложные, но все они предназначены для использования не более чем несколькими пользователями. Я чувствую, что у меня есть приличное понимание большинства концепций программирования и я могу учиться / учить себя чему угодно, но мне не хватает опыта. Мой босс любит говорить мне: «Ты не знаешь, чего не знаешь».

В частности, мы хотели бы, чтобы с кем-то, кого мы нанимаем, у нас был опыт (которого у меня нет), это: многоуровневая разработка, многопользовательская среда, разработка крупномасштабных приложений, двусторонний обмен сообщениями, общие сеансы и многопоточность / BackgroundWorkers.

ОБНОВИТЬ:

В ответ на комментарий Тора, приведенный ниже, мы наняли кого-то несколько месяцев назад, и я думаю, что все прошло отлично. Я многому учусь, не только в области кодирования, но и в таких вещах, как шаблоны проектирования, архитектура программного обеспечения, документация и то, как другие крупные группы разработчиков выполняют свои задачи. Не всегда легко заставить кого-то прийти и указать лучшие способы сделать то, что вы сделали, но если вы можете проглотить свою гордость и быть готовыми попробовать что-то новое, вы можете многому научиться.

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

Ты не можешь

Вместо этого я бы предложил вам прийти на собеседование со списком проблем, которые у вас есть сегодня , и спросить его, как он их решит .

Это очень интересный метод по следующим двум причинам:

1. Это бесплатная консультация . Даже если вы не нанимаете парня, он может предложить хорошие решения ваших проблем .

2. Если он приходит с интересными решениями , он решает проблемы . Тот парень, которого вы хотите нанять.

Используйте свой возраст в качестве преимущества.

Я взял интервью у тонны людей, которые старше меня. Я выбираю технологию , что я действительно знаю очень хорошо , и сказать им , что я слышал о технологии X, но никогда не использовал его. Я прошу кандидата дать мне общее представление о технологии и о том, как они использовали ее в проекте.

Это работает на удивление хорошо. Прежде всего, если кандидат использует только эту Технологию X в качестве модного слова в своем резюме, то его объяснение не будет иметь смысла. Кроме того, если они не могут дать вам хороший, конкретный пример того, как они использовали эту технологию в своих прошлых проектах, у вас есть большой красный флаг прямо здесь.

Я взял интервью у кого-то, кто имел опыт Java-Spring. Я использовал Spring в своей предыдущей работе, и одной из главных особенностей Spring является Dependency Injection. Я сказал кандидату, у которого я взял интервью, что я слышал о Spring и никогда не использовал его. Он начал болтать снова и снова, но не мог сказать мне, где он использовал Spring AOP, и не мог объяснить мне инъекцию зависимостей, даже после того, как я явно спросил, увидев эти вещи в его резюме. Он просто сказал мне, что они действительно крутые, и там есть чему поучиться и т. Д. И т. П. На самом деле выясняется, что он не знал Джека ... и я был единственным, кто это понял. младший член команды разработчиков.

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

Помните, что, поскольку у них больше опыта, чем у вас, они могут быть не лучшим разработчиком, чем вы. Фраза «Один год опыта повторяется n раз». приходит, потому что вы видите, что это происходит в промышленности. Таким образом, ваша первая задача во время собеседования должна состоять в том, чтобы установить, что у них действительно есть соответствующий опыт, и они могут представить себя кем-то, кто знает, что они делают. Точно так же, тот факт, что у кого-то был опыт работы в отрасли n лет, не означает, что он обладает огромным опытом работы с данным языком, библиотекой или структурой, поэтому они могут время от времени приходить к вам, задавая вопросы, пока учиться чему-то.

Далее, помните, что хороший старший разработчик - это тот, к кому вы должны обратиться и спросить о чем-то, с чем у вас возникли проблемы. Это хорошее время, чтобы задать им несколько вопросов о дизайне, по которым у вас возникли проблемы, и посмотреть, как они реагируют и в чем их объяснение. Видели ли они что-то похожее раньше, делают ли они обоснованное предположение, основываясь на своем опыте, читали ли они статью онлайн или в журнале?

Наконец, еще одна вещь, на которую стоит обратить внимание, это то, как они подходят к отладочному коду. Исходя из своего собственного опыта, я обнаружил, что независимо от языка определенные методы отладки имеют тенденцию применяться универсально. Приведя кандидату пример одной из наиболее эзотерических ошибок, с которыми вы столкнулись, и попросите их показать вам, как они подошли бы к этой ошибке. У них есть некоторое понимание проблемы, которая не сразу очевидна?

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

Мне очень нравится ответ « Использовать свой возраст как преимущество» , и я бы предложил нечто подобное:

Используйте свой низкий уровень опыта в качестве преимущества

Этот человек, вероятно, станет вашим боссом или наставником, поэтому задавайте вопросы таким образом, чтобы вы могли выяснить, может ли этот человек вас наставлять.

Задавайте сложные вопросы, которые можно сделать намного проще или которые включают в себя слишком сложные проблемы. Если он / она хоть сколько-нибудь хорош, он / она не только решит, попытается ответить на вопрос / решить проблему, но и реально дойдет до реальной проблемы, показывая вам недостатки в вашем вопросе. Если ему / ей удается сделать это вежливо, не запугивая вас, он / она является хранителем.

Действительно значимым является то , что вы убедитесь , что он правильный вид опытного разработчика за то , что вам нужно.

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

Я должен был сделать это несколько раз. Я научился делать это поэтапно.

1. Начните с тех же вопросов, которые я задаю выпускникам колледжа. Я сделал это, потому что позиция, на которой я проводил техническое интервью, была позицией программирования, где мы ожидали, что разработчик будет практиковаться в коде, и я хотел убедиться, что кандидаты могут программировать. Только с одним исключением ни один из кандидатов не мог - они были хуже любого из выпускников колледжа. Все они были на руководящих должностях слишком долго.
2. Для кандидата, прошедшего базовый тест на знание кода, у меня возникли более общие вопросы типа «как бы вы справились с X-сценарием». Например, если вы используете веб-сервисы в своем проекте, подумайте над интересным вопросом о веб-сервисах и спросите кандидата, как он решит его. Я не рекомендовал бы, чтобы это было чем-то, над чем вы сейчас работаете напрямую, в основном из-за проблемы интеллектуальной собственности и фирменных данных компании. Не выдавай это!
3. Проведите время, спрашивая кандидата о материалах в его резюме. Это важно. Вы можете узнать о его или ее лучшем и худшем опыте команды, опыте супервизора и так далее. Попытайтесь понять стиль работы человека, чтобы видеть, подходит ли он или она в вашу команду.

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

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

1. Подбор по резюме или рекомендации агентства.
2. Тест на способность (объединение таких вещей, как FizzBuzz , strdup () / isAlpha (), OOD и т. Д.)
3. Телефонное интервью (для быстрого исключения, если они плохо общаются)
4. Личное интервью
5. Письменное упражнение по кодированию
6. Познакомьтесь с некоторыми членами команды.
7. Для опытного человека, который подразумевает более высокий риск и более высокие затраты, допустимы дополнительные раунды собеседований, но вы должны четко сообщить им, где они находятся в процессе (т.е. это 1 из 3 раундов собеседования).

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

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

Вы можете нанять двух опытных инженеров:

1) Соответствующий отраслевой опыт

Это человек, с которым вы можете взять свой список текущих проблем и обсудить, как они могут подойти к этим проблемам. Вы должны оценить их уровень понимания каждой предметной области в вашей отрасли. Поскольку вы работаете в этой отрасли, вы можете сказать «тупой» ответ из «хорошего» ответа и, вероятно, также можете найти «опытный» ответ. В отличие от других ответов, я бы не ожидал, что они действительно решат ваши текущие проблемы - это произойдет, когда вы их наняли, - но вам нужно, чтобы они убедили вас, что могут, как только начнут.

2) Нет соответствующего отраслевого опыта

Таким образом, этот кандидат, возможно, меняет отрасль, но имеет хороший опыт в базовых технологиях / платформах / навыках, которые вам нужны. Углубитесь в эти вопросы, но не ожидайте, что они смогут найти решения для проблем, специфичных для конкретной области, хотя вы могли бы просто обсудить их. Например, если вашей компанией является Facebook, а человек, с которым вы беседуете, неравнодушен к PHP и C ++, было бы нереально ожидать, что они узнают обо всех подводных камнях огромных серверных ферм (если только они не заявят об этом в своем резюме).

Вещь, которую я не видел в явном виде: «Вы хорошо знаете технологию X, и это звучит очень интересно. Не могли бы вы объяснить это мне через пять минут?»

Поскольку от вас, скорее всего, ожидают, что вы сможете поддерживать код, исходящий от нового человека, крайне важно, чтобы он или она могли эффективно и хорошо объяснить его другим программистам. Считайте, что это навыки общения.

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

Если человек не может общаться устно, он или она, скорее всего, пишут код только для компилятора, а не для сопровождающего.

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

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

определенно выбери себе мозги в интервью о реальных проблемах и технологиях, которые ты в настоящее время имеешь или собираешься использовать

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

вы не берете интервью у своего будущего босса, вы берете интервью у своего будущего наставника. Не выбирайте того, кто знает все ответы, но не может научить

Возьмите кучу проблем, которые вы уже решили. Опишите ему, что было сделано для решения проблемы (оставьте это от третьего лица; вы не хотите ставить здесь под угрозу свое личное эго). Спросите его, что он сделал бы «по-другому». Вы должны быть в состоянии, основываясь на том, что он предлагает, понять, было бы это лучше или хуже, концептуально, чем то, что вы сделали.

Я настоятельно рекомендую вам прочитать книгу «Умный и добившийся цели: краткое руководство Джоэла Спольски по поиску лучших технических талантов» .

Я никогда никого не нанимал, но иногда, когда я был интервьюируемым, я хотел, чтобы у некоторых идиотов, которые знали только о модных словах и брали у меня интервью, была раскрыта линия рассуждений в этой книге. Текст очень плавный и приятный для чтения.

И нет, я не делаю рекламу только потому, что этот сайт от автора книги. Книга действительно замечательная, и я буду рекомендовать ее всем, кто имеет возможность нанимать ИТ-специалистов, особенно тем, кто не разбирается в технологиях. В настоящее время очень часто встречаются нетехнический руководитель проекта или начальник.