Часто так бывает, что насобеседованиях задают вопросы вроде: "Вот, есть существующая система. У нее есть Модуль1-ГУИ и Модуль2-ДЛЛ. Что добавить в схему чтобы достичь того-то и того-то?". Вопрос только для примера...
Интересует — собраны ли подобные вопросы(или же примеры архитектур) в одном месте, чтобы можно было поднатаскаться в идеях? Есстественно, что с объяснениями — толку-то от одних вопросов.
ПС: Банду не предлагать — читал, но уж больно теоретическая — без опыта проектирования больших систем трудно сразу прикинуть что лучше использовать.
Здравствуйте, twonderer, Вы писали:
T>Интересует — собраны ли подобные вопросы(или же примеры архитектур) в одном месте, чтобы можно было поднатаскаться в идеях? Есстественно, что с объяснениями — толку-то от одних вопросов.
паттерны проектирования хотя уверен, наверняка существуют, как говорится был бы спрос
T>Интересует — собраны ли подобные вопросы(или же примеры архитектур) в одном месте, чтобы можно было поднатаскаться в идеях? Есстественно, что с объяснениями — толку-то от одних вопросов.
Здравствуйте, twonderer, Вы писали:
T>Часто так бывает, что насобеседованиях задают вопросы вроде: "Вот, есть существующая система. У нее есть Модуль1-ГУИ и Модуль2-ДЛЛ. Что добавить в схему чтобы достичь того-то и того-то?". Вопрос только для примера...
Интереснее спрашивать какие-то архитектурные задачки на реальном материале.
Мы, например, спрашивали такую. В линуксе некоторые утилиты (например, grep, ls) умеют подсвечивать разными цветами свою выдачу. Делают они это с помощью ESC-последовательностей, которые понимает терминал. Однако через пайп это, очевидно, не работает: grep не знает, понимает ли программа на другом конце пайпа терминальные ESC-последовательности, поэтому на всякий случай их отключает. Поэтому grep | sort будет черно-белым, а не цветным.
Вопрос, что можно было бы изменить в архитектуре системы, чтобы grep | sort работал в цвете, и при этом сохранилась совместимость со старыми программами, которые могут этого не понимать?
Тут, понятно, единственного правильного ответа не существует, но интересно послушать, как человек рассуждает и насколько широко охватывает возможный спектр возникающих проблем.
Вопрос, конечно, очень UNIX-специфический, но для венды наверняка можно придумать аналогичные вопросы.
А зачем далеко ходить, если этих примеров можно у себя нарыть массу. Всегда можно спросить: "Как бы вы решили <подставить интересующую вас в настоящий момент задачу или мнение насчет какого-то решения>"? И вопрос конкретный, а не абстрактный (а это практически всегда чувствуется) и разговор получается живым и интересным. И польза есть, и удовлетворение, и человек (субъективно) лучше раскрывается.
K>А зачем далеко ходить, если этих примеров можно у себя нарыть массу. Всегда можно спросить: "Как бы вы решили <подставить интересующую вас в настоящий момент задачу или мнение насчет какого-то решения>"? И вопрос конкретный, а не абстрактный (а это практически всегда чувствуется) и разговор получается живым и интересным. И польза есть, и удовлетворение, и человек (субъективно) лучше раскрывается.
Ага, типа надо тебе какую-то задачу посложнее да побыстрее решить — объявляешь вакансию на стотыщбаксов, приходит профи, ты ему а как вот решить <интересующая тебя в данный момент задача> ? А он тебе — так, так и так. Ты — "ага, спасибо, мы вам перезвоним" и с довольной ухмылкой бежишь кодить это всё...
Здравствуйте, x64, Вы писали:
K>>А зачем далеко ходить, если этих примеров можно у себя нарыть массу. Всегда можно спросить: "Как бы вы решили <подставить интересующую вас в настоящий момент задачу или мнение насчет какого-то решения>"? И вопрос конкретный, а не абстрактный (а это практически всегда чувствуется) и разговор получается живым и интересным. И польза есть, и удовлетворение, и человек (субъективно) лучше раскрывается.
x64>Ага, типа надо тебе какую-то задачу посложнее да побыстрее решить — объявляешь вакансию на стотыщбаксов, приходит профи, ты ему а как вот решить <интересующая тебя в данный момент задача> ? А он тебе — так, так и так. Ты — "ага, спасибо, мы вам перезвоним" и с довольной ухмылкой бежишь кодить это всё...
x64>
Даже с вашей позиции мой способ выглядит практичнее нежели решение абстрактных примеров.
1) Если у вас нес своего архитекта, не стоит и пытаться тестировать его проф. знания глубоко, все равно оценить не сможете.
2) Архитектура понятие растяжимое. Есть микроуровень, есть уровень подсистем, есть уровень систем. На каждом из них все очень сильно разнится.
3) Если на собеседовании задаются задачки типа "спроектируй мне такое то приложение", то, с большой долей вероятности, в архитектурном плане у собеседующего все печально. Потому что даже для примерного решения той или иной задачки необходимо знать массу факторов — существующий код, бюджет и сроки проекта, средство разработки, размер и квалификацию команды, требования к устойчивости и безглючности решения и т.п. Все эти факторы непосредственно влияют на дизайн, и никакого верного дизайна вне этих факторов просто не существует.
Так как же все таки собеседовать архитектов? ИМХО, ничего лучше просто беседы с кандитатом на тему проектирования с наблюдением за ходом его мысли вряд ли что то есть.
Хотя, можно таки задать задачку в описанном стиле. И если кандидат сразу бросится что то там проектировать, вместо того чтобы начать задавать вопросы, собеседование сразу сворачивать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1137 on Windows Vista 6.0.6001.65536>>