Возрастнрй фактор в разработке
Alimenkou Nikolay
накопленный багаж знаний и опыта, который он может использовать
самостоятельно или же передавать другим. С некоторыми из них очень
приятно общаться и польза от них просто неоценима.
Но все же позволю себе сформулировать ряд наблюдений из жизни:
1) Факт, доказанный учеными - с возрастом мозг становится менее
активным, человеку начинает быть свойственно быстрее забывать
информацию, тяжелее усваивать большие объемы новой информации
2) Человек в возрасте менее склонен воспринимать изменения, он
сопротивляется им, особенно когда они противоречат его личному опыту в
прошлом
3) Опытный разработчик в возрасте чаще всего скептик, который считает
что его опыт и знания позволяют ему не соглашаться и продавливать
решения в спорных вопросах
4) Разработчик в возрасте часто не потерпит чтобы кто-то младше него
стоял сверху по служебной лестнице и будет всячески сопротивляться и
вставлять палки в колеса
5) Разработчик в возрасте меньше изучает новые технологии, фреймворки,
практики даже просто потому что ему это уже не так интересно, у него
есть семья и дети, у него нету свободного времени
6) Наконец очень многих опытных разработчиков компании держат в очень
узком русле (к примеру тюнинг DB2 или разработка драйверов к USB
устройствам на C++). Когда такой человек хочет поменять компанию и
заявляет что его опыт в C++ уже больше 10 лет, то он лукавит, потому
что его узкопрофильные знания могут быть низкоприоритетными для новой
компании
7) Разработчик в возрасте редко меняет работу (и даже задумывается о
ее смене). Это происходит потому что у него уже есть семья, куча
обязательств и ему не так просто изменить что-то в жизни
8) Разработчик с опытом стоит немалых денег, часто бывает что
неоправданных
Что вы думаете по этому поводу? Если у вас стоит выбор брать молодого
разработчика, но с меньшим опытом и знаниями или же матерого
разработчика с 15-летним стажем, что вы выберете?
Igor Bondarenko
мне приходит разработчик который 15 лет только этим и занимался - возьму
его.
В остальных случаях - молодого, желательно после вуза и без собственного
мнения. Чаще всего в каждом проете есть свои собственные наработки. То есть
все равно придется учится писать именно для этого проекта по тем правилам
которые устоялись тут.
И сьньйору и джуниору.
Только джуниор не задает при этом глупых вопросов - типа - а зачем, я могу
предложить лучше.
Kononov Roman
1) Можно 10 лет делать одну и ту же операцию (например копипастить и стать профессионалом по копипасту), или 5 лет побывать во многих областях и получить гораздо больше опыта чем за 10 лет копипаста
2) Профессионалом или экспертом в любой области невозможно стать за короткий срок, взять для примера те же книги - "С++ за 21 день" - абсолютный фейк,на который все продолжают вестись и думать что программирование это легко и быстро.(кажись в обсуждении такого рода "самоучителей" был приведен интересный факт - Моцарт начал заниматься музыкой в 3 года, а первые профессиональные произведения он начал писать в 13 лет, ссылку можно погуглить статья была популярная)
что касается темы обсуждения я думаю что тут все упирается в человека и должность,команду,условия,проект - контекст рулит и будет рулить ни смотря ни на что. Нельзя вывести какой либо обобщенный ответ кто лучше - прошедший крым и рым молодой или старый опытный копипастер, все зависит от контекста.
Pavel Aksonov
берут возрастных девелоперов, потому
что остальная команда - намного младше. Я с этим согласен, поэтому
смотрю на диапазон 23-35 лет. Возможно это неправильно. Был у меня 42
летний на собеседовании,
и полностью впечатление остались такие же как и у Коли.
Но мне кажется, что все-таки возрастной и опытный - это не всегда
синонимы. Скажем уже в 30 лет можно иметь достаточно серьезный опыт в
10 лет и я с удовольствием
возьму такого человека на работу с большим удовольствием чем 23
летнего с 3 летним опытом (при прочих равных, в том числе и зарплате).
Также 28 с 8 годами опыта или 25 летний с 5 годами для меня
будет более предпочтителен чем 23 с 3 (опять повторюсь, если они
проявят себя одинаково на собеседовании)
И если брать двух разработчкив с одинаковым возрастом, но разным
опытом - я возьму более опытного.
Опыт значит многое и я убедился в этом лично. Даже супер талантливый и
способный человек не может знать и перепробовать всего. Да, он
потенциально сможет разобраться с проблемами,
но это потребует времени, времени в твоей компании, на твоем проекте.
Недавний пример - я спрашивал тебя на тренинге про OutOfMemory
ошибки в tomcat при re-deployе и ты прислал много информации (за что
огромное спасибо) по поиску leakов и путей решения.
Уверен, что изучение этого вопроса у тебя заняло не один час в
прошлом. Какая вероятность, что у разработчика с меньшим опытом будет
этот опыт? Вероятность меньше. Тоже самое с hibernate - там много всяких
тонкостей ("граблей"), на которые обычно все наступают и на этом
учатся. У меня был очень талантливый программист, он разбирался с
всеми такими "граблями" проходя их и это забирало время. Более опытный
- проходил бы их на основе своего прошлого опыта.
Резюмирую. Опыт для меня играет роль. Также огромную роль играет
способность и желание учиться и рости дальше. Так как первое, без
второго - безсмысленно для IT.
Отвечая на твой вопрос - я выберу первое. Но лучше - третий, средний
вариант (не матерый, но и не молодой с 10 лет опыта :)
Borys Lebeda
У разработчиков с большим опытом работы есть один огромный плюс -
накопленный багаж знаний и опыта, который он может использовать
самостоятельно или же передавать другим. С некоторыми из них очень
приятно общаться и польза от них просто неоценима.
Но все же позволю себе сформулировать ряд наблюдений из жизни:
1) Факт, доказанный учеными - с возрастом мозг становится менее
активным, человеку начинает быть свойственно быстрее забывать
информацию, тяжелее усваивать большие объемы новой информации
2) Человек в возрасте менее склонен воспринимать изменения, он
сопротивляется им, особенно когда они противоречат его личному опыту в
прошлом
3) Опытный разработчик в возрасте чаще всего скептик, который считает
что его опыт и знания позволяют ему не соглашаться и продавливать
решения в спорных вопросах
4) Разработчик в возрасте часто не потерпит чтобы кто-то младше него
стоял сверху по служебной лестнице и будет всячески сопротивляться и
вставлять палки в колеса
5) Разработчик в возрасте меньше изучает новые технологии, фреймворки,
практики даже просто потому что ему это уже не так интересно, у него
есть семья и дети, у него нету свободного времени
6) Наконец очень многих опытных разработчиков компании держат в очень
узком русле (к примеру тюнинг DB2 или разработка драйверов к USB
устройствам на C++). Когда такой человек хочет поменять компанию и
заявляет что его опыт в C++ уже больше 10 лет, то он лукавит, потому
что его узкопрофильные знания могут быть низкоприоритетными для новой
компании
7) Разработчик в возрасте редко меняет работу (и даже задумывается о
ее смене). Это происходит потому что у него уже есть семья, куча
обязательств и ему не так просто изменить что-то в жизни
8) Разработчик с опытом стоит немалых денег, часто бывает что
неоправданных
Что вы думаете по этому поводу? Если у вас стоит выбор брать молодого
разработчика, но с меньшим опытом и знаниями или же матерого
разработчика с 15-летним стажем, что вы выберете?
--
Borys L.
RomanOksyukovski
В своей практике я стараюсь прагматично смотреть на вопрос возраста
кандидата и исхожу из целей и потребностей отдельно взятого проекта.
Считаю, что при найме любого человека в команду стоит оценивать и
определять исключительно способность кандидата эффективно выполнять
обязанности, которые определены для конкретной позиции в команде. Для
определения этой способности, на мой взгляд, как минимум, необходимо
оценить кандидата по след. направлениям:
* общая "эрудиция" и кругозор;
* техническая компетенция кандидаита с учетом специфики задач
определенной позиции;
* навыки межличностного общения с учетом "атомсферы" и динамики
взаимоотношений в команде проекта;
* другие навыки и способности.
Для определения общей эрудиции можно воспользоваться различными
логическими задачами, тестами и т.п.
При оценке технической компетенции обычно проверяют образование
кандидата, опыт работы, технические знания (теоритические вопросы и
практические задания).
Навыки межличностного общения я обычно проверяю просто пообщавшись с
кандидатом.
Так вот, если простыми словами, то возраст кандидата для меня не
играет никакого значения в случае, когда техничесие навыки, опыт
работы с необходимыми технологиями, уровень независимости в принятии
рещений (для себя называю это термином "внутренняя свобода"),
способность мыслить нестандартно (опять же, если необходимо для
позиции), способность эффективно общаться с коллегами и(!)
максимальное соответствие атмосфере и культуре команды кандидата
похожи на мои ожидания.
Из этого получается, что для себя, как для руководителя, я определяю
список критериев, по которым нужно оценить кандидата, а также стараюсь
производить детальный анализ позиции, на которую планирую набор.
Да, еще и деньги ;)
Borys Lebeda
в тим/тех лиды в вашей компании - это очень грустно. Позиция недаром
называется Lead. На этой позиции должен быть лидер, который может
принимать решения и брать на себя ответственность, при этом технически
подкованный не меньше чем остальные члены команды. А то, что это
"наименьший лунатик из всех остальных" просто порвало меня на части.
Alimenkou Nikolay
обязательно было на собеседовании решать логические задачки для того
чтобы определить уровень мышления. Способ может быть и не самый
лучший, но за неимением лучшего приходилось действовать так. Так вот
немного статистики: для людей старше 30 лет большая часть либо не
решало ни одной либо отказывалась решать их вообще с аргументацией "Не
хватало мне еще в Х лет задачки решать. Вы программера ищете или
кого?". При этом народ помоложе (18-25) обязательно брался и многие
справлялись с несколькими задачками или просто показывали свои мысли.
Yaroslav Gnatyuk
Anton Naumov
поискать скалу по-удобнее.
> Но все же позволю себе сформулировать ряд наблюдений из жизни:
> 1) Факт, доказанный учеными - с возрастом мозг становится менее
> активным, человеку начинает быть свойственно быстрее забывать
> информацию, тяжелее усваивать большие объемы новой информации
Мозг, как и весь прочий организм, необходимо поддерживать в тонусе. Во
всяком случае ни за собой, ни за своими друзьями, некоторым из которых
гораздо больше 30 подобных тенденций не наблюдал.
> 2) Человек в возрасте менее склонен воспринимать изменения, он
> сопротивляется им, особенно когда они противоречат его личному опыту в
> прошлом
Это еще одно испытание рациональности, нужности и рискованности Ваших
изменений. С каких пор это стало злом? Если человек адекватен,
настроен на работу и понимает, что такое командная работа он не станет
спорить ради спора. Ему не нужно показывать, что он соотвествует той
должности, на которую его взяли. За него уже говорят и резюме, и
рекомендации, и друзья.
> 3) Опытный разработчик в возрасте чаще всего скептик, который считает
> что его опыт и знания позволяют ему не соглашаться и продавливать
> решения в спорных вопросах
Продавливать -- нет, говорить, когда остальные молчат -- да. Тут очень
остро стоит вопрос целей. Если нужны исполнители без собственного
мнения -- тогда конечно люди взрослые и состоявшиеся не нужны.
> 4) Разработчик в возрасте часто не потерпит чтобы кто-то младше него
> стоял сверху по служебной лестнице и будет всячески сопротивляться и
> вставлять палки в колеса
Стереотип.
> 5) Разработчик в возрасте меньше изучает новые технологии, фреймворки,
> практики даже просто потому что ему это уже не так интересно, у него
> есть семья и дети, у него нету свободного времени
Стереотип. Вы, Николай, действительно думаете, что семья и дети МЕШАЮТ
разработке программного обеспечения? И второе, с чего вдруг Вы
претендуете на СВОБОДНОЕ время разработчиков? Работодателя интересует
прежде всего рабочее время. Во всяком случае должно интересовать.
> 6) Наконец очень многих опытных разработчиков компании держат в очень
> узком русле (к примеру тюнинг DB2 или разработка драйверов к USB
> устройствам на C++). Когда такой человек хочет поменять компанию и
> заявляет что его опыт в C++ уже больше 10 лет, то он лукавит, потому
> что его узкопрофильные знания могут быть низкоприоритетными для новой
> компании
Не могли бы Вы более подробно описать кто, а главное как держит
"многих опытных разрабочиков в очень узком русле"? Цепями их
приковывают, доступ в интернет закрывают?
> 7) Разработчик в возрасте редко меняет работу (и даже задумывается о
> ее смене). Это происходит потому что у него уже есть семья, куча
> обязательств и ему не так просто изменить что-то в жизни
Стереотип. Лично для меня факт смены работы мало коррелирует с моими
личными обязательствами. Размер компенсации, социальные плюшки,
соотношение свободного времени к рабочему -- да, а сам факт -- нет.
> 8) Разработчик с опытом стоит немалых денег, часто бывает что
> неоправданных
Опять-таки стереотип.
> Что вы думаете по этому поводу? Если у вас стоит выбор брать молодого
> разработчика, но с меньшим опытом и знаниями или же матерого
> разработчика с 15-летним стажем, что вы выберете?
Того, который прийдет работать в моей команде для достижения
поставленной цели. Без привязки к дате рождения. Если же ВСЕ остальные
условия равны -- разумеется опытного разработчика.
Anton Naumov
Alimenkou Nikolay
например на пост как все плохо в Украине с разработчиками писал бы
гневные отзывы "Да нет же, позвольте, я знаю неплохих. И еще Вася из
Одессы". Я вовсе не утверждаю что такие все и не предлагаю не брать на
работу по возрастному признаку. Я поделился наблюдениями из жизни.
Поучаствовал недавно в конференции http://softwarepeople.ru/ и как раз
увидел там подавляющее большинство людей в возрасте. Были очень
опытные и грамотные. Но было достаточно, кто читает по одной книге в
год и претендует на огромный опыт в разработке, а при этом меряет
людей количеством произведенного кода. Были и те, кто выставляет лет
по 15 в разработке, а задает вопрос "А за ваши юнит тесты кто платить
будет?" и с видом победителя рассказывает что в его коде багов не
бывает вот уже как 7 лет, а все остальные уроды.
Я заметил что молодые готовы развиваться и бороться за роль в команде
и свой экспертный уровень больше нежели люди в возрасте. И это опять
таки не про всех.
И еще - стереотипы придуманы не на пустом месте.
Вопрос:
> Не могли бы Вы более подробно описать кто, а главное как держит
> "многих опытных разрабочиков в очень узком русле"? Цепями их
> приковывают, доступ в интернет закрывают?
Ответ: Человека загружают на 100% на нескольких проектах (возможно на
всю компанию) узкопрофильными задачами. Времени на что-то другое и
интересное у него не остается, да компании и не надо.
Вопрос:
> И второе, с чего вдруг Вы
> претендуете на СВОБОДНОЕ время разработчиков?
Ответ: На собеседовании человек говорит что знает технологию X, но
ничего по ней не помнит, а если понадобится вспомнит за пару дней. И
таких технологий X целая пачка. Как по мне, так это проблемы человека
и ему (если он сознательный) нужно вечерком что-то прочитать и
освежить в памяти, а не привносить в проект риски с тем, во что
выльется его воспоминания по времени.
Yaroslav Gnatyuk
Artjom Serdyuk
А вот эту бы даму вы бы взяли на работу? http://distantnik.livejournal.com/116949.html
On Jul 6, 1:49 pm, Alimenkou Nikolay <lumii.subscri...@gmail.com>
wrote:
Artem Marchenko
скажем так.
Может сферический конь в вакууме и выглядит похоже на сферу, но в
реальной жизни похож больше на лошадку.
Периодически сталкиваюсь с опытными разработчиками и в подавляющем
большинстве случаев не променял бы их ни на какого "студента с
горящими глазами" и даже "яркого тим-лида с пятилетним стажем".
Исключения бывают везде, но по моим наблюдениям (прежде всего
Финляндия, немного Штаты и Англия) со временем те, кому возраст
мешает, уходят сами. Кто в менеджмент, кто в консультанты, кто в свою
фирму, кто в админы. Кто-то, разумеется, остаётся мало чем
интересующимся программистом. Но таких, во-первых, не очень много, а
во-вторых - видно за километр и на любом собеседовании сомнений не
возникнет.
ИМХО, работа программиста и тестера, и, наверное, сопутствующих ролей
настолько динамичная и требовательная, что 10-15 лет ей могу
заниматься либо те, кому это действительно нравится, либо те, кому
больше совсем некуда идти.
С уважением,
Артём.
On Jul 6, 1:49 pm, Alimenkou Nikolay <lumii.subscri...@gmail.com>
wrote:
Pavel Aksonov
Расскажите, у кого был ли реальный опыт молодой команды (23-30) с одни
возрастным программистом (40+ ) (не в качестве тим-лида)?
Alimenkou Nikolay
помнит. Но лично я бы не рискнул.
On Jul 6, 5:33 pm, Artjom Serdyuk <artem.serd...@gmail.com> wrote:
> Ой как в тему ))))
>
> А вот эту бы даму вы бы взяли на работу?http://distantnik.livejournal.com/116949.html
Anton Naumov
> например на пост как все плохо в Украине с разработчиками писал бы
> гневные отзывы "Да нет же, позвольте, я знаю неплохих. И еще Вася из
> Одессы". Я вовсе не утверждаю что такие все и не предлагаю не брать на
> работу по возрастному признаку. Я поделился наблюдениями из жизни.
Ну что делать, возраст :)
> Были и те, кто выставляет лет
> по 15 в разработке, а задает вопрос "А за ваши юнит тесты кто платить
> будет?" и с видом победителя рассказывает что в его коде багов не
> бывает вот уже как 7 лет, а все остальные уроды.
Ну как бы слово характеризует в первую очередь говорящего. Да, таких
персонажей мы все знаем. Только это не от опыта зависит, а от
культуры. И подобное поведение как-раз говорит о том, что в своем
опыте и уровне экспертизы человек не уверен. Это компенсаторный
механизм комплексов.
> Я заметил что молодые готовы развиваться и бороться за роль в команде
> и свой экспертный уровень больше нежели люди в возрасте. И это опять
> таки не про всех.
"Бороться за роль в команде" -- это за "лычки" чтоли? Так если джуниор-
мидл освоит в Cruise Control, Maven, TeamCity, Mercurial, SVN, то
будет на одного человека больше, который это ЗНАЕТ. Им это намного
полезнее, чем мне, который уже знает и так. А я помогу, подскажу,
покажу, расскажу. По-моему это правильное поведение. Иначе так и будут
джуниоры-мидлы сидеть и ждать дядю, который прийдет и все настроит. Я
в чем-то оишбся?
> И еще - стереотипы придуманы не на пустом месте.
Давайте не будем? Клише в человеческих взаимоотношениях есть зло,
потому что мешают рассмотреть человека за мишурой из возраста, пола,
национальности, социального статуса, разреза глаз, предпочтений в
одежде, физических данных и прочих менее значительных факторов. И это
в то время, когда нас, как потенциального работодателя, должны
интересовать профессиональные качества человека и его способность
работать в команде.
> Вопрос:
> > Не могли бы Вы более подробно описать кто, а главное как держит
> > "многих опытных разрабочиков в очень узком русле"?
> Ответ: Человека загружают на 100% на нескольких проектах (возможно на
> всю компанию) узкопрофильными задачами. Времени на что-то другое и
> интересное у него не остается, да компании и не надо.
Стереотип. Если другое что-то действительно интересное, как минимум
почитать обзоры и потыкать пальцем время всегда найдется.
> Вопрос:
> > И второе, с чего вдруг Вы
> > претендуете на СВОБОДНОЕ время разработчиков?
> Ответ: На собеседовании человек говорит что знает технологию X, но
> ничего по ней не помнит, а если понадобится вспомнит за пару дней. И
> таких технологий X целая пачка. Как по мне, так это проблемы человека
> и ему (если он сознательный) нужно вечерком что-то прочитать и
> освежить в памяти, а не привносить в проект риски с тем, во что
> выльется его воспоминания по времени.
Хозяин Ваших рисков -- человек взявший такого "специалиста" на работу.
Я могу не помнить -- и довольно часто не помню -- деталей, каких-то
трюков в той или иной предметной области. Но НИЧЕГО не помнить, а
потом вспомнить ЗА ПАРУ ДНЕЙ -- очень похоже на вранье. Проведите еще
одно собеседование через ПАРУ дней. В данном случае это проблемы уже
руководства проекта. Опять-таки, есть еще испытательный срок, на
котором загрузка все-равно минимальна. Важно только одно, если Вы
взяли человека на работу -- это Ваши риски. И Вам за них отвечать.
Anton Naumov
> А вот эту бы даму вы бы взяли на работу?http://distantnik.livejournal.com/116949.html
Нейробиологом? Безусловно, если бы госпожа Леви-Монтальчини соизволила
оказать мне такую честь. И приставил бы к ней пару шустрых студентов,
который бы ходили и записывали, ходили и записывали.
Anton Naumov
> возрастным программистом (40+ ) (не в качестве тим-лида)?
В паралелльной команде считается? Я был причастен к проекту в качестве
консультанта. Проблем в профессиональном общении никаких. Польза
огромна, причем не только прямая -- проектная, но и косвенная. В
общениях "за кофе" я узнал массу интересного о внутреннем мире MSSQL и
его различных версиях. Экспертом я конечно не стал, но... Плюс, мы
делали внутренний тренинг по базам где данный сециалист выступал
докладчиком. Очень полезно.
Borys Lebeda
--
Borys L.
Borys Lebeda
Вопрос:
> И второе, с чего вдруг ВыОтвет: На собеседовании человек говорит что знает технологию X, но
> претендуете на СВОБОДНОЕ время разработчиков?
ничего по ней не помнит, а если понадобится вспомнит за пару дней. И
таких технологий X целая пачка. Как по мне, так это проблемы человека
и ему (если он сознательный) нужно вечерком что-то прочитать и
освежить в памяти, а не привносить в проект риски с тем, во что
выльется его воспоминания по времени.
Artjom Serdyuk
народу на интервью?
Например, мы задавали в своё время такую задачу соискателям:
Имеется 100-этажный небоскреб и два одинаковых стеклянных шарика. За
какое наименьшее число попыток можно с гарантией определить самый
низкий этаж, при бросании с которого шарики этого типа разбиваются?
On Jul 6, 1:49 pm, Alimenkou Nikolay <lumii.subscri...@gmail.com>
wrote:
Alimenkou Nikolay
написать функцию, которая будет проверять есть ли в этом списке цикл.
Alexander Rivkind
задач. Собеседование как правило - это стресс, на нем люди теряют до
30% IQ :)
Кроме того (отдельная тема? :) ) по моим наблюдениям, люди, хорошо
решающие головоломки не обязательно могут понять, что такое указатель.
Мне очень нравятся все задания напрямую связанные с профилем. Наверное
все эти статьи читали, но на всякий случай:
http://www.joelonsoftware.com/articles/fog0000000073.html
http://www.artima.com/wbc/interprog.html
Ну и мой рецепт "придумывания домашнего задания" - ACM.
2009/7/7 Alimenkou Nikolay <lumii.su...@gmail.com>:
--
Best Regards, Alik.
Anton Naumov
математических задач на собеседованиях. Собеседование в любом случае
есть стресс, а умение бодро решать задачи, в отрыве от персноальных и
профессиональных характеристик, есть всего лишь умение решать задачи.
Если персонально и профессионально человек подходит, решит он задачу
или нет не важно, ему в любом случае найдется работа.
А делать что-то только потому, что так делают в Microsoft или Google
мне не кажется разумным.
Что касается писания кода на интервью на бумажке, я категорически
против. Это усугубляет стресс еще больше, чем задачи. Человек начинает
нервничать, у него нет под рукой компилятора, интернет, документации
по API... Шанс на то, что человек окажется в ситуации, когда ему
прийдется работать в такой форме бесконечно стремится к нулю. А знания
можно проверить и без этого. Другое дело, если человек сам попросит
ручку и бумагу, чтобы набросать функцию.
On 7 Лип, 10:59, Artjom Serdyuk <artem.serd...@gmail.com> wrote:
Artjom Serdyuk
А кстати, никто и не обещал, что на них будет комфортно )) это тоже
определённый тест, нет?
Alexander Rivkind
наследование, он просит листик и ручку. :)
(Исключение составляют люди, которые сразу упоминают diamond problem -
им ничего рисовать не надо)
2009/7/7 Anton Naumov <grays...@gmail.com>:
--
Best Regards, Alik.
Sergiy Movchan
> 6) Наконец очень многих опытных разработчиков компании держат в оченьНе могли бы Вы более подробно описать кто, а главное как держит
> узком русле (к примеру тюнинг DB2 или разработка драйверов к USB
> устройствам на C++). Когда такой человек хочет поменять компанию и
> заявляет что его опыт в C++ уже больше 10 лет, то он лукавит, потому
> что его узкопрофильные знания могут быть низкоприоритетными для новой
> компании
"многих опытных разрабочиков в очень узком русле"? Цепями их
приковывают, доступ в интернет закрывают?
--
...dali bude...
Michael Naoumov
Один цикл достает следующий элемент, а второй достаёт через один
элемент. Если они через некоторое время окажутся на одном элементе, то
цикл есть. Иначе список рано или поздно закончится.
Задача про шарики. Нужно 14 попыток.
Бросаем по очереди со следующих этажей до тех пор, пока шарик не разобьётся.
14 27 39 50 60 69 77 84 90 95 99 100
Например шарик разбился на 39 этаже. Значит до этого было сделано
(14,27,39) 3 броска.
Чтобы теперь выяснить на каком из 28-39 этажей шарик начал биться,
нужно ещё 11 бросков. (28-38)
Всего 14.
Доказательство того, что меньше 14 нельзя - несложное, но громоздкое.
7 июля 2009 г. 12:07 пользователь Alimenkou Nikolay
(lumii.su...@gmail.com) написал:
Anton Naumov
Вероятно я не совсем понял суть Вашего вопроса, но я попытаюсь
ответить.
Я не оригинален в данном случае и общий свой стиль позаимствовал у
старших коллег, так сказать вывел некое среднее из своего обширного
опыта соискания работы. Как правило есть набор вопросов -- большой
список, который составлен для конторы целиком и малый список, который
составлен для проекта. Если таковых списков нет, то вопросы по
концепиям ООП, Java Core, по технологиями и фрэйморкам, которые
используются в проекте и одновременно имеют место в резюме соискателя.
Если резюме соискателя совсем-совсем бедное на технологии, то я
интересуюсь теоретическими знаниями технологий и фрэймворков, которые
используются в проекте. Причем списков вопросов тем меньше, чем более
уверенно соискатель отвечает.
Для Senior Developers список вопросов, как мне кажется, должен быть
максимально короткми. А основное внимание следует уделить problem
solving, мы подразумеваем, что Senior Developer технлогии и фрэймвоки
знает.
Ну и вопросы относительно специфики командной работы, "глупых" решений
руководства и прочия, и прочия.
Вот примерно так.
> А кстати, никто и не обещал, что на них будет комфортно )) это тоже
> определённый тест, нет?
Мне кажется, что нет. Или я отвечу вопросом, это определенный тест на
что? На то как человек работает под давлением? Я Вас уверяю, один и
тот же человек под давлением разных причин работает совершенно по-
разному. Вы ведь не знаете, с чем человек пришел на собеседование.
Может быть, если он сейчас не найдет работу, через месяц к нему
кредиторы явятся, проводить опыты по термально-ректальному
криптоанализу. Или может быть какие-то другие, не менее важные
проблемы зависят от того, получит человек место или нет. И уж
однозначно по-разному человек будет работать в ситуации, когда он,
образно выражаясь, один против мира или у него за плечами надежная
команда. Так что я считаю, что проводить тест на стрессоусточивость
собеседованием излишне. Слишком велика погрешность.
Alexey Tigarev
> Задача про список.. Нужно запустить одновременно два цикла по списку.
> Один цикл достает следующий элемент, а второй достаёт через один
> элемент. Если они через некоторое время окажутся на одном элементе, то
> цикл есть. Иначе список рано или поздно закончится.
Не сильно ли замудренно?
На мой взгляд, достаточно пройтись по списку вперёд, добавляя элементы
в хэш. Как только очередной элемент есть в хэше - всё, цикл. Сложность
O(N).
--
С уважением, Алексей Тигарев
<ti...@nlp.od.ua> Jabber: ti...@jabber.od.ua http://t_gra.livejournal.com/
Alexander Rivkind
2009/7/7 Alexey Tigarev <alexey....@gmail.com>:
--
Best Regards, Alik.
Alexander Rivkind
Например если надо оптимизировать скорость, но не память, то можно
просто идти под списку нумерую элементы. Как только попадаем на
пронумерованный элемент - цикл. Вот тут точно O(N). :)
Если я, конечно, правильно понял условие...
2009/7/7 Alexander Rivkind <alik...@gmail.com>:
--
Best Regards, Alik.
Michael Naoumov
дополнительной памяти. Моё решение использует минимум памяти. И
теоретически не имеет предела в длине списка
7 июля 2009 г. 16:23 пользователь Alexander Rivkind
(alik...@gmail.com) написал:
Michael Naoumov
Цикл в цикле.
Внешний цикл бегает по элементам x и инкриментирует счётчик.
Второй бегает с начала до элемента x и тоже инкрементирует свой счётчик.
Если оба счётчика совпали, то элемент x не лежит в цикле.
Иначе - цикл есть
7 июля 2009 г. 16:44 пользователь Michael Naoumov (mnao...@gmail.com) написал:
Anton Naumov
> Другое решение со счётчиками.
> 7 июля 2009 г. 16:44 пользователь Michael Naoumov (mnaou...@gmail.com) написал:
> > По-моему эта задача должна быть решена без использования
> > дополнительной памяти. Моё решение использует минимум памяти. И
> > теоретически не имеет предела в длине списка
> > 7 июля 2009 г. 16:23 пользователь Alexander Rivkind
> >> Тут важен криетрий оптимизации.
> >> 2009/7/7 Alexander Rivkind <alik1...@gmail.com>:
> >>> А какая у тебя скорость поиска в кеше для каждого элемента? :)
Джентельмены, мне показалось или мы все-таки несколько ушли в
оффтопик? :)
Michael Naoumov
Пруфтопик:
On 7 Лип, 10:59, Artjom Serdyuk <artem.serd...@gmail.com> wrote:
> Коллеги! А давайте делиться вопросами и задачами, которые вы даётё
> народу на интервью?
7 июля 2009 г. 16:54 пользователь Anton Naumov (grays...@gmail.com) написал:
Alexander Rivkind
Тема "интервью" такая обширная, из нее мы не ушли. Но от возраста отклонились.
Не удержусь и прокоментирую "По-моему эта задача должна быть решена
без использования дополнительной памяти. Моё решение использует
минимум памяти. И теоретически не имеет предела в длине списка"
В одной из статей (не помню в какой, может даже в одной из тех, на
которые я дал выше ссылки) приведен очень хороший пример. На одном из
собеседований на бизнес аналитика кандидата попросили нарисовать
домик. Кандидат сразу взялся рисовать красивый функциональный домик.
Интервьюруемый подождал пока тот дорисует и уточнил: "это дом для
слепых жирафов". Какая мораль? Не надо придумывать требования. Если
они не ясны из постановки задачи, надо задать уточняющий вопрос. Об
оптимальности решения в задаче вообще не было требования. Но поскольку
наш опыт подсказывает, что какие-то требования к памяти, скорости, и
т.п. как правило есть, то я бы задал уточняющий вопрос. ;)
2009/7/7 Michael Naoumov <mnao...@gmail.com>:
--
Best Regards, Alik.
sun
--
sun
Alexander Rivkind
Интервьюруемый -> Интервьюрующий :)
2009/7/7 Alexander Rivkind <alik...@gmail.com>:
--
Best Regards, Alik.
Sergiy Movchan
--
...dali bude...
Alimenkou Nikolay
же могу и потяжелее скинуть задачки.
On Jul 7, 3:57 pm, Michael Naoumov <mnaou...@gmail.com> wrote:
> Задача про список.. Нужно запустить одновременно два цикла по списку.
> Один цикл достает следующий элемент, а второй достаёт через один
> элемент. Если они через некоторое время окажутся на одном элементе, то
> цикл есть. Иначе список рано или поздно закончится.
>
> Задача про шарики. Нужно 14 попыток.
> Бросаем по очереди со следующих этажей до тех пор, пока шарик не разобьётся.
> 14 27 39 50 60 69 77 84 90 95 99 100
>
> Например шарик разбился на 39 этаже. Значит до этого было сделано
> (14,27,39) 3 броска.
> Чтобы теперь выяснить на каком из 28-39 этажей шарик начал биться,
> нужно ещё 11 бросков. (28-38)
> Всего 14.
> Доказательство того, что меньше 14 нельзя - несложное, но громоздкое.
>
> 7 июля 2009 г. 12:07 пользователь Alimenkou Nikolay
> (lumii.subscri...@gmail.com) написал:
Alexander Rivkind
не имеет смысла.
Для джавистов у меня есть другие не менее интересные вопросы.
В остальном поддерживаю в целом. Но есть отдельные случаи. Например
если мне нужен программист, который будет реализовавывать algorithmic
trading. Если он "не помнит" институтскую математику, мне он не
подойдет. Ему и так придется разбираться в куче сложных вещей.
Хотя, видел людей, которые "забытые формулы" выводили или просто
начинали рассуждать в правильном направлении... короче,
демонстрировали понимание. Это тоже нормально. Но при этом тот, кто
"помнит", имеет больше шансов.
2009/7/7 sun <aleksey....@gmail.com>:
--
Best Regards, Alik.
Alimenkou Nikolay
поиск быстрый делал. Решение неоптимальное по ресурсам.
On Jul 7, 4:19 pm, Alexey Tigarev <alexey.tiga...@gmail.com> wrote:
> 2009/7/7 Michael Naoumov <mnaou...@gmail.com>:
Alimenkou Nikolay
решить проблему логически, а уже потом ее кодить. И тут он начинает
городить. Решить задачу - это не критерий отбора, а плюс для человека,
которого отбирают. Это показывает что он может нормально работать при
стрессе и не теряться и умеет логически быстро мыслить. В свое время
даже если человек больше ничего не знал мы его брали на курсы
внутренние (потому что он толковый). В результате получали классных
разработчиков.
AvP
> Бросаем по очереди со следующих этажей до тех пор, пока шарик не разобьётся.
> 14 27 39 50 60 69 77 84 90 95 99 100
Поиск делением, при 100 элиментах максимум 7 сравнений. Формулу не
помню.
sun
Если он java программист, то сам вопрос про виртуальное наследование
не имеет смысла.
Для джавистов у меня есть другие не менее интересные вопросы.
В остальном поддерживаю в целом. Но есть отдельные случаи.
Например
если мне нужен программист, который будет реализовавывать algorithmic
trading. Если он "не помнит" институтскую математику, мне он не
подойдет. Ему и так придется разбираться в куче сложных вещей.
--
sun
Michael Naoumov
доказать, что их недостаточно.
7 июля 2009 г. 17:28 пользователь AvP (apyro...@gmail.com) написал:
Serge Levin
2009/7/7 Michael Naoumov <mnao...@gmail.com>:
Michael Naoumov
ответа не знаю. Приятель рассказывал, что на Java собеседовании его
спросили в чём смысл кода
if (this == null)
{
...;
}
В .Net смысл есть, так как оператор == можно перегрузить. Зачем это в
Java я не знаю.
Разве что для "индусского" кода, где важно количество строчек.
Но тогда круче писать так
if (false)
{
...;
}
:)
7 июля 2009 г. 18:14 пользователь Serge Levin (srg...@gmail.com) написал:
Anton Naumov
Вау! Да это же бубль гум. Одна большая и известная в прошлом локально
харьковская, а ноне общеукраинская контора очень любит задавать на
собеседованиях и в письменных тестах вот такие вот задачи. А еще очень
популярно употребить все возможные операторы языка. Я так и не смог за
10 лет понять зачем :)
> А зачем человеку помнить саму реализицию алгоритма нахождения циклических
> зависимостей?
> К примеру мой мозг устроен так, что он не держит в голове ненужной на данный
> момент информаиции, она закидывается в самые далёкие участки мозга. Это
> может быть как результат последнего финала лиги чемпионов, так и сигнатуры
> методов HttpServlet.
Мы с Вами коллега, никогда не будем работать минимум в двух конторах.
Потому что мой мозг устроен точно также. И область моих интересов
несколько шире, нежели программирование. С другой стороны, а велико ли
счастье в тех конторах работать? :)
> Технический уровень важен, только тогда когда человек прошёл тест на
> адекватность, рассказав о том, почему он ушёл с прошлой работы, рассказав
> про свою самую инересную задачу за последние пол года, сумел и показать
> насколько он владеет современной терминологией.
А вот тут не согласен. Совсем. Не имеет смысла выяснять, насколько
Василий хороший человек и командный игрок, если мы пригласили Василия
на собеседование по вакансии Senior Java Developer, а Василий оказался
COBOL guru. Так что технический уровень важен. Другое дело, что для
его подтверждения не обязательно иметь степень доктора математических
наук.
Constantine Karnacevych
при поиске методом деления на 2 может потребоваться больше 2-х шариков,
коих по условию задачи нет.
sun
По поводу задач на собеседовании вспоминаю одну на которую до сих пор
--
sun
Michael Naoumov
ключевое слово this, компилятор не пропустит
7 июля 2009 г. 18:29 пользователь sun (aleksey....@gmail.com) написал:
sun
А вот тут не согласен. Совсем. Не имеет смысла выяснять, насколько
Василий хороший человек и командный игрок, если мы пригласили Василия
на собеседование по вакансии Senior Java Developer, а Василий оказался
COBOL guru. Так что технический уровень важен. Другое дело, что для
его подтверждения не обязательно иметь степень доктора математических
наук.
--
sun
sun
--
sun
Anton Naumov
> не имеет смысла.
> Для джавистов у меня есть другие не менее интересные вопросы.
Поделитесь? Можно приватно.
> В остальном поддерживаю в целом. Но есть отдельные случаи. Например
> если мне нужен программист, который будет реализовавывать algorithmic
> trading. Если он "не помнит" институтскую математику, мне он не
> подойдет. Ему и так придется разбираться в куче сложных вещей.
Согласен, но с небольшим дополнением, это следует одтельно отметить в
job description. С другой стороны, если программист подходит во всем,
кроме знания институтской математики... У него будет испытательный
срок, чтобы ее вспомнить. По-моему так. Вообще забавная вещь память,
года два назад мне пришлось помогать знакомой поступать на заочный. И
там были вступительные экзамены по математике, в которых нужно было
порешать... тригонометрические задачи. В 1996 году, когда я последний
раз решал тригонометрические задачи, я прекрасно разбирался во всех
этих забавных латинских буквах :) Я решил, что мне пора на свалку, но
взял справочник и нашел базовые формулы. Удивительно, но через 30
минут у меня снова начало получатся. Этот спич к тому, что человек
может действительно не понмнить институтскую математику. И не факт,
что ему прийдется приложить титанические усилия для того, чтобы все
вспомнить.
> Хотя, видел людей, которые "забытые формулы" выводили или просто
> начинали рассуждать в правильном направлении... короче,
> демонстрировали понимание. Это тоже нормально. Но при этом тот, кто
> "помнит", имеет больше шансов.
В данном случае преимущество имеет выпускник профильного факультета с
опытом подработки в пару лет :)
Alexander Rivkind
>> Если он java программист, то сам вопрос про виртуальное наследование
>> не имеет смысла.
>> Для джавистов у меня есть другие не менее интересные вопросы.
>
> Поделитесь? Можно приватно.
>
В общем-то джависта можно спросить "почему в джаве нет множественного
наследования".
Можно спросить про double check locking.
Можно спросить про принципы работы GC.
Можно по паттернам поговорить. Например про lazy factory. Сравнить с
singleton. Поговорить про thread safety.
Короче, мой подход - после набора стандартных банальных вопросов
задать один на "поговорить". Возможно провокационный. Возможно занять
неверную позицию и дать возможность кандидату отстоять правильную
версию. Тут главное оставаться в конструктивном русле. Ну и не тратить
на это много времени.
>> В остальном поддерживаю в целом. Но есть отдельные случаи. Например
>> если мне нужен программист, который будет реализовавывать algorithmic
>> trading. Если он "не помнит" институтскую математику, мне он не
>> подойдет. Ему и так придется разбираться в куче сложных вещей.
>
> Согласен, но с небольшим дополнением, это следует одтельно отметить в
> job description. С другой стороны, если программист подходит во всем,
> кроме знания институтской математики... У него будет испытательный
> срок, чтобы ее вспомнить. По-моему так. Вообще забавная вещь память,
> года два назад мне пришлось помогать знакомой поступать на заочный. И
> там были вступительные экзамены по математике, в которых нужно было
> порешать... тригонометрические задачи. В 1996 году, когда я последний
> раз решал тригонометрические задачи, я прекрасно разбирался во всех
> этих забавных латинских буквах :) Я решил, что мне пора на свалку, но
> взял справочник и нашел базовые формулы. Удивительно, но через 30
> минут у меня снова начало получатся. Этот спич к тому, что человек
> может действительно не понмнить институтскую математику. И не факт,
> что ему прийдется приложить титанические усилия для того, чтобы все
> вспомнить.
>
>> Хотя, видел людей, которые "забытые формулы" выводили или просто
>> начинали рассуждать в правильном направлении... короче,
>> демонстрировали понимание. Это тоже нормально. Но при этом тот, кто
>> "помнит", имеет больше шансов.
>
> В данном случае преимущество имеет выпускник профильного факультета с
> опытом подработки в пару лет :)
Не исключено. Как правило задачи будут на оптимальную реализацию
алгоритмов, а не грамотный дизайн классов или еще что.
Культура разработки тоже будет играть роль.
> >
>
--
Best Regards, Alik.
Anton Naumov
> решить проблему логически, а уже потом ее кодить. И тут он начинает
> городить.
Или спокойно решает проблему логически, или срашивает совета, или
сначала городит огород, а потом решает проблему логически. Понимаете,
Николай, в мире существует еще огромное количестов цветов и оттенков,
кроме черного и белого. Вариативность поведенческих реакций различных
людей в данной ситуации неизмеримо выше, чем Вы или я можем
представить в самых смелых фантазиях, а отнюдь не исчерпывается Вашим
или моим опытом. Поэтому проводить стастический анализ, а тем более
наверняка утверждать что-то в данной ситуации мне не представляется
мне возможным.
Ваш доклад по метрикам, который Вы делали этой весной (?) в Харькове,
был прекрасен, но увы не все можно померять.
> Решить задачу - это не критерий отбора, а плюс для человека,
> которого отбирают. Это показывает что он может нормально работать при
> стрессе и не теряться и умеет логически быстро мыслить.
Прочитайте пожалуйста внимательно мою последнюю реплику в сообщении,
на которое Вы ответили. Там я весьма подробно описал, почему я считаю,
что СОБЕСЕДОВАНИЕ не может показать, как человек будет РАБОТАТЬ при
стрессе.
> В свое время даже если человек больше ничего не знал мы его брали на курсы
> внутренние (потому что он толковый). В результате получали классных
> разработчиков.
Толкового человека можно и в проект взять. Я вот однажды взял. И не
ошибся. Только причем здесь логические задачи? Или в Вашем случае
толковый == отлично решает логические задачи на собеседованиях?
Anton Naumov
> наследования".
Вопрос из моего персонального большого списка. Именно в такой
формулировке :)
> Можно спросить про double check locking.
Спасибо.
> Можно спросить про принципы работы GC.
Еще один вопрос из персонального большого списка.
> Можно по паттернам поговорить. Например про lazy factory. Сравнить с
> singleton. Поговорить про thread safety.
Паттерны это практически обязательная часть программы. Равно как и
базовые прицнипы thread safety.
> Короче, мой подход - после набора стандартных банальных вопросов
> задать один на "поговорить". Возможно провокационный. Возможно занять
> неверную позицию и дать возможность кандидату отстоять правильную
> версию. Тут главное оставаться в конструктивном русле. Ну и не тратить
> на это много времени.
Аналогично.
Alexey Tigarev
А вот дополнительная память да, нужна.
2009/7/7 Alexander Rivkind <alik...@gmail.com>:
> А какая у тебя скорость поиска в кеше для каждого элемента? :)
> 2009/7/7 Alexey Tigarev <alexey....@gmail.com>:
>> 2009/7/7 Michael Naoumov <mnao...@gmail.com>:
Alimenkou Nikolay
задачи, по которым можно увидеть как быстро и продуктивно человек
способен мыслить и решать проблемы. Задача про горящие шнуры, шарики в
мешках и так далее. Тут не надо помнить никаких формул. Для того чтобы
у человека не возникало предположений что его пытаются занять ерундой
можно сформулировать похожие задачи на прикладном уровне в том языке
программирования, по поводу которого проходится собеседование.
А по одним только технологиям глупо отбирать людей, потому что при
определенном складе ума освоить фреймворк или технологию - плевое
дело. А куча людей использует годами, но так и не может объяснить
принцип Dependency Injection или IoC. А некоторые думаю что это слова
синонимы. :)
On Jul 7, 5:18 pm, sun <aleksey.solnt...@gmail.com> wrote:
> Diamond problem? А если он java программист? Задачки со школьной олимпиады
> по математики? А если он вдруг забыл что n*(n+1)/2 - это формула суммы
> арифметической прогрессии? Так что с ним теперь и не разговаривать дальше? А
> может его тогда ещё и добить вопросом про i+=i+++++i ?
>
> А зачем человеку помнить саму реализицию алгоритма нахождения циклических
> зависимостей?
> К примеру мой мозг устроен так, что он не держит в голове ненужной на данный
> момент информаиции, она закидывается в самые далёкие участки мозга. Это
> может быть как результат последнего финала лиги чемпионов, так и сигнатуры
> методов HttpServlet.
>
> Технический уровень важен, только тогда когда человек прошёл тест на
> адекватность, рассказав о том, почему он ушёл с прошлой работы, рассказав
> про свою самую инересную задачу за последние пол года, сумел и показать
> насколько он владеет современной терминологией.
>
> 2009/7/7 Alexander Rivkind <alik1...@gmail.com>
>
>
>
>
>
> > Например, когда спрашиваешь у человека для чего нужно виртуальное
> > наследование, он просит листик и ручку. :)
> > (Исключение составляют люди, которые сразу упоминают diamond problem -
> > им ничего рисовать не надо)
>
> > 2009/7/7 Anton Naumov <grayswan...@gmail.com>:
Borys Lebeda
--
Borys L.
Borys Lebeda
--
Borys L.
Alimenkou Nikolay
абсолютно бесполезных в реальной жизни как то что будет в результате
выполнения i=i++++i--. Ответ очень простой - не пиши так и не будешь
задумываться что получится. Или напиши тест и посмотри что получится.
Но в этой книге хватает и очень интересных вещей, которые просто
ОБЯЗАН знать КАЖДЫЙ, кто называет себя JAVA разработчиком. А
"Effective Java" просто обязан прочитать даже тот, кто уже не один год
разрабатывает на Java и думает что достиг совершенства.
И интереснее всего что практически все примеры из "Effective Java"
встречаются в жизни каждый день. И очень грустно наблюдать как люди
повторяют ошибку снова и снова. Так почему бы не узнать из таких ли
людей собеседуемый?
On Jul 7, 11:28 pm, Borys Lebeda <borys.leb...@gmail.com> wrote:
> Бррр .... Вообще говоря, для .Net выражение (this == null)
> тоже сомнительного качества ;)
> Перегрузить оператор конечно можно, но кто станет его перегружать, что бы
> такое выражение возымело смысл?
>
> Я помню читал замечательную книжку J. Bloch про всякие pitfalls в языке
> Java. Книжка очень занимательная и хотя большинство приколов не удаётся
> воспроизвести на .Net в те времена я работал на Java и даже поделился своими
> впечатлениями от прочитанного:http://atriplex-on-software.blogspot.com/2009/03/c-vs-java-slight-dif...
>
> Но большинство задач Блоха практического смысла не имеет. На интервью можно
> ими завалить и грамотного спеца!
>
> Другое дело, что если есть смысл в проведении креш-теста для кандидата ...
>
> 2009/7/7 sun <aleksey.solnt...@gmail.com>
>
>
>
>
>
> > Можно было бы предположить, что это какая-то проверка на статический класс
> > )
>
> > 2009/7/7 Michael Naoumov <mnaou...@gmail.com>
>
> >> По поводу задач на собеседовании вспоминаю одну на которую до сих пор
> >> ответа не знаю. Приятель рассказывал, что на Java собеседовании его
> >> спросили в чём смысл кода
> >> if (this == null)
> >> {
> >> ...;
> >> }
>
> >> В .Net смысл есть, так как оператор == можно перегрузить. Зачем это в
> >> Java я не знаю.
> >> Разве что для "индусского" кода, где важно количество строчек.
> >> Но тогда круче писать так
> >> if (false)
> >> {
> >> ...;
> >> }
>
> >> :)
>
> >> 7 июля 2009 г. 18:14 пользователь Serge Levin (srgy...@gmail.com)
> >> написал:
> >> > Для 7 нужно 5 шариков :) Думаю просто имелся ввиду бианрный поиск.
>
> >> > 2009/7/7 Michael Naoumov <mnaou...@gmail.com>:
> >> >> Не понял про 7 сравнений. Если имеется ввиду 7 бросков, то легко
> >> >> доказать, что их недостаточно.
>
> >> >> 7 июля 2009 г. 17:28 пользователь AvP (apyrozhe...@gmail.com) написал:
Serge Levin
.НЕТ выражение особого смысла не имеет. Зато имеет для С++, если
используется внутри не виратуальной функции.
Вот такой код на С++ компилируется, запускается и работает :)
Компилятор MS VC++ 2008.
#include "stdafx.h"
#include <iostream>
using namespace std;
class Foo
{
public:
void bar()
{
if (this == 0)
{
cout << "Are you crazy??!!";
return;
}
cout << "OK!";
}
};
int _tmain(int argc, _TCHAR* argv[])
{
Foo * foo = 0;
foo->bar();
return 0;
}
С уважением,
Сергей
2009/7/7 Borys Lebeda <borys....@gmail.com>:
Borys Lebeda
Если ты про "Java Puzzlers", то там достаточно много примеров
абсолютно бесполезных в реальной жизни как то что будет в результате
выполнения i=i++++i--. Ответ очень простой - не пиши так и не будешь
задумываться что получится. Или напиши тест и посмотри что получится.
Но в этой книге хватает и очень интересных вещей, которые просто
ОБЯЗАН знать КАЖДЫЙ, кто называет себя JAVA разработчиком. А
"Effective Java" просто обязан прочитать даже тот, кто уже не один год
разрабатывает на Java и думает что достиг совершенства.
Да. Точно. Про Java Puzzlers.
А какие вещи нужно оттуда знать?
Кроме как, то что 2 - 1.1 не даёт 0.9 (одно из тех что воспроизводится в .Net)
И интереснее всего что практически все примеры из "Effective Java"
встречаются в жизни каждый день. И очень грустно наблюдать как люди
повторяют ошибку снова и снова. Так почему бы не узнать из таких ли
людей собеседуемый?
Я не читал Effective Java (Я не джавист, мне можно :)). Но обычно люди которые не освобождают ресурсы, хендлера, коннекшены или колбасят макаронный код на собеседовании очень легко выявляются.
--
Borys L.
sun
--
sun
Alimenkou Nikolay
пример, которого должно быть достаточно:
try {
...
if (...) {
throw new IllegalStateException();
}
} finally {
...
throw new IllegalArgumentException();
}
В итоге всегда будет выброшен IllegalArgumentException, не смотря на
то что основной код тоже бросил эксепшен. Многие этого не знают.
On 8 Лип, 00:05, Borys Lebeda <borys.leb...@gmail.com> wrote:
> 2009/7/7 Alimenkou Nikolay <lumii.subscri...@gmail.com>
nvoynov
задает, какие ответы ожидает услышать, и что он сделал своими
руками ;)
Если коротко программирую уже где-то лет десять, а лет мне уже почти
35. Своими руками на Delphi / Interbase (десктоп-приложение + RDBMS +
Система построения отчетов) сделал где-то пяток учетных систем.
Две из них в глубокой молодости, и две в отрочестве. Могу сказать, что
самую первую систему на заказ делал в три раза дольше чем рассчитывал,
вторую ее версию с увеличенным где-то вдвое функционалом и другим
типом СУБД ровно в три раза меньше. Это заметка про первый проект.
Делали первый проект вдвоем с товарищем, но товарищ в конце первого
месяца устал и самоустранился, пришлось самому страдать. Собственно в
конце концов результат меня удовлетворил, т.к. чему-то я тут научился.
И тот первый проект, уже в своей третьей реинкарнации и поддержкой
другим человеком работает уже 10 лет без особых изменений дизайна что
внешнего что внутреннего. Согласитесь это довольно приятно. Дальше
было еще пару проектов, один из которых также до сих пор работает в
заочном деканате ХАИ. и еще один, который не потянул из-за масштаба и
начал усиленно рубить инженерию и управление проектами.
Т.е. *** я бы не брал людей без собственных шишек, пусть даже и
маленьких, т.к. человек должен понимать что такое проект и
ответственность***. Когда я случайно попал на собеседование в Киев,
будущий начальник сказал, что за целый месяц я единствевнных вменяемый
кандидат, котоырй что-то умеет делать своими руками и через день
пригласил на работу. А мне еще оставался курс института. (Хотел
поучаствовать в дискуссии по обучению на Украине, да уж слишком все во
флейм скатилось). Кроме того, что уже работал в Киеве, ездил сдавать
свои сессии да еще преподавать младшим курсам "основы баз данных". В
общем сделал я на этой работе еще два проекта, собственно прошло уже
лет пять, а продукты, судя по сайту, как-то все на том же уровне с
моего ухода и остались.
Собственно еще некоторое время мне было интересно программировать
(немного веба, немного java) и очень хотелось стать менеджером
проекта, и аж такого как у Брукса. Однако, если официально, дорос я
лишь до аналитика с зарплатой ниже уровня его достоинства и был
успешно сокращен за отсутствием проектов (а руководителя аналитической
службы до сих пор периодически встречаю (светлый, приятный, грамотный,
максимально профессиональный, корректный, и вообще золотой человек
которому же за 50!) и он все зовет обратно, но кроме перспектив и
двойного расстояния до работы ... Однако я бы с удовольствием
поработал бы еще под его началом.
В общем после того сокращения посидел я немного дома в свое
удовольствие, да начал на работу устраиваться. Но старый блин, слишком
много знает, не брали и все тут, хотя вакансий было море по всем
направлениям. Конечно же нужно учитывать еще того, кто собеседует.
Часто это просто маленькие глупенькие девочки или опять же молоденькие
разработчики, которые максимум про GoF чего-то слышали и не дальше,
т.е. просто не понимают тебя вот и все. Повезло, друзья на работу
взяли чтобы в торговой компании перейти с 1С77 на 1С8. Ни одну из них
я не знал, и раньше вообще 1С хаял, все надеялся что внедрим мы
ADempiere, но все-таки вышел 1С. До сих пор там и работаю,
поддерживаю, модернизирую и другими ИТ-проектами занимаюсь. Сообща с
системным администратором успел внедрить еще одну систему на базе
1C8.1 Управление торговлей для Украины для розничной сети магазинов
обуви и одежды (всего около 20 шт магазинов и два оптовых склада). В
общем должность менеджера проекта я уже давно не хочу, т.к. сейчас у
меня реально этих проектов 3. Добавился еще веб-сайт компании...
С сайтом вообще история отдельная. Руководство пригласило "своих", на
мне лежала помощь в предоставлении данных из 1С в базу веб-сайта.
Знакомым был дизайнер, и вообще бывший сотрудник, который сказал "У
меня, да и сам азм есть, просто программистский бог с большим
бубеном". Бог оказался совсем молоденьким, и скорее дубом. Что-то он
конечно сделал, что до сих пор местами глючит, да и уровень владения
антипаттернами разработки, SEO оптимизации, работой с БД, просто
первоклассный .. качество кода изумительное, комментариев -100%, ...
Сайт на меня повесили, т.к. больше некому. Пришлось и за ним
подтирать, т.к. просто выгнал на середине, и срочно исправлять
некоторые моменты. Т.е. вместо проекта получили постоянную
неадекватную реакцию маленького программистского божка с годичным
опытом п-страдания. Пришлось осваивать азы Rails ...
Около месяца назад начали новый веб-проект, завтра как раз исполнитель
должен подойти на переговоры. Так что их у меня теперь четыре. Два
проекта поддержки, и два проекта разработки - чем не PM? Кроме того
иногда еще хватает времени чего-то сделать на 1С, с чем-то интересным
разобраться, чем-то поделиться.
Про найм правильных людей уже давно за нас все сказали
Караоке капитализма, Карр, Фергюс О"Коннел, и уверен много кто другой.
Нужно просто прислушаться к чужому опыту. Я вот просто на 100%
согласен
Выбор правильных людей - http://nvoynov.blogspot.com/2007/04/blog-post_2758.html
Peopleware Ларри Константина - http://nvoynov.blogspot.com/2007/12/blog-post.html
...
Проекты разные, цели разные, и конечно же люди. Но очень часто не
хватает проектам опыта, а но сын ошибок трудных и друг парадоксов. Как-
то даже книжка такая была Программист-Прагматик и идеи там излагались
правильные.
А что технологии? Наиболее революционные технологии гнобят и двигаются
они крайне медленно. Вместо этого С#, Java и около, а сейчас уже и
вообще не само программирования, а скорре адаптация конструкторов под
решения. Т.е. больше заменяют понятия и путают следы. Я вот и сам
балуюсь иногда с Rails - да неплохая платформа, вернее фреймворк, но
что там революционного? У меня с одним другом шутка есть такая "Это
отчего я раньше такой злой был? - Потому что у меня фреймворка не
было!"
Звездная болезнь часто встречается. А может это не звездная болезнь?
Может вы просто только собрались решать какие-то проблемы, которые ваш
кандидат уже решал 10 лет назад? Я вот например так в институте учился
на первом курсе. Сдал двух-семестровый курс программирования за два
дня и еще успел выступить с презентацией по конкретной технологии,
чтобы мой преподаватель наконец в тему врубился.
Есть старая русская пословица - "Старый конь борозды не портит", и
если вы все-таки решитесь взять его на работу, возможно в следующем,
текущем или очередном проекте он сократит вам 50% времени разработки.
Да и с возрастом звездная болезнь скорее проходит, если не успел
случится старческий маразм у сегодняшнего начальника, который боится,
что этот старый конь займет его место. Если б молодость слушала, если
б старость не устала учичть и учиться. Я пока еще не устал
интересоваться ИТ, только ничего такого особого тут пока не
происходит. Да и серебрянной пули нет - проекты нужно просто делать, а
перед тем как начинать делать думать.
Прошу извинения, за возможно резкий пост.
Alexey Maslov
Regards,
Alexey Maslov
У разработчиков с большим опытом работы есть один огромный плюс -
накопленный багаж знаний и опыта, который он может использовать
самостоятельно или же передавать другим. С некоторыми из них очень
приятно общаться и польза от них просто неоценима.
Но все же позволю себе сформулировать ряд наблюдений из жизни:
1) Факт, доказанный учеными - с возрастом мозг становится менее
активным, человеку начинает быть свойственно быстрее забывать
информацию, тяжелее усваивать большие объемы новой информации
2) Человек в возрасте менее склонен воспринимать изменения, он
сопротивляется им, особенно когда они противоречат его личному опыту в
прошлом
3) Опытный разработчик в возрасте чаще всего скептик, который считает
что его опыт и знания позволяют ему не соглашаться и продавливать
решения в спорных вопросах
4) Разработчик в возрасте часто не потерпит чтобы кто-то младше него
стоял сверху по служебной лестнице и будет всячески сопротивляться и
вставлять палки в колеса
5) Разработчик в возрасте меньше изучает новые технологии, фреймворки,
практики даже просто потому что ему это уже не так интересно, у него
есть семья и дети, у него нету свободного времени
6) Наконец очень многих опытных разработчиков компании держат в очень
узком русле (к примеру тюнинг DB2 или разработка драйверов к USB
устройствам на C++). Когда такой человек хочет поменять компанию и
заявляет что его опыт в C++ уже больше 10 лет, то он лукавит, потому
что его узкопрофильные знания могут быть низкоприоритетными для новой
компании
7) Разработчик в возрасте редко меняет работу (и даже задумывается о
ее смене). Это происходит потому что у него уже есть семья, куча
обязательств и ему не так просто изменить что-то в жизни
8) Разработчик с опытом стоит немалых денег, часто бывает что
неоправданных
Что вы думаете по этому поводу? Если у вас стоит выбор брать молодого
разработчика, но с меньшим опытом и знаниями или же матерого
разработчика с 15-летним стажем, что вы выберете?