Комментарии 36
Как-то уж больно кратко получилось.
Поставьте человеку задачу, которую пришлось недавно решать человеку на похожей должности или которую реально придётся решать нашему кандидату.с этим могут возникнуть некоторые проблемы, не будете же вы давать на собеседовании задание, на которое человек на аналогичной должности потратил, скажем, месяц. Иногда нелегко подобрать такое задание, которое было бы одновременно и достаточно сложным, и в то же время быстро решаемым при наличии достаточных знаний.
«Вы заходите в метро, а там толпа народа. Какие Ваши предположения?» РБК.
После этого вопроса сразу перестал корректно отвечать на дальнейшие вопросы
После этого вопроса сразу перестал корректно отвечать на дальнейшие вопросы
«Землю крестьянам». И «да, в РБК я не работаю» ;)
Какой вопрос, такой и ответ:
«Установить у входа в метро заградительные отряды с пулеметами, открывающие огонь по всему, что находится в радиусе видимости. После этого количество людей в метро станет значительно ниже»
«Установить у входа в метро заградительные отряды с пулеметами, открывающие огонь по всему, что находится в радиусе видимости. После этого количество людей в метро станет значительно ниже»
в вопросе не было ничего про уменьшение количества людей. С чего вы взяли, что это проблема?)
Ну очевидно предположение должно быть «потому что там нет заградительных отрядов с пулемётами» )
Вы сказали, там «толпа народу», а это уже проблема с точки зрения тех кто в метро перемещается.
Возможно, да. Но я бы тогда сформулировал вопрос как «какие меры вы можете предложить для снижения плотности потока в часы пик» или как-то иначе. До тех пор, пока человек не понимает, чего спрашивает, его нужно просить уточнить формулировку. Это можно сделать вежливо, пояснив двусмысленность вопроса или осветив возможные варианты ответа. А можно попросить уточнения формулировки более грубым способом — точным ответом, которого человек гарантированно не ожидает.
Я использую оба способа в разных ситуациях. Но чаще всего, после первого, очевидно неверного ответа, перехожу к первому варианту поведения. Хотя если человека раздражает, то стараюсь избегать шуточек ;)
Я использую оба способа в разных ситуациях. Но чаще всего, после первого, очевидно неверного ответа, перехожу к первому варианту поведения. Хотя если человека раздражает, то стараюсь избегать шуточек ;)
Часто задают неясные/нелепые вопросы, чтоб проверить как человек на них реагирует. Это бывает важно, если инженеру приходится много общаться с не техническими/далекими от темы людьми. Вам задали квинтэссенцию подобных вопросов. В целом, любое собеседование двустороннее. И если вы не понимаете зачем у вас спрашивают такие вопросы или же понимаете, но вам не нравится на них отвечать, то лучше сразу отказаться от позиции.
Я -> Тим. Лид. -> Тех.Дир. < — > Директор по маркетингу -> Далекий человек менеджер.
Так вот, цыпочка должна прерываться на Дир.Марк.
Я не в тех. поддержку устраиваюсь, а если у компании цыпочка сразу на программистов то она обречена на провал.
Так вот, цыпочка должна прерываться на Дир.Марк.
Я не в тех. поддержку устраиваюсь, а если у компании цыпочка сразу на программистов то она обречена на провал.
«1. Практика важнее теории»
Очень спорное утверждение. Как-то при разговоре, с моим зав кафедрой, он мне сказал: лучше всего брать на работу (да и просто общаться) людей, которые и в теории и в практике сильны. Просто если чистый теоретик, толку при практическом задании будет мало, а если практик, то с таким поговорить не о чем. Я собственно с ним полностью согласен.
Очень спорное утверждение. Как-то при разговоре, с моим зав кафедрой, он мне сказал: лучше всего брать на работу (да и просто общаться) людей, которые и в теории и в практике сильны. Просто если чистый теоретик, толку при практическом задании будет мало, а если практик, то с таким поговорить не о чем. Я собственно с ним полностью согласен.
Вам, простите, человек нужен чтобы работу делать, или разговаривать?
А если серьёзно, то хотите узнать, насколько человек знает теорию – дайте ему задачу, где ему придётся эту теорию использовать.
А если серьёзно, то хотите узнать, насколько человек знает теорию – дайте ему задачу, где ему придётся эту теорию использовать.
Вы так поставили вопрос, словно я сказал теория, теория и еще раз теория.
Отвечая на вопрос: я бы брал людей которые и работу делают и способны обсудить какую-то проблему.
Отвечая на вопрос: я бы брал людей которые и работу делают и способны обсудить какую-то проблему.
Вы зря не указали, кого собеседуют.
Знание теории и умение применять типовые решения — разные вещи. Зачастую, вопросы по теории — важны. А разница в версиях продуктов как раз очень даже практика.
Например:
Теория: — В чём преимущество множества нитей над множеством процессов в работе одной программы? В чём недостатки? Как можно организовать работу программы со множеством клиентов в одной ните исполнения?
Практика: — Чем апач префорк отличается от апач worker? А чем они отличаются от nginx?
Знающий ответ на первые вопросы, легко ответи на остальные.
Вообще, текст откровенно слабый. Очень напоминает злость непрошедшего собеседование. Из всего текста я вынес себе мысль «надо посмотреть moneyball».
Скажите, вы точно не заваливали собеседований в последнее время?
Знание теории и умение применять типовые решения — разные вещи. Зачастую, вопросы по теории — важны. А разница в версиях продуктов как раз очень даже практика.
Например:
Теория: — В чём преимущество множества нитей над множеством процессов в работе одной программы? В чём недостатки? Как можно организовать работу программы со множеством клиентов в одной ните исполнения?
Практика: — Чем апач префорк отличается от апач worker? А чем они отличаются от nginx?
Знающий ответ на первые вопросы, легко ответи на остальные.
Вообще, текст откровенно слабый. Очень напоминает злость непрошедшего собеседование. Из всего текста я вынес себе мысль «надо посмотреть moneyball».
Скажите, вы точно не заваливали собеседований в последнее время?
Точно, психоанализ не удался. Статья навеяна опытом собеседований с «обоих» сторон
Ну не удался, так не удался. Бывает.
В любом случае, по практике собеседований с двух сторон, я бы сказал, что ваш четвёртый пункт — самый важный. Он должен быть первым.
На мой вкус, большая часть проблем предприятий в том, что руководство врёт само себе. В частности — в вопросах найма сотрудников. Посмотрите на большую часть вакансий на каком-нибудь hh: в своей профессиональной области я вряд ли претендую на 10% из них. При хорошем опыте работы в 7 лет. Но по факту, я пройду собеседование почти на любую из них. Почему? Потому что требуют не то, что реально нужно. И в личной беседе это становится очевидно.
Как решить эту проблему? Чётче формулировать требования к сотрудникам. Если вам нужно поддерживать 100500 костылей в старом коде, это одно. Если писать что-то с нуля — это другое.
Если вы понимаете, что в формулировках запросов у вас одно, а нанимаете вы другое, то попросите у кого-нибудь помощи.
Тоже самое касается вопросов (ваш третий пункт): если вы спрашиваете одно, а в реальности человек будет заниматься другим — бросайте задавать вопросы, попросите помощи в их формулировке у других.
Второй пункт даже спорить не буду: если вам нужно решить задачу А, вы ищете под это специалиста. Если он справляется с этой работой — хорошо. Если работа измениться, вы сможете сменить специалиста, если этот «не потянет». Хватит врать себе и верить, что есть бесконечно талантливые люди, способные на всё.
В любом случае, по практике собеседований с двух сторон, я бы сказал, что ваш четвёртый пункт — самый важный. Он должен быть первым.
На мой вкус, большая часть проблем предприятий в том, что руководство врёт само себе. В частности — в вопросах найма сотрудников. Посмотрите на большую часть вакансий на каком-нибудь hh: в своей профессиональной области я вряд ли претендую на 10% из них. При хорошем опыте работы в 7 лет. Но по факту, я пройду собеседование почти на любую из них. Почему? Потому что требуют не то, что реально нужно. И в личной беседе это становится очевидно.
Как решить эту проблему? Чётче формулировать требования к сотрудникам. Если вам нужно поддерживать 100500 костылей в старом коде, это одно. Если писать что-то с нуля — это другое.
Если вы понимаете, что в формулировках запросов у вас одно, а нанимаете вы другое, то попросите у кого-нибудь помощи.
Тоже самое касается вопросов (ваш третий пункт): если вы спрашиваете одно, а в реальности человек будет заниматься другим — бросайте задавать вопросы, попросите помощи в их формулировке у других.
Второй пункт даже спорить не буду: если вам нужно решить задачу А, вы ищете под это специалиста. Если он справляется с этой работой — хорошо. Если работа измениться, вы сможете сменить специалиста, если этот «не потянет». Хватит врать себе и верить, что есть бесконечно талантливые люди, способные на всё.
Честно говоря, мне тяжело было разделять на пункты — все утверждения тесно друг с другом связаны. А в целом — я с Вами согласен.
> четвёртый пункт — самый важный.
Анекдот по теме
Вакансия: водитель.
Требования:
Профессиональные навыки управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими / средними танками, находящимися на вооружении стран СНГ и НАТО.
Навыки раллийского и экстремального вождения — обязательны, опыт управления болидами F1 — приветствуется.
Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем (GPS) и автомобильных аудиосистем ведущих производителей — обязательны.
Опыт проведения кузовных и окрасочных работ приветствуется.
Претенденты должны иметь сертификаты Mercedes, BMV, Ceneral Motors, а также справки об участии в крупных международных ралли не более чем двухлетней давности.
Зарплата 1500-2500 руб., определяется по результатам собеседования.
Требования:
Профессиональные навыки управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими / средними танками, находящимися на вооружении стран СНГ и НАТО.
Навыки раллийского и экстремального вождения — обязательны, опыт управления болидами F1 — приветствуется.
Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем (GPS) и автомобильных аудиосистем ведущих производителей — обязательны.
Опыт проведения кузовных и окрасочных работ приветствуется.
Претенденты должны иметь сертификаты Mercedes, BMV, Ceneral Motors, а также справки об участии в крупных международных ралли не более чем двухлетней давности.
Зарплата 1500-2500 руб., определяется по результатам собеседования.
Согласен на все 100%. Обычно по большей части предложений создается впечатление, что в них засовываются названия всех технологий, которые только есть. И очень становится инетресно, кто же в конце концов соответствует всем этим требованиям.
Кстати, указанные вами вопросы — это всё теория, с моей точки зрения. Практика звучала бы как «Необходимо создать веб-приложение, способное обрабатывать большое количество запросов в единицу времени. Ваши идеи?» — такой вопрос даёт простор фантазии. И самое интересное — Вы можете даже узнать что-то новое для себя.
Ваш вопрос — тоже теория. Только в несколько другой области («создание веб-приложения» может подразумевать разработку всей архитектуры решения). Подобные задачи, обычно, решаются «в общем виде»: «запросы приходят сюдя в таком-то виде, туда в таком-то виде, а в кэшах вот тут, тут и тут у нас хранится то, то и то». И только после проработки этого общего решения начинается практика в виде «запросы принимает mysql, кэши построим на апаче».
В данном случае, можно сослаться на теорию массового обслуживания, как фундаментальную. Но и сама архитектура штука во многом теоретическая.
В данном случае, можно сослаться на теорию массового обслуживания, как фундаментальную. Но и сама архитектура штука во многом теоретическая.
но зато можно задавать человеку вопросы, на которые нет ответов в теории. Например — зачем отделять бекенд от фронтенда — это породит лишний трафик в подсети и задержки. У нас небольшой проект, мы можем без этого обойтись? такие вопросы и помогут выяснить мышление человека. А в вопросе «в чём разница между потоком и процессом» — места для фантазии и мышления нет.
Я не понимаю, почему я должен отказываться от вопросов по теории. Почему я не могу спросить, чем буфер отличается от кэша или протокол от интерфейса? Я понимаю, что не все это знают. Но если человек утверждает, что знает сети, например, то я бы предпочёл работать с человеком понимающим эту разницу. Да, в таких вопросах нет места полёту фантазии. Но фантазии не бывает на пустом месте. Обычно, я хочу работать с людьми, чей полёт фантазии опирается на крепкие крылья теории.
С другой стороны, да, вы правы, задавать вопросы только по теории — неправильно. На разные вакансии вопросы должны быть разные. Где-то нужно спрашивать о типовых решениях в архитектуре. Где-то об утилитах консоли. А где-то достаточно, чтобы человек был сообразителен или усидчив.
Вернусь к первой фразе вашего поста: кого мы собеседуем? В общем случае ваши советы… могут оказаться не совсем актуальными ;) Хотя в частностях — вполне приемлимы.
С другой стороны, да, вы правы, задавать вопросы только по теории — неправильно. На разные вакансии вопросы должны быть разные. Где-то нужно спрашивать о типовых решениях в архитектуре. Где-то об утилитах консоли. А где-то достаточно, чтобы человек был сообразителен или усидчив.
Вернусь к первой фразе вашего поста: кого мы собеседуем? В общем случае ваши советы… могут оказаться не совсем актуальными ;) Хотя в частностях — вполне приемлимы.
Не могу сходу придумать вакансию, на которую знания теории были бы важнее умения выполянть свои обязанности. Но возможно такие есть.
Я не прошу вас отказыватся от теории вообще, я лишь написал, что теория не столь важна, как практика. Так например, в чём разница между .net и java я могу за пару минут найти в гугле. А вот чтоб действительно понять, с какими трудностями прийдёться столкнуться при разработке на этих технологиях — нужен практический опыт.
Я не прошу вас отказыватся от теории вообще, я лишь написал, что теория не столь важна, как практика. Так например, в чём разница между .net и java я могу за пару минут найти в гугле. А вот чтоб действительно понять, с какими трудностями прийдёться столкнуться при разработке на этих технологиях — нужен практический опыт.
Еще раздражает, когда до начала технического собеседования мне дают анкету на 3 листа, где надо указать все данные о себе включая паспортные данные родителей.
>>> В ближайшей перспективе важен опыт и знания. В длительной – мышление
А вы готовы соответствовать росту этого человека в длительной перспективе, его изменяющимся потребностям и прочему.
Очень многие заранее знают что нет, не признаются, но знают. И ищут они тех кто умеет сейчас, а не потом.
А вы готовы соответствовать росту этого человека в длительной перспективе, его изменяющимся потребностям и прочему.
Очень многие заранее знают что нет, не признаются, но знают. И ищут они тех кто умеет сейчас, а не потом.
Краткость — сестра таланта. При приеме в федеральную организацию ГИСовцем мне задали вопросы: образование, наличие диплома, чем занимался на учебе, практике, военный билет, почему покинул предыдущее место работы, затем дважды давали задания (два этапа). Собеседование проводил замдиректора. Был принят, спустя 2,5 года — из родного филиала с должности инженера дважды звали работать начальником отдела в Москву, общаюсь в вышестоящим руководством, в том числе из вышестоящей организации, занимаюсь техподдержкой организации по России, программированием, проектированием ИС и ГИС-технологиями. Если бы тогда задавали вопросы по теории — не на все бы смог ответить и всё было бы по другому.
На практическую часть при приеме дали новую для меня программу, файлы для выполнения задания и мануал. Освоил за пару часов не заглядывая в мануал и выполнил задания.
Вывод: практика и обучаемость всегда важнее всего для полноценной работы, чем знание теории, нужную часть которой запоминаешь при применении на практике.
На практическую часть при приеме дали новую для меня программу, файлы для выполнения задания и мануал. Освоил за пару часов не заглядывая в мануал и выполнил задания.
Вывод: практика и обучаемость всегда важнее всего для полноценной работы, чем знание теории, нужную часть которой запоминаешь при применении на практике.
Я как раз достаточно регулярно провожу собеседования.
Вопросы как теоретические, так и сугубо практические, но, как показывает практика, большинство кандидатов отсеиваются уже на элементарной теории.
Кстати, приятно, когда кандидат показывает opensource проекты на собеседовании (или перед ним присылает), это очень большой плюс — можно сразу оценить его уровень и подготовить специфичные вопросы на собеседовании. Так же приятно, когда приносят даже закрытые проекты на своём ноуте — можно побеседовать «по живому коду», который пишет человек.
Вопросы как теоретические, так и сугубо практические, но, как показывает практика, большинство кандидатов отсеиваются уже на элементарной теории.
Кстати, приятно, когда кандидат показывает opensource проекты на собеседовании (или перед ним присылает), это очень большой плюс — можно сразу оценить его уровень и подготовить специфичные вопросы на собеседовании. Так же приятно, когда приносят даже закрытые проекты на своём ноуте — можно побеседовать «по живому коду», который пишет человек.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько советов по проведению собеседований