какие вопросы задавать на собеседовании программисту

Справочник по собеседованиям для тех программистов, которые их не понимают

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

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

Собеседование в мировую it компанию

Многие программисты хотят попасть в такие компании, потому что там сухо и тепло (и корпоративные ипотеки под низкие проценты). Поэтому компании просто завалены резюме от кандидатов со всех концов страны (или мира). Чтобы хоть как-то отбирать кандидатов, компании приходят к фильтру по алгоритмическим задачам.

Резюмируем

«Вас много, а я одна!» — кричит нам крупная контора, которую мы дружно закидываем своими резюме. Нам дают сложный, скучный и бесполезный в работе фильтр из задачек. Кто-то проходит, а кто-то — нет (я — нет).

Хотите, чтобы отбор был без задачек? Ну… Давайте сговоримся и будем подавать от всех нас лишь одно резюме в месяц, уверен, тогда уж точно найдется время спросить у кандидата про его прошлые проекты. 🙂

Собеседование в аутсорсную компанию

Давайте сразу проясним: цель любой аутсорсной компании — продать ваше время разработчика задорого, а потом забирать себе часть вашей зарплаты (половину). Это основная бизнес модель.

Ах да, чтобы казаться солиднее, еще можно у кандидата пару задачек на алгоритмы спросить. Ну а что, вон, Яндекс же так делает.

Резюмируем

«А насколько вы — выгодное вложение для перепродажи?» — хищно смотрит на вас контора. Ну а мы же не лыком шиты, да? Хитро улыбаемся в ответ, зубрим все определения перед собеседованием, решаем несколько простейших алгоритмических задачек (обход дерева в ширину, ага), а потом заламываем хорошую цену за свой будущий труд. И возможно, с грустным лицом, компания согласится отдавать вам не меньшую, а большую часть ваших заработанных непосильным трудом денег.

Собеседование в небольшую компанию

В небольших и средних компаниях, которые выпускают свой продукт или занимаются автоматизацией на заказ, обычно нет общих для всех правил отбора новых кандидатов.
Всё зависит от конкретных людей, проблем, фазы луны. Где-то вас попросят решать задачки (потому что так делает Гугл), где-то будет тестирование на знание всех методов библиотек (потому что так делает Люксофт). А где-то вам предложат разобрать ваш код, поспрашивают о ваших предыдущих проектах, и вообще, вы мило побеседуете обо всем на свете на 2 часа, а потом эти ребята станут вашими лучшими коллегами на много лет вперед (слезы умиления).

Резюмируем

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

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

Источник

Проблемы в собеседовании на позицию программиста

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

Преамбула

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

Обычно меня собеседовали два человека: менеджер\босс и программист\технарь. Реже — один, еще реже — трое и более. Задают вопросы они, как правило, из совершенно разных областей, поэтому разделим условно собеседование на тестовое задание, инспектирование софт скиллов и инспектирование технических скиллов.

Тестовое задание

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

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

Проверка софт скиллов

«Расскажите о себе?» — вопрос, вводящий в ступор человека с глубоко-техническим складом ума (будем в дальнейшем называть его конструктор). Конструктор может немного покопавшись в памяти вывалить своё имя, возраст, рост и вес, национальность и цвет глаз, но при этом не поймет какое это все имеет отношение к делу, ведь он пришел продавать свой технический скилл, а не себя. «Что конкретно вы хотите обо мне узнать?» — обычно отвечаю я и наблюдаю разочарование в глазах босса, босс редко любит когда ему отвечают вопросом на вопрос, ведь теперь мячик на его стороне и думать приходится ему. Если бы я мыслил по другому, то конечно, я бы вывалил на него заранее подготовленную смачную историю меня любимого с детальными подробностями того насколько я клёвый, классный и, что самое главное, лучше чем остальные. Но если бы я мыслил по другому, я вряд ли стал бы программистом. Поэтому на ответ «что хотите то и рассказывайте» я начинаю тупо перечислять где я работал и какими проектами занимался, плюс какие технологии использовал, чем совершаю очередную ошибку, поскольку всё это уже расписано в резюме и не вызывает ничего кроме скуки. Ведь словами невозможно донести тот объем, вес и значимость, которые я ощущаю в своей голове.

И здесь я делаю допущение: допустим, что программист НЕ ДОЛЖЕН обладать сильными софт-скиллами.

