>>>>Знание названий паттернов и умение разрабатывать системы - несколько разные вещи.
---------------------------------------
>>Верно. Знание что-такое шаблоны ещё ни о чём не говорит. Но человек, умеющий разрабатывать системы, как правило с таким понятием сталкивался и понимает что это такое. Помнить наизусть названия совершенно не обязательно. :-)
Человек, достаточно хорошо разрабатывающий системы, может не знать подробно ни одного паттерна. Тем не менее в силу своего опыта и интуиции он строит систему даже в соответствии с каким-нибудь паттерном. Если ему ставится задача создать систему по определенному паттерну, у него никаких проблем не возникает, поскольку он достаточно хорошо разбирается в архитектурах и принципах построения систем.
Например, банальный MVC - любой опытный человек уже давно использовал такой паттерн в своих разработках, даже не догадываясь, что это оформлено в виде классического шаблона.
Человек, достаточно хорошо разрабатывающий системы, может не знать подробно ни одного паттерна.
--------------------------------------
М-м-м. Не соглашусь с Вами. Дело в том, что паттерны это не только способ проектирования, это ещё, в некотором смысле, общий язык для описания системы. Если я говорю кому то, что тут использован синглетон, то он сразу всё понимает. Это во-первых. Во-вторых, какой бы умный человек не был, но какие-то книги читать приходится (ну если приходится :-)). Трудно сейчас найти достойную книгу по дизайну, в которой бы не упоминался этот термин. А это значит, что внимательно человек ни одной книги не прочёл. И эта книга не обязательно класcический GoF. Это просто любая неплохая книга по ООП дизайну. Если человек говорит, что он вообще не знает такого термина, то вероятность, что ему интересна его профессия, увы, не велика.
Вильямс: книга "Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию"
Небольшая цитата.
"Я хотел, чтобы мои студенты разбирались в шаблонах проектирования, и обнаружил, что лучшим способом достичь этого является применение исследовательского подхода. Например, вместо того, чтобы просто описать шаблон Bridge (мост), лучше сформулировать подходящую задачу и попросить студентов решить ее на основе нескольких рекомендуемых принципов и методов, которые всегда можно выделить в большинстве шаблонов проектирования. В процессе поиска студенты сами находят то решение, которое называется шаблоном Bridge, и прочно запоминают его. "
Полковник, Владимир собеседует людей на определенное место, и скорее всего это место предполагает знание определенного набора вещей. И задача у него стоит понять человека минут за 30, причем часто начинающего, с которым кроме как о "знаешь/не знаешь" и говорить-то не о чем.
Ясно, что реальный мир не делится на белое и черное. Бывает, что хороший Джавер, которому и 1500 заплатить не грех не знает что такое Weak Reference... ну или просто не помнит, что такое volatlie. И может так случиться, что набор в общем-то простых для собеседующего вопросов отсекает толгового человека - это неизбежное зло собеседований, и кандидату тоже надо это понимать, и искать способ показать свои плюсы (если они есть), которые перевесят незнание патернов и т.п.
Но все таки, когда человек все красиво про SQL излагает, вдруг путает (не оговаривается, а именно искренне путает) байт с битом, то это его явно характеризует.
>>Полковник, Владимир собеседует людей на определенное место, и скорее всего это место предполагает знание определенного набора вещей.
Это все верно.
>>И задача у него стоит понять человека минут за 30, причем часто начинающего, с которым кроме как о "знаешь/не знаешь" и говорить-то не о чем.
Раз такой подход, тогда пожалуйста. Но такие собеседования не дают полного представления об интервьируемом.
>>Ясно, что реальный мир не делится на белое и черное. Бывает, что хороший Джавер, которому и 1500 заплатить не грех не знает что такое Weak Reference... ну или просто не помнит, что такое volatlie.
Именно об этом я и говорю.
>>И может так случиться, что набор в общем-то простых для собеседующего вопросов отсекает толгового человека - это неизбежное зло собеседований, и кандидату тоже надо это понимать, и искать способ показать свои плюсы (если они есть), которые перевесят незнание патернов и т.п.
Вот и приходится опытным людям готовится к можно сказать "экзамену".
>>Но все таки, когда человек все красиво про SQL излагает, вдруг путает (не оговаривается, а именно искренне путает) байт с битом, то это его явно характеризует.
Это уже крайности. Мы не об этом беседуем.
Вообще-то, лучший вариант тестирования кандидата (но и достаточно трудоемкий) - небольшое тестовое задание. Не прямо на месте и без инструментария, как в свое время в Crona (например, голый JDK), а на пару дней, чтобы человек мог в спокойной обстановке разобраться, вспомнить, что нужно, и сделать нормально.
Соглашусь с Полковником - если человек не знает ни про один паттерн, книг по профессии не читает, но сам их (паттерны) "открыл" и применяет на практике - то такого человека надо брать с руками и ногами! :-)
Можно только одно отметить, что такие люди не встречаются в реальной жизни. :-)
>>Соглашусь с Полковником - если человек не знает ни про один паттерн, книг по профессии не читает, но сам их (паттерны) "открыл" и применяет на практике - то такого человека надо брать с руками и ногами! :-)
>>Можно только одно отметить, что такие люди не встречаются в реальной жизни. :-)
Как правило, такие люди сразу видны и уже через 2 минуты разговор с ними совсем другой. Более того, впереди их идет их рекоммендация (или от HR или от сотрудников или просто анкета) и уже принимающей стороне к интервью с ними надо готовиться.
>>Как правило, такие люди сразу видны и уже через 2 минуты разговор с ними совсем другой.
Не все таких видят.
>>Более того, впереди их идет их рекоммендация (или от HR или от сотрудников или просто анкета) и уже принимающей стороне к интервью с ними надо готовиться.
Вот и готовятся, не глядя в резюме: тестовые задания дают, экзамен устраивают и пр.
Может и не все. Но в принципе это как раз не очь сложно. Человек, действительно, может не называть имён паттернов по "букварю", но способен предлагать похожие по удобству и безопасности подходы. Но всегда есть один нюанс - вы не сможете поставить такого человека в тупик простым вопросом - а вот в каком таки порядке вызываются конструкторы? Как правило он отлично понимает механику ООП, что и есть подтверждение его высокой квалификации. Статистически, в жизни, чаще встречается другая ситуация - человек знает названия паттернов, но не знает в каком порядке вызываются конструкторы и как этим управлять. Увы, но это так. Это не мнение, это статистика. :-)
...Естественно, если нужны обычные кодировщики.
--------------------------------------
Я не знаю что такое обычный кодировщик или обычный верстальщик... Все эти вещи уже достаточно сложны и требуют хорошей квалификации. Расписать на пальцах каждый пук не так и просто. Это куда как накладнее, чем взять квалифицированного разработчика и с уважением относиться к его труду. Не специфицируя в мелочах каждую строчку его кода. :-)
какой смысл про особенности языков вообще спрашивать? полно фрэймворков которые покрывают слабые места. кто и когда последний раз использовал явно теже слабые ссылки?
в области бд, транзакций, локинга данных, конкурентной работы с данными, асинхронных взаимодействий столько интересных особенностей, что человек знающий их потенциально может создавать приложения на любом языке
Мне казалось, что знание чего-либо в IT НАЧИНАЕТСЯ со "знания байта и бита".
>в области бд, транзакций, локинга данных, конкурентной работы с данными, асинхронных взаимодействий столько интересных особенностей, что человек знающий их потенциально может создавать приложения на любом языке
Особенно приложения, абсолютно не имеющие отношения к БД. И без "знания байта и бита".
Стыд мне и позор, но сколько работаю J2EE девелопером ни разу не использовал WeakReference. Даже при подготовке к сановскому экзамену не встречал упоминаний о нем. Пошел читать javadoc...
Сомневаюсь, что на такой вопрос хоть 20% senior джава девелоперов ответят.
>Стыд мне и позор, но сколько работаю J2EE девелопером ни разу не использовал WeakReference. Даже при подготовке к сановскому экзамену не встречал упоминаний о нем. Пошел читать javadoc...
>Сомневаюсь, что на такой вопрос хоть 20% senior джава девелоперов ответят.
Дело в том, что наш так называемый senior developer, зачастую не соответствует квалификации буржуйского senior developer. Сколько процентов наших senior developers даст четкое краткое определение полиморфизму, например, или скажет, какой процесс разработки используется в его проекте? Стыд не в том, что не пришлось использовать (weak ref и за всю карьеру jee developer может не пригодиться), а собственно в незнании.
Приходилось присутсвовать на собеседовании человека с 5-летним опытом в джава, который не знал собственно ничего. Его отмазкой было - а вот я все это время на своем проекте делал только вот это (а был это какой то бесконечный самописный узкоспециализороанный фрэймворк)...
>> 2инкогнито. Если интересует белорусское представительство SAP,
>> то милости просим на sap.by, многое станет понятно. ;)
2Alexander (ABAP ): Ну это они нескромно. ЛиверХ не представительство SAP, а обычный партнёр, которым может стать любая контора хоть как-то имеющая к SAP отношение. Я думаю, что вот такая вот реклама не с лучшей стороны характеризует компанию: зачем выставлять себя тем, кем не являешься?
Извините, очень хотелось бы получить конструктивные ответы только от тех кто работал/знает-тех-кто-работал(транзитивность передачи<=1) на SCAND:
"В Чем Собственно Прикол?", т.е. интересность проектов/направлений (сколько тратят на саппорт), наличие методологии разработки/инструменты/распределение обязанностей, рабочий график, ОСОБЕННО насколько порядочна фирма с сотрудниками.
А что в Минске с офисом Exadel происходит? Людей не берут (собеседование проходишь, они говорят, что ты им подходишь, но взять не могут, т.к. не разрешают американцы). И очень много народа валит сейчас оттуда.
Страницы
Минск, 10 марта 2008 года, 22:39
>>>>Настоящий Полковник:
>>>>Знание названий паттернов и умение разрабатывать системы - несколько разные вещи.
---------------------------------------
>>Верно. Знание что-такое шаблоны ещё ни о чём не говорит. Но человек, умеющий разрабатывать системы, как правило с таким понятием сталкивался и понимает что это такое. Помнить наизусть названия совершенно не обязательно. :-)
Человек, достаточно хорошо разрабатывающий системы, может не знать подробно ни одного паттерна. Тем не менее в силу своего опыта и интуиции он строит систему даже в соответствии с каким-нибудь паттерном. Если ему ставится задача создать систему по определенному паттерну, у него никаких проблем не возникает, поскольку он достаточно хорошо разбирается в архитектурах и принципах построения систем.
Например, банальный MVC - любой опытный человек уже давно использовал такой паттерн в своих разработках, даже не догадываясь, что это оформлено в виде классического шаблона.
По проектам судят, а не по определениям.
Человек, достаточно хорошо разрабатывающий системы, может не знать подробно ни одного паттерна.
--------------------------------------
М-м-м. Не соглашусь с Вами. Дело в том, что паттерны это не только способ проектирования, это ещё, в некотором смысле, общий язык для описания системы. Если я говорю кому то, что тут использован синглетон, то он сразу всё понимает. Это во-первых. Во-вторых, какой бы умный человек не был, но какие-то книги читать приходится (ну если приходится :-)). Трудно сейчас найти достойную книгу по дизайну, в которой бы не упоминался этот термин. А это значит, что внимательно человек ни одной книги не прочёл. И эта книга не обязательно класcический GoF. Это просто любая неплохая книга по ООП дизайну. Если человек говорит, что он вообще не знает такого термина, то вероятность, что ему интересна его профессия, увы, не велика.
Вильямс: книга "Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию"
Небольшая цитата.
"Я хотел, чтобы мои студенты разбирались в шаблонах проектирования, и обнаружил, что лучшим способом достичь этого является применение исследовательского подхода. Например, вместо того, чтобы просто описать шаблон Bridge (мост), лучше сформулировать подходящую задачу и попросить студентов решить ее на основе нескольких рекомендуемых принципов и методов, которые всегда можно выделить в большинстве шаблонов проектирования. В процессе поиска студенты сами находят то решение, которое называется шаблоном Bridge, и прочно запоминают его. "
Ясно, что реальный мир не делится на белое и черное. Бывает, что хороший Джавер, которому и 1500 заплатить не грех не знает что такое Weak Reference... ну или просто не помнит, что такое volatlie. И может так случиться, что набор в общем-то простых для собеседующего вопросов отсекает толгового человека - это неизбежное зло собеседований, и кандидату тоже надо это понимать, и искать способ показать свои плюсы (если они есть), которые перевесят незнание патернов и т.п.
Но все таки, когда человек все красиво про SQL излагает, вдруг путает (не оговаривается, а именно искренне путает) байт с битом, то это его явно характеризует.
11 марта 2008 года, 12:25
>>Полковник, Владимир собеседует людей на определенное место, и скорее всего это место предполагает знание определенного набора вещей.
Это все верно.
>>И задача у него стоит понять человека минут за 30, причем часто начинающего, с которым кроме как о "знаешь/не знаешь" и говорить-то не о чем.
Раз такой подход, тогда пожалуйста. Но такие собеседования не дают полного представления об интервьируемом.
>>Ясно, что реальный мир не делится на белое и черное. Бывает, что хороший Джавер, которому и 1500 заплатить не грех не знает что такое Weak Reference... ну или просто не помнит, что такое volatlie.
Именно об этом я и говорю.
>>И может так случиться, что набор в общем-то простых для собеседующего вопросов отсекает толгового человека - это неизбежное зло собеседований, и кандидату тоже надо это понимать, и искать способ показать свои плюсы (если они есть), которые перевесят незнание патернов и т.п.
Вот и приходится опытным людям готовится к можно сказать "экзамену".
>>Но все таки, когда человек все красиво про SQL излагает, вдруг путает (не оговаривается, а именно искренне путает) байт с битом, то это его явно характеризует.
Это уже крайности. Мы не об этом беседуем.
Вообще-то, лучший вариант тестирования кандидата (но и достаточно трудоемкий) - небольшое тестовое задание. Не прямо на месте и без инструментария, как в свое время в Crona (например, голый JDK), а на пару дней, чтобы человек мог в спокойной обстановке разобраться, вспомнить, что нужно, и сделать нормально.
Можно только одно отметить, что такие люди не встречаются в реальной жизни. :-)
11 марта 2008 года, 16:13
>>Соглашусь с Полковником - если человек не знает ни про один паттерн, книг по профессии не читает, но сам их (паттерны) "открыл" и применяет на практике - то такого человека надо брать с руками и ногами! :-)
>>Можно только одно отметить, что такие люди не встречаются в реальной жизни. :-)
Встречаются. ;)
Как правило, такие люди сразу видны и уже через 2 минуты разговор с ними совсем другой. Более того, впереди их идет их рекоммендация (или от HR или от сотрудников или просто анкета) и уже принимающей стороне к интервью с ними надо готовиться.
Но это единицы. А ан масс вопросы по ООП рулят.
11 марта 2008 года, 17:18
>>>> Встречаются. ;)
>>Как правило, такие люди сразу видны и уже через 2 минуты разговор с ними совсем другой.
Не все таких видят.
>>Более того, впереди их идет их рекоммендация (или от HR или от сотрудников или просто анкета) и уже принимающей стороне к интервью с ними надо готовиться.
Вот и готовятся, не глядя в резюме: тестовые задания дают, экзамен устраивают и пр.
>>Но это единицы. А ан масс вопросы по ООП рулят.
Естественно, если нужны обычные кодировщики.
...Не все таких видят.
---------------------------------
Может и не все. Но в принципе это как раз не очь сложно. Человек, действительно, может не называть имён паттернов по "букварю", но способен предлагать похожие по удобству и безопасности подходы. Но всегда есть один нюанс - вы не сможете поставить такого человека в тупик простым вопросом - а вот в каком таки порядке вызываются конструкторы? Как правило он отлично понимает механику ООП, что и есть подтверждение его высокой квалификации. Статистически, в жизни, чаще встречается другая ситуация - человек знает названия паттернов, но не знает в каком порядке вызываются конструкторы и как этим управлять. Увы, но это так. Это не мнение, это статистика. :-)
...Естественно, если нужны обычные кодировщики.
--------------------------------------
Я не знаю что такое обычный кодировщик или обычный верстальщик... Все эти вещи уже достаточно сложны и требуют хорошей квалификации. Расписать на пальцах каждый пук не так и просто. Это куда как накладнее, чем взять квалифицированного разработчика и с уважением относиться к его труду. Не специфицируя в мелочах каждую строчку его кода. :-)
какой смысл про особенности языков вообще спрашивать? полно фрэймворков которые покрывают слабые места. кто и когда последний раз использовал явно теже слабые ссылки?
в области бд, транзакций, локинга данных, конкурентной работы с данными, асинхронных взаимодействий столько интересных особенностей, что человек знающий их потенциально может создавать приложения на любом языке
Мне казалось, что знание чего-либо в IT НАЧИНАЕТСЯ со "знания байта и бита".
>в области бд, транзакций, локинга данных, конкурентной работы с данными, асинхронных взаимодействий столько интересных особенностей, что человек знающий их потенциально может создавать приложения на любом языке
Особенно приложения, абсолютно не имеющие отношения к БД. И без "знания байта и бита".
Ну-ну...
Сомневаюсь, что на такой вопрос хоть 20% senior джава девелоперов ответят.
>Сомневаюсь, что на такой вопрос хоть 20% senior джава девелоперов ответят.
Дело в том, что наш так называемый senior developer, зачастую не соответствует квалификации буржуйского senior developer. Сколько процентов наших senior developers даст четкое краткое определение полиморфизму, например, или скажет, какой процесс разработки используется в его проекте? Стыд не в том, что не пришлось использовать (weak ref и за всю карьеру jee developer может не пригодиться), а собственно в незнании.
Приходилось присутсвовать на собеседовании человека с 5-летним опытом в джава, который не знал собственно ничего. Его отмазкой было - а вот я все это время на своем проекте делал только вот это (а был это какой то бесконечный самописный узкоспециализороанный фрэймворк)...
И на этом узкоспециализорованном фрэймворке он делал все то, что остальные делали без этого узкоспециализорованного фрэймворка.
Бывает.
Недавно Exigen Services искал такого, но сейчас не знаю...
>> Minsk, 14 марта 2008 года, 11:15
>> 2инкогнито. Если интересует белорусское представительство SAP,
>> то милости просим на sap.by, многое станет понятно. ;)
2Alexander (ABAP ): Ну это они нескромно. ЛиверХ не представительство SAP, а обычный партнёр, которым может стать любая контора хоть как-то имеющая к SAP отношение. Я думаю, что вот такая вот реклама не с лучшей стороны характеризует компанию: зачем выставлять себя тем, кем не являешься?
Он и сейчас ищет, в Одессу )))
Тепло, но далековато))
или лучше левер Икс? если пробовать стажером туда идти?
"В Чем Собственно Прикол?", т.е. интересность проектов/направлений (сколько тратят на саппорт), наличие методологии разработки/инструменты/распределение обязанностей, рабочий график, ОСОБЕННО насколько порядочна фирма с сотрудниками.
Заранее благодарствую
Страницы