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

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

У Вас есть продукт, устоявшаяся команда и финансирование. Вы (команда) хорошо работали, и руководство готово заплатить еще денег чтобы нанять человека, чтобы, соответственно, ускорить разработку, повысить качество и иметь возможность тратить ресурсы на технологическое развитие продукта. Вы уже разместили на hh объявление с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать. Знакомая ситуация? Тогда добро пожаловать под кат.

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

Для начала заметим, что крайне вредно нанимать человека под сиюминутную потребность. Скажем, сейчас у вас слегка «тормозит» разработка серверной части. Значит ли это что надо нанять server-side программиста? Вообще-то нет. Если у вас достаточно активная разработка, то приоритет разных кусков будет неизбежно меняться. В этом смысле глупо нанимать человека под задачу на ближайший месяц. Ведь месяц пройдет, а человек у Вас останется. И если в этом месяце Вы залатаете дыру в server-side разработке, то в следующем выяснится что server-side пишется быстрее чем клепается интерфейс. И что, в следующем месяце надо нанимать UI-программиста? Или уволить «слабое звено» в server-side? Нет, тут стоит подойти по-другому. Посмотрите, чем Вы занимались раньше в разработке продукта. Расспросите продажи, инвесторов или кто там определяет цели для разработки, и постарайтесь построить картину того что ждет вас, скажем, на год вперед. А теперь представьте, какой человек помог бы Вам работать в прошлом и будущем эффективнее. Надеюсь, Вам представился не один человек. Скорее всего окажется, что можно и тут укрепить команду, и здесь. А если где-то окажется слишком крепко (и соответственно где-то - слишком тонко), то кто-то из существующей команды возможно согласится «переключить» род деятельности.

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

Но что же спросить на техническом собеседовании? Составить тест? Выяснить что человек делал на прошлом месте работы? Задать каверзный вопрос? Дать задачку с braingames.ru?
Давайте рассмотрим эти варианты по порядку.

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

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

Чем Вы занимались на прошлой работе?
- Ну там была сложная система моделирующая систему городских коммуникаций с поиском оптимальных маршрутов и (…)
- Что такое алгоритм Дейкстры?
- Эмм, да, и что-то такое я слышал.

Итого - что мы узнали? Да ничего. Какой-то сложный проект. Толком не понятно что за проект, что именно делал этот сотрудник, что он в итоге научился делать хорошо. Мы промотали 5 минут на то, чтобы не выяснить о человеке ничего. Конечно, можно потратить полчаса и разобрать все по полочкам. Но есть два «но».
Во-первых, цените время. Если на каждого кандидата будете тратить по 4 часа, то вы можете просто «не дойти» до действительно стоящего. Вообще, на мой взгляд, собеседование стоит жестко ограничить временными рамками, скажем одним часом. И постараться вытрясти за этот час из человека все, что Вам необходимо для принятия решения.
Во-вторых, не зацикливайтесь на том, кем человек был. Попробуйте оценить, кем бы он мог стать в вашей компании. Ваш кандидат говорит, что на прошлой работе сделал за неделю модуль, который Вы делали месяц? Так может на прошлой работе крутые бизнес процессы и гора готового кода, а у вас он бы делал этот модуль ровно столько же, сколько и Вы? Или Вам показалось, что на прошлой работе кандидат не сделал ничего сколько-нибудь примечательного? Очень может быть. Но может это талантливый человек, прозябавший в третьесортных «рогах и копытах», а у Вас раскроется весь его потенциал! Поверьте, во многих ситуациях за такого человека стоит побороться даже больше, чем за состоявшегося специалиста.

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

- Ну это адрес объекта

И второй вариант:

Что такое Object.hashCode()?
- Да там генератор случайный чисел, вот он и возвращает.

Вы потратили 3 минуты на этот вопрос. Как вы сравните первого и второго кандидата? Можно ли сказать, что один из них лучше другого? Может быть второй листал на досуге grepcode. Или читал хабр вместо работы. А может и не вместо. Но вам-то это что-то говорит?

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

Так что же спросить?

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

Есть фрагмент кода

void x(List a)

…Some processing

Вопрос кандидату - предположим в этом коде нам надо перед «Some processing» отсортировать список в алфавитном порядке. Что будете делать? Кстати да, тут же можно сказать кандидату про Collections.sort - мы же не «словарный запас» проверяем.
Положим наш кандидат написал что-то типа

