ГлавнаяРазноеТехнические вопросы на собеседовании

25 каверзных вопросов, которые задают кандидатам на собеседованиях в Microsoft. Технические вопросы на собеседовании


пять способов отпугнуть соискателя / пять способов взбесить интервьюера / Блог компании ООО «ЦИТ» / Хабр

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

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

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

А что на собеседованиях раздражает или напрягает вас? Поделитесь в комментариях.

Собеседование с позиции соискателя
Каждый раз при поиске работы программисту приходится проходить множество технических собеседований. Он ходит по офисам или разговаривает по скайпу, решает задачки или делает тестовые задания, отвечает на заковыристые технические вопросы, пытаясь продемонстрировать себя с лучшей стороны. Однако и сам он при этом оценивает людей, которые собеседуют и проверяют его, думая о том, что завтра ему потенциально с этими людьми придётся работать. И есть множество способов для технических интервьюеров отпугнуть соискателя от интересной должности. Я расскажу о том, что всегда отпугивало лично меня, и чего стараюсь не допустить я как интервьюер.
1. «Какое ещё техническое собеседование?»
Первое и главное, что всегда настораживало меня в техническом собеседовании — это его отсутствие. Бывает так, что вся беседа с техническими специалистами — потенциально будущими коллегами — строится на вопросах относительно профессионального опыта: где работал, какими проектами занимался, какую функцию в них выполнял. По технологиям или знаниям — вопросы уровня «какого цвета учебник». Знаете, что такое Message Broker? Отлично, мы вас берём!

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

2. «Ну и чем вы там занимались в этом своём…»
Удивительно, как часто встречается пренебрежительное отношение к соискателям на технических собеседованиях. Да, возможно, вы суровый и опытный программист с кучей проектов за плечами, вас оторвали от чрезвычайно важной работы ради каких-то ненужных интервью с людьми, большая часть из которых, по вашему мнению, совершенно некомпетентна. Но не забывайте о том, что вы в этот момент представляете свою компанию и свою команду, и человек по вашему поведению обязательно составит оценку о климате в коллективе и о том, как к нему в этом коллективе будут относиться. Будьте вежливы и уважительны к соискателю, даже если вы с первых пяти минут поняли, что его и близко нельзя подпускать к вашему драгоценному коду.
3. «Что-то у вас имя/фамилия/отчество в резюме неправильно написано!»
Это совсем не технический, но, тем не менее, часто встречающийся косяк даже на технических интервью. У меня, к счастью, достаточно простое и распространённое имя, и таких проблем со мной не случалось. Однако я знаю, что существует удивительно много людей, которые свято уверены в том, что определённых имён и даже отчеств попросту не существует. Они будут вас убеждать, что правильно не «Данила», а «Даниил», или что имени «Алёна» нет, а есть только «Елена». Будут предлагать исправить и записать в своих документах «правильно». С такими грамотеями-доброхотами приходится часто иметь дело людям с редкими или необычными именами, и поверьте, это невероятно раздражает. Так вот, есть одно простое правило: нет таких имён, которых нет. Правильно писать так, как записано в паспорте. Проявите уважение к соискателю и не считайте его настолько глупым, что он не в состоянии переписать из паспорта в резюме собственное имя. Если даже подозреваете ошибку, это можно уточнить как-то более тактично.
4. «Сколько шариков для гольфа понадобится, чтобы помыть все круглые окна в школьном автобусе, уменьшенном до размеров пятицентовой монеты, во время эвакуации из Сан-Франциско, используя не более 3 взвешиваний?»
Ни одна статья про собеседования не будет полной без упоминания канализационных люков. Можете считать это моим персональным пунктиком, связанным с неумением быстро и под напряжением решать нестандартные задачи. Но я уверен, что брейн-тизеры на собеседованиях абсолютно бесполезны. Вернее, это отличный способ набрать полный отдел вундеркиндов с олимпиадой головного мозга, которые круглыми днями вместо работы будут перекидываться свеженькими брейн-тизерами. Реальный программист в естественной среде обитания, даже занимающийся очень крутыми и нестандартными задачами, всё равно редко кодит под напряжением, а большую часть дня сидит и в относительно спокойной обстановке неспешно думает над тем, как ему красиво распилить код по методам. «Мозговые мышцы» для решения хитрых задачек он не задействует в этом процессе ни разу.
5. «Неправильно. Дальше.»
Конечно, заниматься обучением приходящих на собеседование людей — это не задача интервьюера. Однако, если соискатель не смог ответить на вопрос, но всё же заинтересовался, то подсказать или хотя бы указать ему на правильное решение, прежде чем переходить к следующему вопросу — это вопрос профессиональной этики, демонстрация того, что здесь ему в случае чего помогут, научат, не бросят наедине с техническими проблемами. Скажите хотя бы пару слов, что ему погуглить, что почитать. Ведь интерес к правильному решению задачи — это само по себе положительное качество технического специалиста, и не стоит демотивировать такого человека пренебрежительным отношением к его ошибкам или неточностям.
Собеседование с позиции интервьюера
Каждый раз при открытии новой вакансии ведущему специалисту или начальнику отдела приходится проводить множество технических собеседований. На собеседования приходят люди с разным техническим опытом, уровнем подготовки, ожиданиями. Для проведения собеседований нужно продумывать план разговора, составлять список вопросов, а потом пытаться по ответам на эти вопросы понять, подходит человек на должность или нет. И вот иногда соискатели на собеседованиях говорят такие вещи, что становится сразу ясно — нет, ты с этим человеком работать вместе не сможешь. Вот некоторый набор ключевых фраз соискателей, которые настораживают лично меня.
1. «Какие-то у вас вопросы теоретические. Я не силён в теории, я закалён в практике! Давайте лучше тестовое!»
Слово «теоретические» обычно произносится с пренебрежительным оттенком, как будто это что-то плохое. Но беда даже не в этом. Думаете, этой фразе предшествовала просьба интервьюера доказать теорему Коши? Дать точное определение третьей нормальной форме? Отнюдь. Такие возгласы я слышал в ответ на следующие вопросы:
  • чем сравнение по == отличается от сравнения по equals в Java?
  • расскажите, как устроена хэш-карта.
  • объясните своими словами, что такое REST.
  • что такое транзакции и зачем они нужны?
