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

T>>... задание не приняли?
P_R>Да было дело... ещё прошлой осенью по-моему...

T>>Может есть кто на форуме, кто прошел тестовое задание? Поделитесь!!
P_R>Ну просто интересно, что же именно всё-таки ожидают от этой задачи проверяющие? Выставили бы хоть, как говориться, собственный эталон.

Вот это тестовое задание, решенное одним из кандидатов. Решение очень понравилось.
http://www.rsdn.ru:80/File/20496/Euro.zip

Объясняю почему — это может кому-то показаться странным. Другими словами — как оценивается задание.
Задание проверяют независимо два человека. Эти двое назначаются отделом HR из числа программистов — типа, "наряд вне очереди". Каждый из них заполняет т.н чеклист. Основная графа в чеклисте — рекомендуется ли продолжать процесс с кандидатом. Проверяющие обязательно должны сойтись во мнении касательно кандидата — для этого есть отдельная процедура. Предполагается, что кандидат применит к решению те же требования, что и к собственному production коду.

Вот так выглядит мой чеклист для задания, который я привел.

Code Inspection    please provide ranking and notes below    

"-" - None/Not Applicable        
"0" - Poor        
"1" - Acceptable         
"2" - High        


    Task: Euro Diffusion    
    Inspector: Vlad Balin    
    Ranking    Notes
Compilation                   2    
Comments                       2    Excellent.
Code Readability               2    Excellent.
Bad Input Processing          2    Present.
OO Design                      2    
Disconnected Regions          2        Excellent.
Map Scalability                  0    Not good.
C++ Knowledge                  2    Good.
STL usage                       1    Good.
Performance                      2    
Scalability                      2    
Results                          2    
Error Processing and Logging  2    Excellent.

Other Issues    please list other issues below    
1.        
2.        
3.        

    General feedback    
Do you recommend to continue (Yes/No)    Yes.    
Why? Please, give explanation/feedback    
    Code is very clear and easy to understand.    
    Motivation is clear, result is adequate.    
    Single consideration is that the map is represented with array, which is not good.    
    However, overall impression is very positive. 
    Need to rise question about alternative map representation on the interview.

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

Это общая философия, теперь по пунктам.

У задачи есть несколько аспектов. Каждый оценивается отдельно.
1) Владение технологиями. Сюда относится знание языка и библиотек, и умение их по делу (мотивировано, а не как попало) применять.

2) Владение ОО дизайном. Опять же, предпочтение отдается минимально достаточному решению — наличие каждого класса должно быть мотивировано. Далее, для каждого языка в решении должны быть использованы родные для него идиомы и натуральные для него ходы. Например, решение на С++, которое выглядит совокупность COM-объектов, за редчайшими исключениями идет фтопку — на позицию seniour developer такого человека не возьмут. Почему? Потому, что это не есть натуральный способ писать приложения для С++, в С++ все делается проще.

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

Далее, бывает, что при предложении слегка поправить прогу, чтобы эффективнее обрабатывался некоторый случай (пример — сильно разряженная карта, вытянутая крестом во все стороны), навороченый и "правильный" дизайн рассыпается на части. Обычно это происходит именно с навороченными, "передизайнеными" решениями. В таких случаях говорят, что дизайн хрупкий. Короче, будьте проще, господа.

3) Алгоритмическая часть. Проверяется, насколько адекватны примененные алгоритмы. Не то, чтобы это было основное, но О(N^2) на ровном месте — это очень серьезный минус, господа.

4) Структуры данных. То, что задача сделана на большом массиве — не повод для отказа. Это повод для вопроса на собеседовании — изменяем постановку так, что структуру данных надо изменить. Вот если кандидат не может этого сделать (т.е. не видит других вариантов) — то это очень и очень плохо.

5) Простота и читабельность. Программа пишется для человека, господа. В первую очередь это верно, когда речь идет о тестовом задании — мы вашу программу читаем, да. В четыре глаза. Чем она короче, чем проще для понимания — тем больше ваши шансы. И вовсе не обязательно писать многостраничные комментарии — лучше давайте осмысленные названия переменным, функциям, etc. В идеале — ваша программа должа быть понятной и читабельной без комментариев. Но это в идеале.

Вообще, к решению прилагается основной критерий — инженерной красоты. В инженерии это то же, что и в исскустве — максимум результата при минимуме задействованых изобразительных средств. Был случай, когда одно из решений было написано на чистом С и занимало (со слов проверяющего) пару экранов кода. При этом, это был красивый и лаконичный, простой и понятный код на чистом С, без лишних наворотов. Плюс ко всему, он работал быстрее всех остальных вариантов. Человека рекомендовали брать. Почему? Он убедил нас в том, что он хороший инженер. Чего и вам желаю .