G>>Как представитель CQG прошу модераторов удалить эту ветку. G>Впрочем, не надо. В ближайшее время тестовое задание будет изменено, а пообсуждать решение полезно по-любому.
Здравствуйте, Pavel_RM, Вы писали:
T>>... задание не приняли? P_R>Да было дело... ещё прошлой осенью по-моему...
T>>Может есть кто на форуме, кто прошел тестовое задание? Поделитесь!! P_R>Ну просто интересно, что же именно всё-таки ожидают от этой задачи проверяющие? Выставили бы хоть, как говориться, собственный эталон.
Объясняю почему — это может кому-то показаться странным. Другими словами — как оценивается задание.
Задание проверяют независимо два человека. Эти двое назначаются отделом 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. В идеале — ваша программа должа быть понятной и читабельной без комментариев. Но это в идеале.
Вообще, к решению прилагается основной критерий — инженерной красоты. В инженерии это то же, что и в исскустве — максимум результата при минимуме задействованых изобразительных средств. Был случай, когда одно из решений было написано на чистом С и занимало (со слов проверяющего) пару экранов кода. При этом, это был красивый и лаконичный, простой и понятный код на чистом С, без лишних наворотов. Плюс ко всему, он работал быстрее всех остальных вариантов. Человека рекомендовали брать. Почему? Он убедил нас в том, что он хороший инженер. Чего и вам желаю .
1. Лишний класс результатов, название страны и так есть, а количество дней заполненности можно добавить в свойства страны.
2. При распарсивании строки со страной, если страна состоит из нескольких слов выпадет по Exception, допустим Great Britain
в остальном решение понравилось, может господа из CQG не оценили задачу Integrator?
_NT>Отлично! _NT>Мое решение здесь
_NT>Надеюсь на интересное обсуждение
Я тоже устраивался к вам и решал данную задачу. Был приглашен на первое собеседование, а потом на второе. В итоге нашел у себя в ящике письмо с невозможностью принять меня на должность разработчика в вашей компании. Я уже устроился в другом месте и вроде не плохо, но все же интересует ответ на вопрос почему же не я.
Не могли бы объяснить хотя бы примерные причины моего краха. В каком случае кандидаты приглашаются на второе собеседование?
Здравствуйте, solano, Вы писали:
S>Не могли бы объяснить хотя бы примерные причины моего краха. В каком случае кандидаты приглашаются на второе собеседование?
Честно говоря — не знаю. Второе собеседование было техническим? О чем вы на нем говорили?
Здравствуйте, mbrodin, Вы писали:
M>1. Лишний класс результатов, название страны и так есть, а количество дней заполненности можно добавить в свойства страны.
Согласен. Действительно можно было реализовать IComparable интерфейс для класса Country ..
M>2. При распарсивании строки со страной, если страна состоит из нескольких слов выпадет по Exception, допустим Great Britain
Согласен.
M>в остальном решение понравилось, может господа из CQG не оценили задачу Integrator?
Спасибо.
Не думаю, что проблема была с Integrato'om... ведь там все намного проще.
Для обсуждения задачки Integrator можно выделить отдельную ветку и на другом форуме
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, solano, Вы писали:
S>>Не могли бы объяснить хотя бы примерные причины моего краха. В каком случае кандидаты приглашаются на второе собеседование?
G>Честно говоря — не знаю. Второе собеседование было техническим? О чем вы на нем говорили?
Скорее всего нет. Оно было не технических. Со мной беседовали два человека. Одного из них зовут Areg Melik-Adamyan. Он мне свою визитку дал, поэтому я его и запомнил. Второго не запомнил. Я бы сказал, что второе собеседование больше было связано с психологическими аспектами работы.
Здравствуйте, solano, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, solano, Вы писали:
S>>>Не могли бы объяснить хотя бы примерные причины моего краха. В каком случае кандидаты приглашаются на второе собеседование?
G>>Честно говоря — не знаю. Второе собеседование было техническим? О чем вы на нем говорили?
S>Скорее всего нет. Оно было не технических. Со мной беседовали два человека. Одного из них зовут Areg Melik-Adamyan. Он мне свою визитку дал, поэтому я его и запомнил. Второго не запомнил. Я бы сказал, что второе собеседование больше было связано с психологическими аспектами работы.
Я понял. В таком случае я вообще ничего не могу вам сказать — я отвечаю только за техническую часть, и то — временами, когда заставляют.
G>>Как представитель CQG прошу модераторов удалить эту ветку. G>Впрочем, не надо. В ближайшее время тестовое задание будет изменено, а пообсуждать решение полезно по-любому.
2. Не рациональное использование памяти (overhead иногда ~1.5 Mb )
Я конечно признаю, что и мой вариант не оптимален, но, чтобы не быть голословным, привожу скриншоты из .NET Memory Profiler для Вашего варианта здесь и для своего — здесь.
Очень понравился ваш подход к реализации, изложенный в файле "How i do it.txt"!
Действительно супер!
И спасибо за предоставленную возможность ознакомиться с еще одним интересным решением!
Здравствуйте, Gaperton, Вы писали:
G>Теперь о том, как проверяющий проверяет задание. Надо заметить, что проверяющие знакомы почти со всеми возможными вариантами решения этой задачи (практика — великая вещь).
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
G>>Теперь о том, как проверяющий проверяет задание. Надо заметить, что проверяющие знакомы почти со всеми возможными вариантами решения этой задачи (практика — великая вещь).
Т>И с таким
Здравствуйте, Gaperton, Вы писали:
_NT>>Будет ли Вам интересно обсудить мой Вариант решения этой задачки (описание самой задачки можно найти здесь, Problem D)?
G>Как представитель CQG прошу модераторов удалить эту ветку.
а я, как представитель другой компании, категорически требую запретить и удалить все темы в которых обсуждаются вопросы и задачи, задаваемые на интервью
Здравствуйте, ilya_ny, Вы писали:
_> _>а я, как представитель другой компании, категорически требую запретить и удалить все темы в которых обсуждаются вопросы и задачи, задаваемые на интервью
_>спасибо за понимание и успехов в поиске работы _>
Здравствуйте, _NT_, Вы писали:
_NT>Здравствуйте, ilya_ny, Вы писали:
_>> _>>а я, как представитель другой компании, категорически требую запретить и удалить все темы в которых обсуждаются вопросы и задачи, задаваемые на интервью
_>>спасибо за понимание и успехов в поиске работы _>>
_NT>Вы это серьезно?!
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
G>>Теперь о том, как проверяющий проверяет задание. Надо заметить, что проверяющие знакомы почти со всеми возможными вариантами решения этой задачи (практика — великая вещь).
Т>И с таким
?
Я как раз хотел объявить конкурс в декларативном программировании на самое экзотическое и компактное решение без ограничений на язык . Тут АПВС грозился на Хаскеле в экран кода уложиться, но думаю, первый приз по любому твой
Здравствуйте, _NT_, Вы писали:
_NT>Здравствуйте, Left2, Вы писали:
L>>Мда... L>>Похоже, CQG всё же прийдётся менять тестовое задание
_NT>На их усмотрение
Хмм... А я как раз сходил в агентство на собеседование для CQG и теперь жду задания... Что же делать? Может прочитать условие и начать думать? Или и решение тоже прочитать и начать думать, как еще лучше сделать? Или это будет не честно и потому ничего не читать? Или ничего не делать — вдруг они резюме недостойным сочтут? Наверное, ничего читать не буду. Буду надеяться, что задачку пришлют и при том уже новую.
Здравствуйте, Phacochoerus, Вы писали:
P>Здравствуйте, Gaperton, Вы писали:
G>>Теперь о том, как проверяющий проверяет задание. P>....
P>Красиво написал. Вот только забыл указать, что описал свой собственный подход, которому придерживаются не все проверяющие.
Ничего я не забыл.
1) Решение, которое я привел в качестве эталона, пропустил бы любой из проверяющих.
2) Разница между проверяющими только в том, что каждый из них по разному расставляет акценты, и все.
3) Для того, чтобы это нивелировать, проверяющих на каждую задачу выделяется двое.