что спрашивать на собеседовании у кандидата инженера

Что спрашивать на собеседовании у кандидата инженера

Группа: Участники форума
Сообщений: 29199
Регистрация: 4.12.2006
Из: 97
Пользователь №: 5032

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

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

5. Кем вы видите себя через 5 лет в нашей компании?
Вот вам встречный вопрос: какие планы компании на ближайшие 5 лет? Нет таких? Так если вы сами не знаете, что с вами будет через 20 лет, будет ли компания и какую нишу она намеревается занять, то мне-то откуда это знать?

7. Каким бы вы хотели видеть своего начальника?
Я бы хотел его не видеть. Серьезно, мне нет разницы как он выглядит. Главное, чтобы он был начальником: тем, кто может нормально и внятно сформулировать задачи. А в остальном, пусть хоть в красных труселях на белой капибаре разъезжает по офису.

Источник

Техническое собеседование: пять способов отпугнуть соискателя / пять способов взбесить интервьюера

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

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

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

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

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

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

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

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

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

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

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

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

Это совсем не технический, но, тем не менее, часто встречающийся косяк даже на технических интервью. У меня, к счастью, достаточно простое и распространённое имя, и таких проблем со мной не случалось. Однако я знаю, что существует удивительно много людей, которые свято уверены в том, что определённых имён и даже отчеств попросту не существует. Они будут вас убеждать, что правильно не «Данила», а «Даниил», или что имени «Алёна» нет, а есть только «Елена». Будут предлагать исправить и записать в своих документах «правильно». С такими грамотеями-доброхотами приходится часто иметь дело людям с редкими или необычными именами, и поверьте, это невероятно раздражает. Так вот, есть одно простое правило: нет таких имён, которых нет. Правильно писать так, как записано в паспорте. Проявите уважение к соискателю и не считайте его настолько глупым, что он не в состоянии переписать из паспорта в резюме собственное имя. Если даже подозреваете ошибку, это можно уточнить как-то более тактично.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Хорошие вопросы на собеседовании.

А вообще подобные темы о «правильных вопросах» для собеседования на инженерные вакансии были на форуме, вот и вот
Может еще были, поищите.
Сначала было немного конструктивных предложений, потом скатились во флуд. И с этой будет так, инфа 146%.

Offtop: Боян, но в тему.

Молодой изумленно:
— А как же претенденты?!

Опытный невозмутимо:
— А зачем нам неудачники.

Я здесь не имею ввиду ситуацию, когда реальному заданию соответствует не только задача, но и объем работы, которую соискателю предлагают выполнить в рамках собеседования. Это, конечно, 100% развод.

потому что это по сути попытка получить бесплатную консультацию у специалиста по текущим задачам, какими словами это не пытаться замаскировать)

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

Расскажу кое-что, вынесенное из 350 резюме, примерно 200 звонков и 50+ собеседований, проходивших по часу-два. Без тестов и прочей HR-лабуды, но с выводом человека на откровенные разговоры.

1. 75% кандидатов на технические должности с инженерным образованием сразу после выпуска вообще не помнят, чему их учили. Это норма.

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

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

Через два-три года пути могут вновь пересечься.

— Ну я не думаю, что это вообще нужно.

— А как вы сейчас, в своей лаборатории, растворы готовите?

— Лаборантка готовит, по старым прописям.

К чему я это. Может есть какие-нибудь задачки, либо чертежи, либо листы с заведомо неправельными решениями.
Например, мой однокурсник при найме конструкторов на работу (в том числе после университета), рисует на листе балки или рамы с нагрузками, а кандидат рисует эпюры моментов.
Либо просит заармировать колонну, ферму и т.д.
И сразу видно, человек учился, либо *** пинал. Есть базовые знания, либо нет.

Источник

Собеседование для QA: резюме, вопросы на интервью, переговоры о зарплате + полезные ссылки

Спросили Алексея Петрова pifagor_mc, Head of QA Сбермаркета, про интервью QA-инженеров и записали ответы. А ещё для подготовки прикрепили ссылки, которые он советовал — ищите их в конце статьи.

В тексте говорим только про собеседования:

3 основные рекомендации по составлению резюме для QA

Из каких блоков состоит стандартное интервью

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

В g-mate — много крутых вакансий для QA. Используйте бот @g_jobbot, чтобы получать вакансии по своему профилю прямо в Telegram.

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

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

Наверное, теперь придётся исключить из собеседований этот вопрос! Но приведу пример. Форма авторизации: логин-пароль, всё просто. Логин по маске либо телефон, либо имейл, пароль имеет какое-то ограничение. Большинство кандидатов начинают перебирать комбинаторные варианты: введу много пробелов, ещё что-то такое. А для пользователя важны другие кейсы: при существующем аккаунте, пускай при корректной связке логин-пароль (имейл+пароль, номер телефона+пароль) пускает, по несуществующей связке — не пускает. Дробить тут можно бесконечно. Почему-то забывают про кейс с восстановлением пароля. Я регулярно сталкиваюсь с тем, что забываю пароль от очередного сервиса, и надо его восстанавливать.

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

