Тут периодически обсуждается как надо *правильно* проводить интервью. Честно говоря, я просто не уверен, что *правильное* интервью вобще возможно. Последний пример из личной практики.

Несколько месяцев назад взял двух товарищей. Первый на интервью показал себя очень хорошо, т.е. правильно ответил почти на все вопросы, быстро и правильно написал маленькую тестовую задачку (даем прямо на интервью написать на ручкой на бумаге).

Второй был так себе. На некоторые вопросы отвечал типа — не знаю, не помню, или давно этим не занимался. Задачку написал с ошибкой (не принципиальной, но все же). Вобщем, взяли только потому что позицию надо было заполнить очень срочно, а другие кандидаты были еще хуже.

Что имеем сейчас. С первым — постоянные проблемы. Что ему не поручишь — он прибегает и жалуется, что по таким-то и таким-то причинам он это сделать не может. Причем сам даже не пытается эти проблемы решить. Доходит до смешного. Ему поручили добавить некоторую функциональность в давно существовавшую утилиту. Он пожаловался, что утилита не собирается. Оказалось, что расположение хедеров в конфигурации проекта и в реальности не совпадают, но человек даже не пытался с этим разобраться, т.е. просто пишет, типа работать не могу — ничего не собирается. Второй товарищ звезд с неба может и не хватает, но абсолютно все поставленные задачи решает без проблем. Еще интересно, что мимо первого товарища проходишь — у него на экране монитора всегда или окошка чата, или какой-то сайт не относящийся к работе. У второго на экране всегда код, терминальное окошко и т.п.

Выводы? да собственно никаких.

Здравствуйте, justinian, Вы писали:

J>Выводы? да собственно никаких.

Первый — профессионал по трудоустройству, второй — по разработке

Здравствуйте, justinian, Вы писали:

J>Второй был так себе. На некоторые вопросы отвечал типа — не знаю, не помню, или давно этим не занимался. Задачку написал с ошибкой (не принципиальной, но все же).
J>Второй товарищ звезд с неба может и не хватает, но абсолютно все поставленные задачи решает без проблем.
J>Выводы? да собственно никаких.

Точно, с выводами тяжело... Иначе мы не женились бы во второй раз )).

..со временем стал ловить себя на мысли, что если на интервью человек нравится — жди проблем. И если не нравится — тоже самое. Был коллега, имхо замечательный плюс-программер, дык он из тех, кто на интервью на вопрос девочки-хаера "Знаете С++?" — подумает-подумает, и скажет "Нет", потому что это строгий ответ )).

Здравствуйте, justinian, Вы писали:

J>Второй был так себе. На некоторые вопросы отвечал типа — не знаю, не помню, или давно этим не занимался. Задачку написал с ошибкой (не принципиальной, но все же). Вобщем, взяли только потому что позицию надо было заполнить очень срочно, а другие кандидаты были еще хуже.

Этого точно надо брать.

J>Второй товарищ звезд с неба может и не хватает, но абсолютно все поставленные задачи решает без проблем.

Если понадобится этот и бога за бороду ухватит.

J>Еще интересно, что мимо первого товарища проходишь — у него на экране монитора всегда или окошка чата, или какой-то сайт не относящийся к работе.

В отдельности это еще не показатель. Но в совокупности с предыдущим описанием повод подумать о ценности его.

Здравствуйте, justinian, Вы писали:

J>Что имеем сейчас. С первым — постоянные проблемы. Что ему не поручишь — он прибегает и жалуется, что по таким-то и таким-то причинам он это сделать не может. Причем сам даже не пытается эти проблемы решить.

Проблемы с ТЗ?

J>Доходит до смешного. Ему поручили добавить некоторую функциональность в давно существовавшую утилиту. Он пожаловался, что утилита не собирается. Оказалось, что расположение хедеров в конфигурации проекта и в реальности не совпадают, но человек даже не пытался с этим разобраться, т.е. просто пишет, типа работать не могу — ничего не собирается.

В репозитарии не должно быть не компилябельного кода.

J>Второй товарищ звезд с неба может и не хватает, но абсолютно все поставленные задачи решает без проблем. Еще интересно, что мимо первого товарища проходишь — у него на экране монитора всегда или окошка чата, или какой-то сайт не относящийся к работе. У второго на экране всегда код, терминальное окошко и т.п.

Xмм... Может он на простых задачах работает у вас на пределе своих сил?

J>Выводы? да собственно никаких.

Думаю что первый проработал долгое время в компании где очень хорошо были отлажены процессы разработки, а у вас нужно еще порядок наводить своими силами.

Здравствуйте, justinian, Вы писали:

J>Выводы? да собственно никаких.
ну почему — собеседование научились проходить, осталось научиться проводить.

Здравствуйте, justinian, Вы писали:

J>Тут периодически обсуждается как надо *правильно* проводить интервью. Честно говоря, я просто не уверен, что *правильное* интервью вобще возможно. Последний пример из личной практики.

Кем обсуждается? Работниками? Некоторые вообще думают что резюме и получасовая беседа при “грамотной постановке” могут заменить и испытательный срок и все-все-все.

J>Выводы?
Искать нужно людей способных решать проблемы.
Вы имхо искали способных писать код. Что искали, то собственно и нашли.

Здравствуйте, UA, Вы писали:

UA>Здравствуйте, justinian, Вы писали:

J>>Что имеем сейчас. С первым — постоянные проблемы. Что ему не поручишь — он прибегает и жалуется, что по таким-то и таким-то причинам он это сделать не может. Причем сам даже не пытается эти проблемы решить.

UA>Проблемы с ТЗ?

У одного?

J>>Доходит до смешного. Ему поручили добавить некоторую функциональность в давно существовавшую утилиту. Он пожаловался, что утилита не собирается. Оказалось, что расположение хедеров в конфигурации проекта и в реальности не совпадают, но человек даже не пытался с этим разобраться, т.е. просто пишет, типа работать не могу — ничего не собирается.

UA>В репозитарии не должно быть не компилябельного кода.

Оно-то так. Но это не повод не разбираться с возникшими проблемами.

J>>Выводы? да собственно никаких.

UA>Думаю что первый проработал долгое время в компании где очень хорошо были отлажены процессы разработки, а у вас нужно еще порядок наводить своими силами.

Не стоит бросаться словами про "процессы разработки". Потому что эти процессы могут быть сильно разными.

03.11.2010 9:49, justinian пишет:
> Несколько месяцев назад взял двух товарищей. Первый на интервью показал
> себя очень хорошо, т.е. правильно ответил почти на все вопросы, быстро и
> правильно написал маленькую тестовую задачку (даем прямо на интервью
> написать на ручкой на бумаге).
>
> Второй был так себе. На некоторые вопросы отвечал типа — не знаю, не
> помню, или давно этим не занимался. Задачку написал с ошибкой (не
> принципиальной, но все же). Вобщем, взяли только потому что позицию надо
> было заполнить очень срочно, а другие кандидаты были еще хуже.
>
> Выводы? да собственно никаких.
А зря. Тут уже не раз писали о полной бессмысленности (если нужно найти
человека, который будет хорошо работать) твоего первого варианта. По
сути необходимо спрашивать что человек раньше делал, как и почему так? И
после принимать решение справится он с вашими задачами или нет.

03.11.2010 10:47, UA пишет:
> Xмм... Может он на простых задачах работает у вас на пределе своих сил?
>
> J>Выводы? да собственно никаких.
>
> Думаю что первый проработал долгое время в компании где очень хорошо
> были отлажены процессы разработки, а у вас нужно еще порядок наводить
> своими силами.
Круто. А знаю, что телепалка тут у всех развита, но чтобы до такой
степени — ты меня потряс.

03.11.2010 10:53, Кодёнок пишет:

> Кем обсуждается? Работниками? Некоторые вообще думают что резюме и
> получасовая беседа при “грамотной постановке” могут заменить и
> испытательный срок и все-все-все.
Да не. Тут многие думают, что собеседование в виде 3 экзаменов по
пол-дня каждый могут заменить и испытательный срок и все-все-все.

Здравствуйте, UA, Вы писали:

UA>В репозитарии не должно быть не компилябельного кода.

и дело разработчика поправить этот момент, разве нет

Здравствуйте, justinian, Вы писали:

J>даем прямо на интервью написать на ручкой на бумаге

Один из самых раздражающих приемов интервьюеров. Мой совет — дайте ноут пусть хоть с голым нотепадом.

Здравствуйте, Donz, Вы писали:

J>>даем прямо на интервью написать на ручкой на бумаге

D>Один из самых раздражающих приемов интервьюеров. Мой совет — дайте ноут пусть хоть с голым нотепадом.

Хум, как говорится, хау.
Мне, например, с бумагой и ручкой лучше думается.
К компу надо подходить с готовым решением. Но это лично моё ИМХО.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>К компу надо подходить с готовым решением.

...с уже скомпилирванным?

PS извини, ничего личного, просто не могу удержаться

Здравствуйте, justinian, Вы писали:

J>Что имеем сейчас. С первым — постоянные проблемы. Что ему не поручишь — он прибегает и жалуется, что по таким-то и таким-то причинам он это сделать не может.

Да, ситуевина знакомая — такого товарища недавно сами уволили. В начале работы в конторе рвал зад, работал неплохо, но потом че-то видать посчитал, что подобрал ключик к основным людям со стороны клиента и началась звздная болезнь, плюс все та же фигня: 75% тасков, которые ему давались, были очень грамотно слиты — и типа вроде ресерч провел, и покопался, и туда и сюда,ну и вобщем вывод такой что сделать не удасться... Правда потом вскрылась, когда я сам начал разгредать его таски, а также когда его таски передали другому челу. Короче пришлось расстрелять, хотя — видит бог — у нас тут вся контора вокруг него почти 5 месяцев танцевала, уговаривали быть поактивнее...

Здравствуйте, justinian, Вы писали:

моё имхо:
думаю второй разработчик просто более приспособлен к работе в бардаке чем первый.
всё наверное будет ещё проще если вы напишете где и кто из них до вас работал.
полагаю что первый работал больше в софт конторах, где нормально поставлен процесс и нет таких косяков что не собирается проект из репозитария и т д.
а вот второй больше по системным интеграторам видать поработал и для него проблемы которые у вас — просто лёгкая прогулка по арбату.
в связи с этим я могу сделать такие выводы:вы — системный интегратор и первый чел к вам просто случайно попал. А вот второй товарищ — ваш клиент и будет работать.

Здравствуйте, Unhandled_Exception, Вы писали:

U_E>и дело разработчика поправить этот момент, разве нет

Если он хочет заниматься этим постоянно, то да. Более эффективная стратегия: пнуть того, кто закоммитил несобирающийся код. Тогда в следующий раз тот будет проверять прежде чем коммитить.

J>Выводы? да собственно никаких.
Может всё же надо что-то в консерватории подправить?

Здравствуйте, Vzhyk, Вы писали:

V>03.11.2010 9:49, justinian пишет:
>> Несколько месяцев назад взял двух товарищей. Первый на интервью показал
>> себя очень хорошо, т.е. правильно ответил почти на все вопросы, быстро и
>> правильно написал маленькую тестовую задачку (даем прямо на интервью
>> написать на ручкой на бумаге).
>>
>> Второй был так себе. На некоторые вопросы отвечал типа — не знаю, не
>> помню, или давно этим не занимался. Задачку написал с ошибкой (не
>> принципиальной, но все же). Вобщем, взяли только потому что позицию надо
>> было заполнить очень срочно, а другие кандидаты были еще хуже.
>>
>> Выводы? да собственно никаких.
V>А зря. Тут уже не раз писали о полной бессмысленности (если нужно найти
V>человека, который будет хорошо работать) твоего первого варианта. По
V>сути необходимо спрашивать что человек раньше делал, как и почему так? И
V>после принимать решение справится он с вашими задачами или нет.