void x(List a)

List b = new ArrayList(a);

Collections.sort(b);

…Some processing with b

(надеюсь наш кандидат именно так решил эту задачу а не начал сортировать a).

Однако решение задачи тут не главное. Главное дискуссия.
Почему он создал новый список а не использовал старый? Всегда ли это правильно?
Почему использовал ArrayList а не что-то еще? А знает ли он что еще есть?

Самое интересное что дискуссия тут может быть почти бесконечная. Кандидат скажет что ArrayList лучше тем что он random access, а Вы скажите что sort все равно копирует перед сортировкой данные в массив, а потом возвращает обратно. Стал ли ArrayList лучше теперь, по мнений кандидата? Как, уже нет? Или все равно лучше?

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

Или скажем другой пример.

Не спрашивайте «что такое garbage collector». Не спрашивайте «сколько там поколений». Какая разница сколько. Какая разница может или нет человек рассказать как устроен gc - для вашей работы может быть важно только то, сможет ли человек исправить performance проблему если таковая возникнет, а не может ли он поведать душещипательную историю про сборку поколениями или там про concurrent mark sweep gc.
Я не говорю, что кто-то может решать сколько-нибудь интересные проблемы с GC не зная, как он работает. Один раз, конечно, может и повезет. Но на практике знание чрезвычайно важно. Проблема в другом - не каждый, кто может рассказать как что-то работает, может исправить проблему с этим чем-то. И, вообще говоря, интуиция, общая техническая подкованность часто для решения задачи важнее прочитанного где-то описания алгоритма.
Например, для gc хорошо будет привести опять же какую-нибудь практическую задачку.
Скажем, «вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?».

Увеличу хип

А станет ли быстрее? И самое интересное, а разве не стоит перед ответом на этот вопрос спросить, а что такое для меня «быстрее»? Посмотрите, понимает ли кандидат разницу между throughput и latency. Не спрашивайте что это и в чем разница. Если кандидату при вышеописанной постановке задачи не приходит в голову задаться такими банальными вопросами, значит и на практике у него этих вопросов не возникнет. Однако не стоит забывать, что мы ведем беседу. Если кандидат прыгнул с места в карьер, остановите его, расскажите про разные характеристики производительности. Кандидат никогда про них не слышал, но сходу сообразил что рост хипа возможно улучшит одно, но точно ухудшит другое? Ну так это же замечательно!

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

• Подбор и отбор, Оценка, Рынок труда, Адаптация

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

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

Чит-коды для победы 4 боссов, которых вы, возможно, встретите в квесте на получение должности нового разработчика программного обеспечения

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

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

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

Секундочку, что за супер-квест? Что за уровни? Похоже на компьютерную игру, не так ли?

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

Главному игроку (например, Марио, Зельде или Дюку Нюкему) нужно победить всех боссов в игре, чтобы пройти на следующий уровень: совсем как менеджеров в IT-компаниях.

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

- специалист по набору персонала;
- старший разработчик;
- менеджер по программному обеспечению;
- CTO.

Готовы? Отлично! Начинаем со схватки со специалистом по набору персонала из отдела кадров на первом уровне.

1 уровень: Босс, специалист по набору персонала

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

Дженифер Лоффус, региональный директор компании Astron Solutions, бывший президент ассоциации специалистов по работе с персоналом Нью-Йорка.

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

Существует мнение, что у кадровиков только одно желание - заваливать кандидатов на новую должность. Помните Тоби из сериала «Офис»? Так вот, его образ специалиста отделов кадров сильно приукрашен.

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

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

Не высылайте резюме с ошибками

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

Не высылайте слишком длинное резюме

Вы многого добились в карьере и хотите об этом рассказать. А кадровик хочет понять, подходите ли вы на конкретную позицию, при этом у него очень мало времени на знакомство с вашим резюме. Отредактируйте свое резюме так, чтобы оно подходило именно на ту вакансию, на которую вы его подаете. Резюме должно содержать 500 - 1000 слов и быть длиной максимум в две страницы. Используйте 12 шрифт, чтобы текст было удобно читать (а не 8 или 9).

Не высылайте общих резюме и мотивационных писем

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

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

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

Приходите заранее и хорошо подготовленным

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

Оденьтесь в официальном стиле

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

Приведите себя в порядок

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

Сосредоточьтесь!

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

Почти 2 уровень!

