Подумалось тут о таком формате технического интервью:
— выбирается опенсорс проект, который каким-то образом оноситьсяй к проекту. Например, используемый фреймворк
Вариант 1:
— в зависимости от пердполагаемого уровня кандидата или даем ему выбрать и/или предлагаем некоторый набор открытых багов/запрошенных фич
— скриншаринг/сидим за плечом и смотрим как он это делает
Вариант 2:
— в зависимости от пердполагаемого уровня кандидата или даем ему выбрать и/или предлагаем некоторый набор открытых пулреквестов
— просим сделать ревью
Вариант 3 = Вариант 1 + Вариант 2
Никаких ограничений по использованию гуглов и прочих стэковерфлоу естественно нет
Кажется что такое может относительно адекватно показывать на что способен кандидат.
Здравствуйте, Dziman, Вы писали:
D>Подумалось тут о таком формате технического интервью:
D>- выбирается опенсорс проект, который каким-то образом оноситьсяй к проекту. Например, используемый фреймворк
D>Вариант 1: D>- в зависимости от пердполагаемого уровня кандидата или даем ему выбрать и/или предлагаем некоторый набор открытых багов/запрошенных фич D>- скриншаринг/сидим за плечом и смотрим как он это делает
Мда, сидеть над душой и смотреть можно, если кандидат знает этот проект как свои 5 пальцев. И то это касается тривиальных вещей.
На одном из предыдущих мест работы обсуждался (в шутку, конечно же) вариант подбросить свои исходники конкурентам в качестве диверсии (чтобы они потеряли уйму бесценного времени в попытках разобраться в коде и тогда у них нарушится биологическое равновесия и они помрут от голода).
А ты хочешь устроить подобную диверсию на собеседовании в ограниченное время.
_____________________
С уважением,
Stanislav V. Zudin
хороший сценарий, если бизнес компании — делать ревью и придет человек который спит и видит как он что то ревьюит,главное не забывать об этом в вакансии рассказывать
Здравствуйте, raydac, Вы писали:
R>хороший сценарий, если бизнес компании — делать ревью и придет человек который спит и видит как он что то ревьюит,главное не забывать об этом в вакансии рассказывать
Слышится боль в этом сообщении. Что не так с кодревью?
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, Dziman, Вы писали:
D>>Подумалось тут о таком формате технического интервью:
D>>- выбирается опенсорс проект, который каким-то образом оноситьсяй к проекту. Например, используемый фреймворк
SVZ>Мда, сидеть над душой и смотреть можно, если кандидат знает этот проект как свои 5 пальцев. И то это касается тривиальных вещей.
Выделил ключевой момент. Т.е. если опыт работы с этим проектом есть, то и хотя бы некоторое понимание его должно быть.
SVZ>На одном из предыдущих мест работы обсуждался (в шутку, конечно же) вариант подбросить свои исходники конкурентам в качестве диверсии (чтобы они потеряли уйму бесценного времени в попытках разобраться в коде и тогда у них нарушится биологическое равновесия и они помрут от голода).
Соболезную. Это не нормально.
SVZ>А ты хочешь устроить подобную диверсию на собеседовании в ограниченное время.
И нет и да: см выше про то что опыт как бы уже есть
Здравствуйте, Dziman, Вы писали:
R>>хороший сценарий, если бизнес компании — делать ревью и придет человек который спит и видит как он что то ревьюит,главное не забывать об этом в вакансии рассказывать D>Слышится боль в этом сообщении. Что не так с кодревью?
Чтоб сделать грамотное ревью, надо разбираться в устройстве проекта, изменение в котором ты ревьювишь. Иначе ревьюверу прийдется по ходу ревью скакать по коду и разворачивать все возможные ветки вызовов функций.
Либо код для ревью должен быть настолько тривиально ревьювабельным, что вся затея теряет смысл.
Здравствуйте, raydac, Вы писали:
R>кодревью очень мутная субъективная тема
Можно конкретные примеры мутности? Ну и вообще: для чего на твой взгляд нужен ревью?
Здравствуйте, John1979, Вы писали:
J>Здравствуйте, Dziman, Вы писали:
R>>>хороший сценарий, если бизнес компании — делать ревью и придет человек который спит и видит как он что то ревьюит,главное не забывать об этом в вакансии рассказывать D>>Слышится боль в этом сообщении. Что не так с кодревью?
J>Чтоб сделать грамотное ревью, надо разбираться в устройстве проекта, изменение в котором ты ревьювишь. Иначе ревьюверу прийдется по ходу ревью скакать по коду и разворачивать все возможные ветки вызовов функций. J>Либо код для ревью должен быть настолько тривиально ревьювабельным, что вся затея теряет смысл.
Оценивать нужно не только и не столько конечный резльтат ревью, сколько его процесс
Вроде все здраво, но:
D>- скриншаринг/сидим за плечом и смотрим как он это делает
Вот реально мне интересно, зачем?
У вас только парное программирование? Пускай как хочет — так и делает, меня лично очень раздражает, когда начинают заниматься микроменеджметом надо мной.
Здравствуйте, Dziman, Вы писали:
D>Подумалось тут о таком формате технического интервью:
D>- выбирается опенсорс проект, который каким-то образом оноситьсяй к проекту. Например, используемый фреймворк D>- в зависимости от пердполагаемого уровня кандидата или даем ему выбрать и/или предлагаем некоторый набор открытых багов/запрошенных фич
То есть я, как кандидат, должен потратить дофига времени чтобы въехать в какой-то новый для меня проект, а потом написать в нем полезный для вас функционал?
D>- просим сделать ревью
То есть я, как кандидат, должен потратить три раза по дофига времени, чтобы получить знания о проекте, достаточное для проведения ревью?
Вы издеваетесь, или действительно считаете это хорошими способами?
Распечатайте небольшой относительно изолированный фрагмент _говнокода_, и дайте его человеку со словами "как вы собираетесь это рефакторить"
Через 5 минут общения получите массу информации. Это много быстрее и результативнее, чем заставлять человека че-то там пул-реквестить.
Здравствуйте, Dziman, Вы писали: D>Подумалось тут о таком формате технического интервью:
что касается проверки человека проводить ревью (что мне кажется очень правильно и важно), то я бы лично подходил так, если бы мне поручили такое организовать
— взля бы пример опенсорсного кода, попросил бы текущих сотрудников компании сделать ему ревью.
— собрал бы просто статистику "проблемных" строк кода и заодно бы посмотрел не распадаются ли решения на кластеры. типа, новичик отмечают одни строки, опытные уже друие или куда больше.
— дал бы задачу провести ревью человеку уже. просто прогнал бы его ответы оп статистике, посмотрел чему и кому его ответы соотвествуют. дополнительно бы смотрел на его комменты к каждой строке, сообенно в случае необынчх результатов.