Да спрашиваь что раньше делал тоже не выход — есть профессиональные проходильщики собеседований (при чем, намного больше чем хороших программеров), которые тебе расскажут, что работали в НАСА и писали софт для хабблов и шатлов. На самом деле серебряной пули нет. Только грамотная оперативная работа. Каждого трекать, по каждому смотреть за всеми изменениями в его работе. Если наблюдается неприятная тенденция — поговорить, попросить исправить, но если чел из месяца в месяц только отмазки ищет — ну тут только расстрел.

>> Выводы? да собственно никаких.
V>А зря. Тут уже не раз писали о полной бессмысленности (если нужно найти
V>человека, который будет хорошо работать) твоего первого варианта. По
V>сути необходимо спрашивать что человек раньше делал, как и почему так? И
V>после принимать решение справится он с вашими задачами или нет.
+1
Человека на собеседовании оценивают по одним критериям, а на работе по другим. И после удивляются, а кого это мы набрали

Здравствуйте, Glоbus, Вы писали:

G>Да спрашиваь что раньше делал тоже не выход — есть профессиональные проходильщики собеседований (при чем, намного больше чем хороших программеров), которые тебе расскажут, что работали в НАСА и писали софт для хабблов и шатлов. На самом деле серебряной пули нет. Только грамотная оперативная работа. Каждого трекать, по каждому смотреть за всеми изменениями в его работе. Если наблюдается неприятная тенденция — поговорить, попросить исправить, но если чел из месяца в месяц только отмазки ищет — ну тут только расстрел.

грамотная оперативная работа — да. Но это потом, когда выбор уже сделан и ты уже теряешь время)). А до? Почему не попросить показать кусочек кода "для наса и хабблов"? То, что код чужой (есличо), выясняется на раз-два.

Все время вспоминаю анекдот, как жонглера принимали в цирк на работу... долго спрашивали что он умеет, но попросить пожонглировать забыли
Почему переводчика с французского просят покалякать по французски, а переводчика с русского на С++ зачастую даже не просят показать примеры перевода?

Здравствуйте, sumson, Вы писали:

S>думаю второй разработчик просто более приспособлен к работе в бардаке чем первый.
S>всё наверное будет ещё проще если вы напишете где и кто из них до вас работал.
S>полагаю что первый работал больше в софт конторах, где нормально поставлен процесс и нет таких косяков что не собирается проект из репозитария и т д.

Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

Здравствуйте, Skelterer, Вы писали:

S>Все время вспоминаю анекдот, как жонглера принимали в цирк на работу... долго спрашивали что он умеет, но попросить пожонглировать забыли
S>Почему переводчика с французского просят покалякать по французски, а переводчика с русского на С++ зачастую даже не просят показать примеры перевода?

Вообще-то просят. Часто дают небольшое задание по переводу чего-нибудь пустякового, что вызывает много отрицательных эмоций

Здравствуйте, ambel-vlad, Вы писали:

AV>Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

В мире эльфов есть только два типа контор: грамотные, где все пучком, и дерьмо всякое, где бардак. Наличие некомпилябельного кода в репозитории однозначно относит ее ко второй группе.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Skelterer, Вы писали:

S>>Все время вспоминаю анекдот, как жонглера принимали в цирк на работу... долго спрашивали что он умеет, но попросить пожонглировать забыли
S>>Почему переводчика с французского просят покалякать по французски, а переводчика с русского на С++ зачастую даже не просят показать примеры перевода?

Кё>Вообще-то просят. Часто дают небольшое задание по переводу чего-нибудь пустякового, что вызывает много отрицательных эмоций

не, я не про задания. Это действительно довольно спорный момент. Я про "показать то, что писал".

Здравствуйте, justinian, Вы писали:

J>Второй был так себе. На некоторые вопросы отвечал типа — не знаю, не помню, или давно этим не занимался.
хорошо, избавил и себя и вас от бесполезных вопросов. ну и +1 к честности.

J>Задачку написал с ошибкой (не принципиальной, но все же).
отлично. на мой взляд, надо было спросить, — "а примерно как это фиксить?". дискуссия же, а не просто отбрыкивание от вопросов...

Здравствуйте, ambel-vlad, Вы писали:

AV>Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

Это только мелкий звоночек.
[telepathy mode on]
1) некомпилирующийся код обнаружен случайно случайным человеком -> continious integration отсутствует
2) проблема оказалась в порядке библиотек -> сборочные скрипты отсутствуют
3) вопросы вызывают недоумение -> процесс интеграции новых разработчиков в команду отсутствует
[telepathy mode off]

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, Unhandled_Exception, Вы писали:

U_E>>и дело разработчика поправить этот момент, разве нет

M>Если он хочет заниматься этим постоянно, то да. Более эффективная стратегия: пнуть того, кто закоммитил несобирающийся код. Тогда в следующий раз тот будет проверять прежде чем коммитить.

Скрипты на билд-сервере должны пинать всех после неудачного автоматического билда после коммита на сервере.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, Donz, Вы писали:

J>>>даем прямо на интервью написать на ручкой на бумаге

D>>Один из самых раздражающих приемов интервьюеров. Мой совет — дайте ноут пусть хоть с голым нотепадом.

SVZ>Хум, как говорится, хау.
SVZ>Мне, например, с бумагой и ручкой лучше думается.
SVZ>К компу надо подходить с готовым решением. Но это лично моё ИМХО.

Ну тогда спросить перфокарты и дырокол.

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, Unhandled_Exception, Вы писали:

U_E>>и дело разработчика поправить этот момент, разве нет

M>Если он хочет заниматься этим постоянно, то да. Более эффективная стратегия: пнуть того, кто закоммитил несобирающийся код. Тогда в следующий раз тот будет проверять прежде чем коммитить.

Не нужно никого пинать всего лишь нужно настроить репозитарий так чтобы он комитил код когда пройдены все тесты: 1. Билд без ошибок (+ Code Analyser) 2. Пройдены все юнит тесты проекта. 3. Пройдено CodeReview

03.11.2010 11:57, Glоbus пишет:
> которые тебе расскажут, что работали в НАСА и писали софт
> для хабблов и шатлов.
Ну значит пойдут лесом, ибо что они тут делают.

А серебряная пуля — это твой жизненный опыт и твои знания.

03.11.2010 12:07, Skelterer пишет:
> Почему переводчика с французского просят покалякать по французски, а
> переводчика с русского на С++ зачастую даже не просят показать примеры
> перевода?
Проблема в том, что по малому объему кода понять что-то невозможно, а по
большому — это уже не тестик маленький. Кроме того, человек, проходящий
собеседование всегда в состоянии стресса, а из программеров очень
немногие могут писать что-то прилично в таком состоянии. Большинству
надо время и спокойная обстановка, на обдумать (у кого это 5 мин, у кого
4 часа).
А в ежедневной работе (если это не быстрое прототипирование уровня
президента) чаще "медленнодумы" нужны.

Здравствуйте, Skelterer, Вы писали:

S>не, я не про задания. Это действительно довольно спорный момент. Я про "показать то, что писал".
С этим тоже всё в порядке

Автор: Геннадий Ванин
Дата: 03.10.07

.

03.11.2010 11:57, Glоbus пишет:
> которые тебе расскажут, что работали в НАСА и писали софт
> для хабблов и шатлов.
Ну а если в самом деле чтото-то подобное делал, то для беседы идеальная
тема — пусть рассказывает.
Профессиональные проходильщики подобные темы не затронут, ибо пролетят.

Здравствуйте, Miroff, Вы писали:

AV>>Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

M>Это только мелкий звоночек.
M>[telepathy mode on]
M>1) некомпилирующийся код обнаружен случайно случайным человеком -> continious integration отсутствует

Возможно мимо. Зависит от того что это за утилита.

M>2) проблема оказалась в порядке библиотек -> сборочные скрипты отсутствуют

См. выше.

M>3) вопросы вызывают недоумение -> процесс интеграции новых разработчиков в команду отсутствует

Из слов топикстартера этого вывода не следует.

M>[telepathy mode off]

Здравствуйте, Кодёнок, Вы писали:

AV>>Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

Кё>В мире эльфов есть только два типа контор: грамотные, где все пучком, и дерьмо всякое, где бардак. Наличие некомпилябельного кода в репозитории однозначно относит ее ко второй группе.

Ну если только в мире эльфов. А в реальном мире зависит от утилитки. Если ее собрали черт знает сколько лет назад и спокойно пользуются. А через некоторое время про ее сорцы забыли до лучших времен. Ничего в этом ужасного нет.

Хотя в целом, подобных ситуаций стоит избегать.

03.11.2010 11:53, Glоbus пишет:
> Да, ситуевина знакомая — такого товарища недавно сами уволили. В начале
> работы в конторе рвал зад, работал неплохо, но потом че-то видать
> посчитал, что подобрал ключик к основным людям со стороны клиента и
> началась звздная болезнь, плюс все та же фигня: 75% тасков, которые ему
> давались, были очень грамотно слиты — и типа вроде ресерч провел, и
> покопался, и туда и сюда,ну и вобщем вывод такой что сделать не
> удасться... Правда потом вскрылась, когда я сам начал разгредать его
> таски, а также когда его таски передали другому челу. Короче пришлось
> расстрелять, хотя — видит бог — у нас тут вся контора вокруг него почти
> 5 месяцев танцевала, уговаривали быть поактивнее...
Мои поздравления.
И не раз же предупреждали здесь.

03.11.2010 12:19, Кодёнок пишет:
> В мире эльфов есть только два типа контор: грамотные, где все пучком, и
> дерьмо всякое, где бардак. Наличие некомпилябельного кода в репозитории
> однозначно относит ее ко второй группе.
Тогда понятно.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Skelterer, Вы писали:

S>>не, я не про задания. Это действительно довольно спорный момент. Я про "показать то, что писал".
S>С этим тоже всё в порядке

Автор: Геннадий Ванин
Дата: 03.10.07

.

ну, там мнения разделились. К тому же дискуссия 3-летней давности, а время идет и люди, рынок труда, и тп меняется.

Здравствуйте, Vzhyk, Вы писали:

V>03.11.2010 12:07, Skelterer пишет:
>> Почему переводчика с французского просят покалякать по французски, а
>> переводчика с русского на С++ зачастую даже не просят показать примеры
>> перевода?
V>Проблема в том, что по малому объему кода понять что-то невозможно, а по
V>большому — это уже не тестик маленький. Кроме того, человек, проходящий
V>собеседование всегда в состоянии стресса, а из программеров очень
V>немногие могут писать что-то прилично в таком состоянии. Большинству
V>надо время и спокойная обстановка, на обдумать (у кого это 5 мин, у кого
V>4 часа).
V>А в ежедневной работе (если это не быстрое прототипирование уровня
V>президента) чаще "медленнодумы" нужны.

я понял. Я плохо сформулирвоал вопрсо и примеры неудачны. Лично я не сторонник тестовых заданий и "напишите вот это прям щас побыстрому".

Я про "попросить код, который у вас есть". Не обязательно весь проект, достаточно кусок. Мысль, в том числе и здесь звучавшая — резюме и разговор не дают достаточного представления, неут серебряной пули. Всегда полагал, что если дать посмотреть код кандидата его будущему лиду (и/или коллегам), то мнение составится гораздо быстрее и точнее. При этом (имхо) совершенно необязательно код причесывать и приглаживать — достаточно посылку снабдить каментами "это так и так, потому что (писал в заданном стиле, писал не один, писал давно, и т.п.)", — те кто смотрят в код, не с луны же упали...

Почему этот подход так непопулярен?

Здравствуйте, Skelterer, Вы писали:

S>Почему этот подход так непопулярен?

