Подготовка к собеседованию в сфере веб-разработки и само собеседование. Что такое техническое собеседование

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

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

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

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

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

Собеседование с позиции соискателя

1. «Какое ещё техническое собеседование?»

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

2. «Ну и чем вы там занимались в этом своём…»

3. «Что-то у вас имя/фамилия/отчество в резюме неправильно написано!»

4. «Сколько шариков для гольфа понадобится, чтобы помыть все круглые окна в школьном автобусе, уменьшенном до размеров пятицентовой монеты, во время эвакуации из Сан-Франциско, используя не более 3 взвешиваний?»

5. «Неправильно. Дальше.»

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

1. «Какие-то у вас вопросы теоретические. Я не силён в теории, я закалён в практике! Давайте лучше тестовое!»

• чем сравнение по == отличается от сравнения по equals в Java?
• расскажите, как устроена хэш-карта.
• объясните своими словами, что такое REST.
• что такое транзакции и зачем они нужны?

2. «Не ожидал здесь испанскую инквизицию! У вас прямо как на экзамене в институте. Обычно просто спрашивают, где работал, что делал»

3. «Мне и не нужно это знать, я специализируюсь на более высокоуровневых задачах!»

4. «А сами-то! / А покажите ваш код! / А вот я зашёл к вам на GitHub, а там такое...»

5. «Вы не правы!»

Заключение

habr.com

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

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

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

Фото: @leacoligado

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

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

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

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

Фото: @thetrendytechie

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

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

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

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

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

Фото: @falkyou

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

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

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

Фото: @stephcodes

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

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

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

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

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

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

Фото: @programm.r

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

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

Фото: @jonesdoeslife

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

Будьте собой

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

Фото: @secretlifeofcode

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

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

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

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

Фото: @chmodxx

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

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

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

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

Источник.

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

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

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

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

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

rb.ru

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

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

Шпаргалка для технического собеседования / Блог компании Mail.Ru Group / Хабр

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

Основы структур данных

Массив

Определение:

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

Что вам нужно знать:

• Массив оптимален для индексирования; плох для поиска, вставки и удаления (если не делать этого в самом конце массива).
• Основная разновидность — линейные массивы, или одноразмерные.
  • Их размер статичен, то есть при объявлении линейного массива задаётся фиксированный размер.
• Динамические массивы подобны линейным, но в них зарезервировано пространство для дополнительных элементов.
  • При заполнении динамического массива его содержимое копируется в массив большего размер.
• Двумерные массивы имеют два индекса x и y, как сетки или вложенные массивы.

Эффективность («О» большое):

• Индексирование: линейный массив — O(1), динамический массив — O(1).
• Поиск: линейный массив — O(n), динамический массив — O(n).
• Оптимизированный поиск: линейный массив — O(log n), динамический массив — O(log n).
• Вставка: линейный массив — недопустимо, динамический массив — O(n).

Связный список

Определение:

• Данные хранятся в узлах, указывающих на другие узлы.
  • Узел содержит один элемент данных и одну ссылку (на другой узел).
  • Связный список соединяет узлы друг с другом с помощью ссылок от одного узла к другому.

Что вам нужно знать:

• Связный список разработан для оптимизирования вставки и удаления. Медленно работает при индексировании и поиске.
• Двусвязный список содержит узлы, которые ссылаются на предыдущие узлы.
• Кольцевой связный список — это простой связный список, хвост которого (последний узел) ссылается на голову (первый узел).
• Стек обычно реализуется с помощью связных списков, но может быть создан и из массивов.
  • Стеки — это LIFO-структуры данных (last in, first out).
  • Голова связного списка, лежащего в основе стека, единственное место для вставки и удаления элементов.
• Очереди тоже могут быть реализованы с помощью связного списка или массива.
  • Очереди — это FIFO-структуры данных (first in, first out).
  • Очередь представляет собой двусвязный список, в котором элементы удаляются из головы, а добавляются в хвост.

Эффективность («О» большое):

• Индексирование: связный список — O(n).
• Поиск: связный список — O(n).
• Оптимизированный поиск: связный список — O(n).
• Вставка: связный список — O(1).

Хэш-таблица

Определение:

• Данные хранятся в виде пар ключ-значение.
• Хэш-функции принимают ключ и возвращают выходные данные, соответствующие только этому ключу.
  • Этот процесс называется хэшированием: однозначным сопоставлением друг другу входных и выходных данных.
  • Хэш-функции возвращают для данных уникальные адреса в памяти.

Что вам нужно знать:

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

Эффективность («О» большое):

• Индексирование: хэш-таблицы — O(1).
• Поиск: хэш-таблицы — O(1).
• Вставка: хэш-таблицы — O(1).

Двоичное дерево

Определение:

• Двоичное дерево — это такая структура данных, в которой каждый узел имеет максимум два дочерних элемента.
  • Дочерние элементы бывают левым и правым.

Что вам нужно знать:

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

Эффективность («О» большое):

