Re[2]: Про тестовое задание. Попинайте пожалуйста. - О работе

Во время собеседования интересно выявить у кандидата умение использовать имеющиеся знания и навыки. По-моему, то, на сколько человек умеет пользоваться тем, что знает гораздо важнее (в профессиональном плане и долгосрочной перспективе) …широты, так сказать, знаний, которые "лежат без дела" (или используются не по назначению, что суть одно и то же). Позиция, конечно, спорная (велкам).

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

Задачка предлагалась совсем не джуниорам, а даже программистам, от которых ожидалось, что они (по прошествии какого времени, введения в курс дела и ознакомления с особенностями) будут самостоятельно "пилить свой кусок проекта", то есть сеньёрам, как я это понимаю.

Суть задачи была в следующем: требовалось спроектировать элементарный, простейший, практически примитивный тип данных самого "широкого профиля" (как будто он будет добавлен в mscorlib на ровне с Int32, String, DateTime и т.п.). Например, тип данных, который представляет из себя отрезок времени между двумя датами (двумя точками на временной оси). По большому счёту, даже код показывать не нужно, достаточно рассказать, каким этот тип должен быть — что в нём было бы полезно учесть, что нужно было бы сделать, что не нужно.

Конечно, единственного правильного решения не существует (или их может быть много, не суть важно). Само решение даже не так важно — важно обсудить с кандидатом его же решение: "Это вот" было сделано за "тем-то", "это" для "того-то", а "это" не стали делать "потому-то" и "потому-то". Подвохов каких-то вроде нет: тут сам себе устанавливаешь правила-цели (что будешь делать), потом сам же выбираешь стратегию достижения-реализации (как будешь делать).

Для чистоты эксперимента, что ли, уберу под кат пару вещей, которые, как мне казалось, данное задание поможет проверить (возможно, не всем кандидатам я об этом говорил).

	Скрытый текст
	Хотелось таким заданием проверить, на сколько кандидат умеет обращаться с самыми (с одними из, на мой, конечно, взгляд) базовыми вещами библиотеки, с которой приходится работать (.NET/BCL) сумеет спроектировать нечто непротиворечивое, сбалансированное что ли, согласованное с самим собой и с другими важными частями BCL решение (это, пожалуй, самое главное) Я сам считаю задание достаточно сложным: при обсуждении решения можно поговорить очень о многом, да практически обо всём ключёвом как в дотнете так и в проектировании/архитектуре. Потому и интересным с точки зрения "задачки на собеседовании". "обо всём" расказывать никого не прошу

Поскажите пожалуйста следующие вещи:

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

Ну вот, теперь снова придётся что-то другое выдумывать, если меня ещё допустят к собеседованиям после таких каверз

Если получаю такие задания/вакансии по почте, то сразу отправляю в корзину.
Либо ожидается четкая постановка задачи, либо подразумевается длительное ее обсуждение.
Второе тестирует аналитические способности,и здесь сразу возникают вопросы по процессам разработки в компании, дабы не попасть в CMM-1.
Работа в компании, где много свободы, и столько же хаоса, сильно на любителя.
Не забывайте, что собеседующий — лицо компании.
А задачки на собеседовании — отражение рабочих заданий, и делать то-не-знаю-что занятие не из приятных.

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

N>Если получаю такие задания/вакансии по почте, то сразу отправляю в корзину.
N>Либо ожидается четкая постановка задачи, либо подразумевается длительное ее обсуждение.

Что в постановке не чётко сформулировано?

_FR>Суть задачи была в следующем: требовалось спроектировать элементарный, простейший, практически примитивный тип данных самого "широкого профиля" (как будто он будет добавлен в mscorlib на ровне с Int32, String, DateTime и т.п.). Например, тип данных, который представляет из себя отрезок времени между двумя датами (двумя точками на временной оси). По большому счёту, даже код показывать не нужно, достаточно рассказать, каким этот тип должен быть — что в нём было бы полезно учесть, что нужно было бы сделать, что не нужно.

Сферический универсальный конь в вакууме сделать проще чем понять Ваше немыслимое задание.

Отрезок времени между двумя датами измеряется в секундах и для этого идеально подходит тип double. Если вместо double надо сделать гомоморфно-анизотропный синхрофазотрон, то это много говорит об интеллекте собеседующего

Keep it simple stupid еще никто не отменял. Если отрезок между двумя датами отлично определяется double, то нефиг придумывать универсальный супертип с блэеджеком и шлюхами

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

_FR>>Во время собеседования интересно выявить у кандидата умение использовать имеющиеся знания и навыки. По-моему, то, на сколько человек умеет пользоваться тем, что знает гораздо важнее (в профессиональном плане и долгосрочной перспективе) …широты, так сказать, знаний, которые "лежат без дела" (или используются не по назначению, что суть одно и то же). Позиция, конечно, спорная (велкам).

D>ИМХО, задачка не стыкуется с тем, что написано в первом абзаце. Новый тип, который будет добавлен в базовую библиотеку, вряд ли создает 99.9% программистов.

То есть, если програмист _рисовал_ например финансовые графики, то _рисование_ температурных уже не его профиль? (я специально выделил важное — рисование, а не предметную область)? Как можно браться за проектирование каких-то репозитариев/визиторов/контролов/билдеров и прочего (сейчас у любого в резюме сказано про паттерны проектирования) не умея проектировать …гвоздь?

D>И вряд ли в ее решении будет что-то от реальных проектов.

Ну вот конкретно в нашем проекте такой тип есть и используется очень и очень широко.

D>Но такие задачки нужны, просто нужно понимать, что они мало пересекаются с повседневными задачами. Но это не отменяет необходимости знать базовые вещи. Короче, задача нужна, но проверяет она не то, что ты описываешь в первом абзаце.
D>Для начала стоит FizzBuzz задачку дать, можно сэкономить время.

Это не для начала, это типа самое сложное

_FR>Поскажите пожалуйста следующие вещи:
_FR>

_FR>

На сколько задание сложное? То есть не "смогли бы вы его сделать?", а "Не должен ли каждый "взрослый" программист уметь обращаться с перечисленными (под катом) вещами?" Естественно, всё это требует навыков и опыта. Именно это и ожидается от кандидатов.

Задание вполне по силам для сеньёра-помидора. Тем более что все мы любим ничего не делать и булждать мыслями по древу — как бы можно было бы забацать славный тип данных в .NET

_FR>

На сколько задание адекватное, то есть соответствует поставленным целям?

Если цель — это "пилить свой кусок проекта", то задание неадекватное. Если надо "пилить свой кусок проекта" — опишите человеку проект в двух словах (заодно сами будете четко понимать, что в нем и как

) минут за 10-15. А потом скажите что дескать вот в этом проекте вам надо будет "пилить свой кусок", интересно? Может человеку проект не интересен совсем и даже если он круто рубит — работать он не захочет нормально. Или (если ему/ей таки интересно) пусть расскажет как будет "пилить". Тут вы сможете посмотреть — насколько человек "правильный" с точки зрения "гайдлайнов вашей партии" — а то может у кандидата принципиально иной (и что самое страшное — принципиально) взгляд на то как надо писать ваш проект. А это будет просто смерть ~~тому многострочному мракобесию~~ сложно-архитектурированному решению, которое создавалось годами

_FR>

На сколько реально или даже должно выполнить его "тут же" за пятнадцать скажем минут (напоминаю, писать реализацию даже не обязательно, главное — обозначить решаемые проблемы, указать способ решения, не забыть перечислить все необходимые вещи, которые вы считаете обязательными).
_FR>

Для задач не имеющих одного однозначного решения лучше не ставить рамок, а дать возможность кандидату показать себя. Многое выясняется даже по тому, как и какие кандидат задает уточняющие вопросы.

P.S. Вообще — моя личная практика показывает, что лучше разговаривать на собеседовании предметно — о конкретном проекте и конкретной работе. А потом на испытательном сроке кандидата — уповать, что ты не ошибся с его оценкой

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

H>Keep it simple stupid еще никто не отменял. Если отрезок между двумя датами отлично определяется double, то нефиг придумывать универсальный супертип с блэеджеком и шлюхами

Будьте добры, ответьте в таком случае, зачем нужен тип DateTime, ведь если по вашим словам "отрезок между двумя датами отлично определяется double", то и точка на этом отрезке определяется даблом же и "нефиг придумывать универсальный супертип с блэеджеком и шлюхами"? Не касаясь конкретной реализации DateTime в BCL — что же, специальный тип для даты не нужен? А сделали его просто за ради переусложнить?

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

H>Отрезок времени между двумя датами измеряется в секундах и для этого идеально подходит тип double.

А задачка действительно работает!

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

D>>ИМХО, задачка не стыкуется с тем, что написано в первом абзаце. Новый тип, который будет добавлен в базовую библиотеку, вряд ли создает 99.9% программистов.
_FR>То есть, если програмист _рисовал_ например финансовые графики, то _рисование_ температурных уже не его профиль? (я специально выделил важное — рисование, а не предметную область)? Как можно браться за проектирование каких-то репозитариев/визиторов/контролов/билдеров и прочего (сейчас у любого в резюме сказано про паттерны проектирования) не умея проектировать …гвоздь?

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

D>>Для начала стоит FizzBuzz задачку дать, можно сэкономить время.
_FR>Это не для начала, это типа самое сложное

Так я и говорю, что перед твоей задачей стоит дать FizzBuzz, возможно и не придется тратить время на проектирование типа

_FR>Будьте добры, ответьте в таком случае, зачем нужен тип DateTime
Это вопрос риторический. И так можно скатиться до вопросов необходимости языков высокого уровня.
А вот зачем нужен Ваш новый тип — очень даже практический.
Кидаться проектировать, не поняв задачу до конца — не есть гут.

Очень часто люди делают вид, что поняли больше, чем на самом деле.©

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

_FR>>На сколько задание адекватное, то есть соответствует поставленным целям?

D>Если цель — это "пилить свой кусок проекта", то задание неадекватное. Если надо "пилить свой кусок проекта" — опишите человеку проект в двух словах (заодно сами будете четко понимать, что в нем и как

) минут за 10-15. А потом скажите что дескать вот в этом проекте вам надо будет "пилить свой кусок", интересно? Может человеку проект не интересен совсем и даже если он круто рубит — работать он не захочет нормально.

Это обязательно рассказываем. Мне кажется, предметная область достаточно интересна что бы обязательно подробнее о ней рассказать, дабы заинтересовать

D>Или (если ему/ей таки интересно) пусть расскажет как будет "пилить". Тут вы сможете посмотреть — насколько человек "правильный" с точки зрения "гайдлайнов вашей партии" — а то может у кандидата принципиально иной (и что самое страшное — принципиально) взгляд на то как надо писать ваш проект. А это будет просто смерть ~~тому многострочному мракобесию~~ сложно-архитектурированному решению, которое создавалось годами

"Иной" — не страшно. Мне кажется, что не правильно, когда взгляд такой, что допускает не согласованные, непродуманные (возможно поспешные, когда необходимости в этом нет никакой, а наоборот важна некая фундаментальность что ли — при этом возможность продумать есть) решения. Неудачный дизайн одного куска приводит к необходимости делать что-то криво в другом месте или воротить костыли-адаптеры или т.п. Без этого конечно никуда, но чем больше продуманности будет в дизайне, тем проще будет рефакторить в дальнейшем.

_FR>>На сколько реально или даже должно выполнить его "тут же" за пятнадцать скажем минут (напоминаю, писать реализацию даже не обязательно, главное — обозначить решаемые проблемы, указать способ решения, не забыть перечислить все необходимые вещи, которые вы считаете обязательными).

D>Для задач не имеющих одного однозначного решения лучше не ставить рамок, а дать возможность кандидату показать себя.

Какие рамки в данном задании вам показались лишними? Какие вообще рамки вы видите?

D>Многое выясняется даже по тому, как и какие кандидат задает уточняющие вопросы.

Именно так. Скажем, если решение получается не таким, как я ожидаю (ну имею же я право что-то ожидать) начинаются тёрки — а почему так, а не этак? Как правило, они приводят к тому, что кандидат просто о чём-то не подумал, на что-то не обращал внимания, чего-то не знал, а не к тому, что он просто "думал по другому", хотя не без исключений естественно

