Комментарии 263
Насчёт пункта 19 в больших европейских собеседованиях прямо-таки можно писать книгу.
И всякие книги, собственно, и пишут. :)))
А вот что вы скажете, если кандидат, прямо идеально подходя по остальным пунктам, на вопрос из п.19 открытым текстом вежливо скажет всякое нелицеприятное, причём кратко, но объективно обоснует, почему.
Это же противоречит классическим правилам ответа на этот вопрос!
Во всех этих инструкциях не пишут про умение «читать между строк». Ведь важно не только то, что человек говорит, но и как. Плюс контекст.
Пришёл человек в стартап устраиваться — там скорее всего все посмеются и не придадут значение.
Придёт в какой-нибудь банк или крупную корпорацию, то там градус серьёзности зашкаливает.
А в России вообще с этим просто, по-моему.
ВЫВОД: нужно говорить, что ты дауншифтер и тебе надоело зарабатывать огромные деньги, которые не успеваешь тратить, и очень надеешься, что новый работодатель будет платить мало.
Работодатели! Скажите честно! Вы бы приняли на работу дауншифтера идущего на меньшие деньги?
На почасовую оплату крутого специалиста — с руками бы оторвали. Даже на 20 часов в неделю. Но таких найти крайне тяжело.
Тут вопрос в том что собеседование это по сути оценка риска. Какой риск, что соискатель:
-адекватен;
-пришел только подсмотреть, подучиться, а сам планирует открыть бизнес в той же сфере;
-не умеет работать в команде;
-вырастил корону на голову;
-деньги для него не являются хоть сколько влияемым фактором и поэтому он в любой момент имеет финансовую возможность все бросить и уехать в Тибет лам разводить;
и т.п.
Поэтому когда такой дауншифтер приходит — оцениваешь его. Если в целом объяснение похоже на правду и проверяется, например дичайший перегруз на предыдущей работе и уточнение у предыдущего работодателя подтверждает это, то можно брать.
Вопрос психологии — человека нужно понять и оценить. Сделать это сложно, граблей хватает — но нет ничего невозможного.
-деньги для него не являются хоть сколько влияемым фактором и поэтому он в любой момент имеет финансовую возможность все бросить и уехать в Тибет лам разводить;
Вот это ключевой момент. Ни ипотеки, ни детей. Денег достаточно. То есть надавить на такого человека в случае чего будет сложно, эйчары скорее не возьмут такого человека, чем возьмут.
Ага, https://bash.im/quote/417928 — это кто-то цитату с моего давнего собеседования запостил на баш.
Вообще, кредиты, дети, количество денег — это личные вопросы, на которые можно не отвечать.
Другой вопрос, стоит ли в такое устраиваться, но ситуации бывают разные.
Собеседование со «Службой Безопасности» (именно с Больших Букв),
Да, был у меня как-то собес с безопасником одного банка. Предварительно надо было заполнить анкету. Одно из требований — данные отца, а я его 20 лет не видела. Как он выглядит не помню, а уж что там говорить о том кем работает. Матушка с большим натугой вспомнила год его рождения. Так безопасник крайне удивлялся, как это так, я не знаю. Даже велел матери звонить при нем.
Там вообще вопросов было.
Спрашивал пью ли я, курю и принимаю наркотики. Ага, даже если у меня алкоголизм, так я в этом признаюсь.
Интересовался адресами моей нынешней и прежних работ. вот зачем мне помнить столько не нужную информацию.
Есть ли у меня долги, кредиты, ипотека. Адрес моей новой строящейся квартиры(я в ней уже два месяца живу и знаю приблизительно адрес).
Есть ли машина и права. Вот не понимаю какое это имеет отношение к делу, как и про квартиру.
В общем мне хотелось от туда сбежать, хотя офер потом прислали
Есть ли у меня долги, кредиты, ипотека.
«А вы с какой целью интересуетесь?»
А так, да, я же говорю — СБшники очень любят делать вид. Со стороны это смотрится порой смешно.
Если в целом объяснение похоже на правду и проверяется, например дичайший перегруз на предыдущей работе и уточнение у предыдущего работодателя подтверждает это, то можно брать.
FULL STOP!!!!!
А если он ещё не ушёл с этой работы, а только собирается уйти, вы что звоните и сообщаете его руководству «ваш сотрудник собирается уйти и ищет работу»?!
если сотрудник приходит просить повышение, то с психологической точки зрения, его смело можно и нужно увольнять, «шантаж» недопустим
Вот из-за такого подхода, сотрудники часто предпочитают сразу сменить работу, вместо того чтобы попросить повышения.
если сотрудник приходит просить повышение, то с психологической точки зрения, его смело можно и нужно увольнять
… и нанять на его место следующего бедолагу.
Это крайне омерзительная точка зрения, работать с такими людьми — себя не уважать.
Я не руководитель, а обычный разработчик, мое мнение сложилось по опыту, поймите меня правильно
Зачем вам такой сотрудник, который периодически будет попрошайничать?
А ничего что цены растут?!
И ничего что, новый сотрудник, который пришёл на ту же самую должность, что и давно работающий получает заметно выше за ту же самую работу?
Или по-твоему, сотрудник проявивший лояльность не сменив работу — «лох, который должен страдать»?
Зачем вам такой сотрудник, который периодически будет попрошайничать?
Слушайте, мне вот прямо нравится эта негативная коннотация. «Попрошайничать». Слово-то какое подобрали.
Поэтому я и утверждаю, что нах… такого владельца идиота, пусть ищет себе рабов-студентов, если уж он мыслит в таких категориях, ну и конечно, удачи ему!
Если у вас всегда так было, это не значит, что так должно быть везде и у всех
P.S. Не надо утрировать и задавать вопросы про цены в магазинах, дискуссия идет строго в определенном контексте и для конкретной сферы деятельности
Вы уже достойны повышения в должности или в зарплате. Но понимаете, что у вас не хватает навыка провести переговоры об этом с руководством. Для вас это выход далеко за вашу зону комфорта и поэтому вы замещаете это на мысль: что такие переговоры это «попрошайничество» и «шантаж» и вообще вас за это сразу уволят.
Конечно многое зависит от личных качеств руководителя и от корпоративной культуры. Однако в большинстве организаций, если ваш руководитель адекватный человек — с ним можно провести подобные переговоры так чтобы это не было попрошайничеством или шантажом.
С позиции работника можно уточнить, например, что нужно сделать, уметь и знать, чтобы получить повышение или рост зарплаты. Или например уточнить, что тут вам пришло приглашение на более выгодную зарплату(должность) и уточнить, что ближайший полгода-год вы точно не уйдете, что когда решите уходить — за три месяца(или сколько надо для первичного обучения замены) предупредите, что вам вообще нравится тут работать, но можно что-нибудь подумать на счет зарплаты(должности).
И вопрос по зарплате(должности) не подымать чаще чем раз в полгода, а лучше год. Если он не решился положительно — можете думать над тем чтобы искать новую работу, только предупредите руководство если начнете поиск и отработайте достаточный срок для подготовки замены.
Так если вы проводите переговоры не чаще раза в полгода, то это не попрошайничество, а периодическая оценка ваших рабочих качеств и соответствия оплаты за них. А если при этом четко скажете, что в случае решения поменять работу вы однозначно отработаете время для подготовки замены, то это не шантаж. Это нормальный ход работы.
У каждого руководителя есть определенный люфт в плане зарплат подчиненным, и тут вступает в силу вопрос — что ему проще, выбить вам зарплату побольше или нового человека найти. Если люфт по зарплате есть, то это значительно проще, чем искать другого сотрудника.
А если зарплату поднять не могут, значит у вас по крайней мере есть определенность. А это уже очень хорошо.
В идеальном мире конечно руководитель он все видит и все знает. А в реальном мире руководитель иногда замечает, а иногда нет. И если он этого не заметил — дайте ему шанс. Помогите ему исправить эту ошибку. Переговоры с руководителем о своей карьере это нормально!!! Однако делать это нужно аккуратно и деликатно. Чтобы это действительно не выглядело как шантаж или попрошайничество.)))
А вы не задумывались, что возможно у вас такая ситуация.
Именно потому я так и утверждаю, что считаю, что у меня такая ситуация
И если он этого не заметил — дайте ему шанс. Помогите ему исправить эту ошибку.
Вы серьезно? Вы считаете, что до меня с руководителем никто не общался из сотрудников? Просто люди зачастую ленятся в своем профессиональном развитии и не хотят меняться с течением времени
«шантаж» недопустим, да и вообще, попрошайничать стыдно и позорноКогда в вашем мире какая-нибудь фирма повышает цены на свои товары/услуги, это тоже шантаж или попрошайничество?
«шантаж» недопустим, да и вообще, попрошайничать стыдно и позорноТролинг какой-то.
А если не стыдно? А что значит позорно, это стыдиться мнения неизвестных и неинтересных вам, окружающих людей, пусть даже сотрудников?
Вы себе нанимаете рабов/легко манипулируемых сотрудников?
И как, схема устойчиво работает, клиенты довольны вашими сотрудниками?
Илои просто заявление на сто, если руководитель начинает подлизываться и предлагать больше — решительно отвергать, подкуп недопустим.
попрошайничать стыдно и позорно
Стыдно и позорно манипулировать людьми.
Стыдно и позорно не ценить свой труд.
Платить людям три копейки и занижать их самооценку вместо поднятия стоимости компании в глазах сотрудников это вообще недальновидно
Если ответ — нет, то выясняю почему. Это ведь очень важный звоночек, это элемент нечестного отношения к текущему работодателю и нужно выяснить это ответная реакция на неправильное поведение руководства или низкая планка ответственности перед работодателем. Если на уточняющий вопрос, почему не сообщили, ответ — А я не обязан, не знаю, не хочу и т.п. То нет смысла брать такого сотрудника, он потом точно так же кинет вас.
Если есть адекватная обида со стороны кандидата на текущего работодателя, то проверяется это очень аккуратно и только косвенными методами. Само собой что в этом случае звонить напрямую нельзя. Если не получается так проверить, значит остается рисковать и верить на слово. Вопрос важности сотрудника и критичности ошибки при найме.
А если говорит, что предупреждал руководство, то это нормально — позвонить и уточнить. Многие фирмы предпочитают не увольнять человека сразу, а дать срок для поиска новой работы — в этом случае чем звонок плох? Конечно еще неплохо спросить кандидата, можно ли позвонить на его текущую работу. И если он предупреждал об уходе, а позвонить нежелательно — это еще одна хорошая зацепка узнать лучше кандидата.
Сказала — хочет мужа и детей)
Работодатели как девушки — любят тех, кто бегает от них, а не за ними. Любое принижение кандидатом своей позиции/требований/опыта автоматически отправляет его в френдзону, где у него нет шансов.
Почему это работает именно так (приводит к такому результату), прежде всего по психологическим причинам — долго объяснять, хотя на самом деле чуть выше один комментатор в трех строчках все объяснил.
Но можно посмотреть, как это работает с технологической точки зрения, и как улучшить результат.
По всей видимости, «в целом тянет своё направление» — это еще и орг работа (а, возможно, не орг, но тянет направление в «продуктовом» или «предметном»/доменном смысле)?
А нет версии, что на этом фоне, если идти на дауншифтинг, то чисто исполнительские скиллы, да еще в части применения современных технологий, ослабли?
Тогда есть смысл в собственном текущем развитии сконцентрироваться на подтягивании технологических знаний и навыков, и сделать в CV упор именно на эти навыки (наверняка уже все ушло вперед, и есть что наверстывать и/или переосмысливать в новом качестве), а организационные, руководящие, аналитические и тому подобные навыки задвинуть немного в фон.
А если при этом для перехода выбрать смежную, но технологически и политически более перспективную платформу, то желание перехода будет более понятно, и особо не придется ничего объяснять.
Другими словами, нужно не просто говорить «ах, мне это не нужно, а нужно то и то», и рассчитывать, что «то и то» тебе дадут, а нужно прежде всего внутренне измениться, и действительно хотеть и мочь пойти туда, где есть вот это «то и то».
Даже если сходу не получится попасть туда, куда 100% надо, то в середине пути человек обрастет и новыми знаниями, и новыми коллегами/знакомствами, вообще станет своим, и тогда конечная точка маршрута станет реально достижимой.
Да и не будет этой конечной точки — будет развитие на новом пути и и достижение все новых и новых вершин.
А при этом может еще и оказаться (и, скорее всего, окажется), что, сделав на новом пути дауншифтинг в занимаемой позиции, человек вырастет в материальном, в возможностях развития, в свободном времени, и т.д. — т.к. на новом пути в целом будет в целом «все лучше».
Но — все это требует огромной внутренней и не только внутренней работы («в свободное от основной работы время»!), и качественные результаты будут видны далеко не сразу — т.е., не тогда, когда человек выйдет на новую работу, а заметно после.
Поэтому в России предпочитают нанимать молодёжь с горящими глазами, готовые заниматься интересным делом за заниженную зарплату.
Ну и много эффективных менеджеров, не читавших классику (Брукса, например) и верящих, что одного сеньора можно заменить 2-3-5 джунами/миддлами.
А Опытный зажрался и считает, что ему должны выдавать зарплату только за факт совего существования. «Вы хотите чтобы я еще и работал? Тогда платите в два раза больше!»
Не каждый выпускник дотягивает даже до джуна.Около 80% (или даже 90%) выпускников до джуна не дотягивает, по той причине что раньше все поступали на юристов и финансистов, а теперь поступают «вайти-в-айти» надеясь что корочка им автоматически гарантирует сверхвысокую зарплату.
джун… если он не идиот, то вполне способен вытянуть проект даже без опыта
Многократно пройдясь по всем известным старым граблям, и угрохав борьбу с граблями кучу времени.
Я не утверждаю, что всегда надо работать с джунами.
Я лишь отвечаю на вопрос — почему джунов любят нанимать.
Любят их нанимать, потому что они справляются.
Хелло ворлд безусловно дешевле заказать у джуна. Всё, мало-мальски более сложное, просить сделать юниора без надзора — самоубийство.
www.youtube.com/watch?v=aeSOLJnw8p4
На видео там только сама сцена. Но за бортом там еще достаточно мощный редактор уровней, терминал управления с поддержкой плагинов и система синхронизации, позволяющая запускать сцену на кластере. Это с учетом того, что там вообще то скрипты, которые синхронизировать — та еще задачка.
Сделано всё удаленно и без надзора.
Если бы наняли сеньёра — проект скорее всего не состоялся бы, потому что врядл сеньеор согласился бы работать за 400 долларов.
Плюс рано или поздно работодатель встречает способных джунов и начинает думать, что проще найти таких джунов, чем платить тыщи сеньеору.
Поэтмоу, кстати, многие компании делающие не слишком сложный софт имеют постоянно открытые вакансии на тыщи позиций. Просто перебирают варианты, в надежде наткнуться на способного новичка.
Промышленная разработка, если вы не знаете, это даже не только и не столько про программирование программ с нуля. Это архитектура, технологии, фреймворки, лицензии, сертификаты, деплоймент, переговоры, менеджмент, поддержка, руководство и пр и пр.
А набросать проектик на коленке в своё удовольствие — так это и студенты делают на курсовых.
То что вы за самописный движок предлагаете «джуниорскую» зарплату — говорит о вашей патологической жадности, и любви к унижению людей.
(и нет, на видео работа не джуна, а мидла — если не в начале разработки, то в конце точно)
Когда нам понадобилось добавить крупную фичу в код, написанный семь лет назад крепким синьором — мы её взяли и добавили. Когда нам понадобилось добавить маленькую фичечку в код, написанный полгода назад весьма подкованным мидлом, который знал, в какую сторону будет расшираятьса дальше код — пришлось обложиться кучей костылей, и на ближайшей рефактор фазе вообще переписать модуль.
Собственно, в этом и заключается единственное отличие синьора от мидла (а говорите вы, повторюсь, не о джунах).
Джуны-джунами, но сложные вещи с долгоиграющей поддержкой одними новичками лучше не делать. Иначе можно будет разориться на поддержке.
Ну, честно говоря, у HR свои взгляды на многие вещи.
При правильном применении это может действительно служить на пользу фирме/компании/корпорации. И лично мне доводилось общаться при обсуждении некоторых рабочих вопросов с действительно классными спецами.
Вот только, как и в любой сфере человеческой деятельности с широкой степенью охвата общества, и в этой сфере "люди всякие бывают"… :)
digore — а вот вы почему-то так и не ответили на мой вопрос насчёт 19-го пункта…
А вот что вы скажете, если кандидат, прямо идеально подходя по остальным пунктам, на вопрос из п.19 открытым текстом вежливо скажет всякое нелицеприятное, причём кратко, но объективно обоснует, почему.
Тут ведь нужно смотреть не только на то, ЧТО он скажет, но больше на то, КАК он это скажет. Нужно быть немножко психологом.
Не так давно девочка на этот вопрос ответила спокойно и рассудительно: потому что меня заставляли выходить в выходные и перерабатывать без оплаты сверхурочных. Зато когда она это говорила, ее губы задрожали. Не все из присутствовавших на собеседовании это заметили…
Просто вы неправильно воспринимаете этот вопрос. Вы думаете он задается с целью узнать, реально, зачем вы идете к ним работать. Но на самом деле это тест на конформность — твоя готовность к социальным реверансам и принятию правил игры. Так же как и вопросы про "кем вы видите себя через 5 лет" и другие идиотские вопросы. На них просто надо знать правильные ответы.
Все равно что девушке при ухаживании сказать всю правду о ее внешности, вместо того, чтобы говорить, какая она красавица. Продолжение светит умным, а не честным.
Кем вы себя видите через 5 лет? (До этого вопроса надо было сделать ДЗ и узнать немного про компанию и оргструктуру, куда собеседуемся). Далее, в зависимости от предпочтений: 1) мне кажется, я бы смог приносить наибольшую пользу компании, значительно улучшив свои профессиональные навыки и получив должность (называем должность 1-2 позиции выше той, которой собеседуемся — техлид, тимлид, архитектор решений) через 3-4 года. Это позволило бы повысить уровень ответственности за принятие решений, а сами решения влияли бы не только на скорость сортировки, но и на архитектуру разрабатываемых мною решений. Б) Вариант менеджера: мне кажется, что через несколько лет я буду не настолько молод, чтобы иметь такую же работоспособность как у меня сейчас. Но с годами приходит опыт, и окончив (MBA/экономический/юридический факультет чего-нибудь) я бы смог сначала занять позицию менеджера команды, а впоследствии, может быть, получить должность менеджера продукта. Имея сильный достойный технический бэкграунд в вашей компании, я бы смог быть на одной ноге с разработчиками, а с полученным образованием, я бы смог смотреть на разрабатываемые продукты с точки зрения бизнеса — мы же хотим, чтобы бизнес был успешен, ведь так?
Кем видеть себя через пять лет — это не совсем идиотский вопрос. Он слишком заезженный, и задается порой не в тему, отсюда и кажется глупым. Работодатель хочет оценить амбиции человека и его способность к саморазвитию без того, чтобы его гнать в эту сторону. Можно смело рассказать о ваших планах развиваться как профессионально, так и человечески, включая культурный уровень, достижения в хобби и т.п. Глупым ответом на этот вопрос будет ответ в духе «в вашей компании я стану руководителем» (или иные карьерные изменения). Еще вообще ничего не известно о компании, о работе, о принципах и правилах, а кандидат уже губу раскатывает.
Зарплата конечно важна, но стоит на втором месте.
В остальном, я согласен, что бывает интересная работа или сфера, в которой хочется работать, даже если получаешь меньше. Этот случай я указал в своём комментарии выше.
Первые пункты, казалось бы, очевидны, но даже их не все соблюдают, увы.
> ведь скорость овладения новыми знаниями важнее, чем текущие знания кандидата.
Количество интервьюеров, которые это понимают, ускользающе мало :)
> Спросите его цели на ближайшие 1-3 года. Знаю, что многие кандидаты не любят этот вопрос и не знают, что ответить
По моему опыту, если спросить «кем вы себя видите в компании через …» то это ставит в ступор и потому, что это клише, и потому, что речь идёт о статичной цели в довольно отдалённом будущем (в IT даже 1 год это уже срок). Дать хороший ответ (а не продолжить игру в клише) на это мало кто может.
Можно спросить соискателя, если ли у него дорожная карта на ближайшие полгода-год на тему того, что он хочет в компании достичь, узнать, прокачать навыки. Т.е. более детализированно и меньшие сроки.
«кем вы себя видите в компании через …» то это ставит в ступор
У меня есть прекрасный, но неприличный ответ на этот вопрос. Пару раз я его применил. Эффект потрясающ. Главное — сохранять крайне серьезные щи. Точнее, его можно применять, если HR не употребил словосочетание «в компании». «Кем вы себя видите через пять лет?» — вот тут-то и можно подсекать.
Может, конечно, меня за такой юмор ниже пояса и заминусят, но я искренне считаю, что это один из самых идиотских вопросов, которые могут только быть на собеседовании, вместе с «почему наша компания должна нанять именно вас?»
Это в случае, если вы очень-очень хотите работать в этой компании.
Хотя вспоминается «мегапихарь»… так сказать, нашлись люди в реале…
Откуда программист может знать, какие технические проблемы есть в проекте компании? Например, какую важную проблему можно решить для Хабра?
Правильный ответ, ИМХО, всегда один: «не понадобится, она нужна только умным детям».
По поводу 21 не соглашусь. А если человек, например, регулярно опаздывает и приходит на работу с бодунища, тупит до обеда и делает в два раза меньше, чем остальные? Вряд ли об этом написано в резюме, да и на собеседовании он в этом не признается.
звоним в предыдущие места работы и просим рекомендации.
Надеюсь, до собеседования.
Ни для кого не секрет, что есть начальники не очень хорошие люди или просто малокомпетентные, и возможно у них будет другой взгляд на работу сотрудника. Ну скажем, "вечно норовит от работы отлынивать, по задачам не успевает", а на самом деле это про постоянные переработки в выходные. То есть кому-то не только не повезло там работать, а еще и на новой работе аукнется.
Обмануть опытного собеседующего в ответе на этот вопрос очень сложно.
Но и негатив про предыдущего работодателя говорить не принято, так что абсолютно искреннего разговора не получится.
Если кто-то мне скажет, что кандидат раздолбай, я просто не стану звать его на очную встречу.
Хотя, конечно, как совет новичку в качестве интервьюера — согласен. Сколько раз было — приходит по рекомендации вроде ничего, а по факту…
Я принимаю инженеров на производственное предприятие — головоломки даю не часто, но бывает))) А вот что даю всегда — так это задачи по математике и физике за 4-8 класс до 3 действий.
А то когда инженер не знает формулу площади круга, как решать задачи на трудоемкость и тому подобное, то какой он тогда инженер?
К айти конечно только косвенно относится, но по опыту могу сказать, что люди которые решают — практически все толковые. За остальных сказать сложно, так как не брал))) Но многие из них приходили с рекомендациями, а потом ни одной задачи не решали)))
Как выпускник физтеха скажу, что подход не очень. С iq, смекалкой, решением нестандартных задач и прочим у меня всегда было все отлично. А вот стандартные задачи давались раньше тяжело, ибо были скучны, а я — недостаточно собран и внимателен. Могу ответственно сказать, что работник из меня был очень посредственный.
Только благодаря особым событиям в жизни и серьезной работой над собой я стал действительно хорошим работником.
А собеседуя ребят с того же физтеха сейчас, наблюдаю как раз ситуацию, когда мозг есть, но далеко не факт, что он пригодится в работе, и что когда-нибудь его вообще получится настроить на рабочее русло.
Мораль такова: мозги — хорошо, но для работы недостаточно. Умение работать — еще лучше, можно брать работать вечным мидлом. А если есть и то, и то — бинго, надо брать с прицелом в ключевого специалиста.
Разве что вместо целей на 1-3 года я спрашиваю более конкретны вещи, например если это программист, то собирается ли он дальше развиваться в узкой области (фронт-энд, например) или хочет быть более универсальным, хочет ли попробовать руководить коллективом, изучить другой язык, и т. д. Из ответов можно получить полезную информацию о кандидате.
Проходил на днях собеседование.
Профильные вопросы спрашивали так:
"- Представление о шейдерах в UE имеешь?
-Конечно. Писал свои движки, поэтому с шейдерами на ты. И в самом UE тоже немного ковырялся."
КОНЕЦ ВОПРОСА.
В таком духе по всем профильным вопросам.
«Знаешь?
Да.
ОК.»
А в конце началось: «Как проверить что односвязный список не зациклен?»
Чего?? За 10+ лет в геймдеве я ни разу не использовал односвязные списки. Я не мыслю односвязными списками. Зачем вам это?
Еще замечательный вопрос:
"- Как создать экземпляр класса в фиксированной области памяти?
— Эээ. Перекрыть new?
— Почти. Есть стоковое решение."
WAAAT? Зачем? Зачем это в геймдеве?! Я могу представить свой менеджер памяти, которому понадобится такой функционал. Я могу представить ситуацию при работе с драйверами, когда нужно создать объект в фиксированной памяти. И то, я бы 10 раз подумал прежде чем использовать такой инструмент. Но геймдев? Особенно при работе с таким движком как UE, в котором использовать new в любом виде — прямой путь к проблемам…
Ребята еще не ответили, но после такого собеседования, таких вопросов — работать с ними уже не хочется.
Простите за оффтом, бомбануло. :(
Поэтому, когда вас спрашивают о сортировке списков, возможно, у компании есть собственный движок чего-то, во внутренностях которого иногда приходится иметь дело с вещами, которые современные движки от пользователей успешно скрывают.
У нас, например, довольно много низкоуровневого С++ кода, и не умеющий с ним работать человек нас автоматически не устраивает. С моей точки зрения, джун должен уметь решать как минумум простые задачи, его этому в универе на лабах учили. Мы его уже в свою очередь научим, как из простых решений собрать большие, как думать в контексте системы и так далее. Учить программированию все же не наша задача, а собирание решения из готовых деталек — это не программирование сложной системы со всеми ее низкоуровневыми нюансами.
Я не решил сходу задачу на проверку списка, потому что я не работал с односвязными списками, и построить мышление быстро я на это не могу.
Если вдруг такая задача возникнет, я за 5 минут её не решу сходу. Я буду думать пол дня над вариантами. Потому что незнакомая тема(односвязные списки), потому что не сталкивался раньше.
Этот вопрос не на умение придумывать алгоритмы, это вопрос на «ты уже встречал этот вопрос на собеседовании?»
1. Берем второй указатель
2. ??????
3. PROFIT!!!
Если знаешь пункт 1, дальше как раз за время, отведенное на задачу, можно найти решение для большинства самых хитровыдуманных задач на односвязные списки. Если не знаешь — шансов очень мало.
Собеседующий: Брать второй указатель нельзя.
Соискатель: WAT?
=)
Так вот, с моей точки зрения, в контексте разработки алгоритмов в конкретной компании, оба вопроса — и про списки и про размещение в памяти — были бы уместны. Первый покажет ваши знания структур данных, без хорошего понимания которых в алгоритмах делать нечего. Второй покажет, что вы имеете представление о методах оптимизации размещения объектов в памяти. Не теоретически, а практически. Причем, задачу даже не обязательно решить, я бы просто смотрел, как вы ее решаете, этого более чем достаточно. Опять же, уместны только в том случае, если в работе этим приходится заниматься. Но при разработке алгоритмики игры вам разве не прийдется с этим столкнуться? Неужели движок UE все, ну вот прямо все сделает за вас?
За это время я использовал односвязные списки ровно 0 раз.
По поводу new — если говорить об UE — то про new вообще следует забыть. Использование new это ошибка. В UE свой менеджер памяти с GC, что-то выделять в обход него — большая ошибка, которая аукнется очень быстро.
Безусловно есть области деятельности где знание о существовании new с явным указанием адреса и односвязные списки нужны и полезны. Поэтому я и уточнил, что речь не об абстрактной работе, а о вакансии на UE программиста.
Я писал свои движки. С нуля. Более 10 лет я этим жил и зарабатывал.
Тогда тем более странно, что вы считаете вопрос про простые структуры данных сложным и не подходящим для собеседований.
Поэтому я и уточнил, что речь не об абстрактной работе, а о вакансии на UE программиста.
Я тоже уточнил, что, возможно, кроме движка UE там есть еще что-то.
Тогда тем более странно, что вы считаете вопрос про простые структуры данных сложным и не подходящим для собеседований.
Там есть вторая часть высказывания. Про 0 раз.
Я считаю этот вопрос идиотским и не уместным.
Потому что он не про «стандартыне структуры данных». Он про «решите ка мне быстренько задачку, которая в нашей области не встречается, на структуре данных, которая используется чуть реже чем никогда, за ближайшие 5 минут, пока мы ждём»
А вопрос развернуто звучит так: вот есть структура данных и нужно на ней алгоритм, как бы вы решали эту задачу учитывая особенности структуры, проанализируйте граничные случаи, обоснуйте, составьте тест-кейсы. Интервьювера в данном случае интересует не готовое решение — его-то скорее не будут ожидать вообще — а то, как вы будете над ним думать. И лучше всего наблюдать процесс решения на белой доске.
В моей практике ковыряния в недрах кода встречалось такое, что Кнут и в страшном сне представить не мог. Так что если это вам не встречалось, то это еще не значит, что это не нужно на работе, на которую вы хотет попасть.
Использование new это ошибка. В UE свой менеджер памяти с GC, что-то выделять в обход него — большая ошибка, которая аукнется очень быстро.
Я не могу удержаться, когда вы второй раз на этом акцентируете внимание. Расскажите, пожалуйста, уже нам чем это аукнется? Опережая ответ: зачем тогда вообще писать на C++, когда все доступно на блюпринтах?
Я как-то был на собеседовании MS, где как раз давали такую задачу на смекалку, белую доску, маркер и 45 минут общения с «экзаменатором». Я готовился по книжке задач собеседований MS, половину задач я знал, но это не помогло по очень простой причине: важно не решить задачу, важно показать, как вы будете подходить к решению. При этом на вопрос «что вы делаете на работе» у каждого инженера из MS загорались глаза и он начинал рассказывать про оптимизацию трафика хранилищ данных, гео-привязку или быстрый поиск по огромным наборам данных. И каждый раз было понятно, что смекалка и умение правильно решать задачи — это основа их работы, а задачи на собеседовании в целом оправданы.
Чуть позже я проходил собеседование в другой компании, из Долины. Там задачи на алгоритмы были действительно сложные, а рабочие задачи, о которых рассказали инженеры, были совершенно с алгоритмами не связаны. Ну разве что одна из них, мне ее и дали на собеседовании, я ее решил за час с маленькой подсказкой. Зачем им были нужны крутые алгоритмисты и такое сложное собеседование — я так и не понял, и в этом случае с вами согласен, такая форма собеседования там была, скорее всего, не нужна.
Как соискатель вы, возможно, не знаете, зачем задают те или иные вопросы. То что кажется вам совершенно излишним, может оказаться ежедневной реальностью работы.
ну и кроме того, алгоритм — это лишь одна из составляющих интервью. так же смотрят на то, как оформлен код, как структурирован, насколько легко читается, легко ли будет расширяться, если вдруг изменятся тербования, как кандидат пришел к решению (мыслительный процесс), как держал себя, как разговаривал. в зависимости от фокуса интервью, какие-то параметры меняются, на что-то обращается больше внимания, на что-то меньше.
Вы это лучше расскажите моему оппоненту, которого бомбанул вопрос про поиск циклов в односвязном списке, как не релевантный работе.
Обычно, когда работаешь с чем-то потенциально требующем оптимизации, первое, что требуется сделать — выбрать структуру данных, отвечающую требованиям, включая потенциальные новые требования в будущем. Односвязные списки, допускающие зацикливание, ну никак не тянут на успешную структуру, как мне кажется.
На мой взгляд, требование у доски на собеседовании рассказывать какие-то тонкости и хитрости — это чрезмерно, достаточно, что у кандидата есть обзорные знания. В моей работе алгоритмы и структуры используются почти в каждом проекте, и особенно в многопоточной среде. Использование этого дает конкурентное преимущество и вообще способность создавать адекватные рынку решения.
А касаемо списков — это тот минимальный уровень владения алгоритмами, который реально нужен почти в каждом проекте. Деревья у меня почти не используются (кроме реализаций стандартных библиотек), но списки практически повсеместно. И списки самые разные. Умение писать список и работать с ним, на настоящий момент времени, — это основной навык после умения писать циклы и работать с граничными условиями. Редко в каком коде не используется динамическая память, так что объекты, так или иначе, надо группировать и как-то проходить по ним. Минимум — это связывать их в список.
Так что, необходимость знания алгоритмов работы со списками зависит от задач.
с огромной вероятностью решение вы знали. интервьюера интересует не «знаете или нет», а «как вы до этого решения дошли».
Часто задачи приходится действительно решать, читать статьи, проводить параллели.
Вот это и имеется в виду, когда говорят про "найти в гугле". То есть где-то прочитать дополнительный материал. Это не означает "найти готовое решение".
Почему вы приравниваете «загуглить незнакомый термин» и «гуглить каждый термин»? Первое не означает второе. Если человек не знает такое количество терминов, он просто собеседование не пройдет.
Почему вы решили, что человек будет гуглить каждый раз при встрече термина? Откуда этот вывод про вечность? На каждую группу задач незнакомая информация гуглится только один раз, после этого она становится знакомой.
Сформулирую еще раз. Позиция алгоритмиста подразумевает, что у человека в голове наличествует определенная система знаний, которая в свою очередь означает, что человек знает базовые термины. Наличие тех или иных определений в голове и умение ими оперировать и решать задачи — или хотя бы анализировать задачи — обычно выявляется постановкой алгоритмических задач на собеседовании.
Умение гуглить, т.е. быстро получать факты и подсказки очень условно соотносится с системой знаний. Факты — это не знания. Знания — это книжка, или курс, это дни чтения. Если мне нужен специалист по алгоритмам, я буду ожидать от него умение оперировать базовыми понятиями без помощи гугла. Если мне будет нужен спец по нейронным сетям, то на базовые вопросы он тоже должен будет отвечать без помощи гугла, пусть даже без терминов, пусть своими словами.
Если же без подсказки человек не умеет понять и указать направление решения задачи, то я делаю вывод, что решать такие задачи он не умеет, с гуглом-ли или без. Если простую задачу он сможет решить, то я уверен, что с гуглом он решит и любую сложную.
Чтобы загугленная информация стала действительно знакомой, опять же, в голове должна быть система, в которую новые знания будут встроены. Если же в голове каша, то новый термин только увеличит ее количество и густоту.
Это все менее касается разработчиков, которые больше работают с приклаными библиотеками, где нюансов больше чем принципов, а нюансы действительно сложно запомнить в таких количествах, и тут уж гугл в помощь. Но чем позиция ближе к Computer Science, тем больше нужно держать в голове, просто потому что CS — это логичная система знаний, а не необъятная совокупность фактов.
это гипербола, если что
Я с учетом этого написал)
Позиция алгоритмиста подразумевает
Если вы имеете в виду конкретную позицию, где требуется знание математики, умение составлять алгоритмы с заданными характеристиками по сложности и памяти и доказывать соответствие им математическими методами, то да. Есть области знаний, которые надо долго изучать. Дольше, чем приемлемое время выполнения задачи.
Но начали вы разговор про размышления "на тему «обучения в гугле», популярный ныне подход, когда зачем учить, если можно нагуглить".
Если же без подсказки человек не умеет понять и указать направление решения задачи
Вы не понимаете. Гуглят не подсказки для поиска направления. Гуглят чтобы узнать подробности о возможных решениях задачи, после определения направления.
Если простую задачу он сможет решить
Так дело в том, что такие вопросы не проверяют способность к решению, они проверяют знание готового решения. Если человек нагуглил его полчаса назад, он ее решит. Общие принципы решения задач схожи, если сложную можно решить с гуглом, то и простую тоже.
А как раз для решения с нуля условия собеседования не очень подходят. То что я выше писал.
Если же в голове каша
Ну вот опять. Вы приравниваете "загуглить незнакомый термин" к "в голове каша". Рассматриваете 2 взаимоисключающих варианта. Если человек что-то не знает, это никак не означает, что у него в голове каша.
это логичная система знаний, а не необъятная совокупность фактов
Вот ровно так же, как человек переводит факты в систему знаний до собеседования, так же он будет делать и после собеседования. Вопрос только во времени и иногда в желании, а не в принципиальной невозможности.
Вот ровно так же, как человек переводит факты в систему знаний до собеседования, так же он будет делать и после собеседования. Вопрос только во времени и иногда в желании, а не в принципиальной невозможности.
Если человек перевел факты в систему знаний до собеседования, то вы на собеседовании могли в этом убедиться. Если же нет, то вам надо верить ему на слово, что он сможет это делать после собеседования. Скажем, незнание сигнатуры какой-то функции или синтаксиса использования делегатов — это ерунда и гуглится. Неумение найти эффективный алгоритм для решения задачи, которая для решения требовала знание о существовании делегатов (колбэков) — уже не факт, что нагуглится. Может оказаться, что «параллелей», как вы это назвали, проводить надо будет слишком много, чтобы хоть что-то похожее нагуглить.
Ну и еще одна проблема гугления — огромный процент того, что гуглится, оказывается достаточно низкого качества. Человек, не способный додуматься до решения и привыкший гуглить решения, как правило, не сможет и определить качество нагугленного решения.
Если человек перевел факты в систему знаний до собеседования, то вы на собеседовании могли в этом убедиться.
Он мог не перевести к моменту вопроса конкретно тот факт, о котором его спросили.
Если же нет, то вам надо верить ему на слово, что он сможет это делать после собеседования.
Не надо верить на слово, даете соответствующие условия и проверяете — гугл, отладчик, или что там используется в реальной работе.
Человек, не способный додуматься до решения и привыкший гуглить решения
Ну вот опять. Гуглить что-то не означает неспособность это проанализировать. Как вы это представляете? "как написать бизнес-логику для создания заказа в компании X". "какую структуру данных применить для оптимизации логистики в компании Y". Никто так не ищет. Чтобы предположить, что для задачи нужен кэш, необязательно знать все методы кэширования.
Я сказал, что "зачем учить, если можно нагуглить" в большинстве случаев и есть "читать статьи, проводить параллели". А человек их противопоставляет.
Я сказал, что «зачем учить, если можно нагуглить» в большинстве случаев и есть «читать статьи, проводить параллели».
Дело в том, что если человек регулярно «читает статьи и проводит параллели», у него накапливается приличный слой относительно систематизированных знаний. Есть риск, что задача, которую ему дали на интервью, окажется далекой от всего, что человек знал. Но обычно интервью состоит из нескольких раундов. Конкретно у нас — это 5 разных секций. В предыдущем месте было 4-6. Если во всех пяти секциях человеку надо гуглить, то что-то не так. Или ему прям очень не повезло, или недостаточно он читал статей.
Вот ровно так же, как человек переводит факты в систему знаний до собеседования, так же он будет делать и после собеседования
Если человек делал это до собеседования, то он сможет ответить на вопросы. Даже в стиле «о, я помню было такое, напомните мне вот это, а я додумаю дальше». Это вполне приемлемо.
Вопрос только во времени и иногда в желании, а не в принципиальной невозможности.
Принципиально возможно все, вопрос только в том, должна ли компания тратить время и деньги на то, чтобы заново обучить человека тому, что он должен был бы изучить в университете.
Да я же не зверь какой, не знает кандидат эту задачу, даем другую. Но я уже сколько раз сталкивался с ситуацией, когда человек с опытом вообще не умеет решать задачи. Ни дизайн решения, ни само решение, ни юз-кейсы проанализировать, ни входные данные. Технологии знает — а с зачами просто ноль. Я не сомневаюсь, что он успешно пишет какой-то вполне себе работающий код, костыли к нему делает, старается. Но сколько времени мы потратим, чтобы он стал писать код на уровне качества нашей команды? Очень сложный вопрос, ответ на который «от пары месяцев до бесконечности». Готова ли команда брать такие риски? Нет, не готова.
Поймите мою точку зрения правильно. Современные технологии делают огромное количство знаний в CS просто ненужными. И на большинство позиций все эти алгоритмические задачи, вопросы о распределении памяти и прочие сложности действительно не имеют смысла, в чем я с вами и с другими комментаторами абсолютно согласен. Но иногда люди с этими знаниями чертовски нужны, и найти их с каждым годом все сложнее. Но эти знания нельзя просто найти в гугле, это все же сложная система, требующая для освоения пару лет серьезного обучения, после которых вполне можно без привлечения гугла решать с нуля различные задачи. Даже на собеседовании за полчаса можно набросать анализ задачи и возможный путь ее решения. Даже если человек предложит экспоненциальный лобовой перебор, но сможет указать на эту экспоненту, и после подсказки сможет предложить более эффективное решение, то это уже хорошо. Далеко не все могут даже первое.
Но я уже сколько раз сталкивался с ситуацией, когда человек с опытом вообще не умеет решать задачи. Ни дизайн решения, ни само решение, ни юз-кейсы проанализировать, ни входные данные.
А можете какой-нибудь пример привести? Просто для интереса.
Для собеседования у нас есть простые задачи двух типов: в одних дается несложный кейс на дизайн, нужно построить диаграмму классов, диаграмму событий, разделить ответственности. Во второй задаче нужно написать алгоритм, проанализировать его, оптимизировать и протестировать.
Не смотря на многолетний разнообразный опыт, данный товарищ с кейсом на дизайн не справился вообще в принципе, а при построении алгоритма не смог внятно построить тесты и запутался в std, причем ладно бы в сигнатурах библиотеки, я и сам, бывает, в них путаюсь, но он не знал и концепций. Оказалось, что на практике он не дружит ни с UML, ни с С++11, ни с оптимизацией кода. Интересно, что этот кандидат прошел первый раунд собеседования, который проводил не по-наслышке знакомый с технологиями человек, но не разработчик, а продакт менеджер. И пока мы во время второго раунда спрашивали о технологиях, он очень бойко отвечал, но как только дело дошло до задачи, так сразу и оказалось, что все грустно.
Понимание базовых вещей нужно не только для того, чтобы сделать что-то, чего нет в стандартной библиотеке, а еще и для того, чтобы понимать, что для решения задачи нужно выбрать в стандартной и библиотеке, и как использовать.
Например, в приложении нужно сгенерировать случайную последовательность байтов.
В зависимости от задачи, нужно уточнить, что нам из стандартной библиотеки нужно использовать — генератор псевдослучайных чисел, или же задействовать генератор криптографически строгой последовательности (и то, и то, есть в современных платформах).
А в случае, если в задаче достаточно псевдослучайной последовательности, будет не лишним посмотреть в документации, обеспечивает ли конструктор по умолчанию генератора инициализацию seed хотя бы на основе текущего времени.
(А для этого ведь вообще нужно знать, что такое псевдослучайная последовательность.)
Т.е., даже если все, что нужно, есть в базовой библиотеке, нужно понимать, какие вообще типы задач существуют, и как они маппятся на стандартную библиотеку.
Конечно, в задаче генерации случайной последовательности редкая, но встречается.
Гораздо больше в проде можно встретить кода, который неумело работает с другими задачами, а где то вообще пишутся свои велосипеды, хотя в стандартной библиотеке (именно в библиотеке, а не сторонних «фреймворках») есть готовые решения.
И здесь нужно понимать, что такой код возникает не из-за незнания библиотеки, а из-за незнания именно классов задач.
Т.к. если бы было понимание, с задачей какого класса идет работа, то сразу бы возникло понимание, что нужно посмотреть, есть ли готовое решение (также понимание задачи позволяет понимать, где именно искать — в библиотке, фреймворках, учебниках или stackoverflow).
Вы мне напомнили собеседование в Joom:
- есть бинарное дерево, напишите код, чтобы можно было сказать его максимальную глубину.
- ок. Вот решение за O(1)
- не подходят. Найдите другое.
- оно работает?
- да, но найдите другое.
- лучше O(1) не смогу.
Занавес.
Неверно. После выяснил, что товарищ собеседующий знал алгоритм с O(nlogN) и именно известный ему и допытывал.
знал алгоритм с O(nlogN)
что-то я не вижу, где написано, что дерево сбалансировано.
1. План собеседования? Как Вы выстраиваете встречу? Сколько она длится?
Ну например:
15 минут — рассказ о проекте
5 минут — уточняющие вопросы кандидата
30 минут — тест
15 мин — обсуждение результатов теста
…
2. Что Вы читали / смотрели по теме? Что действительно полезным оказалось?
Обычно собеседование длится не более часа, этого вполне достаточно чтобы сформировалось мнение о кандидате.
Собеседующие просят сделать тестовое задание, получают, хвалят твой код, а после просят расшифровать значение каждой буквы SOLID. Вот с таких собеседований хочется бежать.
![image](https://habrastorage.org/webt/h_/9j/6u/h_9j6udryofeaamvp3iycfx8hkm.jpeg)
Спросите его цели на ближайшие 1-3 года. Знаю, что многие кандидаты не любят этот вопрос и не знают, что ответить.
Хочу добавить, что особенно нет смысла спрашивать об этом джуниоров. Он еще не сталкивался с достаточным количеством областей. Возможно он определится как раз после работы у вас.
Спросите, почему он ищет новую работу.
Потому что нужны деньги. Если имеется в виду, почему решил уйти с предыдущей работы, то лучше так и спрашивать.
- если планирую давать задачу на собеседовании, уточняю заранее согласен ли кандидат.
- всегда начинаю собеседование со 'small talk': «спрашиваю как погода/добрался/дела/и т.д.». Возможно кандидат мыслями ещё на работе или в своих делах, нужно дать возможность расслабиться.
- во время выполнения задачи можно гуглить, я считаю что иначе факт невыполнения задачи показывает не совсем то, что нужно.
Технически-знающий детали специалист может вызвать ошибочное представление о себе как о кандидате высокого уровня. И получаем «сеньоров» с опытом работы в 1-2 года.
Большая часть новичков не сможет адекватно держать сложный проект в рабочем состоянии. Можно наизусть знать фреймворк, библиотеку, разбираться в тонкостях языка, в паттернах, но создавать код, живущий только одну версию, до первых модицикаций. Дальше все скатывается в тягую неповоротную смесь кода, какую сложно модицифировать и развивать. Особенно актуально для продуктовых компаний.
Потом, ничего принципиально-нового со времен 70-х годов пока не сделано. Все что преподносится как новые технологии — все то же программирование на тех же самых принципах. Опытный программист легко переключается между инструментами, языками, библиотеками. А специфические технологические вещи пишутся учеными, потом подхватываются технологическими компаниями, и лишь потом эти технологии становятся доступными тем, кого набирают на работу через резюме. И уже эти технологии обрастают пачками научных работ, готовых библиотек, сред и подготовленной информацией в интернет, коммерческими компаниями, специализирующимися на популяризации перспективных направлений. Простого Васю не возьмут по резюме разрабатывать супер-новую, никем не виданную технологию. Этот Вася должен сначала засветиться в этих средах как специалист, подходящий для разработки новой технологии.
И еще, про 10 лет в моем тексте упоминания нет.
И если меня спросят, участвовал ли я в провальных проектах за много-много миллионов денег, то у меня есть о чем рассказать. ИЧХ, я, хоть и не менеджер, теперь проблемные проекты вижу сильно заранее)
Про второй пункт вспомнил историю. Лет 15 назад, я, тогда уже крутой админ, мне около 20, умею переставлять Винду, настраивать ip адрес, и обжимать витуху. Правда образование не профильное, поэтому решил получить какие-нибудь корочки. Пришел на курсы Оператор ПК, экстерном сдал на отлично. А в этом обучающий центр как раз требуется сисадмин. Ну и пошел я к директору, на первое, в своей жизни, собеседование. А он меня про какие-то сетевые маски спрашивает, модель какой-то оси, и другие страшные слова. В общем, по окончании, вручил мне визитку, и сказал — парень ты неглупый, наберёшься знаний и опыта, приходи. И вот, пару лет назад, когда я перенос очередную компанию, вспомнил об этой визитке, и решил попытать удачи. Но, оказалось, и учебного центра этого больше нет, и директор работает совсем в другой сфере.
В общем, за все 15 лет, и десятки собеседований, это был единственный подобный случай, но самый запоминающийся
Это в идеальном мире, населённом роботами. А в реальном, вам надо чтоб у вас команда работала, а не грызлась по причине несовместимоси мировоззрений.
Согласен. Никто и ничто ничего не гарантирует.
Но если на собеседовании внезапно выяснится, что кандидат — гей-сатанист за путина, то я бы трижды подумал прежде чем брать его в команду семейных украинских разработчиков, например.
У нас бывало и так, что эти вещи (политические взгляды) выяснились спустя значительное время, полгода, год… А чтобы в койку лезли — за 6 или 7 мест работы был только 1 коллектив, в котором практиковался вопрос «а с кем ты спал в эти выходные». Правда, это выяснилось не на собеседовании, а на испытательном сроке.
был только 1 коллектив, в котором практиковался вопрос «а с кем ты спал в эти выходные».
Простите, но я немножечко
Сейчас я работаю в другой компании, недалеко от меня наш колл-центр, коридор у нас общий, а работает там сплошь молодые люди — в общем, общение у них тоже будь здоров.
вас, как работодателя, не касаютсяПодводники не согласны. </сарказм>
Прошел нормальное количество собеседований, сам некоторое количество провёл сам и хочется добавить свои 5 копеек.
Мне кажется не хватает такого пункта, как наведение контактов. Часто бывает так, что кандидат волнуется, его трясёт, переживает. Представьте какого когда тебе 38 лет, а тебя собеседует пацан 23-х лет, да еще и глушит? Надо сразу настроить кандидата на благоприятную атмосферу (идею за 'smaltalk' лайк), расположить к себе человека, чтобы он психологически настроился. Да, со всеми бывает когда тебе очень нужна эта работа, но психологически тебя давят и ты не можешь уже выдать тот результат, который нужен, а ты понимаешь что ты способен на большее. Даже если человек чего-то не помнит, можно подтолкнуть его к правильному ответу, потому что информация имеет свойство вылетать из головы.
Мой личный опыт, когда я проходил собеседование и переезжал в Москву (конец апреля 2018).
2 недели, не включая выходные, каждый день по 4 собеседования.
Итого 40 компаний. Вакансия: Full-stack developer / Spark developer / Java developer
Прохождение собеседований
Руководитель разработки
- Количество — 16
- Успешных — 9
Старший специалист / специалист
- Количество — 10
- Успешных — 2
PM — проекта
- Количество — 7
- Успешных — 5
HR
- Количество — 7
- Успешных — 2
За успешными я считаю свой субъективный взгляд + наличие офферов. Из общего числа получил 15 офферов (18 успешных). Откинул из успешных компании, которые хотели встретиться лично пообщаться, но у меня не было возможности всё бросить и ради компании ехать в другой город. Свои неудачные собеседования делятся на несколько категорий:
- Задавили морально. Настолько в глубь капать под кандидата, я хз зачем это нужно. Одна мадам меня просто задавила вопросами, особенно бомбит до сих пор с: «Мне неважно, что вы понимайте как работает контракт между hashCode() и equals(), я хочу получить ответ как это написано в JLS». Мне просто трубку бросить хотелось, когда настолько идиотские вопросы спрашивают;
- Каждое первое собеседование нового дня было слито. Хз не выспыпался я, потому что параллельно работал или просто не в настроении был, но этот факт за мной;
- Личная встреча. Конечно, я всё понимаю, что рассчитывать на большую зарплату и доказать через Скайп, что ты реально тот, кто им нужен — непростая задача + многим необходимо посмотреть на человека в живую, чтобы окончательно составить портрет;
- Не сошлись в стеке технологий. Зачастую видят одну технологию и считают, что ты в ней гуру. Мало того, что гуру, так еще и пытаются подсунуть свой стек, который тебе вообще никак не лежит. И есть обратная ситуация, когда я сам понимаю, что имею недостаточно практического опыта в конкретном направлении и нет смысла продолжать беседу.
Наверное это всё что хотел сказать) Главное — быть адекватным и стой, и с другой стороны. В остальном всё обязательно сложится и каждый найдет своё место :)
1) Перед выявлением уровня скилов всегда спрашиваю насколько человека сам себя оценивает в том или ином скиле, что он считает своей более сильной стороной. Очень помогает понять на сколько человек правильно себя видит и определиться с глубиной вопросов по скилу, что задавать. Очень редко встречаются люди, что оценивают себя правильно. Обычно или недооценивают или переоценивают. Особенно молодежь.
2) В процессе проверки скилов обязательно нужно найти то, что человек не знает. Реакция у человека на это должна быть адекватной. Все что-то не знают, и это нормально. Если чел начинает на это злиться или юлить или вообще переходит в ответные вопросы… бывают, в общем варианты.
3) Обязательно надо задать задачку. Или на скилы или, если человек не особо опытен, то на общую логику, типа головоломки. Это по сути модель дальнейшего взаимодействия с человеком. Ему ставится задача, он оценивает свои силы и решает ее… ну, или не решает. Очень часто бывает, что на первом же этапе постановки задачи уже начинаются нюансы. Человек не услышал половину, а уже погнал что-то творить. Или, наоборот, все приходится три раза объяснять. И, вроде, все выяснили, а делает человек опять не то. Или все вопросы начинаются уже ближе к концу решения… Далее говоришь, что на эту задачку всем обычно дают столько-то времени. Хватит/не хватит? Очень полезно поглядеть как человек оценит время на решение. Если сказал, что хватит, а потом все равно не решил, даже с дополнительный временем — повод задуматься. Далее… скажем, решил. Внимательно слушаешь как объясняет решение. Или, если не решил, то как объясняет что пытался делать. Если все четко и понятно, даже если и неправильно — один колинкор, если вообще не понятно как решил, — другой. И сразу видно старался вообще или нет. Проверил решение за собой или нет.
По опыту, задачка — самый главный пункт. Более предпочтителен человек пусть и с меньшими знаниями, но с цепким умом и ясной речью, чем эрудит, который не умеет оперировать своими знаниями. Научить хорошего человека можно всему и это даже не будет тяжело. А вот когда проблемы коммуникации, проблемы самомнения, все это так и будет жрать и ваши силы и силы команды, и вряд ли это можно как-то поправить в обозримом будущем.
Все что-то не знают, и это нормально. Если чел начинает на это злиться или юлить или вообще переходит в ответные вопросы…
Ага, ответные вопросы — это вообще катастрофический исход. Ужасно! Как он посмел что-то вякать, когда «здесь вопросы задаю я» ©? Сразу увести такого с охраной.
Если чел начинает на это злиться или юлить или вообще переходит в ответные вопросы… бывают, в общем вариантыИногда знания и опыт позволяют видеть подводные камни в казалось бы совершенно простых вопросах Ну например частый вопрос: чем POST отличается от GET есть «общепринятое определение» есть «определение W3C» и они разные. И кроме этих двух вариантов ради хохмы могу набросать код который опровергает общепринятое определение. То есть если я уточню, что Вас конкретно интересует, то это я буду по Вашему юлить, злиться, или не нужные вопросы задавать?
Если просто «пришлите резюме, мы посмотрим» — то на их усмотрение (тк я время не тратил, мне пофигу).
Научите меня проводить собеседования