Да, с определённой позиции, любой вопрос по программированию является теоретическим, если он не требует от вас прямо здесь и сейчас написать строчку кода. Но я уверен, что человек с достаточно большим опытом в определённой области должен уметь своими словами объяснить самые базовые вещи, или хотя бы не делать вид, что их незнание — это нормально и естественно.
2. «Не ожидал здесь испанскую инквизицию! У вас прямо как на экзамене в институте. Обычно просто спрашивают, где работал, что делал»
Вы пришли на техническое собеседование. На техническом собеседовании вам будут задавать технические вопросы, чтобы проверить ваши технические навыки. Методику проверки и выбор вопросов оставьте на совести интервьюера — вопросы не всегда могут вам казаться адекватными, но интервьюер знает, какую именно информацию он хочет о вас получить, анализируя ваши ответы. Многие вопросы нужны не затем, чтобы проверить знания, а чтобы заставить вас порассуждать и посмотреть на ход ваших мыслей. Помните также, что не на все вопросы требуется идеально точный ответ, и если вы внятно ответите хотя бы на половину из того, о чём вас спросили, это уже произведёт хорошее впечатление.
3. «Мне и не нужно это знать, я специализируюсь на более высокоуровневых задачах!»
Не надо путать специализацию и незнание основ программирования. От разработчиков мобильных приложений я слышал подобные вещи про протоколы стека TCP/IP, от фронтэнд-программистов — в ответ на вопросы про алгоритмы сортировки и поиска. «Зачем мне это знать, всё есть в стандартной библиотеке, я работаю на более высоком уровне». В ответ на такие заявления я давно придумал пару небольших задачек с подло скрытой алгоритмикой — в надежде показать, что «наивное» решение, выданное от незнания алгоритмов, не выдерживает критики, и побудить хотя бы к самообразованию. Причём это не какие-то искусственно сконструированные задачи, а такие вещи, которые встречаются в разработке ежедневно. Любой код это алгоритм. Понимание основных алгоритмов и структур данных важно для любого программиста, а протоколы сети Интернет — это база, без знания которой невозможно грамотно написать хоть что-то, что выходит за пределы одного компьютера.
4. «А сами-то! / А покажите ваш код! / А вот я зашёл к вам на GitHub, а там такое...»
Меньше всего интервьюеру хочется взять человека на работу, а потом выслушивать от него критику своей кодобазы. Да, она, скорее всего, неидеальна. Да, технический долг есть везде и у всех. В любом коде найдётся что покритиковать. Но если вы действительно считаете себя настолько крутым, что видите очевидные проблемы в коде своих потенциальных работодателей — переведите это в конструктивный позитив: я знаю, как улучшить, у меня есть наработки на эту тему, я смогу принести вам пользу.
5. «Вы не правы!»
Всякое бывает, конечно, но мнение относительно неправоты интервьюера или сомнения в его компетентности лучше оставить при себе до окончания собеседования. Потом погуглите и разберётесь, кто из вас был прав. Техническое собеседование — это не место для дискуссий или самоутверждения, и вопросы здесь в первую очередь задают вам. Интервьюер не станет спрашивать о том, в чём сам не разбирается.
Заключение
А знаете, какую самую приятную вещь я слышал на собеседовании от соискателей? «Что-то я не очень наотвечал, да? А можете дать листочек? Я запишу ваши вопросы и дома поразбираюсь, даже если не возьмёте меня, хоть буду знать теперь». Слёзы гордости наворачиваются на глаза — ты не зря потратил на человека полтора часа времени, он и сам что-то вынес из этого собеседования. Даже если сейчас он слабоват для этой должности, возможно, это побудит его к самообразованию, и через годик-другой он придёт ещё раз, покажет себя с лучшей стороны и получит работу — как это случилось однажды и в моей собственной карьере.

habr.com

Идеальное техническое собеседование. Советы от Нила Розмана

2013-09-10

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

В своём интервью Розман рассказывает, как он организует процесс собеседования, позволяющий выстроить эффективную компанию вне зависимости от её размера и ресурсов.

 

 

На безымянной высоте

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

 

  • После интервью у вас должно сложиться ясное представление о том, сможет ли этот человек внести вклад в успех компании.

  • Хорошее собеседование — это труд. К нему нужно готовиться, его нужно провести, а потом потратить время на обсуждение результатов. Если вы к этому не готовы — не проводите собеседования.

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

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

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

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

  • Тот, кого вы хотите нанять — умный, трудолюбивый человек, обладающий навыками, необходимыми для конкретной вакансии.

 

Как правильно читать резюме и составлять вопросы

Любой ищущий работу начинает с составления резюме или своего веб-профиля — и ищущий работу по рекомендациям, и использующий различные ресурсы по поиску работы. Жизненный опыт подсказывает нам, что резюме не всегда показывает реальные знания кандидата, но Розман утверждает, что внимательное прочтение резюме даёт очень много информации.

При просмотре резюме Розаман ищет те ниши, которые занимает кандидат в реальности. «Я всегда смотрю, измеряют ли люди свой успех, делают ли они сравнения и используют ли процентные соотношения». Например, «прибыль выросла на 50%, время простоя снизилось на 30%».

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

Лакмусовой бумажкой будет то, насколько чётко кандидат оценивает себя и свою роль в проделанной прежде работе. «Кандидат может думать, что заявление вроде «я улучшил доступность системы на 50%» звучит круто, но если мы ищем человека на вакансию системного инженера, мне нужно знать, как именно он это сделал. В большинстве случаев, несмотря на такие громкие заявления, человек на самом деле был лишь участником процесса и мало понимает в его сути. Он не сможет внятно ответить на вопрос, как он добился такого результата». Хороший кандидат всегда объяснит и подтвердит свои заявления, каким бы дотошным вы ни были.

В одном из недавних резюме, полученных Розманом, было написано: «Был тим-лидом команды из 3 инженеров, создавал высоконагруженную инфраструктуру, используемую различными продуктами Google». Розман записал это себе в блокнот и во время собеседования попросил кандидата нарисовать на доске инфраструктуру, рассказать о своём вкладе в её создание и ответить на вопросы—– что позволило выяснить, действительно ли человек знает, о чём говорит.

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

  • Прощупайте почву: приведите мне пример…

  • Уточняйте: кто, что, где, когда, почему, как – о каждом достижении или проекте

  • Выясняйте: мы или я; хорошо или отлично; отдаленное представление или точное знание; участник или лидер…

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

  • Над чем вы работали в компании?

  • Какие задачи выполняли?

  • Какие действия вы предпринимали для решения задач?

  • Какие результаты получили?

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

 