Пойдем от обратного: допустим, что программист ДОЛЖЕН обладать сильными софт-скиллами, тогда — зачем нужен менеджер? Зачем тогда вообще нужна фирма, если я могу пойти на биржу фриланса и найти себе там самостоятельно заказчика? Господин Форд — великий изобретатель прошлого века, он изобрел конвеер, невероятно эффективную вещь, которую, видимо, еще не все научились использовать. В некоторых фирмах просекли эту фишку и вставили между программистами и заказчиками особое звено — менеджеров, по сути являющихся переводчиками с «человеческого» на «программисткий». Задача менеджера — договориться с программистом и заказчиком, задача программиста — «договориться» с кодом. Ожидая от программиста дополнительного повышенного скилла договариваться и коммуницировать, вы отсекаете тех программистов, которые за счет отсутствия этих софт-скиллов освободили в своей голове достаточно места чтобы прокачать скилл разработки гораздо глубже.

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

Оценка быстроты реакции — отдельная ошибка. Мгновенно отвечающие люди на самом деле даже не успевают подумать. Люди же тормозящие с ответом, напротив, погружаются в чертоги разума, тщательно взвешивая все возможные варианты, пока чувствуют что было бы уместно еще немного подумать. Даже если у них сразу появляется подходящий ответ.

Проверка технических скиллов

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

Так что же, реально за 1-2 часа разговоров оценить человека достаточно хорошо чтобы принять правильное решение? Конечно же нет. Самая главная ошибка здесь — точно такая же как и в предыдущей части — задача найти лучшего, а не отсеять подходящих от неподходящих. В результате собеседование превращается из поиска знаний в поиск пробелов, ведь чем больше пробелов найдет собеседующий, тем менее подходит кандидат и тем проще сложить-вычесть-посчитать виртуальные очки. Дополнительная ошибка в том что мы проверяем у кандидата наличие лишь тех знаний, которые знаем сами, полностью упуская из виду те знания, которых не знаем, которые могли бы быть намного более полезными в фирме, чем очередная копия меня.

Особенно скользкое в происходящем то, что превращенное в экзамен инспектирование проверяет не способность кандидата программировать, а его способность объяснить, донести, научить, то есть по сути та же самая проверка коммуникативных способностей в иной плоскости. Я, например, могу быстро и качественно спроектировать нормализованную структуру базы данных или нормализовать уже имеющуюся, но совершенно не в состоянии объяснить словами другому человеку как это делать, потому что когда я нормализую, я не использую русские слова, я использую внутренние знания, приобретенные не на парах в университете, а на «боевом» опыте. Эту разницу скиллов между исполнителем и учителем понимают не все. Другой каноничный пример — путаница в шаблонах проектирования. Я быть может и знаю тот шаблон что вы у меня спрашиваете, но в моей голове он называется по другому и его реализация может немного отличаться.

Особенно мной нелюбимое — инспектирование очень мелких и сверх-специфичных деталей, место которым в Гугле, а не в моей голове. За что отвечает третий параметр в функции пузырьковой сортировки? Организуйте очередь двумя стеками. Как сделать выборку так чтобы не так, а вот так? Конечно, хорошо когда эти детали находятся в голове, программист экономит время, а фирма экономит деньги. Но чего вы никогда не узнаете задавая подобные вопросы — это что лежит у кандидата в голове ВМЕСТО этих знаний, знаний такой низкой ценности. Быть может там глубокое понимание асинхронности, а может навык подката к девочкам на вечеринках, но вопрос задан, время потрачено, собеседование на очередной шаг приблизилось к своему завершению, а вы разведали мало значимого.

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

Есть ли выход?

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

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

Источник

20 вопросов, которые задаются на интервью веб-разработчикам

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

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

1. Какие профессиональные сайты и блоги вы регулярно читаете?
Этот вопрос поможет вам составить представление о том, насколько человек осведомлен об актуальных тенденциях, а также – насколько ему вообще интересна данная тематика. Вы сможете отделить людей, для которых это не только работа, но и хобби, от тех, кто просто пытается гнаться за высокой зарплатой.

2. Что вы предпочитаете – работать в одиночку или в команде?
Ответ на этот вопрос важен в зависимости от предполагаемого рабочего окружения. Если ваш проект подразумевает тесное взаимодействие между разработчиками, очень хорошо, если новый человек будет иметь опыт продуктивной командной работы. С другой стороны, у многих разработчиков всё получается гораздо лучше, если они трудятся сольно. Постарайтесь найти человека, который в этом смысле отвечал бы вашим ожиданиям.

3. Насколько уверенно вы чувствуете себя, если приходится писать HTML «от руки»? (+задание)
Несмотря на то, что человек может написать в резюме, что он эксперт в HTML, на деле может оказаться, что писать на HTML с нуля он и не умеет. Такие люди полагаются на сторонние программы или на то, что всегда смогут подглядеть в мануал. Любой сколько-нибудь стоящий разработчик просто обязан быть в состоянии написать простой HTML-код, никуда не подглядывая. Несложное задание может заключаться в том, что вы чертите схему фейкового сайта и просите написать соответствующий HTML-код. Усложнять не надо – вы должны просто убедиться, что человек в курсе самого главного, а также обратить внимание на такие ошибки, как пропуск тегов и серьезные упущения некоторых элементов. Если кто-то напишет с ним вполне можно попрощаться и позвать следующего кандидата.

4. Что такое w3c?
Это стандарты веб-разработки, в соответствии с которыми (хотелось бы верить) все делается. Не надо требовать цитат по поводу миссии w3c, но человек должен, как минимум, представлять, что это такое.

5. Можете ли вы написать безтабличный XHTML? Валидируете ли вы свой код?
Искореняйте старомодный табличный дизайн! Найдите такого разработчика, который использует элементы HTML так, как они были задуманы изначально. Также бывают разработчики, которые говорят, что могут писать без таблиц, но в реальности – по привычке или из удобства – все равно их используют. Можно нарисовать простое навигационное меню или статью и попросить создать под нарисованное HTML-код. Можно схитрить и представить данные как бы в табличном виде – будет бонусом, если человек догадается, что при таком раскладе таблица как раз вполне уместна.

6. Какой инструмент разработки нравится вам больше всего и почему?
Если человек скажет, что Notepad, вы, наверно, разговариваете не с тем человеком. Такой вопрос не только позволит вам «прощупать» уровень компетентности, но и понять, насколько органично инструментарий соискателя соотносится с тем, что используется у вас.

7. Опишите или покажите, что вы умеете в *nix shell?
Обратите внимание на то, как человек работает без привычного ему интерфейса. Задайте пару вопросов вроде того, как рекурсивно скопировать директорию или как сделать файл доступным для чтения только владельцу. Выясните, с какими операционными системами человек умеет работать.

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

9. Покажите мне ваше портфолио!
Портфолио может многое рассказать о разработчике. Есть ли у него вкус? Что для него более важно – креатив или логика? Важнее всего обращать внимание на солидные, масштабные, ЗАВЕРШЕННЫЕ проекты. Пяток-другой набросков и хакнутых скриптов – признак неопытности и некомпетентности.

10. С сайтами каких масштабов вам приходилось работать?
Ищите разработчика, у которого есть опыт с сайтами сходных с вашим масштабов. Человек, умеющий справляться с большим трафиком и большими размерами, может оказаться беспомощным в простой настройке Apache или оптимизации тяжелых SQL-запросов. С другой стороны, разработчики, которые обычно занимаются мелкими сайтами, могут подмечать вещи, которые их «более крупным» коллегам недоступны. Допустим, речь может идти об элементарной визуальной привлекательности решения.

11. Покажите мне ваш код!
Архаичный HTML или навороченный Ruby on Rails? Неважно! Все равно просите показать образцы кода. Исходники могут многое рассказать о привычках человека, гораздо больше, чем вы думаете. Чистый, элегантный код часто может указывать на методичного, мощного разработчика. В резюме может быть написано, что у человека более 7-лет опыта в написании скриптов на perl, но это может быть 7 лет плохой работы. Также постарайтесь получить много исходников, а не просто кусочки HTML. 20-30 строк к собеседованию подготовить может каждый, вам же важно видеть положение дел в целом. Не надо требовать кода полных работающих приложений, просто он должен отвечать на все ваши вопросы.

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

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

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

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

16. Есть ли какой-нибудь язык, который вас пугает?
Когда проясняется одна загадка, за ней открывается десять других. Если собеседник расскажет вам о своих неудачах, это поможет понять, сколько он на самом деле знает.

17. Время аббревиатур
Некоторые могут заявить, что знание аббревиатур – это чепуха, но есть некоторые такие сокращения, которые должны быть вшиты в мозг разработчика (допустим, HTML и CSS). Это вопрос из серии телефонных, который помогает отсеивать неподходящих людей еще на подступах к вашей компании.

18. Каким браузером вы пользуетесь?
Правильный ответ: всеми. Компетентный разработчик должен быть знаком с понятием кроссбраузерной совместимости, причем — знаком на деле. Ясно, что у каждого есть любимый браузер, который используется для серфинга, но ответ на этот вопрос может помочь плавно перейти к теме кроссбраузинга. Кроме того, если речь идет о должности, связанной с CSS/HTML, полезно поинтересоваться установленными тулбарами.

19. Оцените по шкале от 1 до 5, насколько вам интересны следующие задачи (1 – совсем не интересно, 5 – чрезвычайно интересно)
Предложите список задач на данной позиции. Когда вы увидите рейтинг, это поможет вам понять, насколько человек подходит на место.

20. Какие собственные проекты вы собираетесь продолжать?
Почти у каждого разработчика есть персональные проекты, которыми ему нравится заниматься на досуге. Это еще один вопрос, который помогает отделить страстных разработчиков от тех, кто привык работать строго в режиме с девяти до пяти. Это также хороший вопрос для завершения собеседования (потому что ответ на него обычно легкий и приятный).

Автор перевода — Давиденко Вячеслав, основатель компании MBA Consult.

Источник

Собеседование на позицию разработчика, как оно есть

Доброго времени суток. На данный момент я занимаю должность Senior/Team Lead IOS Developer. Так вышло, что за последний год мне довелось побывать на огромном количестве собеседований, так сказать, по обе стороны баррикад. Поэтому мне бы хотелось поделиться своим опытом и поговорить о том, как, на мой взгляд, надо проводить собеседование, ведь в общей суматохе можно упустить ряд важных моментов, что, впоследствии, может негативно отразиться на качестве собеседования.

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

Заповеди

Заповедь номер раз

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

Заповедь номер два

Ваша задача – выяснить, что данный человек может сделать для Вашей фирмы сейчас и через три месяца, а не то, что он мог сделать год назад.

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

Заповедь номер три

Ваша задача – определить сможет ли человек влиться в команду.

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

То, на что надо обратить внимание

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

Собеседование на junior программиста

Цель – выяснить обучаемость собеседуемого.

Для начала выясните, где человек учился или учится (я сторонник того, что для работы программистом необходимо иметь инженерное образование, так как это позволит вам говорить на одном языке). Бог свидетель, ко мне на собеседование приходили люди из музыкальной консерватории, которые прошли 2-месячные курсы по программированию.
Обучаемость может частично компенсироваться усердием. И тут на помощь приходит система образования. Выясните какой у претендента средний балл, учится он платно или бесплатно. Квадратный зад в программировании пригодится.

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

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

Собеседование на middle/senior программиста

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

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

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

Разумеется, надо иметь в голове список вопросов, которых вы бы хотели коснуться, чтобы направлять беседу в нужное русло. Такой тип собеседования позволит проверить очень важное качество человека – его честность. Был следующий случай. Пришел на собеседование человек, который рассказал, что работал на проекте на ведущих ролях, а также что в его проекте было более 50 таблиц в базе данных, не один десяток миграций и обращения к базе идут в разных потоках и много чего еще. Однако при вопросе, как была организована работа с базой из многих потоков, внятного ответа не последовало (см. заповедь 2). Думаю, всем понятно, что место в нашей компании этот человек не получил.

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

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

Вы должны найти границу знаний собеседуемого, если пробел обнаружен не стоит тратить 10 минут на добивание, лучше двигайтесь дальше. Такой вариант будет приятнее для собеседуемого и продуктивнее для вас. (см заповедь 1).

Если в результате собеседования были даны ответы на все вопросы – грош цена такому собеседованию. Вы не дали собеседуемому в полной мере раскрыть свой потенциал.

Напоследок, коснусь спорного для многих вопроса.«Стоит ли объяснять правильный ответ на вопрос?». На мой взгляд, если человек был близок к решению задачи, ответ может быть оглашен. Однако, если к решению задачи человек не приблизился ни на йоту – смысла что-то ему объяснять я не вижу.

Как вести себя на собеседовании

Заключение

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

Всем удачный поисков и высококлассных специалистов.

Источник