как оценить flash программиста?
 

странный вопрос, но
я, скромно говоря, опытный web разработчик, без проблем собеседую претендетов на должность PHP программиста. на устном собеседовании все прояснияется с высокой точностью, но в целях экономии времени обычно я прошу предварительно решить тестовую задачу. глядя в этот код по некоторым критериям можно оценить опытность и другие качества разработчика.
ближе к делу.
собеседовать flasherа я не могу - не компитентен
но в рамках заказов flash разработки на аутсорс фрилансерам мне предстоит оценивать качество продукта, принимать решение о дальнейших заказах
понятно, что если программа работает и ТЗ выполнено - то вроде бы и все ок
но есть вопрос качества реализации: архитектура, выбор средств,гибкость к модификациям, корректность и читабельность кода, обработка исключений и пр.

какие характерезующие моменты можно выделить для оценки программы на action script ?

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

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

задачи действительно разные и объективно оценить программера очень сложно ! скорей тут нада действовать - давать работу и смотреть, как он ее выполняет, конечно перед этим нада поговорить, чтоб овощем не оказался ! а так есть еще такая замечательная штука, как обучение ! все знать сложно ,но вот научиться быстро тому, что нужно - ценная черта программера

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

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

Если ты один человек в команде — тогда да, может быть, особенно когда сроки поджимают и приложение одноразовое, если нет — в корне не согласен с данным утверждением :)

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

Я считаю, что нужно комментировать свой код, хотя бы на уровне выборки алгоритмов для решения задачи. Сталкивался с ситуацией, когда разработчик сделал код, а я его должен был проверить на соответствие ТЗ (устному), при чем сам я плохо знаком с ООП и AS в частности. Но четкие комментарии в стиле "//... а здесь создаем массифчег для..." помогли разобраться что к чему. На этой же стадии проверки становится ясна дальновидность программиста на предмет универсальности кода - считаю это так же немаловажным фактором его профессионализма. Но не имея опыта разработок нельзя точно оценить качество кода, быстродействие приложения, правильность выбора тех или иных путей решения задач.

Хороший код не надо комментировать. Особенно комментировать в стиле " ... а здесь создаем массив для ..." .
Хороший код сам себя комментирует.

обсуждать синтаксис AS - наверное глупо
а объектнуб модель - я просто не смогу

вобщем скорее всего мне придется заказать простенький прототип и на его примере освежить свои знания про flash и разобраться в конкретном исполнителе...

Добавлено через 1 минуту
в процедурном коде - возможно
в ОО да при приличном объеме - комментирование существенно упращает понимание
особенно если много точек входа, как во flash приложениее