Техническое интервью

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

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

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

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

В современном мире это особенно важно, когда в сети есть огромное количество ресурсов с возможными вопросами на собеседовании. Кандидаты просматривают задачи с собеседований на Quora и готовятся к ним. Абсолютно нормально использовать такие вопросы и задачи для составления собственных. «Хорошо бы обсудить со своей командой варианты плохих и хороших вопросов, и какие из них было бы неплохо задать на собеседовании».

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

Для создания уникальных вопросов необходимо спросить кандидата, как бы они решили реальные проблемы, с которыми сталкивается ваша компания. «Когда я работал в Amazon, я часто задавал вопросы, связанные с системой рекомендаций – та самая опция «люди, которые купили этот товар, также приобрели вот этот…» Вопросы из этой сферы позволяли определить, насколько соискатель ориентирован на продукт».

Розману очень нравится подталкивать кандидатов на инженерные должности к дизайну продуктов. Хороший инженер – это не просто исполнитель, а активный участник разработки продукта. Вопросы, связанные с дизайном, позволят лучше понять ход мыслей соискателя. Розман просит кандидатов перечислить продукты, в разработке которых они принимали участие, просит их написать небольшую план развития продукта. Также он может попросить выполнить достаточно общую задачу вроде «обдумать разработку лифта для слепых людей».

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

В технических вопросах есть одна проблема: ответы могут занять очень много времени. Вот тут важно следить за временем и вовремя прервать ответ. Ответ на сложный вопрос может запросто съесть 45 минут из часового собеседования.

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

С этой целью Розман задаёт всем кандидатам, вне зависимости от предполагаемой должности, один свой любимый вопрос: «Считаете ли вы себя счастливым?»

«Оглянитесь на то, что сделали, и подумайте: можете ли вы себя отнести к тем людям, кто был счастлив на своём жизненном и профессиональном пути? Многие на этот вопрос отвечали мне: «Я бы получил повышение, но менеджер отменил мой проект…» Это как раз те, кто не считает себя счастливым человеком. Удача улыбается подготовленным умам. Я ищу тех людей, кто готов найти выгоду в каждом обстоятельстве».

Розман часто использует вопросы типа «опишите себя тремя прилагательными». Многие интервьюеры просят описать свои сильные и слабые стороны, но Розман ставит акцент на другом. «Я прошу кандидата вспомнить тех людей, с кем он работал, своих учителей, однокурсников, менеджеров и прочих, и представить, какими бы тремя словами эти люди описали бы его. Это позволяет взглянуть на себя с другой стороны. И уже не так просто сказать, что самое твоё плохое качество – это трудоголизм». И если кандидат назвал эти три качества, Розман на этом не останавливается. Если кандидат сказал: «творческий», вам нужно спросить: «А приведите примеры своего творческого подхода».

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

Если кандидат, наоборот, явно в фаворитах, важно сделать им предложение о работе в конце собеседования. «Ответить на вопросы потенциального сотрудника и с энтузиазмом рассказать подробности о работе и возможностях – это благодарное дело. Своим  HR-менеджерам я всегда говорю, что даже если позитив из вас не бьет ключом, по отношению к делам компании нужно оставаться оптимистичным. Если в вас нет оптимизма – вам незачем проводить собеседования».

Розман старается предугадать мотивы кандидата, и что может заставить кандидата отказаться от предложения. «Сейчас я, как старый морской волк, могу не задавать вопросы типа «А кем вы себя видите через 2-3-5 лет?». Но я хочу убедиться, что я правильно понимаю ожидания кандидата».

 

HR-команда

Насколько хороши будут ваши будущие работники, зависит от вашей HR-команды. Очень часто компании не тратят время на то, чтобы обучить своих кадровиков проводить собеседования. Розман считает, что каждый кадровик должен знать, как это делается. «Даже если обязанность человека состоит лишь  в телефонном общении с кандидатами, я требую, чтобы он вначале посидел рядом с опытным кадровиком и послушал, как это делается».

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

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

  • Если отдел кадров не может предоставить внятных комментариев, они потратили впустую и своё время, и время компании, и время кандидата;

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

Хороший интервьюер не должен работать самоотверженно и бескорыстно. Его труд отражается  и на существующих работниках. «Покажите, что вы – человек, на котором лежит большая ответственность».

Несмотря на свой командный подход к принятию решений по найму, Розман осторожно относится к HR-менеджерам, слишком вовлечённым в процесс. Важно учитывать мнения людей, которые будут работать с новым сотрудником ежедневно. «Что бы ни случилось, не позволяйте мнению менеджера победить мнение команды».

Если вернуться к запредельным стандартам Силиконовой долины, Розман  признаёт, что очень часто кандидату отказывают, потому что он не проявил никаких способностей супермена. Но далеко не ото всех требуются такие сверхспособности на собеседовании. Розман предлагает установить такую планку: «Чего нужно ожидать – так это того, каждое поколение работников лучше, чем предыдущее. Нет никакой гарантии, что если вы уволитесь и захотите вернуться, вас возьмут обратно на ту же должность. С каждой новой работой вы повышаете свою собственную планку. Другими словами, каждый новый сотрудник должен быть лучше, чем ваш среднестатистический работник».

Та же логика применима и для найма новых сотрудников по рекомендации работников.

Итак, краткая сводка правил Розмана:

  • Не забывайте представиться и беречь нервы всех участников собеседования.

  • «Расскажите немного о себе» - самый бесполезный вопрос для технического интервью.

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

  • Фильтруйте информацию в резюме с длинным списком навыков. Отделяйте зерна от плевел.

  • Не испытывайте новые вопросы на кандидатах. Тестируйте их на своих сотрудниках.

  • Пусть кандидат напишет код на собеседовании! Почему так часто забывают это сделать?

  • Остановитесь подробней на алгоритмах, структуре данных, организации и простоте кода.

  • Задайте расплывчатые и двусмысленные вопросы. Посмотрите, попросит ли кандидат у вас уточнений.

  • Задайте вопрос о дизайне продукта. Посмотрите, есть ли у соискателя общее представление.

  • Определите основные ценности вашей компании. Убедитесь, что у соискателя осталось верное впечатление.

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

