Иногда люди не получают желаемую должность не потому что они для нее не подходят, а потому что неправильно вели себя во время собеседования. Возможно, нервы сыграли злую шутку, а может, у кандидата просто нет опыта.
Тема важная, поэтому в этой статье мы пройдемся по основным моментам, которые помогут вам превратить это неприятное «спасибо, мы вам перезвоним» в «поздравляем, вы приняты».
Информация в резюме
Тут важно запомнить две вещи. Во-первых, больше не значит лучше. Не надо упоминать все свои достижения. Да, даже то, как вы в 5 лет получили электричество от картошки. Это круто, но оставим эти истории для корпоратива.
Во-вторых, все сказанное вами может использоваться против вас. И не с целью завалить, как на школьном экзамене, а просто потому что ваши знания захотят проверить.
Упомянули о владении Python — будьте готовы рассказать, где вы им пользовались. Написали о том, что знаете Django или Flask, то будет здорово, если в портфолио завалялись проекты, которые вы сделали на этих фреймворках.
Проверить могут что угодно, поэтому ещё раз пересмотрите резюме и убедитесь, что хорошо знаете каждый пункт. Если что-то вы знаете только на практике, но не в теории, — так и скажите. Если вас собеседует компетентный специалист, он сразу вычислит, что вы не особо шарите. Зачем вам + 1 неловкий момент? Неужели вам больше не о чем подумать перед сном?
Собеседование начинается с рассказа о себе — здесь нужно не пересказывать автобиографию, а дать выжимку по основным пунктам:
Где вы учились и какой опыт в ИТ;
Что сделали на последнем проекте;
Какие обязанности выполняли;
Название прошлой должности;
Где раньше работали или стажировались;
- Как ваши знания соприкасаются с вакансией, на которую вы собеседуетесь.
Мы, например, когда берем человека на позицию тестировщика можем задать такие вопросы:
- Чем GET-запрос отличается от POST-запроса;
- Какие бывают виды тестирования;
- Чем валидация отличается от верификации;
- Какая структура у баг-репорта и т.д.
Помимо этого, могут также дать страничку сайта, где нужно найти все баги. Или решить вот такую задачку: "Пользователь зарегистрировался, но письмо с подтверждением не пришло на почту - в чем проблема и что делать?". Владение английским также играет немаловажную роль.
Еще советуем обратить внимание на книгу Романа Савина «Тестирование Дот Ком». Ее часто называют библией в мире русскоязычного тестирования и основа для построения логики мышления. Будет интересна всем, кто хочет узнать больше о кухне стартапов и процессе разработки ПО.
Рекрутер = друг
Чаще всего рекрутеры работают за процент, то есть за каждую закрытую должность они получают приятный бонус. Поэтому можно сказать, что они заинтересованы в том, чтобы вы получили должность, больше чем вы сами. Будьте с рекрутерами максимально вежливыми. Не стесняйтесь спрашивать о том, как будет проходить собеседование. Возможно, вы заранее сможете узнать перечень вопросов и подготовиться к интервью.
Это кратно увеличивает ваши шансы. Еще можете посмотреть, есть ли у компании закрытые вакансии. Пройдитесь по списку технологий, которыми они пользуются. Так вы получите базовое представление о том, что у вас могут спросить.
Техническое интервью
Не так страшен черт, как его малюют. Часто информация, которую у вас запрашивают, процентов на 80 состоит из теории. Это значит, что во время каждодневной работы вы не будете с ней соприкасаться. Поэтому не переживайте, если не смогли ответить на какой-то вопрос, но лучше где-то пометьте его и изучите информацию дома. Лишним не будет.
Софт скиллс и внешний вид
Несмотря на то, что ввиду своей деятельности вы будете чаще взаимодействовать с компьютером, собеседование проводит человек. Оценивают вас и делают выбор тоже люди. Поэтому человеческий фактор неизбежен. В любом случае разработка — командная работа. Развейте миф о том, что все айтишники интроверты и психи :D
Опрятно оденьтесь. Будьте вежливыми, задавайте вопросы. Даже если в фирме нет дресс-кода, запомните главное:
A. чистая одежда лучше, чем любимая с пятном от соуса;
B. глаженая лучше мятой;
C. однотонная толстовка безопаснее, чем со странной надписью или мемчиком (а может и нет).
В общем, касатики, меньше нервов и все получится. Готовьтесь, учитесь, будьте жадными к знаниям и любопытными к этому миру. Думайте с позиции работодателя и посмотрите, как вы сможете закрыть его проблемы. Рассказы о себе — ничто, если вы потом чуть что бежите на Stack Overflow.
Ну а телега и куча бесплатных плюшек ждет вашего визита. Приходите и зовите друзей.
А что в этом плохого? Если молодой специалист (а для кого ещё эта статья) может самостоятельно найти решение не дёргая коллег на каждую трудность, то это наоборот плюс.
P.S. Главное чтоб код брал из ответа, а не из вопроса :)
Комментарий удален модератором
Комментарий недоступен
Ну я вот могу много чего с помощью кода сделать. Но зачем мне запоминать все паттерны, функции, модули, синтаксис? А если я ещё и на нескольких языках пишу?
Мне удобнее зайти на stack owerflow и быстро освежить знание.
Неумение гуглить проблему и находить решение говорит о том что кодер использует ограниченный набор инструментов, который он заучил. И вряд ли сталкивается с новыми для себя задачами.
Комментарий недоступен
Если знает, что гуглит - хорошо.
Комментарий недоступен
Вопрос - чем же валидация отличается от верификации? Просто я впервые за более десяти лет слышу подобное сравнение... Только с примером. И не говорите, что это установление принадлежности к типу, посколько, это механизм никогда не обозначался верификацией.
Просьба - наймите адекватных рекрутеров, которым будет безразличны картинки на толстовке.
Отличаются источниками проверяемыми в их ходе свойств, правил и ограничений. Верификация проверяет, насколько продукт получился таким, каким задумывался. Например, мы изобретали велосипед и получили его.
Валидация проверяет насколько верным получился продукт. Например, ваш велосипед едет
Вообще ни слова не понял. Вы сами прочтите и попробуйте это в голове нарисовать. И я знаю значение варификации. Мне хочется пример из жизни, который к тому же будет из одной области.
Я тоже нихера не понимаю разницу между валидацией и верификацией.
Но возможно под верификацией они проверяют на соотвествие бизнес требований. А потом валидируют каждую часть, что она работает корректно.
Условно заказывали двух колесный велосипед с цепным приводом на переднее колесо и педали надо крутить руками.
Вот верифиация проверяет, что да педали есть и они там где руки, что есть цепной привод. А валидация уже проверяет, что руль крутится, что цепь нигде не закусывает и так далее.
Но как по мне это какая-то хуйня.
Ровно как и вопросы которые они задают тестерам, чем отличается get от post, если тестер работал с http, то ок, а если нет, то разве что ради кругозора.
Задача тестера, сделать правильный план тестирования на продукт.
Автоматизировать все, что автоматизируется, руками тестать то, что нельзя или нецелесообразно тестировать. Как строить тест план на релиз и куда смотреть в продукт.
В общем это работа на выявление и устранение проблем.
А вопросы типа, структура баг репорта какая-то херня, на которую не ответит разве что джун, да и структуры могут быть разными.
Вопросики тоже из разряда а давайте че-нить спросим.
На собесе главная задача это понять на сколько конкретный человек со своими плюсами и минусами подходит под наши задачи. И каким образом он вообще решает проблемы.
подряд было два собеса, которые радикально отличаются.
Первые спрашивали лютую дичь, по .NET с которой я никогда не сталкивался в проде, но даже столкнувшись все их вопросы решаются гуглом и pet проектами максимум за неделю. Но все собеседование было построено на доминировании. Такого дерьмища давно не встречал
Вторые: иностранная компания, все исключительно по делу, что решал, что было сложно, как решали и так далее, дали потом логическую задачу, в принципе несложную, но я там подтупил и сделал не совсем оптимально. Отказали, но им скорее всего нужен кодер, а я тот человек который может вести проект от и до. Но впечатления только положительные остались.
Я никогда не работал тестировщика, но тесты иногда пишу и мне кажется, что главное в тестах, это логически верно выстраивать структуру тестов и максимально придерживаться DRY. А все остальное зависит от проектировщика.
А ещё есть такая фигня, что невозможно отвечать на вопросы, когда ты ничего не знаешь, либо знаешь слишком много, что не понимаешь о чем именно вопрос. Так вот вторая проблема решается за счёт общепринятой конкретной терминологии. Я впервые слышу термин верификация относительно тестов. Кроме того, автор поста даже вразумительного ответа дать не смог. И помимо этого, о чем вообще речь? О тестировании ЯП, фраймворка, готового ui kit или его написания, или очень сложной логики? К какому именно контексту относится вопрос? Да и вообще, после установления контекста неприменно возникнет куча вопросов, на которые ответь сходу сложно. А если ещё и интервьювьер будет говорить так, как ответили мне, то это вообще беда!
Да просто выебываются и не более, мол мы тут понаблатыкались в терминологии и щас все правильно сделаем )))
Мне хочется пример из жизни, который к тому же будет из одной области)
Ну, сделал работу за штуку и получил её: твои и контрагента ожидания срослись, те ризалт верифицирован.
На следующий день ты просадил штырь на ставке, а контрагент лоханулся на ту же штуку, те ризалт валидирован))
то бишь,
Леси где-то убыло,
то где-то это прибыло)
Вы случаем не имеете ввиду две стадии из TDD - до написания тестируемого кода, и после?
Тоже поделюсь своим опытом относительно поиска сотрудников.
Я никогда не проводил собеседований, но пару недель назад мой старый друг попросил собрать команду из 10-ти человек для нового проекта, а таких компетенций в его компании нет по техчасти пока.
Меня пригласили как 'независимого эксперта'.
Отсмотрел, наверное, пока что примерно 50 резюме.
Отсобеседовал человек 15. Много джунов (мидлов и синьоров пока маловато). Я буду лидом, так что жизненно необходимы мидлы как минимум.
Так вот, со стороны компании друга был ещё CTO и он задавал какие-то совершенно бестолковые вопросы типа 'а чем гет отличается от поста', 'какой запрос нужно писать, чтобы получить данные из базы' и прочие глупости. Потом, конечно, я с ним поговорил и он перестал так делать.
А меня больше интересовало, в какую сторону человек хочет развиваться, какие проекты реализовывал, какую роль там играл, сколько человек было в команде, как было реализовано взаимодействие внутри неё.
Ну иногда спрашивал с базами какого размера он работал -)
Совершенно до пизды, помнит ли он, как конкретно в этом фреймворке обычно делают валидацию полей, какие там базовые классы, и какое у кандидата образование. Спрашивал ещё про общую схему, чтобы понять, что кандидат понимает хотя бы частично архитектуру.
И записывал в список тех, к кому нужно присмотреться получше, когда уже будет выбор для набора.
PS. Просто делюсь опытом, без нравоучений всяких
Ну хорошо хоть эти кофе не предлагают выпить
Я бы ещё по своему опыту добавил, что важно задавать вопросы и вести диалог. Провожу собеседования на позицию системный аналитик и больше плюсиков, как правило, получают кандидаты, которые задают вопросы и общаются. Также такого мнения придерживаются ещё несколько знакомых, которые тоже проводят собеседования на различные позиции. Кандидаты, которые приятные в общении и задают вопросы по интересующей вакансии, получают больше шансов на офер, даже если не ответили на все вопросы, чем те, которые ответили, но не задали ни одного вопроса.
Шпаргалка для интервью, чтобы порадовать интервьюера вопросами.
-Какой стек технологий используется? /Лучше предварительно изучить инфу о компании и сформулировать вопрос применительно к особенностям компании
-Какие применяются системы контроля версий и баг-репортс?
-В решении каких задач у компании наработана максимальная экспертиза? Над чем я буду работать?
-Я планирую в свободное время расширить знания и опыт по ХХХ. Будет ли такая возможность при решении рабочих задач?
-Есть ли система повышения/пересмотра должности, как она устроена и как часто это происходит?
-Исходя из резюме и моего опыта, какие знания мне необходимо расширить в первую очередь, чтобы эффективнее решать стоящие задачи.
PS Задавание вопросов не превращать в допрос рекрутера, а использовать ответы для развития диалога.
Дельные замечания, но как говорил Илон Маск, нужно проводить соборования в формате вопросов. То есть, задавать какие сложности в работе у него были и др по работе, что ему нравится. А то, по сути, человек может получить должность, просто, потому что, у него сегодня хороший день.