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

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

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

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

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

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

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

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

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

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

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

    Заключение

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

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

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

    При этом «модели» используются самые разные. В гугле когда-то считали, что человек, который сможет ответить на вопрос: сколько шариков для гольфа влезет в багажник Lexus LS470 является хорошим программистом и сможет успешно решать их задачи. Майкрософт когда-то использовал похожий подход (вспомните «Чтобы сделал мистер Фейнман» Эрика Липперта), а сейчас они садят кандидата за стол и просят его покодить. Очевидно, что эта модель также не совершенна, ведь она не соответствует реальному миру, ведь мы никогда не кодим на работе, когда от этого зависит наша судьба, а наш начальник при этом заглядывает в код через наше левое плечо.

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

    ПРИМЕЧАНИЕ
    Помимо отечественного аутсорса подобные тип собеседований активно используется и в некоторых компаниях в США. Например, в Нью Йорке большинство собеседований очень напоминают киевские;)

    Кого мы хотим найти?

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

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

    Так что планка в наши компании несколько ниже, ключевые критерии совпадают: нам нужно найти человека, который умеет думать, решать задачи и доводить дело до конца (кстати, именно умение довести дело до конца Бертран Мейер считает самой полезной чертой разработчика, о чем он поведал в своем недавнем интервью).

    ПРИМЕЧАНИЕ
    Я тут здорово все упростил, поскольку процесс отбора существенно сложнее. Как минимум нужно учитывать человеческие качества, ведь даже rock star разработчику стоит отказать, если из-за него развалится вся команда.

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

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

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

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

    Узнайте, как человек думает

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

    Например, вполне нормальным попросить реализовать StringBuilder самостоятельно или спросить о том, как он реализован в.NET. При этом значительно интереснее обсуждать этот вопрос, когда кандидат не знает решения. Тут можно затронуть компромиссы между эффективностью реализации методов Append и ToString , подумать о выборе структуры данных и т.п..

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

    Никаких вопросов из "тестов"

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

    Меня всегда очень беспокоит, когда на собеседовании задается вопрос следующего вида: "Скажите, а какой тип возвращаемого значения должен быть у перегруженного оператора = в С++? Ссылка или константная ссылка?". Особенно печально, когда ответ на этот вопрос просто записывается на бумажке и интервьюер переходит к следующему подобному вопросу.

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

    Сосредоточьтесь на фундаментальных вещах

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

    Обычно под фундаментальными вещами я понимаю ключевые концепции: основы типов в.NET, основы сборки мусора и проблемы управления ресурсами; основы языка C# типа делегатов, событий, замыканий. Фундаментальные вещи из области проектирования, типа cohesion & coupling, проблемы наследования/агрегации, опасностей изменяемости и т.п; паттерны проектирования, отношение к ним и их роль в арсенале разработчика. Основы алгоритмов, можно в привязке к платформе ("Что будет если метод GetHashCode будет всегда возвращать 42?") и т.п.

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

    Определите свой уровень по шкале от 1 до 10

    Я уже несколько лет пользуюсь подходом, подсмотренным когда-то у Эрика Липперта и в качестве первого вопроса собеседования задаю следующий: "Определите, пожалуйста свой уровень знания языка C# по шкале от 1 до 10, где 1 – это уровень моей мамы, преподавателя математики, а 10 – уровень автора языка C# – Андерса Хейлсберга.".

    Это довольно распространенный вопрос, но для меня он не самодостаточен (хотя бывает любопытно услышать от синьера, что его уровень ниже 6 или выше 8). После этого вопроса я всегда задаю второй: "Ок, ваш уровень 8, а какие именно знания перевели вас с уровня 7 на уровень 8?".

    Польза такого подхода в том, что можно узнать следующее: (1) чем человек интересуется и интересуется ли чем-то вообще, и (2) можно пропустить ряд простых тем, если кандидат говорит о недавнем изучении каких-то продвинутых вещей. Так, если кандидат говорит, что он узнал о сегментах в GC и Card Table, о реализации обобщений, деревьях выражений, о проблемах изменяемых значимых типах или о генерации IL-кода, то вполне можно пропустить базовые вопросы, типа разницы между ссылочными и значимыми типами и углубиться в более серьезные подробности.

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

    ПРИМЕЧАНИЕ
    Не так давно на rsdn было обсуждение этого вопроса: "Как вы оцениваете... по 10ти бальной шкале?" , в котором я также принял участие .

    Тяните за ниточку

    Я очень редко провожу собеседование по бумажке. Обычно происходит следующее: берется несколько ключевых вопросов (таких себе "якорей"), на основе которых строится все обсуждение. Ответ на вопрос n зачастую дает почву для вопроса n+1, который в свою очередь дает почву для следующих вопросов.

    Обычно даже невинный вопрос, типа, а зачем нужен интерфейс IDisposable приводик к обсуждению управляемых и неуправляемых ресурсов, Dispose-паттерна, откуда легко перейти к обсуждению стандартов кодирования (поскольку все эти вещи описаны в Framework Design Guideline).

    Аналогично, невинный вопрос, типа "А атомарна ли операция i++, где i – это System.Int32?" может послужить хорошим началом разговора, поскольку наверняка даст почву к другим темам, таким как неизменяемость и многопоточность, проблеме гонок, вопросам об атомик операциях и многим другим.

    Именно поэтому мне нравится сверх простая задача следующего вида:

    class Foo
    {
    public event EventHandler MyEvent;
    private readonly int _syncRoot = 42 ;public void RaiseMyEvent()
    {
    Monitor . Enter(_syncRoot);
    try
    {
    if (MyEvent != null )
    MyEvent(this , new EventArgs ());
    }
    finally
    {
    Monitor . Exit(_syncRoot);
    }
    }
    }

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

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

    Насколько "технологическое" интервью эффективно?

    Есть ли связь между знанием языка C# и умением решать производственные задачи? Тут все не так просто. Можно выделить две крайние ситуации.

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

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

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

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

    Интервью – это двусторонний процесс

    Для любого специалиста собеседование является двусторонним процессом: интервьюер оценивает кандидата, а кандидат оценивает компанию посредством оценки интервьюера.

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

    Можно подумать, что это лишь мое личное наблюдение, и не каждый интервьюер готов спрашивать C# MVP о языке C# (хотя лично я не вижу в этом ни каких проблем). Но ведь такую же картину видят и многие мои коллеги, которые проходят собеседования на Senior или даже Middle позиции.

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

    З.Ы. Если так уж случилось, что вы были на моих собеседованиях (Земля ведь квадратная;), будет интересно услышать ваше мнение о нем.

    09.07.2016

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

    Бенджамин Вейсс из компании 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: старшего разработчика.



    Тэги:

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

    Диалог из жизни:

    Кандидат: Мы должны выполнять операцию «А» до тех пор, пока не выполнится условие «Б».
    Я: Отличный план. Давай его реализуем.

    Кандидат пишет цикл в стиле for each. Хотя очевидно . Если кандидат прошел этот уровень, он рано или поздно станет хорошим программистом. Но 70% соискателей отваливаются здесь.

    Богдан Гусев, СТО

    Исправим это досадное неразумение.

    while (bool offer == false){

    Правило 0

    Если вы собеседуетесь на роль java-девелопера, необходимо хорошо знать java и смежные технологии

    //Без комментариев.

    Правило 1

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

    Заранее выясните у рекрутера все возможные подробности о проекте.

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

    Александр Питц, Project Manager

    Правило 2

    Не врите в резюме

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

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

    Правило 3

    Соотнесите свои ценности с ценностями компании

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

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

    Правило 4

    Развивайте коммуникационные навыки

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

    Правило 5

    Совершенствуйте свой английский

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

    Немного мотивации: уровень английского и зарплата у киевских Java и.NET мидлов и сеньоров с опытом 3-5 лет соотносится .

    Правило 6

    Покажите увлеченность своей профессией

    По мнению Богдана Гусева, о том, что вы получаете удовольствие от своей деятельности, может говорить наличие Open Source проектов, участие в тематических конференциях, владение фишками текстового редактора или IDE. И, конечно, интерес к деталям дальнейшей работы. Программисты, которые относятся к своему делу равнодушно, не пользуются высоким спросом у работодателей.

    Правило 7

    Покажите интеллект и абстрактное мышление

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

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

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

    Правило 8

    Демонстрируйте желание получать новые знания

    Иногда кандидат говорит: «Я изучил технологию X и хочу работать только с ней. Зачем мне изучать технологию Y, если я знаю X?» Шансы такого кандидата на оффер резко снижаются. Технологии - это всего лишь инструменты. Через какое-то время X станет неактуальной, а вместе с ней - и сам специалист, который владеет только ею.

    Максим Ковтун, Solution Architect

    Правило 9

    Покажите ориентированность на результат

    Я оцениваю:
    - умение пойти на компромисс со своими «религиозными убеждениями» (например, если того требует релиз, использовать «hot fix», а не подходить к решению фундаментально);
    - умение настоять на своем, когда это необходимо;
    - и еще важнее - умение держать правильный баланс между двумя пунктами выше.

    Андрей Мудрый, Project Manager

    Правило 10

    Не говорите «не знаю»

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

    Если не поняли, о чем речь, задайте уточняющий вопрос.

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

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

    Алексей Колупаев, СТО

    Правило 11

    Не стесняйтесь обучаться даже на собеседовании

    Невозможно знать всё. Однажды я работал на проекте, где требовались знания довольно специфического стека технологий и картографии. Как показал опыт, немногие программисты могут перевести классическую запись координат из WGS84 в десятичное представление. В таких случаях хорошим ответом на собеседовании я считаю вопрос: «Можно заглянуть в гугл?»

    Артем Полюхович, CTO

    Правило 12

    Думайте над тем, что говорите в ответ

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

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

    Сергей Чирков, Project Manager

    Правило 13

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

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

    Правило 14

    Не портите свою репутацию

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

    Правило 15

    Выстраивайте с интервьюером партнерские отношения

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

    Алексей Колупаев, СТО

    Правило 16

    Ведите себя корректно

    «Корректно» значит вежливо, уважительно. Надменность, заискивания или лесть по отношению к интервьюеру только испортят впечатления. Юмор тоже уместен не всегда.

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

    Последний легко определяется по следующему диалогу:
    Я: Возьмите на собеседование свой ноутбук
    Кандидат: А зачем?

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

    Богдан Гусев, СТО

    Правило 17

    Будьте адекватным:)

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

    Артем Полюхович, CTO

    Правило 18

    Будьте оптимистом

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

    Правило 19

    Feel free

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

    Но слишком большая самоуверенность - это тоже минус. Монолог на 20 минут без остановок может послужить поводом для отказа.

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

    Правило 20

    Если провалили, учитесь на ошибках

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

    Александр Кагановский, СТО

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

    Я проходил через этот процесс дюжины раз в различных IT-компаниях, на моей памяти огромное число как отказов, так и предложений. И вот какие уроки я из этого извлек. Собеседование требует труда: не верьте тем, кто утверждает, что это должно быть легко. Это не так. Люди говорят только о своих успехах и никогда - о провалах.

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

    Шаг 1. План подготовки

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

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

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

    Возникает вопрос, что именно надо практиковать? У вас не будут проверять знание синтаксиса какого-либо языка. При желании можно изучить основы синтаксиса Ruby за одну ночь. Но на что ночи не хватит, так это на основы фундаментальной информатики. А ведь на собеседовании у вас будут проверять именно знания структур данных и алгоритмов.

    Начните с прохождения двух курсов:
    введение в структуры данных (My Code School)
    введение в алгоритмы (MIT Open Courseware)
    Оба они находятся в открытом доступе и идеально подходят для того, чтобы получить базовые знания по этим разделам.

    После этого можно закрепить полученные знания на HackerRank и HackerEarth . Эти ресурсы содержат огромное количество задач для оттачивания навыков программирования.

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

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

    Шаг 2. Найдите компании, которые вас интересуют

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

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

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

    Шаг 3. Составьте портфолио

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

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

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

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

    Шаг 4. Получите приглашение на собеседование

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

    Настало время перейти к…

    Шагу 5. Пройдите собеседование

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

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

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

    Заключение

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



    Поделиться