Перевод: Люся Ширшова. По материалам статьи на FirstRound.

Читайте также: 

Своё дело: от инженера до технического директора

Дэйв Мэтвин: jQuery создают личности

42 правила командной работы от Джонатана Розенберга

itmozg.ru

Каких ответов я жду на собеседовании по тестированию / Хабр

Я провожу собеседования на тестировщиков. У меня иногда болит голова.

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

Сначала несколько слов о себе. На данный момент являюсь начальником отдела тестирования и сопровождения компании, занимающейся корпоративными ГИС. До этого работал руководителем группы тестирования в компании, разрабатывающей коммерческие СДО (Системы дистанционного обучения). А еще раньше ведущим инженером по тестированию в компании, которая обеспечивала электронные торги по ФЗ №94. А начинал я свою карьеру более 11 лет назад в роли системного администратора (в трех различных организациях). Стажером-программистом был чуть меньше двух лет (вначале нулевых – VB). Фрилансил инженером-программистом: писал собственный баг-трекер для госкомпании… Исходя из сказанного, можно утверждать, что определенный опыт (тестирования — суммарно более 5 лет) наработан…

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

На собеседовании я всегда задаю одни и те же вопросы:

  1. Почему вы решили стать тестировщиком?
  2. Что такое тестирование? В чем его суть как процесса?
  3. Что такое ошибка?
  4. В чем цель тестирования?
  5. Что вы знаете о жизненном цикле ПО?
  6. Какие бывают требования?
  7. Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?
  8. Расскажите о тестовой документации: виды, цели.
  9. Из каких этапов состоит процесс тестирования?
  10. Автоматизированное тестирование – отдельный вид тестирования?
  11. Какой тип/вид класс тестирования имеет смысл автоматизировать?
Соискатель, который доходит за полтора часа беседы до восьмого вопроса, – редкость, такого я возьму на работу юниором. Доходящий за то же время до 11 вопроса может быть принят на должность ведущего тестировщика, однако за 240 проведенных собеседований таких оказалось только 5 человек!

Может, я слишком требователен к ответам? Нет, я просто жду от соискателя понимания того, чем ему придется заниматься. Вот как проходит собеседование: я начинаю разговаривать с соискателем предпочтительно в форме диалога, задавая ему указанные вопросы. Если получаю ответ, правильный или близкий к правильному, то перехожу к следующему вопросу. Если соискатель «блуждает», приводит заученную формулировку или просто не может ее обосновать, я пытаюсь подвести его к правильному ответу и почему этот ответ правильный. Пытаюсь заставить рассуждать. Последний год вместо собеседований у меня получаются импровизированные лекции. И дело не только в том, что соискатели менее осведомлены или у них мало опыта. Имели место и собеседования на должность ведущего инженера по тестированию с претендентами с 10 летним опытом… результат почти всегда удручает. По-моему, дело в том, что очень много противоречивой информации и «неполезного» опыта, ведь очень многие российские компании строят процесс тестирования по модели С. Канера – когда два – три высококвалифицированных тестировщика полностью генерируют, отбирают и описывают кейсы, а проверки проводят 10 -15,100, 500+ «тестеров» не особо вникая в саму суть процесса.

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

Наиболее частый ответ: «потому что это просто и интересно (!)». Т. е. кандидат считает, что ему будут платить деньги за щелканье мышкой в вк… Или дадут софт и скажут – сломай его… Или он просто не готовился к этому вопросу и имеет весьма слабое представление о профессии.

Второй по частоте ответ: «потому что я хочу работать в IT и тестирование – самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).

Бывали и ответы: «меня мама/муж/жена заставила идти на собеседование».

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

Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».

Наиболее частый ответ (напрямую прописан у С. Канера и Р.Савина) – «поиск ошибок». И во всей литературе по тестированию почему-то никто не указывает, что это упрощение и весьма грубое, и вообще, этот ответ просто неверен!

Тестирование – комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).

Да, действительно, в ходе проверок выявляются ошибки/инциденты/замечания, но это лишь побочный продукт процесса. Основным является информация о соответствии продукта требованиям, которые к нему предъявляются.

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

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

Здесь люди начинают повторять ответ на второй вопрос с разными вариациями. Наиболее внимательные соискатели пытаются пересказать то, что я им подсказывал при ответе на второй вопрос. А ответ крайне простой:

Цель тестирования – предоставление актуальной информации о соответствии производимого продукта требованиям.

Всё. Не больше и не меньше. Ну, конечно же, можно еще сказать, что цель тестирования – предоставление информации о количестве ошибок в продукте. А именно это и неправильно. Почему? Вот просто-таки каждодневный кейс многих тестировщиков/ПМ/аналитиков: звонок заказчика – «как там мой продукт?». «Вы знаете, в нем еще 60 багов!» – ответ тестировщика/ПМ… И что дальше? Это много? Мало? Нормально? Можно, конечно, рассказать подробно о критичности этих багов, их приоритетах, но это не ответ на вопрос заказчика, это выдача сырой необработанной информации ДВП. Теперь тот же кейс. «Как там мой продукт?», – спрашивает заказчик. «35% процентов требований реализовано полностью, еще 5% – с замечаниями и еще 2% – сейчас в реализации», – отвечает ПМ/тестировщик. Как Вам кажется, такой ответ понятнее? И пусть в эти 5% входят, уже упомянутые 60 багов-замечаний… Ответ на вопрос дан настолько точный, насколько это вообще возможно в данном формате. Вот именно это и является целью тестирования. А, соответственно, и сам процесс по своей сути должен сводиться к достижению этой цели.

Про ЖЦ ПО сказано много, да и он сильно зависит от организации процесса реализации в целом. Все же есть некоторая «золотая середина», но и здесь умудряются фантазировать дикие вещи, то сводя все к трем пунктам, то разрисовывая схему на три страницы… Всем, кто проводил/проходил собеседование, и так ясно, какие ошибки совершаются и сколько вариантов у правильных ответов. Останавливаться подробнее не буду, скажу только, что есть целый пул кандидатов, которые намертво стопорились на этом вопросе (примерно 7%). До этого вопроса за полтора часа доходят только процентов 50 соискателей… Хотя я и не требую ответов «буква в букву», главное, как это называют юристы, сохранить «дух».