Смотреть код не зная при каких параметрах {время, ресурсы, деньги} он создавался — смысла нету.

03.11.2010 14:00, Skelterer пишет:
>
> Я про "попросить код, который у вас есть". Не обязательно весь проект,
> достаточно кусок. Мысль, в том числе и здесь звучавшая — резюме и
> разговор не дают достаточного представления, неут серебряной пули.
> Всегда полагал, что если дать посмотреть код кандидата его будущему лиду
> (и/или коллегам), то мнение составится гораздо быстрее и точнее. При
> этом (имхо) совершенно необязательно код причесывать и приглаживать —
> достаточно посылку снабдить каментами "это так и так, потому что (писал
> в заданном стиле, писал не один, писал давно, и т.п.)", — те кто смотрят
> в код, не с луны же упали...
>
> Почему этот подход так непопулярен?
Где-то популярен, где-то нет.
По опыту достаточно бессмысленное занятие просить дать код или написать
по-быстрому какую фигню. Что можно увидеть по коду, отступы?
предпочитаемый им стиль? Ошибки сделанные человеком впопыхах?
Мне нужно другое:
хочет ли может человек учиться и искать нужную информацию;
как он относится к работе и качеству ее выполнения;
имеет ли он достаточную базу (специализация) в тех задачах, которые
предстоит ему выполнять.

Ну иногда имеет смысл дать задачку, напиши класс vector, string, но это
в первую очередь для людей с опытом меньше 2 лет.

Например, специализация — ИБД.

Здравствуйте, justinian, Вы писали:

J>Тут периодически обсуждается как надо *правильно* проводить интервью. Честно говоря, я просто не уверен, что *правильное* интервью вобще возможно. Последний пример из личной практики.

J>Несколько месяцев назад взял двух товарищей. Первый на интервью показал себя очень хорошо, т.е. правильно ответил почти на все вопросы, быстро и правильно написал маленькую тестовую задачку (даем прямо на интервью написать на ручкой на бумаге).

Выводы есть Эксперты искали эксперта и нашли эксперта

А надо было искать нормального человека, который сумеет вписаться в коллектив, будет играть по правилам, с которым удастся
установить отношения, В ТОМ ЧИСЛЕ и рабочие, то есть у него есть определенные знания языка и Вы в состоянии добиться от
него выполнения задач на нужном уровне.

Как это сделать, это уже другой вопрос Я не знаю

J>Выводы? да собственно никаких.

Здравствуйте, UA, Вы писали:

M>>Если он хочет заниматься этим постоянно, то да. Более эффективная стратегия: пнуть того, кто закоммитил несобирающийся код. Тогда в следующий раз тот будет проверять прежде чем коммитить.

UA>Не нужно никого пинать всего лишь нужно настроить репозитарий так чтобы он комитил код когда пройдены все тесты: 1. Билд без ошибок (+ Code Analyser) 2. Пройдены все юнит тесты проекта. 3. Пройдено CodeReview

4. Получено благословение Патриарха.

Здравствуйте, Кодёнок, Вы писали:

AV>>Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

Кё>В мире эльфов есть только два типа контор: грамотные, где все пучком, и дерьмо всякое, где бардак. Наличие некомпилябельного кода в репозитории однозначно относит ее ко второй группе.

Есть ещё третий тип, где ваще нет репозиториев.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Хум, как говорится, хау.
SVZ>Мне, например, с бумагой и ручкой лучше думается.

На вкус и цвет, как говорится. Но отказаться от ноута и взять ручку с бумагой ты можешь и сам, а вот отказаться от ручки с бумагой и взять ноут навряд ли получится, если он заранее не припасен в кустах.

Из плюсов ноута с нотепадом:
1)Можно проверить, умеет ли кандидат пользоваться командной строкой для сборки проекта
2)Повышается читабельность как интервьюером, так и самим кандидатом. Учитывая, что ручкой только расписываюсь, иногда даже цифры на бумаге получаются неоднозначными Ну и на бумаге сложнее черкать/исправлять.

Здравствуйте, Skelterer, Вы писали:

S>Я про "попросить код, который у вас есть".
экий вы странный, я вот десять лет почти в бизнесе, но ни одной строки которую можно показать у меня нет. политика партии не позволяет.

Здравствуйте, Donz, Вы писали:

D>1)Можно проверить, умеет ли кандидат пользоваться командной строкой для сборки проекта

Ты взаправду считаешь это крайне важным умением? Или просто так, привел в качестве примера первое, что пришло в голову?

D>2)Повышается читабельность как интервьюером, так и самим кандидатом. Учитывая, что ручкой только расписываюсь, иногда даже цифры на бумаге получаются неоднозначными Ну и на бумаге сложнее черкать/исправлять.

Читабельность действительно повышается, спору нет. Но тут надо знать, что интервьюеру интереснее — точный результат без помарок или ход твоих рассуждений.
Будь я на месте интервьюера, меня бы больше интересовало второе (наверное). Но т.к. я был только по одну сторону баррикады будет ли такая оценка полезной —

Здравствуйте, cvetkov, Вы писали:

C>Здравствуйте, Skelterer, Вы писали:

S>>Я про "попросить код, который у вас есть".
C>экий вы странный, я вот десять лет почти в бизнесе, но ни одной строки которую можно показать у меня нет. политика партии не позволяет.

Ну, можно 1 раз потратить 4 часа времени на написание простенькой программки, которая решает какую-то четко поставленную задачу (пусть бесполезную, не важно)
Полученный образец кода будет даже лучше фрагмента из реальной внедренной системы, потому как во втором случае оценить код будет мешать непонимание контекста и зачастую предметной области.

Здравствуйте, justinian, Вы писали:

J>Выводы? да собственно никаких.

Зато их есть у нас
Приходя на все свои контракты, первым делом мне приставлялся разработчик (чаще лид), который помогал поставить/настроить рабочую среду — рассказывал, где лежат необходимые дистрибы, настраивал scc, убеждался, что проект нормально собирается и работает. И причина этого предельно простая — новый разработчик самостоятельно проблемы может и решит, но это займёт куда больше времени, чем у кого-то, кто уже знает всю эту кухню, знает типовые грабли и т.п. А время контрактора ооочень недёшево... По той же причине нам при возникновении любых препятствий рабочему процессу сразу же обращаться к людям, которые знают, как их устранить. Потому что компании умеют считать деньги.
Видимо, первый человек привык работать в подобном окружении — признаться, к этому очень быстро привыкаешь. А второй привык работать в компаниях, где сразу после приёма работника оставляют с кодом один на один...

Здравствуйте, Donz, Вы писали:

D>Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>>Хум, как говорится, хау.
SVZ>>Мне, например, с бумагой и ручкой лучше думается.

D>На вкус и цвет, как говорится. Но отказаться от ноута и взять ручку с бумагой ты можешь и сам, а вот отказаться от ручки с бумагой и взять ноут навряд ли получится, если он заранее не припасен в кустах.
Это конечно да.

D>Из плюсов ноута с нотепадом:
D>1)Можно проверить, умеет ли кандидат пользоваться командной строкой для сборки проекта
сразу позникает два вопроса
а) вы что, (т.е. интервьювер) разрабатываете при помощи ноутпада? И билдите командной строкой?
б) я что, должен все константы помнить (С) ? Серьезно, я фигачу на Visual Studio, и не не помню как там и чего из командной строки запускать. Ну да, в одной книжке как-то читал про билд из командной строки. Почитал и потом забыл, ибо не юзал. В последующих книжках подобный раздел игнорировал. А когда надо было настроить автобилды — полез в гугль, понял что нужно, быстренько подобрал нужные параметры для MSBuild, один раз настроил и забыл.


D>2)Повышается читабельность как интервьюером, так и самим кандидатом. Учитывая, что ручкой только расписываюсь, иногда даже цифры на бумаге получаются неоднозначными Ну и на бумаге сложнее черкать/исправлять.

Повышается, только ноутпад такая же кустарщина как и бумажка.
Если уж дается ноут, почему бы там не открыть среду разработки?

Здравствуйте, Кодёнок, Вы писали:

Кё>Вообще-то просят. Часто дают небольшое задание по переводу чего-нибудь пустякового, что вызывает много отрицательных эмоций

Продолжая аналогию с переводчиком, я думаю, попросить перевести прям на собеседовании анекдот — и можно, и должно, и многое сразу о человеке говорит. Попросить же заранее перевести главу из Анны Карениной — это хамство.

Здравствуйте, Gradient, Вы писали:

G>Ну, можно 1 раз потратить 4 часа времени на написание простенькой программки, которая решает какую-то четко поставленную задачу (пусть бесполезную, не важно)
и когото действительно будет интересовать код написаный 3-5 лет назад?
не говоря уже о том что для написания такой програмы я должен обладать талантами которых у меня нет (и которые не нужны для позиции на которую я претендую).
Либо это будет нечто из серии крестики нолики которые покажут максимум как я называю переменные и форматирую код.

Зд0равствуйте, ambel-vlad, Вы писали:
J>>>Доходит до смешного. Ему поручили добавить некоторую функциональность в давно существовавшую утилиту. Он пожаловался, что утилита не собирается. Оказалось, что расположение хедеров в конфигурации проекта и в реальности не совпадают, но человек даже не пытался с этим разобраться, т.е. просто пишет, типа работать не могу — ничего не собирается.
UA>>В репозитарии не должно быть не компилябельного кода.
AV>Оно-то так. Но это не повод не разбираться с возникшими проблемами.

Сразу тупо брасаться в бой и решать проблему которой может и не быть — не всегда оптимальная стратегия. Имхо человек сделал правильно — сначало подошел к колегам и спросил что он делает нетак, вдруг там какую галочку или омцию надо было в студии поставить чтоб работать с этим проектом, вместо того чтоб сам просидеть молча полдня копая проект в попытках решить проблему.

Здравствуйте, ambel-vlad, Вы писали:
AV>Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

По двум факторам:
— в репозитории лежал некомпилябельный проект;
— Топикстартер считает это нормальным и ставит в вину тому кому поручили сделать правку в проекте, а не тому кто закомитил некомпилябильный проект.

Т.е. по тому что некомпилябильный проект в репозитории считается нормальным явлением и разбираться сним приходится тому кому непосчастливилось делать следующую правку, а не тому кто такое закомитил — таки да, вполне можно сделать вывод что в конторе в разработке бардак и хаос.

Здравствуйте, Donz, Вы писали:

D>Из плюсов ноута с нотепадом:
D>1)Можно проверить, умеет ли кандидат пользоваться командной строкой для сборки проекта
это можно просто спросить. тратить время на вылизывание до собирабельного состояния — не вижу смысла.

D>Ну и на бумаге сложнее черкать/исправлять.
имхо наоборот

Здравствуйте, Gradient, Вы писали:

G>а) вы что, (т.е. интервьювер) разрабатываете при помощи ноутпада? И билдите командной строкой?
я частенько собираю из командной строки, а что? вы так это говорите, как будто это что-то плохое. мир не уперся в VS.

G>б) я что, должен все константы помнить (С) ? Серьезно, я фигачу на Visual Studio, и не не помню как там и чего из командной строки запускать. Ну да, в одной книжке как-то читал про билд из командной строки.
так вот откуда потом берутся "программисты", которые в принципе не понимают, что программу можно собрать без VS (да, я дофига таких видел). начитаются тут...

Здравствуйте, Nik_1, Вы писали:

AV>>Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

N_>По двум факторам:
N_> — в репозитории лежал некомпилябельный проект;
N_> — Топикстартер считает это нормальным и ставит в вину тому кому поручили сделать правку в проекте, а не тому кто закомитил некомпилябильный проект.

ТС ставит в вину несколько иное. И судя по описанию других случаев проблема скорее все таки в том человеке.

Здравствуйте, Nik_1, Вы писали:

J>>>>Доходит до смешного. Ему поручили добавить некоторую функциональность в давно существовавшую утилиту. Он пожаловался, что утилита не собирается. Оказалось, что расположение хедеров в конфигурации проекта и в реальности не совпадают, но человек даже не пытался с этим разобраться, т.е. просто пишет, типа работать не могу — ничего не собирается.
UA>>>В репозитарии не должно быть не компилябельного кода.
AV>>Оно-то так. Но это не повод не разбираться с возникшими проблемами.

N_>Сразу тупо брасаться в бой и решать проблему которой может и не быть — не всегда оптимальная стратегия. Имхо человек сделал правильно — сначало подошел к колегам и спросил что он делает нетак, вдруг там какую галочку или омцию надо было в студии поставить чтоб работать с этим проектом, вместо того чтоб сам просидеть молча полдня копая проект в попытках решить проблему.

И так надцать раз. Почему, судя по описанию, у других подобных проблем не возникает?

Здравствуйте, ambel-vlad, Вы писали:
AV>И так надцать раз. Почему, судя по описанию, у других подобных проблем не возникает?
Привыкли к пордаку в этой конторе и хорошо внем ориентируются Он же человек новый, к месным реалям и традициям не превык еще, посему пытался решать проблемы привычным способом как это было в других конторах.
Я ни в коем случаи не утверждаю что он хороший разработчик, мож он действительно некудышний. Просто топикстартер привел всего один пример и именно в этом примере по моему мнению был прав работник. Поэтому инфы чтоб делать какие-либо выводы пока недостаточно, вдруг в остальных "надцать раз" так же все весьма неоднозначно.

Здравствуйте, Nik_1, Вы писали:

AV>>И так надцать раз. Почему, судя по описанию, у других подобных проблем не возникает?
N_>Привыкли к пордаку в этой конторе и хорошо внем ориентируются Он же человек новый, к месным реалям и традициям не превык еще, посему пытался решать проблемы привычным способом как это было в других конторах.

N_>Я ни в коем случаи не утверждаю что он хороший разработчик, мож он действительно некудышний. Просто топикстартер привел всего один пример и именно в этом примере по моему мнению был прав работник.

Вообще-то ТС говорил и о других случаях. А насчет бардака, то как раз ты по одному случаю делаешь вывод о наличии бардака.

Здравствуйте, ambel-vlad, Вы писали:

AV>Здравствуйте, Nik_1, Вы писали:

AV>>>И так надцать раз. Почему, судя по описанию, у других подобных проблем не возникает?
N_>>Привыкли к пордаку в этой конторе и хорошо внем ориентируются Он же человек новый, к месным реалям и традициям не превык еще, посему пытался решать проблемы привычным способом как это было в других конторах.

N_>>Я ни в коем случаи не утверждаю что он хороший разработчик, мож он действительно некудышний. Просто топикстартер привел всего один пример и именно в этом примере по моему мнению был прав работник.

AV>Вообще-то ТС говорил и о других случаях.
Ну вот пусть приведет пример расписав в как было дело в другом случии, а то вдруг они такие же как и приведенный.

AV>А насчет бардака, то как раз ты по одному случаю делаешь вывод о наличии бардака.

Как я написал в соседней подветке, такой вывод я сделал не из-за того что случилось один раз "в репозитории оказался несобирающийся проект", а по тому как отреагировали на этот инцидент и какое отношение кнему. Подход "то что проект не собирается это проблемы того кому непосчастливилось делать следующую правку, а не того кто закомитил кривые изменения" говорит не в пользу данной команды разработчиков.

J>Выводы? да собственно никаких.

Зря. Помимо профессиональных вещей имеет смысл смотреть подходит ли человек Вашей компании, в этом случае или не проверяли или ошиблись. Если компания устроена так что человек сам должен быть активным и пинать других если что-то застопорилось, то имеет смысл не брать даже умныхисуперпрофессиональных, если они пассивны.

Здравствуйте, UA, Вы писали:

UA>Здравствуйте, Skelterer, Вы писали:

S>>Почему этот подход так непопулярен?

UA>Смотреть код не зная при каких параметрах {время, ресурсы, деньги} он создавался — смысла нету.

Кто-то плюсов поставил, кто-то минусов.
+/-
С одной стороны верно, а с другой стороны обычно, когда просят код, присылают самый лучший ))

G>Да, ситуевина знакомая — такого товарища недавно сами уволили. В начале работы в конторе рвал зад, работал неплохо, но потом че-то видать посчитал, что подобрал ключик к основным людям со стороны клиента и началась звздная болезнь, плюс все та же фигня: 75% тасков, которые ему давались, были очень грамотно слиты — и типа вроде ресерч провел, и покопался, и туда и сюда,ну и вобщем вывод такой что сделать не удасться... Правда потом вскрылась, когда я сам начал разгредать его таски, а также когда его таски передали другому челу. Короче пришлось расстрелять, хотя — видит бог — у нас тут вся контора вокруг него почти 5 месяцев танцевала, уговаривали быть поактивнее...

Надо было не таневать, а выразить ему свое "датысовсемохуел!", глядишь, и работать бы стал, увольнять не пришлось бы..

J>Тут периодически обсуждается как надо *правильно* проводить интервью. Честно говоря, я просто не уверен, что *правильное* интервью вобще возможно. Последний пример из личной практики.

J>Несколько месяцев назад взял двух товарищей. Первый на интервью показал себя очень хорошо, т.е. правильно ответил почти на все вопросы, быстро и правильно написал маленькую тестовую задачку (даем прямо на интервью написать на ручкой на бумаге).

J>Второй был так себе. На некоторые вопросы отвечал типа — не знаю, не помню, или давно этим не занимался. Задачку написал с ошибкой (не принципиальной, но все же). Вобщем, взяли только потому что позицию надо было заполнить очень срочно, а другие кандидаты были еще хуже.

J>Что имеем сейчас. С первым — постоянные проблемы. Что ему не поручишь — он прибегает и жалуется, что по таким-то и таким-то причинам он это сделать не может. Причем сам даже не пытается эти проблемы решить. Доходит до смешного. Ему поручили добавить некоторую функциональность в давно существовавшую утилиту. Он пожаловался, что утилита не собирается. Оказалось, что расположение хедеров в конфигурации проекта и в реальности не совпадают, но человек даже не пытался с этим разобраться, т.е. просто пишет, типа работать не могу — ничего не собирается. Второй товарищ звезд с неба может и не хватает, но абсолютно все поставленные задачи решает без проблем. Еще интересно, что мимо первого товарища проходишь — у него на экране монитора всегда или окошка чата, или какой-то сайт не относящийся к работе. У второго на экране всегда код, терминальное окошко и т.п.

J>Выводы? да собственно никаких.


Имхо, просто первый долбаеб, а как разработчик, может даже лучше второго ))
Вставьте первому по самое не хочу за такое, чтоб работал, и может, будет работать еще лучше второго ))

Здравствуйте, MishaSt, Вы писали:

MS>Кто-то плюсов поставил, кто-то минусов.
MS>+/-
MS>С одной стороны верно, а с другой стороны обычно, когда просят код, присылают самый лучший ))

По своему опыту могу сказать что красивый код может быть только во внешней обертке, а если спустится ниже туда где заоптимизированный код то там уже не до красоты кода.

Здравствуйте, Nik_1, Вы писали:
N_>Как я написал в соседней подветке, такой вывод я сделал не из-за того что случилось один раз "в репозитории оказался несобирающийся проект", а по тому как отреагировали на этот инцидент и какое отношение кнему. Подход "то что проект не собирается это проблемы того кому непосчастливилось делать следующую правку, а не того кто закомитил кривые изменения" говорит не в пользу данной команды разработчиков.
+1. У нас кто накоммитил некошерного в SVN — тот и смывает. Если не смылось — проталкивает рукой. Исключение только для старых проектов, которые юзают всё еще развивающиеся компоненты.

Здравствуйте, Nik_1, Вы писали:

AV>>>>И так надцать раз. Почему, судя по описанию, у других подобных проблем не возникает?
N_>>>Привыкли к пордаку в этой конторе и хорошо внем ориентируются Он же человек новый, к месным реалям и традициям не превык еще, посему пытался решать проблемы привычным способом как это было в других конторах.

N_>>>Я ни в коем случаи не утверждаю что он хороший разработчик, мож он действительно некудышний. Просто топикстартер привел всего один пример и именно в этом примере по моему мнению был прав работник.

AV>>Вообще-то ТС говорил и о других случаях.
N_>Ну вот пусть приведет пример расписав в как было дело в другом случии, а то вдруг они такие же как и приведенный.

Дык в примере с несобирающейся утилиткой ты сделал выводы о состоянии процессов. Если делать выводы по результатам сборки каких-то утилиток, то, боюсь, практически ни в одной компании процессы не налажены.

AV>>А насчет бардака, то как раз ты по одному случаю делаешь вывод о наличии бардака.

N_>Как я написал в соседней подветке, такой вывод я сделал не из-за того что случилось один раз "в репозитории оказался несобирающийся проект", а по тому как отреагировали на этот инцидент и какое отношение кнему. Подход "то что проект не собирается это проблемы того кому непосчастливилось делать следующую правку, а не того кто закомитил кривые изменения" говорит не в пользу данной команды разработчиков.

Во-первых, не проект не собирается. А утилитка. А это совсем другое.

Здравствуйте, Stanislav V. Zudin, Вы писали:

D>>1)Можно проверить, умеет ли кандидат пользоваться командной строкой для сборки проекта
SVZ>Ты взаправду считаешь это крайне важным умением? Или просто так, привел в качестве примера первое, что пришло в голову?

Не крайне важным, а просто важным. Если человек в состоянии подключить правильным способом нужные библиотеки и указать нужны параметры компиляции, то это означает, что он понимает такие базовые вещи, как настройка путей для сборки проекта, что библиотеки должны лежать отдельно, а не в общей кучи dll в том дефолтовом каталоге, откуда все это берет IDE, что осознает возможности самого компилятора, а не упирается в ограничения IDE, что он сможет сам написать тот же билд-скрипт, что при выходе новой версии крутейшей среды разработки он не будет бороться с новым ГУИ для настроек проекта, пытаясь в очередной раз осознать, что откуда берется, а в случае непреодолимой ограниченности IDE напишет билд-скрипт. Работа с консолью, по моему мнению, это очень важный навык. И для самой компиляции он действительно редко нужен (хотя я мелкие утилиты пишу в Фаре, а компилирую из командной строки — это быстрее, чем создание проекта в IDE), но для вспомогательных программ очень часто.

SVZ>Читабельность действительно повышается, спору нет. Но тут надо знать, что интервьюеру интереснее — точный результат без помарок или ход твоих рассуждений.

Теперь моя очередь задавать этот вопрос: ты взаправду считаешь, что кому-то может быть важно количество нажатий клавиши Backspace?

Здравствуйте, Gradient, Вы писали:

D>>1)Можно проверить, умеет ли кандидат пользоваться командной строкой для сборки проекта
G>сразу позникает два вопроса
G>а) вы что, (т.е. интервьювер) разрабатываете при помощи ноутпада? И билдите командной строкой?

Мелкие утилиты да. Это быстрее, чем создавать проект со всей требухой, которая по мнению IDE обязательна. Задачки на собеседовании обычно быстрорешаемые, так что вполне. Лично я бы предпочел Фар + Колорер, а от среды разработки, в которой не привык работать, отказался бы. Я не вижу смысл тратить время собеседования на осваивания навыков работы с конкретной IDE. Лучше я это время потрачу на выполнение предложенного задания.
И, как уже сказал выше, компиляция из командной строки покажет, понимает ли кандидат, что такое компиляция, как правильно подключить необходимые ресурсы, и что творится при запуске приложения (речь не только об exe файлах). Как минимум это гарантирует, что потенциальный работник не будет запихивать необходимые библиотеки в каталог bin среды разработки, а сможет их корректно подключить. А также, что его работа не встанет, если ему придется переходить на другую IDE, в которой он не сможет найти заветную кнопочку "Собрать и запустить проект и сделать его работающим".
Если брать конкретно Java, то чуть ли не половина вопросов новичков связана с полным непониманием, как подключаются пакеты, библиотеки и с полной путаницей в путях. Если брать J2ME, то ситуация еще хуже.

