Да, согласен — грустно тут даже не то слово. Когда вместо прозрачных, профессиональных критериев начинают оперировать абстрактными понятиями вроде «вайбов» и «мэтча по духу» — это действительно удобная позиция, позволяющая избегать конкретики. А значит, и ответственности.
В таком подходе легко оправдать что угодно: и предвзятые решения, и отсутствие объективной обратной связи, и даже откровенно неадекватное поведение.
Спасибо большое, рад, что материал оказался полезным!
Что касается исключения папки (например, tests) при копировании кода на VPS в GitHub Actions — тут всё зависит от того, каким именно способом копируются файлы. Ниже пару вариантов:
За этим как раз таки и нужен скрининг, согласен с вами
Кто вам сказал, что скрининг это всегда "девочка hr?"
Возможно у большинства сложилось такое мнение, потому что в 90% случаях, действительно скрининг проводить HR. У разработки часто просто нет на это времени
Тем не менее такое часто случается) Есть кандидаты, которые на словах Лев Толстой, на деле, как это обычно бывает, все оказывается намного проще
Тем более кандидат мог элементарно зазубрить, например, определение паттерна декоратор, при этом он вообще не имеет представления зачем он нужен, где и когда применяется) Видели, знаем
Скорее всего, в этом виноваты не только работодатели, но и сами соискатели. На вакансию джуна из 100% откликов примерно 80–90% приходят от выпускников курсов. Их там штампуют сотнями каждый месяц, а порой даже с одного и того же потока какой-нибудь конторы "КурсыBox". У всех одинаковые резюме, одинаковые проекты на GitHub, которые они просто копируют друг у друга. Работодателю просто приходиться завышать требования дабы отсеить уже прям свосем невдупленышей
Если человек самоучка и действительно грамотно подошел к поиску работы, пусть даже пройдет 50 собеседований — он найдет свое место. Если он горит идеей и активно развивается, то работу он точно получит. Почему? Потому что компании, в том числе и наша, делают ставку на проактивных джунов — тех, кто пока без опыта, но у кого буквально чешутся руки изучать новое. И я знаю о чем говорю, потому что есть живые примеры. Такие ребята за полгода становятся самостоятельными и приносят реальную пользу.
А вот мидлам и сеньорам уже сложнее. Многие (не все, конечно) теряют мотивацию учиться чему-то новому. Например, убедить ручного тестировщика-сеньора освоить автоматизацию — почти нереально. Если он дорос до этого уровня, но так и не начал разбираться в автотестах, это уже о многом говорит.
HH в последние 4-5 лет действительно стал так себе площадкой, как по мне) Но, судя по описанной ситуации, скорее всего проблема в резюме. Если отказы идут уже на этапе подачи, значит, это единственная информация, на основе которой рекрутер принимает решение.
Возможно, стоит попробовать адаптировать резюме под конкретные вакансии. Это не значит, что нужно приписывать себе несуществующие навыки, но, например, можно пересортировать технологии и акцентировать внимание на тех, которые наиболее релевантны для данной позиции.
Еще один вариант — законнектится с опытным HR-специалистом. Они видят сотни резюме в день и могут дать дельные советы (может быть и за отдельную плату). Сам когда-то так делал, и это помогло, как минимум стали понятны, казалось бы очевидные ошибки, но тогда мне так не казалось)
Короче, если уже 3 месяца без результата, просто рассылать резюме без корректировок — не лучшая стратегия. Нужно что-то менять.
Возможно, вы немного неверно интерпретировали этот момент) Я упомянул это выражение как противопоставление задачам на написание автотестов, которые действительно важны для QA Automation Engineer. Вычисление интеграла в этом контексте — бесполезная и абсурдная задача, независимо от того, знает ли кандидат все методы или не знает ни одного и не важно существуют ли эти методы. Суть именно в абсурдности задачи для данного специалиста
Мне самому давали подобные вопросы на собеседованиях в крупных компаниях, и они не имеют смысла: даже если кандидат решит их идеально или не решит вовсе, это ничего не скажет о его реальных навыках написания автотестов. А вот как он пишет автотесты, проектирует тестовую архитектуру, строит тестовую модель, пользуется тестовым фреймворком и тестирует бизнес-логику — это действительно важно
Да 600–700 — это еще на продуктовые вакансии, а на какие-нибудь позиции QA может прилететь и 1000–1500 откликов со всех ресурсов. Эйчары от этого дико загружены, нужно все фильтровать. В итоге поиск кандидата из формата «найдем за две недели» превращается в «вроде изи, найдем за неделю», а на деле — ищем полгода. И вот реально нормальному специалисту (а такие, конечно, есть) пробиться через весь этот шум из сотен кандидатов ну очень сложно
Ну и со стороны кандидатов ситуация не лучше. Сейчас на рынке много реально прокачанных специалистов уровня сеньор, но даже им тяжело. Потому что есть куча кандидатов, которые просто перебивают им ЗП. Зачем мне брать сеньора+ за 100 рублей, если я могу взять миддла+ за 50, который под мои задачи за глаза хватит? Видели такое, знаем. Когда один кандидат просит одну ЗП, а в этот момент рекрутеру уже стучатся десять таких же, ничем не хуже, но дешевле)
Понимаю ваш вопрос, уже много раз отвечал на него в комментариях, но давайте еще раз, держите пример с Юрой)
История из жизни: к нам как-то пришёл разработчик, пусть его звали Юра. В этот же день Юра уволился, потому что "в гробу видал он этот gRPC". С тех пор мы звали его "Юра один день". С одной стороны, кому-то может показаться, что это мелочь, но бывают ситуации, когда знание определённой технологии — суперважно для бизнеса.
Никто не говорит, что нужно полностью выучить технологию и досконально в ней разбираться. Речь о том, чтобы хотя бы быть в контексте — вам же самому так будет проще.
Почему это важно? Потому что некоторым кандидатам на собеседовании кажется, что вопросы вроде «Вы точно с этим работали?», «Вы хотите с этим работать?», «У вас точно не будет проблем?» — это формальность. А потом человек устраивается на работу и понимает, что вообще не тянет. В итоге, зачем мне в команде QA, на поиск которого я потратил три месяца, если он через три месяца (а может, и завтра) сбежит в ужасе?
Ему же самому будет проще, если он заранее разберется хотя бы на базовом уровне. Плюс, знания никогда не бывают лишними. А на собеседовании, если спросят про этот самый gRPC, не нужно быть в нем асом, но хотя бы понимать, что это такое и зачем оно нужно.
Не факт, уверяю вас) Когда-то я работал на фрилансе, и там было полно заказов в формате «выполнить ТЗ», «написать автотесты по ТЗ для компании» и так далее. Так что есть большая вероятность, что по такому заданию вы будете оценивать не самого кандидата. Доходило даже до того, что мама будущего «инженера» просила решить ТЗ. А задания были элементарные — например, написать Page Object и пару автотестов на главную страницу в GitHub или в какой-то репозиторий. Так что далеко не факт, что кандидат вообще сам это сделал)
Да и лайв-кодингом это назвать сложно. Написать пару автотестов в формате псевдокода для QA Automation Engineer — это база, без которой никуда. Это как пузырьковая сортировка для любого программиста или написание SELECT-запроса для бэкендера. Никто же не требует изобрести синхрофазотрон.
Более того, есть задачи в формате «вот код, объясни, что он делает». И даже это для многих оказывается сложным!
Обращаю внимание, что эта статья помечена тегом «Мнение», в котором я, как автор, делюсь своим опытом и взглядами)
Все рекомендации в статье основаны на практике и адресованы кандидатам, у которых возникают проблемы на собеседованиях. Возможно, не все пункты актуальны для каждого, но, как минимум, 1–2 из них встречаются довольно часто. Здесь минимум воды. Если хотите увидеть настоящую «простыню» текста на 5 минут чтения обо всем и ни о чем, то таких статей на хабре полно
Не знаю как можно не заметить завалил ты вопросы или нет. Тут или ты знаешь ответ и отвечаешь, либо не знаешь и понимаешь, что завалил. В итоге в конце собеса ты и сам понимаешь на что не знал ответы и что тебе нужно подтянуть. Поэтому как-то и нет смысла задавать вопросы и дальше тратить время.
Это идеальный вариант, если есть саморефлексия и способность объективно оценить свои силы)
А другой момент, что ты реально знал ответы, отвечал, а тебе все равно отказали. То вот здесь в принципе можно уже узнать в чем дело. Но опять же, это вопрос уже после собеса, когда пришел отказ.
Иногда кандидаты уверены, что ответили великолепно, а отказ их удивляет. Представь, ты сидишь на собесе, тебя по листочку спрашивают с каменным лицом, ты отвечаешь, переходят к следующему вопросу и так весь собес. Так можно ответить на все, но в какой-то момент не понятно, понравилось ли это собеседующим, были ли правильные ответы. Я был на таких собесах, и впечатление оставалось довольно странное, как будто на допросе побывал) Это были крупные компании, чьи продукты мы, используем ежедневно. В идеале все вопросы должны быть ясными, а ответы на них — четкими. Но бывают исключения. Например, в QA Automation можно задать вопрос: «Какие виды автотестов нужно запускать на каждый релиз?». И тут может быть целая серия уточняющих вопросов — около 15. Как ты их задашь, так и будет выглядеть твой ответ. Может, ты вообще не задашь уточняющих вопросов, а сам додумаешься, что не очевидно. И если после этого тебе скажут «угу, идем дальше», то в таких ситуациях действительно сложно понять, правильный ли ответ был дан)
А вообще, чисто для себя интересуюсь, были ли какие-нибудь может быть похожие кейсы, когда человек вроде ответил на все/почти все, а ему все равно дали отказ? Какие были причины, на что обращали внимание? Но только без совсем неадекватных кандидатов, пожалуйста)
Что касается случаев, когда человек вроде бы ответил на все вопросы, а отказ все равно пришел, то да, такие случаи были и много. Причины бывают разные, и довольно неожиданные (казалось бы). Например, кандидат начал требовать слишком высокую зарплату после того, как предложили оффер (бывает такое). Или отказался от условий компании, которые были общие для всех (аля релок, хотя про это как правильно информируют сразу HR). В некоторых случаях, уже на интервью "за жизнь", становится понятно, что кандидат не сможет выдержать бешеный темп релизов. У него может быть хороший бэкраунд, но он больше ориентирован на спокойную работу, а тут "пятничные релизы"). Иногда просто не сошлись в ценностях, например, когда рассказывали про продукт, кому-то например, прям буэ, как не хочется работать в банке. Короче причины разные
Был случай с кандидатом, назовем его Иван (не в обиду всем Иванам). Он решал задачи, отвечал на вопросы, но вел себя в общении довольно грубо в формате: «И че? Оно же и так будет работать». Да, всё работает, но важно, чтобы человек понимал, что на работе нужно работать в команде, и что с таким отношением к коллегам — «И че?» — никто не хочет работать. И да, Иван ответил на 95% вопросов, решал задачи, но его софт-скиллы "оставляли желать лучшего") Люди не хотят работать с кем-то, кто будет им "ичекать". Вань, тут автотесты сломались, глянешь? "И че? Они же не просто так сломались"
По такой логике вообще не нужно ни к чему готовиться — мол, если провалю собес, ну и ладно, пойду дальше.
Но дело ведь не в этом. Допустим, в компании используется технология X. Что мешает потратить 20 минут, открыть Google и хотя бы базово разобраться, что это такое? Возможно, это вообще не что-то новое для вас — вы с этим работали, просто не знали, что оно так называется.
В итоге, если на собесе спросят: "Знаете ли вы про X?" — можно будет честно ответить: "Да, читал, в работе пока не использовал". Это куда лучше, чем полное незнание, когда даже непонятно, хотите ли вы с этим работать. Это лучше для вас самих же
И хуже от этих 20–30 минут точно не станет. Никто не говорит, что за это время нужно заиметь гигантский опыт, но хотя бы общее представление получить можно.
История из жизни: к нам как-то пришёл разработчик, пусть его звали Юра. В этот же день Юра уволился, потому что "в гробу видал он этот gRPC". С тех пор мы звали его "Юра один день". С одной стороны, кому-то может показаться, что это мелочь, но бывают ситуации, когда знание определённой технологии — суперважно для бизнеса.
Если бы Юра заранее потратил 20 минут, чтобы понять, что gRPC — это та ещё шляпа для него, он бы просто не пошёл на этот собес. В итоге он сэкономил бы себе несколько часов, которые потратил на интервью и последующее осознание, что работать с gRPC он не хочет.
К слову, знаю людей, которых при слове GraphQL аж выворачивает, потому что они топят за REST API и "в гробу видали этот GraphQL". И хорошо бы понять это заранее, чем в первый рабочий день осознать, что выбрал "не ту дверь"
Тут скорее речь о ситуациях, когда кандидат явно завалил много вопросов, но сам этого не замечает или не хочет замечать. Обычно в таких случаях интервьюеры уже во время собеседования пишут друг другу в ЛС и принимают решение не тратить время всех присутствующих господ)
И вот такие моменты должны вызывать вопросы у самого кандидата. Например: Что мне стоит подтянуть? Где у меня пробелы? Ведь если собеседование прошло неудачно, это шанс понять, над чем работать, как минимум
Конечно, никто не обязан что-то спрашивать. Особенно если вы идеально ответили на все вопросы — тогда, наоборот, у них должны быть вопросы к вам аля: Когда сможете выйти на работу? Сколько деняк хотите?
Но тут речь именно о ситуациях, когда очевидно идёт "слив"
Помнить все функции наизусть, вас будут проверять по написанию кода на листочке. IDE/Google пользоваться нельзя.
Возможно, вы неправильно поняли эту фразу) Тут речь не о том, что нужно знать весь Python наизусть. А о ситуациях, когда кандидат, проработав несколько лет, вообще не может написать элементарную функцию, любую функцию. Это ведь база, функции изучают практически сразу после переменных и типов данных. Если после нескольких лет работы человек забывает, как их писать, это уже реально странно)
Будьте почтительны к интерьвьюеру, не спорьте с ним.
Ой, спасибо, но слишком много чести! Но если без шуток, то тут просто речь о базовой вежливости. Это же обычное человеческое общение — никто не любит, когда его перебивают или игнорируют. Это касается не только собеседований, а любых диалогов в целом.
Почему то идет впечетление что тут позиция такая: "автору можно спорить даже если он не прав, если собеседовтель реагирует, это потому что он неадекватный.". Но вообще конечно кричать на интервью не стоит.
Возможно, вам так показалось, потому что вы не знаете всей ситуации. Там не было спора, был вопрос, как лучше реализовать задачу — через if или try/except. Я выбрал if и сделал через if, интервьюер ожидал try/except и спросил, почему так. Я объяснил свою логику, но после этого его прям сильно бомбануло)
Наушниками пользоваться нельзя, должны быть колонки и отдельный микрофон.
Мой опыт (.NET developer) сильно отличается, практически 100% собеседований проходит в наушниках (гарнитуре с микофроном). Даже не очень понятно чего такого плохого в наушниках: человек работает либо в офисе либо из дому. В обоих случаях шуметь как-то неприятно. Да и беседа казалось бы должна быть приватной.
Возможно, вы не так поняли) Конечно, в обычных случаях никто не запрещает использовать гарнитуру, хоть сабвуфер. Проблема не в самих наушниках, а в том, что есть конторы, которые за деньги или откат от зарплаты помогают людям "пройти" собеседования. В таком случае кандидат сидит на собеседовании, а в наушнике у него "сеньор Вася", который подсказывает ответы или даже пишет код за него
И да, если вам кажется, что это не нужно, потому что вас еще не взяли на работу, вы будете правы — вас действительно еще не взяли, и вы никому ничего не обязаны.
Эта рекомендация скорее для тех, кто хочет повысить свои шансы, особенно если приходит на собеседование "попытать счастья". Если вы лютейший сеньор, то, конечно, логично, что рекрутеры должны сначала изучить ваш опыт сами.
Но суть этой рекомендации именно в том, чтобы увеличить ваши шансы.
Но суть именно в том, чтобы увеличить вероятность успешного собеседования. Бывают компании с очень сложными процессами: тысячи сотрудников в IT-отделе, сотни команд, и владение какой-то конкретной технологией может быть критически важно не только для работодателя, но и для самого кандидата.
История из жизни: к нам как-то пришёл разработчик, пусть его звали Юра. В этот же день Юра уволился, потому что "в гробу видал он этот gRPC". С тех пор мы звали его "Юра один день". С одной стороны, кому-то может показаться, что это мелочь, но бывают ситуации, когда знание определённой технологии — суперважно для бизнеса.
Ну и бывают случаи, когда кандидат просто не указал что-то важное в резюме. Например, лет 7 назад у меня был коллега — питонист, но работал 1С-ником когда-то. На собеседовании его спросили: — Знаешь Python? — Да, ещё и 1С знаю. — О, так нам как раз 1С-ник нужен, поехали к нам! В итоге он получил оффер на зарплату в 1.5 раза выше той, на которую рассчитывал)
В идеале, да, обратную связь должны давать без запроса — те, кто проводили собеседование, а HR передавать её кандидату. Но, как показывает практика, так бывает далеко не всегда. У меня тоже были случаи, когда даже сам факт отказа не сообщали, и приходилось самому "напоминать о себе", чтобы просто получить ответ)
Поэтому иногда имеет смысл самому запросить фидбэк, особенно если есть понимание, что где-то не дотянул и нужно подтянуть слабые места. В идеале, конечно, записывать вопросы с собеседования, но на практике, фиг, что записать успеешь, да еще в стрессовой ситуации, короче есть нюансы
Хорошая идея, сначала думал КАПСОМ и жирный шрифт, но потом почему-то от этой идеи решил отказаться
Да, согласен — грустно тут даже не то слово. Когда вместо прозрачных, профессиональных критериев начинают оперировать абстрактными понятиями вроде «вайбов» и «мэтча по духу» — это действительно удобная позиция, позволяющая избегать конкретики. А значит, и ответственности.
В таком подходе легко оправдать что угодно: и предвзятые решения, и отсутствие объективной обратной связи, и даже откровенно неадекватное поведение.
Абсолютно верно, это тоже один из явных признаков
Спасибо большое, рад, что материал оказался полезным!
Что касается исключения папки (например, tests) при копировании кода на VPS в GitHub Actions — тут всё зависит от того, каким именно способом копируются файлы. Ниже пару вариантов:
Вариант 1: rsync
Можно исключать несколько папок:
Вариант 2: scp
scp сам по себе не умеет исключать директории, но можно воспользоваться tar:
За этим как раз таки и нужен скрининг, согласен с вами
Возможно у большинства сложилось такое мнение, потому что в 90% случаях, действительно скрининг проводить HR. У разработки часто просто нет на это времени
Тем не менее такое часто случается) Есть кандидаты, которые на словах Лев Толстой, на деле, как это обычно бывает, все оказывается намного проще
Тем более кандидат мог элементарно зазубрить, например, определение паттерна декоратор, при этом он вообще не имеет представления зачем он нужен, где и когда применяется) Видели, знаем
Скорее всего, в этом виноваты не только работодатели, но и сами соискатели. На вакансию джуна из 100% откликов примерно 80–90% приходят от выпускников курсов. Их там штампуют сотнями каждый месяц, а порой даже с одного и того же потока какой-нибудь конторы "КурсыBox". У всех одинаковые резюме, одинаковые проекты на GitHub, которые они просто копируют друг у друга. Работодателю просто приходиться завышать требования дабы отсеить уже прям свосем невдупленышей
Если человек самоучка и действительно грамотно подошел к поиску работы, пусть даже пройдет 50 собеседований — он найдет свое место. Если он горит идеей и активно развивается, то работу он точно получит. Почему? Потому что компании, в том числе и наша, делают ставку на проактивных джунов — тех, кто пока без опыта, но у кого буквально чешутся руки изучать новое. И я знаю о чем говорю, потому что есть живые примеры. Такие ребята за полгода становятся самостоятельными и приносят реальную пользу.
А вот мидлам и сеньорам уже сложнее. Многие (не все, конечно) теряют мотивацию учиться чему-то новому. Например, убедить ручного тестировщика-сеньора освоить автоматизацию — почти нереально. Если он дорос до этого уровня, но так и не начал разбираться в автотестах, это уже о многом говорит.
HH в последние 4-5 лет действительно стал так себе площадкой, как по мне) Но, судя по описанной ситуации, скорее всего проблема в резюме. Если отказы идут уже на этапе подачи, значит, это единственная информация, на основе которой рекрутер принимает решение.
Возможно, стоит попробовать адаптировать резюме под конкретные вакансии. Это не значит, что нужно приписывать себе несуществующие навыки, но, например, можно пересортировать технологии и акцентировать внимание на тех, которые наиболее релевантны для данной позиции.
Еще один вариант — законнектится с опытным HR-специалистом. Они видят сотни резюме в день и могут дать дельные советы (может быть и за отдельную плату). Сам когда-то так делал, и это помогло, как минимум стали понятны, казалось бы очевидные ошибки, но тогда мне так не казалось)
Короче, если уже 3 месяца без результата, просто рассылать резюме без корректировок — не лучшая стратегия. Нужно что-то менять.
Возможно, вы немного неверно интерпретировали этот момент) Я упомянул это выражение как противопоставление задачам на написание автотестов, которые действительно важны для QA Automation Engineer. Вычисление интеграла в этом контексте — бесполезная и абсурдная задача, независимо от того, знает ли кандидат все методы или не знает ни одного и не важно существуют ли эти методы. Суть именно в абсурдности задачи для данного специалиста
Мне самому давали подобные вопросы на собеседованиях в крупных компаниях, и они не имеют смысла: даже если кандидат решит их идеально или не решит вовсе, это ничего не скажет о его реальных навыках написания автотестов. А вот как он пишет автотесты, проектирует тестовую архитектуру, строит тестовую модель, пользуется тестовым фреймворком и тестирует бизнес-логику — это действительно важно
Да 600–700 — это еще на продуктовые вакансии, а на какие-нибудь позиции QA может прилететь и 1000–1500 откликов со всех ресурсов. Эйчары от этого дико загружены, нужно все фильтровать. В итоге поиск кандидата из формата «найдем за две недели» превращается в «вроде изи, найдем за неделю», а на деле — ищем полгода. И вот реально нормальному специалисту (а такие, конечно, есть) пробиться через весь этот шум из сотен кандидатов ну очень сложно
Ну и со стороны кандидатов ситуация не лучше. Сейчас на рынке много реально прокачанных специалистов уровня сеньор, но даже им тяжело. Потому что есть куча кандидатов, которые просто перебивают им ЗП. Зачем мне брать сеньора+ за 100 рублей, если я могу взять миддла+ за 50, который под мои задачи за глаза хватит? Видели такое, знаем. Когда один кандидат просит одну ЗП, а в этот момент рекрутеру уже стучатся десять таких же, ничем не хуже, но дешевле)
Понимаю ваш вопрос, уже много раз отвечал на него в комментариях, но давайте еще раз, держите пример с Юрой)
Никто не говорит, что нужно полностью выучить технологию и досконально в ней разбираться. Речь о том, чтобы хотя бы быть в контексте — вам же самому так будет проще.
Почему это важно? Потому что некоторым кандидатам на собеседовании кажется, что вопросы вроде «Вы точно с этим работали?», «Вы хотите с этим работать?», «У вас точно не будет проблем?» — это формальность. А потом человек устраивается на работу и понимает, что вообще не тянет. В итоге, зачем мне в команде QA, на поиск которого я потратил три месяца, если он через три месяца (а может, и завтра) сбежит в ужасе?
Ему же самому будет проще, если он заранее разберется хотя бы на базовом уровне. Плюс, знания никогда не бывают лишними. А на собеседовании, если спросят про этот самый gRPC, не нужно быть в нем асом, но хотя бы понимать, что это такое и зачем оно нужно.
Не факт, уверяю вас) Когда-то я работал на фрилансе, и там было полно заказов в формате «выполнить ТЗ», «написать автотесты по ТЗ для компании» и так далее. Так что есть большая вероятность, что по такому заданию вы будете оценивать не самого кандидата. Доходило даже до того, что мама будущего «инженера» просила решить ТЗ. А задания были элементарные — например, написать Page Object и пару автотестов на главную страницу в GitHub или в какой-то репозиторий. Так что далеко не факт, что кандидат вообще сам это сделал)
Да и лайв-кодингом это назвать сложно. Написать пару автотестов в формате псевдокода для QA Automation Engineer — это база, без которой никуда. Это как пузырьковая сортировка для любого программиста или написание SELECT-запроса для бэкендера. Никто же не требует изобрести синхрофазотрон.
Более того, есть задачи в формате «вот код, объясни, что он делает». И даже это для многих оказывается сложным!
Обращаю внимание, что эта статья помечена тегом «Мнение», в котором я, как автор, делюсь своим опытом и взглядами)
Все рекомендации в статье основаны на практике и адресованы кандидатам, у которых возникают проблемы на собеседованиях. Возможно, не все пункты актуальны для каждого, но, как минимум, 1–2 из них встречаются довольно часто. Здесь минимум воды. Если хотите увидеть настоящую «простыню» текста на 5 минут чтения обо всем и ни о чем, то таких статей на хабре полно
Это идеальный вариант, если есть саморефлексия и способность объективно оценить свои силы)
Иногда кандидаты уверены, что ответили великолепно, а отказ их удивляет. Представь, ты сидишь на собесе, тебя по листочку спрашивают с каменным лицом, ты отвечаешь, переходят к следующему вопросу и так весь собес. Так можно ответить на все, но в какой-то момент не понятно, понравилось ли это собеседующим, были ли правильные ответы. Я был на таких собесах, и впечатление оставалось довольно странное, как будто на допросе побывал) Это были крупные компании, чьи продукты мы, используем ежедневно. В идеале все вопросы должны быть ясными, а ответы на них — четкими. Но бывают исключения. Например, в QA Automation можно задать вопрос: «Какие виды автотестов нужно запускать на каждый релиз?». И тут может быть целая серия уточняющих вопросов — около 15. Как ты их задашь, так и будет выглядеть твой ответ. Может, ты вообще не задашь уточняющих вопросов, а сам додумаешься, что не очевидно. И если после этого тебе скажут «угу, идем дальше», то в таких ситуациях действительно сложно понять, правильный ли ответ был дан)
Что касается случаев, когда человек вроде бы ответил на все вопросы, а отказ все равно пришел, то да, такие случаи были и много. Причины бывают разные, и довольно неожиданные (казалось бы). Например, кандидат начал требовать слишком высокую зарплату после того, как предложили оффер (бывает такое). Или отказался от условий компании, которые были общие для всех (аля релок, хотя про это как правильно информируют сразу HR). В некоторых случаях, уже на интервью "за жизнь", становится понятно, что кандидат не сможет выдержать бешеный темп релизов. У него может быть хороший бэкраунд, но он больше ориентирован на спокойную работу, а тут "пятничные релизы"). Иногда просто не сошлись в ценностях, например, когда рассказывали про продукт, кому-то например, прям буэ, как не хочется работать в банке. Короче причины разные
Был случай с кандидатом, назовем его Иван (не в обиду всем Иванам). Он решал задачи, отвечал на вопросы, но вел себя в общении довольно грубо в формате: «И че? Оно же и так будет работать». Да, всё работает, но важно, чтобы человек понимал, что на работе нужно работать в команде, и что с таким отношением к коллегам — «И че?» — никто не хочет работать. И да, Иван ответил на 95% вопросов, решал задачи, но его софт-скиллы "оставляли желать лучшего") Люди не хотят работать с кем-то, кто будет им "ичекать". Вань, тут автотесты сломались, глянешь? "И че? Они же не просто так сломались"
По такой логике вообще не нужно ни к чему готовиться — мол, если провалю собес, ну и ладно, пойду дальше.
Но дело ведь не в этом. Допустим, в компании используется технология X. Что мешает потратить 20 минут, открыть Google и хотя бы базово разобраться, что это такое? Возможно, это вообще не что-то новое для вас — вы с этим работали, просто не знали, что оно так называется.
В итоге, если на собесе спросят: "Знаете ли вы про X?" — можно будет честно ответить: "Да, читал, в работе пока не использовал". Это куда лучше, чем полное незнание, когда даже непонятно, хотите ли вы с этим работать. Это лучше для вас самих же
И хуже от этих 20–30 минут точно не станет. Никто не говорит, что за это время нужно заиметь гигантский опыт, но хотя бы общее представление получить можно.
Если бы Юра заранее потратил 20 минут, чтобы понять, что gRPC — это та ещё шляпа для него, он бы просто не пошёл на этот собес. В итоге он сэкономил бы себе несколько часов, которые потратил на интервью и последующее осознание, что работать с gRPC он не хочет.
К слову, знаю людей, которых при слове GraphQL аж выворачивает, потому что они топят за REST API и "в гробу видали этот GraphQL". И хорошо бы понять это заранее, чем в первый рабочий день осознать, что выбрал "не ту дверь"
На самом деле людей, которые так упорно учатся, как ты, реально очень мало) Обычно всё выглядит так: "я прошёл курс, дайте мне 200 ТЫЩ"
Если хочешь, можем обсудить подробнее в ЛС — могу подсказать, где могут быть слабые места в резюме или как лучше заходить в компании
Тут скорее речь о ситуациях, когда кандидат явно завалил много вопросов, но сам этого не замечает или не хочет замечать. Обычно в таких случаях интервьюеры уже во время собеседования пишут друг другу в ЛС и принимают решение не тратить время всех присутствующих господ)
И вот такие моменты должны вызывать вопросы у самого кандидата. Например: Что мне стоит подтянуть? Где у меня пробелы? Ведь если собеседование прошло неудачно, это шанс понять, над чем работать, как минимум
Конечно, никто не обязан что-то спрашивать. Особенно если вы идеально ответили на все вопросы — тогда, наоборот, у них должны быть вопросы к вам аля: Когда сможете выйти на работу? Сколько деняк хотите?
Но тут речь именно о ситуациях, когда очевидно идёт "слив"
Возможно, вы неправильно поняли эту фразу) Тут речь не о том, что нужно знать весь Python наизусть. А о ситуациях, когда кандидат, проработав несколько лет, вообще не может написать элементарную функцию, любую функцию. Это ведь база, функции изучают практически сразу после переменных и типов данных. Если после нескольких лет работы человек забывает, как их писать, это уже реально странно)
Ой, спасибо, но слишком много чести! Но если без шуток, то тут просто речь о базовой вежливости. Это же обычное человеческое общение — никто не любит, когда его перебивают или игнорируют. Это касается не только собеседований, а любых диалогов в целом.
Возможно, вам так показалось, потому что вы не знаете всей ситуации. Там не было спора, был вопрос, как лучше реализовать задачу — через if или try/except. Я выбрал if и сделал через if, интервьюер ожидал try/except и спросил, почему так. Я объяснил свою логику, но после этого его прям сильно бомбануло)
Возможно, вы не так поняли) Конечно, в обычных случаях никто не запрещает использовать гарнитуру, хоть сабвуфер. Проблема не в самих наушниках, а в том, что есть конторы, которые за деньги или откат от зарплаты помогают людям "пройти" собеседования. В таком случае кандидат сидит на собеседовании, а в наушнике у него "сеньор Вася", который подсказывает ответы или даже пишет код за него
Не, не, точно не обязан, тут упомянул про это
Эта рекомендация скорее для тех, кто хочет повысить свои шансы, особенно если приходит на собеседование "попытать счастья". Если вы лютейший сеньор, то, конечно, логично, что рекрутеры должны сначала изучить ваш опыт сами.
Но суть именно в том, чтобы увеличить вероятность успешного собеседования. Бывают компании с очень сложными процессами: тысячи сотрудников в IT-отделе, сотни команд, и владение какой-то конкретной технологией может быть критически важно не только для работодателя, но и для самого кандидата.
История из жизни: к нам как-то пришёл разработчик, пусть его звали Юра. В этот же день Юра уволился, потому что "в гробу видал он этот gRPC". С тех пор мы звали его "Юра один день". С одной стороны, кому-то может показаться, что это мелочь, но бывают ситуации, когда знание определённой технологии — суперважно для бизнеса.
Ну и бывают случаи, когда кандидат просто не указал что-то важное в резюме. Например, лет 7 назад у меня был коллега — питонист, но работал 1С-ником когда-то. На собеседовании его спросили:
— Знаешь Python?
— Да, ещё и 1С знаю.
— О, так нам как раз 1С-ник нужен, поехали к нам!
В итоге он получил оффер на зарплату в 1.5 раза выше той, на которую рассчитывал)
Так что это действительно важный момент)
В идеале, да, обратную связь должны давать без запроса — те, кто проводили собеседование, а HR передавать её кандидату. Но, как показывает практика, так бывает далеко не всегда. У меня тоже были случаи, когда даже сам факт отказа не сообщали, и приходилось самому "напоминать о себе", чтобы просто получить ответ)
Поэтому иногда имеет смысл самому запросить фидбэк, особенно если есть понимание, что где-то не дотянул и нужно подтянуть слабые места. В идеале, конечно, записывать вопросы с собеседования, но на практике, фиг, что записать успеешь, да еще в стрессовой ситуации, короче есть нюансы