Самый частый кейс: соискатели начинают перечислять виды технической документации, которые они знают или о которых слышали… Обязательно выслушаю, покиваю и спрошу: «что-нибудь еще?». Редко кто вспоминает про деление на «функциональные»/«нефункциональные», а кто вспоминает, часто не может объяснить разницу.

Но есть одна категория, про которую забывают. Я в этой статье уже несколько раз упоминал о «…требованиях прямых и косвенных…». На собеседовании я эту фразу произношу раз пять-шесть. Очень малый процент соискателей переспрашивает и тем самым исключает этот вопрос из собеседования. А полный ответ таков: «Требования бывают прямыми (т. е. формализованными в технической документации, спеках, юзер-стори и прочих формальных артефактах) и косвенными (т. е. проистекающими из прямых, либо являющимися негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования данного продукта или продуктах, подобных ему). Все требования также подразделяются на функциональные (описывающие какие функции должен выполнять продукт) и нефункциональные (требования к окружению, поддерживаемости, надежности и прочим характеристикам продукта). Прямые требования всегда приоритетнее косвенных.»

Самый очевидный и «простой» пример: в ТЗ — «кнопка должна быть красного цвета» – прямое требование, из него проистекают косвенные – она не должна быть синей, зеленой, серой или черной и т. д… Естественно, это сильное упрощение, но очень показательное. А главное – такой подход отсекает излишне формальное отношение к тестированию и поднимает планку квалификации тестирования как такового, ибо для грамотного тестирования мало знать только ТЗ и юзер-стори, надо еще изучить прикладную область и специфику потребления производимого продукта. Такое тестирование значительно эффективнее.

Есть маленький грех за мной: я отрицаю существование негативных проверок, поскольку:

  • их тяжело обосновать перед руководством,
  • на них трудно получить время,
  • их практически невозможно обосновать экономически перед заказчиком при составлении сметы на тестирование.
Опираясь на концепцию косвенных требований этого делать не надо, т. к. все проверки становятся позитивными, но часть из них – на соответствие прямым требованиям, часть – на соответствие косвенным. И квалификация специалиста как раз и выявляется пониманием косвенных требований для каждого конкретного продукта. О классификации тестирования имеется очень много информации, вариантов правильных ответов тоже очень много. Я задаю этот вопрос, чтобы увидеть, готовился соискатель хоть в малой степени или вообще не удосужился. Дело в том, что на предыдущие вопросы можно ответить, просто рассуждая и имея общее представление о сфере в целом. Данный вопрос требует элементарного знания терминов. Возможно, я рассмотрю его в других статьях, ибо он достаточно большой и заслуживает отдельной статьи. Тестовая документация – пожалуй, самая большая проблема. По ней идут такие битвы в сообществах, фирмах и т. д.! Про нее столько противоречивой информации. О ней изданы многотомники на разных языках. О ней такая каша в головах… Каких только ответов не приходилось слышать (да-да, включая ТЗ и проектное решение – это тоже тестовая документация)… Поэтому выскажу свои мысли по этому поводу.

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

Внешняя документация:

  • Замечание – короткая записка, комментарий о небольшой неточности в реализации продукта.
  • Баг-репорт – описание выявленного случая несоответствия производимого продукта требованиям, к нему выдвигаемым – ошибки или ее проявления. Он обязательно должен содержать следующие элементы:
    • Идею тестового случая, вызвавшего ошибку.
    • Описание исходного состояния системы для выполнения кейса.
    • Шаги, необходимые для того, чтобы выявить ошибку или ее проявление.
    • Ожидаемый результат, т. е. то, что должно было произойти в соответствии с требованиями.
    • Фактический результат, т. е. то, что произошло на самом деле.
    • Входные данные, которые использовались во время воспроизведения кейса.
    • Прочую информацию, без которой повторить кейс не получится.
    • Критичность и/или приоритет.
    • Экранный снимок (скрин).
    • Версию, сборку, ресурс и другие данные об окружении.
  • Запрос на изменение (улучшение) – описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя. И пути/рекомендации по модификации продукта для соответствия им.
  • Отчет о тестировании (тест репорт) – документ, предоставляющий сведения о соответствии/ несоответствии продукта требованиям. Может так же содержать описание некоторых подробностей проведенной сессии тестирования, например, затраченное время, использованные виды тестирования, перечень проверенных случаев и т. п. В идеальном варианте фраза вида «Тест пройден. Ошибка не воспроизводится/Функционал работает корректно/Соответствует требованиям» означает, что продукт или его часть полностью соответствует требованиям прямым и косвенным (в производстве ПО).
Внутренняя документация:
  • Тест-план (план тестирования) – формализованное и укрупненное описание одной сессии тестирования по одному или нескольким направлениям проверок. Т.е. перечень направлений проверок, которые должны быть проведены в рамках сессии тестирования (и, сообразных этим направлениям, требований). Также может содержать в себе необходимую информацию об окружении, методике, прочих условиях важных для показательности данной сессии тестирования. Под направлением проверок также может пониматься более детализированная тестовая документация (в виде ссылки на нее): чек листы, тестовые комплекты, тестовые сценарии, на которую необходимо опираться при проведении сессии тестирования. Основная цель документа – описать границы сессии тестирования, стабилизировать показательность данной сессии.
  • Тестовый сценарий – последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им  проверок корректности поведения продукта в ходе этих действий. Может содержать информацию об исходном состоянии продукта для запуска сценария, входных данных и прочие сведения, имеющие определяющее значение для успешного и показательного проведения проверок по сценарию. Особенностью является линейность действий и проверок, т.е. зависимость последующих действий и проверок от успешности предыдущих. Цель документа – стабилизация покрытия аспектов продукта, необходимых для выполнения функциональной задачи, показательными необходимыми и достаточными проверками. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию.
  • Тестовый комплект – некоторый набор формализованных тестовых случаев объединенных между собой по общему логическому признаку.
  • Чек-лист (лист проверок) – перечень формализованных тестовых случаев в виде удобном для проведения проверок. Тестовые случаи в чек-листе не должны быть зависимыми друг от друга. Обязательно должен содержать в себе информацию о: идеях проверок, наборах входных данных, ожидаемых результатах, булевую отметку о прохождении/непрохождении тестового случая, булевую отметку о совпадении/несовпадении фактического и ожидаемого результата по каждой проверке. Может так же содержать шаги для проведения проверки, данные об особенностях окружения и прочую информацию необходимую для проведения проверок. Цель – обеспечить стабильность покрытия требований проверками необходимыми и достаточными для заключения о соответствии им продукта. Особенностью является то, что чек-листы компонуются теми тестовыми случаями, которые показательны для определенного требования.
  • Тестовый случай (тест-кейс) – формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным. Обязательно должен содержать следующую информацию:
    • Идея проверки.
    • Описание проверяемого требования или проверяемой части требования.
    • Используемое для проверки тестовое окружение.
    • Исходное состояние продукта перед началом проверки.
    • Шаги для приведения продукта в состояние, подлежащее проверке.
    • Входные данные для использования при воспроизведении шагов.
    • Ожидаемый результат.
    • Прочую информацию, необходимую для проведения проверки.