D>P.S. Вообще — моя личная практика показывает, что лучше разговаривать на собеседовании предметно — о конкретном проекте и конкретной работе. А потом на испытательном сроке кандидата — уповать, что ты не ошибся с его оценкой

Испытательный срок слишком. Нарпимер, взять десять человек и через пару месяцев оставить двоих — это мне кажется за гранью добра и зла по отношению к кандидатам же. А брать одного, потом, если не подошёл искать другого и т.д. — очень долго выйдет. Брать так наверняка. Но эти мои рассуждения уже оф-топик, кажется — давайте о них не спорить.

ЗЫ: при цитировании в списках форматер "ломается" и всё красит зелёным в некоторых браузерах (здесь). Можно просто в отквоченном убрать тег [list] (и даже уже [*] кажется надо убирать

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

H>>Отрезок времени между двумя датами измеряется в секундах и для этого идеально подходит тип double.
D>А задачка действительно работает!

А то, я долго этот вопрос не решался задать, не хотелось терять такой повод для беседы

_FR>Будьте добры, ответьте в таком случае, зачем нужен тип DateTime, ведь если по вашим словам "отрезок между двумя датами отлично определяется double", то и точка на этом отрезке определяется даблом же и "нефиг придумывать универсальный супертип с блэеджеком и шлюхами"? Не касаясь конкретной реализации DateTime в BCL — что же, специальный тип для даты не нужен? А сделали его просто за ради переусложнить?

Для даты нужен тип DataTime, для разницы между датами DateTime не нужен.
DateTime — DateTime = number;

Если надо хранить DateTime начала — не проблема

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

_FR>Конечно, единственного правильного решения не существует (или их может быть много, не суть важно). Само решение даже не так важно — важно обсудить с кандидатом его же решение: "Это вот" было сделано за "тем-то", "это" для "того-то", а "это" не стали делать "потому-то" и "потому-то". Подвохов каких-то вроде нет: тут сам себе устанавливаешь правила-цели (что будешь делать), потом сам же выбираешь стратегию достижения-реализации (как будешь делать).

Типы в стандартной библиотеке (любого языка) это все-таки инструменты, а не эйдосы по распространенному заблуждение. Поэтому и проектируются они как инструменты. Т.е. сделал заготовку исходя из своего опыта -- отдал народу на использование, собрал требования и исключил противоречия (обтесал заготовку), дальше в течение жизненного цикла точишь этот инструмент. Если ты предложишь спроектировать эйдос и тебе его спроектируют, то либо тебе повезло (маленькая вероятность) и ты поймал звезду, либо не повезло (гораздо более вероятно) и ты поймал человека в кризисе переусложнизма, который характеризуется очень широкими знаниями и малой продуктивностью в работе. Кстати, насчет DateTimeInterval с дабловым содержимым я могу привести кучу примеров, когда это будет удобно и уместно. Это инструмент, очень узконаправленный, но инструмент, поэтому такого человека имхо надо брать.

_FR>) А то, я долго этот вопрос не решался задать, не хотелось терять такой повод для беседы

C# компилять не хочу, а вот что есть отрезок между двумя датами в JavaScript

> var d1 =new Date();
undefined
> var d2 =new Date();
undefined
> d2-d1
3562

3562 — 3,62 секунды.

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

D>>>ИМХО, задачка не стыкуется с тем, что написано в первом абзаце. Новый тип, который будет добавлен в базовую библиотеку, вряд ли создает 99.9% программистов.
_FR>>То есть, если програмист _рисовал_ например финансовые графики, то _рисование_ температурных уже не его профиль? (я специально выделил важное — рисование, а не предметную область)? Как можно браться за проектирование каких-то репозитариев/визиторов/контролов/билдеров и прочего (сейчас у любого в резюме сказано про паттерны проектирования) не умея проектировать …гвоздь?

D>Если работа состоит в проектировании широко используемых типов, то да, все нормально. Если в формоклепательстве, багоисправлении или даже проектировании узких мест, где нужна жесткая оптимизация, то эта задача будет несколько оторвана от реальной работы.

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

D>>>Для начала стоит FizzBuzz задачку дать, можно сэкономить время.
_FR>>Это не для начала, это типа самое сложное

D>Так я и говорю, что перед твоей задачей стоит дать FizzBuzz, возможно и не придется тратить время на проектирование типа

Нет. Тут вот какое дело. FizzBuzz это мелочи. Я хочу проверить самым ненапряжным для кандидата образом именно умение комплексно мыслить, смотреть на проблему с разных углов зрения (а на дизайн именно так и требуется смотреть).

_FR>Это задачка не на какую-то супер-мега-анти-коуплинг-кохесинг-ажайл-архитектуру. Это попытка проверить, знает ли архитектор, какие бывают кирпичи. Чего такого свехъестественного, ну пускай даже просто сложненького в ней? Мне кажется, это даже проще должно быть для кандидата, чем обсуждение сортировок.

В C# есть замечательный тип TimeSpan

DateTime departure = new DateTime(2010, 6, 12, 18, 32, 0);
DateTime arrival = new DateTime(2010, 6, 13, 22, 47, 0);
TimeSpan travelTime = arrival - departure;

тот-же аналог double, но c тнтерфейсными плюшками.

Вы хотите заставить написать аналог существующего типа?

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

_FR>>Конечно, единственного правильного решения не существует (или их может быть много, не суть важно). Само решение даже не так важно — важно обсудить с кандидатом его же решение: "Это вот" было сделано за "тем-то", "это" для "того-то", а "это" не стали делать "потому-то" и "потому-то". Подвохов каких-то вроде нет: тут сам себе устанавливаешь правила-цели (что будешь делать), потом сам же выбираешь стратегию достижения-реализации (как будешь делать).

D>Типы в стандартной библиотеке (любого языка) это все-таки инструменты, а не эйдосы по распространенному заблуждение.

Что такое "эйдосы"?

D>Поэтому и проектируются они как инструменты. Т.е. сделал заготовку исходя из своего опыта -- отдал народу на использование, собрал требования и исключил противоречия (обтесал заготовку), дальше в течение жизненного цикла точишь этот инструмент. Если ты предложишь спроектировать эйдос и тебе его спроектируют, то либо тебе повезло (маленькая вероятность) и ты поймал звезду, либо не повезло (гораздо более вероятно) и ты поймал человека в кризисе переусложнизма, который характеризуется очень широкими знаниями и малой продуктивностью в работе.

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

D>Кстати, насчет DateTimeInterval с дабловым содержимым я могу привести кучу примеров, когда это будет удобно и уместно. Это инструмент, очень узконаправленный, но инструмент, поэтому такого человека имхо надо брать.

Это противоречит исходной задаче спроектировать тип общего назначения. Позвольте допустить, что вы не совсем знакомы с BCL.Вот там например есть такой примитив как TimeSpan а вот DateTimeInterval нет. Если вы добавите DateTimeInterval на даблах, он будет _там_ (а не в вашем конкретном узком месте) выглядеть неестественно. Если вы не знакомы с дотнетом, то не нужно тут спорить об этом. А если считаете, что знакомы и не понимаете — то по моему мнению давать вам пилить кусок проекта рано.

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

_FR>>Это задачка не на какую-то супер-мега-анти-коуплинг-кохесинг-ажайл-архитектуру. Это попытка проверить, знает ли архитектор, какие бывают кирпичи. Чего такого свехъестественного, ну пускай даже просто сложненького в ней? Мне кажется, это даже проще должно быть для кандидата, чем обсуждение сортировок.
H>В C# есть замечательный тип TimeSpan
…
H>тот-же аналог double, но c тнтерфейсными плюшками.
H>Вы хотите заставить написать аналог существующего типа?

Вовсе нет. Во-первых, это совсем не "аналог double". почему — это следует обсудить в профильном форуме. Во-вторых, это тип, описывающий _расстояние_ между двумя точками на числовой оси. Я прошу другое: "отрезок времени между двумя датами". Конкретными датами. На недопонимании формулировки никого не ловлю — объясняю разницу, что нужно не просто "две секунды", а "от второго февраля 2012 по 13 марта 2014".

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

_FR>Это задачка не на какую-то супер-мега-анти-коуплинг-кохесинг-ажайл-архитектуру. Это попытка проверить, знает ли архитектор, какие бывают кирпичи. Чего такого свехъестественного, ну пускай даже просто сложненького в ней? Мне кажется, это даже проще должно быть для кандидата, чем обсуждение сортировок.

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

_FR>Нет. Тут вот какое дело. FizzBuzz это мелочи. Я хочу проверить самым ненапряжным для кандидата образом именно умение комплексно мыслить, смотреть на проблему с разных углов зрения (а на дизайн именно так и требуется смотреть).

Ну не знаю, мелочи ли. Например, ООП программист, который не знает азы наследования, у меня вызывает сильное подозрение. Ладно, это уже оффтоп.

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

_FR>>Будьте добры, ответьте в таком случае, зачем нужен тип DateTime
N>Это вопрос риторический.

Это ещё почему? Есть есть тип, значит он зачем-то нужен. Иначе его быть не должно.

N>А вот зачем нужен Ваш новый тип — очень даже практический.

Это я обязательно объясняю зачем. Для например предоставления информации о датах рождения-смерти человека.

N>Кидаться проектировать, не поняв задачу до конца — не есть гут.

В задаче мне кажется всё чётко сформулировано. Вы почему-то один раз уже не ответили на прямой вапрос выше "Что в постановке не чётко сформулировано?" но уже повторили своё мнение

_FR>Вовсе нет. Во-первых, это совсем не "аналог double". почему — это следует обсудить в профильном форуме. Во-вторых, это тип, описывающий _расстояние_ между двумя точками на числовой оси. Я прошу другое: "отрезок времени между двумя датами". Конкретными датами. На недопонимании формулировки никого не ловлю — объясняю разницу, что нужно не просто "две секунды", а "от второго февраля 2012 по 13 марта 2014".

class DateInterval {
    public DateTime start;
    public DateTime end;
}

TimeSpan есть обертка вокруг double с методами "дай в секундах", "дай в минутах", "дай в сутках"

_FR>Откуда какие-то догадки про переусложнизм? Попробуйте пожалуйста мне ответить — что вообще сложного в том, что я спрашиваю? Угадать чего я ожидаю — на самом деле совсем не сложно, но главное это и не нужно. Нужно что-то предоставить а потом ответить, зачем есть то что есть и почему нет того чего нет.

Переусложизнм — поиск сложного решения, вместо простого. Простое

class DateInterval {
    public DateTime start;
    public DateTime end;
}

_FR>Во-вторых, это тип, описывающий _расстояние_ между двумя точками на числовой оси. Я прошу другое: "отрезок времени между двумя датами". Конкретными датами. На недопонимании формулировки никого не ловлю — объясняю разницу, что нужно не просто "две секунды", а "от второго февраля 2012 по 13 марта 2014".
Это не "_расстояние_ между двумя точками", а расстояние, смещение от конкретной точки.
Разница существенна.
И это не тянет на задание, просто вопрос на подумать-прикинуть.
Если все же это задание, то требуется выяснить дополнительные условия.

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

_FR>>Это задачка не на какую-то супер-мега-анти-коуплинг-кохесинг-ажайл-архитектуру. Это попытка проверить, знает ли архитектор, какие бывают кирпичи. Чего такого свехъестественного, ну пускай даже просто сложненького в ней? Мне кажется, это даже проще должно быть для кандидата, чем обсуждение сортировок.
D>Я и не говорю, что она сложная. Она слишком абстрактная в большинстве случаев,

Не более абстрактная, чем написание типов DateTime и TimeSpan и DateTimeOffset, однако три вышеперечисленных решены с той или иной долей успеха. "Взрослый" программист конечно же должен уметь решать абстрактные задачии. Более того — мывслить абстрактно тоже должен уметь. Но это задача к абстракциям не имеет прямого отношения. Это чисто хорошее знание некоторых вещей в дотнете. Ничего более.