Проверьте, что вы правильно одеты, приятно пахнете и полностью настроились на собеседование. И вот вы на финишной прямой 1 уровня! Помимо того, что вы обладаете всеми навыками и опытом, нужными для данной должности, необходимо…

Поддерживать зрительный контакт

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

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

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

Приготовьтесь рассказать о прошлых работодателях

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

Говорите понятными словами

Программные разработчики используют много аббревиатур: ASP, CAO, GAC, IIS и т.д. Во время беседы с кадровиком (возможно, без технического образования), расшифровывайте каждую аббревиатуру, когда будете называть ее в первый раз. Убедитесь, что вы говорите понятным для собеседника языком, чтобы не провоцировать новые вопросы.

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

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

- Что вам больше всего нравится в организации?
- Почему вы здесь работаете? Люди любят рассказывать о себе!
- Каким образом информационные технологии поддерживают планы компании по развитию?
- Какие ошибки обычно допускают новые сотрудники?

Скажите «спасибо»

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

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

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

Как это бывает

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

В целом, такой подход бывает эффективен, но он имеет ряд недостатков:
1. Существует вероятность, что в собеседующий технический специалист может воспринять несоответствие опыта соискателя его собственному, как отсутствие опыта вообще. Например, могут быть заданы довольно узко-практические вопросы, с которыми соискатель не сталкивался на практике, что может быть истолковано как «Да как же можно такое не знать, это же так просто». А специалист от кадров, никогда не сможет это распознать в силу специфики контекста.
2. Даже если будут заданы открытые вопросы вида «А какие задачи вам приходилось решать?», опять же, несоответствие опыта может быть истолковано как «Он нам не подходит, потому что он не делал то, чем мы занимаемся уже несколько лет».
3. Отдельные технические специалисты, особенно уже с довольно большим опытом, мало признают тот факт, что незнание конкретных инструментов не является зачастую большим препятствием. Например, если человек не работал с GIT, но хорошо знает CVS, это значительно сокращает порог входа в обладание инструментом.
4. Также может иметь место проблема, когда соискатель обладает большим практическим опытом и хорошо отвечает на вопросы по конкретным решениям, но когда его берут на работу, внезапно, выясняется что он допускает довольно типичные ошибки в областях, с которыми он до этого не работал. Про таких людей складывается впечатление, что они «тупят на ровном месте» или «активно копипастят код» из своих предыдущих проектов.
5. Порой попадается специалист, который производит впечатление новичка и его резюме показывает малый практический опыт, но важно понять «выстрелит ли он». Потому что если выстрелит, вы можете малыми вложениями получить хорошую «звезду» в команду. И не понятно как это распознать максимально точно.

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

Классификация знаний

Для начала нужно определиться с классификацией знаний. Для этого их надо разбить на 3 вида:
1. Фундаментальные – это базовые знания в конкретной области. Например, это может быть вопрос «Какие основные виды запросов в SQL вы знаете?».
2. Прикладные – это навык решения конкретных задач. Например, это могут быть задачи на правильное написание SQL запросов для конкретных примеров.
3. Инструментальные – это знания о том, как применять конкретные инструменты. Например, в чем различие между innodb и myisam хранилищами?

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

Когда что-то пошло не так