Цель – зафиксировать сгенерированную и отобранную показательную проверку в виде, позволяющем тестировщику любой квалификации ее провести и суметь проанализировать полученные результаты.

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

  • Обеспечить стабильность покрытия требований проверками.
  • Обеспечить показательность всех проводимых проверок.
  • Обеспечить необходимость и достаточность проводимых проверок.
  • Сэкономить время на этапах тестирования, сводя их к проведению проверок и анализу  и передаче результатов.
  • Снизить входной уровень квалификации тестировщика для проведения проверок.
  • Повысить прогнозируемость сессий тестирования в части затрат времени и ресурсов.
  • Повысить прозрачность процесса тестирования для других участников процесса производства продукта.
  • Обеспечить базу знаний о продукте и истории его развития.
Но следует учитывать, что есть и свои недостатки:
  • Стабильность покрытия. Со стремящейся к бесконечности долей вероятности, если проводится тестирование по документации, то будут проведены только те проверки, которые есть в данной документации. Вероятность пропуска ошибки (чаще всего несоответствие косвенному требованию, непокрытому документацией) возрастает.
  • Плохая локализация ошибки тестировщиком. Либо полное отсутствие локализации. Фактический результат не совпал с ожидаемым – ошибка. А что это на самом деле: ошибка; проявление ошибки; инцидент, уже описанной ошибки, тестировщик не проверит (в подавляющем количестве случаев).
  • Высокий требуемый уровень квалификации специалиста для создания и поддержания тестовой документации.
  • Большие временные затраты на создание и поддержание тестовой документации.
  • Слабо прогнозируемое время актуальности тестовой документации.
Списки как плюсов так минусов можно продолжать, я указал только те, которые лежат на поверхности. Но понимание хотя бы этого списка крайне важно для нынешнего или будущего специалиста по тестированию. Вопрос, касающийся тестовой документации, преодолевает очень малый процент соискателей.

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

Чаще всего отвечают приблизительно так: «подготовка, тестирование, отчет…» Так-то оно так, только абсолютно любой процесс состоит из этих этапов. И ответ никак не отражает понимание соискателем процессов тестирования. Больше похоже на читерство… Поэтому позволю себе изложение своего видения:
  1. инициация,
  2. выявление требований прямых и косвенных,
  3. генерация тестовых случаев,
  4. отбор показательных тестовых случаев,
  5. проведение проверок,
  6. фиксация результатов,
  7. анализ результатов,
  8. передача информации о соответствии проверенного продукта требованиям.
Более подробная информация об указанных этапах:

Инициация – событие, которое извещает команду тестирования о необходимости сессии тестирования, а также гарантирует выполнение требований к продукту для проведения тестирования.

Для производства ПО требования включают:

  • доступно необходимое тестовое окружение,
  • доступен билд/ресурс/предмет тестирования,
  • код, БД, прочие компоненты объекта тестирования «заморожены», т. е. не изменяются в период всей сессии тестирования,
  • модификация требований (хотя бы прямых) «заморожена»,
  • известно направление тестирования,
  • известны сроки на сессию тестирования.
Есть и другие условия, но они менее значимы и сильно зависят от конкретного процесса в компании.

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

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

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

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

Проведение проверок – тут все понятно. Либо согласно документации, либо ad hoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок. Почему-то большинство именно этот пункт называет тестированием. И в голове обывателя, незнакомого с профессией, только один этот пункт и содержится J.

Фиксация результатов – создание внутренней и внешней тестовой документации в формализованном виде или в виде записей и т. п. На данном этапе отчет о тестирование даже если и создается, то не считается законченным.

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

Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п. Но это – уже QA J!

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

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

habr.com

Как пройти техническое собеседование: советы девяти программисток

Порепетируйте и найдите знакомых в этой компании

Лиа работает программистом в Google и занимается Google Картами и локальным поиском. До этого она проходила практику в Apple и Facebook. Лиа советует отрепетировать собеседование с другом — пусть он сыграет интервьюера, а вы будете писать перед ним алгоритмы на доске. А еще нужно обязательно заранее изучить проекты компании, в которую вы устраиваетесь, чтобы подготовиться к их обсуждению на собеседовании.

pic

Фото: @leacoligado

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

«Вы удивитесь, как много людей хочет вам помочь, — рассказала Лиа. — Однажды я попросила незнакомого программиста провести для меня экскурсию по офису Twitter, и он не отказался. А я даже не пользовалась этой соцсетью».

Задавайте важные вопросы

Сейдж Франч — разработчик, предпринимательница и автор блога TrendyTechie.ca. Она работает с технологиями блокчейна, смешанной реальности и когнитивных вычислений.

pic

Фото: @thetrendytechie

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

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

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

Показывайте любовь к своему делу

Элисон работает frontend-разработчиком в медицинской компании. Однажды ее подруга дала ей очень ценный совет. «Найти человека, который бы выполнял работу, легко, — сказала она. — Гораздо сложнее найти того, кто искренне полюбит эту работу. Именно эту любовь я и ищу у кандидатов».

pic

Фото: @falkyou

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

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

Превратите собеседование в разговор

pic

Фото: @stephcodes

Стефани работала в таких компаниях, как Google, Facebook, NASA Jet Propulsion Laboratory. Девушка утверждает, что технические собеседования сильно изматывают, поэтому советует следующее:

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

  • Задавайте вопросы. Собеседование — это не экзамен, поэтому можно спрашивать о том, что вам непонятно. Чаще всего Стефани использует фразы вроде «что вы имеете в виду?» или «можете привести пример?». На работе вы ведь тоже будете задавать вопросы коллегам.

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