D>что противоречит твоему нежеланию проверять знания, лежащие без дела. Я указал только на это. Задачка, как я уже сказал, вполне нормальная.

Я нигде не высказывал нежелания проверять знания, лежащие без дела. Я говорил о важности одного в данном конкретном случае. Другое так же несомненно имеет важность но в другом случае, по моему мнению.

_FR>>Нет. Тут вот какое дело. FizzBuzz это мелочи. Я хочу проверить самым ненапряжным для кандидата образом именно умение комплексно мыслить, смотреть на проблему с разных углов зрения (а на дизайн именно так и требуется смотреть).
D>Ну не знаю, мелочи ли. Например, ООП программист, который не знает азы наследования, у меня вызывает сильное подозрение. Ладно, это уже оффтоп.

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

За меня Handie ответил.
И вот еще дополнительные вопросы: точность 1 день, месяц, год? А может точность должна быть различной(несколько типов)?
Вариантов много, и здесь возникает больше вопросов, чем написанного кода.

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

_FR>>Вовсе нет. Во-первых, это совсем не "аналог double". почему — это следует обсудить в профильном форуме. Во-вторых, это тип, описывающий _расстояние_ между двумя точками на числовой оси. Я прошу другое: "отрезок времени между двумя датами". Конкретными датами. На недопонимании формулировки никого не ловлю — объясняю разницу, что нужно не просто "две секунды", а "от второго февраля 2012 по 13 марта 2014".

H>class DateInterval {
H>    public DateTime start;
H>    public DateTime end;
H>}

Спасибо. Но вот скажите (перед собеседованием я всё же вижу резюм и то, о чём говорить зависит от того что там сказано о себе, а то, что известно о вашем опыте в дотнете из профиля вообще не способствует даже рассмотрению задания) — вы действителньно претендуете на опытного дотнетчика?

H>TimeSpan есть обертка вокруг double с методами "дай в секундах", "дай в минутах", "дай в сутках"

Садитесь, двойка, как говориться. Рекомендую с вопросами "а чё так" обратиться в профильный форум, тут не об этом.

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

_FR>>Во-вторых, это тип, описывающий _расстояние_ между двумя точками на числовой оси. Я прошу другое: "отрезок времени между двумя датами". Конкретными датами. На недопонимании формулировки никого не ловлю — объясняю разницу, что нужно не просто "две секунды", а "от второго февраля 2012 по 13 марта 2014".
N>Это не "_расстояние_ между двумя точками", а расстояние, смещение от конкретной точки.
N>Разница существенна.

Существенна разница, да. var span = TimeSpan.FromSeconds(10); — смещение от какой "конкретной точки", не подскажете?

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

N>За меня Handie ответил.
N>И вот еще дополнительные вопросы: точность 1 день, месяц, год? А может точность должна быть различной(несколько типов)?
N>Вариантов много, и здесь возникает больше вопросов, чем написанного кода.

Что в дотнете используется для обозначения даты (временной точки)? Для продолжения разговора огаласите пожалуйста опыт использования дотнета, а то из профиля этого не понять. По вашим с Handie ответам у меня пока есть подозрение, что до этого вопроса наше собеседование бы просто не дошло

Если так будет и дальше, то продолжать мне не интересно.

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

_FR>>Откуда какие-то догадки про переусложнизм? Попробуйте пожалуйста мне ответить — что вообще сложного в том, что я спрашиваю? Угадать чего я ожидаю — на самом деле совсем не сложно, но главное это и не нужно. Нужно что-то предоставить а потом ответить, зачем есть то что есть и почему нет того чего нет.

H>Переусложизнм — поиск сложного решения, вместо простого. Простое

H>class DateInterval {
H>    public DateTime start;
H>    public DateTime end;
H>}

В таком случае ответье пожалуйста, почему существует тип TimeSpan, а вместо него не используется double как вы настаеваете или не long что было бы более естественно? ну или почему они не сделаны так вот:

class DateTime {
    public long value;
}

?

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

По сравнению с тем, как спроектирована BCL и как рекомендуют лучшие собаководы — предложенный вами вариант не выдерживает никакой критики. Если же вы не знаете, что и как рекомендуют делать при проектировании в дотнете (например, когда выбирать класс, а когда структуру) — то вам ещё рано считать себя "взрослым" дотнетчиком.

Плохо, может Вам не стоит собеседовать людей?
Я изначально задание неправильно понял, но не стал же сомневаться в Вашей способности постановки задач и спрашивать сколько у Вас лет опыта рекрутинга и проведения собеседований?
Мы не это сейчас обсуждаем. Или не обсуждаем — как Вам угодно.

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

N>Плохо, может Вам не стоит собеседовать людей?

Может быть. Только скажите почему. Вы же не ответили ни на один вопрос пока

N>Я изначально задание неправильно понял, но не стал же сомневаться в Вашей способности постановки задач и спрашивать сколько у Вас лет опыта рекрутинга и проведения собеседований?

А вы приходя на собеседование это спрашиваете? Мне вот казалось что именно с ознакомления резюме кандидата начинается собеседование. А опыт собеседующего во время собеседования есть офтопик.

N>Мы не это сейчас обсуждаем. Или не обсуждаем — как Вам угодно.

Тему я предложил. Вы что-то ответили. Я задал встречные уточняющие вопросы и ни на один ответа не получил. Наверное мне и правда лучше собеседования с вами не проводить.

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

D>>что противоречит твоему нежеланию проверять знания, лежащие без дела. Я указал только на это. Задачка, как я уже сказал, вполне нормальная.
_FR>Я нигде не высказывал нежелания проверять знания, лежащие без дела. Я говорил о важности одного в данном конкретном случае. Другое так же несомненно имеет важность но в другом случае, по моему мнению.

"По-моему, то, на сколько человек умеет пользоваться тем, что знает гораздо важнее (в профессиональном плане и долгосрочной перспективе) …широты, так сказать, знаний, которые "лежат без дела" "
Выделенное, ИМХО, употребляют в случаях, когда что-то практически ничтожно.

_FR>Да, это проверяется совсем другим. Я не хочу сейчас узнать как и что нужно спрашивать на собеседованиях. Я хочу узнать, не ерунду ли я спрашиваю? То есть должен ли программист это знать? А связь тут в том, что, оказывается, с такой простой задачей мало кто может справиться.

Естественно должен. И нет, не ерунду. Но, естественно, нельзя ограничиться только этой задачкой.

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

D>>>что противоречит твоему нежеланию проверять знания, лежащие без дела. Я указал только на это. Задачка, как я уже сказал, вполне нормальная.
_FR>>Я нигде не высказывал нежелания проверять знания, лежащие без дела. Я говорил о важности одного в данном конкретном случае. Другое так же несомненно имеет важность но в другом случае, по моему мнению.

D>"По-моему, то, на сколько человек умеет пользоваться тем, что знает гораздо важнее (в профессиональном плане и долгосрочной перспективе) …широты, так сказать, знаний, которые "лежат без дела" "
D>Выделенное, ИМХО, употребляют в случаях, когда что-то практически ничтожно.

Считаете важным, что бы я оправдался?

_FR>В таком случае ответье пожалуйста, почему существует тип TimeSpan, а вместо него не используется double как вы настаеваете или не long что было бы более естественно? ну или почему они не сделаны так вот:

В JavaScript например d2-d1 дает "double" (number). TimeSpan предлагает только синтаксический сахар в виде конвертеров в дни, часы минуты и т.д.

А Ваше умение поставить задачу привело к тупейшему халивару. Ставить надо точно и конкретно а не филосовскую воду разводить

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

_FR>Считаете важным, что бы я оправдался?

Нет, просто объясняю, к чему был мой коммент.

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

_FR>>В таком случае ответье пожалуйста, почему существует тип TimeSpan, а вместо него не используется double как вы настаеваете или не long что было бы более естественно? ну или почему они не сделаны так вот:

H>В JavaScript например d2-d1 дает "double" (number).

Никакого отношения к чему либо обсуждаемому здесь, на мой взгляд, данный факт отношения не имеет. Из данного факты вы делаете какие-то выводы, но совершенно напрасно в контексте выполнения сабжевого задания опытным дотнетчиком.

H>TimeSpan предлагает только синтаксический сахар в виде конвертеров в дни, часы минуты и т.д.

В этом вы не правы. Далеко не "только". За разъяснениями пожалуйста обращайтесь в профильный форум, но не ко мне.

H>А Ваше умение поставить задачу привело к тупейшему халивару. Ставить надо точно и конкретно а не филосовскую воду разводить

То есть моё "умение поставить задачу привело к" возникновению "философской" темы? Нет, я скромнее

Вопрос спрашиваю на самом деле сугубо практический. Да, может перемудрил с "отрезком" и "временной осью", но это уже давно выяснилось. Вы же, к сожалению, упорны в своём заблуждении относительно даблов и времени в дотнете — кажется, тупиковость диалога с вами возникает именно из-за этого, а не из-за неточности моей формулировки.

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

H>Отрезок времени между двумя датами измеряется в секундах и для этого идеально подходит тип double. Если вместо double надо сделать гомоморфно-анизотропный синхрофазотрон, то это много говорит об интеллекте собеседующего

а фраза выше говорит о твоих знаниях

Про type-rich programming, слыхал? http://habrahabr.ru/post/144334/

H>Keep it simple stupid еще никто не отменял. Если отрезок между двумя датами отлично определяется double, то нефиг придумывать универсальный супертип с блэеджеком и шлюхами

вот есть функция которая принимает дату, и отрезок времени.
по твоей логике и дату и отрезок можно закодировать простым типом, например double.
что лучше:

void some_func(double date,double interval);

или

void some_func(Date,DateInterval);

?
что надёжней?

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

P>

P>void some_func(double date,double interval);
P>

P>или
P>

P>void some_func(Date,DateInterval);
P>

да, и конечно же перегрузку не забываем:

void some_func(Date,Date);

а вам слабо с этими double'ами?

P>а фраза выше говорит о твоих знаниях

P>Про type-rich programming, слыхал? http://habrahabr.ru/post/144334/

О да, конечно. Надо создавать типы Day, Month, Year, Minute, Second, Millisecond, Microsecond, Nanosecond — а то не дай бог какой товарищ сложит дни с минутами.

TimeInterval(Year y, Month m, Day d, Second s, Millisecond m, Microsecond ms, Nanosecond n) {
...
}

Типобогатый код:

Year y = new Year(2012);
Month m = Month::September;
Day d = new Day(10);
Second s = new Second(30);
Millisecond m = new Millisecond(254);
TimeInterval interval = new TimeInterval(y, m, d, s, m);

Вот в unix конечно-же идиоты, сделали time_t в секундах с 1 января 1970 года.

А пост юморной, это сколько наворотов ради "типобогатства".

04.09.2012 14:42, Piko пишет:

> Про type-rich programming, слыхал? http://habrahabr.ru/post/144334/
Ужас. Налицо явное переусложнение простой задачи. Вместо конкретного
решения задачи, человек предлагает обобщенную реализацию для чего-то
несуществующего.
Вообще, описываемые автором проблемы всегда решались простым
комментарием, если была такая необходимость.

> H>Keep it simple stupid еще никто не отменял. Если отрезок между двумя
> датами отлично определяется double, то нефиг придумывать универсальный
> супертип с блэеджеком и шлюхами
Уже давно отменили, чему примером являются местные обсуждения.

> void some_func(double date,double interval);
> void some_func(Date,DateInterval);
> что надёжней?
Первое, по причине простоты и меньшего количества кода и следовательно
меньшего количества ошибок.

З.Ы. Да я знаю, что сейчас ты начнешь фантазировать о возможных
проблемах и совместными усилиями простой вопрос мы доведем до
сферического коня в вакууме. Я тебя в оном не поддержу.

Posted via RSDN NNTP Server 2.1 beta

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

P>>а фраза выше говорит о твоих знаниях

P>>Про type-rich programming, слыхал? http://habrahabr.ru/post/144334/
H>О да, конечно. Надо создавать типы Day, Month, Year, Minute, Second, Millisecond, Microsecond, Nanosecond — а то не дай бог какой товарищ сложит дни с минутами.

