Здравствуйте, 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 + заказчик склонен спускать свои требования в очень общем виде. Так что действительно надо не просто кодировать по готовым спецификациям. Активная позиция очень нужна.