Так как «академическое образование» в области ИТ все еще довольно слабо, большинство специалистов во многом являются самоучками. Это создает определенные отклонения, которые хорошо можно понять на данной модели если гипертрофировать одну из областей знаний. Приведу классические портреты кандидатов и их объяснение:
1. Всезнайка – имеет значительный объем фундаментальных знаний, например приобретенных в рамках каких-либо курсов и чтения книг/статей, однако, практических навыков их применения не имеет, что его никак не смущает. Даже если вы начнете его спрашивать какие-то практические задачи, вы всегда услышите массу знаний о том как это на самом деле должно работать, как устроены отдельные части, но собрать все вместе для решения задачи, без ваших подсказок, такому кандидату будет довольно сложно. Довольно частая ситуация если спрашивать кандидата про мало используемые паттерны ООП: услышите описание паттерна, когда его применяют на каком-нибудь академическом примере, но встраивание в живую задачу будет идти «со скрипом».
2. Stackoverflow-разработчик – обычно, такие разработчики довольно активно рассказывают про свой опыт, про то какие задачи и как им удавалось решать, но при попытке ответить на вопрос «А как сделать…?» из неизвестной им практической области, вы услышите или попытку «притянуть за уши» другое решение, или же ответ в стиле «Да это гуглится за 5 минут, я уже такое где-то видел». Подобные разработчики часто стараются притянуть какие-то готовые решения, которые они уже делали, аргументируя это как «Зачем делать 2 раза?», либо же просто копипастят код из интернета и других проектов. При вопросах «А почему это работает именно так?» или «А как это можно сделать по-другому?» часто могут теряться и пытаться перевести тему.
3. Tools&Frameworks-разработчик . Есть старый анекдот: «Как начать делать сайт в 1995 году? Открыть блокнот и начать писать код. Как начать делать сайт в 2015 году? Скачать и установить composer, framework, cms-extension, bootstrap, jquery, bower, less, поставить IDE, начать писать код». Вот примерно тоже самое для подобного рода специалистов. Большая часть прикладного опыта таких специалистов связана исключено с конкретным инструментом. Такое понятие как «bitrix головного мозга» вполне конкретно характеризует этот случай. Для таких кандидатов очень сложно даются задания по «нативному» коду, потому как без инструмента для них это практически невозможная задача.
Данные примеры приведены для случаев, когда одна из областей знаний занимает ведущую позицию, а так как ощущение «превосходства» в этой области зарождает чувство собственного «величия», то специалист старается удержаться за нее всеми возможностями («каждый хочет быть крутым»). Например, Stackoverflow-разработчик, при попытке выяснения фундаментальных знаний, до последнего будет аргументировать к тому, что «да мне это и не нужно знать, я такое уже сто раз делал и все и так работало».

Как работает эффективное развитие

Самым эффективным же сценарием развития знаний является именно баланс между областями. Достигать его можно разными способами, но нельзя допускать именно «перекоса». Например, вы захотели сделать домашнюю страничку и ничего в этом не понимаете (все с этого начинали): скачали wordpress (взяли «инструмент»); загуглили как все настроить и сделали свой первый блог с несколькими статьями (приобрели прикладные знания); а теперь разберитесь как и почему это работает, например как устроена база и кеш, какова архитектура движка и т.п. (приобретите фундаментальные знания). Дальше можно уже и посмотреть какие еще инструменты и как могут решать эту задачу, либо написать свой инструмент. Если же остановиться только на первом или втором шаге, то можно легко попасть в одну из категорий специалистов, приведенных выше, а вы, я уверен, явно не этого желаете:)

Как оценивать знания

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

Например: Что такое составные b-tree индексы и как они работают? А можете привести пример, когда могут потребоваться такие индексы или когда наоборот они будут неуместны? А как понять, что данные индексы работают эффективно и что вообще можно для этого использовать?

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

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

Типичные ошибки при оценке

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

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

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

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

На что обращать внимание

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

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

Стратегия интервьюирования

Предварительно, до собеседования, составьте список ключевых областей, в которых вам требуется опыт от специалиста. Хорошо, если их будет не менее 10. Например: PHP + паттерны ООП; SQL + оптимизация запросов; архитектура высоконагруженных проектов; работа с кешом и т.п.
В каждой из ключевых областей составьте минимум по 5 вопросов для каждого вида знаний, итого минимум по 15 вопросов на каждую область. Это сделать лучше для того, чтобы не придумывать вопросы на ходу. Желательно, чтобы такие вопросы обеспечивали между собой вертикальную связанность.

Например:
Область: архитектура высоконагруженных проектов.
Фундаментальные вопросы: Какие основные параметры важно учитывать при проектировании высоконагруженных систем? Какие типовые архитектурные решения вы знаете? В чем отличие горизонтального и вертикального масштабирования?
Прикладные вопросы: Если пользователи могут загружать файлы, то каким образом лучше решить вопрос их горизонтального масштабирования на отдачу? Если имеется страница с высоким RPM, и информационным блоком, который имеет длительное время генерации, то каким образом можно ускорить отдачу страницы? Если в проекте в результате роста нагрузки узким местом стала единственная база данных, то каким образом лучше подойти к этому вопросу?
Инструментальные вопросы: Какие инструменты можно использовать для балансирования нагрузки HTTP траффика? Какие кеширующие сервера вы знаете и в чем их отличия? Каким образом можно измерять производительность приложения при больших нагрузках?

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

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

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

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

Где еще можно использовать модель

