Comments 240
Я бы не назвал этот формат собеседования идеальным, так как иногда требуется наверняка знать о некоторых скилах кандидата, о которых он сам может умолчать.
Ну вот например нужно проверить знание регекспов кандидатом.
Можно заявить ему, что ты в этом эксперт и жаждешь продемонстрировать свои знания. Если он начнёт уходить от темы — значит там проблемы. Если он таки попросит написать пример регекспа, то надо написать заведомо неверный регексп и проверить, сумеет ли кандидат найти ошибку. И т.п.
Но в целом согласен, тут уже требуется креатив и сноровка при таком ходе событий )
Можно заявить ему, что ты в этом эксперт и жаждешь продемонстрировать свои знания. Если он начнёт уходить от темы — значит там проблемы. Если он таки попросит написать пример регекспа, то надо написать заведомо неверный регексп и проверить, сумеет ли кандидат найти ошибку. И т.п.
Но в целом согласен, тут уже требуется креатив и сноровка при таком ходе событий )
креатив и сноровка
И вновь возвращаясь к теме о заимствованиях в русском языке…
Несколько напоминает «респект и уважуха», хотя тошнотворный эффект несколько слабее.
Хорошо, пусть будут «творческая жилка» и «находчивость».
мокроступы и ногомяч
Reductio ad absurdum. Я не впечатлён. © Шелдон Купер
Серьёзно, мы здесь говорим о словах, имеющих нормальные, общепринятые эквиваленты в русском языке. Ваши примеры никак нельзя назвать устоявшимися.
Серьёзно, мы здесь говорим о словах, имеющих нормальные, общепринятые эквиваленты в русском языке. Ваши примеры никак нельзя назвать устоявшимися.
И ещё: с другой стороны таким образом кандидат обозначит именно свои сильные стороны (на тему которых он и будет задавать вопросы), а слабы будет избегать — что сразу будет видно. А при «обычном» собеседовании такие его сильные стороны могли бы остаться нераскрытыми.
Идея заманчивая, но есть один недостаток — кандидат может отлично разбираться в теме, но совершенно не уметь задавать по ней вопросы. Одно дело решить поставленную проблему, и совсем другое — поставить её самому, это на уровень выше. Отсюда вывод — так можно собеседовать потенциального тимлида, попросив его задавать вопросы «виртуальному» джуниору.
Ну почему же. «Неумение задавать вопросы» вполне себе характеризует разработчика. К тому же, можно ему помогать: заявлять «а ещё я вот это знаю» и смотреть, как он среагирует, заценит-ли ))
Тогда нужно самому хорошо знать предмет, чтобы эффективно задавать такие вопросы.
А если плохо знать предмет, то и собеседовать не стоит, не так ли?
что ж теперь искать специального человека который будет собеседовать? :)
Отвлекать техлида или хотя бы «синьора», иначе никак.
Джоэл вон вообще всей командой предлагает слушать собеседования, и у каждого сотрудника есть право вето.
Джоэл вон вообще всей командой предлагает слушать собеседования, и у каждого сотрудника есть право вето.
вот вам пример: мне сейчас нужен опытный Qt-разработчик. Я сам Qt первый раз увидел пару месяцев назад, и в компании нет никого кто знал бы его профессионально.
Но проект запущен, человек нужен. Что делать? :)
Но проект запущен, человек нужен. Что делать? :)
Для начала помолиться и объяснить заказчику что возможен фейл. :)
1. Нанять признанного Qt-гуру (дорого).
2. «Арендовать» признанного Qt-гуру для проведения собеседования (муторно).
3. Придумать «боевое» тестовое задание (сомнительно).
Да, ситуация тяжёлая ))
Предлагаю такой вариант: попросите пришедших кандидатов обучить вас Qt. Ну то есть сразу признайтесь, что знаете его плохо, но вас интересует такой-то тип задач. Пусть кандидат объяснит вам, как стоит это делать, какую документацию и какой инструментарий при этом использовать — пусть побудет техлидом для вас )
2. «Арендовать» признанного Qt-гуру для проведения собеседования (муторно).
3. Придумать «боевое» тестовое задание (сомнительно).
Да, ситуация тяжёлая ))
Предлагаю такой вариант: попросите пришедших кандидатов обучить вас Qt. Ну то есть сразу признайтесь, что знаете его плохо, но вас интересует такой-то тип задач. Пусть кандидат объяснит вам, как стоит это делать, какую документацию и какой инструментарий при этом использовать — пусть побудет техлидом для вас )
цимес в том, что 90% из приходящих знают Qt еще хуже меня. Возможно, дело в вилке (50-75).
Наверное всего два человека из десятков соискателей выполнили задание с использованием именно уникальных Qt-шных фишек (не сигналов и слотов конечно, про них к счастью все знают).
Но эти два человека по разным причинам отказались работать.
Наверное всего два человека из десятков соискателей выполнили задание с использованием именно уникальных Qt-шных фишек (не сигналов и слотов конечно, про них к счастью все знают).
Но эти два человека по разным причинам отказались работать.
Хороший вариант :) А 3) действительно сомнительно — с гуглом или даже просто с доками любой вменяемый разработчик, по-моему, задание выполнит, но вот сколько времени это займёт и насколько качественный код выйдет никак не проверить, если не подключать 2)
Большой минус если кандидат хитрожопый
Спросит что то типа «а расскажите мне об особенностях полиморфизма в РНР», а сам при этом не в теме, только поддакивает
и да, выше уже поднята мысль про неумение задавать вопросы, а так же нестандартное собеседование может просто напугать и замкнуть человека в себе, если вы ищете не продавца а программиста, то для него это не является минусом
Спросит что то типа «а расскажите мне об особенностях полиморфизма в РНР», а сам при этом не в теме, только поддакивает
и да, выше уже поднята мысль про неумение задавать вопросы, а так же нестандартное собеседование может просто напугать и замкнуть человека в себе, если вы ищете не продавца а программиста, то для него это не является минусом
> а сам при этом не в теме, только поддакивает
Не прокатит. Нужно выдать ему фигню. Если поддакивает — значит не шарит вообще в этом.
> если вы ищете не продавца а программиста, то для него это не является минусом
Ещё как является. Все хорошие программисты умеют излагать мысли и задавать вопросы, иначе это просто кодер-ремесленник, что собственно тоже требуется выяснить. Ну и «молчунам» можно просто начать рассказывать о себе и смотреть на его реакцию.
Не прокатит. Нужно выдать ему фигню. Если поддакивает — значит не шарит вообще в этом.
> если вы ищете не продавца а программиста, то для него это не является минусом
Ещё как является. Все хорошие программисты умеют излагать мысли и задавать вопросы, иначе это просто кодер-ремесленник, что собственно тоже требуется выяснить. Ну и «молчунам» можно просто начать рассказывать о себе и смотреть на его реакцию.
Я знаю, минимум, двоих Программеров (именно с большой буквы), которые не всегда могут изложить ход своих мыслей, не то что поставить задачи. А вот им задачи ставить не нужно — надо просто объяснить, что должно быть в результате и они сами решают без проблем. Так что зря вы так, всех под одну гребенку…
Попробуйте их спросить, смогли бы они позадавать вопросы другому программеру с целью выяснить его уровень? Да, я думаю, что любой Программер с большой буквы (тем более) сможет, причём с большим удовольствием, заодно поведает про свои достижения и возьмёт «на слабо» ))
Вообще, я говорил про «Все хорошие программисты умеют излагать мысли и задавать вопросы, иначе это просто кодер-ремесленник» — именно это неверно. Про то, что 2 программера смогут пообщаться и померятся п… ми — согласен. Вот только задать вопрос «почему ооп лучше/хуже функций» — это одно, а выяснять действительный уровень другого человека — совсем другое.
Хах… весьма сомнительный тип собеседования… имхо… Пример моей прошлой работы — штат народу небольшой, нужен прогамер для организации и доработки биллинга. Из админов народ шарит в этом в пределах администрирования. Собсно как тут подберешь нужного человека?
Думаю этот вариант реален только если ищешь себе замену…
Думаю этот вариант реален только если ищешь себе замену…
Куда хуже, когда вас собеседует сотрудница HR (а не прямой специалист), следуя вопросам по списку:
— вы знакомы с пи-айч-пи?
— владеете пхотошоп?
— сможете настроить май-эс-ку-ель?
— играете в рабочее время в контрл-страйк?
И ей действительно не важно, что вы сделали, как уникально решили какую-то проблему на предыдущем месте работы и вообще откуда у вас эти знания.
(из личного примера 6 лет назад)
— вы знакомы с пи-айч-пи?
— владеете пхотошоп?
— сможете настроить май-эс-ку-ель?
— играете в рабочее время в контрл-страйк?
И ей действительно не важно, что вы сделали, как уникально решили какую-то проблему на предыдущем месте работы и вообще откуда у вас эти знания.
(из личного примера 6 лет назад)
Как-то проходил собеседование в одной конторе (вроде как крупной и серьезной, но не суть важно).
Собеседовала меня как раз сотрудница HR, которая выдала мне просто лист с тестом, содержащим вопросы на профессиональную тематику. Было указано, что на каждый вопрос есть только один правильный ответ. К одному из вопросов обнаружилось два правильных овтета (при тех условиях, которые были првиедены в вопросе). Сообщил об этом и реально ввел в ступор человека.
После заполнения этого теста, мне дали еще два теста, вроде как на должности поменьше. Сказали, что вопросы могут пересекаться. Каково же было мое удивление, когда эти два теста оказались просто разбитым на две части первым тестом (даже последовательность вопросов та же).
Все-таки, действительно, собеседование должны проводить люди, с которыми придется наиболее плотно взаимодействовать в случае успешного трудоустройства, ну и хорошо, когда HR имеет представление о должности, на которую собеседует человека.
Ну и да, работать я туда не пошел, о чем ничуть не жалею (правда, по несколько иной причине).
Собеседовала меня как раз сотрудница HR, которая выдала мне просто лист с тестом, содержащим вопросы на профессиональную тематику. Было указано, что на каждый вопрос есть только один правильный ответ. К одному из вопросов обнаружилось два правильных овтета (при тех условиях, которые были првиедены в вопросе). Сообщил об этом и реально ввел в ступор человека.
После заполнения этого теста, мне дали еще два теста, вроде как на должности поменьше. Сказали, что вопросы могут пересекаться. Каково же было мое удивление, когда эти два теста оказались просто разбитым на две части первым тестом (даже последовательность вопросов та же).
Все-таки, действительно, собеседование должны проводить люди, с которыми придется наиболее плотно взаимодействовать в случае успешного трудоустройства, ну и хорошо, когда HR имеет представление о должности, на которую собеседует человека.
Ну и да, работать я туда не пошел, о чем ничуть не жалею (правда, по несколько иной причине).
Такая интригующая история и в конце «но я к ним не пошел, от метро далеко» :)
Кстати, от метро и правда неблизко было, но этот факт меня волновал в последнюю очередь.
Принял решение о том, что не пойду к ним в любом случае, после такого диалога с HR:
-Чего вы больше всего ждете от нового места работы?
-В первую очреедь, выплачиваемой вовремя зарплаты (ответил честно, да и вообще основной причиной ухода с прошлой работы были именно постоянные задержки зарплаты)
-Так кто ж вам такое пообещает?
Как-то демотивировало сие меня.
Принял решение о том, что не пойду к ним в любом случае, после такого диалога с HR:
-Чего вы больше всего ждете от нового места работы?
-В первую очреедь, выплачиваемой вовремя зарплаты (ответил честно, да и вообще основной причиной ухода с прошлой работы были именно постоянные задержки зарплаты)
-Так кто ж вам такое пообещает?
Как-то демотивировало сие меня.
Возможно это была просто «первая линия», особенно если народу на вакансию много отозвалось.
Сомнительно, т.к. моё резюме они нашли и позвонили мне первыми сами.
Тогда зачем на этой линии живой HR?
Достаточно формального соответствия критериям, ну или на крайняк мини-онлайн-теста.
Достаточно формального соответствия критериям, ну или на крайняк мини-онлайн-теста.
Ну, онлайн тест кроме неочевидности реализации не даёт идентифицировать личность респондента. А так сидит реальный человек и ставит галочки. Тот же ЕГЭ почему-то не разрешают сдавать из дома в онлайне ;) Или я от жизни отстал?
Ну да, ниже я согласился, что лучше тест либо кусок реального кода.
Меня на время выполнения теста оставили в абсолютно пустой комнате. Безо всяких там камер и всего прочего. Хоть доставай телефон и гугли, если вдруг чего не знаешь. Так что польза такого подхода в конкретно моем случае была сомнительно. Тем не менее, отвечал я честно, не подглядывая.
Я честно говоря не вижу особо такой проблемы, потому что жульничать просто бессмысленно. Если ты чего-то не знаешь, то это моментально вскроется на первой же боевой задаче. Тогда и вылетишь с треском.
тогда и сдавать онлайн можно с тем же успехом, тоже в случае фейла все сразу вскроется.
Мы же изначально говорили все-таки чуть-чуть о другом.
Мы же изначально говорили все-таки чуть-чуть о другом.
Некоторые тестовые задания — это проверка выхваченных с потолка фактов. Идея про «кусок кода, которым гордишься» — нравится куда как больше. И в целом про дело или проект. И уровень показывает, и реальная боевая задача.
По крайней мере это покажет, что именно этот человек может гуглом пользоваться, а не брат/сват. Но вообще, конечно, в целом подход странноватый.
HR чаще оценивают не техническую сторону ответов на вопросы, а как человек на них отвечает и вообще как ведет себя, их задача: отсеить тех кто не впишется в коллектив или просто неадекватных людей.
Если вы смеетесь над глупым вопросом от нее, то тоже самое может произойти и при диалоге с заказчиком, они тоже не всегда технически-грамотные. А зачем такой сотрудник, если есть возможность найти другого?
Если вы смеетесь над глупым вопросом от нее, то тоже самое может произойти и при диалоге с заказчиком, они тоже не всегда технически-грамотные. А зачем такой сотрудник, если есть возможность найти другого?
О, как знакомо. Особенно если этот HR шарит в теме на уровне пре-эникея. Помнится, требовался админ в один холдинг. Девочка начала задавать вопросы, прошлись по виндоусам, линуксам, почтам и много чему еще (с обильным количеством терминологии с её стороны), а потом она шарашит меня вопросом:
— А чем отличается хаб от роутера?
Меня на этом немного сконфузило, а она продожает
— Ну, что, вы не знаете? Хаб отправляет интернет всем, а роутер тольок тем, кому разрешено.
Я, честно сказать, не удержался и рассмеялся. Рассказал ей чем отличается концентратор от коммутатора, а комутатор от маршрутизатора и откланялся (уже было более интересное предложение).
Бывают интересные случаи, да.
— А чем отличается хаб от роутера?
Меня на этом немного сконфузило, а она продожает
— Ну, что, вы не знаете? Хаб отправляет интернет всем, а роутер тольок тем, кому разрешено.
Я, честно сказать, не удержался и рассмеялся. Рассказал ей чем отличается концентратор от коммутатора, а комутатор от маршрутизатора и откланялся (уже было более интересное предложение).
Бывают интересные случаи, да.
Есть методы собеседования простые, надёжные и проверенные веками. Компетентный человек любого другого человека на раз-два отсобеседует и поймёт что он из себя представляет на первый взгляд. А дальше есть уже тестовые задания или по обстоятельствам. Зачем придумывать какие-то там хитровы... элегантные™ схемы? Когда натыкаешься на какого-нибудь такого фантазёра, мысль одна — встать и уйти.
> Когда натыкаешься на какого-нибудь такого фантазёра, мысль одна — встать и уйти.
А вы ждёте стандартный список вопросов?
Я даже от верстальщика ожидаю умения добиваться ответов при постановке задач и готовности к нестандартным ситуациям (и чтоб в IE работало!).
Суть в том, что не нужно вообще никакого списка вопросов. Просто слушаешь человека, и тебе всё понятно сразу.
А вы ждёте стандартный список вопросов?
Я даже от верстальщика ожидаю умения добиваться ответов при постановке задач и готовности к нестандартным ситуациям (и чтоб в IE работало!).
Суть в том, что не нужно вообще никакого списка вопросов. Просто слушаешь человека, и тебе всё понятно сразу.
Дело не в списке вопросов, дело в подходе.
Я всегда стараюсь проецировать предлагаемые варианты на себя. Если подобный вариант собеседования предложат не в мегакрутой фирме, и у меня не будет необходимости срочно-срочно найти работу, то я могу действительно встать и уйти.
Тогда возникает вопрос: так ли идеально собеседование, формат которого не нравится кандидатам? В итоге вы возьмёте не самого лучшего программиста, а лучшего из тех, кто согласился играть с вами в HR-игры.
PS: Тест из тысячи вопросов даст примерно такой же результат.
Я всегда стараюсь проецировать предлагаемые варианты на себя. Если подобный вариант собеседования предложат не в мегакрутой фирме, и у меня не будет необходимости срочно-срочно найти работу, то я могу действительно встать и уйти.
Тогда возникает вопрос: так ли идеально собеседование, формат которого не нравится кандидатам? В итоге вы возьмёте не самого лучшего программиста, а лучшего из тех, кто согласился играть с вами в HR-игры.
PS: Тест из тысячи вопросов даст примерно такой же результат.
«действительно встать и уйти» очень эффектно выглядит и производит должный эффект.
Бывало несколько таких на практике. О таких потом долго говорят.
Бывало несколько таких на практике. О таких потом долго говорят.
> Если подобный вариант собеседования предложат не в мегакрутой фирме, и у меня не будет необходимости срочно-срочно найти работу, то я могу действительно встать и уйти.
1. Либо вас нашли и «уговаривают» поработать в компании, тогда разговор вообще по-другому строится.
2. Либо вы ищите работу и приложили некие целенаправленные усилия, чтобы попасть на собеседование и считает фирму достаточно «крутой», чтобы тратить на неё своё время.
Речь в посте идёт только о втором варианте.
1. Либо вас нашли и «уговаривают» поработать в компании, тогда разговор вообще по-другому строится.
2. Либо вы ищите работу и приложили некие целенаправленные усилия, чтобы попасть на собеседование и считает фирму достаточно «крутой», чтобы тратить на неё своё время.
Речь в посте идёт только о втором варианте.
Я, если честно, не вижу существенной разницы между вариантами при таких формулировках.
Одно дело — когда переманивают с уже имеющейся работы, и предлагают определённые условия. Другое — когда кандидат ищет работу, а фирма — сотрудника.
В последнем случае не принципиально, кто на кого вышёл первым. И если компания предлагает приехать к ним на собеседование, а человек ищет работу, и его устраивают описанные в вакансии условия, то он почти наверняка поедет.
И вот человек приехал на собеседование, потратил время, а тут ему предлагают какую-нибудь HR'овскую фигню (я не про описанный вариант, а вообще). Для человека встаёт вопрос, насколько ему жалко уже потраченных усилий, чтобы не принимать в ней участие. И чем большую фигню предлагают, тем больше весы склоняются в пользу неучастия.
Я, например, отношусь к уже упоминавшимся в комментариях интровертам (и в некоторой степени социофобам), мне и при обычном собеседовании не особо комфортно. Так что необоснованный дискомфорт для меня вполне может перевесить мнимую крутость фирмы, ибо никто не может обещать, что он закончится собеседованием, и не распространится на ежедневную работу.
Одно дело — когда переманивают с уже имеющейся работы, и предлагают определённые условия. Другое — когда кандидат ищет работу, а фирма — сотрудника.
В последнем случае не принципиально, кто на кого вышёл первым. И если компания предлагает приехать к ним на собеседование, а человек ищет работу, и его устраивают описанные в вакансии условия, то он почти наверняка поедет.
И вот человек приехал на собеседование, потратил время, а тут ему предлагают какую-нибудь HR'овскую фигню (я не про описанный вариант, а вообще). Для человека встаёт вопрос, насколько ему жалко уже потраченных усилий, чтобы не принимать в ней участие. И чем большую фигню предлагают, тем больше весы склоняются в пользу неучастия.
Я, например, отношусь к уже упоминавшимся в комментариях интровертам (и в некоторой степени социофобам), мне и при обычном собеседовании не особо комфортно. Так что необоснованный дискомфорт для меня вполне может перевесить мнимую крутость фирмы, ибо никто не может обещать, что он закончится собеседованием, и не распространится на ежедневную работу.
Существенная разница в том, что обычно вы сначала должны пройти предварительный отбор — выполнить тест или показать «боевой» код. А чтобы потратить на это время, нужно уже хотеть работать в этой компании.
Что касается темы интровертов.
Вот откликнулись вы на мою вакансию, прислав резюме и кусок кода. Меня всё устроило и я пригласил вас. Вы пришли, мы перекинулись парой общих слов, я налил вам чаю и спрашиваю: «А вам приходилось проводить собеседования?..» «А какими вопросами вы бы выяснили, насколько я хороший программист? Можете мне их задать?»
Вы бы потерялись? Встали и ушли?
Нормальный ход событий, ничего страшного, я не кусаюсь, спокойно жду и не напираю, это просто диалог.
Что касается темы интровертов.
Вот откликнулись вы на мою вакансию, прислав резюме и кусок кода. Меня всё устроило и я пригласил вас. Вы пришли, мы перекинулись парой общих слов, я налил вам чаю и спрашиваю: «А вам приходилось проводить собеседования?..» «А какими вопросами вы бы выяснили, насколько я хороший программист? Можете мне их задать?»
Вы бы потерялись? Встали и ушли?
Нормальный ход событий, ничего страшного, я не кусаюсь, спокойно жду и не напираю, это просто диалог.
Ну, видимо мы пришли к консенсусу, что не столь важно, как именно будет проходить собеседование, лишь бы обе стороны относились друг к другу уважительно и с пониманием.
Просто сравните то, что предлагаете вы, и фразу из топика:
Просто сравните то, что предлагаете вы, и фразу из топика:
Пришёл кандидат, вы говорите ему: «Расспроси меня о моих знаниях? А принял ли бы ты меня на работу? Стал ли бы ты работать со мной в команде?»Чувствуете, какое сразу давление на кандидата?
Мне удалось под вас подстроиться? )
> лишь бы обе стороны относились друг к другу уважительно и с пониманием.
Необходимо, но не достаточно )
> фразу из топика
В топике сформулировано экспрессивно в качестве демонстрации, о чём вообще идёт речь.
Естественно, не нужно быть роботом и тупо следовать инструкциям и методикам. Перед тобой человек со своими особенностями, и нужно так или иначе под подстраивать свои методы под него и находить обоюдо комфортные способы коммуникации.
> лишь бы обе стороны относились друг к другу уважительно и с пониманием.
Необходимо, но не достаточно )
> фразу из топика
В топике сформулировано экспрессивно в качестве демонстрации, о чём вообще идёт речь.
Естественно, не нужно быть роботом и тупо следовать инструкциям и методикам. Перед тобой человек со своими особенностями, и нужно так или иначе под подстраивать свои методы под него и находить обоюдо комфортные способы коммуникации.
Ну вопросы типа «как оценивать труд дворника? а врача? а таксиста?» по-моему мало отношения имеют к обязанностям рядового кодера.
А вы не могли бы дать ссылки на такие методы? Или ключевые слова (для гугла)? Очень требуется…
Множество многогранных подходов к приему программистов на работу наталкивают на мысли о том, что на самом деле этих людей потом вербуют в супер секретную организацию для свержения мировых диктаторов.
Вообще говоря, некоторые подобные идеи проскальзывали у Joel'а:
«Introduction
Question about recent project candidate worked on
Impossible Question
C Function
Are you satisfied?
Design Question
The Challenge
Do you have any questions?»
Я думаю, что хорошо, если кандидата попросят задавать вопросы. Но это не должно быть в начале (люди практически всегда напряжены перед собеседованием, поэтому такие сюрпризы можно делать, когда человек уже «вошёл в ритм») и собеседование не должно исчерпываться этим.
«Introduction
Question about recent project candidate worked on
Impossible Question
C Function
Are you satisfied?
Design Question
The Challenge
Do you have any questions?»
Я думаю, что хорошо, если кандидата попросят задавать вопросы. Но это не должно быть в начале (люди практически всегда напряжены перед собеседованием, поэтому такие сюрпризы можно делать, когда человек уже «вошёл в ритм») и собеседование не должно исчерпываться этим.
Такая штука называется зеркальное интервьюирование. На поток такое ставить нет смысла, тесты выполнят задачу лучше.
Как человеку, готовящемуся к экзаменам, хочется что бы на экзаменах преподы именно так делали.
Можно взять не того человека, что нужно, если человек «критикан» в хорошем смысле слова. То есть в предмете разбирается хотя бы поверхностно, но грубо неправильный ответ от правильного отличит или найдёт недостатки в предлагаемом методе решения, но вот сам ответить на вопрос или предложить более-менее приемлемое решение не в состоянии.
P.S. А вообще не понимаю почему разработчиков не просят сначала показать код или выполнить тестовое, но более-менее реальное, задание, а уж потом приглашать на собеседование — по-моему кучу времени работодатель может себе сэкономить. Хотя с позиции работодателя выступал редко, может и ошибаюсь.
P.S. А вообще не понимаю почему разработчиков не просят сначала показать код или выполнить тестовое, но более-менее реальное, задание, а уж потом приглашать на собеседование — по-моему кучу времени работодатель может себе сэкономить. Хотя с позиции работодателя выступал редко, может и ошибаюсь.
> Можно взять не того человека, что нужно, если
Ну я же не предлагаю ограничиться только этим. Просто после такого перекрёстного собеседования уже будет о чём говорить дальше (или быстро станет ясно, что говорить не о чем))
> показать код или выполнить тестовое, но более-менее реальное, задание
Абсолютно согласен. Всегда так делаю и считаю, что по-другому нельзя.
Можно тогда такой алгоритм предложить:
1. Публикуется простое тестовое задание и описание вакансии.
2. Кандидаты присылают свой код по заданию ЛИБО «код, которым они гордятся» (всегда так и пишу)). Тимлид оценивает качество кода («студентов» сразу видно по именованию переменных, комментариям, циклам и прочим тонким моментам). Отсеиваются лишние, оставшиеся приглашаются на очное собеседование.
3. На собеседовании кандидат интервьюирует тимлида. Вполне можно даже заранее предупредить о таком формате, чтобы не было смущения и можно было подготовиться. Неадекваты просто не придут, по ходу станет понятен уровень кандидата и темы для более детального обсуждения.
4. В режиме обычного диалога-разговора проясняются оставшиеся моменты, принимается решение.
Ну я же не предлагаю ограничиться только этим. Просто после такого перекрёстного собеседования уже будет о чём говорить дальше (или быстро станет ясно, что говорить не о чем))
> показать код или выполнить тестовое, но более-менее реальное, задание
Абсолютно согласен. Всегда так делаю и считаю, что по-другому нельзя.
Можно тогда такой алгоритм предложить:
1. Публикуется простое тестовое задание и описание вакансии.
2. Кандидаты присылают свой код по заданию ЛИБО «код, которым они гордятся» (всегда так и пишу)). Тимлид оценивает качество кода («студентов» сразу видно по именованию переменных, комментариям, циклам и прочим тонким моментам). Отсеиваются лишние, оставшиеся приглашаются на очное собеседование.
3. На собеседовании кандидат интервьюирует тимлида. Вполне можно даже заранее предупредить о таком формате, чтобы не было смущения и можно было подготовиться. Неадекваты просто не придут, по ходу станет понятен уровень кандидата и темы для более детального обсуждения.
4. В режиме обычного диалога-разговора проясняются оставшиеся моменты, принимается решение.
Из топика как-то неясно, то не только этим.
Возможно идеальный алгоритм, по крайней мере со стороны потенциального работника. Побольше бы таких работодателей. Ловите плюсик в карму :)
Возможно идеальный алгоритм, по крайней мере со стороны потенциального работника. Побольше бы таких работодателей. Ловите плюсик в карму :)
Очень часто используемый алгоритм компаниями по разработке ПО.
Встречал как минимум 2 организации которые сначала дают небольшой проект на 1 неделю. И по его результатам оценивают кандидата.
Недели обычно не достаточно чтобы полностью выполнить задание, и за счет этого оценивается как кандидат распределяет время, как пишет. Кандидат может отправить промежуточные результаты спросить совета в каком-нибудь «узкопрофильном» месте.
Студенты больше любят процедурное программирование, чем ООП, на чем иногда с треском проваливаются.
Встречал как минимум 2 организации которые сначала дают небольшой проект на 1 неделю. И по его результатам оценивают кандидата.
Недели обычно не достаточно чтобы полностью выполнить задание, и за счет этого оценивается как кандидат распределяет время, как пишет. Кандидат может отправить промежуточные результаты спросить совета в каком-нибудь «узкопрофильном» месте.
Студенты больше любят процедурное программирование, чем ООП, на чем иногда с треском проваливаются.
«Студенты больше любят процедурное» потому что преподаватели сначала требуют процедурное, а студенты привыкают и не хотят потом на классах писать
ничего себе «небольшой проект» который и за неделю не успеешь. Это предполагается, что соискатель уже уволился и кроме одной вашей вакансии ничем не занят.
Мы даем задание, которое можно сделать за 2-6 часов, но предлагаем соискателю самому назвать срок выполнения. Обычно, делают неделю
Мы даем задание, которое можно сделать за 2-6 часов, но предлагаем соискателю самому назвать срок выполнения. Обычно, делают неделю
Интересно, кто будет тратить целую неделю, чтобы сделать непонятное задание с непонятным результатом? Такие находятся?
Встречал такое — задание оплачивается по расценкам вполовину меньше заявленных и вполне реальное. Может, конечно, это такой способ находить временную дешевую рабочую силу, но фидбэк прислали грамотный, трудно было не согласится что мой код косячный.
Я сам никогда не брался за слишком объёмные задания и сам стараюсь ставить задачи, которые искомый кандидат выполнит за пару часов.
>>> («студентов» сразу видно по именованию переменных,
>>> комментариям, циклам и прочим тонким моментам
В идеальном мире, это было бы не так…
Если не лукавить (что на собеседовании в реальном мире не принято) и показать код которым я горжусь на самом деле, то это была бы одна незаковыристая процедурка которую я написал на 3-й месяц изучения РНР, и написана она в стиле быдлокода. Я не горжусь всеми её аспектами, но там есть одна мелочь от которой меня распирает гордость (особенно когда я вспоминаю как «много» я тогда знал о РНР и как удачно у меня получилось «раскинуть мозгами»)
>>> комментариям, циклам и прочим тонким моментам
В идеальном мире, это было бы не так…
Если не лукавить (что на собеседовании в реальном мире не принято) и показать код которым я горжусь на самом деле, то это была бы одна незаковыристая процедурка которую я написал на 3-й месяц изучения РНР, и написана она в стиле быдлокода. Я не горжусь всеми её аспектами, но там есть одна мелочь от которой меня распирает гордость (особенно когда я вспоминаю как «много» я тогда знал о РНР и как удачно у меня получилось «раскинуть мозгами»)
Да ну, за мою практику я написал несколько кусков «кода, которым я горжусь», которые сменили друг друга на этом почётном месте.
Возможно, есть старый добрый код, которым я гордился ТОГДА, но речь идёт именно о том, какой собственный код кажется наиболее качественным и интересным СЕГОДНЯ, с учётом всего багажа опыта и знаний.
Возможно, есть старый добрый код, которым я гордился ТОГДА, но речь идёт именно о том, какой собственный код кажется наиболее качественным и интересным СЕГОДНЯ, с учётом всего багажа опыта и знаний.
а меня такая просьба ставит обычно в ступор, т.к. могу показать красивую архитектуру, которая под понятие «кусок кода» никак не подходит.
Если же брать отдельные куски этой архитектуры — ничего примечательного в них нет.
Если же брать отдельные куски этой архитектуры — ничего примечательного в них нет.
Зависит от специализации.
При найме архитектора вполне можно попросить показать архитектуру проекта, которой вы гордитесь :-)
При найме архитектора вполне можно попросить показать архитектуру проекта, которой вы гордитесь :-)
не троллинга ради, а чисто из профессионального любопытства. Вы с такими встречались? С архитектурами которыми человек гордится и которые действительно были бы хороши?
(в качестве пояснения почему у меня родился такой вопрос
У меня есть подозрение, что это невозможно. Если у нас «водопад» — то когда мы закончим «падать» — есть большой шанс, что «всё нетак» и мы быстро внесём изменения которые сделают нашу идеальную архитектуру — уже не идеальной.
Если у нас Agile или RUP с недлинными итерациями — то изменения архитектуры почти всегда отстают от изменения требований: новое требование — костыль, 2 костыля => изменение архитектуры.
Можно предположить что изначально была спроектирована архитектура «повышенной гибкости» — тогда она бдет «оч сложной» со всеми вытекающими.
Вот и получается что архитектура может быть идеальной когда архитектор что-то недоговаривает и все грязные места убраны под ковёр, или он уже не видит её недостатков.)
(в качестве пояснения почему у меня родился такой вопрос
У меня есть подозрение, что это невозможно. Если у нас «водопад» — то когда мы закончим «падать» — есть большой шанс, что «всё нетак» и мы быстро внесём изменения которые сделают нашу идеальную архитектуру — уже не идеальной.
Если у нас Agile или RUP с недлинными итерациями — то изменения архитектуры почти всегда отстают от изменения требований: новое требование — костыль, 2 костыля => изменение архитектуры.
Можно предположить что изначально была спроектирована архитектура «повышенной гибкости» — тогда она бдет «оч сложной» со всеми вытекающими.
Вот и получается что архитектура может быть идеальной когда архитектор что-то недоговаривает и все грязные места убраны под ковёр, или он уже не видит её недостатков.)
Честно говоря, я вообще вас не понял.
У меня у самого в моей практике есть как минимум две архитектуры, которыми я горжусь: я полностью с нуля их разработал и они успешно выполняют поставленные задачи.
Ещё пара «гениальных» архитектур (вместе с идеями проектов) есть у меня в голове.
Что я делаю не так?
У меня у самого в моей практике есть как минимум две архитектуры, которыми я горжусь: я полностью с нуля их разработал и они успешно выполняют поставленные задачи.
Ещё пара «гениальных» архитектур (вместе с идеями проектов) есть у меня в голове.
Что я делаю не так?
Имеется ввиду что идельных/универсальных решений не существует + не существует проектов в которых требования не меняются => не существует архитектуры которая в полной мере покроет абсолютно все. Следовательно нет архитектуры которой можно по настоящему гордиться.
Есть добротные вещи. Но гордиться вряд ли архитектор этим будет. Архитектор всегда знает где припрятан костыль. :)
Есть добротные вещи. Но гордиться вряд ли архитектор этим будет. Архитектор всегда знает где припрятан костыль. :)
Я так и не понял, какие подвохи вы ищете.
Никто и никогда не говорит об универсальных архитектурах. Есть исходная задача, есть архитектура, созданная специально под эту задачу. У архитектуры есть своя красота, простота, эффективность — именно ею можно похвастаться )
Ну и да, я спокойно могу рассказать об ограничениях той или иной архитектуры, границах применимости, недостатках — они есть, но от этого я не перестаю «гордиться» своим результатом ))
Никто и никогда не говорит об универсальных архитектурах. Есть исходная задача, есть архитектура, созданная специально под эту задачу. У архитектуры есть своя красота, простота, эффективность — именно ею можно похвастаться )
Ну и да, я спокойно могу рассказать об ограничениях той или иной архитектуры, границах применимости, недостатках — они есть, но от этого я не перестаю «гордиться» своим результатом ))
Да ну что вы, никаких подвохов. :) Просто человек хочет вас спустить с небес на землю. Но если вы в себе уверены, то просто не обращайте внимания. :)
Ну вобще-то не правда. Никого ниоткуда и никуда я спускать не хочу.
Изначальный посыл был в том что rubbyrabbit предлагал спросить на собеседовании у кандидата про архитектуру, которой кандидат гордится.
Я высказал обоснованные сомнения в том что хорошая архитекутра может существовать и спросил — встречался ли rubbyrabbit с такой на собеседованиях в том смысле что насколько такой метод хорошо работает.
Изначальный посыл был в том что rubbyrabbit предлагал спросить на собеседовании у кандидата про архитектуру, которой кандидат гордится.
Я высказал обоснованные сомнения в том что хорошая архитекутра может существовать и спросил — встречался ли rubbyrabbit с такой на собеседованиях в том смысле что насколько такой метод хорошо работает.
Я спросил — встречались ли вы с такими архитектурами. Вы ответили. Всё хорошо. Вы всё делаете «так».
А вы обсуждали эти архитектуры (те которые уже есть и которыми вы гордитесь) с кем-то ещё, кто не является вашим подчиненным и при этом тоже занимается разработкой?
А вы обсуждали эти архитектуры (те которые уже есть и которыми вы гордитесь) с кем-то ещё, кто не является вашим подчиненным и при этом тоже занимается разработкой?
Не понял про обсуждение.
Если речь про процесс разработки, то я писал документацию, сам разрабатывал в рамках этих архитектур, обучал других программистов (как равных так и в подчинении).
Если речь про процесс разработки, то я писал документацию, сам разрабатывал в рамках этих архитектур, обучал других программистов (как равных так и в подчинении).
Я спроектировал проект. Я считаю своё решение очень хорошим и горжусь им. Но действительно ли оно хорошее? Убедиться в этом можно только обсудив его с кем то «со стороны».
Так вы обсуждали свою архитектуру, которой вы гордитесь, с кем-то со стороны?
Так вы обсуждали свою архитектуру, которой вы гордитесь, с кем-то со стороны?
В случае одного проекта я обсуждал новую архитектуру с заказчиком и другими специалистами компании, защищал своё решение перед командой.
Во втором случае заказчику нужен был результат и он просто полностью мне доверился, архитектура обсуждалась с заказчиком только на высоком логическом уровне, на техническом — только с подчинёнными мне исполнителями.
Во втором случае заказчику нужен был результат и он просто полностью мне доверился, архитектура обсуждалась с заказчиком только на высоком логическом уровне, на техническом — только с подчинёнными мне исполнителями.
В этом нет необходимости. Хорошая архитекрура выдерживает проверку временем, имеет хорошую масштабируемость, легко читается даже после трех лет разработки разными программистами, проста в изучении новичками, не затратная в плане поддержки и расширения. Другими словами, если стоимость разработки со временем дешевеет, то вы создали отличную архитектуру. Кому-то показывать ее вовсе не обязательно, ведь вы можете нарваться на адепта своей архитектуры, который не признает ничего другого кроме своих разработок. Он вам расскажет, что это все у вас отстой, надо делать так, как он скажет, это единственный истинный путь.
Всё кроме «нарваться на адепта» слижком идеалистично.
Обсуждать и вправду практически не с кем.
Ну и да, нужно стремиться к идеалу, и взвешенное решение найти вполне реально.
Ну и да, нужно стремиться к идеалу, и взвешенное решение найти вполне реально.
У меня это все работает. Это получается, что я практикующий идеалист?
Давайте создадим клуб практикующих идеалистов ))
PS: У меня был такой без привязки к IT: Домик Иллюзий.
PS: У меня был такой без привязки к IT: Домик Иллюзий.
Никто не мешает показать чужой код. Я вообще по коду ничего не спрашиваю. Все мои собеседования проходят под лозунгом «Найди в команду человека, который умеет мыслить как ты, а все остальное вложим по ходу». Гибкость мышления важнее знаний в нашей команде. Наличие предрассудков и зашоренности будет только мешать, а не помогать этому человеку в работе.
Это всё хорошо. Вопрос лишь в оптимальной методике выяснения всех этих моментов. Поделитесь пожалуйста вашим способом поиска и найма сотрудников.
Каждое собеседование не похоже на предыдущее. Каждый соискатель уникален и собеседование проходит в ключе раскрытия его способностей и возможностей.
Один из самых главных и первых вопросов, который я задаю — расскажите мне про что-нибудь, что вы сделали такого, чем бы хотелось гордиться, про что хочется рассказывать другим людям. Этот вопрос и показывает уровень проблем, которые решает соискатель в данный момент времени. Чем выше уровень абстракций, тем лучше. Чем интереснее задачи решает соискатель, тем интереснее его рассказ, и, соответственно, проще определить его потенциал. Если знаний много, но рассказать особо нечего, то человек скорее всего «уставший».
Второй тип вопросов — решение «обыденных» абстрактных задач. Например, как лучше всего создать структуру хранения данных административно-территориального устройства государства. Этим проверяется способность наблюдать, анализировать, сопоставлять данные, про которые программист особо не задумывался даже. Заодно и кругозор проверяется, уровень эрудиции. Умение видеть проблемы в будущем — очень важное умение. Обычно люди получают ТЗ, реализовывают его и забывают про это. Но мне такие люди не особо нужны, потому что они не хотят изучать подоплеку задания, почему именно так было составлено ТЗ и какие задачи оно решает. Мне нужен человек, который помогал мне и был как можно более самостоятельным, а не который требовал на себя внимание как капризный ребенок.
Один из самых главных и первых вопросов, который я задаю — расскажите мне про что-нибудь, что вы сделали такого, чем бы хотелось гордиться, про что хочется рассказывать другим людям. Этот вопрос и показывает уровень проблем, которые решает соискатель в данный момент времени. Чем выше уровень абстракций, тем лучше. Чем интереснее задачи решает соискатель, тем интереснее его рассказ, и, соответственно, проще определить его потенциал. Если знаний много, но рассказать особо нечего, то человек скорее всего «уставший».
Второй тип вопросов — решение «обыденных» абстрактных задач. Например, как лучше всего создать структуру хранения данных административно-территориального устройства государства. Этим проверяется способность наблюдать, анализировать, сопоставлять данные, про которые программист особо не задумывался даже. Заодно и кругозор проверяется, уровень эрудиции. Умение видеть проблемы в будущем — очень важное умение. Обычно люди получают ТЗ, реализовывают его и забывают про это. Но мне такие люди не особо нужны, потому что они не хотят изучать подоплеку задания, почему именно так было составлено ТЗ и какие задачи оно решает. Мне нужен человек, который помогал мне и был как можно более самостоятельным, а не который требовал на себя внимание как капризный ребенок.
Прям захотелось с вами пообщаться на собеседовании ))
сколько уходит времени на такое собеседование?
Так это на собеседовании выяснится, нет? Всё равно некоторая фильтрация будет, думаю мало кто попытается устроиться на работу посредством чужого кода.
Большинству работодателей как-то, по-моему, важнее, чтобы человек сходу в команду влился как можно быстрее, а то и принял проект от увольняющегося сотрудника. Тех, которые готовы «вкладывать по ходу» минимум.
Большинству работодателей как-то, по-моему, важнее, чтобы человек сходу в команду влился как можно быстрее, а то и принял проект от увольняющегося сотрудника. Тех, которые готовы «вкладывать по ходу» минимум.
С нашим объемом знаний, который требуется вложить в сотрудника, любому будет тяжело влиться в проект. Именно поэтому мы готовы обучать. И даже, скорее всего, будем рассматривать больше джуниоров, чем опытных соискателей. Потому что опытные будут пытаться переложить свой опыт в проект, но это не всегда требуется, а в некоторых случаях даже мешает.
+джуниоры останутся на большее время скорее всего
согласен. и иногда, если честно, удивляет активное нежелание некоторых компаний признать очевидное и нанимать джуниоров. Часто ещё сопровождающееся плачем ярославны о том что — «ой мужиковкандидатов та толковых не осталось»
Это чисто финансовый вопрос.
В России очень дорого выращивать кадры.
Те, кто имеет для этого ресурсы, с удовольствием выращивают.
В России очень дорого выращивать кадры.
Те, кто имеет для этого ресурсы, с удовольствием выращивают.
видите ли, не на всякий проект можно набрать много юниров, от которых реальная отдача будет далеко не сразу. Это только долгосрочные проекты.
Но даже и на долгосрочный команду одних юниоров нанимать нельзя — будет провал.
Но даже и на долгосрочный команду одних юниоров нанимать нельзя — будет провал.
тут спору нет. всё верно.
Моя ошибка. в своём комментарии я подразумивал легион вебпроектов. В них часто нет ничего сложного, часто цена ошибки ->0. для них часто достаточно будет одного адекватного опытного человека + группа джуниоров (от полу года разработки или пользования соответсвующим языком в своих поделках), часто «выращивание» джуниоров до уровня достаточного для поддержки такого проекта происходит очень быстро.
Моя ошибка. в своём комментарии я подразумивал легион вебпроектов. В них часто нет ничего сложного, часто цена ошибки ->0. для них часто достаточно будет одного адекватного опытного человека + группа джуниоров (от полу года разработки или пользования соответсвующим языком в своих поделках), часто «выращивание» джуниоров до уровня достаточного для поддержки такого проекта происходит очень быстро.
Вам известны такие примеры? Мне нет.
> В них часто нет ничего сложного, часто цена ошибки ->0
Скажите это бухгалтеру или заказчику.
> для них часто достаточно будет одного адекватного опытного человека + группа джуниоров
Джуниор — это тот, 75% работы кого нужно контролировать. Как много времени останется у «адекватного опытного человека» на работу, если на нём «висит» группа джуниоров?
По моему опыту возможны варианты 1 опытный + 1 новичок либо 1 опытный + 2 середнячка. При этом опытный сможет хотя бы 50% времени тратить на свою работу.
> В них часто нет ничего сложного, часто цена ошибки ->0
Скажите это бухгалтеру или заказчику.
> для них часто достаточно будет одного адекватного опытного человека + группа джуниоров
Джуниор — это тот, 75% работы кого нужно контролировать. Как много времени останется у «адекватного опытного человека» на работу, если на нём «висит» группа джуниоров?
По моему опыту возможны варианты 1 опытный + 1 новичок либо 1 опытный + 2 середнячка. При этом опытный сможет хотя бы 50% времени тратить на свою работу.
>Вам известны такие примеры? Мне нет.
К сожалению известны
>Скажите это бухгалтеру или заказчику.
Странно что вы не упомянули запуск спутников на марс.
Да — ошибки в бухгалтерском по стоят денег (и потенциально очень больших).
Но процент уникального бухгалтерского ПО серди «легиона вебпроектов» не велик (заметьте — в своём комментарии я использовал слово «часто», а не «всегда»)
К сожалению известны
>Скажите это бухгалтеру или заказчику.
Странно что вы не упомянули запуск спутников на марс.
Да — ошибки в бухгалтерском по стоят денег (и потенциально очень больших).
Но процент уникального бухгалтерского ПО серди «легиона вебпроектов» не велик (заметьте — в своём комментарии я использовал слово «часто», а не «всегда»)
> Скажите это бухгалтеру или заказчику.
Я имел в виду высокую стоимость содержания «группы джуниоров» и оплату времени «одного адекватного опытного человека» по воспитанию этой группы.
На это способны только зрелые крупные компании со свободными деньгами. Причём для них тоже велик риск ухода обученного джуниора вместе со вложенными в него средствами.
Я имел в виду высокую стоимость содержания «группы джуниоров» и оплату времени «одного адекватного опытного человека» по воспитанию этой группы.
На это способны только зрелые крупные компании со свободными деньгами. Причём для них тоже велик риск ухода обученного джуниора вместе со вложенными в него средствами.
теперь я понял вас правильно.
Но не согласен.
Впрочем — возможно, что когда стартапноинвестиционный ажиотаж стихнет и толковые phpмидлы перестанут «хотеть и получать» 100т — схема о которой я говорил и станет лишена смысла. Ну или аутсорс в регионы — смотря что наступит раньше.
Но не согласен.
Впрочем — возможно, что когда стартапноинвестиционный ажиотаж стихнет и толковые phpмидлы перестанут «хотеть и получать» 100т — схема о которой я говорил и станет лишена смысла. Ну или аутсорс в регионы — смотря что наступит раньше.
Чужой код очень легко вычислить любым открытым вопросом, типа «почему вы выбрали именно этот алгоритм». Я с большим трудом представляю себе человека, который растеряется от такого вопроса к «коду, которым он гордится». Да и не нужно это, как правило, соответствие человека заявленному опыту видно и так.
Кстати, как раз код и помогает отсеять людей, которые мыслят заведомо не так, как ты. Я помню код, присланный от одного из нынешних гуру Хайлоада. В собеседовании я не участвовал, но его результаты подтверждают предварительные соображения от его кода: ни один человек из нашей тогдашней команды не смог бы с ним сработаться. Более того, при этом все были уверены, что хлопец вполне подходит по опыту.
В общем, если не лень, таки попробуйте эту методу, она отсеивает ненужный Вам формат очень легко и непринужденно.
Кстати, как раз код и помогает отсеять людей, которые мыслят заведомо не так, как ты. Я помню код, присланный от одного из нынешних гуру Хайлоада. В собеседовании я не участвовал, но его результаты подтверждают предварительные соображения от его кода: ни один человек из нашей тогдашней команды не смог бы с ним сработаться. Более того, при этом все были уверены, что хлопец вполне подходит по опыту.
В общем, если не лень, таки попробуйте эту методу, она отсеивает ненужный Вам формат очень легко и непринужденно.
>А вообще не понимаю почему разработчиков не просят сначала показать код или выполнить тестовое, но более-менее реальное, задание
Почему это не просят? Очень даже. Последние лет 10 такое наблюдаю постоянно. С точки зрения работодателя это просто мегаполезно. Некоторые работодатели утверждают, что не больше 10% из приславших резюме вообще пытается выполнить тесты. Отсев сразу и достаточно хороший.
Тут другое. Очень трудно адекватную тестовую задачу придумать. Чтобы и не слишком сложная/долгая и не совсем банальная, а желательно, ещё и интересная. Последнее время наблюдаю какой-то просто убийственный перекос в объём задач — предлагают реализовать хрень, над которой надо только думать пару дней и ещё несколько дней писать. Не, наверное, человеку, который именно такого рода задачи делает каждый день это на день работка, но если из смежной области — ужос-ужос какой-то. Совершенно непонятно ради чего _так_ надрываться и вообще стОит ли игра свеч.
Почему это не просят? Очень даже. Последние лет 10 такое наблюдаю постоянно. С точки зрения работодателя это просто мегаполезно. Некоторые работодатели утверждают, что не больше 10% из приславших резюме вообще пытается выполнить тесты. Отсев сразу и достаточно хороший.
Тут другое. Очень трудно адекватную тестовую задачу придумать. Чтобы и не слишком сложная/долгая и не совсем банальная, а желательно, ещё и интересная. Последнее время наблюдаю какой-то просто убийственный перекос в объём задач — предлагают реализовать хрень, над которой надо только думать пару дней и ещё несколько дней писать. Не, наверное, человеку, который именно такого рода задачи делает каждый день это на день работка, но если из смежной области — ужос-ужос какой-то. Совершенно непонятно ради чего _так_ надрываться и вообще стОит ли игра свеч.
Я честно говоря так ни разу сам не придумал и ни разу не видел «боевых» тестовых задач, которые были бы полезны на практике.
Сам обычно прошу написать что-то простое типа элементарного гестбука: без наворотов, просто добавление записей в БД, а потом смотрю код. По коду сразу всё-всё видно.
Потом задаю дополнительные вопросы: почему именно так реализована запись в БД, почему именно так вывод на экран и т.п.
Сам обычно прошу написать что-то простое типа элементарного гестбука: без наворотов, просто добавление записей в БД, а потом смотрю код. По коду сразу всё-всё видно.
Потом задаю дополнительные вопросы: почему именно так реализована запись в БД, почему именно так вывод на экран и т.п.
Почему это не просят? Очень даже. Последние лет 10 такое наблюдаю постоянно.
Как-то редко вижу, даже если пишу просьбу выслать тестовое задание сам — в ответ просят резюме, иногда приглашают на собеседование и тишина…
Не, наверное, человеку, который именно такого рода задачи делает каждый день это на день работка, но если из смежной области — ужос-ужос какой-то.
Вероятно такого человека и ищут?
Одно из адекватных, по-моему мнению, тестовых заданий для веб-разработки, что встречал — сделать прототип социальной сети — регистрация, профили, друзья, фотки, стена и всё в принципе. Допускается использование любимых сервер- и клиент-сайд фреймворков, включая самописные. Понятно, что грамотно написать такое с нуля на PHP займёт не один день, даже если точно знаешь что писать и архитектуру за 15 минут набросаешь — рутина заест. А вот владея любым MVC фреймворком — несколько часов, а по коду такого прототипа, по-моему, довольно много можно сказать о разработчике и как о кодере, и даже как об архитекторе.
> Как-то редко вижу, даже если пишу просьбу выслать тестовое задание сам — в ответ просят резюме, иногда приглашают на собеседование и тишина…
Либо работать там не стоит, либо именно вас им и не хватает :-)
Либо работать там не стоит, либо именно вас им и не хватает :-)
>Вероятно такого человека и ищут?
Ну, конечно, лучше быть богатым, но здоровым :) и хорошо получить сразу готовенького спеца именно в той области, в которой необходимо. Но, мне кажется, это редкая удача и слепая надежда именно на такой случай не слишком красит работодателя в глазах потенциальных работников. У меня были интересные случаи, когда та сторона соглашалась принять тестовое задание не на том языке, на котором требовалось изначально (и по результатам мы ещё встречались) или наоборот, предлагали пройти онлайн-тестирование на дотнете при том, что я ни его, ни егойных современных IDE в глаза не видел («да ладно, дотнет на яву похож — раберёшься») :).
>Одно из адекватных, по-моему мнению, тестовых заданий для веб-разработки, что встречал — сделать прототип социальной сети — регистрация, профили, друзья, фотки, стена и всё в принципе. Допускается использование любимых сервер- и клиент-сайд фреймворков, включая самописные.
А по-моему, этот самый перебор в чистом виде (я, вот, даже не знаю что такое «стена» :). Однажды мне предлагали подобное задание с условием НЕ использования каких-либо фреймворков :-( )
>а по коду такого прототипа, по-моему, довольно много можно сказать о разработчике и как о кодере, и даже как об архитекторе.
А по-моему, вон там выше человек написал про гестбук — это куда более гуманно, а по коду можно будет узнать ровно столько же :).
Ну, конечно, лучше быть богатым, но здоровым :) и хорошо получить сразу готовенького спеца именно в той области, в которой необходимо. Но, мне кажется, это редкая удача и слепая надежда именно на такой случай не слишком красит работодателя в глазах потенциальных работников. У меня были интересные случаи, когда та сторона соглашалась принять тестовое задание не на том языке, на котором требовалось изначально (и по результатам мы ещё встречались) или наоборот, предлагали пройти онлайн-тестирование на дотнете при том, что я ни его, ни егойных современных IDE в глаза не видел («да ладно, дотнет на яву похож — раберёшься») :).
>Одно из адекватных, по-моему мнению, тестовых заданий для веб-разработки, что встречал — сделать прототип социальной сети — регистрация, профили, друзья, фотки, стена и всё в принципе. Допускается использование любимых сервер- и клиент-сайд фреймворков, включая самописные.
А по-моему, этот самый перебор в чистом виде (я, вот, даже не знаю что такое «стена» :). Однажды мне предлагали подобное задание с условием НЕ использования каких-либо фреймворков :-( )
>а по коду такого прототипа, по-моему, довольно много можно сказать о разработчике и как о кодере, и даже как об архитекторе.
А по-моему, вон там выше человек написал про гестбук — это куда более гуманно, а по коду можно будет узнать ровно столько же :).
В гестбуке, как правило, нет связей многие-ко-многим, да ещё со значениями в таблице связи, что часто вызывает проблемы у начинающих. Если на синьора тест, то может и не надо, а вот на джуниора я б поинтересовался.
Конечно, вы правы, в гестбуке много чего нет: основ ООП, использования особенностей PHP5, мудрёных регекспов и сложного SQL.
Это всё можно уже узнать при дальнейшем собеседовании, но на первом отсеивающем этапе вполне возможно и достаточно оценить адекватность человека и его опыт по нескольким строчкам кода.
Это всё можно уже узнать при дальнейшем собеседовании, но на первом отсеивающем этапе вполне возможно и достаточно оценить адекватность человека и его опыт по нескольким строчкам кода.
Одно из адекватных, по-моему мнению, тестовых заданий для веб-разработки, что встречал — сделать прототип социальной сети — регистрация, профили, друзья, фотки, стена и всё в принципе.
Фотострана? :)
ИМХО, задание не адекватное, да и любая соцсеть предполагает высокие нагрузки в будущем, а значит проблема будет не в коде, а в организации хранения данных. Собственно, прототип должен учесть масштабирование, то есть в данном случае я бы кода дальше интерфейсов не написал бы ни строчки, не говоря уже об HTML.
Фотострана? :)
ИМХО, задание не адекватное, да и любая соцсеть предполагает высокие нагрузки в будущем, а значит проблема будет не в коде, а в организации хранения данных. Собственно, прототип должен учесть масштабирование, то есть в данном случае я бы кода дальше интерфейсов не написал бы ни строчки, не говоря уже об HTML.
Ога :)
Ну, организация хранения данных не забота рядового кодера. Делаю модель, обеспечиваю её хранение, а дальше оптимизация, не касающаяся модели.
Ну, организация хранения данных не забота рядового кодера. Делаю модель, обеспечиваю её хранение, а дальше оптимизация, не касающаяся модели.
Для организации распределенного хранения данных нужно и кода немало написать…
Нужно, но, наверное, не на уровне модели. Её интерфейсы, вероятно, останутся неизменяемые, а логику хранения в хайлоад проекте будут писать не рядовые кодеры, а «специально обученные люди», и находиться она будет на каком-то уровне абстракции, который рядовые кодеры будут вызывать процедурами/методами типа $object.save() или save($object).
Долго думал, что бы ответить.
Не будет так никогда $object.save() во всем проекте, далеко не всегда нужно тратить время на создание таких сущностей.
Такого уровня абстракции, конечно, можно достичь, но часто просто не имеет смысла.
В общем, у нас нету рядовых кодеров и специально обученных людей, каждый может писать и тот и другой код, но при желании может спросить совета и принять совместное решение по той или иной проблеме.
Собственно, если возвращаться к теме топика, то зарплата в нашей компании, насколько мне известно, зависит от отдачи проекту, а не от профессионального уровня. Те — кто больше/быстрее/качественнее работают, у тех и уровень очень быстро растёт, а средние люди сидят и потихоньку кодят, получают свое бабло. Поэтому, если говорить о подборе людей в проект — то я бы искал прежде всего тех, кто готов и будет быстро развиваться, хоть и не имеет опыта того же хайлоада. Но средних людей тоже надо брать, чтобы обеспечить какую-то стабильность в кадрах, иначе будет тяжело по многим причинам. В общем, тема большая, а я уже далеко от этой ветки комментариев ушел :)
А, да, не в обиду, но не похоже, чтобы у Вас был опыт хайлоада, поэтому и есть такое представление о $object.save() и адекватности тестового задания на создание соцсети.
Не будет так никогда $object.save() во всем проекте, далеко не всегда нужно тратить время на создание таких сущностей.
Такого уровня абстракции, конечно, можно достичь, но часто просто не имеет смысла.
В общем, у нас нету рядовых кодеров и специально обученных людей, каждый может писать и тот и другой код, но при желании может спросить совета и принять совместное решение по той или иной проблеме.
Собственно, если возвращаться к теме топика, то зарплата в нашей компании, насколько мне известно, зависит от отдачи проекту, а не от профессионального уровня. Те — кто больше/быстрее/качественнее работают, у тех и уровень очень быстро растёт, а средние люди сидят и потихоньку кодят, получают свое бабло. Поэтому, если говорить о подборе людей в проект — то я бы искал прежде всего тех, кто готов и будет быстро развиваться, хоть и не имеет опыта того же хайлоада. Но средних людей тоже надо брать, чтобы обеспечить какую-то стабильность в кадрах, иначе будет тяжело по многим причинам. В общем, тема большая, а я уже далеко от этой ветки комментариев ушел :)
А, да, не в обиду, но не похоже, чтобы у Вас был опыт хайлоада, поэтому и есть такое представление о $object.save() и адекватности тестового задания на создание соцсети.
Ну да, опыта хайлоада нет и это, наверное, хорошо видно по моему коду таких тестовых заданий. Но в таких заданиях про хайлоад ни слова не говорится, и задание на создание прототипа соцсети, а не соцсети. Кто-то сочтёт нужным сделать код оптимизированным и масштабируемым, кто-то заложит простые возможности сделать это, а кто-то (типа меня) выполнит ТЗ от «сих до сих». А работодатель выберет того, кто больше отвечает его требованиям. Ведь адекватность разработчика величина не абсолютная, для кого-то преждевременная оптимизация и излишняя расширяемость зло, а главное время разработки, для кого-то по умолчанию это самые важные критерии.
Если речь идет про вакансии программистов, то ваше идеальное интервью сразу отсеет интровертов.
А не исключено, что именно среди них большинство хороших программистов.
А не исключено, что именно среди них большинство хороших программистов.
Ребята, нет идеальных, всегда точных и работающих способов узнать, что из себя представляет человек с помощью интервью. Все попытки подойти к этому процессу технократически, т.е. свести его к дискретным алгоритмам, к сожалению (а на самом деле — к счастью!) — провальны.
Это искусство, потому что одинаковых соискателей не существует.
И поэтому в первую очередь нужно не столько составлять алгоритмы, сколько обучать и воспитывать качественных HR-специалистов, которые способны к этому труду.
Способные к этому люди знают тысячи способов понять внутреннее устройство соискателя. И — важно — они утруждают себя разобраться в той работе, на которую будут отбирать людей. Не до тонкостей, но достаточно, чтобы понять, какие конкретно качества нужно искать в приходящих людях.
Например, я могу написать интернет-магазин с CRM-системой на PHP, но мой путь изучения этого языка был таков, что на большинство «умно-профессиональных вопросов» я не отвечу. Я просто знаю, как что на нем можно сделать, а каким специальным термином это называется — я могу не знать, и чаще всего — не знаю. И это не делает меня плохим разработчиком. Странным — да :)
Вообще, как мне кажется, главное, что отличает хорошего программиста от «быдлокодера» — это образ мышления. Вовсе не знание на память сотни методов вывода чего-то там куда-то там — на это есть документация и всякие шпоргалки, в конце концов. Вот образ мышления соискателя и надо каким-то образом оценить в первую очередь.
Для теста вполне сгодится просьба оптимизировать код, написанный «быдлокодером». Чтобы соискатель привел в порядок переменные, читаемость, логику, может быть задействовал какой-то более скоростной метод из ему известных, где-то урезал лишнее выделение памяти, запросы к БД, и т.п.
Это искусство, потому что одинаковых соискателей не существует.
И поэтому в первую очередь нужно не столько составлять алгоритмы, сколько обучать и воспитывать качественных HR-специалистов, которые способны к этому труду.
Способные к этому люди знают тысячи способов понять внутреннее устройство соискателя. И — важно — они утруждают себя разобраться в той работе, на которую будут отбирать людей. Не до тонкостей, но достаточно, чтобы понять, какие конкретно качества нужно искать в приходящих людях.
Например, я могу написать интернет-магазин с CRM-системой на PHP, но мой путь изучения этого языка был таков, что на большинство «умно-профессиональных вопросов» я не отвечу. Я просто знаю, как что на нем можно сделать, а каким специальным термином это называется — я могу не знать, и чаще всего — не знаю. И это не делает меня плохим разработчиком. Странным — да :)
Вообще, как мне кажется, главное, что отличает хорошего программиста от «быдлокодера» — это образ мышления. Вовсе не знание на память сотни методов вывода чего-то там куда-то там — на это есть документация и всякие шпоргалки, в конце концов. Вот образ мышления соискателя и надо каким-то образом оценить в первую очередь.
Для теста вполне сгодится просьба оптимизировать код, написанный «быдлокодером». Чтобы соискатель привел в порядок переменные, читаемость, логику, может быть задействовал какой-то более скоростной метод из ему известных, где-то урезал лишнее выделение памяти, запросы к БД, и т.п.
> Я просто знаю, как что на нем можно сделать, а каким специальным термином это называется — я могу не знать, и чаще всего — не знаю. И это не делает меня плохим разработчиком.
Ну так о том-то и речь! И как бы вы проводили собеседование? Вы бы спрашивали о возможностях и путях реализации этих возможностей, пускай и без терминов.
> Для теста вполне сгодится просьба оптимизировать код, написанный «быдлокодером».
Хороший, хотя и не очень гуманный вариант :-)
Ну так о том-то и речь! И как бы вы проводили собеседование? Вы бы спрашивали о возможностях и путях реализации этих возможностей, пускай и без терминов.
> Для теста вполне сгодится просьба оптимизировать код, написанный «быдлокодером».
Хороший, хотя и не очень гуманный вариант :-)
> Например, я могу написать интернет-магазин с CRM-системой на PHP, но мой путь изучения этого языка был таков, что на большинство «умно-профессиональных вопросов» я не отвечу.
Вот я бы вас не взял. :) Почему? Потому что на другой платформе вам будет трудно. Уж извините.
Программирование это такая же наука как, скажем, физика. Если вы не знаете базовых вещей, из чего все состоит, то вы плохой ученый. И многое вы не сделаете.
Вот я бы вас не взял. :) Почему? Потому что на другой платформе вам будет трудно. Уж извините.
Программирование это такая же наука как, скажем, физика. Если вы не знаете базовых вещей, из чего все состоит, то вы плохой ученый. И многое вы не сделаете.
Согласен с вами.
Без знания терминологии и «тройку» не получишь :-)
Без знания терминологии и «тройку» не получишь :-)
Собственно, тот «волшебный метод», по которому я изучал PHP, а до этого JS и когда-то сам HTML — это обратная разработка.
Начинается всё с желания (или необходимости) модифицировать уже написанный кем-то код под свои нужды. После того, как ты разбираешься с этим, ты пишешь свой первый самостоятельный плагин, попутно разбираясь с тем, что у тебя не получается. Постепенно ты усложняешь уровень решаемых задач, и в конце концов, тебе становится под силу то, что делают «нормальные» профессионалы.
Неизбежно в процессе этого ты читаешь мануалы, где описаны способы решения задач и их «заграничные» названия. Но ты всегда решаешь конкретную задачу, и для решения её достаточно знать, как это сделать, а про то, как это называется, позволительно и забыть.
Начинается всё с желания (или необходимости) модифицировать уже написанный кем-то код под свои нужды. После того, как ты разбираешься с этим, ты пишешь свой первый самостоятельный плагин, попутно разбираясь с тем, что у тебя не получается. Постепенно ты усложняешь уровень решаемых задач, и в конце концов, тебе становится под силу то, что делают «нормальные» профессионалы.
Неизбежно в процессе этого ты читаешь мануалы, где описаны способы решения задач и их «заграничные» названия. Но ты всегда решаешь конкретную задачу, и для решения её достаточно знать, как это сделать, а про то, как это называется, позволительно и забыть.
У меня всегда вызывают подозрение кандидаты, слишком хорошо знающие терминологию, названия паттернов, десятки технологий упоминают. На поверку часто оказывается что за этой ширмой полтора недоделанных проекта и огромная куча предрассудков типа «это правильно, потому что я так читал у МакКонелла»
:) А вы думаете что МакКонелл ересь несет? :)
В целом, не сталкивался с человеком который правильно употребляя терминологию, не понимает в чем суть. А по поводу недоделанных проектов — это не показатель конкретного программиста.
В целом, не сталкивался с человеком который правильно употребляя терминологию, не понимает в чем суть. А по поводу недоделанных проектов — это не показатель конкретного программиста.
нет, МакКонелл все правильно написал, только не все его могут правильно прочитать :)
да, и аргумент должен быть не «потому что так писал МакКонелл». Человек должен понимать почему МакКонелл рекомендует именно это.
Я понял что вы имеете виду. Вы правы.
Но была у мну история… Был у мну архитектор, который был самоучка. И если ему начинаешь объяснять что вот тут сделать лучше так, то он это не принимал. А если скажешь что так писал Фаулер (или еще кто то), то он тогда с умной физиономией говорит что да, так лучше будет. :) Любил он громкие имена. Поэтому иногда высказывание «потому что так писал МакКонел» бывает гораздо сильнее чем толковое объяснение слов МакКонела. :)
Но это притча. Как я уже сказал, вы правы. Мало знать чего там кто пишет, главное понимать почему кто то рекомендует именно так. Но вот ребят которые грамотно употребляют терминологию, чаще всего понимают почему надо именно так, а не иначе.
Но была у мну история… Был у мну архитектор, который был самоучка. И если ему начинаешь объяснять что вот тут сделать лучше так, то он это не принимал. А если скажешь что так писал Фаулер (или еще кто то), то он тогда с умной физиономией говорит что да, так лучше будет. :) Любил он громкие имена. Поэтому иногда высказывание «потому что так писал МакКонел» бывает гораздо сильнее чем толковое объяснение слов МакКонела. :)
Но это притча. Как я уже сказал, вы правы. Мало знать чего там кто пишет, главное понимать почему кто то рекомендует именно так. Но вот ребят которые грамотно употребляют терминологию, чаще всего понимают почему надо именно так, а не иначе.
>>Был у мну архитектор, который был самоучка
странно, обычно самоучки не признают никаких громких имён :)
>> ребят которые грамотно употребляют терминологию, чаще всего понимают почему надо именно так, а не иначе
удивительно, мне чаще попадаются обратные варианты :) Может быть дело в том что по собеседованию не всегда удается глубоко копнуть. Но все это видно на тестовом задании
странно, обычно самоучки не признают никаких громких имён :)
>> ребят которые грамотно употребляют терминологию, чаще всего понимают почему надо именно так, а не иначе
удивительно, мне чаще попадаются обратные варианты :) Может быть дело в том что по собеседованию не всегда удается глубоко копнуть. Но все это видно на тестовом задании
«Но вот ребят которые грамотно употребляют терминологию, чаще всего понимают почему надо именно так, а не иначе.»
ох… даже на хабре часто можно видеть и по топикам и по комментариям следующие часто распространенные заблуждения:
1)любой автотест написанный на xUnit = юнит/модульный тест
2)«модель» из «MVC» = классы хранящие в себе значения соответсвующих записей в базе данных
носители этих заблуждений могут вполне неплохо жонглировать модными словечками, некоторые могут вполне себе даже быть архитекторами или тимлидами в своих компаниях.
ох… даже на хабре часто можно видеть и по топикам и по комментариям следующие часто распространенные заблуждения:
1)любой автотест написанный на xUnit = юнит/модульный тест
2)«модель» из «MVC» = классы хранящие в себе значения соответсвующих записей в базе данных
носители этих заблуждений могут вполне неплохо жонглировать модными словечками, некоторые могут вполне себе даже быть архитекторами или тимлидами в своих компаниях.
Не, ну я же же говорю:
«ребята которые грамотно употребляют терминологию».
А тут разве грамотное употребление терминологии?
«жонглировать модными словечками» и грамотно употреблять терминологию, это разные вещи. Хотя вы конечно удачно придрались. :)
«ребята которые грамотно употребляют терминологию».
А тут разве грамотное употребление терминологии?
«жонглировать модными словечками» и грамотно употреблять терминологию, это разные вещи. Хотя вы конечно удачно придрались. :)
Ни вкоем случае не ставил целью «придираться».
«Грамотно употреблять терминалогию» — это свойство в реальном мире очень редко достигает значения 1 + имеет свойство меняться в зависимости от времени наблюдения)
А эти 2 распространенных заблуждения — легко проверить в неунизительной для кандидата форме диалога + одновременно с этим проверяется адекватность кандидата + можно потом продолжать разговор далее в более тонкие материи.
Например можно попросить кандидата спроектировать ну например «библиотеку книг» ну или там… сервис для отслеживания появления билетов на поезд. И когда начнется традиционный буллщитинг, вы задаёте традиционные вопросы почему он сделал именно так, а потом спрашиваете кандидата, что он думает по поводу ну например такого решения, и рисуете правильное решение (строго говоря «решение которое вам кажется правильным»). Если мы всё сделали правильно и не проявили неуважения — то тут станет видна способность кандидата вести диалог и в случае ошибки признать это, ну а заодно и наша способность быть тактичными в непростой ситуации и приводить аргументы.
«Грамотно употреблять терминалогию» — это свойство в реальном мире очень редко достигает значения 1 + имеет свойство меняться в зависимости от времени наблюдения)
А эти 2 распространенных заблуждения — легко проверить в неунизительной для кандидата форме диалога + одновременно с этим проверяется адекватность кандидата + можно потом продолжать разговор далее в более тонкие материи.
Например можно попросить кандидата спроектировать ну например «библиотеку книг» ну или там… сервис для отслеживания появления билетов на поезд. И когда начнется традиционный буллщитинг, вы задаёте традиционные вопросы почему он сделал именно так, а потом спрашиваете кандидата, что он думает по поводу ну например такого решения, и рисуете правильное решение (строго говоря «решение которое вам кажется правильным»). Если мы всё сделали правильно и не проявили неуважения — то тут станет видна способность кандидата вести диалог и в случае ошибки признать это, ну а заодно и наша способность быть тактичными в непростой ситуации и приводить аргументы.
Я с вами абсолютно согласен. Ваш подход верен. Но я писал уже ниже, что нельзя использовать на собеседовании лишь один инструмент. Надо использовать несколько. Безусловно я делаю и так как вы говорите, но я делаю и так как написано в топике. Необходимо использовать несколько инструментов для выявления портрета кандидата. И вот тут я считаю что текущий инструмент (давайте называть это так, что бы не было проблем с пониманием друг друга), довольно таки неплох. :) Он имеет право на существование. :)
>нельзя использовать на собеседовании один инструмент
согласен (хотя у меня есть подозрение, что часто можно обходится и одним — «тестом на адекватность», но пока нет возможности убедится в этом на сколь-нибудь значащей выборке)
мои комментарии относились к вашему утверждению про «ребят», с целью показать что это не всегда так.
согласен (хотя у меня есть подозрение, что часто можно обходится и одним — «тестом на адекватность», но пока нет возможности убедится в этом на сколь-нибудь значащей выборке)
мои комментарии относились к вашему утверждению про «ребят», с целью показать что это не всегда так.
Да ну, про терминологию вы меня не убедите. Ей богу. :) Если человек грамотно ее употребляет, то человек понимает о чем он говорит. Просто употребление термина в правильном контексте, говорит о том что человек знает контекст (потому что он может найти для текущего контекста термин).
А про изменчивость я ничего не понял что вы имели ввиду. :) То что один и тот же термин в разных контекстах несет разную смысловую нагрузку? Дык, ну это и ежу понятно. То что технологии быстро меняются и нельзя сейчас точно сказать что этот термин означает? Да тоже как то притянуто… :(
А про изменчивость я ничего не понял что вы имели ввиду. :) То что один и тот же термин в разных контекстах несет разную смысловую нагрузку? Дык, ну это и ежу понятно. То что технологии быстро меняются и нельзя сейчас точно сказать что этот термин означает? Да тоже как то притянуто… :(
Например, AJAX очень часто употребляется формально неверно. И вполне в остальном грамотные люди тянут асинхронно JavaScript'ом JSON или HTML c сервера, уверенные что они используют AJAX(ML). Не часто услышишь AJAJ(SON) или AJAH(TML). Грамотно это?
Ух ты какой пример! :)
Что то мне подсказывает что вы не новичок в этой области, а скорее всего матерый гуру. Знаете почему? :) Потому что вы грамотно употребляете терминологию. :)
Что то мне подсказывает что вы не новичок в этой области, а скорее всего матерый гуру. Знаете почему? :) Потому что вы грамотно употребляете терминологию. :)
А вот ещё кстати терминологический пример.
DTO(Data transfer object) и VO(Value Object) иногда используются как синонимы или один вместо другого. Ничего страшного в этом нет, но в зависимости от того на какой литературе/статьях мы учились мы можем считать грамотным/неграмотным/совсем не грамотным.
DTO(Data transfer object) и VO(Value Object) иногда используются как синонимы или один вместо другого. Ничего страшного в этом нет, но в зависимости от того на какой литературе/статьях мы учились мы можем считать грамотным/неграмотным/совсем не грамотным.
Скорее
:(
У меня всегда вызывают подозрение кандидаты, слишком хорошо знающие терминологию, названия паттернов, десятки технологий упоминают. На поверку часто оказывается что за этой ширмой полтора недоделанных проекта и огромная куча предрассудков типа «это правильно, потому что я так читал у МакКонелла»
:(
Вы правда не в теме? :)
Эникей, не теряющий надежды устроиться чисто веб-разработчиком и для этого следящий за тенденциями, технологиями, фреймворками и т. п., в том числе терминологией :)
Ну вот вас я бы взял. :)
мой вам совет, не старайтесь охватить все современные тенденции, скоцентрируйтесь на чем-то одном. Тогда есть шанс.
«про изменчивость»
я имел ввиду вот что: «грамотность употребления терминов».
Мы задаём вопрос человеку. Он на него отвечает. В зависимости от того принимаем ли мы его ответ как правильный, мы принимаем решение — «грамотно» или «не грамотно». Можно закончить, а можно задать ещё вопрос — и величина итоговой «грамотности»изменится.
Получается что «грамотность» помимо того что зависит от нашего восприятия, так ещё и меняется с течением времени и зависит от длительности наблюдения.
я имел ввиду вот что: «грамотность употребления терминов».
Мы задаём вопрос человеку. Он на него отвечает. В зависимости от того принимаем ли мы его ответ как правильный, мы принимаем решение — «грамотно» или «не грамотно». Можно закончить, а можно задать ещё вопрос — и величина итоговой «грамотности»изменится.
Получается что «грамотность» помимо того что зависит от нашего восприятия, так ещё и меняется с течением времени и зависит от длительности наблюдения.
Извините, но хочется уточнить что унизительного вы увидели в текущем подходе?
слова про неунизительную форму относились к моим словам о возможном использовании распространенных заблуждений с целью проверки кандидата на адекватность(в нашей отрасли очень распространено стремление выставить человека идиотом. в такой ситуации на о какой адекватности речи не идёт ибо мы сами ещё в младшей школе).
К «текущему подходу» они отношения не имели каким бы он ни был)
К «текущему подходу» они отношения не имели каким бы он ни был)
>Был у мну архитектор, который был самоучка.
Мне стало жутко любопытно — а где учат на архитекторов?
Мне стало жутко любопытно — а где учат на архитекторов?
Имелось ввиду человек который всю жизнь работал один, не было человека более компетентного, который мог бы указать на ошибки и чего то разъяснить. Человек не работал в команде. Вот он и самоучка поэтому.
Обычно ты развиваешься в команде с более опытными людьми, которые передают тебе опыт.
Очень редки случаи когда человек работает один и из него получается хороший архитектор/программист.
Вы не знали?
Обычно ты развиваешься в команде с более опытными людьми, которые передают тебе опыт.
Очень редки случаи когда человек работает один и из него получается хороший архитектор/программист.
Вы не знали?
Не, не про то. Я без подколок спрашивал (ну,… почти). Возможно, я действительно что-то пропустил и на архитектора где-то учат. Я бы подумал а не пойти ли мне поучиться на него самого.
А в ситуации, которую вы описали — вероятно человек занимал не соответствующую его квалификации должность? Почему он архитектор? Я работал и в команде. Я работал и один, когда все решения от выбора технологии и архитектуры, до проектирования любого уровня и написания конечного кода на мне. Я архитектор? Ну да, такой маленький архитектор проектов, которые могут быть сделаны силами одного человека. Но брать на себя ответственность за большой проект — не, не, не. Слаб в коленках :).
А в ситуации, которую вы описали — вероятно человек занимал не соответствующую его квалификации должность? Почему он архитектор? Я работал и в команде. Я работал и один, когда все решения от выбора технологии и архитектуры, до проектирования любого уровня и написания конечного кода на мне. Я архитектор? Ну да, такой маленький архитектор проектов, которые могут быть сделаны силами одного человека. Но брать на себя ответственность за большой проект — не, не, не. Слаб в коленках :).
Я то же до недавнего времени придерживался такой логике. Там где задачи не очень сложные в плане архитектуры, все это работает очень хорошо. Многие вещи можно держать в голове, много походу можно переписать, при этом не боишься что нибудь сломать.
Но относительно недавно встала задача, сопровождать параллельно несколько проектов, у которых примерно половина функционала идентична, а остальное у каждого свое. И когда надо было менять какой то кусок из совпадающего кода, приходилось править во всех проектах, что не очень интересно. И тогда я подумал, можно же все это реализовать в виде плагинов с помощью Ioc и DI. Тогда у меня будет 1 проект с кучей плагинов, а на паблише для каждого проекта будут свои плагины. И вот когда я решил все это делать, я понял как много значит, знание всяких паттернов. Не обязательно надо знать название паттерна(хотя когда вы начнете их использовать, названия у вас осядут в голове), но зная что в таком то проекте использован тот или иной паттерн, можно примерно уже понять, как это все работает.
Но относительно недавно встала задача, сопровождать параллельно несколько проектов, у которых примерно половина функционала идентична, а остальное у каждого свое. И когда надо было менять какой то кусок из совпадающего кода, приходилось править во всех проектах, что не очень интересно. И тогда я подумал, можно же все это реализовать в виде плагинов с помощью Ioc и DI. Тогда у меня будет 1 проект с кучей плагинов, а на паблише для каждого проекта будут свои плагины. И вот когда я решил все это делать, я понял как много значит, знание всяких паттернов. Не обязательно надо знать название паттерна(хотя когда вы начнете их использовать, названия у вас осядут в голове), но зная что в таком то проекте использован тот или иной паттерн, можно примерно уже понять, как это все работает.
У меня на тему собеседований имеется любимая история. Есть у меня хороший знакомый в штатах, зовут Скотт. У него есть головастая сестра, которая сейчас работает в IBM. Он рассказывал, что до IBM она работала в Red Hat, но самое интересное, как она туда попала. Приходит на собеседование и после всех формальностей ей начинают задавать вопросы. Только несколько вопросов были про линукс или IT тематику, а 95% собеседования её проверяли на знание вселенной Star Wars. Кто такой Чубакка, родная планета Скайвокера, имя корабля Хана Соло и тому подобное. Всё знала, приняли на работу.
Выскажу своё мнение по поводу формата приема на работу, без претензии на идеальность.
Онлайн-тест с ограниченным временем, на знание основ, т.е чтобы успеть ответить, но не успеть нагуглить.
Далее, 2-3 реальных задачи. Код отсылаем по E-Mail. Работодатель смотрит код (разумеется, имеется ввиду не сам работодатель, если он «не шарит», а, например, штатный программист), если код неадекватный — соискатель отсеивается, если адекватный — приглашается на собеседование.
Далее, на собеседовании по этому коду задается пара-тройка вопросов, с целью понять, кем написан код. Если человек не может что-то объяснить — «До свиданья»
Если все ОК, даются опять же, примеры кода, с целью объяснить «как это работает и какого его назначение»
Ну а далее, не односторонее интервьюрирование соискателя, а дискуссия, обсуждение каких-то вопросов и технологий, связанных с предстоящей деятельностью.
Вот так, по-моему, должен выглядеть прим в штат программиста.
Онлайн-тест с ограниченным временем, на знание основ, т.е чтобы успеть ответить, но не успеть нагуглить.
Далее, 2-3 реальных задачи. Код отсылаем по E-Mail. Работодатель смотрит код (разумеется, имеется ввиду не сам работодатель, если он «не шарит», а, например, штатный программист), если код неадекватный — соискатель отсеивается, если адекватный — приглашается на собеседование.
Далее, на собеседовании по этому коду задается пара-тройка вопросов, с целью понять, кем написан код. Если человек не может что-то объяснить — «До свиданья»
Если все ОК, даются опять же, примеры кода, с целью объяснить «как это работает и какого его назначение»
Ну а далее, не односторонее интервьюрирование соискателя, а дискуссия, обсуждение каких-то вопросов и технологий, связанных с предстоящей деятельностью.
Вот так, по-моему, должен выглядеть прим в штат программиста.
Мне кажется, в этом методе слишком смещены акценты на умение кодить.
Для проверки навыков кодинга достаточно одного тестового задания, выполняемого прямо на собеседовании. Причем, возможности гуглить, человека лишать не надо. Это не школьный госэкзамен по математике. В реальной рабочей обстановке Гугль с Википедией у сотрудника будут, и время на их чтение — тоже.
Кстати, если вы принимаете на работу не школьников, а хотя бы студентов, то они прекрасно понимают, что «попросить друга сделать тестовое задание» — бесполезно, ведь потом каждый день придется делать такое на работе, а работать за себя друга уже не посадишь.
Все, кто откликнется на вакансию, будут в той или иной мере специалистами, и ваша задача — найти среди них адекватного человека. Который потом на равных с вами разделит ответственность. Именно найти человека среди специалистов, а не наоборот.
Нельзя не уделять внимание личностному, психологическому портрету кандидата. По меньшей мере это надо делать наравне с оценкой профессиональных умений. А иногда и приоритетнее.
Для проверки навыков кодинга достаточно одного тестового задания, выполняемого прямо на собеседовании. Причем, возможности гуглить, человека лишать не надо. Это не школьный госэкзамен по математике. В реальной рабочей обстановке Гугль с Википедией у сотрудника будут, и время на их чтение — тоже.
Кстати, если вы принимаете на работу не школьников, а хотя бы студентов, то они прекрасно понимают, что «попросить друга сделать тестовое задание» — бесполезно, ведь потом каждый день придется делать такое на работе, а работать за себя друга уже не посадишь.
Все, кто откликнется на вакансию, будут в той или иной мере специалистами, и ваша задача — найти среди них адекватного человека. Который потом на равных с вами разделит ответственность. Именно найти человека среди специалистов, а не наоборот.
Нельзя не уделять внимание личностному, психологическому портрету кандидата. По меньшей мере это надо делать наравне с оценкой профессиональных умений. А иногда и приоритетнее.
Да ничерта подобного. Собеседование это в первую очередь испытание человека в не комфортных для испытуемого условиях. Основная цель собеседования понять уровень компетенции и личностый портрет составить.
Кодинг — это последняя вещь которую надо проверять. Точно знаю что хороший программист это не тот который умеет кодить на конкретном языке, это человек который знает основы и принципы работы с технологиями. Вот например прошу накодить какой нить DAL в рамках Hibernate на Java. Человек это делал сто раз. Он код заучил. Но он абсолютно не понимает че это такое и как это работает. Ему будет сложно потом работать скажем с Entity Framweork в рамках .Net. Переход будет для него сложен. Другое дело что он просто понимает как это работает и в чем суть ORM, например.
Так и обстоят дела. Надо понять, в курсе ли человек че это такое и как это работает. Как он пишет код, мне абсолютно по барабану. И никогда не просил на собеседовании писать код. И никогда не просил прислать примеры кода.
Сделать тестовое задание на незнакомой человеку платформе — это да. Это сразу покажет как он знает основы и как он умеет обучаться.
И очень важно понять «адекватность» человека с точки зрения социума. Я считаю что это самый важный показатель. Просто трудно будет людям работать с таким человеком, не зависимо от того какой он гуру. А программист идеально работает тогда, когда ему комфортно. Такой человек может испортить комфорт других программистов. И его плюсы не стоят ничего против тех минусов которые он принесет.
Кодинг — это последняя вещь которую надо проверять. Точно знаю что хороший программист это не тот который умеет кодить на конкретном языке, это человек который знает основы и принципы работы с технологиями. Вот например прошу накодить какой нить DAL в рамках Hibernate на Java. Человек это делал сто раз. Он код заучил. Но он абсолютно не понимает че это такое и как это работает. Ему будет сложно потом работать скажем с Entity Framweork в рамках .Net. Переход будет для него сложен. Другое дело что он просто понимает как это работает и в чем суть ORM, например.
Так и обстоят дела. Надо понять, в курсе ли человек че это такое и как это работает. Как он пишет код, мне абсолютно по барабану. И никогда не просил на собеседовании писать код. И никогда не просил прислать примеры кода.
Сделать тестовое задание на незнакомой человеку платформе — это да. Это сразу покажет как он знает основы и как он умеет обучаться.
И очень важно понять «адекватность» человека с точки зрения социума. Я считаю что это самый важный показатель. Просто трудно будет людям работать с таким человеком, не зависимо от того какой он гуру. А программист идеально работает тогда, когда ему комфортно. Такой человек может испортить комфорт других программистов. И его плюсы не стоят ничего против тех минусов которые он принесет.
Да, важнее не кодинг, а умение понимать алгоритм и искать решение. Просто в тексте как то не получилось акцент на это поставить, но это я и имел ввиду.
А вот по поводу дискуссии, человеку комфортнее общаться на тематику, которая ему близка, и по тому, как он об этом говорит, можно судить и о личности. Потому что знаю очень много людей, который чуствуют себя «на своей волне» и пытаются убедить собеседника, что «я — д'Артаньян, а все — п......», что неплохо иллюстрирут личность.
Другое дело, что да, интересно как поведет себя человек в нестандартной для него ситуации.
А вот по поводу дискуссии, человеку комфортнее общаться на тематику, которая ему близка, и по тому, как он об этом говорит, можно судить и о личности. Потому что знаю очень много людей, который чуствуют себя «на своей волне» и пытаются убедить собеседника, что «я — д'Артаньян, а все — п......», что неплохо иллюстрирут личность.
Другое дело, что да, интересно как поведет себя человек в нестандартной для него ситуации.
> Потому что знаю очень много людей, который чуствуют себя «на своей волне» и пытаются убедить собеседника, что «я — д'Артаньян, а все — п......», что неплохо иллюстрирут личность.
Самое обидное что иногда бывает, что все п… :) Но редко. :)
Самое обидное что иногда бывает, что все п… :) Но редко. :)
Поэтому и надо провоцировать его меньше говорить и больше задавать вопросы.
По уровню вопросов легко понять уровень компетенции.
По уровню вопросов легко понять уровень компетенции.
Ну личностный портрет свой не изменишь, а вот как «Надо понять, в курсе ли человек че это такое и как это работает»?
Да, такой подход реально работает. Расскажу из собственного опыта.
Работая преподавателем часто замечал следующую странную особенность. Никто из студентов не может задать себе вопрос. Абсолютно неспособны! Сценарий обычно следующий… Студент чего то там отвечает, но так себе. Но ему же хочется поставить четыре. Прошу задать вопрос самому себе. После этого студент впадает просто в ступор. Мало того что он не может сформулировать вопрос, он даже его придумать не может. Хотя я разрешаю задавать вопросы самому себе абсолютно любые, но на IT тематику.
Как то собеседовал парня на работу. И тоже предложил задать самому себе вопрос. И все, человек замолчал и скуксился. :)
И скажу так. Из собственного опыта замечено, если человек не в теме, он не задаст вопроса. Если человек не может мыслить, он не задаст вопроса. Если человек загнал свое мышление в рамки и не может из них выйти, он не задаст вопроса. Вот и получается, а нужен ли нам такой кандидат?..
А еще я часто придираюсь к постановке вопроса. Например спросит студент что такое наследование. И начинает отвечать про наследование в рамках ООП. А я скажу что он не прав. Из его вопроса я понял что он хочет рассказать про наследование в рамках генетики. :) Может быть не честно, но после этого они учатся задавать вопросы правильно, правильно формулировать свои мысли.
Работая преподавателем часто замечал следующую странную особенность. Никто из студентов не может задать себе вопрос. Абсолютно неспособны! Сценарий обычно следующий… Студент чего то там отвечает, но так себе. Но ему же хочется поставить четыре. Прошу задать вопрос самому себе. После этого студент впадает просто в ступор. Мало того что он не может сформулировать вопрос, он даже его придумать не может. Хотя я разрешаю задавать вопросы самому себе абсолютно любые, но на IT тематику.
Как то собеседовал парня на работу. И тоже предложил задать самому себе вопрос. И все, человек замолчал и скуксился. :)
И скажу так. Из собственного опыта замечено, если человек не в теме, он не задаст вопроса. Если человек не может мыслить, он не задаст вопроса. Если человек загнал свое мышление в рамки и не может из них выйти, он не задаст вопроса. Вот и получается, а нужен ли нам такой кандидат?..
А еще я часто придираюсь к постановке вопроса. Например спросит студент что такое наследование. И начинает отвечать про наследование в рамках ООП. А я скажу что он не прав. Из его вопроса я понял что он хочет рассказать про наследование в рамках генетики. :) Может быть не честно, но после этого они учатся задавать вопросы правильно, правильно формулировать свои мысли.
Да, вероятно именно так следует обобщить идею топика: нужно так или иначе проверять умение задавать вопросы по теме.
Умение задавать такие вопросы характеризует как свободное владение контекстом, так и личностные качества кандидата.
А проведение зеркального интервью — это один из способов такой проверки.
Спасибо.
Умение задавать такие вопросы характеризует как свободное владение контекстом, так и личностные качества кандидата.
А проведение зеркального интервью — это один из способов такой проверки.
Спасибо.
Я бы от такого предложения точно растерялся.
Дело тут вот в чём. Я могу назадавать себе кучу вопросов, но не вижу в этом смысла.
Зачем задавать себе вопрос, ответ на который я и так знаю? Это глупо с моей точки зрения.
Зачем задавать себе вопрос, ответ на который я не знаю? Вообще-то, это полезно :), но в _данной_ ситуации это будет выглядеть архиглупо с точки зрения собеседующего :).
Следовательно, задача состоит примерно в следующем (простите за каламбурчик): нужно задать такой вопрос, который был бы не совсем простым, но с известным мне ответом/решение, потом прикинуться, что ответ не то чтобы совсем не известен, но известен лишь путь к нему. Потом пройти по этому пути, желательно «случайно» завернув в пару очевидных тупичков, благополучно из них выбраться, объяснив почему это были тупички, а потом «внезапно» удачно «найти» правильное решение.
В глазах собеседователя, думаю, в этом случае, я буду выглядеть мегареспектабельно. НО! Во-первых, довольно сложно быстро и без подготовки провернуть такую блестящую комбинацию, а во-вторых, кого вы хотите получить себе в работники в случае если кандидат всё это проделает на ваших глазах? Ловкого и скользкого проходимца, могущего мгновенно в условиях стресса эффектно и эффективно декорировать макаронными изделиями внешние слуховые органы собеседника? Мы точно говорим о вакансии программиста? :)
Дело тут вот в чём. Я могу назадавать себе кучу вопросов, но не вижу в этом смысла.
Зачем задавать себе вопрос, ответ на который я и так знаю? Это глупо с моей точки зрения.
Зачем задавать себе вопрос, ответ на который я не знаю? Вообще-то, это полезно :), но в _данной_ ситуации это будет выглядеть архиглупо с точки зрения собеседующего :).
Следовательно, задача состоит примерно в следующем (простите за каламбурчик): нужно задать такой вопрос, который был бы не совсем простым, но с известным мне ответом/решение, потом прикинуться, что ответ не то чтобы совсем не известен, но известен лишь путь к нему. Потом пройти по этому пути, желательно «случайно» завернув в пару очевидных тупичков, благополучно из них выбраться, объяснив почему это были тупички, а потом «внезапно» удачно «найти» правильное решение.
В глазах собеседователя, думаю, в этом случае, я буду выглядеть мегареспектабельно. НО! Во-первых, довольно сложно быстро и без подготовки провернуть такую блестящую комбинацию, а во-вторых, кого вы хотите получить себе в работники в случае если кандидат всё это проделает на ваших глазах? Ловкого и скользкого проходимца, могущего мгновенно в условиях стресса эффектно и эффективно декорировать макаронными изделиями внешние слуховые органы собеседника? Мы точно говорим о вакансии программиста? :)
> НО! Во-первых, довольно сложно быстро и без подготовки провернуть такую блестящую комбинацию, а во-вторых, кого вы хотите получить себе в работники в случае если кандидат всё это проделает на ваших глазах? Ловкого и скользкого проходимца, могущего мгновенно в условиях стресса эффектно и эффективно декорировать макаронными изделиями внешние слуховые органы собеседника?
Да вы знаете, если такой будет, и он это сделает мастерски, то мне нужен такой программист! :) Честно! Таких быстро принимающих решения и быстро находящих пути решения людей я не встречал. :)
> Дело тут вот в чём. Я могу назадавать себе кучу вопросов, но не вижу в этом смысла. Зачем задавать себе вопрос, ответ на который я и так знаю? Это глупо с моей точки зрения.
Вы будете удивлены, но фишка скорее не в том как вы ответите, а что вы спросите и как. :) А если вы можете задать себе кучу вопросов то разве это не проверка ваших знаний?:)
Да вы знаете, если такой будет, и он это сделает мастерски, то мне нужен такой программист! :) Честно! Таких быстро принимающих решения и быстро находящих пути решения людей я не встречал. :)
> Дело тут вот в чём. Я могу назадавать себе кучу вопросов, но не вижу в этом смысла. Зачем задавать себе вопрос, ответ на который я и так знаю? Это глупо с моей точки зрения.
Вы будете удивлены, но фишка скорее не в том как вы ответите, а что вы спросите и как. :) А если вы можете задать себе кучу вопросов то разве это не проверка ваших знаний?:)
Уточню! Кучу вопросов по теме! :)
>Да вы знаете, если такой будет, и он это сделает мастерски, то мне нужен такой программист! :)
Он ведь будет так же мастерски вешать вам лапшу по поводу сроков, по поводу почему не сделано задание и тд и тп. А как эти качества помогут ему разрабатывать программы — ума не приложу.
>Таких быстро принимающих решения и быстро находящих пути решения людей я не встречал. :)
Ай, да ладно! Любой человек, отслуживший в армии, может лепить сорок бочек арестантов отмазок по любому поводу в любое время дня и ночи :).
Опять же, зачем вам такой человек в качестве программиста? Вы разрабатываете на скорость? :) В ведении переговоров, то да, а так…
>А если вы можете задать себе кучу вопросов то разве это не проверка ваших знаний?:)
Ещё раз — я не вижу смысла задавать себе вопросы про которые знаю, что я на них заранее знаю ответы. Ну глупо же!
Он ведь будет так же мастерски вешать вам лапшу по поводу сроков, по поводу почему не сделано задание и тд и тп. А как эти качества помогут ему разрабатывать программы — ума не приложу.
>Таких быстро принимающих решения и быстро находящих пути решения людей я не встречал. :)
Ай, да ладно! Любой человек, отслуживший в армии, может лепить сорок бочек арестантов отмазок по любому поводу в любое время дня и ночи :).
Опять же, зачем вам такой человек в качестве программиста? Вы разрабатываете на скорость? :) В ведении переговоров, то да, а так…
>А если вы можете задать себе кучу вопросов то разве это не проверка ваших знаний?:)
Ещё раз — я не вижу смысла задавать себе вопросы про которые знаю, что я на них заранее знаю ответы. Ну глупо же!
> Ещё раз — я не вижу смысла задавать себе вопросы про которые знаю, что я на них заранее знаю ответы. Ну глупо же!
Даже если в этом есть смысл для слушающего, я бы тоже чувствовал себя глупо ))
Даже если в этом есть смысл для слушающего, я бы тоже чувствовал себя глупо ))
Ещё раз — я не вижу смысла задавать себе вопросы про которые знаю, что я на них заранее знаю ответы. Ну глупо же!
Навскидку, чтобы я задал придя на джуниора php-программиста и как бы принимая на работу кого-то вроде синьора или архитектора, заранее предупрежденный о такой засаде :) (если бы ответы совпадали с ожидаемыми и были лаконичными):
— Что за последний проект был?
— На какой платформе реализовали?
— Какая версия PHP?
— Использовали ли ООП?
— Зачем?
— Использовали ли новые фичи?
— Какие?
— Зачем?
— Разделяли ли логику?
— Как?
— Толстый или тонкий контроллер?
— Почему?
— Сколько ответственностей было у модели?
— Почему не одна?
— Почему ActiveRecord?
— Другие ORM рассматривали?
— Почему?
— Что за фреймворк?
— Другие варианты рассматривали?
— И почему этот?
— Шаблонизатор использовали?
— А почему нативный?
— Почему Мускул?
— А NoSQL рассматривали?
— Откуда инфу взяли?
— А не лучше ли было самим потестить?
— Почему ищите новую работу?
— Думаете у нас перспектив больше?
— Почему?
— А кэшировали ответы?
— Как?
— А почему на кэш СУБД забили?
— А инвалидация по логике?
— А пробовали или просто решили, что овчинка не стоит выделки?
— Кто решил, что 1 минута в самый раз?
— О, а почему?
— И думаете пользователь будет доволен, что своего коммента не видит?
— Шустрые у вас модераторы :) А сколько у нас собираетесь проработать?
— А инфляцию учитываете?
и т. д.
Ни на один из этих вопросов я точно ответа не знаю :)
Согласен с вами.
Будет много конфуза от такой атаки без предупреждения.
Непросто быстро перестроится на другой тип мышления и беседы.
Себе задавать вопросы как-то вообще глуповато, нужно хорошо думать и готовиться, чтобы это получилось интересно.
Будет много конфуза от такой атаки без предупреждения.
Непросто быстро перестроится на другой тип мышления и беседы.
Себе задавать вопросы как-то вообще глуповато, нужно хорошо думать и готовиться, чтобы это получилось интересно.
Я кандидат, мне предлагали сделать наоборот, и я задаю вопросы:
— Как Вы думаете, какие именно знания нужны для работы в этом проекте?
— Какой заработок Вас удовлетворяет?
— В каком команде Вы бы хотели работать?
С такими методами кандидат может узнать, что на самом деле потребуется от него работодателю, и в дальнейшем делать упор именно на эти факты. ИМХО, не очень эффективный метод.
— Как Вы думаете, какие именно знания нужны для работы в этом проекте?
— Какой заработок Вас удовлетворяет?
— В каком команде Вы бы хотели работать?
С такими методами кандидат может узнать, что на самом деле потребуется от него работодателю, и в дальнейшем делать упор именно на эти факты. ИМХО, не очень эффективный метод.
Я такие вопросы задаю всегда и без подобной методики. Первым делом я хочу узнать сколько будут платить, что для этого надо делать и с кем работать.
Нормальные вопросы, а что не так?
Сразу характеризуют вас как скорее бизнесмена или менеджера, чем программиста, что в некоторых случаях тоже полезно и нужно. Но большинство программистов начнут с программистских вопросов, а потом уже может быть и эти зададут.
Сразу характеризуют вас как скорее бизнесмена или менеджера, чем программиста, что в некоторых случаях тоже полезно и нужно. Но большинство программистов начнут с программистских вопросов, а потом уже может быть и эти зададут.
Обожаю HR-ов. Я конечно понимаю, что Вам не обязательно разбираться во всех тонкостях, но это решение — это прости верх идиотизма. А давайте вы еще будите просить испытуемых подметать пол, чтобы узнать, насколько человек сговорчивый.
ВАМ нужен этот специалист, ВЫ должны выяснить уровень знаний человека. На собеседование человек должен приходить готовым отвечать на вопросы, а не в истерике придумывать что бы спросить, чтобы не выглядеть идиотом.
Попросив провести собеседование вы получите 3-4 любимых вопроса, которые специалист мог услышать от друзей знакомых итд. У каждого айтишника всегда на слуху пара-тройка таких вопросов.
ВАМ нужен этот специалист, ВЫ должны выяснить уровень знаний человека. На собеседование человек должен приходить готовым отвечать на вопросы, а не в истерике придумывать что бы спросить, чтобы не выглядеть идиотом.
Попросив провести собеседование вы получите 3-4 любимых вопроса, которые специалист мог услышать от друзей знакомых итд. У каждого айтишника всегда на слуху пара-тройка таких вопросов.
Знания сами по себе, по-моему, мало какому работодателю нужны. Собеседование же это не экзамен.
> а не в истерике придумывать что бы спросить, чтобы не выглядеть идиотом.
Истерика возникает в том случае, если не знаешь что спросить => не погружен в предмет.
> Обожаю HR-ов. Я конечно понимаю, что Вам не обязательно разбираться во всех тонкостях, но это решение — это прости верх идиотизма.
Я не HR. Но мне кажется что подход не так уж и плох. Я думаю что только разбирающийся в теме человек может задавать вопросы => отличный способ найти разбирающего человека.
Истерика возникает в том случае, если не знаешь что спросить => не погружен в предмет.
> Обожаю HR-ов. Я конечно понимаю, что Вам не обязательно разбираться во всех тонкостях, но это решение — это прости верх идиотизма.
Я не HR. Но мне кажется что подход не так уж и плох. Я думаю что только разбирающийся в теме человек может задавать вопросы => отличный способ найти разбирающего человека.
> Истерика возникает в том случае, если не знаешь что спросить => не погружен в предмет.
Ох как это всегда правильно — не знаешь что спросить = не погружен в предмет.
> Я думаю что только разбирающийся в теме человек может задавать вопросы => отличный способ найти разбирающего человека.
Вопросы задавать может любой человек, а поставив перед IT-шником задачу, которую он не станет выполнять никогда по долгу своей службы, вы рискуете отсеять толковых специалистов и нанять к себе на работу людей, которые краем уха слышали о предмете и прочитали пару статей на википедии.
Ох как это всегда правильно — не знаешь что спросить = не погружен в предмет.
> Я думаю что только разбирающийся в теме человек может задавать вопросы => отличный способ найти разбирающего человека.
Вопросы задавать может любой человек, а поставив перед IT-шником задачу, которую он не станет выполнять никогда по долгу своей службы, вы рискуете отсеять толковых специалистов и нанять к себе на работу людей, которые краем уха слышали о предмете и прочитали пару статей на википедии.
Если что, я веб-разработчик, проектировщик и техлид, и выполняю функции HR-а лишь по мере надобности.
> Вопросы задавать может любой человек, а поставив перед IT-шником задачу, которую он не станет выполнять никогда по долгу своей службы
Вы про какую задачу? Я все таки думаю не про «задать вопрос». Если вы никогда не задавали вопросов, это как то странно.
Мне кажется вы как то поверхностно смотрите на задачу «задать вопрос». Это гораздо глубже чем может показаться на самом деле. Ведь то какой вопрос задаст кандидат покажет то, насколько глубоко он разбирается в вопросе. Согласитесь:
Вы про какую задачу? Я все таки думаю не про «задать вопрос». Если вы никогда не задавали вопросов, это как то странно.
Мне кажется вы как то поверхностно смотрите на задачу «задать вопрос». Это гораздо глубже чем может показаться на самом деле. Ведь то какой вопрос задаст кандидат покажет то, насколько глубоко он разбирается в вопросе. Согласитесь:
Чорд. Случайно отправил.
Согласитесь что задать правильно вопрос многого стоит. Ведь то, как программист задаст вопрос, во многом показывает как программист может ставить задачи перед собой и другими людьми. Фишка я думаю не столько в том насколько сложный вопрос он задаст. А фишка в совокупности нескольких факторов: как правильно задаст вопрос, насколько хорошо человек может собраться в непривычной для себя обстановке, насколько человек хорошо знает тему. Я думаю что можно найти еще какие то показатели.
Возможно вы считаете что стоит использовать только этот подход на собеседовании? Так это боже упаси. :) Необходимо подходить с разных сторон к человеку. Надо дать тестовое задание на незнакомой платформе, задать вопросы самому, попросить человека задать вопросы. В итоге вы сформируете перед собой некий портрет человека. И вот текущий инструмент весьма неплох. Я честно проверял. :) Инструмент позволит выяснить показатели человека сразу по нескольким пунктам, которые я описал выше. :)
Согласитесь что задать правильно вопрос многого стоит. Ведь то, как программист задаст вопрос, во многом показывает как программист может ставить задачи перед собой и другими людьми. Фишка я думаю не столько в том насколько сложный вопрос он задаст. А фишка в совокупности нескольких факторов: как правильно задаст вопрос, насколько хорошо человек может собраться в непривычной для себя обстановке, насколько человек хорошо знает тему. Я думаю что можно найти еще какие то показатели.
Возможно вы считаете что стоит использовать только этот подход на собеседовании? Так это боже упаси. :) Необходимо подходить с разных сторон к человеку. Надо дать тестовое задание на незнакомой платформе, задать вопросы самому, попросить человека задать вопросы. В итоге вы сформируете перед собой некий портрет человека. И вот текущий инструмент весьма неплох. Я честно проверял. :) Инструмент позволит выяснить показатели человека сразу по нескольким пунктам, которые я описал выше. :)
Заданый вопрос это конечно здорово, возможно что-то покажет, но мне кажется что этого слишком мало, чтобы судить о человеке.
Мне приходилось проводить несколько собеседований чтобы найти человека на свое место. Также мне пришлось проходить не одно собеседование.
Могу сказать вот что — были кандидаты, которые с первого взгляда были просто шикарны — хоть на следующий день сади за работу и он справиться и вопросы человек задавал толковые(в основном по обязанностям итд) то есть как работать человек представлял.
Но основным фактором был разговор о проектах в которых участвовал человек. Вспоминая себя на собеседовании я просил человека рассказать чем он занимался, что ему было интересно на прошлом месте работы. И когда человек начинал рассказывать мол я тут drdb настраивал, но не может объяснить зачем и почему, дальнейшие разговоры бессмысленны. Верно и обратное — человек, который общался с нашими HR-ами и не очень хорошо себя показал, сейчас работает на моем старом месте, тк он не только рассказал, что он делал и как он делал, но и смог толково объяснить почему и зачем. И да — мне пришлось это из него по началу долго и упорно выпытывать, и если бы я попросил его задать самому себе вопрос — это было бы довольно жалкое зрелище.
Я не говорю, что нельзя ставить такие задания, но мягко говоря — это не должно быть основой собеседования. Ну и естественно это все IMHO :)
Мне приходилось проводить несколько собеседований чтобы найти человека на свое место. Также мне пришлось проходить не одно собеседование.
Могу сказать вот что — были кандидаты, которые с первого взгляда были просто шикарны — хоть на следующий день сади за работу и он справиться и вопросы человек задавал толковые(в основном по обязанностям итд) то есть как работать человек представлял.
Но основным фактором был разговор о проектах в которых участвовал человек. Вспоминая себя на собеседовании я просил человека рассказать чем он занимался, что ему было интересно на прошлом месте работы. И когда человек начинал рассказывать мол я тут drdb настраивал, но не может объяснить зачем и почему, дальнейшие разговоры бессмысленны. Верно и обратное — человек, который общался с нашими HR-ами и не очень хорошо себя показал, сейчас работает на моем старом месте, тк он не только рассказал, что он делал и как он делал, но и смог толково объяснить почему и зачем. И да — мне пришлось это из него по началу долго и упорно выпытывать, и если бы я попросил его задать самому себе вопрос — это было бы довольно жалкое зрелище.
Я не говорю, что нельзя ставить такие задания, но мягко говоря — это не должно быть основой собеседования. Ну и естественно это все IMHO :)
Не забывайте что лучшее — враг хорошего,
и поиск идеального типа собеседования опасен надеждой на него как на волшебную палочку,
так же как и поиск человека со скилами значительно выше остальной команды.
На нем завяжется слишком много, и его уход будет очень болезненным.
и поиск идеального типа собеседования опасен надеждой на него как на волшебную палочку,
так же как и поиск человека со скилами значительно выше остальной команды.
На нем завяжется слишком много, и его уход будет очень болезненным.
UFO just landed and posted this here
Типа такого habrahabr.ru/blogs/hr/120642/?reply_to=3966351#comment_3962246 :-[
Sign up to leave a comment.
Идеальное собеседование?