H>TimeInterval(Year y, Month m, Day d, Second s, Millisecond m, Microsecond ms, Nanosecond n) {
H> ...
H>}

не надо драматизировать

H>

H>Year y = new Year(2012);
H>

дядя, а зачем вообще new? Или ты из этих, жабашарперов?

H>Вот в unix конечно-же идиоты, сделали time_t в секундах с 1 января 1970 года.

time_t появился во времена C, для конкретных типов никакой инкапсуляции не было.
напрямую трогать time_t как-бы нельзя, так как implementation defined

H>А пост юморной, это сколько наворотов ради "типобогатства".

чей пост? Страуструпа?

P>time_t появился во времена C, для конкретных типов никакой инкапсуляции не было.
P>напрямую трогать time_t как-бы нельзя, так как implementation defined

А пацаны то и не знали!

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

>> Про type-rich programming, слыхал? http://habrahabr.ru/post/144334/
V>Ужас. Налицо явное переусложнение простой задачи. Вместо конкретного
V>решения задачи, человек предлагает обобщенную реализацию для чего-то
V>несуществующего.

Какой человек? Страуструп?

V>Вообще, описываемые автором проблемы всегда решались простым
V>комментарием, если была такая необходимость.

ну так ты видео посмотри. просрали многолимонный аппарат из-за такой вот ошибки, и наверняка ведь комментарии были.

>> void some_func(double date,double interval);
>> void some_func(Date,DateInterval);
>> что надёжней?
V>Первое, по причине простоты и меньшего количества кода и следовательно
V>меньшего количества ошибок.

из меньшего количество кода, не следует меньшее количество ошибок

V>З.Ы. Да я знаю, что сейчас ты начнешь фантазировать о возможных
V>проблемах и совместными усилиями простой вопрос мы доведем до
V>сферического коня в вакууме. Я тебя в оном не поддержу.

да нет же, зачем метать бисер перед свиньями

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

P>>time_t появился во времена C, для конкретных типов никакой инкапсуляции не было.
P>>напрямую трогать time_t как-бы нельзя, так как implementation defined

H>А пацаны то и не знали!

и чем предложенный топикстартером конкретный тип представляющий интервал, сохраняющий свои инварианты, идеологически отличается от time_t который нельзя трогать голыми грязными руками?

P>Какой человек? Страуструп?

Страуструп из монстройдального языка C++ сделал еще более страшного монстра. На пару с Александреску они создали язык, который может освоить только прошедший Путь Джедая и обретший Силу.

При программировании на PHP, JavaScript и т.д. люди пишут код, на С++ же часто демонстрируют силу духа и степень просветления. Я вот удивляюсь — в динамических языках нет адских шаблонов и метапрограммирования но почему-то это не только не мешает писать код, но и упрощает задачу.

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

H>При программировании на PHP, JavaScript и т.д. люди пишут код, на С++ же часто демонстрируют силу духа и степень просветления.

ни разу не видел такого в production

H>Я вот удивляюсь — в динамических языках нет адских шаблонов и метапрограммирования но почему-то это не только не мешает писать код, но и упрощает задачу.

а почему ты вообще запел про шаблоны? это какая-то попная боль?

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

P>>>time_t появился во времена C, для конкретных типов никакой инкапсуляции не было.
P>>>напрямую трогать time_t как-бы нельзя, так как implementation defined

H>>А пацаны то и не знали!

P>и чем предложенный топикстартером конкретный тип представляющий интервал, сохраняющий свои инварианты, идеологически отличается от time_t который нельзя трогать голыми грязными руками?

Как минимум тем, что аналога требуемого мной типа обычно не бывает. Я _например_ прошу тип, который позволяет описать отрезок времени меду двумя датами, например период жизни кого-то, или время прохождения воиской службы. Одним скаляром это нельзя выразить. Можно выразить парой. собственно рассказать, как сделать такую пару, что бы она органично выгляде бы на фоне дотнета я и прошу.

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

P>>>>time_t появился во времена C, для конкретных типов никакой инкапсуляции не было.
P>>>>напрямую трогать time_t как-бы нельзя, так как implementation defined

H>>>А пацаны то и не знали!
P>>и чем предложенный топикстартером конкретный тип представляющий интервал, сохраняющий свои инварианты, идеологически отличается от time_t который нельзя трогать голыми грязными руками?

_FR>Как минимум тем, что аналога требуемого мной типа обычно не бывает. Я _например_ прошу тип, который позволяет описать отрезок времени меду двумя датами, например период жизни кого-то, или время прохождения воиской службы. Одним скаляром это нельзя выразить. Можно выразить парой. собственно рассказать, как сделать такую пару, что бы она органично выгляде бы на фоне дотнета я и прошу.

то есть ты предлагаешь конкретный тип, который сохраняет свои инварианты, да?
а теперь перечитай выделенное

P>то есть ты предлагаешь конкретный тип, который сохраняет свои инварианты, да?
P>а теперь перечитай выделенное

Совершенно троллинговая и никчемная дискуссия. Ну, у меня настроение было потроллить. Из мухи раздули слона.

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

H>Совершенно троллинговая и никчемная дискуссия. Ну, у меня настроение было потроллить. Из мухи раздули слона.

такая же никчёмная как твоя реализация переворота строки

P>такая же никчёмная как твоя реализация переворота строки

Чувак, самоутверждайся в другом месте.

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

P>>>>>time_t появился во времена C, для конкретных типов никакой инкапсуляции не было.
P>>>>>напрямую трогать time_t как-бы нельзя, так как implementation defined

H>>>>А пацаны то и не знали!
P>>>и чем предложенный топикстартером конкретный тип представляющий интервал, сохраняющий свои инварианты, идеологически отличается от time_t который нельзя трогать голыми грязными руками?

_FR>>Как минимум тем, что аналога требуемого мной типа обычно не бывает. Я _например_ прошу тип, который позволяет описать отрезок времени меду двумя датами, например период жизни кого-то, или время прохождения воиской службы. Одним скаляром это нельзя выразить. Можно выразить парой. собственно рассказать, как сделать такую пару, что бы она органично выгляде бы на фоне дотнета я и прошу.

P>то есть ты предлагаешь конкретный тип, который сохраняет свои инварианты, да?
P>а теперь перечитай выделенное

Я не понимаю, что значит "конкретный тип, который сохраняет свои инварианты" потому что не понимаю что значит "свои инварианты", но я не предлагаю "тип представляющий интервал". Тип что я прошу сравнивать с time_t вообще не корректно, именно это я и хотел сказать.

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

_FR>Я не понимаю, что значит "конкретный тип, который сохраняет свои инварианты" потому что не понимаю что значит "свои инварианты",

что такое инварианты класса знаешь?

_FR>Тип что я прошу сравнивать с time_t вообще не корректно, именно это я и хотел сказать.

почему не корректно? некоторые части вполне корректно, например time_t какая-никакая, хотя бы мнимая, инкапсуляция пристуствует

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

_FR>Во время собеседования интересно выявить у кандидата умение использовать имеющиеся знания и навыки. По-моему, то, на сколько человек умеет пользоваться тем, что знает гораздо важнее (в профессиональном плане и долгосрочной перспективе) …широты, так сказать, знаний, которые "лежат без дела" (или используются не по назначению, что суть одно и то же). Позиция, конечно, спорная (велкам).

Согласен. Я вот за собой замечаю нехорошую вещь: вот вроде есть уже и относительно немаленький опыт, и теоретические знания, читал разные умные книги и т.д. и т.п., а на практике бывает что в реальной работе об этом забываешь — напишешь код, и если потом критически на него посмотреть, то можно найти несколько "запашков".

_FR>Суть задачи была в следующем: требовалось спроектировать элементарный, простейший, практически примитивный тип данных самого "широкого профиля" (как будто он будет добавлен в mscorlib на ровне с Int32, String, DateTime и т.п.). Например, тип данных, который представляет из себя отрезок времени между двумя датами (двумя точками на временной оси). По большому счёту, даже код показывать не нужно, достаточно рассказать, каким этот тип должен быть — что в нём было бы полезно учесть, что нужно было бы сделать, что не нужно.

Мне было бы интересно.

_FR>На сколько задание адекватное, то есть соответствует поставленным целям?

Это уже тебе виднее, чем будут заниматься потом эти люди. Я бы сказал что задачка больше подходит для тех, кто потом будет писать какие-то переиспользуемые библиотеки, небольшие фреймворки.

_FR>На сколько реально или даже должно выполнить его "тут же" за пятнадцать скажем минут (напоминаю, писать реализацию даже не обязательно, главное — обозначить решаемые проблемы, указать способ решения, не забыть перечислить все необходимые вещи, которые вы считаете обязательными).

Вот ограничение по времени лично меня бы напрягло, я бы наверное начал нервничать, если бы мне заикнулись о временных рамках. Имхо лучше не делать ограничений по времени, а наоборот расслабить человека, типа "ну вы пока начинайте думать, не торопитесь, а я пойду чайку нам заварю". Ведь лучше если человек подумает побольше, и выдаст более качественный результат, чем уложится в 15 минут и выдаст сырой недодуманный вариант? Ну и лучше дать человеку компьютер, мне бы было удобнее сразу в коде начинать набросок делать, может даже начал бы с теста.

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

_FR>>Я не понимаю, что значит "конкретный тип, который сохраняет свои инварианты" потому что не понимаю что значит "свои инварианты",
P>что такое инварианты класса знаешь?

Я не понимаю, как какой-то тип может сохранять _чужие_ инварианты. Но к интересующему меня вопросу это никакого от ношения не имеет. Я лишь на всякий случай уточнил задачу, потому что мне показалось, что вы не совсем верно её поняли.

_FR>>Тип что я прошу сравнивать с time_t вообще не корректно, именно это я и хотел сказать.
P>почему не корректно? некоторые части вполне корректно, например time_t какая-никакая, хотя бы мнимая, инкапсуляция пристуствует

В таком разрезе ("некоторые чести", "инкапсуляция") любые два типа сравнивать корректно даже в разных языках/концепциях/системах

но ни к обсуждаемому вопросу, ни к моему уточнению это отношения не имеет.

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

_FR>Как можно браться за проектирование каких-то репозитариев/визиторов/контролов/билдеров и прочего (сейчас у любого в резюме сказано про паттерны проектирования) не умея проектировать …гвоздь?

Имхо вот так вот и можно. Мне кажется что качественно сделать такой тип может быть сложнее и может требовать от человека больше знаний и опыта, чем использовать какой-то известный паттерн.

04.09.2012 15:34, Piko пишет:

> Какой человек? Страуструп?
Ссылка не на Страуструпа у тебя, это раз. Два, Страуструп еще тот теоретик.

> ну так ты видео посмотри. просрали многолимонный аппарат из-за такой вот
> ошибки, и наверняка ведь комментарии были.
Не смотрел и не буду, но обычно это проблемы просравших. Если там
настолько все плохо от спасти таких от того, чтобы они не разбили себе
голову поможет только комната, обитая войлоком. И это офтопик.

> V>Первое, по причине простоты и меньшего количества кода и следовательно
> V>меньшего количества ошибок.
>
> из меньшего количество кода, не следует меньшее количество ошибок
Перечитай еще раз.

Posted via RSDN NNTP Server 2.1 beta

04.09.2012 15:48, Handie пишет:

> Страуструп из монстройдального языка C++ сделал еще более страшного
> монстра.
Не такой он и страшный, если не извращаться с ним.

> При программировании на PHP, JavaScript и т.д. люди пишут код, на С++ же
> часто демонстрируют силу духа и степень просветления.
Это глупость пишущих. Им дали в руки мощнейший инструмент и они его
стали использовать для пенисометрии, причем осложняя оным жизнь себе и
сильно.
Это прекрасно видно по оному форуму, на собеседованиях не по С++ (пока
туда не добрались укушенные Александреску) ищут тех, кто будет решать
задачи, а по С++ тех, у кого больше.

Posted via RSDN NNTP Server 2.1 beta

04.09.2012 16:41, MozgC пишет:

> Согласен. Я вот за собой замечаю нехорошую вещь: вот вроде есть уже и
> относительно немаленький опыт, и теоретические знания, читал разные
> умные книги и т.д. и т.п., а на практике бывает что в реальной работе об
> этом забываешь — напишешь код, и если потом критически на него
> посмотреть, то можно найти несколько "запашков".
Потому что в реальной работе требуется написать решение задачи за
ограниченное время, а на исправление всех "запашков" потребоваться может
бесконечность, а это деньги.

Posted via RSDN NNTP Server 2.1 beta

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

H>>Я вот удивляюсь — в динамических языках нет адских шаблонов и метапрограммирования но почему-то это не только не мешает писать код, но и упрощает задачу.

Это в руби, перле, питоне и js нет метапрограммирования? Или ты про другие динамические?

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

H>При программировании на PHP, JavaScript и т.д. люди пишут код, на С++ же часто демонстрируют силу духа и степень просветления.

Тебе про С++ ещё кошмары не снятся?

... << RSDN@Home >>

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

_FR>На сколько задание сложное? То есть не "смогли бы вы его сделать?", а "Не должен ли каждый "взрослый" программист уметь обращаться с перечисленными (под катом) вещами?" Естественно, всё это требует навыков и опыта. Именно это и ожидается от кандидатов.
С моей точки зрения — всё ок, такой подход проверяет все скиллы будущего сотрудника, а не только умение кодить. "Спроектировать ... тип данных, который представляет из себя отрезок времени между двумя датами " с ходу не выйдет, нужна дополнительная информация. Всё как в реальной обстановке: люди не любят описывать контекст — не по злому умыслу, а просто "и так очевидно"

Будущий сеньор просто обязан спросить 2 вещи:
1. Описание предметной области и нюансы, про которые знает только эксперт в предметной области. Сотрудник может забыть/не знать про разницу в летнем/зимнем времени, leap seconds и прочие прелести — это абсолютно нормально. Ненормально, когда человек стесняется спросить: "что мне нужно знать перед тем как решать задачу?".

2. Затем — обязательно — попросить привести сценарии работы с нашим типом данных. Это буквально первая заповедь, её должен знать любой разработчик библиотек:

Framework Design Principle
Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.

(с) Framework Design Guidelines

Тут тоже может всплыть куча неочевидных вещей:
* может потребоваться работа с неограниченными справа/слева интервалами (с 1.01.2012 по бесконечность; по 31 января такогото года и т.д.)
* отрезок может включать/исключать конечные даты (с 12:00 первого сентября включительно и по 12:00 второго сентября исключительно)
* как насчёт объединения, сортировки, пересечения отрезков?
* что, если потребуется работать не с датами, а с другим типом?
* как насчёт составных интервалов/интервалов с "дырками"?

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

_FR>На сколько задание адекватное, то есть соответствует поставленным целям?
_FR>На сколько реально или даже должно выполнить его "тут же" за пятнадцать скажем минут (напоминаю, писать реализацию даже не обязательно, главное — обозначить решаемые проблемы, указать способ решения, не забыть перечислить все необходимые вещи, которые вы считаете обязательными).
Зависит от того, как именно вы уточните задание. Обычно дизайн (по крайней мере основные моменты) вырисовывается прямо по ходу беседы, когда каждое новое требование отсекает сразу несколько решений. Например, если надо хранить отрезок без правой/левой границы или нужен отрезок, способный работать с любыми типами данных, то логичнее будет хранить начало-конец интервала, а не "начало + длина"

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

_FR>Ну вот, теперь снова придётся что-то другое выдумывать, если меня ещё допустят к собеседованиям после таких каверз

Почему? Правильное задание — это вешь в себе, по мере уточнения требований могут получаться весьма неожиданные результаты.

Например, шикарен вопрос: Дано: интервал1 — с 1 по 10 апреля. интервал2 — с 1 по 10 мая. Что должна возвращать операция объединения этих интервалов?

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

_FR>>На сколько задание сложное? То есть не "смогли бы вы его сделать?", а "Не должен ли каждый "взрослый" программист уметь обращаться с перечисленными (под катом) вещами?" Естественно, всё это требует навыков и опыта. Именно это и ожидается от кандидатов.
S>С моей точки зрения — всё ок, такой подход проверяет все скиллы будущего сотрудника, а не только умение кодить. "Спроектировать ... тип данных, который представляет из себя отрезок времени между двумя датами " с ходу не выйдет, нужна дополнительная информация. Всё как в реальной обстановке: люди не любят описывать контекст — не по злому умыслу, а просто "и так очевидно"

S>Будущий сеньор просто обязан спросить 2 вещи:
S>1. Описание предметной области и нюансы, про которые знает только эксперт в предметной области. Сотрудник может забыть/не знать про разницу в летнем/зимнем времени, leap seconds и прочие прелести — это абсолютно нормально. Ненормально, когда человек стесняется спросить: "что мне нужно знать перед тем как решать задачу?".

Предметная область такая же, как им для типа DateTime нарпимер или даже Int32

То етсь _примитивный_ тип данных.

S>2. Затем — обязательно — попросить привести сценарии работы с нашим типом данных.

Это и есть задача проектирования. Никто вам не даст (не заказчик и не даже менеджер проекта) таких сценариев. Их надо придумать самому. Самому принять решение — это мы позволяем, а это нет.

S>Тут тоже может всплыть куча неочевидных вещей:
…
S>Если подобные вещи не спросить сразу — они всплывут потом, когда тип уже будет готов и непригоден к использованию

Ещё раз — я не прошу спроектировать тип, который мне нужен для какой-то конкретной задачи. Я прошу спроектировать примитивный тип, который сможет использоваться там, где нужно оперировать отрезком времени. И исходить нужно именно из такой постановки. Лично мне кажется, тут есть два пути — или оставтиь только самое необходимое (самому решить не сложно), что понадобится везде или выбрать что-то одно. Но если выбранное окажется узкозаточенным подо что-то одно — это слегка нарушит условие, а если это выльется в отдельную библиотеку — окажется перебором и несомненно уже переусложнизмом. Если я в постановке задачи сказал, что тип должен быть примитивен, то именно \это и имел в виду! смотрите: и Int32 и String вполне конкретны и очень ре-юзабельны. Тип который я прошу должен быть "как они".

Я ведь думаю как — ни заказчик "тётя Маша", как я уже сказал, ни проджект менеджер не станет взрослому программисту рассказывать, как ему проектировать элементарный тип данных. Человек получает задачу. Он её декомпозирует, решает, что ему нужно для реализации и реализует. Если каждый простейший тип нужно обсуждать с менеджером, то это явно не взрослый программист. Люди сами определяют, какие типы понадобятся для решения задачи, сами их пишут и поддерживают. Я хочу посмотреть как они умеют это делать. Как они свои знания об используемом языке-платформе применяют при этом.

От "взрослого" программиста я ожидаю умения решить, что ему нужно для решения задачи и реализации решения. Задача — написать примитивный тип самого широкого "спектра действия" (да даже узкого — разницы на самом деле _никакой_). "Широкого" я говорю как раз для того, что бы отстраниться от конкретной прикладной задачи. Ну вот позвольте мне аналогию провести. Я в институте несколько лет слушал лекции про болты. Я прошу вас спроектировать болт. Вы можете спросить, например, про нагрузку, которую болт должен уметь держать. Её я вам скажу. Пожалуй, это и всё. Из того, что я не скажу, что именно я буду скреплять болтом — лампочку там в машине прикручивать или ручку к каминной полке — следует лишь то, что детали связанные с такими тонкостями меня в данном конкретном задании не интересуют. Я хочу посмотреть, как вы рассчитаете болт, как выберете материал, резьбу и прочее. Но если при выполнении вы мне покажете какой-то очень уж экзотический и изощрённый болт (под заявленную нагрузку естественно) — я посмотрю на вас косо: зачем было впадать в крайности? Выбрали бы что нить попроще, что бы легче было бы разобраться.

Я же никакой ловушки не готовлю. Так с типами здесь тоже самое. Тут вот меня пытались обвинит в "переусложнизме", так по моему он наоборот с другой стороны :о) Это сложно не просто, но не сложнее, чем спроектировать вообще любой тип. Кода может быть немного побольше, но думать надо абсолютно так же, о том же, как при написании любого вашего типа. Поступать да, скорее всего по другому (в виду специфики общности типа) но думать и принимать в расчёт совершенно те же самые вещи.

Теперь вот посмотрим:

S>* может потребоваться работа с неограниченными справа/слева интервалами (с 1.01.2012 по бесконечность; по 31 января такогото года и т.д.)
S>* отрезок может включать/исключать конечные даты (с 12:00 первого сентября включительно и по 12:00 второго сентября исключительно)
S>* как насчёт объединения, сортировки, пересечения отрезков?
S>* что, если потребуется работать не с датами, а с другим типом?
S>* как насчёт составных интервалов/интервалов с "дырками"?

Это всё надо вспомнить-представить себе при проектировании. То есть это правильные вопросы которые, как я ожидаю, подходящий в данном случае человек _себе_ задаст

А дальше посмотрит на задание и найдёт ответы. Потом он покажет, что у него получилось…

…Я, например, хитрющие такие глаза сделаю и спрошу:
— А если вот если понадобится "неограниченный" интервал, а у ваш тип не предназначендля этого, что посоветуете?
А он не в этот момент станет
— Ааааа… мммм… надо подумать…
Но дерзко так
— Я думал об этом, но это добавляет лишние данные, помимо самих концов отрезков и делает тип намного сложнее и решил, что если понадобится, то можно сделать новый тип на основании моего имеющегося и какого-то флажочка, который скажет, какая часть уходит в бесконечность или может даже лучше спроектировать под это дело отдельный тип.

Или наоборот, сделает такую вещь, а я спрошу:
— Зачем вам это показалось необходимым? И код вот раздулся, и помимо двух концов отрезков хранить ещё их интерпретацию пришлось — размер увеличился — стоит ли?, и … [ну найду что сказать]".
А он мне
— А вот удалось так интерфейс сделать, что эта особенность и не заметна вовсе тогда, когда не нужна. А зато когда понадобится — окажется очень кстати.

Ну вот и с остальным примерно так же

Шутка конечно, но, надеюсь, так понятнее.

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

_FR>Предметная область такая же, как им для типа DateTime нарпимер или даже Int32

То етсь _примитивный_ тип данных.

Интервалы — это не примитивный тип данных, это целый набор абстракций со своими правилами операций, логикой и холиварами (являются ли ±∞ допустимыми значениями числовой прямой, могут ли существовать интервалы вида (a,a], допустимо ли объединение непересекающихся интервалов и т.д. и т.п.). Аналогично — с работой с временем.

Конечно, соискатель может решить, что ему виднее и самостоятельно выбрать сценарии по которым будет проверять свой дизайн. И, если повезёт, сможет обосновать свой выбор так, что не придерётесь. А На выходе — абсолютно корректный и абсолютно бесполезный код, потому что вы в голове держали совсем другие юз-кейсы. Ну и зачем оно нужно?

_FR>Ещё раз — я не прошу спроектировать тип, который мне нужен для какой-то конкретной задачи. Я прошу спроектировать примитивный тип, который сможет использоваться там, где нужно оперировать отрезком времени. И исходить нужно именно из такой постановки.
_FR> ...
_FR>От "взрослого" программиста я ожидаю умения решить, что ему нужно для решения задачи и реализации решения.
_FR> ...
_FR>Это всё надо вспомнить-представить себе при проектировании. То есть это правильные вопросы которые, как я ожидаю, подходящий в данном случае человек _себе_ задаст

А дальше посмотрит на задание и найдёт ответы. Потом он покажет, что у него получилось…

На мой взгляд, это неправильно. Если утрировать, то получается, что основной критерий приёма на работу следующий: человек должен решить задачу самостоятельно. Если ему не хватает информации — он должен додумать её сам, не обращаясь к экспертам, за что потом и будет обстёбан