Стефани советует помнить, что то, что вас пригласили на техническое собеседование, это уже достижение. Успокойтесь, будьте собой и подготовьтесь ко всему заранее.

Сообщите, если вам нужны особые условия работы

pic

Фото: @programm.r

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

Не бойтесь ответить на вопрос с ошибкой

pic

Фото: @jonesdoeslife

Джонна Рутч разрабатывает цифровые решения для клиентов компании Credera. Она считает, что каждый может ошибаться и на собеседованиях никто не ждет от вас энциклопедических знаний того или иного языка программирования, фреймворка или алгоритма. Если вы в чем-то неуверены, проговорите свои доводы вслух. Лучше пройти 90% пути к правильному ответу, чем сидеть молча и выдать стопроцентно неправильный ответ.

Будьте собой

Такой совет дала девушка по имени Рэйчел, которая увлекается медицинскими технологиями и прошла программу Google Summer of Code.

pic

Фото: @secretlifeofcode

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

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

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

Подробно рассказывайте о ваших предыдущих проектах

pic

Фото: @chmodxx

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

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

Не забывайте о своих личных качествах

Оливия Шэнли — программист по образованию. Она считает, что личные качества могут выделить вас на фоне других кандидатов с аналогичными техническими навыками. К таким качествам относится умение адаптироваться и работать в коллективе, энтузиазм, креативность и критическое мышление.

Источник.

Если вы хотите поделиться опытом работы в крупной компании или маленьком стартапе, рассказать о перипетиях своей карьеры и раскрыть секреты профессии, пишите на [email protected]. Лучшие рассказы опубликуем на Rusbase.

Материалы по теме:

«Эти знания пригодятся вам в любой индустрии»: как супермодель Карли Клосс нашла свое призвание в программировании

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

Личный опыт: Как за один год пройти путь от фотомодели до программиста

«Как бы вы протестировали тостер?» 33 вопроса, которые задают на собеседованиях в Apple Актуальные материалы — в Telegram-канале @Rusbase

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

rb.ru

Топ-50 вопросов на собеседовании на должность технического писателя

Топ-50 вопросов на собеседовании на должность технического писателя

31.03.2016

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

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

Рассмотрим Топ-50 вопросов, задаваемых на собеседовании опытным (2-4 года) техписам.

Уверены, что если вы до собеседования изучите эту статью, шансы на эту самую «приятную ноту» существенно вырастут.

Мы разделили вопросы на три основные группы:

 

Основные вопросы

  1. Поговорим о вашем резюме? (Интервьюер может перебить вас и задать вопрос по информации, данной в резюме).
  2. Что вы можете рассказать о себе?
  3. Почему вы выбрали стезю технического писателя?
  4. Вы получали какие-либо сертификаты?
  5. С какими трудностями сталкиваются техписы?
  6. Можете рассказать о рабочих процессах в организации, где вы сейчас работаете?
  7. Что подтолкнуло вас к поискам новой работы?
  8. Как вы относитесь к переработкам?
  9. Каковы ваши трудовые заслуги в организации?
  10. Какую пользу вы можете принести нашей компании?
  11. Можете объяснить разницу между резюме и CV?

 

Технические вопросы

  1. C какими трудностями вы сталкивались при сборе информации?
  2. C какими инструментами вы работали?
  3. Можете объяснить разницу между Ms Word и Framemaker?
  4. Разница между Structured Framemaker и Unstructured Framemaker?
  5. Разница между XML и HTML?
  6. Можете рассказать о процессах DDLC?
  7. Можете рассказать о процессах SDLC?
  8. Как DDLC и SDLC работают в параллели?
  9. Как вы рассчитываете время на создание документации?
  10. Что такое топикоориентированное писательство?
  11. Как вы добываете информацию у экспертов по предмету?
  12. Трудности при сборе информации у экспертов по предмету?
  13. Как вы работаете на UML? или Что такое UML (Унифицированный язык моделирования)?
  14. Вы работали с инструментами видеомонтажа? (напр. Camtasia)
  15. Вы можете предоставить примеры работ?
  16. Сравнительный обзор Robohelp и MS Word?
  17. Что такое условия, накладываемые на текст?
  18. Процедуры вычитки технической документации?
  19. Разница между руководством пользователя и руководством по эксплуатации?
  20. Как вы работаете с документацией по API? (Спрашивают, только если проект связан с документацией по API).
  21. У вас есть опубликованные статьи?

 

Технические вопросы для техписов со знанием английского

  1. Разница между активным и пассивным залогом?
  2. Разница между which и that?
  3. Разница между its и it’s?
  4. Разница между there и their?
  5. Типы придаточных предложений? Что такое рестриктивные и нерестриктивные придаточные?
  6. Типы запятых?
  7. Что вы подразумеваете под выносками?
  8. Расскажите о переводческих процессах?
  9. Когда вы используете Organise, а когда Organize?
  10. Разница между your и you’re?

 

Письменное задание

  1. Вопросы по профессиональным навыкам.
  2. Тест на грамматику.
  3. Отредактировать существующую процедуру (грамматика, словарь, изменить залог, и т.д.)
  4. Создать файл оглавления.
  5. Написать процедуру, используя
  6. Написать процедуры на тему:
  • Как совершить звонок (используя протокол MSTP)
  • Как снять деньги в банкомате?
  1. Описать необходимые навыки и сложности, с которыми сталкивается технический писатель.
  2. Написать обзор на последний просмотренный фильм.

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

 

Желаем удачи!! 🙂

 

Источник: Top 50 question asked in technical writing interview

Тэги: навыки, профессия

protext.su

25 каверзных вопросов, которые задают кандидатам на собеседованиях в Microsoft

Microsoft - одна из крупнейших в мире технических компаний, и многие инженеры (впрочем, не только) из разных стран мира были бы рады получить там работу. Разумеется, это не слишком просто - заурядных туда не берут. Чтобы продемонстрировать собственную незаурядность, на собеседовании (если ваши навыки и опыт окажутся релевантными) придется ответить на несколько нестандартных вопросов. Издание Business Insider нашло на портале Glassdoor, где сотрудники делятся всесторонними впечатлениями о разных компаниях, 25 мини-задачек, которые кандидаты решали на интервью в Microsoft.

Фото: Fotoimedia

