Comments 87
Иногда собеседуют одни люди, а работать нужно будет с другими. Такой подход странный сам по себе. Но и закрывать глаза на такую реалию тоже нельзяПо идее такого быть вообще не должно, т.к. в итоге в неприятной ситуации, когда не хочется работать с человеком по причине психологической несовместимости, может оказаться обе стороны.
У меня была ситуация, что брать готовы, условия хорошие, но я не хочу туда идти, т.к. мне будущий начальник не понравится как человек. Узнал бы я об этом, если бы меня собеседовали третьи лица? Вряд-ли
Это норма в крупных компаниях.
Например, в Фейсбук: ты подходишь интервью в компанию, потом попадаешь на boot camp, где знакомишься с внутренними особенностями и подыскиваешь команду
Насколько я понимаю масштабы фейсбука, там постоянно кто-то приходит и уходит. Поэтому найти команду под себя и наоборот не проблема.
Если человека берут не в принципе куда-нибудь, а на конкретную позицию, то может получиться неприятная ситуация.
Ну а вообще посыл статьи прекрасный, т.к. в некоторых местах вопросы от кандидата воспринимают, если не как оскорбление, но точно как наглость.
Если человека берут не в принципе куда-нибудь, а на конкретную позицию, то может получиться неприятная ситуация.
Ну а вообще посыл статьи прекрасный, т.к. в некоторых местах вопросы от кандидата воспринимают, если не как оскорбление, но точно как наглость.
Разумеется. И таких компаний хватает, так что собеседование не с членом будущей команды — обычное дело.
Но неприятие вопросов со стороны кандидата — это плохо.
В «наших» странах я последний раз собеседовался в Минске в 2011 и как-то не помню, что задавал вопросы.
Но в США это норма. И если кандидат не спрашивает ничего — это звоночек, что может быть он не заинтересован в позиции. Стандарт — 5-10 минут в конце каждой сессии на любые вопросы (хоть про любимую кафешку). Я всегда следил за временем, чтоб не прекращать и не затягивать интервью.
Но у меня, как интервьюируемого, никогда не появлялось желания попросить реализовать алгоритм Дейкстры или банальный пузырёк. Как-то старался другими вопросами понять что и как. Да даже в процессе решения задачи можно вывернуться и что-то спросить (но тут надо просто уже набить руку на решение, чтоб в какой-то момент было время подумать)
Но неприятие вопросов со стороны кандидата — это плохо.
В «наших» странах я последний раз собеседовался в Минске в 2011 и как-то не помню, что задавал вопросы.
Но в США это норма. И если кандидат не спрашивает ничего — это звоночек, что может быть он не заинтересован в позиции. Стандарт — 5-10 минут в конце каждой сессии на любые вопросы (хоть про любимую кафешку). Я всегда следил за временем, чтоб не прекращать и не затягивать интервью.
Но у меня, как интервьюируемого, никогда не появлялось желания попросить реализовать алгоритм Дейкстры или банальный пузырёк. Как-то старался другими вопросами понять что и как. Да даже в процессе решения задачи можно вывернуться и что-то спросить (но тут надо просто уже набить руку на решение, чтоб в какой-то момент было время подумать)
Мне кажется такой вариант имеет права на жизнь, если есть второй этап, где вы сможете пообщаться с командой и начальником на свободную тему.
Это всё напоминает некую разновидность тестового задания на проверку «soft skills». И относиться кандидаты к нему могут соответственно. «Сначала они проверили как я классно умею сортировать пузырьком, а теперь хотят проверить, какие классные вопросы я могу им задать».
В итоге вопросы из «туториала» рискуют стать чисто «механическими». Можно с умным видом спросить «А какое предложение Вы бы внесли в стандарт C++22 для улучшения работы с параллельными вычислениями?» и полностью пропустить ответ мимо ушей. Ведь цель была в задаче вопроса, а не получении ответа.
Ценность вопросов кандидата в том, что они искренние. Интересует его наличие свежих печенек каждый день — хорошо. Интересует наличие и оплата переработок — хорошо. Интересуют процессы формирования ТЗ на разработку в команде — тоже хорошо.
Плюс интересы человека могут зависеть и от текущего контекста. Уволился он из-за снижения реальной зарплаты на прошлом месте, а у него взята ипотека — будет интересоваться премиями и оплатой сверхурочных. Надоело ему работать в условиях хаоса управления — будет интересоваться выстроенными процессами в организации/команде. Причём это может быть один и тот же человек на временном отрезке в пару месяцев.
В итоге вопросы из «туториала» рискуют стать чисто «механическими». Можно с умным видом спросить «А какое предложение Вы бы внесли в стандарт C++22 для улучшения работы с параллельными вычислениями?» и полностью пропустить ответ мимо ушей. Ведь цель была в задаче вопроса, а не получении ответа.
Ценность вопросов кандидата в том, что они искренние. Интересует его наличие свежих печенек каждый день — хорошо. Интересует наличие и оплата переработок — хорошо. Интересуют процессы формирования ТЗ на разработку в команде — тоже хорошо.
Плюс интересы человека могут зависеть и от текущего контекста. Уволился он из-за снижения реальной зарплаты на прошлом месте, а у него взята ипотека — будет интересоваться премиями и оплатой сверхурочных. Надоело ему работать в условиях хаоса управления — будет интересоваться выстроенными процессами в организации/команде. Причём это может быть один и тот же человек на временном отрезке в пару месяцев.
У меня счас всплыл огромный минус: в скором времени вы не найдете интервьюеров.
Например, кандидат собеседуется в 10 компаний и он может подготовить один набор общих вопросов.
У интервьюера же будет человека 4 в неделю с разнообразными вопросами. И так в течение нескольких месяцев, а то и постоянно.
Ещё если собеседование включает не одно, а телефонное + 4 онсайт сессий — подготовка увеличивается
Для большинства компаний это не работает:
1. Как вы сказали — время. Надо просмотреть много кандидатов. После 2х часов человек обычно уже измотан и все равно не сможет адекватно отвечать.
2. Вопросы обычно еле помещаются в часовое интервью (идеал по времени). А значит отвечать времени просто нету.
3. Мы компания которая пишет бинарные деревья. Вот мы и спрашиваем про них. Заодно показываем чем вы будете заниматься. Нам не интересны ваши успехи в искусственном интеллекте(косвенно) и если мы ответим вам, что понятия не имеем как он строится — что это даст нам обоим?
4. По стандартам в интервью уже есть место для «Может у вас к нам какие-то вопросы?». И возможно экспромт скажет больше, чем подготовка вопросов по гугл.
5. Интервью обычно оценивается менеджером. Разработчик там только для создания фона из вопросов. Менеджер всегда мечтает о работнике умнее, чем уже есть. Поэтому в игре «мы все знаем лучше вас» нет смысла по определению. Мы вас набираем решить наши проблемы, а не пипками меряться.
6. Вы в институте пробовали спросить профессора, а он точно знает доказательство теоремы Х? Вы же оба ученые, что же вам не поговорить. Стандартная печаль последних лет — это 23 летний молокозавр, который рассказывает ветеранам, что вчера он прочитал в книжке, что у нас дизайн не по феншую.
7. Да, здорово, когда люди работают душа в душу. Но так не всегда получается. И вас нанимают делать работу, а не обсуждать интервью Дудя на кухне с коллегами. Вот таск, время и веслы. Может у нас зарплата высокая именно потому, что придется общаться с трудными, глупыми людьми.
8. В вакансии надо писать список технологий которые требуется. Тогда не придется дополнительно что-то передавать через HR.
1. Как вы сказали — время. Надо просмотреть много кандидатов. После 2х часов человек обычно уже измотан и все равно не сможет адекватно отвечать.
2. Вопросы обычно еле помещаются в часовое интервью (идеал по времени). А значит отвечать времени просто нету.
3. Мы компания которая пишет бинарные деревья. Вот мы и спрашиваем про них. Заодно показываем чем вы будете заниматься. Нам не интересны ваши успехи в искусственном интеллекте(косвенно) и если мы ответим вам, что понятия не имеем как он строится — что это даст нам обоим?
4. По стандартам в интервью уже есть место для «Может у вас к нам какие-то вопросы?». И возможно экспромт скажет больше, чем подготовка вопросов по гугл.
5. Интервью обычно оценивается менеджером. Разработчик там только для создания фона из вопросов. Менеджер всегда мечтает о работнике умнее, чем уже есть. Поэтому в игре «мы все знаем лучше вас» нет смысла по определению. Мы вас набираем решить наши проблемы, а не пипками меряться.
6. Вы в институте пробовали спросить профессора, а он точно знает доказательство теоремы Х? Вы же оба ученые, что же вам не поговорить. Стандартная печаль последних лет — это 23 летний молокозавр, который рассказывает ветеранам, что вчера он прочитал в книжке, что у нас дизайн не по феншую.
7. Да, здорово, когда люди работают душа в душу. Но так не всегда получается. И вас нанимают делать работу, а не обсуждать интервью Дудя на кухне с коллегами. Вот таск, время и веслы. Может у нас зарплата высокая именно потому, что придется общаться с трудными, глупыми людьми.
8. В вакансии надо писать список технологий которые требуется. Тогда не придется дополнительно что-то передавать через HR.
UFO just landed and posted this here
Ожидаемая реакция. Со стороны это часто может казаться правдой. Однако:
1. Через год молокозавр говорит, что ему надо отредизайнить уже его код. Через 3 приходит новый молокозавр и хаит код предыдущего ничуть не меньше остального легаси.
2. На самом деле есть вселенские законы и механизмы почему так происходит. Вам никогда не приходило в голову, что еще НИКТО не видел легаси с идеальным дизайном. Неужели все эти годы программировали одни ушлепки? Просто это физика, почему любой код через 3 года превращается в тыкву. И тогда ты осознаешь, что «работает — не трогай» вполне правильный принцип. «Трогаешь — следуй стилю модуля» вторая заповедь достойная каменной скрижали.
1. Через год молокозавр говорит, что ему надо отредизайнить уже его код. Через 3 приходит новый молокозавр и хаит код предыдущего ничуть не меньше остального легаси.
2. На самом деле есть вселенские законы и механизмы почему так происходит. Вам никогда не приходило в голову, что еще НИКТО не видел легаси с идеальным дизайном. Неужели все эти годы программировали одни ушлепки? Просто это физика, почему любой код через 3 года превращается в тыкву. И тогда ты осознаешь, что «работает — не трогай» вполне правильный принцип. «Трогаешь — следуй стилю модуля» вторая заповедь достойная каменной скрижали.
А потом они все уйдут и кому-то поддерживать ультрамодный проект на перспективном фреймворке, который уже лет 5 не поддерживается.
И данные в NoSQL загонят, хотя это там совсем не к месту.
Чтоб не было застоя по технологиям и бросания на каждый новый язык — просто надо проводить дизайн ревью проекта с доказательством обоснованности, привлекая архитекторов
+ Whuthering
И данные в NoSQL загонят, хотя это там совсем не к месту.
Чтоб не было застоя по технологиям и бросания на каждый новый язык — просто надо проводить дизайн ревью проекта с доказательством обоснованности, привлекая архитекторов
+ Whuthering
Это нормально. Разработку могут делать 20 человек, а на поддержку оставят 5. Там нет сил дизайн переделывать. Просто надо догнивать потиху. Жизненный цикл программных продуктов.
Иногда бывает, что надо срочно внести правки в умирающий проект. GDPR тому пример
Это бизнес и его риски. Надо править — наняли студента за пол батона или подрядчика за много денег. Исправили — отправили всех отдыхать на рынок дальше. Поэтому у понимающих бизнес прибыльный. А мечтатели, минусующие за ответы, которые им не нравятся, получат инфаркт в 35 лет ибо ночь темна и полна ужасов.
Сейчас рынок кандидатов другой. Падение средней квалификации при росте хотелок. И вопросы у них всегда одинаковые: «Сколько я буду получать? Будете ли вы меня развивать через конференции и командировки? И смогу ли я завтра набрать себе команду из 10 человек?» Там никто не спрашивает про архитектуру, решения и тд.
Поэтому на рынке и появляется все больше фреймворков и языков упрощающих жизнь, чтобы в любой момент можно было снять обезьяну с дерева, запилить заплатку и не отстрелить себе ногу.
Сейчас рынок кандидатов другой. Падение средней квалификации при росте хотелок. И вопросы у них всегда одинаковые: «Сколько я буду получать? Будете ли вы меня развивать через конференции и командировки? И смогу ли я завтра набрать себе команду из 10 человек?» Там никто не спрашивает про архитектуру, решения и тд.
Поэтому на рынке и появляется все больше фреймворков и языков упрощающих жизнь, чтобы в любой момент можно было снять обезьяну с дерева, запилить заплатку и не отстрелить себе ногу.
Фреймворки появляются для того, чтоб не решать типовые задачи для каждого нового проекта.
Если проект делается на полгода (для какой-то рекламной кампании) — не вопрос, можно отдать кому угодно и пусть делают на чём угодно.
А если что-то на долгосрочную перспективу — желательно, чтоб потом было кому поддерживать и развивать при необходимости. А в устоявшемся бизнесе проекты живут по 15-20 лет.
Плохие кандидаты из вне — это проблема везде. Из примерно 50, где я участвовал в интервью, у нас наняли только двух человек. И мы рассматривали их не только в нашу команду. В случае чего мы их рекомендовали бы соседям.
Посему можно развивать текущих людей и уменьшать их нагрузку унификацией. А они в свою очередь будут решать проблемы бизнеса эффективнее, что-то предугадывать заранее и не кидаться на новый язык/фрейморк со словами, что это модно, игнорируя, что производительность потом будет отъедать хорошую часть бюджета
Если проект делается на полгода (для какой-то рекламной кампании) — не вопрос, можно отдать кому угодно и пусть делают на чём угодно.
А если что-то на долгосрочную перспективу — желательно, чтоб потом было кому поддерживать и развивать при необходимости. А в устоявшемся бизнесе проекты живут по 15-20 лет.
Плохие кандидаты из вне — это проблема везде. Из примерно 50, где я участвовал в интервью, у нас наняли только двух человек. И мы рассматривали их не только в нашу команду. В случае чего мы их рекомендовали бы соседям.
Посему можно развивать текущих людей и уменьшать их нагрузку унификацией. А они в свою очередь будут решать проблемы бизнеса эффективнее, что-то предугадывать заранее и не кидаться на новый язык/фрейморк со словами, что это модно, игнорируя, что производительность потом будет отъедать хорошую часть бюджета
Так о чем спор? Я и говорю, что сначала автор потратит 50 дней вместо 50 часов. Если нанимается 7 человек, то 5 окажется так себе. И худшие два из них придут к тебе с предложением переписать фреймворк потому что ты застрял и по другому не умеешь.
Мы Whuthering где-то потеряли.
А фреймворки лучше не плодить, а придерживаться какого-то разумного количества. Чтоб при переключении на неделю на проект не надо было перечитывать все доки =)
А фреймворки лучше не плодить, а придерживаться какого-то разумного количества. Чтоб при переключении на неделю на проект не надо было перечитывать все доки =)
UFO just landed and posted this here
И все же, грустно быть молокозавром, который рассказывает, что «single responsibility principle — это то, к чему, в большинстве случаев, стоит стремиться, по крайней мере, если нет причин этого не делать». Хотя, конечно, такое встречается редко.
Лучшая практика по моему мнению, собеседовать начинающих и студентов по общим тестам, а опытных по их работам. Все остальное для меня выглядит сомнительно, и вызывает подозрение.
Тем не менее сам позыв для валидации собеседующих приветствую, но как то все не так. Возможно надо сделать какую то памятку «10 вопросов компании» для проверки объективности.
Тем не менее сам позыв для валидации собеседующих приветствую, но как то все не так. Возможно надо сделать какую то памятку «10 вопросов компании» для проверки объективности.
Опытных по из работам нельзя — вы никогда не сравните 10 кандидатов с разными проектами так, чтоб потом ещё доказать это в суде (бывает. надеюсь, что со мной не будет =) )
Надо оценивать как они будут решать ваши проблемы.
Надо оценивать как они будут решать ваши проблемы.
В каком суде, о чем вообще?
Надо оценивать как они будут решать ваши проблемы.Вот как раз по уже готовым работам и расспросам о них можно определить — сможет ли кандидат справиться с задачами, на основе их рассказа, тем более что они уже эти задачи выполняли. Иначе, какой смысл тогда в опыте?
Если кандидат считает что он идеально прошёл интервью, а взяли кого-то менее выдающегося — он имеет право оспорить это решение в суде. По крайней мере в США такое случалось не раз. Может в СНГ другая ситуация — сам я не слышал про такие случаи.
А если решил человек сменить сферу и из разработки баз данных переключиться в ИИ? опыт у него есть, он великолепно решал проблемы кэширования и синхронизации нескольких БД, но к ИИ оно мало применимо.
А если решил человек сменить сферу и из разработки баз данных переключиться в ИИ? опыт у него есть, он великолепно решал проблемы кэширования и синхронизации нескольких БД, но к ИИ оно мало применимо.
Связь то какая? Или в базе данных он циклы не писал, деревья не строил, числа не складывал, кнопки не нажимал? Неужели по его прошлому опыту не будет понятно знает ли он язык или нет? А что сейчас по общим тестам можно сказать знает ли человек в ИИ, чтобы без опыта его брать? К тому же, раз он в ИИ захотел, значит были у него свои работы на коленке и по ним можно спросить — всяко лучше чем по тестам теорию с новыми аббревиатурами и старым содержимым спрашивать.
А на счет суда, у нас бы давно всех засудили если бы была такая практика. Поскольку без всяких тестов, отделавшись «правильными выводами» посылают куда по дальше — в основном НИИ и бывшие их сотрудники. Банально даже на программиста ЧПУ в стажировку только студентов со стажем. Не говоря уже про затраты на суд, если избиение с фактами побоев без лишней 10к рублей дальше заявления в милиции ни куда не пойдет — и это московская область.
А на счет суда, у нас бы давно всех засудили если бы была такая практика. Поскольку без всяких тестов, отделавшись «правильными выводами» посылают куда по дальше — в основном НИИ и бывшие их сотрудники. Банально даже на программиста ЧПУ в стажировку только студентов со стажем. Не говоря уже про затраты на суд, если избиение с фактами побоев без лишней 10к рублей дальше заявления в милиции ни куда не пойдет — и это московская область.
Знает ли человек язык понять бы хорошо, но порой очень сложно.
Если синтаксис на доске весь правильный — это плюс. Но сложно подобрать задачу, которая бы охватила все аспекты языка.
Прошлый опыт, имхо, мало о чём говорит. Не факт, что эти решения он лично принимал. Вполне может быть, что приписал имплементацию чего-либо себе — никто же не будет на это место работы звонить и спрашивать единоличный вы автор или вы просто в одной комнате сидели.
Про прошлый проект нужно спросить в начале — чтоб человек успокоился рассказывая что-то знакомое, что он не один день готовил.
А потом надо смотреть как он решает вашу проблему. Очень желательно, если она будет незнакома.
Гугление сообщает, что юридическая база есть — hr-portal.ru/article/kak-smotrit-sud-na-otkaz-v-prieme-na-rabotu
Не сильно уверен в репутации ресурса, но прецедент есть — www.superjob.ru/community/otdel_kadrov/68033
Практики нет, но всегда может найтись какой хитрец — тут и надо непробиваемые факты.
Если синтаксис на доске весь правильный — это плюс. Но сложно подобрать задачу, которая бы охватила все аспекты языка.
Прошлый опыт, имхо, мало о чём говорит. Не факт, что эти решения он лично принимал. Вполне может быть, что приписал имплементацию чего-либо себе — никто же не будет на это место работы звонить и спрашивать единоличный вы автор или вы просто в одной комнате сидели.
Про прошлый проект нужно спросить в начале — чтоб человек успокоился рассказывая что-то знакомое, что он не один день готовил.
А потом надо смотреть как он решает вашу проблему. Очень желательно, если она будет незнакома.
Гугление сообщает, что юридическая база есть — hr-portal.ru/article/kak-smotrit-sud-na-otkaz-v-prieme-na-rabotu
Не сильно уверен в репутации ресурса, но прецедент есть — www.superjob.ru/community/otdel_kadrov/68033
Практики нет, но всегда может найтись какой хитрец — тут и надо непробиваемые факты.
Не факт, что эти решения он лично принимал. Вполне может быть, что приписал имплементацию чего-либо себе — никто же не будет на это место работы звонить и спрашивать единоличный вы автор или вы просто в одной комнате сидели.Если вопрос изначально стоит в доверии то и начинать собеседование не стоит, потому как такое отношение к кандидату не меняется всю дорогу. А обычный тест на 4 часа на дому может показать многое, и пара вопросов при собеседовании, без ошалелого опроса по всем и вся. Очень хорошая практика в этом плане у фирм в игрострое. Но когда приходишь на собеседование, а тебе после 2 часов беседы задают вопрос «неужели вы умеете в углах Эйлера считать», а у тебя 30 проектов с 3D математикой и собственный движок в придачу — хочется такому просто в рожу плюнуть.
Не сильно уверен в репутации ресурса, но прецедент естьТам ни чего кроме угроз. Но я бы не хотел работать в такой фирме, на которую есть повод в суд подать.
Тест на 4 часа дома показывает, что кто-то написал его. Возможно коллектив. И бывает, что нет у человека 4 часов, которые он может потратить вечером или брать выходной. Час на телефонный звонок гораздо легче найти.
Но может в гейм-деве сильно отличается процесс и иначе никак.
Но может в гейм-деве сильно отличается процесс и иначе никак.
И бывает, что нет у человека 4 часов, которые он может потратить вечером или брать выходной.Какие то у вас крайности. Для выполнения теста обычно договариваются о свободном времени, до отправки задания. И контролируется это без всяких хитростей. Тем более если вы ищите работу то и выходного искать нет надобности.
И потом, какая разница когда вы придете на собеседование и там эти 4 часа проведете. Есть фирмы которые весь деть на 8 часов тестов проводят. Какой нибудь Никс. У них там и тесты на личность 150 вопросов, зацикленных на случай если часть из них не совпадет между собой. И тесты с написанием программы на бумажке. И это не гипотетическое задание, а такое положение дел.
Возможно коллектив.Опять тот же вопрос доверия. Нет доверия — нет собеседования, нет работы. Ваши примеры похожи на аналоги проведения тестов на личность в Никс — все одно и тоже в разной интерпретации.
Контролируется без хитростей? Веб-камера и кто-то, кто будет 4 часа за вами наблюдать? Я бы отказался. Я понимаю, что я в ситуации «ищу работу», но кандидат в таком случае или в отчаянии должен быть, или это должен быть ну очень лакомая позиция.
Ну и если у кандидата 5 подобных интервью — это уже 20 часов или пол рабочей недели, или дополнительные часы вечером. А не все продуктивны после 8 часового дня. Да и на работе после такого интервью тоже можешь быть малопродуктивен.
Но это всё про задание до интервью.
Если такое онсайт проводить — вариант, конечно.
НО если мне дадут реальную задачу на 4 часа — у меня сразу же возникнет тысяча вопросов об окружении, сторонних сервисах и т.д. И потребуется кто-то, кто бы отвечал, что по сути приводит к обычному интервью с задачкой.
А если доверять — можно просто спросить «достойны зарабоатывать Н денег?». Тут же надо убедиться, что человек стоит заявленных денег — уволить по статье «несоответствие» тоже требует хороших усилий со стороны HR.
Ну и если у кандидата 5 подобных интервью — это уже 20 часов или пол рабочей недели, или дополнительные часы вечером. А не все продуктивны после 8 часового дня. Да и на работе после такого интервью тоже можешь быть малопродуктивен.
Но это всё про задание до интервью.
Если такое онсайт проводить — вариант, конечно.
НО если мне дадут реальную задачу на 4 часа — у меня сразу же возникнет тысяча вопросов об окружении, сторонних сервисах и т.д. И потребуется кто-то, кто бы отвечал, что по сути приводит к обычному интервью с задачкой.
А если доверять — можно просто спросить «достойны зарабоатывать Н денег?». Тут же надо убедиться, что человек стоит заявленных денег — уволить по статье «несоответствие» тоже требует хороших усилий со стороны HR.
Веб-камера и кто-то, кто будет 4 часа за вами наблюдать?Обычный вопрос по выполненному заданию они для этого и делаются — чтобы определить степень доверия к имеющимся навыкам, из небольшого интервью с компетентным специалистом, а не из ИИ который будет опрашивать по БД.
у меня сразу же возникнет тысяча вопросов об окружении, сторонних сервисах и т.д. И потребуется кто-то, кто бы отвечал, что по сути приводит к обычному интервью с задачкой.У вас возникает проблема написать арканоид на предложенном фреймворке? Для справки, тетрис с арканоидом пишется за час. В этом и суть задачи — разобраться с имеющимся API и написать хоть что то, по сути вход в любую разработку. И не важно кто вы хоть базист хоть арфист. И нет фреймворк вам не известен. И учить и тесты проводить незачем — опытный программист разберется с АПИ или напишет свое, то что и требуется делать практически на любом рабочем месте.
Обычный вопрос по выполненному заданию они для этого и делаются
Вы лабораторные в «бригадах» по несколько человек делали когда-то? Мы просто распределяли кто что делает, но на сдаче каждый из нас мог ответить на доп. вопросы по коду. Так что тут сложно бывает доказать, что это не вы написали и не ориентируетесь.
У вас возникает проблема написать арканоид на предложенном фреймворке?
Да. Последнюю игру я написал году в 2000ом. Я из мира бэкэнда, БД и обработки больших данных. И у нас можно найти, что можно накидать за 1 час. Но исследовать фреймворк — это просто проверить как кандидат умеет читать и искать примеры на офф. сайте.
И у нас можно найти, что можно накидать за 1 час. Но исследовать фреймворк — это просто проверить как кандидат умеет читать и искать примеры на офф. сайте.Нет примеров на официальном сайте самописный фреймворк, который опытному проще самому написать и разобрать чем искать примеры.
Вы лабораторные в «бригадах» по несколько человек делали когда-то?ACM — мировой чемпионат по программирования 10 задач, на 5 часов, на троих с одним рабочим местом. Можно пользоваться калькулятором и справочником по математике.
Так что тут сложно бывает доказать, что это не вы написали и не ориентируетесь.То есть человек не написал сам, но весь код может рассказать, не видя его до этого, и написать заново. А есть смысл его проверять, после такого, на то что сам он это писал или нет?
Кто сказал, что он его не видел?
Он участвовал в написании, но 3 человека более продуктывны и они смогли написать в 2 раза больше чем ожидается обычно от кандидата и производит вау эффект. Но оценен он будет неадекватно.
Кстати, в моей практике один раз на телефонном интервью было ощущение, что кандидат не сам пишет код.
Он участвовал в написании, но 3 человека более продуктывны и они смогли написать в 2 раза больше чем ожидается обычно от кандидата и производит вау эффект. Но оценен он будет неадекватно.
Кстати, в моей практике один раз на телефонном интервью было ощущение, что кандидат не сам пишет код.
То есть вопрос в скорости написания кода. И из за этого вся свистопляска?
В случае «домашнего задания» количество и качество кода — вполне показатель. Или просто запустилось/не запустилось?
А так собралась великолепная четвёрка: 3 человека реализуют разные подходы (если задачу делить долго), 1 пишет тесты. В конце погоняли 5 минут тесты и отправили лучший вариант.
А так собралась великолепная четвёрка: 3 человека реализуют разные подходы (если задачу делить долго), 1 пишет тесты. В конце погоняли 5 минут тесты и отправили лучший вариант.
Опять у вас крайность. Вы там на домашнее задание операционную систему пишете? Проходная задача на дому, это как минимум решенная. Показывающая способность разобраться в чужом коде — адаптацию при работе в коллективе. Нет ни какой необходимости полировать такую задачу до блеска. Достаточно выполнить условия: разобрался в фреймворке и есть решение. Фреймворк как аналог чужого кода, а задача как вариант решения в любых условиях.
Если у вас 20 кандидатов на место — на качество кода вы тоже будете смотреть.
Ну и не крайность. Вот одно из заданий на час, которое мне приходилось решать: реализовать структуру данных для хранения и поиска числовых диапазонов; диапазоны можно добавлять, удалять и искать.
Можно найти 2-3 подхода с разной производительностью для разных операций. Надо прикинуть что важнее, что быстрее, написать, покрыть тестами.
Или добавить функционал в соц. сеть по добавлению, хранению друзей и поиску взаимных друзей.
Это без всяких фреймворков на голом языке, чтоб понимать знает ли кандидат основу.
А разбираться в чужом фреймворке без документации в режиме цейтнот как-то бесчеловечно, имхо.
Ну и не крайность. Вот одно из заданий на час, которое мне приходилось решать: реализовать структуру данных для хранения и поиска числовых диапазонов; диапазоны можно добавлять, удалять и искать.
Можно найти 2-3 подхода с разной производительностью для разных операций. Надо прикинуть что важнее, что быстрее, написать, покрыть тестами.
Или добавить функционал в соц. сеть по добавлению, хранению друзей и поиску взаимных друзей.
Это без всяких фреймворков на голом языке, чтоб понимать знает ли кандидат основу.
А разбираться в чужом фреймворке без документации в режиме цейтнот как-то бесчеловечно, имхо.
на качество кода вы тоже будете смотреть.Качество кода это долгий процесс шлифовки проекта, и в виду существования дедлайна это второстепенный показатель, поскольку первично — решение. Также как и ошалелое стремление к качеству кода может мешать взаимоотношению в коллективе.
Можно найти 2-3 подхода с разной производительностью для разных операций. Надо прикинуть что важнее, что быстрее, написать, покрыть тестами.Дерганье от одного решения к другому, вместо того чтобы спокойно отправить одно из решений — это не крайность? Вы себя уже загнали в рамки крайностей, надумывая лишние требования к задаче.
А разбираться в чужом фреймворке без документации в режиме цейтнот как-то бесчеловечно, имхо.Это жизнь и показатель опытности, а не опыты в пробирке. К тому же как я сказал задача на час, а под нее выделяется 4.
Опять же кто гарантирует выполнение теста тем же человеком, которому он назначался.
А вот это уже вопрос к компетенции собеседователя, сможет ли он задать по работе кандидата правильные вопросы. Да и многие не хотят разбираться в чужом коде — и тут вопрос, а кто тогда будет разбирать ваш. Квалифицированный специалист легко сможет увидеть знакомые алгоритмы или функции и задать вопросы по их аналогам и реализации — такого и уважать уже хочется и работать с ним, а не «надо». Даже без всякого кода, в процессе рассказа, можно свести разговор об определенном проекте, в обсуждение реализации конкретного алгоритма.
никто же не будет на это место работы звонить и спрашивать единоличный вы автор или вы просто в одной комнате сидели.
А вот это уже вопрос к компетенции собеседователя, сможет ли он задать по работе кандидата правильные вопросы. Да и многие не хотят разбираться в чужом коде — и тут вопрос, а кто тогда будет разбирать ваш. Квалифицированный специалист легко сможет увидеть знакомые алгоритмы или функции и задать вопросы по их аналогам и реализации — такого и уважать уже хочется и работать с ним, а не «надо». Даже без всякого кода, в процессе рассказа, можно свести разговор об определенном проекте, в обсуждение реализации конкретного алгоритма.
Какова вероятность, что ваш интервьюер будет разбираться в БД, особенно, если он последние 10 лет работал на ниве ИИ? Общия теория норм, но со спецификой же будет худо.
Подождите, вы предполагаете, что кандидат принесёт свой код с прошлого проекта?
Кстати, у меня был опыт интервью, когда меня попросили реализовать мой предыдущий проект. Я всю дорогу ещё дополнительно думал как бы не реализовать полную копию ибо NDA, а найти что-то подобное.
Подождите, вы предполагаете, что кандидат принесёт свой код с прошлого проекта?
Кстати, у меня был опыт интервью, когда меня попросили реализовать мой предыдущий проект. Я всю дорогу ещё дополнительно думал как бы не реализовать полную копию ибо NDA, а найти что-то подобное.
Какова вероятность, что ваш интервьюер будет разбираться в БД, особенно, если он последние 10 лет работал на ниве ИИ? Общия теория норм, но со спецификой же будет худо.То же самое что и техническими вопросами будет заниматься HR. Почему бы сюда ЕГЭ не добавить? Одного поля ягоды, когда некомпетентные люди ведут беседу с заготовленными вопросами и ответами на них: «шаг влево, шаг в право — попытка к бегству». Этак вы с такими друг на друга похожими примерами, которые кроются одной картой, бесконечно противопоставлять что то будете. А смысл?
HR ничего не должны спрашивать. Даже рекрутеры. Инженер спрашивает довольно актуальную задачу для проекта. Он знает как она решается в этой компании и причины. Когда идут уточняющие вопросы — он описывает ограничения по памяти и пр. условия.
Потом можно взять М кандидатов и посмотреть как они решали проблему, на что обращали внимание.
Если они рассказывают выученный билет — можно просто оценить, что они хорошо усвоили пройденный материал и подготовили вопросы на дополнительные вопросы.
Потом можно взять М кандидатов и посмотреть как они решали проблему, на что обращали внимание.
Если они рассказывают выученный билет — можно просто оценить, что они хорошо усвоили пройденный материал и подготовили вопросы на дополнительные вопросы.
HR ничего не должны спрашивать.В том то и дело не должен, а вы предлагаете.
Он знает как она решается в этой компании и причины.В 150 компаниях одна и та же задача решается по своему, а вы приходите из 151 и уже не прошли тест.
Когда идут уточняющие вопросы — он описывает ограничения по памяти и пр. условия.
Иначе говоря человек на месте проблемы без уточняющих вопросов не сможет решить задачу.
Потом можно взять М кандидатов и посмотреть как они решали проблему, на что обращали внимание.Так же как и отослать тестовое задания М кандидатом, или выбрать одного подходящего по уже решенным на его практике и опыте примерам, о которых можно спросить один, два вопроса и будет понятно подходит или нет. Только не надо приводить опять в пример «уборщицу», которая когда-то была программистом и будет проводить собеседование. Потому что вопрос с HR-ами мы уже выяснили 2 раза.
Если они рассказывают выученный билет — можно просто оценить, что они хорошо усвоили пройденный материал и подготовили вопросы на дополнительные вопросы.Что очень хорошо подходить только для студентов.
В том то и дело не должен, а вы предлагаете.
Ни в коем случае. HR вообще не причастны к найму. Рекрутеры тоже не спрашивают ничего технического. Только инженеры.
Иначе говоря человек на месте проблемы без уточняющих вопросов не сможет решить задачу.
Разумеется. В реальной жизни надо задавать вопросы и уточнять условия. И это показывает как человек мыслит. Повторю, что лучше всего, если задача незнакомая. Обычно считается хорошим тоном сказать интервьюеру если вы знакомы с задачей — он тогда может изменить её (конечно, может и не менять).
Я никогда уборщицу не приводил в пример.
Проверочное задание можно использовать на этапе отбора вместо телефонного интервью, но не на 4 часа — это долго. И после этого на онсайт с задачами на различную тематику.
Что очень хорошо подходить только для студентов.
Не только. Для тех кто не особо продвинулся тоже подходит
Я никогда уборщицу не приводил в пример.Да? Есть разница между вашим:
Какова вероятность, что ваш интервьюер будет разбираться в БД, особенно, если он последние 10 лет работал на ниве ИИ?Потому что вам остается только ее как бывшего инженера выдвинуть.
Не только. Для тех кто не особо продвинулся тоже подходитНу теперь вы будете мои же слова уточнять:
Лучшая практика по моему мнению, собеседовать начинающих и студентов по общим тестам, а опытных по их работам.
Ну общую теорию СУБД он знает и скорее всего работал за свою карьеру не с одной БД. Но он может быть не в курсе особенностей в данной области: как строятся индексы, какие виды кэша существуют.
Не соглашусь: всех надо проверять на то, как они будут решать ваши задачи.
Не соглашусь: всех надо проверять на то, как они будут решать ваши задачи.
Уборщица тоже работала 10 лет назад над программой запуска ракет — и все работало нормально.
Не соглашусь: всех надо проверять на то, как они будут решать ваши задачи.Опытные программисты обычно ставят задачи сами. И ставят они их именно так, чтобы их можно было решить не только самому.
Уборщица перестала работать. А текущий программист работает но надо другой задачей. Он знает общую теорию по работе БД, структуры данных, алгоритмы и прочее. Он знает, что есть проблемы синхронизации БД на разных серверах, но основные методы решения уже не помнит. Как он оценит достойно человека который работал над синхронизацией последние полгода? «Вроде крут», но это очень поверхностная оценка.
Плюс кандидату этим заниматься на новом месте не придётся — так что смысл спрашивать прошлые проекты?
Опытные ставят, но перед ними ставят задачи другие люди. Обычно это бизнес сторона.
Вот примеры вопросов, которые мне задавали:
— построить систему для телефонного голосования для телевизионного шоу
— разработать систему трэкинга доставщиков пиццы для пицеррии.
Имхо, это будет сложно проверить с 4 часовым кодинг-заданием
Плюс кандидату этим заниматься на новом месте не придётся — так что смысл спрашивать прошлые проекты?
Опытные ставят, но перед ними ставят задачи другие люди. Обычно это бизнес сторона.
Вот примеры вопросов, которые мне задавали:
— построить систему для телефонного голосования для телевизионного шоу
— разработать систему трэкинга доставщиков пиццы для пицеррии.
Имхо, это будет сложно проверить с 4 часовым кодинг-заданием
Как он оценит достойно человека который работал над синхронизацией последние полгода? «Вроде крут», но это очень поверхностная оценка.Точно также как и уборщица с HR вместе — это то что мы уже выяснили, а заодно и то что это так по оценке:
«Вроде крут», но это очень поверхностная оценка.Вы переливаете из пустого в порожнее.
Плюс кандидату этим заниматься на новом месте не придётся — так что смысл спрашивать прошлые проекты?Правильно нет смысла брать если его работы ни как не пересекаются с задачами — это гораздо проще решить без тестов, задав простой вопрос по проекту БД.
Имхо, это будет сложно проверить с 4 часовым кодинг-заданиемВы это уже делали? Нет "-" — нет опыта. Сделаете? Неизвестно. Работ подобных в резюме нет, зачем позвали непонятно.
Вы это уже делали? Да, делал опрос для радио — есть опыт, далее вопросы по проделанной работе. Что юзали? А зачем вот эта функция? А почему другую не использовали?..
Вы это уже делали? Нет, но у меня есть проект геопозиционирования по GPS на собственной GooleErth аналоге. Далее сопутствующие вопросы…
Да что ж такое, в Москве кроме уборщиц собеседовать некому? Я вроде несколько раз говорил, что собеседовать должен инженер.
Какая разница работал он в этой сфере или нет? Светлых голов не то чтоб много. Если человек соображающий и здравомыслящий — его надо брать. Может не к себе в команду — в соседнюю.
Если он расскажет как он это делал — он объяснит почему они сделали это в их условиях и ограничениях, но не покажет как они пришли к такому решению. А надо видеть именно процесс поиска решения. Ибо нерешенных задач много и их надо решать каждый день, а не реализовывать одну и ту же задачу на новый манер.
Единственный приемлемый случай — если вам надо реализовать аналогичную систему и вы нанимаете контрактора только на время этого проекта. Сделал — уволили. Тогда аналогичный опыт может быть в плюс. Но есть возможность, что он проигнорирует ваши требования и просто повторит что делал раньше.
Какая разница работал он в этой сфере или нет? Светлых голов не то чтоб много. Если человек соображающий и здравомыслящий — его надо брать. Может не к себе в команду — в соседнюю.
Если он расскажет как он это делал — он объяснит почему они сделали это в их условиях и ограничениях, но не покажет как они пришли к такому решению. А надо видеть именно процесс поиска решения. Ибо нерешенных задач много и их надо решать каждый день, а не реализовывать одну и ту же задачу на новый манер.
Единственный приемлемый случай — если вам надо реализовать аналогичную систему и вы нанимаете контрактора только на время этого проекта. Сделал — уволили. Тогда аналогичный опыт может быть в плюс. Но есть возможность, что он проигнорирует ваши требования и просто повторит что делал раньше.
Да что ж такое, в Москве кроме уборщиц собеседовать некому? Я вроде несколько раз говорил, что собеседовать должен инженер.А что толку что вы это говорите если ваш инженер не лучше уборщицы с HR. Вы так на титулы реагируете как будто это показатель качества. У вас у самого одни сплошные инженеры, не умеющие объективно провести собеседование. Что за планета такая?
Какая разница работал он в этой сфере или нет? Светлых голов не то чтоб много.Ну и как вы это определите, если не знаете области его деятельности? Тест на IQ?
он объяснит почему они сделали это в их условиях и ограничениях, но не покажет как они пришли к такому решению.То есть «по чему они так сделали» не равно «как решили так сделать»? — Были условия, вот так и пришли к такому решению, перебрав сотни других, потому что под ногами валялось, Не?
Мне интересно, для чего такой педантизм?
Ибо нерешенных задач много и их надо решать каждый день, а не реализовывать одну и ту же задачу на новый манер.Замечательно, осталось только один и тот же пример в разных интерпретациях перестать приводить. И путать область деятельности с этапами проекта.
И потом чем вам уборщица, которая ночами дописывает незаметно код так что все задачи решены оказываются, не угодила?
А что толку что вы это говорите если ваш инженер не лучше уборщицы с HR.
Ио есть у вас работают люди которые глубоко разбираются во всех реализвциях JVM на разных платформах, плюс особенностях спецификаций разных C/C++, скажем пяток-другой БД с закрытыми исходниками, ИИ, щелкают NP полные задачи, графы тоже не проблема, криптография, безопасность, AWS, GCP, Azure, Oracle cloud — спроси любую фичу? Ну и список можно продолжать и продолжать.
Если такие люди есть — их нельзя отправлять проводить интервью. Они должны работать и приносить прибыль, ибо стоят они очень много. Вторая причина по которой нельзя им интервьюировать — они врут.
Обычно люди тем 10 могут держать на хорошем уровне знаний — остальное остается на общем.
Ну и как вы это определите, если не знаете области его деятельности? Тест на IQ?
Озвучу проблему и посмотрю как он её решает. Как разложит по полочкам, как обозначит потенциальные проблемы, что уточнит. Если что-то не знает — в реальной жизни всегда можно спросить эксперта п этой теме. Главное, чтоб знал, что тут надо рассмотреть проблему.
спецификаций разных C/C++, скажем пяток-другой БД с закрытыми исходниками, ИИ, щелкают NP полные задачи, графы тоже не проблема, криптография, безопасность, AWS, GCP, Azure, Oracle cloud — спроси любую фичу?Вы уж определитесь либо вы команда БД и набираете специалиста по базам данных, либо команда ИИ и набираете соответствующего специалиста. Ну или широкопрофильная организация. Только вот БД ИИ и графы — это вполне встречаемое сочетание в требованиях к кандидату, так же как и криптография с безопасностью. И вполне может быть одной задачей, а соответственно без имеющегося специалиста на борту развивать ее бессмысленно.
Озвучу проблему и посмотрю как он её решает. Как разложит по полочкам, как обозначит потенциальные проблемы, что уточнит. Если что-то не знает — в реальной жизни всегда можно спросить эксперта п этой теме. Главное, чтоб знал, что тут надо рассмотреть проблему.
Что уже от тестов отказались? Ну, а раз у него в портфолио подобное решение есть наверняка будут вопросы по нему. Или вы исключительно не по профилю резюме рассматриваете?
Я вцелом обсуждаю методологию интервью.
Есть ситуации когда человек приходит из этой же области, есть когда из другой — их надо сравнить и оценить. И то, что он расскажет про прошлый проект — не будет релевантным срезом его знаний и показателем, что он умеет их применять. Т.к. он делал тот проект в команде и многие решения принимал не единолично. По сути это оценка работы его бывшей команды, а не кандидата.
Тесты всегда надо написать. У доски нет смысла присать все кейсы — достаточно упомянуть наиболее частые и граничные условия.
Я стараюсь не смотреть на резюме кандидата, чтоб не стать предвзятым. «Ага, ты из Оксфорда/Фейсбука/Гугл… счас мы тебя проверим и с позором отпустим»
Вроде у меня нет какой-то неприязни ни к каким компаниям, но вдруг что-то подсознательно где-то есть.
А так есть кандидат и команда, где ему работать — определить сможет ли он делать нужную работу, может ли он быть полезен компании в чём-то другом.
Т.е. определить минимум и максимум его возможностей. Вдруг на прошлом проекте ему не давали развернуться и это причина ухода.
Есть ситуации когда человек приходит из этой же области, есть когда из другой — их надо сравнить и оценить. И то, что он расскажет про прошлый проект — не будет релевантным срезом его знаний и показателем, что он умеет их применять. Т.к. он делал тот проект в команде и многие решения принимал не единолично. По сути это оценка работы его бывшей команды, а не кандидата.
Тесты всегда надо написать. У доски нет смысла присать все кейсы — достаточно упомянуть наиболее частые и граничные условия.
Я стараюсь не смотреть на резюме кандидата, чтоб не стать предвзятым. «Ага, ты из Оксфорда/Фейсбука/Гугл… счас мы тебя проверим и с позором отпустим»
Вроде у меня нет какой-то неприязни ни к каким компаниям, но вдруг что-то подсознательно где-то есть.
А так есть кандидат и команда, где ему работать — определить сможет ли он делать нужную работу, может ли он быть полезен компании в чём-то другом.
Т.е. определить минимум и максимум его возможностей. Вдруг на прошлом проекте ему не давали развернуться и это причина ухода.
Замечательно, люди придумывали стажировку и испытательный срок для подготовки и проверки кандидата на проф пригодность и пользу компании, а теперь еще тесты. А вы в курсе, что по этим вашим тестам вас в ваш же суд за предвзятость то и отправят? Вот так не хотели, а попали. Я вот все время с такими встречаюсь «не хочу читать ваше резюме», а потом по реакции что ты ответил на их глупый вопрос лучше чем ожидалось делаешь выводы что держали тебя за идиота — я уже приводил выше пример такого собеседования.
Тесты — это unit tests
Может в РФ стажировка ещё работает, в США нет — я слышал, что только механиков самолётов нанимают с испытательным сроком.
Возможно особенности рынка. Если есть стажировка — хорошо. Но не всем подходит. И при прочих равных кандидат предпочтёт предложение без стажировки.
ну и есть плохие интервьюеры — ничего не поделаешь, надо идти готовым к тому, что начнут спрашивать глупости. Просто потом туда не идти и никому не советовать
Может в РФ стажировка ещё работает, в США нет — я слышал, что только механиков самолётов нанимают с испытательным сроком.
Возможно особенности рынка. Если есть стажировка — хорошо. Но не всем подходит. И при прочих равных кандидат предпочтёт предложение без стажировки.
ну и есть плохие интервьюеры — ничего не поделаешь, надо идти готовым к тому, что начнут спрашивать глупости. Просто потом туда не идти и никому не советовать
unit tests — и как применимо к тестированию живых людей Ж)))))
а не реализовывать одну и ту же задачу на новый манер.
Подозреваю что понятие Парадигмы для вас совершенно не знакомо.
Отнюдь, я не ограничивал никогда ни языком, ни парадигмой. Если кандидат считает, что функциональный подход будет лучше всего — пусть дерзает.
Ну так а парадигма и описывает одно решение для всех задач. Это по вашему не одно решение для любой задачи. И как же ваш специалист так пишет одну и ту же задачу на новый лад обладая знаниями о парадигмах программирования. Так же как паттерны это вам не одна и та же задача на новый лад?
Не говоря уже про организацию и планированию разработок на шаблонные задачи которые уже решались. Я так подозреваю у вас каждая новый проект, это какая то карусель из оригинальных задач требующих не тривиальные подходы.
нет. Есть типовые приложения, есть инфреструктурные задачи — этим занимаются разные команды и у них разный набор скиллов
И они решают не одни и те же задачи по своему профилю на новый лад? Это какие же?
Давайте-ка в один трэд.
Как я помню, вы утверждаете, что надо спрашивать на интервью про предыдущий проект и этого достаточно для оценки кандидата и найма его на работу.
Я говорию, что это сложно осуществимо из-за того, что надо найти эксперта по технологиям на этом проекте для проведения интервью, а кандидатов будет 100 и количество экспертов может быть большим. Проекты у кандидатов могут различаться сложностью, и степенью вовлечённости кандидата. Плюс после этого экспертам будет сложно сравнить кандидатов между собой и выбрать N лучших. Плюс экспертам надо будет готовиться по каждому кандидату, что увеличивает время на интервью, а им бы ещё работать.
Поэтому ограниченный список задач, спрашивать онсайт, обсуждать, смотреть как кандидат на месте решает проблему. Оценивать по использованию паттернов, умению оценить сложность и ресурсоёмкость вкупе с производительностью, смотреть какие граничные условия и потенциальные проблемы кандидат затронет, чтоб оценить опыт. Можно уйти в глубину какой-то определённой темы и поискать пределы.
Потом можно легко ранжировать и находить лучших.
Ситуацию с глубокими вопросами о прошлом проекте я допускаю в узком случае, когда это очень близкая область и кандидат не подписывал NDA.
Вроде ничего не упустил?
Как я помню, вы утверждаете, что надо спрашивать на интервью про предыдущий проект и этого достаточно для оценки кандидата и найма его на работу.
Я говорию, что это сложно осуществимо из-за того, что надо найти эксперта по технологиям на этом проекте для проведения интервью, а кандидатов будет 100 и количество экспертов может быть большим. Проекты у кандидатов могут различаться сложностью, и степенью вовлечённости кандидата. Плюс после этого экспертам будет сложно сравнить кандидатов между собой и выбрать N лучших. Плюс экспертам надо будет готовиться по каждому кандидату, что увеличивает время на интервью, а им бы ещё работать.
Поэтому ограниченный список задач, спрашивать онсайт, обсуждать, смотреть как кандидат на месте решает проблему. Оценивать по использованию паттернов, умению оценить сложность и ресурсоёмкость вкупе с производительностью, смотреть какие граничные условия и потенциальные проблемы кандидат затронет, чтоб оценить опыт. Можно уйти в глубину какой-то определённой темы и поискать пределы.
Потом можно легко ранжировать и находить лучших.
Ситуацию с глубокими вопросами о прошлом проекте я допускаю в узком случае, когда это очень близкая область и кандидат не подписывал NDA.
Вроде ничего не упустил?
К сожалению ваше количество в 100 кандидатов далеки от истины. Компании у которых большой приток специалистов, обычно вовлечены в их обучение и на этом этапе надобность в тестировании отпадает благодаря профильной организации. Специалисты с опытом идут совсем другой дорогой и не просто так.
А вот реальные цифры это 3 человека в неделю. И причина тут как раз таки в нехватки специалистов с обоих сторон.
Так вот мало того что в России есть испытательный срок, а большие компании за рубежом спонсируют проведение международных конкурсов, плюс все ученые умы работают над тем чтобы свести все решения задач к решению одной и той же задачи на новый лад, вы их еще юнит тестами пытаете. (как программное обеспечение)
А вот реальные цифры это 3 человека в неделю. И причина тут как раз таки в нехватки специалистов с обоих сторон.
Так вот мало того что в России есть испытательный срок, а большие компании за рубежом спонсируют проведение международных конкурсов, плюс все ученые умы работают над тем чтобы свести все решения задач к решению одной и той же задачи на новый лад, вы их еще юнит тестами пытаете. (как программное обеспечение)
В нашей не гигантской компании я проводил по 3 интервью в неделю на протяжении нескольких месяцев.
2 телефонных и 1 онсайт. Это были интервью только в наш отдел. Я не говорю про интервью в гиганты как Амазон, Фейсбук, Гугл.
И из где-то 50 человек мы взяли только 2.
Так что это вполне реальные цифры.
Более того, Амазон устраивает иногда hiring events. Это когда они приезжают в какой-то город или страну и проводят кучу интервью в течении недели. Потом устраивается обсуждение и кандидатов приглашают на работу.
Любые специалисты проходят интервью. По крайней мере до сеньора (по американским меркам). Архитекторов и выше не приходилось интервьюировать.
Если человек не протестировал написаный код — это минус балл
2 телефонных и 1 онсайт. Это были интервью только в наш отдел. Я не говорю про интервью в гиганты как Амазон, Фейсбук, Гугл.
И из где-то 50 человек мы взяли только 2.
Так что это вполне реальные цифры.
Более того, Амазон устраивает иногда hiring events. Это когда они приезжают в какой-то город или страну и проводят кучу интервью в течении недели. Потом устраивается обсуждение и кандидатов приглашают на работу.
Любые специалисты проходят интервью. По крайней мере до сеньора (по американским меркам). Архитекторов и выше не приходилось интервьюировать.
Если человек не протестировал написаный код — это минус балл
В нашей не гигантской компании я проводил по 3 интервью в неделю на протяжении нескольких месяцев.
2 телефонных и 1 онсайт. Это были интервью только в наш отдел. Я не говорю про интервью в гиганты как Амазон, Фейсбук, Гугл.
И из где-то 50 человек мы взяли только 2.
Так что это вполне реальные цифры.
Вот видите как оно оказывается все на самом деле, и провести собеседование без всяких тестов — вполне подъемная задача для одного специалиста со 100 кандидатами.
Потом устраивается обсуждение и кандидатов приглашают на работу.
И что? Человеков не тестируют?
Если человек не протестировал написаный код — это минус баллТо есть мы уже перешли от тестирования людей к тестированию ПО?
Компании у которых большой приток специалистов, обычно вовлечены в их обучение и на этом этапе надобность в тестировании отпадает благодаря профильной организацииЭто, как минимум, не всегда так. У Google большой приток специалистов, но от собеседований они не отказываются.
От собеседований или от тестов на них? Насколько я помню там не просто тесты, а задачи на сообразительность, которые мало относятся к их собственным задачам на рабочем месте.
Смотря что понимать под «тестом». Я так понял, ваш оппонент считает алгоритмическую задачу, решенную у доски или в Google Docs, тестом — в этом смысле Google не отказывается ни от того, ни от другого.
Смотря что понимать под «тестом».Ну уж точно не само собеседование. И такого рода специфичные тесты я тоже не приветствую. Поскольку для молодежи (студентов) они весьма интересны и показательны. А вот для людей с возрастом (опытных), чья сообразительность зависит от погоды на улице, я не советовал бы. В этом собственно и заключается моя точка зрения.
такое случалось не раз
А можно примеров? А то бывает рассказывают ужасы, а на поверку оказывается что все глубже, сложнее и вообще не так все было
Со мной такое не случалось. Кто-то из бывших американских коллег рассказывал.
К сожалению, знакомые юристы работают в других сферах и ничего не подсказали.
Вот что смог нагуглить.
https://www.nolo.com/legal-encyclopedia/lawsuits-based-the-hiring-process.html
del
Всеми руками — за. Всегда и всем говорю, что на собеседовании ситуация симметричная. И всегда все кандидаты удивляются, когда спрашиваю, нет ли у них задач для нас.
А чем это отличается от текущего положения дел? Каждая первая компания в конце собеседования предлагает задать вопросы по компании, проекту и позиции. Если кто-то не задает этих вопросов и потом от этого страдает, то возникает вопрос «а кто же им мешает?»
Ответы по компании, проекту и позиции — это всегда «динамично развивающаяся компания», проект с «передовыми технологиями» и «зарплатой выше рынка». Можно только поверить на слово. А вот кандидатам почему-то на слово не верят.
По моему опыту, как раз нет. Все компании, с кем я общался, весьма доброжелательно относились к вопросам о компании на собеседовании, в том числе отвечали на вопросы типа «нарисуйте релевантную для меня часть структуры менеджмента — всю цепочку подчинения до СЕО включительно и соседние ветки на каждом уровне», и готовы были отвечать на вопросы довольно долго (десятки минут, иногда больше часа, если все происходит на HR интервью). Всегда я мог выяснить все, что хотел.
По статье возникает ощущение, что автор предлагает задавать собеседуюшим алгоритмические задачи, но в этом же нет смысла — они прошли примерно тот же фильтр, что и дается тебе, и по вопросам этого фильтра виден средний уровень сотрудников компании. Как раз интервьюер может оказаться выбросом в ту или иную сторону, так что по нему оценивать всех менее надежно. А что касается остальных вопросов — их и сейчас предлагают задавать. Никакого механизма для большего доверия к ответам в статье не предложено.
По статье возникает ощущение, что автор предлагает задавать собеседуюшим алгоритмические задачи, но в этом же нет смысла — они прошли примерно тот же фильтр, что и дается тебе, и по вопросам этого фильтра виден средний уровень сотрудников компании. Как раз интервьюер может оказаться выбросом в ту или иную сторону, так что по нему оценивать всех менее надежно. А что касается остальных вопросов — их и сейчас предлагают задавать. Никакого механизма для большего доверия к ответам в статье не предложено.
По статье возникает ощущение, что автор предлагает задавать собеседуюшим алгоритмические задачиТочно — и я это предлагаю, хотя и не обязательно алгоритмические. Почему Вы считаете, что собеседники «прошли примерно тот же фильтр, что и дается тебе»? Это как раз совершенно не обязательно. Кто, как и когда попал на эту работу — неизвестно. Поэтому я (и автор вроде тоже) предлагаю относится к собеседованию, именно как к беседе между равноправными лицами. И выбросы тут могут быть симметричные — может, предыдущие кандидаты опубликовали задачи в интернете, а Вы их и прочитали.
Я, конечно, утрировал ответы компании, но проверить-то Вы их не можете. Да и умолчать о чем-то неспрошенном можно. «Столовая есть? — А как же!», вот только есть невозможно :)
Почему Вы считаете, что собеседники «прошли примерно тот же фильтр, что и дается тебе»?Потому, что это логичное предположение, к тому же, полностью соответствующее моему личному опыту. Использовать контекстную информацию в рамках взаимной проверки — нормально, если у вас в резюме Google, то вас тоже будут меньше проверять при собеседовании.
предлагаю относится к собеседованию, именно как к беседе между равноправными лицамиПолностью согласен. Поэтому каждой стороне сделки стоит проверить, что другая ей подойдет. Что и достигается вопросами, которые обе стороны задают друг другу на собеседовании — уже сейчас, и не видно, чем предложение автора статьи отличается. Только ли тем, что он предлагает не доверять правилу «все будущие коллеги прошли плюс-минус такое же собеседование» и задавать алгоритмические вопросы, рискуя получить зашумленный результат, ведь проверяется лишь один сотрудник компании? Если да, то, пожалуй, лично мне такого счастья не надо.
А всю компанию и не надо — Вы же идете в конкретную команду, напротив сидят один-два возможных коллеги, вот их и можно проверить. Про «алгоритмические» вопросы я не понял. Например по C# — что такое иммутабельные объекты? А какой самый популярный иммутабельный объект в .NET? А какие еще знаете? А чем хороши иммутабельные объекты? А чем плохи? А для многопоточности? А в вашем проекте есть многопоточность? А на чем она построена? А async/await? А как оно работает? А… и т.д. и т.п. Если это все алгоритмические вопросы — я с Вами согласен. А если среди собеседующих есть тимлид или SM — можно точно также проверить их способности планирования или управления, попутно, кстати, узнавая «релевантную для меня часть структуры менеджмента» и прочие вопросы по компании, проекту и позиции. Ну а уж насколько это кому нужно — вопрос, конечно, сугубо личный.
Sign up to leave a comment.
Собеседование для собеседующих