• Индексирование: двоичное дерево поиска — O(log n).
• Поиск: двоичное дерево поиска — O(log n).
• Вставка: двоичное дерево поиска — O(log n).

Поиск

Поиск в ширину

Определение:

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

Что вам нужно знать:

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

Эффективность («О» большое):

• Поиск: поиск в ширину — O(|E| + |V|).
• E — количество рёбер (граней?).
• V — количество вершин.

Поиск в глубину

Определение:

• Поиск в глубину — это алгоритм, ищущий по дереву (или графу) сначала в глубину начиная с корня.
  • Алгоритм идёт по дереву, переходя между уровнями по левым дочерним узлам, пока не дойдёт до самого низа.
  • Завершив проход по ветви, алгоритм возвращается обратно, просматривая правые дочерние узлы этой ветви. Причём, если возможно, выбирает самые левые из узлов, расположенных справа от предыдущего маршрута.
  • Завершив просмотр всей ветви, алгоритм переходит к узлу, расположенному справа от корня, и снова идёт по левым дочерним узлам до самого дна.
  • Последним анализируется крайний правый узел (расположенный справа от всех своих предшественников).

Что вам нужно знать:

• Алгоритм оптимален для поиска по дереву, чья глубина превышает ширину.
• Для работы алгоритма используется стек.
  • Поскольку стек является LIFO-структурой, ему не нужно отслеживать указатели узлов, поэтому потребляется меньше памяти, чем в случае с поиском в ширину.
  • Когда алгоритм не может дальше идти по левой стороне, он начинает анализировать стек.

Эффективность («О» большое):

• Поиск: поиск в глубину — O(|E| + |V|).
• E — количество рёбер (граней?).
• V — количество вершин.

Сравнение поисков в ширину и в глубину

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

Нюансы:

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

Эффективная сортировка

Сортировка слиянием

Определение:

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

Что вам нужно знать:

• Это один из фундаментальных алгоритмов сортировки.
• Данные делятся на как можно более маленькие наборы, которые потом сравниваются.

Эффективность («О» большое):

• Наилучший вариант сортировки: сортировка слиянием — O(n).
• Средний вариант сортировки: сортировка слиянием — O(n log n).
• Худший вариант сортировки: сортировка слиянием — O(n log n).

Быстрая сортировка

Определение:

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

Что вам нужно знать:

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

Эффективность («О» большое):

• Наилучший вариант сортировки: быстрая сортировка — O(n).
• Средний вариант сортировки: быстрая сортировка — O(n log n).
• Худший вариант сортировки: быстрая сортировка — O(n^2).

Пузырьковая сортировка

Определение:

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

Что вам нужно знать:

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

Эффективность («О» большое):

• Наилучший вариант сортировки: пузырьковая сортировка — O(n).
• Средний вариант сортировки: пузырьковая сортировка — O(n^2).
• Худший вариант сортировки: пузырьковая сортировка — O(n^2).

Сравнение алгоритмов сортировки слиянием и быстрой сортировки

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

Основные типы алгоритмов

Рекурсивные алгоритмы

Определение:

• Как следует из определения, этот алгоритм вызывает самого себя.
  • Рекурсивный сценарий — когда условный оператор используется для запуска рекурсии.
  • Базовый сценарий — когда условный оператор используется для прерывания рекурсии.

Что вам нужно знать:

• Слишком глубокий уровень стека и переполнение стека.
  • Если при работе рекурсивного алгоритма вы столкнулись с чем-то из перечисленного, значит, вы всё испортили.
  • Это означает, что базовый сценарий не был ни разу запущен из-за ошибок, либо проблема была столь серьёзной, что у вас кончилась память, прежде чем рекурсия была прервана.
  • Знание того, сможете ли вы достичь базового сценария, является неотъемлемой частью правильного использования рекурсии.
  • Такие алгоритмы часто используются при поиске в глубину.

Итеративные алгоритмы

Определение:

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

Что вам нужно знать:

• Обычно итерации представлены в виде циклов, выражений for, while и until.
• Итерация — это однократный проход по набору данных.
• Такие алгоритмы часто применяются для обработки массивов.

Сравнение рекурсивности и итеративности

• Отличить рекурсивность от итеративности бывает сложно, поскольку обе они используются для реализации друг друга. Однако:
  • Рекурсивность обычно более выразительна и проста в реализации.
  • Итеративность потребляет меньше памяти.
• Функциональные языки склонны к использованию рекурсивности (например, Haskell).
• Императивные языки склонны к использованию итеративности (например, Ruby).
• Больше информации вы можете получить из поста на Stack Overflow.

Псевдокод прохождения по массиву (вот почему для этого применяется итеративность)

Жадные алгоритмы

Определение:

• Жадными называют алгоритмы, выбирающие только ту информацию, которая удовлетворяет определённым критериям.
• Жадный алгоритм содержит пять основных компонентов:
  • Набор кандидатов (candidate set), на основе которого создаётся решение.
  • Функция выбора, которая решает, какой лучший кандидат будет добавлен в решение.
  • Функция обоснования (feasibility function), которая решает, может ли кандидат внести вклад в решение.
  • Целевая функция (objective function), которая присваивает значение решению или частичному значению.
  • Функция решения (solution function), которая сигнализирует о том, что мы нашли полное решение.