Приведенная модель, на самом деле, может быть использована не только для технических специалистов, но и вообще для любой профессии. Разница будет лишь в том, насколько полно реализованы отдельные виды знаний в этих областях. Возьмем, для примера, дворника: Какие критерии чистоты вы знаете? Если вам нужно убрать за один день 10 домов, как это лучше сделать? Для каких поверхностей какие средства для уборки лучше использовать?

В качестве заключения

Недавно я решил собрать свои заметки по вопросам на собеседования для PHP-разработчиков и выложить их в открытый доступ (проект «на коленке», так что не обессудьте). Там, конечно, не все, но хватит для того, чтобы собрать мысли вместе и настроиться на проведение собеседования. Вы можете посмотреть вопросы по ссылке:
pagerton.com/hr/question/all
Если будут позитивные отклики, то буду развивать проект по мере возможности, хотелось туда еще скинуть ссылки по хорошим курсам для разработчиков, так что буду признателен за обратную связь.
Надеюсь, эта модель сможет быть полезна и вам. Не только как собеседующим, но и как собеседуемым, потому как понимание своих сильных и слабых сторон поможет вам эффективнее развиваться.
Желаю вам быть лучшими, и работать с лучшими.

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

Введение

2. Протестируйте лифт!

Итак, Вы рассказали, что такое классы эквивалентности и граничные значения. Пришло время проверить, умеете ли Вы их использовать. И вот, Вас просят протестировать лифт. Или карандаш. Или калькулятор, джинсы, чашку. Неважно что. Задача – скорее всего непривычная и нестандартная. Что ждёт от Вашего ответа работодатель?

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

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

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

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

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

3. Расскажите, как создавать тест-кейзы

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

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

Этот вопрос, как и предыдущий, тоже распространён достаточно часто. Google поможет Вам быть к нему готовым.

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

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

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

К примеру, если Вы неудачно ответили на вопрос про MS SQL, скажите сами, что зато Вы имеете опыт работы с Oracle и поэтому быстро сможете «перепрофилироваться».

Способность быстро и самостоятельно разобраться в незнакомой технологии или инструменте ценятся выше, чем имеющиеся знания. Не стесняйтесь хвалить себя. Если после Ваших слов о том, что Вы не разбираетесь в Rational Robot, собеседующий немного поник – гордо скажите, что зато в Silk Test Вы разобрались всего за неделю и сумели многое (конкретизируйте) в нём сделать. Естественно, здесь тоже говорить нужно правду!

Главное – не бояться. Вы ищете работу, а работодатель ищет грамотного сотрудника. Вы оба заинтересованы в результате. Быть принятым на неподходящую работу – значительно хуже, чем получить отказ. Пробуйте, не нервничайте, учитесь! И развивайтесь для себя – а не для «галочки» на собеседовании. Удачи !

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

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

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

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

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

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

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

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

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

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

• Добейтесь совершенства в телефонных собеседованиях от Monster
• 7 шагов на пути к достижению вершин мастерства телефонного собеседования

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

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

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

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

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

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

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

Ссылки

• Разбиремся с собеседованием для программистов это ОБЯЗАТЕЛЬНЫЙ К ПРОЧТЕНИЮ МАТЕРИАЛ , который станет вашим лучшим другом. Он всесторонне рассматривает все виды задач, с которыми вы столкнетесь на собеседовании. Он выходит за рамки того, что мы уже изучили в этом курсе и затрагивает такие вещи, которые хорошо было бы знать, потому что скорей всего вы с ними встретитесь. Потратьте время на то, чтобы познакомиться с как можно большим количеством материала.
• Interviewing.io дает вам шанс попрактиковать анонимно и онлайн техническое собеседование.
• Как получить высшую оценку на техническом собеседовании
• Как выделиться на следующем собеседовани на должность веб-разработчика
• Прочитайте 40 ключевых концептов информатики, объясненных доступным языком
• Руководство для развития технических навыков от Google (для продвинутых)

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

• 8 королев - это классическая задача.
• Программирование на собеседоваии: знай стандартные библиотеки может оказаться перебором для начинающего, но никогда не повредит, если вы найдете на него время.
• На Project Euler вы найдете более обобщенные и сложные задачи, которые нужно эффективно решить (они могут потребовать большого объема вычислений).
• На Coding Bat опубликованы практические вопросы для Java и Python.

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

• Курс по алгоритмам от Udacity (несинхронизированны)
• Курс по алгоритмам от Coursera (частично-синхронизированный)

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

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

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

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

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

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

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

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

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

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

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