G>б) я что, должен все константы помнить (С) ? Серьезно, я фигачу на Visual Studio, и не не помню как там и чего из командной строки запускать. Ну да, в одной книжке как-то читал про билд из командной строки. Почитал и потом забыл, ибо не юзал. В последующих книжках подобный раздел игнорировал. А когда надо было настроить автобилды — полез в гугль, понял что нужно, быстренько подобрал нужные параметры для MSBuild, один раз настроил и забыл.

Не могу сказать про VS, но в Java компиляция приложения с простейшей задачкой — это вызов javac с одним параметром. Да, я действительно считаю, что это должен знать даже начинающий ява разработчик, как и запуск приложения из консоли.
А тебя бы не смутило, что кандидат-сишник не в курсе, что такое линковка, например?

G>Повышается, только ноутпад такая же кустарщина как и бумажка.
G>Если уж дается ноут, почему бы там не открыть среду разработки?

Чтобы быть уверенным в адекватности программиста, когда дело дойдет до реального проекта. Что он, например, не будет бегать и вопрошать, откуда столько ошибок после вызова сборщика проекта, хотя он, как и положено, положил недавно подключенную библиотеку в положенное место C:\MyIDE\bin или C:\Windows\System32.

Не знаю, может быть я очень категоричен, но слишком много проблем случалось из-за непонимания базовых вещей. А IDE как раз подталкивают программиста к забиванию на эти знания.

Здравствуйте, Antikrot, Вы писали:

D>>Из плюсов ноута с нотепадом:
D>>1)Можно проверить, умеет ли кандидат пользоваться командной строкой для сборки проекта
A>это можно просто спросить. тратить время на вылизывание до собирабельного состояния — не вижу смысла.

-Вы умеете работать с командной строкой?
-Да!
Так?
Какое время нужно для собирабельного состояния, если задачки на интервью максимум из трех-пяти классов? Я может слишком в яве задержался, но сколько телодвижений нужно сделать в сях, чтобы из консоли получить исполняемое приложение и запустить его?

Кстати, буквально недавно одного программиста обучал по телефону, как вставить данные из буфера обмена в консоль, и как сделать так, чтобы можно было посмотреть результат выполнения команды (у него окошко очень быстро закрывалось). К называнию консоли DOS'ом я уже почти привык.

Здравствуйте, Donz, Вы писали:

D>Не крайне важным, а просто важным. Если человек в состоянии подключить правильным способом нужные библиотеки и указать нужны параметры компиляции, то это означает, что он понимает такие базовые вещи, как настройка путей для сборки проекта, что библиотеки должны лежать отдельно, а не в общей кучи dll в том дефолтовом каталоге, откуда все это берет IDE, что осознает возможности самого компилятора, а не упирается в ограничения IDE, что он сможет сам написать тот же билд-скрипт, что при выходе новой версии крутейшей среды разработки он не будет бороться с новым ГУИ для настроек проекта, пытаясь в очередной раз осознать, что откуда берется, а в случае непреодолимой ограниченности IDE напишет билд-скрипт. Работа с консолью, по моему мнению, это очень важный навык. И для самой компиляции он действительно редко нужен (хотя я мелкие утилиты пишу в Фаре, а компилирую из командной строки — это быстрее, чем создание проекта в IDE), но для вспомогательных программ очень часто.

Позволите с Вами не согласиться? Ну, когда я писал на MASM под ДОС (98-99 год), я знал параметры компилятора и линкера, а потом я открыл ( ) для себя PWB (Programmer's WorkBench — это такая древняя кросс-языковая ИДЕ от MS) и с радостью постарался забыть все эти параметры. Зачем они мне, если я могу просто расставить галочки? Ну а если они мне очень уж понадобятся, то я всегда могу почитать о них в хелпе(-ах), где все четко и ясно написано английским по черному (тогда так было принято у MS по дефолту). Если вернуться в почти настоящее время — как-то мне нужно было программить контроллер ATMega32, а там Win-AVR — это AVR-lib + gcc + Programmer's Notepad. Проблемой было для меня написать make-файл? Нет, я знал, что это такое и с чем его едят, хотя никогда руками его не писал. Маны меня спасли. Сейчас пишу на плюсах под Win, и без хелпа (включая то, что пишет cl /?) вряд ли смогу что-то скомпилить, но если надо будет, могу заюзать и bjam, и qmake, и собсна make, и MSBuild, и nant в нужных пропорциях. Ну не приходится мне ничего компилить из командной строки, что теперь делать? А для микро-проектов, недостойных IDE, ИМХО, проще один раз настроить Programmer's Notepad.

G>>б) я что, должен все константы помнить (С) ? Серьезно, я фигачу на Visual Studio, и не не помню как там и чего из командной строки запускать. Ну да, в одной книжке как-то читал про билд из командной строки.
A>так вот откуда потом берутся "программисты", которые в принципе не понимают, что программу можно собрать без VS (да, я дофига таких видел). начитаются тут...
а пользователя программы будет волновать, из командрой строки ее собирали или из VS?
Если у тебя куча кода и проектов, вряд ли из командной строки будет быстрее. А писать руками в блокноте то, что студия тебе забесплатно сгенерирует — это и вовсе извращение. А что за это еще кто-то и деньги платит?

D>Чтобы быть уверенным в адекватности программиста, когда дело дойдет до реального проекта.
Извините, у меня ощущение, что вы вряд ли видели реальные проекты

Здравствуйте, Donz, Вы писали:

D>Если брать конкретно Java, то чуть ли не половина вопросов новичков связана с полным непониманием, как подключаются пакеты, библиотеки и с полной путаницей в путях. Если брать J2ME, то ситуация еще хуже.

D>Не знаю, может быть я очень категоричен, но слишком много проблем случалось из-за непонимания базовых вещей. А IDE как раз подталкивают программиста к забиванию на эти знания.

Ну на яве это может быть и нужно, а вот для VS цена этим знаниям ноль целых хрен десятых. Хотя студия покрывают далеко не все возможные из командной строки сценарии. Например, студия не умеет билдить дотнетовские нетмодули, но мой опрос показал, что 11 из 12 опрошенных мной программистов вообще не знают, что такое нетмодули и зачем они нужны. При этом эти люди успешно и качественно решают проблемы бизнеса. И реальность такова, что на работу скорее возьмут человека, умеющего решать проблемы, чем человека, знающего все стопицот опций компилятора.
ИМХО вы не совсем правильно подходите к подбору персонала, если такая ерунда, как командная строка компилятора, для вас оказывается решающей...

Здравствуйте, UA, Вы писали:

UA>Здравствуйте, justinian, Вы писали:

UA>В репозитарии не должно быть не компилябельного кода.

Несобираемая утилита появилась после массовой миграции кода из SVN в AccuRev. и ее давно никто не трогал. За всем не доглядишь. Если вы хоть раз в жизни занимались тотальным переносом кода из одной системы контроля в другую, должны понимать, что это такое.

UA>Xмм... Может он на простых задачах работает у вас на пределе своих сил?

Человек дает результат и не создает проблем, это самое главное.
Или для вас то, что человек на работе занят работой означает, что он работает из последних сил?

UA>Думаю что первый проработал долгое время в компании где очень хорошо были отлажены процессы разработки, а у вас нужно еще порядок наводить своими силами.

Сомневаюсь.
Наша контора сертифицировано CMMI level 5.

Вобще про несобираемую утилиту — это просто пример. Проблемы бывают везде но если проблема решается в течении 2 сек, то нормальный человек ИМХО должен решить ее, если она мешает его работе, продолжить работу, а уж как-нибудь потом уже сообщить руководству, о том что была проблема. А не требовать помощи по любому поводу.

Если вам приходилось самому вести проекты, то должны понимать, что всегда нужны люди, способные решать поставленные задачи, а не просто знающие С++, или что-нибудь еще.

Здравствуйте, kosmik, Вы писали:

J>>Выводы? да собственно никаких.

K>Зря. Помимо профессиональных вещей имеет смысл смотреть подходит ли человек Вашей компании, в этом случае или не проверяли или ошиблись. Если компания устроена так что человек сам должен быть активным и пинать других если что-то застопорилось, то имеет смысл не брать даже умныхисуперпрофессиональных, если они пассивны.

Ну наверное я выразился несколько преувеличенно, что совсем никаких выводов.

В целом я с вами согласен. У нас аутсорсинг + agile + заказчик склонен спускать свои требования в очень общем виде. Так что действительно надо не просто кодировать по готовым спецификациям. Активная позиция очень нужна.

Здравствуйте, justinian, Вы писали:

J>Выводы? да собственно никаких.

Выводы, от вашей продуктивности мало что зависит , зарплата и т.п. Аутсорс ?

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, justinian, Вы писали:

J>>Выводы? да собственно никаких.

K>Зато их есть у нас
K>Приходя на все свои контракты, первым делом мне приставлялся разработчик (чаще лид), который помогал поставить/настроить рабочую среду — рассказывал, где лежат необходимые дистрибы, настраивал scc, убеждался, что проект нормально собирается и работает. И причина этого предельно простая — новый разработчик самостоятельно проблемы может и решит, но это займёт куда больше времени, чем у кого-то, кто уже знает всю эту кухню, знает типовые грабли и т.п. А время контрактора ооочень недёшево... По той же причине нам при возникновении любых препятствий рабочему процессу сразу же обращаться к людям, которые знают, как их устранить. Потому что компании умеют считать деньги.
K>Видимо, первый человек привык работать в подобном окружении — признаться, к этому очень быстро привыкаешь. А второй привык работать в компаниях, где сразу после приёма работника оставляют с кодом один на один...

Не относится к описываемой ситуации, т.к. оба человека проработали уже несколько месяцев.
А вобще у нас любой новый человек всегда в очень щадящем режиме. Времени задавать вопросы и со все разобраться имеет достаточно.

Здравствуйте, ambel-vlad, Вы писали:

AV>Здравствуйте, Кодёнок, Вы писали:

AV>>>Вот одного не могу понять. Почему некоторые считают, что у конторы топикстартера нет налаженных процессов? Только из-за того что какой-то проект в репе был некомбилябелен? Вообще-то стоит уточнить что это была за утилита.

Кё>>В мире эльфов есть только два типа контор: грамотные, где все пучком, и дерьмо всякое, где бардак. Наличие некомпилябельного кода в репозитории однозначно относит ее ко второй группе.

AV>Ну если только в мире эльфов. А в реальном мире зависит от утилитки. Если ее собрали черт знает сколько лет назад и спокойно пользуются. А через некоторое время про ее сорцы забыли до лучших времен. Ничего в этом ужасного нет.

Именно так оно и было.

AV>Хотя в целом, подобных ситуаций стоит избегать.

Об этом спору нет.

G>Здравствуйте, justinian, Вы писали:

G>Да, ситуевина знакомая — такого товарища недавно сами уволили. В начале работы в конторе рвал зад, работал неплохо, но потом че-то видать посчитал, что подобрал ключик к основным людям со стороны клиента и началась звздная болезнь
Скорее "ну вот рву я тут зад, делаю в 10 раз больше работы, чем народ вокруг, и что мне за это будет? премия? повышение? опцион? фиг? ну тогда пусть сами зад рвут, а я пока технологии новые поучу за конторский счет". Очень похоже на мою стратегию на одном из прошлых мест работы, где результат не волновал никого, зато чтилась "лояльность", выражающаяся в сидении в офисе с 9 до 21.
G>, плюс все та же фигня: 75% тасков, которые ему давались, были очень грамотно слиты — и типа вроде ресерч провел, и покопался, и туда и сюда,ну и вобщем вывод такой что сделать не удасться... Правда потом вскрылась, когда я сам начал разгредать его таски, а также когда его таски передали другому челу.
Логично. Думаю, чел это понимал и ставил цель продержаться у кормушки до последнего, параллельно подыскивая вариант получше.
G>Короче пришлось расстрелять, хотя — видит бог — у нас тут вся контора вокруг него почти 5 месяцев танцевала, уговаривали быть поактивнее...
А могли бы повысить до лида, чтобы он делал research, как таск упростить, а не завалить. Дробил бы на кирпичики и раздавал команде, вместо скукотищи зеленой.

Здравствуйте, ambel-vlad, Вы писали:

UA>>В репозитарии не должно быть не компилябельного кода.
AV>Оно-то так. Но это не повод не разбираться с возникшими проблемами.

На новом для себя проекте лучше всё таки спросить в чём дело.
Бо бывает что просто недолили в репу что нибудь.
ИМХО касательно ситуации "не собирается" для человека совсем недавно пришедшего в проект пойти и спросить "какого хрена" самое правильное решение.

Здравствуйте, Unhandled_Exception, Вы писали:

UA>>В репозитарии не должно быть не компилябельного кода.
U_E>и дело разработчика поправить этот момент, разве нет
Речь о разработчике которого недавно взяли.
Когда толком не представляешь что там в проекте к чему пофиксить некомпилябельный код сложнее.
С точки зрения эффективности проще делегировать решение проблемы к тем, кто проблему создал и разбирается в ней лучше.

Здравствуйте, ambel-vlad, Вы писали:

AV>ТС ставит в вину несколько иное. И судя по описанию других случаев проблема скорее все таки в том человеке

ТС по-моему ничего никому не ставит в вину, а просто указывает на тот факт что поведение на собеседовании и на работе — две большие разницы.
А по конкретике, первый или лентяй по жизни, или просто разработчик не для ТС-коллектива (я б вот тоже счел своим долгом пнуть за несобирающийся проект в репозитории ибо если не пинать он там вечно такой будет), или был чем-то очень сильно демотивирован.

Здравствуйте, Donz, Вы писали:

D>Не могу сказать про VS, но в Java компиляция приложения с простейшей задачкой — это вызов javac с одним параметром. Да, я действительно считаю, что это должен знать даже начинающий ява разработчик, как и запуск приложения из консоли.
Шеф, лично я это забыл уже очень давно. javac кажись вообще не пользовался ни разу. Собираю всегда mvn clean install, при этом и CI настраиваю, и из командной строки компилю, но про javac я полностью забыл после перехода на maven. Запускать еще приходилось из командной строки, но компилять, да еще писать в ноутпаде — извращение еще то.
Я как представлю что было б, если мне все импорты нужно было руками прописывать, помнить синтаксис всех библиотечных функций, их аргументов — да 100 лет такая Java не нужна. Без IDE писать — это нужно быть очень и очень большим извращенцем быть. Либо чтоб был важен не результат, а чтобы помучиться. Без нормальной IDE любой мегаязык программирования на текущий момент — шлак полнейший.

Здравствуйте, elmal, Вы писали:

E>Запускать еще приходилось из командной строки, но компилять, да еще писать в ноутпаде — извращение еще то.
...
E>Без IDE писать — это нужно быть очень и очень большим извращенцем быть. Либо чтоб был важен не результат, а чтобы помучиться. Без нормальной IDE любой мегаязык программирования на текущий момент — шлак полнейший.

Конечно, если человек хорошо понимает, что находится "под капотом", зто так. Но если не понимает,
стоит некоторое время помучиться, иначе могут возникнуть проблемы.

Здравствуйте, Donz, Вы писали:

D>Не крайне важным, а просто важным. Если человек в состоянии подключить правильным способом нужные библиотеки и указать нужны параметры компиляции
У нас в репозитории никакой специфической для среды разработки инфы не лежит. Просто maven проект. Чтоб кому то открыть проект, достаточно вытащить исходники и в среде разработки открыть pom.xml. А чтоб сбилдить, даже среду разработки открывать не надо. Я правильно понимаю, что у нас библиотеки неправильным образом подключены? Про подключение библиотек я уже давно забыл как страшный сон.

Здравствуйте, justinian, Вы писали:

Проблема здесь в том, что обычно в организацию собеседуют сферического коня, толком не понимая, что они от него хотят.

По факту же оказывается, что нанимают креативного человека и садят дописывать и фиксить баго-поделье пятилетней давности.
Креативного парня воротит, ему совершенно не хочется ковыряться в го$%$, реанимировать мёртвый проект, который даже не компилируется.

В итоге возникает чувство горечи и отвращения: люди (вчерашние интервьеры), которые вчера спрашивали его про порядки малости, непараметрическую регрессию и заставляли решать задачки на бумаге, строя из себя умных, не способны даже поддерживать проект в рабочем состоянии!

Здравствуйте, justinian, Вы писали:

J>Несобираемая утилита появилась после массовой миграции кода из SVN в AccuRev. и ее давно никто не трогал. За всем не доглядишь. Если вы хоть раз в жизни занимались тотальным переносом кода из одной системы контроля в другую, должны понимать, что это такое.

Ну а хранилище-то на SVN в замороженном виде — в том виде, каком оно было на момент переноса файлов в другую систему, осталось? Если нет, то это косяк в мозгах не у программиста, который не может быстро сделать сборку, а у менеджера проекта...

В любом случае то, что человек задает вопросы: что-где лежит, как собрать — это правильно...
И если уже никто не помнит особенностей сборки конкретного модуля, рассказываем человеку что знаем на эту тему, надеясь, что в остальном он разберется сам... Если конечно, в этом разобраться возможно.

J>Наша контора сертифицировано CMMI level 5.

Всё-таки интересно, старое хранилище уже снесли или нет...

J>Если вам приходилось самому вести проекты, то должны понимать, что всегда нужны люди, способные решать поставленные задачи, а не просто знающие С++, или что-нибудь еще.

О да. Только не стоит ждать этого от новичка, каким бы способным он ни был...

Здравствуйте, ambel-vlad, Вы писали:

AV>И так надцать раз. Почему, судя по описанию, у других подобных проблем не возникает?

Читаем внимательнее посты ТС. Ему дали утилиту, которую сто лет никто не трогал. Именно поэтому у остальных этой проблемы нет.
Вообще если с ней такая задница, начальство могло бы сразу предупредить, что код этот "дела давно минувших дней, предания старины глубокой" и что все проблемы надо решать самому — тогда думаю всё было бы ок...

04.11.2010 15:51, koandrew пишет:
>
> Читаем внимательнее посты ТС.
Именно:
"С первым — постоянные проблемы. Что ему не поручишь — он прибегает и
жалуется, что по таким-то и таким-то причинам он это сделать не может.
Причем сам даже не пытается эти проблемы решить. Доходит до смешного.
Ему поручили добавить некоторую функциональность в давно существовавшую
утилиту. Он пожаловался, что утилита не собирается. Оказалось, что
расположение хедеров в конфигурации проекта и в реальности не совпадают,
но человек даже не пытался с этим разобраться, т.е. просто пишет, типа
работать не могу — ничего не собирается."

Здравствуйте, CreatorCray, Вы писали:

CC>На новом для себя проекте лучше всё таки спросить в чём дело.
CC>Бо бывает что просто недолили в репу что нибудь.
CC>ИМХО касательно ситуации "не собирается" для человека совсем недавно пришедшего в проект пойти и спросить "какого хрена" самое правильное решение.

Может стоит потратить хотя бы 5 минут на анализ проблемы?

лЗдравствуйте, CreatorCray, Вы писали:

UA>>>В репозитарии не должно быть не компилябельного кода.
AV>>Оно-то так. Но это не повод не разбираться с возникшими проблемами.

CC>На новом для себя проекте лучше всё таки спросить в чём дело.
CC>Бо бывает что просто недолили в репу что нибудь.
CC>ИМХО касательно ситуации "не собирается" для человека совсем недавно пришедшего в проект пойти и спросить "какого хрена" самое правильное решение.

Вот только описание ситуации не смахивает на недавно пришедшего в проект.

Здравствуйте, koandrew, Вы писали:

AV>>И так надцать раз. Почему, судя по описанию, у других подобных проблем не возникает?

K>Читаем внимательнее посты ТС. Ему дали утилиту, которую сто лет никто не трогал. Именно поэтому у остальных этой проблемы нет.

Вот именно читаем внимательно. Проблема с несобирающимся кодов не единственный случай. В начальном сообщении написано что были и другие проблемы с человеком. Опять же, если проблема с утилиткой была только в том, что поменялись пути к хидерам, то проблему можно было бы диагностировать самому и уточнить этот момент. А не "работать не могу — ничего не собирается"

Здравствуйте, CreatorCray, Вы писали:

UA>>>В репозитарии не должно быть не компилябельного кода.
U_E>>и дело разработчика поправить этот момент, разве нет
CC>Речь о разработчике которого недавно взяли.

Несколько месяцев назад — это недавно?

Здравствуйте, MescalitoPeyot, Вы писали:

MP>А по конкретике, первый или лентяй по жизни, или просто разработчик не для ТС-коллектива (я б вот тоже счел своим долгом пнуть за несобирающийся проект в репозитории ибо если не пинать он там вечно такой будет), или был чем-то очень сильно демотивирован.

Пнуть можно по разному. Можно найти, что пути к хидерам поменялись и уточнить этот вопрос. А можно прибежать с криками "все пропало, утилита не собирается". Тем более, что ТС подтвердил, что это был единичный случай несобирающегося проекта, который давно никто не трогал.

Здравствуйте, DataMiner, Вы писали:

J>>Если вам приходилось самому вести проекты, то должны понимать, что всегда нужны люди, способные решать поставленные задачи, а не просто знающие С++, или что-нибудь еще.

DM>О да. Только не стоит ждать этого от новичка, каким бы способным он ни был...

В особенности, если это какой-нибудь лид/сеньор девелопер... А то душа может быть ранимой

Здравствуйте, ambel-vlad, Вы писали:

AV>Здравствуйте, koandrew, Вы писали:

AV>>>И так надцать раз. Почему, судя по описанию, у других подобных проблем не возникает?

K>>Читаем внимательнее посты ТС. Ему дали утилиту, которую сто лет никто не трогал. Именно поэтому у остальных этой проблемы нет.

AV>Вот именно читаем внимательно. Проблема с несобирающимся кодов не единственный случай. В начальном сообщении написано что были и другие проблемы с человеком. Опять же, если проблема с утилиткой была только в том, что поменялись пути к хидерам, то проблему можно было бы диагностировать самому и уточнить этот момент. А не "работать не могу — ничего не собирается"

Чисто индусский подход. Двинуть мозгом и разобраться даже в пустяковой проблеме для них неразрешимая задача. Заставить индуса разобраться в коде — это много многочасовых training sessions. Пока по строчке не разберешь все будут жаловаться, что им не объяснили как оно работает.

Здравствуйте, koandrew, Вы писали:

K>Видимо, первый человек привык работать в подобном окружении — признаться, к этому очень быстро привыкаешь. А второй привык работать в компаниях, где сразу после приёма работника оставляют с кодом один на один...

Если ты не заметил, то эти разработчики уже несколько месяцев работают. Не находишь в такой ситуации прибегать и "шеф, все пропало" несколько странно? Учитывая что и до этого были подобные ситуации?

Здравствуйте, ambel-vlad, Вы писали:

AV>Если ты не заметил, то эти разработчики уже несколько месяцев работают. Не находишь в такой ситуации прибегать и "шеф, все пропало" несколько странно? Учитывая что и до этого были подобные ситуации?

Прежде, чем судить о ситуации, нужно услышать версию второй стороны. Поскольку её мы не услышали, всё, что мы можем делать — это спекулировать...

Здравствуйте, koandrew, Вы писали:

AV>>Если ты не заметил, то эти разработчики уже несколько месяцев работают. Не находишь в такой ситуации прибегать и "шеф, все пропало" несколько странно? Учитывая что и до этого были подобные ситуации?

K>Прежде, чем судить о ситуации, нужно услышать версию второй стороны.

Это было бы интересно. Кстати, ты писал, что когда ты приходишь, то к тебе приставляют специального человека для помощи в настройке рабочей среды. И как долго он при тебе? Несколько месяцев?

Здравствуйте, ambel-vlad, Вы писали:

AV>Это было бы интересно.
Это необходимое условие для анализа любой конфликтной ситуации. Без этого весь наш анализ — это не более чем спекуляции.

AV>Кстати, ты писал, что когда ты приходишь, то к тебе приставляют специального человека для помощи в настройке рабочей среды. И как долго он при тебе? Несколько месяцев?
Так долго, как требуется. Плюс при возникновении каких-либо проблем я обращаюсь к нему — он либо исправит ситуацию сам, либо скажет, как её исправить, либо вызовет нужных людей, которые разрулят ситуацию. К примеру, у меня на прошлом контракте в один момент ОС начала вести себя как-то странно. Я обратился к этому человеку, и через 10 минут у меня был новый компьютер со свежей рабочей ОС... Хотя в других условиях я бы сам попробовал исправить ситуацию, но сколько времени я бы потратил на это — это ещё тот вопрос. А время — это деньги.

Здравствуйте, koandrew, Вы писали:

AV>>Кстати, ты писал, что когда ты приходишь, то к тебе приставляют специального человека для помощи в настройке рабочей среды. И как долго он при тебе? Несколько месяцев?
K>Так долго, как требуется. Плюс при возникновении каких-либо проблем я обращаюсь к нему — он либо исправит ситуацию сам, либо скажет, как её исправить, либо вызовет нужных людей, которые разрулят ситуацию. К примеру, у меня на прошлом контракте в один момент ОС начала вести себя как-то странно. Я обратился к этому человеку, и через 10 минут у меня был новый компьютер со свежей рабочей ОС... Хотя в других условиях я бы сам попробовал исправить ситуацию, но сколько времени я бы потратил на это — это ещё тот вопрос. А время — это деньги.

Вот только твой пример никаким боком не относится к ситуации, когда человек не соизволил даже поинтересоваться причиной почему он не может выполнить задание. Уж найти, что пути к хидерам неверные, это как не тянет на разборки с проблемами ОС. Это так сказать, рабочие моменты.

Здравствуйте, ambel-vlad, Вы писали:

AV>Вот только твой пример никаким боком не относится к ситуации, когда человек не соизволил даже поинтересоваться причиной почему он не может выполнить задание. Уж найти, что пути к хидерам неверные, это как не тянет на разборки с проблемами ОС. Это так сказать, рабочие моменты.

Вы не поняли. Я обращаюсь к этому человеку при _любой_ проблеме, если мне явно не было указано разбираться самостоятельно. Но не потому, что я сам не в состоянии разобраться — а потому что спросить быстрее.

Здравствуйте, Abalak, Вы писали:

A>Чисто индусский подход. Двинуть мозгом и разобраться даже в пустяковой проблеме для них неразрешимая задача. Заставить индуса разобраться в коде — это много многочасовых training sessions. Пока по строчке не разберешь все будут жаловаться, что им не объяснили как оно работает.

У меня на предыдущем контракте был прикол — дали индусу кусок относительно старого библиотечного кода (старого относительно кода самого проекта), надо было исправить работу либы на пограничных условиях. Тот кропел над кодом неделю, потом радостный прибежал "я всё сделал". Открываем код — и угадай, что мы там увидели? Если ты работал с индусами, то должен догадаться сразу

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Abalak, Вы писали:

A>>Чисто индусский подход. Двинуть мозгом и разобраться даже в пустяковой проблеме для них неразрешимая задача. Заставить индуса разобраться в коде — это много многочасовых training sessions. Пока по строчке не разберешь все будут жаловаться, что им не объяснили как оно работает.

K>У меня на предыдущем контракте был прикол — дали индусу кусок относительно старого библиотечного кода (старого относительно кода самого проекта), надо было исправить работу либы на пограничных условиях. Тот кропел над кодом неделю, потом радостный прибежал "я всё сделал". Открываем код — и угадай, что мы там увидели? Если ты работал с индусами, то должен догадаться сразу

Хочешь сказать, что я с индусами не работал? Хз, что ты там мог увидеть — копипасту, лапшу, колбасу ифов, да что угодно — в сортах говнокода не разбираюсь

Здравствуйте, Abalak, Вы писали:

A>Чисто индусский подход. Двинуть мозгом и разобраться даже в пустяковой проблеме для них неразрешимая задача. Заставить индуса разобраться в коде — это много многочасовых training sessions. Пока по строчке не разберешь все будут жаловаться, что им не объяснили как оно работает.

А если серьёзно — разобраться в коде, и разобраться, почему проект не собирается — это разные вещи. В дотнете эта проблема не так актуальна (хотя при использовании подписанных сборок порой заставить всё это собираться и работать — веселье то ещё), но кроме дотнета есть и другие среды...

Здравствуйте, Abalak, Вы писали:

A>Хочешь сказать, что я с индусами не работал?
Не, я не это имел в виду. Я имел в виду, что это довольно типичный пример "паттерна индусского кода"
A>Хз, что ты там мог увидеть — копипасту, лапшу, колбасу ифов, да что угодно — в сортах говнокода не разбираюсь
А мне вот пришлось научиться разбираться Копипастом китайцы отличаются, у индусов фирменный стиль — это развесистое дерево ифов, за которым не видно функциональности

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Abalak, Вы писали:

A>>Хочешь сказать, что я с индусами не работал?
K>Не, я не это имел в виду. Я имел в виду, что это довольно типичный пример "паттерна индусского кода"
A>>Хз, что ты там мог увидеть — копипасту, лапшу, колбасу ифов, да что угодно — в сортах говнокода не разбираюсь
K>А мне вот пришлось научиться разбираться Копипастом китайцы отличаются, у индусов фирменный стиль — это развесистое дерево ифов, за которым не видно функциональности

Да ладно, я такие копипасты индусские встречал, эти чудаки даже не удосуживались вычистить ненужный функционал в несколько сотен строк. И еще орали на code review — не называй наш код копипастой.

Здравствуйте, justinian, Вы писали:

J>Выводы? да собственно никаких.

Мне кажется что чуть не на всех сайтах в инете описывается такая проблема, как ходоки, летчики, завсегдатаи интервью. Просто нужно взять за правило проверять эту особенность.

Здравствуйте, koandrew, Вы писали:

AV>>Вот только твой пример никаким боком не относится к ситуации, когда человек не соизволил даже поинтересоваться причиной почему он не может выполнить задание. Уж найти, что пути к хидерам неверные, это как не тянет на разборки с проблемами ОС. Это так сказать, рабочие моменты.

K>Вы не поняли. Я обращаюсь к этому человеку при _любой_ проблеме, если мне явно не было указано разбираться самостоятельно. Но не потому, что я сам не в состоянии разобраться — а потому что спросить быстрее.

Может для контрактора такой подход и оправдан. Но боюсь что в случае обычного программера такие регулярние обращения спустя несколько месяцев вряд ли приемлимы. Особенно прибегать с "шеф все пропало"

Здравствуйте, ambel-vlad, Вы писали:

AV>Может для контрактора такой подход и оправдан. Но боюсь что в случае обычного программера такие регулярние обращения спустя несколько месяцев вряд ли приемлимы. Особенно прибегать с "шеф все пропало"

Опять же это всё зависит от того, как в конкретной компании организован рабочий процесс. И винить сотрудника в том, что он привык работать по-другому, как-то странно. Другое дело, если он намеренно саботирует работу, прикрываясь техническими причинами. Хотя опять же — тут всё зависит от постановки задачи. Если задача была поставлена так: "Вот тут возьми код, и поправь в нём то-то и тот-то" — то ожидать вопросов на тему того, что оно не билдится, вполне нормально. Если же задача звучала "Вот тут код, его не трогали сто лет, написан хз кем, надо там разобраться, завести его и поправить то-то и то-то" — то тут становится ясно, что помощи ждать не стоит и рассчитывать нужно только на себя.

Здравствуйте, AndrewJD, Вы писали:

CC>>На новом для себя проекте лучше всё таки спросить в чём дело.
CC>>Бо бывает что просто недолили в репу что нибудь.
CC>>ИМХО касательно ситуации "не собирается" для человека совсем недавно пришедшего в проект пойти и спросить "какого хрена" самое правильное решение.

AJD>Может стоит потратить хотя бы 5 минут на анализ проблемы?
Блин. Невнимательно прочитал исходное сообщение, сорри.

Здравствуйте, ambel-vlad, Вы писали:

UA>>>>В репозитарии не должно быть не компилябельного кода.
U_E>>>и дело разработчика поправить этот момент, разве нет
CC>>Речь о разработчике которого недавно взяли.

AV>Несколько месяцев назад — это недавно?
Мне SCSI PR вынесло моск.
Невнимательно прочитал топикстартера.

Здравствуйте, Skelterer, Вы писали:

S>не, я не про задания. Это действительно довольно спорный момент. Я про "показать то, что писал".

Я не думаю, что здесь все так просто. Я, например, никогда не прошу кандидатов показать код с предыдущего места работы, потому что сам скорее всего такую просьбу проигнорирую.

Например, на текущей работе я подписывал NDA и нарушать его, т.е. по-просту воровать код, чтобы кому-то показать я не стану. Кода с предыдущей работы у меня нет, т.к. на нынешней, когда я устраивался, у меня его никто не спрашивал, и т.д.

Можно конечно иметь свой собственный проект и делать в свободное время, а потом показывать. Но я уже давно привык получать деньги абсолютно за весь код, который я пишу.

Здравствуйте, server_mouse, Вы писали:

J>>Выводы?
_>Искать нужно людей способных решать проблемы.
_>Вы имхо искали способных писать код. Что искали, то собственно и нашли.

Я с этим согласен. Вопрос — как конкретно вы на интервью распознаете людей способных решать проблемы?

Здравствуйте, msk78, Вы писали:

M>По факту же оказывается, что нанимают креативного человека и садят дописывать и фиксить баго-поделье пятилетней давности.
M>Креативного парня воротит, ему совершенно не хочется ковыряться в го$%$, реанимировать мёртвый проект, который даже не компилируется.

M>В итоге возникает чувство горечи и отвращения: люди (вчерашние интервьеры), которые вчера спрашивали его про порядки малости, непараметрическую регрессию и заставляли решать задачки на бумаге, строя из себя умных, не способны даже поддерживать проект в рабочем состоянии!

Т.е. я типа о судьбах мира размышляю, а мне тут какой-то код подсовывают.

Только за размышления о судьбах мира заказчик денег почему-то не платит, а просит решить его конкретную проблемку.

Здравствуйте, LR, Вы писали:

LR>Мне кажется что чуть не на всех сайтах в инете описывается такая проблема, как ходоки, летчики, завсегдатаи интервью. Просто нужно взять за правило проверять эту особенность.

Ну тогда мы возвращаемся к исходному вопросу — как правильно определить на интервью, подходит человек или нет?

Здравствуйте, justinian, Вы писали:

Я на интервью больше делаю упор на то, какие задачи решал человек на предыдущей работе и как решал. Еще важно узнать чего именно человек хочет и убедится что то что мы ему предлагаем, это именно оно. Плюс очень помогает неформальная беседа о кандидате с его бывшими коллегами по работе (в небольших городах, как наш, где все всех знают — это легко выполнимо). Вообщем мы больше ориентируемся на совпадение интересов/возможностей, чем на мегазнанния и скиллы. Если человек чего-то не знает (но хочет узнать), это не так уж плохо, значит ему есть куда расти.

Интервью в виде экзамена позволяет только выявить знает ли человек ответы на Ваши вопросы или нет, какое это отношение имеет к выполнению реальных задач тут уже мильён раз обсуждалось.

Здравствуйте, justinian, Вы писали:

J>Ну тогда мы возвращаемся к исходному вопросу — как правильно определить на интервью, подходит человек или нет?
Попробуем. Если не ошибаюсь, было только одно интервью?

Вы искали человека, который правильно отвечает на вопросы, касающиеся языка и решает несложные задачки, которые
ему задает преподаватель, который знает правильный ответ

А оказывается, Вам нужен человек, который в первую очередь в описанных Вами ситуациях будет реагировать правильно
+более менее успешно проходит интервью, описанное Вами.

Получается, Вам нужно еще одно интервью, на котором проверять например реакцию кандидата в конкретной ситуации.

Здравствуйте, Abalak, Вы писали:

A>Да ладно, я такие копипасты индусские встречал, эти чудаки даже не удосуживались вычистить ненужный функционал в несколько сотен строк. И еще орали на code review — не называй наш код копипастой.
Сталкивался с такими персонажами.
Скопипастили свою же огромную функцию строк на тысяч 4-5 (файлы меньше чем в 10 тыс строк у них встречались редко)
В начале функции if с телом, составляющим где то процентов 80 от функции, который в новом месте был не нужен вовсе.
Но вместо того чтоб удалить его идус просто дописал перед if кучу присваиваний, которые обеспечивали что условие в if (тоже кстати длинное) всегда будет false.

05.11.2010 7:21, justinian пишет:

> Я с этим согласен. Вопрос — как конкретно вы на интервью распознаете
> людей способных решать проблемы?
Единственный способ выяснить, как человек решал проблемы на прошлых работах.

Здравствуйте, Vzhyk, Вы писали:

V>05.11.2010 7:21, justinian пишет:

>> Я с этим согласен. Вопрос — как конкретно вы на интервью распознаете
>> людей способных решать проблемы?
V>Единственный способ выяснить, как человек решал проблемы на прошлых работах.

Как вы себе это представляете?

Здравствуйте, justinian, Вы писали:

J>Второй был так себе. На некоторые вопросы отвечал типа — не знаю, не помню, или давно этим не занимался. Задачку написал с ошибкой (не принципиальной, но все же). Вобщем, взяли только потому что позицию надо было заполнить очень срочно, а другие кандидаты были еще хуже.

Кроме всяких шуток, "не помню" — это не дежурная отмазка. Во всяком случае, как уже в ветке писали, в состоянии стресса (лично для меня интервью — всегда неслабый стресс) человек может вести себя не так, как в рабочей обстановке. Пару дней назад проходил интервью, так что по свежим впечатлениям... Один из интервьюеров задал дежурный вопрос про виртуальный деструктор (изыгранный баян), а потом минут N-дцать долбил, как заведенный (может, для него это тоже был стресс?) "вы вот все хорошо рассказываете, но я не вижу деталей и из вашего рассказа не улавливаю — какова была ваша роль? выберите проект, которым гордитесь, и нарисуйте для него диаграмму классов, или опишите алгоритм, который использовали". Ну что я, держу в голове то, что делал полгода-год назад? Дальше анекдот: начинаю кое-как рисовать диаграмму классов для кода, который незадолго до того писал. Примитив полный: 1 базовый класс, 2 производных класса, 2 вирт. метода. Интервьюер спрашивает "а почему тут нельзя просто написать две отдельные функции, а не городить ООП и полиморфизм"? Даже вот такой простой, как амеба, код работает не в сферическом вакууме(ТМ), значит, надо еще рассказать, где это применяется, и главное — зачем. Начинаю ему объяснять, товарищ снова недоволен: "не будем углубляться в детали", и тут я уже срываюсь слегка и заявляю "ну вы же сами просили детали!" Смотрю краем глаза, второй интервьюер тихо сползает со стула

Выводы? Да опять же, никаких.

Здравствуйте, Ахмед, Вы писали:

А>Здравствуйте, justinian, Вы писали:

А>Я на интервью больше делаю упор на то, какие задачи решал человек на предыдущей работе и как решал. Еще важно узнать чего именно человек хочет и убедится что то что мы ему предлагаем, это именно оно. Плюс очень помогает неформальная беседа о кандидате с его бывшими коллегами по работе (в небольших городах, как наш, где все всех знают — это легко выполнимо). Вообщем мы больше ориентируемся на совпадение интересов/возможностей, чем на мегазнанния и скиллы. Если человек чего-то не знает (но хочет узнать), это не так уж плохо, значит ему есть куда расти.

Советы в принципе правильные. К сожалению, человек может очень убедительно рассказать как он решал задачи на предыдущей работе, а потом окажется, что работать он не хочет.

Что касается, поговорить неформально с бывшими коллегами это в моей текущей ситуации вобще не применимо.

Кроме того, для меня ситуация усугубляется тем, что наша контора аутсорсинговая. Заказчик платит за головы, заполнение вакансий является делом срочным, причем кандидат при необходимости еще и должен суметь пройти интервью у заказчика.

Здравствуйте, CreatorCray, Вы писали:

UA>>>>>В репозитарии не должно быть не компилябельного кода.
U_E>>>>и дело разработчика поправить этот момент, разве нет
CC>>>Речь о разработчике которого недавно взяли.

AV>>Несколько месяцев назад — это недавно?
CC>Мне SCSI PR вынесло моск.
CC>Невнимательно прочитал топикстартера.

Я так и подумал.

Здравствуйте, koandrew, Вы писали:

K>Хотя опять же — тут всё зависит от постановки задачи. Если задача была поставлена так: "Вот тут возьми код, и поправь в нём то-то и тот-то" — то ожидать вопросов на тему того, что оно не билдится, вполне нормально.

Не совсем согласен. Логично было бы если бы вопрос звучал примерно так: "утилитка не билдится, потому что пути неверные". И далее или вопрос "сейчас вот такие вот пути. Их использовать?" или хотя бы "какие пути сейчас используются". Хотя если утилитка использует что-то что использовалось на проекте, где человек был занят, то второй вариант тоже достаточно подозрителен

05.11.2010 11:26, justinian пишет:
> V>Единственный способ выяснить, как человек решал проблемы на прошлых
> работах.
>
> Как вы себе это представляете?
Честно, я уже устал повторять одно и тоже.
1. Представьте, что перед вами не робот, не компьютер, а живой человек.
2. Попросите человека рассказать о своем прошлом опыте.
3. Слушайте человека и задавайте уточняющие вопросы по необходимости.
4. Поговорите на темы, с которыми будет связана его дальнейшая работа
(вот здесь и пригодятся бумажка с ручкой).
5. Выясните, что человеку интересно делать и как ему нравиться работать.
6. На основе предыдущих пунктов принимайте решение подходит ли вам этот
человек или нет.

05.11.2010 11:40, justinian пишет:

>
> Советы в принципе правильные. К сожалению, человек может очень
> убедительно рассказать как он решал задачи на предыдущей работе, а потом
> окажется, что работать он не хочет.
Он идет к вам работать и получать зарплату за работу и работать не хочет
— как это?

>
> Кроме того, для меня ситуация усугубляется тем, что наша контора
> аутсорсинговая. Заказчик платит за головы, заполнение вакансий является
> делом срочным, причем кандидат при необходимости еще и должен суметь
> пройти интервью у заказчика.
Т.е. ты сам не знаешь чем будет заниматься нанимаемый человек?
Т.е. ты взял специалиста в С++, а задачи ему даются по С# или наоборот?
Я правильно понял?
Тогда вариант у тебя только один — брать студентов (они специалисты во
всем и ни в чем), набор через экзамен, чтобы хоть что-то умели и
увольнять чуть что.
Итого, дешево, быстро и некачественно — но, именно это вами надо.

Здравствуйте, Vzhyk, Вы писали:

V>05.11.2010 7:21, justinian пишет:

>> Я с этим согласен. Вопрос — как конкретно вы на интервью распознаете
>> людей способных решать проблемы?
V>Единственный способ выяснить, как человек решал проблемы на прошлых работах.

Надо выяснить, какие проблемы человек считает "своими". Похоже, Первый считает,
что он должен только писать код, а остальным пусть занимаются другие.

Или же он считает, что работать должны другие Кстати, если он еще умеет
общаться, найти общий язык с коллегами, из него получится хороший начальник

Здравствуйте, UA, Вы писали:


UA>Думаю что первый проработал долгое время в компании где очень хорошо были отлажены процессы разработки, а у вас нужно еще порядок наводить своими силами.


Перевожу на русский: в компании-конвеере, где каждый выполнял не более чем роль винтика системы.

Здравствуйте, Donz, Вы писали:

J>>даем прямо на интервью написать на ручкой на бумаге

D>Один из самых раздражающих приемов интервьюеров. Мой совет — дайте ноут пусть хоть с голым нотепадом.

Кстати, да. Писать что-то ручкой само по себе неудобно(отвыкаешь полностью от этого навыка за годы неиспользования), а уж код и подавно(IDE нынче умные, и огромную черновую работу по написанию кода делают сами, и руками это возпроизводить — )

Здравствуйте, Stanislav V. Zudin, Вы писали:


D>>Один из самых раздражающих приемов интервьюеров. Мой совет — дайте ноут пусть хоть с голым нотепадом.

SVZ>Хум, как говорится, хау.
SVZ>Мне, например, с бумагой и ручкой лучше думается.


А я уже забыл, когда последний раз писал что-либо длиннее номера телефона.

Здравствуйте, CreatorCray, Вы писали:


CC>Скопипастили свою же огромную функцию строк на тысяч 4-5 (файлы меньше чем в 10 тыс строк у них встречались редко)
CC>В начале функции if с телом, составляющим где то процентов 80 от функции, который в новом месте был не нужен вовсе.
CC>Но вместо того чтоб удалить его идус просто дописал перед if кучу присваиваний, которые обеспечивали что условие в if (тоже кстати длинное) всегда будет false.

Жестко.

Здравствуйте, justinian, Вы писали:

J>Ну тогда мы возвращаемся к исходному вопросу — как правильно определить на интервью, подходит человек или нет?

Как минимум, определиться кто вам нужен, какие задачи будут стоять перед разработчиком, как поставлен процесс, учесть коллектив, модель разработки, личные качества. Выделить качества, которые вы бы хотели видеть у разработчика. И потом, исходя из этого, проводить интервью.

Задачки на собеседовании обычно нужны для того, чтобы определить, как у соискателя работает голова при составлении алгоритмов, оптимальном поиске решения нетривиальных задач. Но если у вас таких задач в рабочем процессе в принципе не наблюдается, то это ничего не даст.

Чтобы делать некоторые вещи, надо иметь либо светлую голову, либо чугунную задницу. Специфика вашей работы подразумевает второй вариант.

Здравствуйте, justinian, Вы писали:

J>Советы в принципе правильные. К сожалению, человек может очень убедительно рассказать как он решал задачи на предыдущей работе, а потом окажется, что работать он не хочет.

Почему не хочет? Какая проблема на интервью выделить круг задач, которые интересны соискателю? Хотя бы потому, о каких проектах он рассказывал более увлеченно