Что вам нужно знать:

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

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

Этому алгоритму не нужно сравнивать друг с другом все разницы, что экономит нам целую итерацию.

habr.com

Подготовка к собеседованию и само собеседование || CodenameCRUD

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

Конечно, мы далеки от того, чтобы пытаться разобраться с вашими психологическими барьерами и преодолеть их, но совершенно точно лучше всего было бы рассматривать собеседования как шанс показать все те классные вещи, которые вы создали, и те интересные новые навыки, которые вы освоили. Лучшие собеседования - это полные энтузиазма разговоры с техническим уклоном.

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

В чем заключается весь этот процесс

Просто небольшой обзор процесса, через который проходит средняя техническая компания при найме разработчиков:

1. Предварительное собеседование по телефону (Phone Screen)
2. Техническое собеседование
3. Тестовое техническое задание
4. Последующие собеседования, чтобы убедиться, что вы подходите (Fit Interviews)
5. Предложение работы (Job Offer)
6. Обсуждение условий предложения (Offer Negotiation)
7. Принятие предложения (Offer Acceptance)

Предварительное собеседование по телефону

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

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

ФИНАЛЬНОЕ ПРИМЕЧАНИЕ - это не универсальный метод и многие компании пропускают его, чтобы сразу же нырнуть в глубины технического собеседования, поэтому вам нужно приготовиться просто на всякий случай. Ссылка ниже на Coding Horror самая иллюстративная для этого случая.

Техническое собеседование

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

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

Решая задачу, убедитесь, что делаете это понятным и логичным способом, вслух поясняя, почему вы делаете тот или иной шаг. Проговорите все встреченные препятствия и приведите примеры того, как вы решили бы это в "реальном мире". Зачастую ответом является "погуглить" какую-то определенную функцию. Так и скажите! Они знают, что вы не эксперт Ruby, но они должны знать и то, что вы способны находить решения проблем, с которыми неизбежно столкнетесь на работе.

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

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

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

Ссылки

Тестовые задачи на программирование:

Обучение алгоритмам:

Архитектура:

Техническое тестовое задание

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

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

Финальное собеседование ('Fit')

Последним шагом перед принятием решением обычно является знакомство с командой и офисами в течение нескольких часов. Возможно, вас проверят технически, но основная цель - это удостовериться, что вы будете хорошим коллегой. Если какой-то другой член команды скажет, что вы не сработаетесь, вас скорей всего не возьмут. Совет? Не нужно быть странным или неловким, даже если вы дома :)

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

Немного о заработной плате

Не. Озвучивайте. Ваши. Зарплатные. Ожидания.

Вас всегда спросят "сколько вы хотели бы получать?" Ваш ответ? "Я хотел бы получать среднерыночную оплату" (если только вы не настолько наглы, чтобы просить выше рыночной. Посмотрим, как это у вас получится). Вы ничего не выиграете, назвав уровень желаемой зарплаты. Если она окажется ниже, чем они хотели вам предложить, они просто снизят этот уровень. А если выше, то они просто прервут весь процесс, решив, что вы слишком дороги для них.

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

Поделиться уроком:

codenamecrud.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. инициация,
2. выявление требований прямых и косвенных,
3. генерация тестовых случаев,
4. отбор показательных тестовых случаев,
5. проведение проверок,
6. фиксация результатов,
7. анализ результатов,
8. передача информации о соответствии проверенного продукта требованиям.

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

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

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

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

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

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

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

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

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

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

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

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

habr.com

Пройди техническое собеседование (уровень 4) / Блог компании MBA Consult / Хабр

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

Автор: Бен Вейс, специалист по вопросам стратегии интернет-маркетинга в Infusive Solutions. Особая благодарность Грегу Мейеру, техническому директору Strategic Technology Consulting, LLC.

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

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

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

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

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

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

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

Поддерживайте разговор на темы, выходящие за рамки разработки программного обеспечения

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

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

Выражайте желание развиваться вместе с компанией

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

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

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

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

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

Заключение

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

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

Соответственно, убедитесь, что вы совмещаете общие полезные рекомендации с собственным здравым смыслом и настойчивыми поисками.

P.S. Рекомендуем ещё одну статью по теме — Ежедневные ритуалы чтения, которые повысят вашу продуктивность.

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

habr.com

• 
  Раскрутка инстаграм бесплатно онлайн
• 
  Как майнить эфир классик
• 
  Bitcoin generator отзывы
• 
  Пример создания сайта
• 
  Как платить по кредитной карте
• 
  Лизинг как получить
• 
  Вконтакте раскрутка аккаунта
• 
  Варианты работы на дому
• 
  Логистика и ее задачи
• 
  Работа для беременных на дому
• 
  Заработок на обмене валют в интернете