Такие критерии достаточны для приёма студента, благо с него и спроса никакого нет, главное — уметь писать переиспользуемый код. Но раз уж собеседуем на сеньора, то нас в первую очередь должна интересовать способность человека вести часть проекта. Т.е. не делать на авось, а уметь самостоятельно разведать обстановку и принимать решения на основе объективной информации. Ну не будете же вы в реальной ситуации посередине итерации спрашивать:
"А почему это у нас нет ХХХ?"
или
"А зачем у нас добавилась ХХХ, когда горят сроки по YYY?"
Ответ "а вот тут я не получил указаний, поэтому сделал как показалось правильным" — это самое натуральное детство, потому что девелопер почти наверняка потратил время впустую, ради фана.

P.S. Вообще, вопрос сам по себе достаточно холиварен и я не готов отстаивать свой мнение до последней буквы так что предлагаю ничью

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

_FR>>Предметная область такая же, как им для типа DateTime нарпимер или даже Int32

То етсь _примитивный_ тип данных.

S>Интервалы — это не примитивный тип данных, это целый набор абстракций со своими правилами операций, логикой и холиварами (являются ли ±∞ допустимыми значениями числовой прямой, могут ли существовать интервалы вида (a,a], допустимо ли объединение непересекающихся интервалов и т.д. и т.п.). Аналогично — с работой с временем.

А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).

S>На мой взгляд, это неправильно. Если утрировать, то получается, что основной критерий приёма на работу следующий: человек должен решить задачу самостоятельно.

Конечно.

S>Если ему не хватает информации — он должен додумать её сам, не обращаясь к экспертам, за что потом и будет обстёбан

Вовсе нет. Ну какоё ещё информации не хватает, что бы сделать такое простое задание? Ну вы с ума что ли все посходили? То, что я прошу — каждый программист делает (или не делает) по сто раз на дню. То, что мне нужно должно обсуждаться на каждом кодеревью там где оно есть. Чесное слово. При написании абсолютного каждого типа данных. Вот вы сколько типов данных написали за прошедший месяц? Ну каких вы от меня подвохов ожидаете-то? Ну перечислите что ли, а то ну все поголовно как сговорились "слишком сложно, ничего не ясно, чего самим всё выдумывать" — а как спросишь "ну что выдумывать-то вам тут приходится такого сложного?" ни один не признаётся, прям партизаны

Девушки в Смольном и то порешительнее были сто лет назад чем суровые програмисты с кучей лет опыта сегодня

Принимать решения "это мы сделаем так, это вот так, а там будет этак" приходится повсеместно, буквально на каждом шагу. но многие об этом попросту не задумываются, не понимают, что если не обратить тут внимание на это то это выльется туда-то.

Я вот скажу — такой тип (или аналогичный) написать, то есть набрать в редакторе — ну минут пятнадцать — я не очень быстро печатаю. Любой человек, только что прочитавший вдумчиво Рихтера например, ну за час должен суметь управиться. Начать говорить о том, каким этот тип должен быть любой архитектор/проектировщик должен уметь сразу.

В общем я похоже был прав, что написать визитор там какой-нить или веб-сервер современному программисту проще и понятнее, чем элементарную вещь

Вернее, _взяться_ написать

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

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

D> Но это не отменяет необходимости знать базовые вещи.
Меня всегда удивляло такое безаппеляционное утверждение про необходимость знать базовые вещи.
Это уже начинает напоминать религию "базовых вещей".

Я вот, например, понятия не имею, как делают сахар, шоколадки Сникерс и Водку (могу только догадываться), но, тем не менее, не испытываю проблем с их употреблением.
Даже, если бы и знал я _базовые вещи_, то это только бы усилило мою вселенскую печаль и не более

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

_FR>А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).

Более чем применимо. Только холиварить неинтересно. Всё уже есть из коробки и обсуждение преимуществ-недостатков DateTime vs DateTimeOffset никакой практической пользы не принесёт. Но даже при наличии стандартной реализации иногда приходится пилить велосипеды. Джо Скит joda time не от скуки портировал

_FR>Вовсе нет. Ну какоё ещё информации не хватает, что бы сделать такое простое задание? Ну вы с ума что ли все посходили?
Того, что нужно получить на выходе

Понятное дело, с одноразовым "написал и выбросил" проблем нет. А вот с библиотеками, тем более с публичным API...

При реализации интервалов есть несколько наборов сценариев, каждый из которых отсекает целую ветку вариантов реализации. Упрощённо:

1. Без требований: достаточно пары "begin-end" или "begin-duration" Обе реализации равноправны, но вторая имеет хороший задел для работы с продолжительностью (размер в часах, днях, месяцах и т.п.) и для описания абстрактных интервалов, без даты начала — год, месяц и т.п.

2. Нужно выполнять операции с интервалами — пересечение, объединение, расширение, проверка на входимость и т.п. Вариант с "begin-duration" отпадает из-за лишних накладных расходов.

3. Поддержка ±∞, типов границ (включительно-исключительно). Приходится вводить отдельную структуру для границ — передавать значение границы и тип границы отдельно сильно усложняет код.

4. Введение операций "получить дополнение интервала", "исключить интервал" — нужны составные интервалы с "дырками" внутри. Они порождают свой набор API, который не имел смысла до появления составных инетрвалов и кучу интересных дизайнерских проблем — например, стоит ли наследовать составной интервал от обычного? Оба варианта имеют далекоидущие последствия, если диапазоны активно используются в API.

5. Введение "ключей" диапазонов (значений, ассоциированных с отрезком) и быстрый поиск ключа в составном диапазоне на определённую дату.

Это я привёл только сценарии, которые требуют хранения интервалов как "begin-end". С begin-duration тоже есть свои заморочки, но они настолько редки, что затачивать под них кучу хелперов будет оверкиллом.

Плюс есть ешё несколько "мёртвых" требований — типа поддержки произвольных компареров, пустого диапазона, "неправильных" диапазонов (левая граница больше правой) — если их добавить, API и клиентский код усложняются так, что пользоваться интервалами становится невозможно.

Я имел опыт итеративной доработки классов по работе с диапазонами, когда между каждой из итераций проходило порядочно времени, классы уже успевали расползтись по коду а прочие разработчики — налепить временных костылей. На доработки уходило на порядок больше времени, чем если бы все "простые" и "очевидные" сценарии были бы рассмотрены с самого начала.

_FR>Я вот скажу — такой тип (или аналогичный) написать, то есть набрать в редакторе — ну минут пятнадцать — я не очень быстро печатаю.
Это будет прототип, а не готовая к реализации в продакшне идея. Если мы всё-таки собеседуем синьора, то способность написать компилируемый код по-моему не так важна, как умение предупреждать риски _до_ написания кода

_FR>В общем я похоже был прав, что написать визитор там какой-нить или веб-сервер современному программисту проще и понятнее, чем элементарную вещь

Вернее, _взяться_ написать

Ну да

Просто написать универсальную штуку, да ещё так, чтобы её было легко поддерживать, не ломая ничего у пользователей — это целое искусство. И на практике будет щастьем если соискатель сможет хотя бы прототип рабочий накидать, не говоря уже о том, чтобы назвать сильные-слабые стороны

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

D>> Но это не отменяет необходимости знать базовые вещи.
M>Меня всегда удивляло такое безаппеляционное утверждение про необходимость знать базовые вещи.
M>Это уже начинает напоминать религию "базовых вещей".

M>Я вот, например, понятия не имею, как делают сахар, шоколадки Сникерс и Водку (могу только догадываться), но, тем не менее, не испытываю проблем с их употреблением.

И другие не будут испытывать никаких проблем из-за вашего незнания до тех пор пока вы не будете искать работу профессионала в чём-то, связанном с производством "сахар, шоколадки Сникерс и Водку".

M>Даже, если бы и знал я _базовые вещи_, то это только бы усилило мою вселенскую печаль и не более

Как обращаться и имеющимися знаниями — личное дело каждого

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

_FR>>А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).

S>Более чем применимо. Только холиварить неинтересно. Всё уже есть из коробки и обсуждение преимуществ-недостатков DateTime vs DateTimeOffset никакой практической пользы не принесёт. Но даже при наличии стандартной реализации иногда приходится пилить велосипеды. Джо Скит joda time не от скуки портировал

Не переводите тему разговора. Мои слова и ваши, на которые я отвечал (и которые вы направсно убрали из цитаты) были совсем не о том, что вы тут начали о "DateTime vs DateTimeOffset" и т.п. Если вы будете так быстро терять нить диалога и перескакивать с сути на что-то побочное,Ю то лучше и не продожать.

_FR>>Вовсе нет. Ну какоё ещё информации не хватает, что бы сделать такое простое задание? Ну вы с ума что ли все посходили?
S>Того, что нужно получить на выходе

Понятное дело, с одноразовым "написал и выбросил" проблем нет. А вот с библиотеками, тем более с публичным API...

То, что нужно сказано в самом начале

А придираться типа "купи слоника", то есть до бесконечности выяснять что-то, умеет любой ребёнок. Надо же всё-тки где-то совесть иметь и не стоит спрашивтаь тут одно и то же столько раз. Если после всего то что я наотвечал вма и другим в этом топике вам не достаточно что бы сделать что попросили — то продолжать конечно бесмысленно. Собеседование как правило длится два-три часа максимум. Если такую простую задачу я должен объяснять вам несколдько часов — то вы мне не нужны.

S>При реализации интервалов есть несколько наборов сценариев, каждый из которых отсекает целую ветку вариантов реализации.

Я знаю. Ну и что. То же самое можно сказать про DateTime. Вы не заметили что ни разу на мой вопрос в нашей дискуссии не ответили? Ещё раз повторю — Те же яйца есть и с типом DateTime — "несколько наборов сценариев". Однако тип существует. Он написан. Если вы этого не понимаете, то избавьте уж а? Дальше даже не читал, ибо бесполезно — я вам много уже написал, но у меня такое впечатление, что и вы не читаете.

Проблем можно придумать множество. Они стояли и перед программистами, писавшими тип DateTime и TimeSpan и т.д. И как-то имеющиеся противоречия те программисты, как сумели, разрешили. Если вы не умеете такие противоречия разрешать, не умеете из нескольких альтернатив осознанно выбрать какую-то одну (или даже несколько), а вместо этого предпочитаете утверждать, что вам ничего необходимого и сказали — дело ваше

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

_FR>Суть задачи была в следующем: требовалось спроектировать элементарный, простейший, практически примитивный тип данных самого "широкого профиля" (как будто он будет добавлен в mscorlib на ровне с Int32, String, DateTime и т.п.). Например, тип данных, который представляет из себя отрезок времени между двумя датами (двумя точками на временной оси). По большому счёту, даже код показывать не нужно, достаточно рассказать, каким этот тип должен быть — что в нём было бы полезно учесть, что нужно было бы сделать, что не нужно.

Надоело мне тут ерундой заниматься, пытаясь объяснить самые простые вещи. Мне было интересно-то всего выяснить всего ничего:

[Serializable]
[DebuggerDisplay("{From} - {To}")]
public struct DateTimeInterval : IFormattable, IEquatable<DateTimeInterval>
{
  static DateTimeInterval() {
    Empty = default(DateTimeInterval);
  }

  public DateTimeInterval(DateTime from, DateTime to) : this() {
    // Проверка, что каинды совместимы
    // Проверка, что to >= from или как-то ещё, главное что бы билось со всем остальным
  }

  public DateTimeInterval(DateTime from, TimeSpan duration) : this(from, from + duration) { }

  public static DateTimeInterval Empty { get; private set; }

  public DateTime From { get; private set; }
  public DateTime To { get; private set; }
  public TimeSpan Duration { [DebuggerStepThrought] get { return From - To; } }

  public static DateTimeInterval Create(DateTime item1, DateTime item2) {
    /* создание валидного интервала от минимального к максимальному, если в кторе проверка */
  }

  // Метод Parse в противовес ToString

  override // всего что есть от Object + реализация интерфейсов + операторы == и !=

  // операторы сложения-вычитания с TimeSpan и соответствующие методы Add/Substruct
}

Ну вот например. Обратил бы внимание, что выбран value type, что он неизменяем, что реализованы "стандартные" интерфейсы, которые в праве ожидать от такого типа любой программист (знающий о них). Не забыли о сериализации — нам ни капельки не cложно, а вот забудь мы — пользоватли нас помянут не раз злым словом. Подсобили отладчику. Завели Empty — весьма полезная весчь. А IComparable изобразить смогли бы? А как и почему?