Итак, о чем же спрашивали кандидатов на разные позиции?

1. "Придумайте способ, как убедиться, что в холодильнике всегда есть молоко". (Вопрос стажеру на лето.)2. "Приведите нам пример сайта с великолепным дизайном". (Вопрос специалисту по user experience.)3. "Как определить, хорошо или плохо перемешана колода карт?" (Вопрос инженеру по разработке ПО.)4. "Почему бы вам не присоединиться к команде Google?" (Вопрос старшему менеджеру по развитию бизнеса.)5. "Напишите программу, симулирующую написание статьи для журнала". (Вопрос инженеру-программисту.)6. "Что вы думаете о решении Microsoft запустить продукты Office для iPhone?" (Вопрос ведущему специалисту по бизнес-планированию.)7. "Почему канализационные люки круглые?" (Вопрос разработчику ПО.)8. "Как бы вы спроектировали систему шаттлов, чтобы использовать ее в кампусе Microsoft?" (Вопрос менеджеру программы.)9. "Печально известный вопрос о стрелках часов: сколько раз минутная и часовая стрелки "перекрываются" в течение суток?" (Вопрос разработчику ПО.)10. "Ситуация: ваш отдел продаж сделал ошибку в работе с давним клиентом. Как вы будете использовать свое влияние, чтобы поправить дело?" (Вопрос старшему консультанту.)11. "Как будете решать проблему медленного запуска на компьютере/ноутбуке?" (Вопрос специалисту клиентского сервиса.)12. "Объясните пятилетнему ребенку, что такое рекурсия". (Вопрос разработчику ПО.)13. "Расскажите, как бы вы сконструировали аэропорт". (Вопрос менеджеру программы.)14. "Вам дано время, как вы определите угол между часовой и минутной стрелкой?" (Вопрос разработчику ПО.)15. "Как вы формируете отношения с членами команды, которые работают в другой стране?" (Вопрос ведущему администратору.)16. "Создайте GPS для 16-летнего". (Вопрос менеджеру по продукту.)17. "Опишите трудные отношения с коллегой". (Вопрос менеджеру программы.)18. "Составьте список всех употребляемых в романе слов, а также повторов". (Вопрос разработчику ПО.)19. "Если бы вы оказались в лифте с CEO компании, как бы вы рассказали об облаке в течение полутора минут?" (Вопрос аккаунт-менеджеру.)20. "Вы стоите в толпе. Что вы предпримете, чтобы выделиться?" (Вопрос администратору сайта.)21. "У вашего устройства есть стилус. Как вы его храните? Как заряжаете? Какие еще вещи вы можете использовать для этого устройства?" (Вопрос инженеру-механику.)22. "Создайте план исследований для бренда нового носимого продукта". (Вопрос специалисту по исследованиям в области дизайна.)23. "Если бы у вас был выбор между двумя супер-способностями (невидимостью и умением летать), что бы вы выбрали?" (Вопрос ведущему специалисту по продукту.)24. "Самым неожиданным был вопрос от женщины-менеджера, которая хотела, чтобы я поделился ситуациями сексизма и женоненавистничества, которые имели место на прошлой работе. Она задавала мне много вопросов на эту тему". (Вопрос менеджеру программы.)25. "Как вы помогли бы своей бабушке, если бы у нее сломался компьютер?" (Вопрос инженеру службы поддержки.)

Кстати, о компании Google, про которую спрашивали потенциального старшего менеджера по развитию бизнеса. Как писал в своей книге "Работа рулит" вице-президент по человеческим ресурсам Ласло Бок, в Google от такого подхода уже отказались (Microsoft, судя по всему, тоже постепенно отходит от странных вопросов). Головоломки Бок назвал бессмысленными: "Кандидату могут поставить следующую проблему: "Ваш клиент - производитель бумажной продукции. Он рассматривает возможность покупки второй фабрики. Стоит ли ему делать это?" Или: "Сколько, по-вашему, автозаправок на Манхэттене?" Или совсем заковыристо: "Сколько мячиков для гольфа уместится в Boeing 747?" и "Если я уменьшу вас до размера десятицентовика и засуну в блендер, как вы сможете выбраться?" При помощи такого рода вопросов в лучшем случае можно выявить отдельный навык, который можно усовершенствовать практикой, но полезность их в деле общей оценки кандидатов стремится к нулю. А в худшем случае интервьюер будет полагаться на очень малый объем информации или интуитивное видение, озвученные кандидатом, что всего лишь даст первому возможность ощутить чувство глубокого удовлетворения от своей сообразительности. Но с их помощью вряд ли можно (если можно вообще) предсказать, насколько хорош кандидат для конкретной вакансии. Частично это происходит из-за задачи, не соответствующей ситуации (сколько раз в течение рабочего дня вам приходится оценивать количество автозаправок?), частично - из-за отсутствия корреляции между подвижным интеллектом (неплохой критерий результативности) и задачками на интуицию вроде головоломок, а частично потому, что не существует способа отличить человека с врожденным талантом от того, кто просто натренировал тот или иной навык".

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

rb.ru

10 вопросов для собеседования с кандидатом на IT-должность

23.11.2014

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

Поиск IT-сотрудника – дело тонкое, и очень многие лидеры IT-команд поручают его кадровикам. Вот 10 вопросов, которые можно задать соискателям, а также объяснение того, что тот или иной вопрос может вам рассказать о кандидате.

1: Назовите две-три тенденции, которые актуальны для IT-сферы, и как с вашей точки зрения они влияют на вашу профессию?

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

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

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

3: Расскажите о том, как вы себя чувствовали, когда вас просили сделать что-то, чего вы никогда не делали (незнакомые технологии, новые проекты, новая сфера деятельности и т.п.)

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

4: Быстро ли вам становится скучно?

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

5: Какого рода работу вы хотели бы и предпочли бы выполнять на этой должности?

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

6: Как вы хотите, чтобы ваша карьера продолжилась, и чему вы хотели бы научиться, работая у нас?

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

7: Если бы вы могли сделать два-три изменения на вашем прошлом месте работы, что бы вы сделали?

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

8: Задайте вопрос по конкретной сложной ситуации

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

9: Расскажите о «сложном сотруднике»

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

10: Спросите про хобби и т.п. (если это было в резюме)

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

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

« Вернуться назад

Тэги: IT сфера, карьера, бизнес

blog.mbaconsult.ru