Фахима Уль Хоку, одного из учредителей платформы Educative.
Подборка нескольких наиболее распространённых ошибок, совершаемых кандидатами при прохождении технического интервью.
Как не провалить техническое собеседование
Как со стороны собеседуемого, так и со стороны собеседующего я отметил для себя парочку, по большей части, нетехнических аспектов интервью, грамотное использование которых увеличивает ваши шансы успешно пройти его. Большинство из последующих утверждений основано на моих личных суждениях и ранее совершённых ошибках (да, у меня тоже был такой период в поиске работы под названием «Мы вам перезвоним»).
Основываясь на собственном опыте, я выделил 5 самых распространённых ошибок, которые совершают кандидаты при прохождении интервью.
1. Вы тратите слишком много времени на описание своих прошлых и текущих проектов
Итак, начинается собеседование, и в какой-то момент вам задают вопрос: «Над чем вы работаете в вашей текущей компании?», на что вы тратите следующие 10 минут, описывая ваш проект во всех интимных подробностях.
Как вам кажется, это ваш шанс, чтобы рассказать о том, какую выдающуюся работу вы выполнили за эти 2 года работы над проектом. Вы начинаете описывать настолько мелкие детали, что вас либо перестают понимать, либо вы рассчитываете таким образом протянуть время с целью получить задачу попроще (не выйдет).
В итоге, вместо того, чтобы впечатлить собеседника, вы просто тратите лишние 10 минут, тем самым уменьшая себе время на решение задачи. Интервьюер также и ваш потенциальный коллега, и ему может быть неудобно прерывать вас посередине речи.
Вас спрашивают о текущем проекте для «разогрева». Подразумевается, что вы вкратце опишете суть проекта, чтобы потом собеседник мог плавно перейти к более конкретным вопросам в данной предметной области.
Запомните два момента:
- Как бы вы ни хитрили, задачу на собеседовании вам всё равно придётся решать, но теперь у вас на 10 минут меньше времени на её решение.
- Почти не считается. Вас не наймут, если вы не успели решить задание, но вам «осталось совсем чуть-чуть». Такого попросту не бывает.
Куда бы вы ни шли на интервью, всегда будьте готовы сказать пару слов на следующие вопросы:
- Над каким проектом вы работаете в данный момент?
- Какой аспект вашего текущего проекта вызвал у вас наибольшие затруднения?
- Расскажите о самом сложном баге, с которым вам приходилось иметь дело, за последние полгода.
Итог: Рассчитывайте своё время. Вы не приняты по умолчанию, и у вас есть только 45 минут, чтобы доказать обратное. Если для успешного устройства на работу вы обязаны решить задачу у доски, то вы должны оставить себе как можно больше времени для решения этой задачи.
2. Вы неправильно поняли формулировку задачи
Пример из жизни. Несколько лет назад, проходя собеседование, я выступал с технической презентацией. И так получилось, что каждый раз во время выступления мне давали задачу «Поменять порядок элементов в связном списке на обратный.»
Не знаю, почему, но поначалу я вбил себе в голову, что не знаю, как решить поставленную задачу.
Когда уже четвёртый раз подряд собеседующий заикнулся об обратном порядке элементов в связном списке, я сразу же вышел к доске и за пару минут написал решение. Собеседник улыбнулся, и сказал, что он просил напечатать элементы связного списка в обратном порядке, а не менять сам список. Упс.
Я попытался обратить всё в шутку и сказал, что сейчас напечатаю полученный список, и затем ещё раз поменяю порядок на обратный. Я объяснил ему, почему я так бурно отреагировал на эту задачу, и мы оба рассмеялись. Если я не ошибаюсь, в итоге я всё-таки прошёл на следующий этап отбора.
И хотя для большинства из вас подобного рода ошибки не будут фатальными (так как, надеюсь, вы будете слушать внимательнее, чем я), я до сих пор встречаю кандидатов, которые сразу начинают решать, не до конца разобравшись с условиями. Лучше потратьте лишние 10-15 минут, чтобы проанализировать все аспекты задачи, чтобы потом вам не пришлось переписывать ваше решение по новой.
3. Вы сразу же начинаете писать решение задачи, хотя ещё сами не до конца поняли, как оно выглядит
Познавательный факт: почти все задачи на собеседовании, где от вас требуется написать решение на доске, занимают не больше 20 строчек кода.
А теперь попробуйте выйти к доске и написать 20 строчек кода. Это займёт у вас минуты 2-3, не больше. Следовательно, даже если вы и потратите 30 минут на решение задачи, у вас ещё останется пара минут для написания готового решения.
Но при решении задачи на собеседовании вы начинаете сильно волноваться. Вы лихорадочно начинаете писать решение как можно быстрее. Не стоит. Усвойте для себя, что «накалякать» ответ вы всегда успеете.
Лучше основную часть времени тщательно разберите всю задачу, и потом приступайте к её написанию. Попробуйте протестировать ваш алгоритм. Это также даст возможность собеседующему поправить вас в случае, если вы начинаете делать что-то не так.
4. Сначала вы находите наиболее очевидное решение, а затем начинаете оптимизировать алгоритм
Суровая правда. На собеседованиях от вас ожидают вполне конкретных знаний, поэтому при решении задач подразумевается, что вы уже неплохо знакомы с этой темой и знаете оптимизированный алгоритм. Все вышеперечисленные пункты указывали на то, что не в ваших же интересах тратить время. Поэтому как следует подумайте над решением и над тем, как его можно было бы оптимизировать. Если требуется решение с линейной временной сложностью и требуемым объёмом памяти О(1), то любое решение ниже по производительности приведёт к тому, что вас не возьмут.
5. Вы не проверяете своё решение
Как только вы нашли ответ, попробуйте протестировать его на паре примеров. Это поможет вам самому найти недостатки и недочёты в решении, чтобы собеседующий не указывал вам на них сам. Каждый раз, когда вас вынуждены поправлять, ваши шансы уменьшаются. Также это позволит вам найти и рассмотреть особые случаи в решении вашей задачи. К тому же тот факт, что вы не проверяете своё решение, является для нанимателя тревожным звоночком, поэтому проверьте свой алгоритм, даже если вы на 100% уверены, что всё идеально.
Бонус: Спрашивать, как вы прошли интервью
Возможно, это и не будет иметь негативного влияния на решение о том, нанимать вас или нет, но так вы поставите интервьюера в неловкую ситуацию.
Спасибо за внимание и удачи вам на собеседованиях.
- IT-компании
Я уже достаточно давно провожу технические интервью с кандидатами на позицию Software engineer и на моем счету их имеется несколько десятков. Сегодня я попробую сформулировать основные моменты, которые лично мне, как интервьюеру, кажутся довольно важными.
Советы довольно очевидные (хотя, как показывает практика, бывают и те, кто не знает этих очевидных вещей) и субъективные.
1. Отвечая на общие вопросы помните, что интервьюер может ничего не знать о том, о чем вы говорите
.
Бывает, что в самом начале интервью интервьюер задает общие вопросы - например «Расскажите о проекте Х, над котором вы работали в У» (список проектов берется из резюме) или «Расскажите про самую любимую технологию» или еще что-нибудь такое. Отвечая на этот вопрос очень важно помнить, что вы рассказываете о проекте не себе, а интервьюеру - и ваша задача, чтобы интервьюер вас понял.
Не надо предполагать, что интервьюер очень умный и все знает - он, вероятно, действительно умный, но точно знает далеко не все. И то, что для вас может быть очевидным потому, что вы этим занимались пару лет кряду, для интервьюера может быть совершенно новой областью. И поэтому не стесняйтесь начать с самых основ и время от времени интересуйтесь, понимает ли вас интервьюер.
2. Не гуглите во время интервью.
Бывает такое, что интервьюер задает вопрос, ответ на который вы смутно помните, и если бы только одним глазком взглянуть в википедию… Так вот - не надо этого делать. Стук клавиш обычно довольно неплохо слышен через телефон и ответ, который зачитывается из википедии без особого понимания - тоже довольно несложно отличить. Стоит ли говорить, какое впечатление оставляет у интервьюера такой кандидат?
3. Не врите в резюме.
Есть вещи, которые проверить относительно легко - знание какой-то технологии, например. И вещи, которые проверить сложно - например, если кандидат написал, что он в top 100 на topcoder (это такой сайт, где проводятся соревнования по программированию). Лично я этого на уровне «А под каким ником вы там числитесь?» никогда не проверяю, но от кандидата, который в top 100 на топкодере я жду, что простые вещи он напишет не приходя в сознание (я уже интервьюировала олимпиадников - и по моему опыту так и происходит). И если вдруг окажется, что кандидат пишет код медленно, с кучей ошибок - то это, скорее всего, значит, что либо он очень плохо себя чувствует, либо в резюме он указал неверную информацию.
Конечно, в компетенцию интервьюера не входит оценивать состояние кандидата, но я обязательно упомяну об этом несоответствии в своем отзыве.
4. Не пытайтесь «уболтать» интервьюера.
Если интервьюер задал вопрос - например, «Какая сложность у сортировки пузырьком?» - а вы не помните, то ли это O(N^2), то ли O(N), то ли O(NlogN), то ни в коем случае не надо маскировать свое незнание под кучей фраз, которые вы надеетесь что интервьюер примет за правильный ответ. Интервьюер очень внимательно вас слушает и замечает все попытки невзначай увести его от вопроса, на который кандидат не знает ответа. Лучше просто признаться, что вы точно не помните и подумать вслух - скорее всего вы придете к правильному ответу и так.
5. Говорите и объясняйте. Но не слишком много.
Бывают две крайности - кандидат, который молчит и почти ничего не говорит и даже на вопрос вроде «Расскажите мне, что вы думаете о Х, какие у Х достоинства и недостатки» умудряется ответить максимум одним предложением. И кандидат, который говорит и объясняет все вплоть до последней запятой - «Вот тут я ставлю запятую, потому, что таков синтаксис языка». И первый, и второй тип кандидатов очень сложно интервьюировать - из одних приходится тянуть ответы клещами, а других постоянно обрывать на полуслове.
Объяснений должно быть в самый раз - чтобы интервьюер понял суть, но при этом не чувствовал, что кандидат постоянно хочет сорваться в объяснение тривиальных основ.
6. Тестируйте код сами.
Во время интервью вы написали какой-то код, который по вашему мнению правильный. В этот момент важно этот код протестировать не дожидаясь, пока интервьюер вам скажет «А теперь давайте протестируем код на простом примере 123». Во время тестирования очень важно проверить так называемые corner cases - например, null, пустые строки и массивы, отрицательные числа, ноль - и еще более важно удостовериться, что код действительно работает на простых примерах. Потому что кандидат, который тестирует код, но при этом во время тестирования не замечает очень грубую ошибку, обычно не производит самого лучшего впечатления.
7. Не пытайтесь угодить интервьюеру.
В фильме «Bad teacher» есть один момент - один из главных героев спрашивает другого об акулах:
1: Что вы думаете об акулах?
2: О, акулы это такие ужасные рыбы, я слышал что они едят людей…
1: Но некоторые из них никого не едят, и очень даже милые…
2: О да, это ужасно, что люди истребляют акул, ведь акулы - это вымирающий вид и Бог создал их такими. Они - прекрасные создания…
1: Но ведь они едят людей…
2: Да, да, это ужасно, целые семьи бывают разрушены из-за акул…
Я не помню точно, но суть примерно такая. Так вот, не надо вести «разговор об акулах» с интервьюером. Интервьюер задает вопрос, чтобы узнать, что кандидат думает о том или ином аспекте, а не чтобы услышать, что кандидат с ним в любом случае согласен.
8. Постарайтесь убрать все, что будет мешать вам четко говорить.
Это может показаться очевидным, но я все-таки упомяну - не надо жевать жевачку во время интервью. И кушать тоже не надо. Если у вас есть пирсинг в языке, который имеет обыкновение издавать цокающий звук когда вы говорите, то на время интервью его тоже лучше достать.
Ну и самое главное - вопрос, который интервьюер себе сознательно или подсознательно задает это «Хотел бы я работать в одной команде с этим человеком?». И ответ на этот вопрос складывается не только из знаний и умений кандидата, но и из способности ясно и четко излагать свои мысли, способности слушать и еще многих других мелочей.
Вы уже разместили на объявление на работных сайтах с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать.
У Вас есть продукт, устоявшаяся команда и финансирование. Вы (команда) хорошо работали, и руководство готово заплатить еще денег чтобы нанять человека, чтобы, соответственно, ускорить разработку, повысить качество и иметь возможность тратить ресурсы на технологическое развитие продукта. Вы уже разместили на hh объявление с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать. Знакомая ситуация? Тогда добро пожаловать под кат.
Возможно, ситуация немного утопическая, но многие кейсы также входят в рамки этой статьи. Исключения составляют компании которым «человек нужен вчера» или компаниям которым новый человек вообще не нужен, они просто «наблюдают рынок» и (или) надеются найти «редкого профессионала».
Иными словами, это статья для тех кто хочет вложить деньги и силы в то, чтобы команда стала сильнее.
Для начала заметим, что крайне вредно нанимать человека под сиюминутную потребность. Скажем, сейчас у вас слегка «тормозит» разработка серверной части. Значит ли это что надо нанять server-side программиста? Вообще-то нет. Если у вас достаточно активная разработка, то приоритет разных кусков будет неизбежно меняться. В этом смысле глупо нанимать человека под задачу на ближайший месяц. Ведь месяц пройдет, а человек у Вас останется. И если в этом месяце Вы залатаете дыру в server-side разработке, то в следующем выяснится что server-side пишется быстрее чем клепается интерфейс. И что, в следующем месяце надо нанимать UI-программиста? Или уволить «слабое звено» в server-side? Нет, тут стоит подойти по-другому. Посмотрите, чем Вы занимались раньше в разработке продукта. Расспросите продажи, инвесторов или кто там определяет цели для разработки, и постарайтесь построить картину того что ждет вас, скажем, на год вперед. А теперь представьте, какой человек помог бы Вам работать в прошлом и будущем эффективнее. Надеюсь, Вам представился не один человек. Скорее всего окажется, что можно и тут укрепить команду, и здесь. А если где-то окажется слишком крепко (и соответственно где-то - слишком тонко), то кто-то из существующей команды возможно согласится «переключить» род деятельности.
Итак, Вы набросали несколько портретов «идеальных» кандидатов. Настала пора провести техническое собеседование. Кстати, надеюсь в Вашей компании именно техническое собеседование влияет на решение о найме сотрудников? Часто говорят о компании как о «семье» или о «коллективе где приятно проводить время». Так вот, компания это все таки не семья. И не друзья с которыми вы ходите в боулинг. Конечно, если человек болен клептоманией или проказой то брать его на работу опасно, даже если он лучше всех прошел техническое собеседование. Но не стоит слишком зацикливаться на личных качествах. В принципе, до или после технического собеседования необходимо выяснить, не выкинет ли человек какой-то фокус, и в этом смысле такое «не техническое» собеседование будет иметь роль «порога» - тот кто его не пройдет в компании точно работать не будет, а если пройдет - то не имеет значения будет ли он «душой компании» или просто добросовестным работником. Но это и все, собственно, все остальные решения должны определяться именно техническим собеседованием. Если в вашей компании HR донимают кандидатов вопросами об их карьерных устремлениях и «кем они видят себя через 10 лет» или «почему компания должна нанять вас», то вам еще рано искать технических специалистов. Для начала вам надо найти нового HR.
Но что же спросить на техническом собеседовании? Составить тест? Выяснить что человек делал на прошлом месте работы? Задать каверзный вопрос? Дать задачку с braingames.ru?
Давайте рассмотрим эти варианты по порядку.
Тест может показаться полезной вещью чтобы сэкономить время. Однако хороший тест составить достаточно трудно - на эту задачу саму по себе надо потратить немало времени. Плохой тест может отсеять лишь кандидатов, мало ходящих по собеседованиям и не знающий ответов на «типовые» вопросы. Очень плохой тест может отсеять действительно крутых кандидатов, которые просто занимались немного другими вещами. В целом же тест это просто некоторый первичный фильтр. Вы можете не нанять человека, который не смог ответить на пять банальных по вашему мнению вопросов. Но уж точно не стоит нанимать человека после теста, не спросив у него ни слова.
Чем вы занимались на прошлом месте работы? Ну знаете, тем, чем соискатель занимался на прошлой работе, у Вас он уже заниматься не будет. В принципе можно задать такой вопрос чтобы нащупать тему для беседы. Но, честно говоря, это выглядит пустой тратой времени. Приведу пример из своей практики.
Чем Вы занимались на прошлой работе?
- Ну там была сложная система моделирующая систему городских коммуникаций с поиском оптимальных маршрутов и (…)
- Что такое алгоритм Дейкстры?
- Эмм, да, и что-то такое я слышал.
Итого - что мы узнали? Да ничего. Какой-то сложный проект. Толком не понятно что за проект, что именно делал этот сотрудник, что он в итоге научился делать хорошо. Мы промотали 5 минут на то, чтобы не выяснить о человеке ничего. Конечно, можно потратить полчаса и разобрать все по полочкам. Но есть два «но».
Во-первых, цените время. Если на каждого кандидата будете тратить по 4 часа, то вы можете просто «не дойти» до действительно стоящего. Вообще, на мой взгляд, собеседование стоит жестко ограничить временными рамками, скажем одним часом. И постараться вытрясти за этот час из человека все, что Вам необходимо для принятия решения.
Во-вторых, не зацикливайтесь на том, кем человек был. Попробуйте оценить, кем бы он мог стать в вашей компании. Ваш кандидат говорит, что на прошлой работе сделал за неделю модуль, который Вы делали месяц? Так может на прошлой работе крутые бизнес процессы и гора готового кода, а у вас он бы делал этот модуль ровно столько же, сколько и Вы? Или Вам показалось, что на прошлой работе кандидат не сделал ничего сколько-нибудь примечательного? Очень может быть. Но может это талантливый человек, прозябавший в третьесортных «рогах и копытах», а у Вас раскроется весь его потенциал! Поверьте, во многих ситуациях за такого человека стоит побороться даже больше, чем за состоявшегося специалиста.
Стоит ли спросить что-то каверзное? Скажем вчера Вы прочитали на хабре, что, оказывается, хеш-код в джаве это не адрес (как Вы всегда считали), а случайное число, и Вам интересно, знает ли это кандидат. Или Вы на прошлой неделе ковырялись в никсах и выяснили, что "[" это не часть bash-скрипта как языка, а обычная программа с именем "[". Полезно ли будет выяснить, известно ли это кандидату?
Тут стоит опять же попробовать проиграть вопрос и варианты ответа.
Поиграйте по ролям.
- Ну это адрес объекта
И второй вариант:
Что такое Object.hashCode()?
- Да там генератор случайный чисел, вот он и возвращает.
Вы потратили 3 минуты на этот вопрос. Как вы сравните первого и второго кандидата? Можно ли сказать, что один из них лучше другого? Может быть второй листал на досуге grepcode. Или читал хабр вместо работы. А может и не вместо. Но вам-то это что-то говорит?
Не то чтобы не имело значения знает или нет человек тонкости реализации. Напротив - я считаю что очень важно знать мелочи. Человек, который знает ассемблер, для меня ценнее того, кто его не знает, даже когда я ищу джава разработчика. Но, к сожалению, мелочей так много, что прямой вопрос «А знаете ли вы что» почти никогда не несет смысла. А спросить о сотни вещей мы не можем, у нас ведь ограничено время.
Так что же спросить?
Мне кажется, лучше всего вести беседу, в ключе того чем Вы обычно занимаетесь и смотреть, как кандидат решает задачки которые Вы часто решаете.
Скажем в Вашем приложении есть UI-логика и серверный код. Спросите у кандидата, что, как ему кажется, интереснее.
Серверный код? Отлично. Давайте представим какой-нибудь типичный кусок кода в Вашей программе. Нам интересно, какие вопросы возникают у кандидата, и как увязывает он теоретические знания с практическими потребностями.
Скажем такая задачка:
Есть фрагмент кода
void x(List
…Some processing
Вопрос кандидату - предположим в этом коде нам надо перед «Some processing» отсортировать список в алфавитном порядке. Что будете делать? Кстати да, тут же можно сказать кандидату про Collections.sort - мы же не «словарный запас» проверяем.
Положим наш кандидат написал что-то типа
void x(List
List
Collections.sort(b);
…Some processing with b
(надеюсь наш кандидат именно так решил эту задачу а не начал сортировать a).
Однако решение задачи тут не главное. Главное дискуссия.
Почему он создал новый список а не использовал старый? Всегда ли это правильно?
Почему использовал ArrayList а не что-то еще? А знает ли он что еще есть?
Самое интересное что дискуссия тут может быть почти бесконечная. Кандидат скажет что ArrayList лучше тем что он random access, а Вы скажите что sort все равно копирует перед сортировкой данные в массив, а потом возвращает обратно. Стал ли ArrayList лучше теперь, по мнений кандидата? Как, уже нет? Или все равно лучше?
Беседа с кандидатом должна раскрывать образ его мыслей. Посмотрите как много деталей он знает. Как реагирует на что-то новое? А самое главное - может ли правильно распорядится информацией, которую Вы ему дадите? Ведь абстрактное «знание всего» обычно не особенно важно, в конце-концов рядом есть коллеги и проблемный вопрос часто можно обсудить. Коллеги могут подсказать, но писать код вместо нового сотрудника не будут, так попробуйте понять, сможет ли он, выслушав совет, написать программу лучше?
Или скажем другой пример.
Не спрашивайте «что такое garbage collector». Не спрашивайте «сколько там поколений». Какая разница сколько. Какая разница может или нет человек рассказать как устроен gc - для вашей работы может быть важно только то, сможет ли человек исправить performance проблему если таковая возникнет, а не может ли он поведать душещипательную историю про сборку поколениями или там про concurrent mark sweep gc.
Я не говорю, что кто-то может решать сколько-нибудь интересные проблемы с GC не зная, как он работает. Один раз, конечно, может и повезет. Но на практике знание чрезвычайно важно. Проблема в другом - не каждый, кто может рассказать как что-то работает, может исправить проблему с этим чем-то. И, вообще говоря, интуиция, общая техническая подкованность часто для решения задачи важнее прочитанного где-то описания алгоритма.
Например, для gc хорошо будет привести опять же какую-нибудь практическую задачку.
Скажем, «вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?».
Увеличу хип
А станет ли быстрее? И самое интересное, а разве не стоит перед ответом на этот вопрос спросить, а что такое для меня «быстрее»? Посмотрите, понимает ли кандидат разницу между throughput и latency. Не спрашивайте что это и в чем разница. Если кандидату при вышеописанной постановке задачи не приходит в голову задаться такими банальными вопросами, значит и на практике у него этих вопросов не возникнет. Однако не стоит забывать, что мы ведем беседу. Если кандидат прыгнул с места в карьер, остановите его, расскажите про разные характеристики производительности. Кандидат никогда про них не слышал, но сходу сообразил что рост хипа возможно улучшит одно, но точно ухудшит другое? Ну так это же замечательно!
Таких примеров можно привести бесконечное множество. Самое приятное тут, что такие задачки придумываются элементарно, и им нет числа - можно каждого нового кандидата спрашивать про разные вещи и адаптировать задачки под конкретного кандидата.
- Подбор и отбор, Оценка, Рынок труда, Адаптация
Привет всем, Джаварашовцы! Так уж случилось, что недавно я проходил собеседование и хотел бы рассказать, какие вопросы мне задавали предполагая, что идет позиция Junior++. Т.е. еще не мидл, но уже и не зеленый джун. Так вот, собеседование проходило по такому плану
- JavaCore
- Базы данных.
- Инструменты, которыми пользуешься.
JavaCore
- Исключения. Здесь опять-таки попросили нарисовать иерархию исключений, какие бывают, какие из них checked , а какие unchecked . Что нужно делать с Runtime исключениями. Назовите самое часто попадающее (NullPointerException).
Вначале меня попросили нарисовать иерархию интерфейсов у Коллекций (это было не сложно, там всего их несколько (Collection , List , Set , Queue , Map).
В чем различие ArrayList и LinkedList (это один из самых заезженных вопросов и ответов в инетах просто тьма).
Обсудили скорость выполнения запросов в них и какая разница между листами.
Вопрос про класс Object . Какие у него методы, что они делают.
Рефлексия. Что делает метод getClass() . Очень интересный вопрос, разберите его. Особенно про то, как получить всё про класс, пусть даже там приватные методы или переменные.
Спросили за многопоточность. Слабенько, как я считаю, так рассказать как ты понимаешь что такое многопоточность. Что нужно, чтоб запустить новый поток. Реально, если вы 20+ уровень, то эти вопросы для вас покажутся смешными.
Что можешь сказать про Stream . Это имеется в виду не про Java 8. Имеется в виду потоки ввода и вывода. Как базовые интерфейсы, какие они (символьные и байтовые). На понимание, никакой конкретики.
Вопрос с тем, что нужно делать с checked исключениями(пробрасывать дальше или обработать - понятно и то и другое).
ООП
Что такое ООП в двух словах?
Какие еще есть парадигмы программирования? В чем их различие от ООП
Какие основные принципы ООП (наследование,полиморфизм и инкапсуляция)? Рассказать про каждый из них. Пока всё абстрактно, не привязываясь к какому-то языку.
Задача на понимание проектирования систем: есть Лошадь и Птица. Нужно получить Пегаса. принцип "has a" и "is a"
REST
Что такое REST. В Википедии об этом говориться очень круто. Реально статьи из Википедии для ознакомления хватит.
HTTP. Здесь тоже общие фразы. Его методы, для чего каждый из них.
Коды состояния HTTP. На какие пять частей делиться, расскажите про самые известные (200,204,404,500,501). Зачем они. Спросили еще про 401 и 403. Но я не знал их. Сказали они важные.
Базы данных
Здесь я рассказал, что знаю MySQL. Рассказал про три нормальные формы. Рассказал про Join"ы, какие бывают и нарисовал пересечение областей, в котором используются разные джоины. Рассказал про то, как я понимаю реляционную БД. Не забыл еще о про MongoDB - это NoSQL база данных. Через некоторе время я напишу и про это.Другие инструменты
Здесь мы прошлись по моем резюме. У меня было написано, что использую Maven/Gradle для сборки, использую JIRA для тасков, git, Docker, Swagger. Для Continuous Integration - Stash, Bamboo, Puppet. Для тестирования JUnit , Mockito, JMeter. Я мог что-то забыть, поэтому если интересно - спрашивайте в комментариях постараюсь ответить. Это была первая часть собеседования. Теперь жду результаты и если да, то будет вторая часть. Напишу о ней как только так сразу. Всем кому статья понравилась и была полезна - ставьте "+". Пишите в комментариях. См. также мои другие статьи: уже устал слышать от компаний из Силиконовой долины фразы вроде «нанимайте только лучших и талантливейших». Как бы эти фразы ни вертелись на языках, большинство нанимателей всё равно принимают решения, основываясь на интуиции, анкете соискателя, среднем балле, дипломе университета, громких названиях предыдущих работодателей… Розман категорически против такого положения дел. Как бывший вице-президент в Amazon и Zynga, он провёл собеседования с сотнями людей и уверен в том, что каждая стадия собеседования должна быть тщательно продумана и призвана оценить навыки соискателя, его достижения, способности к командной работе и лидерских качества.В своём интервью Розман рассказывает, как он организует процесс собеседования, позволяющий выстроить эффективную компанию вне зависимости от её размера и ресурсов.
На безымянной высоте
Итак, существует несколько ключевых принципов собеседования, которые работают ещё до того, как вы начали просматривать резюме и смотреть рекомендации. Эти принципы позволят вам составить чёткое видение процесса собеседования и найма работников.
После интервью у вас должно сложиться ясное представление о том, сможет ли этот человек внести вклад в успех компании.
Хорошее собеседование — это труд. К нему нужно готовиться, его нужно провести, а потом потратить время на обсуждение результатов. Если вы к этому не готовы — не проводите собеседования.
Как только вы получили первое впечатление о человеке (обычно это происходит в первую минуту разговора), постарайтесь опровергнуть это впечатление в течение оставшегося времени.
Во время собеседования делайте подробные заметки, чтобы обеспечить себя убедительными доводами за или против кандидата.
В большинстве случаев «лучшие и талантливейшие» уже где-то работают, поэтому вам нужно искать лучших среди тех, кто свободен. Нужно учесть, что у вас не будет возможности доказать успешность своего выбора, поскольку в деле найма работников не может быть немедленных результатов.
Старайтесь найти звёзд, но имейте в виду, что не все вакансии требуют умения перевернуть мир. Человек, которого вы ищете, должен быть лучше большинства в некоторых сферах, и иметь достаточный потенциал для долговременного развития.
Тот, кого вы хотите нанять — умный, трудолюбивый человек, обладающий навыками, необходимыми для конкретной вакансии.
Как правильно читать резюме и составлять вопросы
Любой ищущий работу начинает с составления резюме или своего веб-профиля — и ищущий работу по рекомендациям, и использующий различные ресурсы по поиску работы. Жизненный опыт подсказывает нам, что резюме не всегда показывает реальные знания кандидата, но Розман утверждает, что внимательное прочтение резюме даёт очень много информации.
При просмотре резюме Розаман ищет те ниши, которые занимает кандидат в реальности. «Я всегда смотрю, измеряют ли люди свой успех, делают ли они сравнения и используют ли процентные соотношения». Например, «прибыль выросла на 50%, время простоя снизилось на 30%».
Так же он составляет большинство вопросов. «Вы хотите выяснить, чего человек достиг на самом деле, не был ли он пассивным участником или наблюдателем. Даже в самых крупных компаниях есть те, на кого возложена большая часть функций, и те, кто делает гораздо меньше. На собеседовании вам и нужно выяснить, чем занимался человек ранее».
Лакмусовой бумажкой будет то, насколько чётко кандидат оценивает себя и свою роль в проделанной прежде работе. «Кандидат может думать, что заявление вроде «я улучшил доступность системы на 50%» звучит круто, но если мы ищем человека на вакансию системного инженера, мне нужно знать, как именно он это сделал. В большинстве случаев, несмотря на такие громкие заявления, человек на самом деле был лишь участником процесса и мало понимает в его сути. Он не сможет внятно ответить на вопрос, как он добился такого результата». Хороший кандидат всегда объяснит и подтвердит свои заявления, каким бы дотошным вы ни были.
В одном из недавних резюме, полученных Розманом, было написано: «Был тим-лидом команды из 3 инженеров, создавал высоконагруженную инфраструктуру, используемую различными продуктами Google». Розман записал это себе в блокнот и во время собеседования попросил кандидата нарисовать на доске инфраструктуру, рассказать о своём вкладе в её создание и ответить на вопросы— - что позволило выяснить, действительно ли человек знает, о чём говорит.
Иными словами, хорошие вопросы на собеседовании потребуют от кандидата ответа с конкретными примерами своих действий, принятых решений и его роли в проекте.
Прощупайте почву: приведите мне пример…
Уточняйте: кто, что, где, когда, почему, как - о каждом достижении или проекте
Выясняйте: мы или я; хорошо или отлично; отдаленное представление или точное знание; участник или лидер…
Предыдущие проекты и свершения кандидата могут быть хорошей базой для последующих вопросов. Розман придерживается бихевиористского подхода к собеседованию (вопросы, раскрывающие ситуацию, задачи, действия и результат).
Над чем вы работали в компании?
Какие задачи выполняли?
Какие действия вы предпринимали для решения задач?
Какие результаты получили?
Неплохо при прочтении резюме выяснить, были ли перечисленные проекты и продукты значимыми для компании.
Техническое интервью
Очень часто HR-менеджеры на собеседовании с места в карьер начинают опрашивать кандидата по всем пунктам, указанным в его резюме. По мнению Розмана, такой вопрос можно задавать только в том случае, если вы уже решили отказать человеку. Есть множество других способов расположить соискателя к беседе. Розман рекомендует интервьюеру представиться и обозначить цели интервью. «Потом я прошу человека представитьтся самому и рассказать о том, чем ему интересно заниматься. Так намного проще расслабиться, настроиться на беседу и убедиться, что оба чувствуют себя комфортно».
После такого небольшого вступления Розман продолжает интервью техническими вопросами. «Основная причина, по которой люди не получают работы на технической специальности — это недостаток навыков. Они просто не проходят техническую стадию собеседования. Поэтому важно выяснить это с самого начала».
Тут нужно внимательно отнестись к сфере деятельности соискателя. Если это программирование, то и вопросы нужно задавать из той сферы, в которой кандидат работал. Не задавайте на собеседовании вопросы, которые вы никогда ранее не задавали. «Попробуйте сначала протестировать интересующий вас вопрос на кроликах, задать его своим коллегам, чтобы понять, какие ответы можно ожидать».
Это самый важный принцип составления умных вопросов. «Что меня серьезно достало — так это те люди, которые задают те вопросы, ответить на которые и сами бы не смогли. Как они смогут отличить хороший ответ от хренового?»
В современном мире это особенно важно, когда в сети есть огромное количество ресурсов с возможными вопросами на собеседовании. Кандидаты просматривают задачи с собеседований на Quora и готовятся к ним. Абсолютно нормально использовать такие вопросы и задачи для составления собственных. «Хорошо бы обсудить со своей командой варианты плохих и хороших вопросов, и какие из них было бы неплохо задать на собеседовании».
На своих собеседованиях Розман просит кандидатов составить палиндром, потом предлагает воображаемую ситуацию: например, у них есть машина с ограниченным объемом памяти, и даёт задание, которое нужно решить на месте. Всегда нужно вырывать людей из контекста, выводить их за пределы ответов, найденных в сети. Если человек прошёл все уровни испытаний, — он чертовски умён.
Для создания уникальных вопросов необходимо спросить кандидата, как бы они решили реальные проблемы, с которыми сталкивается ваша компания. «Когда я работал в Amazon, я часто задавал вопросы, связанные с системой рекомендаций - та самая опция «люди, которые купили этот товар, также приобрели вот этот…» Вопросы из этой сферы позволяли определить, насколько соискатель ориентирован на продукт».
Розману очень нравится подталкивать кандидатов на инженерные должности к дизайну продуктов. Хороший инженер - это не просто исполнитель, а активный участник разработки продукта. Вопросы, связанные с дизайном, позволят лучше понять ход мыслей соискателя. Розман просит кандидатов перечислить продукты, в разработке которых они принимали участие, просит их написать небольшую план развития продукта. Также он может попросить выполнить достаточно общую задачу вроде «обдумать разработку лифта для слепых людей».
«Если бы у меня было достаточно времени, я бы выдавал на собеседовании ноутбук и просил бы написать простое приложение в командной строке, либо же нарисовать процесс на доске, и дал бы возможность задать мне вопросы по поводу того, какой продукт я хочу получить. Очень важно, чтобы соискатель задавал вопросы. Мне нужен сотрудник, который задаёт вопросы, а не просто сидит в углу и ждёт указаний».
В технических вопросах есть одна проблема: ответы могут занять очень много времени. Вот тут важно следить за временем и вовремя прервать ответ. Ответ на сложный вопрос может запросто съесть 45 минут из часового собеседования.
«Бывает, я прошу только написать код на доске, потому что уже нужно переходить к вопросам по дизайну или продукту. А ведь ещё нужно прояснить коммуникативные навыки и способность кандидата влиться в команду».
С этой целью Розман задаёт всем кандидатам, вне зависимости от предполагаемой должности, один свой любимый вопрос: «Считаете ли вы себя счастливым?»
«Оглянитесь на то, что сделали, и подумайте: можете ли вы себя отнести к тем людям, кто был счастлив на своём жизненном и профессиональном пути? Многие на этот вопрос отвечали мне: «Я бы получил повышение, но менеджер отменил мой проект…» Это как раз те, кто не считает себя счастливым человеком. Удача улыбается подготовленным умам. Я ищу тех людей, кто готов найти выгоду в каждом обстоятельстве».
Розман часто использует вопросы типа «опишите себя тремя прилагательными». Многие интервьюеры просят описать свои сильные и слабые стороны, но Розман ставит акцент на другом. «Я прошу кандидата вспомнить тех людей, с кем он работал, своих учителей, однокурсников, менеджеров и прочих, и представить, какими бы тремя словами эти люди описали бы его. Это позволяет взглянуть на себя с другой стороны. И уже не так просто сказать, что самое твоё плохое качество - это трудоголизм». И если кандидат назвал эти три качества, Розман на этом не останавливается. Если кандидат сказал: «творческий», вам нужно спросить: «А приведите примеры своего творческого подхода».
Даже если уже после 15 минут общения вы поняли, что это не ваш кандидат, важно довести собеседование до конца. «Мир очень тесен, и даже если вы отказываете кандидату, очень здорово, если у человека останутся от собеседования хорошие воспоминания».
Если кандидат, наоборот, явно в фаворитах, важно сделать им предложение о работе в конце собеседования. «Ответить на вопросы потенциального сотрудника и с энтузиазмом рассказать подробности о работе и возможностях - это благодарное дело. Своим HR-менеджерам я всегда говорю, что даже если позитив из вас не бьет ключом, по отношению к делам компании нужно оставаться оптимистичным. Если в вас нет оптимизма - вам незачем проводить собеседования».
Розман старается предугадать мотивы кандидата, и что может заставить кандидата отказаться от предложения. «Сейчас я, как старый морской волк, могу не задавать вопросы типа «А кем вы себя видите через 2-3-5 лет?». Но я хочу убедиться, что я правильно понимаю ожидания кандидата».
HR-команда
Насколько хороши будут ваши будущие работники, зависит от вашей HR-команды. Очень часто компании не тратят время на то, чтобы обучить своих кадровиков проводить собеседования. Розман считает, что каждый кадровик должен знать, как это делается. «Даже если обязанность человека состоит лишь в телефонном общении с кандидатами, я требую, чтобы он вначале посидел рядом с опытным кадровиком и послушал, как это делается».
Как только вы собрали квалифицированную команду, нужно поближе взглянуть на то, как они принимают решения. Чтобы сформировать объективное мнение о кандидате, каждому участнику команды следует вести подробные записи на собеседованиях. После того, как все лично повстречались с кандидатом, начинается групповое обсуждение. «Каждый из нас высказывает свои впечатления и аргументы, делится задаваемыми вопросами и пересказывает ответы кандидата. Если есть голос против кандидата, не справившегося с техническим заданием, обязательно нужно предоставить точный вопрос и последовавший ответ».
Каждое решение на собрании HR-комианды критично, а критичные решения требуют глубокого осмысления. Розман говорит о двух вещах:
Если отдел кадров не может предоставить внятных комментариев, они потратили впустую и своё время, и время компании, и время кандидата;
Если вы провели собеседование и всё, что можете сказать, это: «Ну да, он вроде ничего, мне понравился», - вы тоже потратили время зря. Вы не справились с работой, и вам нужно либо научиться делать это, либо больше не проводить собеседования. Я не заставляю никого делать эту работу, но если вы взялись за неё, я требую, чтобы она была сделана хорошо.
Хороший интервьюер не должен работать самоотверженно и бескорыстно. Его труд отражается и на существующих работниках. «Покажите, что вы - человек, на котором лежит большая ответственность».
Несмотря на свой командный подход к принятию решений по найму, Розман осторожно относится к HR-менеджерам, слишком вовлечённым в процесс. Важно учитывать мнения людей, которые будут работать с новым сотрудником ежедневно. «Что бы ни случилось, не позволяйте мнению менеджера победить мнение команды».
Если вернуться к запредельным стандартам Силиконовой долины, Розман признаёт, что очень часто кандидату отказывают, потому что он не проявил никаких способностей супермена. Но далеко не ото всех требуются такие сверхспособности на собеседовании. Розман предлагает установить такую планку: «Чего нужно ожидать - так это того, каждое поколение работников лучше, чем предыдущее. Нет никакой гарантии, что если вы уволитесь и захотите вернуться, вас возьмут обратно на ту же должность. С каждой новой работой вы повышаете свою собственную планку. Другими словами, каждый новый сотрудник должен быть лучше, чем ваш среднестатистический работник».
Та же логика применима и для найма новых сотрудников по рекомендации работников.
Итак, краткая сводка правил Розмана:
Не забывайте представиться и беречь нервы всех участников собеседования.
«Расскажите немного о себе» - самый бесполезный вопрос для технического интервью.
В резюме выделяйте то, что кандидат уже сделал. Помните, вам нужны люди, которые смогут работать. И точка.
Фильтруйте информацию в резюме с длинным списком навыков. Отделяйте зерна от плевел.
Не испытывайте новые вопросы на кандидатах. Тестируйте их на своих сотрудниках.
Пусть кандидат напишет код на собеседовании! Почему так часто забывают это сделать?
Остановитесь подробней на алгоритмах, структуре данных, организации и простоте кода.
Задайте расплывчатые и двусмысленные вопросы. Посмотрите, попросит ли кандидат у вас уточнений.
Задайте вопрос о дизайне продукта. Посмотрите, есть ли у соискателя общее представление.
Определите основные ценности вашей компании. Убедитесь, что у соискателя осталось верное впечатление.
Собеседование должно быть сложным, но не занудным. Хороший разработчик с удовольствием поговорит с умными ребятами.
Перевод: Люся Ширшова. По материалам статьи на