С этим типом будет удобно работать в любой логике, котоая на отрезки-интервалы завязана. Да, тут будет чего-то не хватать, если у ваших интервалов какая-то специфика. Но всё минимально-необходимое есть и оно такое, как будет ожидать любой программист, знакомый хоть немного с платформой. Учитывая наличие методов-расширений — делай чот хочешь.

Всё это, мне кажется, должно быть на уровне подсознания. Тут ничегошеньки страшного нет. Всё, что мне не понравится или вызовет вопросы — я обязательно спрошу. Забыть чего-то нельзя. Набирать текст оказалось дольше чем рассказывать на самом деле. Где тут переусложнизм? где тут что не ясного? Я ни чудес, ни догадывания того, чего я загадал не ждал. А получил то что хотел. Этот тип не есть белая ворона среди других примитивных типов. А класс с двумя паблик полями, что показывали выше, будет таким уродцем. Если бы в нём заменить поля на автосвойства он ещё подошёл бы как DTO, но я не это просил.

Ну хотите открытые интервалы? ну делайте свойства nullable или скажите, что для таких вещей лучше другой тип написать. Методы а-ля Intersect/Intersects и т.п. (а какие сами могли бы придумать?) не обязательно тут иметь, их можно сделать extension-ами. Ну захотелось бы мне, попросил бы Intersects изобразить. Хотите вместо DateTime использовать новый DateTimeoffset? Да кто ж вам запретит? Не придётся заморачиваться с каиндом. а взяли DateTime, то заморочиться хорошо бы. Дабы пользователя оградить от возможной ошибки. А как бы именно заморочились?

А что за дырки в интервалах? Вы задание внимательно прочитали? "отрезок времени между двумя датами". При чём здесь дырки? Может, ещё и бозон интервала какой-нить выдумаем? А бесконечность? Не перевирайте задание пожалуйста! я сказал две точки на оси. Ну какая бесконечность? Зачем вы переусложнизмом занимаетесь? А хотите бесконечность? Ну и тут на самом деле можно выкрутиться. Только этого я не просил. Я, как вы можете видеть, не ожидаю вообще ничего такого, о чём не сказал бы. Все эти сериализации\иммутабельности — не потому что я их придумал, а потому, что платформа на которой вы работаете располагает к этому. Посмотрите на все остальные примитивные типы и покажите мне мутабельный. Ага? У них есть всё то, что тут. Неужели не каждый опытный, взрослый программист должен с этим справиться? А не каждый ли новичёк сумеет это сделать, проситав несколько книг и официальные рекомендации?

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

_FR>Ну хотите открытые интервалы? ну делайте свойства nullable или скажите, что для таких вещей лучше другой тип написать.

nullable всё-таки не подойдёт конечно

это скорее если бесконечность нужна, так что лучше другой тип написать. В любом случае, если дата сметри 1 января 2000 — это включительно? А если период жизни 1 января 1900 — 1 января 2000 — тут тоже очевидно что всё включительно? В общем, не принципиально, если бы была важна включительность — я бы конечно сказал. А так всё что угодно подошло бы, лишь бы билось с остальным.

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

D>> Но это не отменяет необходимости знать базовые вещи.
M>Меня всегда удивляло такое безаппеляционное утверждение про необходимость знать базовые вещи.
M>Это уже начинает напоминать религию "базовых вещей".

Способность читать и писать тоже религией назовешь?

M>Я вот, например, понятия не имею, как делают сахар, шоколадки Сникерс и Водку (могу только догадываться), но, тем не менее, не испытываю проблем с их употреблением.

Плохие аналогии. Если бы ты производил сахар, то тогда тебе нужно знать, как его делать. А пользователям твоего ПО действительно ничего не нужно знать о программировании.

M>Даже, если бы и знал я _базовые вещи_, то это только бы усилило мою вселенскую печаль и не более

Меня вселенская печаль настигает, когда я вижу сравнение строк через ==, слышу о реализации метода hashCode через ГСЧ, читаю данные мониторинга за десять минут, в котором общее ожидание нитей составляет около получаса.

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

Что-то мы вообще не о том начали спорить

Давайте вот так:

Я считаю, что если мы берём человека на должность сеньора, то нам должно быть в первую очередь интересно, как он решает задачи с практически применимым выхлопом. Знание FDG/умение следовать стандартным гадлайнам привить куда проще, особенно при нормальном процессе разработки — с автоматизированными проверками при билде, тестами и design review.

Конечно, я могу быть неправ и вы ожидаете от сеньора совсем других наборов скиллов, например вам куда важнее, чтобы человек умел сам решать задачи при неизвестных вводных. Мне реально интересен ваш взгляд на то, что стоит проверять на собеседовании, а что нет. Если мои ответы выглядят как возражения ради возражений — напишите, попробую исправиться:0

На всякий случая я попробую как можно подробней изложить свою точку зрения, если она вам кажется неверной — критика приветствуется.

_FR>Не переводите тему разговора. Мои слова и ваши, на которые я отвечал (и которые вы направсно убрали из цитаты) были совсем не о том, что вы тут начали о "DateTime vs DateTimeOffset" и т.п. Если вы будете так быстро терять нить диалога и перескакивать с сути на что-то побочное,Ю то лучше и не продожать.

Ок, контекст целиком:

_FR>>>>Предметная область такая же, как им для типа DateTime нарпимер или даже Int32 То етсь _примитивный_ тип данных.
S>>>Интервалы — это не примитивный тип данных, это целый набор абстракций со своими правилами операций, логикой и холиварами [примеры холивара skippped]
_FR>>А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).
S>>Более чем применимо. Только холиварить неинтересно. Всё уже есть из коробки [примеры аналогичных холиваров skippped] никакой практической пользы не принесёт. Но даже при наличии стандартной реализации иногда приходится пилить велосипеды [пример, когда стандартного примитива недостаточно и приходится пилить свой skipped]

Не, серьёзно, где я перевожу тему?

_FR>То, что нужно сказано в самом начале

А придираться типа "купи слоника", то есть до бесконечности выяснять что-то, умеет любой ребёнок.
Ну блиин... здравую логику никто не отменял. Зачем нам сеньор, который просит построчной спецификации? Ещё раз, речь с самого начала шла про то, что если задание допускает несколько принципиально разных толкований, то человек с опытом не должен бросаться на баррикады и пилить код так, как он видит. Для начала неплохо бы уточнить в какую именно сторону бросаться

Это уточнение займёт максимум минут пять-семь, сэкономит гораздо больше.

Если человек в ответ на "что конкретно вам нужно?" получает "это ж очевидно — примитив уровня datetime", то он и сделает сфероконя так как его понимает. Раз уж передаёте человеку ответственность за кусок кода, так убедитесь, что он понял задачу так, как её видите вы.

_FR>Я знаю. Ну и что. То же самое можно сказать про DateTime. ... Те же яйца есть и с типом DateTime — "несколько наборов сценариев". Однако тип существует.
Угу, и раз он написан, то уточнять как его написать — несколько бессмысленно, не находите?

У нас с вами другая ситуация: вы просите "напиши класс для работы с числами с запятой", а на вопрос "какие граничные условия?" отвечаете "а посмотри как в Int32 всё организовано". По сути человеку отталкиваться не отчего, вне зависимости от того, что он напишет — float/decimal или BigRational — он всё равно может оказаться неправ.

Аналогично — с DateTime. Если его писать с 0, то на выходе может получиться "стандартный" DateTime или DateTimeOffset или классы из Joda. Но нам скорее всего была нужна какая-то конкретная реализация. Зачем просить "сделай как знаешь", если результатом с определённой долей вероятности будет нельзя пользоваться?

_FR>Надоело мне тут ерундой заниматься, пытаясь объяснить самые простые вещи. Мне было интересно-то всего выяснить всего ничего:
Блин! Это не

элементарный, простейший, практически примитивный тип данных самого "широкого профиля" (как будто он будет добавлен в mscorlib на ровне с Int32, String, DateTime и т.п.). Например, тип данных, который представляет из себя отрезок времени между двумя датами (двумя точками на временной оси)

,
это "заглушка" для представления информации о промежутке времени. Да, она классно написана, не имеет косяков в дизайне, но она абсолютно непригодна для работы с промежутками времени. Последнее требует наличия операций, минимум — пересечение, объединение, получение дополнения интервалов. А поскольку арифметика должна быть замкнутой, то результатом всех трёх вышеперечисленных операций тоже должны быть промежутки.

Например, только одна операция "получить дополнение интервала [0, 10]" (числа/даты — здесь не так уж и важно) — это сразу и введение типов границ (открытая/закрытая), и +/- бесконечность, и составных интервалов. Иначе результат — { (-∞,0), (10, +∞) } — не отобразить никак. Без дополнения у вас отпадает целый класс операций — например, исключение одного интервала из другого. А с тем заделом, что пришлось ввести для операции дополнения практически нахаляву становится доступен целый ряд весьма интересных операций — например, получить все пересечения в некотором наборе интервалов. Это нужно, когда у вас есть несколько независимых наборов хроникальных записей и вы хотите что-то посчитать на каждый из отрезков времени.

Самый простой пример: у человека оклад с 1 по 10е — 100 рублей, с 10 по 31е — 200. Надбавка — 1 по 15е — 10%, с 20 по 31е — 5%. Как насчёт быстро посчитать какие суммы следует выдавать в течение всего месяца?

Вот это сценарий для типа "широкого профиля", который может быть включён в стандартную библиотеку для платформы. Если ограничиться заглушкой, то она будет использована только для случая когда надо передать куда-нибудь уже вычисленный промежуток. Для дальнейших вычислений пользователям всё равно придётся лепить свои костыли. И зачем нужен такой тип данных?

Синдром Not Invented Here. Писать свой интервал дат — это пустая трата денег. В С# отличные средства работы с датами, если не хватает — полно третьих библиотек. Сначала Дату свою напишем, потом свой XML парсер, потом свою библиотеку шаблонов. Вот например mail.ru свою базу данных ключ/значение написали — пусть плохо документированная, пусть отстала от того-же редиса по функционалу и кучеству — но мы же ее сами написали и так любим!

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

_FR>>Не переводите тему разговора. Мои слова и ваши, на которые я отвечал (и которые вы направсно убрали из цитаты) были совсем не о том, что вы тут начали о "DateTime vs DateTimeOffset" и т.п. Если вы будете так быстро терять нить диалога и перескакивать с сути на что-то побочное,Ю то лучше и не продожать.
S>

S>Ок, контекст целиком:
S>

_FR>>>>>Предметная область такая же, как им для типа DateTime нарпимер или даже Int32 То етсь _примитивный_ тип данных.
S>>>>Интервалы — это не примитивный тип данных, это целый набор абстракций со своими правилами операций, логикой и холиварами [примеры холивара skippped]
_FR>>>А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).
S>>>Более чем применимо. Только холиварить неинтересно. Всё уже есть из коробки [примеры аналогичных холиваров skippped] никакой практической пользы не принесёт. Но даже при наличии стандартной реализации иногда приходится пилить велосипеды [пример, когда стандартного примитива недостаточно и приходится пилить свой skipped]

S>Не, серьёзно, где я перевожу тему?

Ну так давайте разберём. Перечитайте пожалуйста очень внимательно процитированное. Из того, что вы сами сказали, что "Более чем применимо" вытекает, что и DateTime — "это не примитивный тип данных", ибо по вашим же словам "это целый набор абстракций со своими правилами операций, логикой и холиварами". Нет, он примитивный. Ибо очень простой. Это тот самый гвоздь, который сотни тысяч наших коллег-программистов используют достаточно регулярно. В этом суть абзаца. А не в том, о чём вы стали говорить далее: прохоливары и прочее.

Так вот любой вопрос который вы хотели задать попробуйте адресовать не мне, а себе; посмотреть, как нечто подобное сделано в другом месте — в имеющихся стандартных типах. Они, несомненно, типы "широкого профиля", но не всеоблемлющи.