В тестировании безусловно играет роль и product vision. Сейчас есть такая модная штука: shift-left testing. Тестирование подключается как можно раньше, включается в процедуру планирования, проработки требований. Такой подход всё популярнее во многих крупных компаниях, и разумеется, что QA-инженер понимает, какое есть продуктовое видение. Пусть в бэклоге заложено 15–20 задач: зачем мы их делаем, какую пользу приносим пользователю — в зависимости от этого строятся кейсы. Например, хотим повысить ретеншн у мобильного приложения. Значит всё, что связано с реактивирующими пушами — для нас в высоком приоритете. Поэтому они должны работать идеально, как часы: приходить ровно, таргетировать человека в то место, куда должны, и так далее. Безусловно, QA должен понимать, зачем и как это происходит.

Есть альтернативный подход: shift-right testing. QA-инженер не начинает работу, когда тикет приходит в состоянии ready for test — подключается раньше, и не бросает её, когда тикет перешел в tested. Инженер помогает зарелизиться, помогает сопровождать в продакшене.

Речь и про регрессионные тесты, которые в будущем повторяются и говорят о том, что данный функционал не деградировал. Речь и про продуктовые метрики. Нередко, глядя на них, можно сделать предположение, что что-то пошло не так: смотрим на тот же DAU, а он резко просел после последнего релиза. Может, по техническим метрикам мы это не уловили, на регрессах проблемы нет, но всё равно это сигнал разобраться, что пошло не так, что повлияло на эти события. Плюс не надо забывать А/В-тестирование, feature toggling и так далее. Многие компании выпускают фичи на часть аудитории, QA вместе с продуктовыми аналитиками оценивают, оправдывает ли фича возложенные на неё надежды, если да — занимаются раскаткой дальше. QA не должны бросать фичу, протестировал — не значит, что работа закончена.

Что спрашивать интервьюеров на собеседовании

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

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

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

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

Soft skills для QA: 3 качества, которые стоит прокачивать в себе по твоему мнению

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

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

Второе: важно, чтобы человек излучал уверенность. Иногда встречаешь кандидатов, просишь рассказать, какие http-методы он знает. Неуверенным голосом он говорит: «get, post, кажется, patch, put… delete… options. ». Спрашиваешь, в чём отличия get и post, а в ответ: «ну, я не уверен… по-моему, один получает, другой создаёт объект, или что-то такое. ». Если видно, что человек выдаёт правильные ответы на собеседовании, но делает это очень неуверенно — в реальной работе его съедят.

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

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

А отсюда — и инициативность. Нужно её прокачивать, не бояться выражать мнение, подсвечивать проблемы. Может, попросить добавить новый статус? А может, начать делать код-ревью? Сопротивление и легкая конструктивная оппозиция. Для всего этого, безусловно, должна быть инициативность.

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

Зарплата по грейдам: про какие цифры может идти речь, к чему стремиться

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

Джуны — от 20 тыс. до 100 тыс. рублей. Найти работу с большой зарплатой сложно, одними курсами не обойдёшься, но устроиться можно. К тому же сильно зависит от региона.

У миддлов зарплаты тоже отличаются в зависимости от региона, компании, в каком секторе она работает. Финтех обычно платит больше всего — область специфичная. Для миддла — от 70–80 тыс. до 150–160 тыс. Тут ещё вопрос, кто какой уровень считает миддлом — в моём представлении, это сформировавшийся QA, который представляет, куда развиваться, чувствует почву под ногами, понимает, что хочет, может ответить на «пять почему».

Сеньоры: нижняя граница — от 100–120 тыс. рублей. Я видел ребят-сеньоров, не лидовых, кто на своей позиции получает 300 тысяч. Это даже не зарубежные компании, такие зарплаты существуют внутри российского рынка. Единственное, нужно отдавать отчёт, что если сфера — криптовалютный блокчейн и подобное, есть риск, что в понедельник вы проснётесь, а тимлид написал: извини, работы больше нет, зарплаты нет, ноутбук можешь оставить себе. Как ни печально, такие истории я слышал.

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

Как торговаться о зарплате

Лайфхак — давать вилку с небольшой «горкой», так, чтобы даже отступив от верхней планки, держать марку. Нормальная техника, если назвал: от 100 до 150, а по факту устроит и 130, к такому можно прибегать.

Ещё два пункта: честность, даже в таких базовых вещах, как назвать свой текущий уровень дохода. И аргументация — по опыту, если было 100 тыс., а хочу 150 тыс., но есть действительно понятные аргументы, та же ипотека — такой подход намного лучше сработает.

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

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

Ресурсы для подготовки к собеседованию

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

Есть пара ссылок про инвертированное собеседование: какие вопросы задавать и зачем. Это архиважно: когда перед тобой сидит кандидат, и на вопрос о компании или продукте не знает, что ответить — выглядит не очень. И наоборот, на моём опыте был человек, который погуглил наши статьи на Хабре, почитал, что пишут СМИ, установил продукт, сделал тестовый заказ, записал несколько баг-репортов, сопроводительное письмо — это подкупает.

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

Источник