S>Аналогично — с DateTime. Если его писать с 0, то на выходе может получиться "стандартный" DateTime или DateTimeOffset или классы из Joda. Но нам скорее всего была нужна какая-то конкретная реализация. Зачем просить "сделай как знаешь", если результатом с определённой долей вероятности будет нельзя пользоваться?

То, можно ли будет пользоваться, зависит только от вас. И не "как знаешь", а "как посчитаешь нужным" — это две большие разницы. Попробуйте их уловить. Вы как раз пытаетесь сделать всё, что знаете и естественно у вас много вопросов. Попробуйте сами ответить на них. Это между прочим тоже на собеседовании заметно: когда по отдельности спрашиваешь (ну как везде) про разницу между struct/class и т.п. все конечно отвечают. А когда сами что-=то делают, почему-то этими знаниями не пользуются! Поэтому я решил не специально спрашивать, а дать возможность сделать и поазать, что умеешь использовать то, что знаешь. Задача толлько для этого.

S>это "заглушка" для представления информации о промежутке времени. Да, она классно написана, не имеет косяков в дизайне, но она абсолютно непригодна для работы с промежутками времени. Последнее требует наличия операций, минимум — пересечение, объединение, получение дополнения интервалов. А поскольку арифметика должна быть замкнутой, то результатом всех трёх вышеперечисленных операций тоже должны быть промежутки.

Не понимаю что значит в данном месте "заглушка" и почему она "непригодна". Про операции я в своём посте с разбором решения написал, поищите. Я говорил о том, что ничто не мешает реализовать их как методы-расширения — в моём дизайне для их реализации доступа к каким-то приватным данным не требуется. На дизайн данного конкретного типа несомненная необходимость таких операций, как видите, не влияет. Их можно будет добавлять по мере надобности сколько хотите.

S>Например, только одна операция "получить дополнение интервала …

А кто вам сказал, что эта операция _необходима_?

Вы вот придумали задачу с дополнением, но решить не смогли. А я смог. Так как в условии о необходимости небыло ничего сказано, я _не обязан_ добавлять эту возможность. Я принял решение, что данном случае возможность получить дополнение излишне перегружает дизайн. Всё. Точно так же разработчики DateTime приняли, что представить с помощью их типа какие-то фантастические даты из запредельного будущего или наоборот шибко исторические даты из истории Древней Греции будет нельзя. И миллиардные доли секунды нельзя описать с помощью этого типа. Всё проектирование — это всегда выбор и принятие решений. Обратите внимание, я все вопросы проецирую на то, что уже сделано и к чему по условию мне нужно максимально приблизиться, и нахожу ответы там. И прежде чем придумать новый вопрос — постарайтесь сами найти для него ответ этим же путём.

S>Самый простой пример: у человека оклад с 1 по 10е — 100 рублей, с 10 по 31е — 200. Надбавка — 1 по 15е — 10%, с 20 по 31е — 5%. Как насчёт быстро посчитать какие суммы следует выдавать в течение всего месяца?
S>Вот это сценарий для типа "широкого профиля", который может быть включён в стандартную библиотеку для платформы. Если ограничиться заглушкой, то она будет использована только для случая когда надо передать куда-нибудь уже вычисленный промежуток. Для дальнейших вычислений пользователям всё равно придётся лепить свои костыли. И зачем нужен такой тип данных?

"широкий профиль" — это не "всё-всё-всё на свете". Даже универсальный ключ подходит не ко всем замкам, а только ко всем замкам определённой серии или модели. Типом Int32 тоже нельзя описать всевозможные числа, есть Int64 и даже BigInt — не один какой-то тип данных, а несколько, каждый на свой случай. Я не в первый раз вам говорю, что не требую чего-то, что покрывает все кейсы. Вы на это-то почему-то упорно внимания не обращаете и пишите так много вопросов

Ещзё раз — да, проектирование любого такого примитивного типа вызывают множество вопросов. Но проектирование _любого_ какого-то куска софта вызывает (должно вызывать, в моём понимании задачии проектирования) вопросов на порядки больше.

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

H>В С# отличные средства работы с датами,

"Ха-ха", как говорит кто-то из Симпсонов.

H>если не хватает — полно третьих библиотек. Сначала Дату свою напишем, потом свой XML парсер, потом свою библиотеку шаблонов.

Между прочим, стандартный парсер xml в дотнете не умеет одну простую весч — сообщить о позиции в тексте любого токена. Поэтому сделать другую простую весч — изменить в документе только то, что требуется, оставив в неприкосновенности всё остальное, с его помощью невозможно. И своя дата в некоторых случаях весьма и весьма полезна. Ну а уж что вы имеете в виду под библиотекой шаблонов я не понял. Но не трудитесь.

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

_FR>Ну так давайте разберём. Перечитайте пожалуйста очень внимательно процитированное. Из того, что вы сами сказали, что "Более чем применимо" вытекает, что и DateTime — "это не примитивный тип данных", ибо по вашим же словам "это целый набор абстракций со своими правилами операций, логикой и холиварами". Нет, он примитивный. Ибо очень простой. Это тот самый гвоздь, который сотни тысяч наших коллег-программистов используют достаточно регулярно. В этом суть абзаца. А не в том, о чём вы стали говорить далее: прохоливары и прочее.

Ок, значит я неправильно вас понял — речь шла не о внутреннем устройстве (которое как раз не примитивное), а о том что этот тип — intrictic, т.е. один из базовых типов, так?

Тогда да, я мягко говоря промахнулся с возражениями

_FR>То, можно ли будет пользоваться, зависит только от вас. И не "как знаешь", а "как посчитаешь нужным" — это две большие разницы. ... Это между прочим тоже на собеседовании заметно: когда по отдельности спрашиваешь (ну как везде) про разницу между struct/class и т.п. все конечно отвечают. А когда сами что-=то делают, почему-то этими знаниями не пользуются!
Ок, уловил идею.

S>>это "заглушка" для представления информации о промежутке времени. Да, она классно написана, не имеет косяков в дизайне, но она абсолютно непригодна для работы с промежутками времени. Последнее требует наличия операций, минимум — пересечение, объединение, получение дополнения интервалов. А поскольку арифметика должна быть замкнутой, то результатом всех трёх вышеперечисленных операций тоже должны быть промежутки.

_FR>Не понимаю что значит в данном месте "заглушка" и почему она "непригодна".
Я исходил из того, что нужно сделать тип данных, который позволяет производить все типовые операции с отрезками без введения дополнительных сущностей — как int достаточно для построения замкнутой арифметики для работы с целыми числами. По сути, обсуждать правильность/неправильность проектирования вашего примера — это всё равно что обсуждать внутреннее устройство decimal-а, написанного без учёта необходимости складывать-вычитать

А как только мы полезем в такие дебри, тут же окажется, что весь набросанный код летит к чертям, потому что без введения дополнительных абстракция пользоваться нашим отрезком будет неудобно.

S>>Например, только одна операция "получить дополнение интервала …
_FR>А кто вам сказал, что эта операция _необходима_?

Никто, но без неё набор операций с интервалами получается незамкнутым и в целом наборе сценариев отрезком пользоваться будет нельзя. Это всё равно, как если бы авторы int-а решили бы что унарный оператор минус и вычитание излишне перегружают дизайн.

Если нам не нужен полноценный отрезок, достаточно просто информации о начале, конце и продолжительности для удобного хранения результатов, без требования для дальнейших операций — откуда об этом узнает разработчик?

Мне кажется, что единственный способ это узнать — уточнить сценарии использования будущего класса. С вашей точки зрения (если я правильно понял) разработчик должен такие моменты решать самостоятельно, не отвлекая коллег.

Если так — в принципе можно закругляться, т.к. аргументы у меня закончились

Спасибо, было приятно поспорить

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

_FR>>Во время собеседования интересно выявить у кандидата умение использовать имеющиеся знания и навыки. По-моему, то, на сколько человек умеет пользоваться тем, что знает гораздо важнее (в профессиональном плане и долгосрочной перспективе) …широты, так сказать, знаний, которые "лежат без дела" (или используются не по назначению, что суть одно и то же). Позиция, конечно, спорная (велкам).

Y>Пинаю. Ужасно.
Y>Проблема в целеполагании. Совершенно непонятно, что вы желаете получить.

Как так? Ну например приведите пару разных вариантов, на ваш взгляд, которые я желаю получить?

Y>Что должно быть на выходе от кандидата (ну кроме холивара на счёт интервалов, представления дат и т.д.) и что должно быть на выходе от выполнения теста (какие качества этот тест проверяет).

То, какие качества проверяет совсем не важно. Прошу написать простую структурку данных. Когда например просят сортировку написать, то проверяют вовсе не то, что она в принципе сортирует (это как бы само=собой подразумевается и очевидно).

Y>В итоге имеем "угадай, что я хочу а я угадаю, что ты умеешь". Смысл данного действа от меня ускользает.

Никаких угадаек не вижу. я прошу наприсать простой тип данных. Какая разница на что я буду смотреть?

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

Y>>Пинаю. Ужасно.
Y>>Проблема в целеполагании. Совершенно непонятно, что вы желаете получить.
_FR>Как так? Ну например приведите пару разных вариантов, на ваш взгляд, которые я желаю получить?

Я в тупике. Отвечая на фразу "совершенно непонятно, что вы желаете получить" вы предлагаете мне предложить пару вариантов? Вы не могли-бы пояснить свой ход мысли?

Y>>Что должно быть на выходе от кандидата (ну кроме холивара на счёт интервалов, представления дат и т.д.) и что должно быть на выходе от выполнения теста (какие качества этот тест проверяет).
_FR>То, какие качества проверяет совсем не важно.

То-есть тест нужен не для проверки кандидата. Ок. А зачем он нужен и для чего вы тогда этот тест им даёте?

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

Y>>>Пинаю. Ужасно.
Y>>>Проблема в целеполагании. Совершенно непонятно, что вы желаете получить.
_FR>>Как так? Ну например приведите пару разных вариантов, на ваш взгляд, которые я желаю получить?
Y>Я в тупике. Отвечая на фразу "совершенно непонятно, что вы желаете получить" вы предлагаете мне предложить пару вариантов? Вы не могли-бы пояснить свой ход мысли?

Ну да, а иначе как же я могу понять, что именно вам не понятно? Я могу в той же форме переадресовать ваш вопрос вам же: мне совершенно не понятно, что вам не понятно. Но толку от этого не будет, к истине нас не приблизит.

Например, когда меня просят нарисать круг, я могу сказать, что мне не понятно какой нужен круг — синий радиусом один сантиметр или зелёный с радиусом в один метр. Если не готовы ответить так, что бы вас поняли — то не стоит и начинать.

Y>>>Что должно быть на выходе от кандидата (ну кроме холивара на счёт интервалов, представления дат и т.д.) и что должно быть на выходе от выполнения теста (какие качества этот тест проверяет).
_FR>>То, какие качества проверяет совсем не важно.
Y>То-есть тест нужен не для проверки кандидата. Ок. А зачем он нужен и для чего вы тогда этот тест им даёте?

Вывод вы сделали не правильный. Это кандидату совершенно не важно, что тестом проверяется. То, зачем тест нужен мне, сказано было в стартовом сообщении.

От:	_FRED_	@ViIvanov
Дата:	04.09.12 06:17
Оценка:

	От:	namespace
	Дата:	04.09.12 07:48
	Оценка:

От:	_FRED_	@ViIvanov
Дата:	04.09.12 07:50
Оценка:

	От:	Handie
	Дата:	04.09.12 08:08
	Оценка:

От:	Donz	http://donz-ru.livejournal.com
Дата:	04.09.12 08:12
Оценка:

От:	dimaka	http://dmitry-pavlov.com
Дата:	04.09.12 08:24
Оценка:

От:	denisko	http://sdeniskos.blogspot.com/
Дата:	04.09.12 08:52
Оценка:

От:	MozgC	http://nightcoder.livejournal.com
Дата:	04.09.12 13:41
Оценка:

	От:	Трололоша
	Дата:	04.09.12 18:56
	Оценка:	+1

От:	msk78	http://miccro.livejournal.com
Дата:	05.09.12 15:05
Оценка: