Задачи на интервью

[Byka]

...
Я на интервью не требую помнить каждую букву. Я требую как раз понимания. Но и общее представление предмета должно быть, или не указывай его в резюме. Например, если указал clearcase, то либо знай, что такое version tree, либо не претендуй больше чем на junior position, а то principal engineer, который никогда не задавался вопросом, кто внёс изменение и почему, меня сильно настораживает.
...

Немного робею, но все-же спрошу.

Какими-такими сокральными знаниями о "version tree" должен обладать кандидат?
Особенно в контексте ClearCase. Это что-то специальное или Вы просто бедолаг "на понт" берете?

[Epi]

Какими-такими сокральными знаниями о "version tree" должен обладать кандидат?
Особенно в контексте ClearCase. Это что-то специальное или Вы просто бедолаг "на понт" берете?

Ну, как раз в контексте ClearCase этих "сокральных" знаний дофига - так что вопрос "Что такое version tree в ClearCase" вполне нетривиальный.

[uncle_Pasha]

ClearCase самый ужасный version control ever. Никогда не укажу.

В чем же его ужасность? Не осилили?

Удачи!

[uncle_Pasha]

вопрос "Что такое version tree в ClearCase" вполне нетривиальный.

Version tree - оно и есть version tree. Какие еще могут быть разночтения? В чем нетривиальность?

Удачи!

[Byka]

Какими-такими сокральными знаниями о "version tree" должен обладать кандидат?
Особенно в контексте ClearCase. Это что-то специальное или Вы просто бедолаг "на понт" берете?

Ну, как раз в контексте ClearCase этих "сокральных" знаний дофига - так что вопрос "Что такое version tree в ClearCase" вполне нетривиальный.

Вы можете предложить Ваши варианты вопросов о "version tree", которые стоило бы задать на интервью, на позицию Старшего Программиста?

Тонкости, присущие Clear Case, могут быть предложены для вопросов на призовые баллы.

Спасибо.

[Epi]

Version tree - оно и есть version tree. Какие еще могут быть разночтения? В чем нетривиальность?

Для специалиста вашего уровня (или даже для того, кто действительно работал с ClearCase в нетривиальном проекте) - действительно, ничего сложного там нет. Но мне приходилось объяснять эти простые вещи моим коллегам (в основном, новеньким, кто до этого работал в чем-то другом).

Например, то, что деревья версий для разных элементов разные, или то, что директория тоже является элементом (со своим деревом версий!). Или как обстоит дело с merge - для нас с вами это может быть очевидно, но я бы не назвал это тривиальным.

Вы можете предложить Ваши варианты вопросов о "version tree", которые стоило бы задать на интервью, на позицию Старшего Программиста?

На senior позицию, в дополнении к вышесказанному, нужно еще рассказать про branch ownership.

[M. Ridcully]

Просто интересно - все эти вопросы про "clearcase" - это для позиции ойтишнека/admina/SCM, или всё-таки программиста?
Если второе, то звучит дико - примерно как в прошлом веке на позицию конструктора, скажем, спрашивали бы - умеете ли точить карандаши марки "Кохинор".

[uncle_Pasha]

Для специалиста вашего уровня

Удачи!

[uncle_Pasha]

Просто интересно - все эти вопросы про "clearcase" - это для позиции ойтишнека/admina/SCM, или всё-таки программиста?
Если второе, то звучит дико - примерно как в прошлом веке на позицию конструктора, скажем, спрашивали бы - умеете ли точить карандаши марки "Кохинор".

IMHO, дико - это когда кандидат на senior level позицию не понимает хотя бы основ SCM и не знает как организовать работу на большом проекте, когда одновременно приходится разрабатывать/поддерживать несколько версий или кастомизаций продукта.

Удачи!

[АццкоМото]

да ладно, любому, кто работал с ЧистымЧемоданом не составит труда накидать общих фраз о том, что дерево версий индивидуально для каждого конфигурационного элемента, коими являются и файлы и дирки; что начинает свою жизнь дерево версий из состояния сингулярности и развивается путем добавления версий и отращивания бранчей; что в конкретной конфигурации "видно" строго от 0 до 1 версии каждого элемента и что именно "видеть" определяет конфигспек.

делов на 2 минуты и всем сразу ясно, что чел действительно работал с ЧЧ. и вопросы такие к программисту более чем адекватны. если бы речь шла про CM-щика, там нужно было бы уже поднимать advanced topics, а не этот вопрос, проще которого и придумать трудно

другой вопрос, что чувак мог не сознательно врать про опыт с ЧЧ, просто был какой-нибудь проект, где большая монструозная система жила в ЧЧ, а его маленький компонентик - в чем-то более легком типа SVN/git, и все, что ему нужно было знать - как найти нужный конфигспек и утащить правильный срез очередного бейзлайна, совершенно не задумываясь, как же работает шайтан-машина

[АццкоМото]

Просто интересно - все эти вопросы про "clearcase" - это для позиции ойтишнека/admina/SCM, или всё-таки программиста?
Если второе, то звучит дико - примерно как в прошлом веке на позицию конструктора, скажем, спрашивали бы - умеете ли точить карандаши марки "Кохинор".

IMHO, дико - это когда кандидат на senior level позицию не понимает хотя бы основ SCM и не знает как организовать работу на большом проекте, когда одновременно приходится разрабатывать/поддерживать несколько версий или кастомизаций продукта.

Удачи!

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

[Medium-rare]

ClearCase самый ужасный version control ever. Никогда не укажу.

В чем же его ужасность? Не осилили?

Удачи!

Сравнивая с Perforce, для примера. В тот период знакомства с CC мне было некогда, в основном писал код, чекинил каким-то скриптом. Но все нестандартные ситуации требовали на порядок-два больше времени на разрешение плюс хождение по клир-кейс-гуру, дольше, чем с любым другим version control. Не интуитевен CC, как инструмент. Не говорю, что он маломощный или что-то ещё. Perforce по применяемости + мощи наилучший, как пишут, и говорят, и сам вижу, у большинства корпоративных монстрофф уровня Гугл и MS, у некоторых подрихтован и называется местным названием, что не меняет сути.

И вам удачи!

[uncle_Pasha]

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

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

Удачи!

[uncle_Pasha]

В тот период знакомства с CC мне было некогда, в основном писал код, чекинил каким-то скриптом. Но все нестандартные ситуации требовали на порядок-два больше времени на разрешение плюс хождение по клир-кейс-гуру, дольше, чем с любым другим version control. Не интуитевен CC, как инструмент. Не говорю, что он маломощный или что-то ещё. Perforce по применяемости + мощи наилучший, как пишут, и говорят, и сам вижу, у большинства корпоративных монстрофф уровня Гугл и MS, у некоторых подрихтован и называется местным названием, что не меняет сути.

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

При этом я понимаю, что 80% народа машина не нужна в принципе. Трехколесного велосипеда вполне достаточно.

Удачи!

[Medium-rare]

Удачи uncle_Pasha, я вам пытался сказать, что огромнейшие проекты успешно поддерживаются Perforce с гораздо меньшей головной болью. Это реальность. Наблюдаемая каждый день. P4, как машина, сильно практичнее, ну не нужна, кроме фанов, никому ручная коробка передач. Автомат отлично работает.

[АццкоМото]

Возможность организации командной работы - это уже бесплатный бенефит беспроблемной поддержки ветвлений и слияний.

Да нет, это как раз то, для чего ЧЧ и создавался. А также то, что используется в 99% проектов под ЧЧ, независимо от дополнительный вводных типа поддержки нескольких версий
Впрочем, не суть. Он и упомянут-то был вскользь

[Poryadok]

Охохонюшки.

В Clearcase я про вершон три пытался задавать наводящие вопросы, и когда это не помогло - спросил прямо, что это. Человек не знал. Я спросил, как он узнавал, что поменялось в софте. Он не мог сказать. При том, что написал clearcase в своём резюме.

Про BSTR. Читаю ваши коменты и плачу. Прямо как в анекдоте. Преподаватель спрашивает на экзамене "Ну, хотя бы - какого цвета учебник?". Студенты: "Во валит, гад!"

Вы-то сами, наверное, на интервью по С# или Джаве спрашиваете, чем String от StringBuilder-а или StringBuffer-а? Ну вот, а мне нужен COM. Мне нужно, чтобы человек знал про BSTR ну хоть что-нибудь. Человек, который не только не знает ничего, но и пытается меня (и себя?) убедить, что знает, мне не подойдёт.

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

[olis]

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

[АццкоМото]

Все что мне было нужно знать - что нажать чтобы зачекинить код.

Дайте-ка я угадаю. А когфигспек у вас был вот такой, да?

Code: Select all

element * CHECKEDOUT
element * /main/LATEST

[Poryadok]

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

Ну вот я не понимаю. Как можно два года работать и только чекинить код? Ну, только если сугубо в одиночку писать. А вот если тебе говорят - в билде xххх фича работает, в билде yyyy - нет. Лезешь в код, и видишь, что оно в принципе работать не может, и вообще непонятно, что тут имелось в виду. Пофиксить нужно немедленно. Переписывать этот кусок - пол года, да ещё соседние системы непонятно как отреагируют. Вот для этого вершон контрол и нужен. Чтобы посмотреть - изменил ли это кто-то сознательно, или мержбэк из какого-то стрима криво лёг. Если кто-то изменил, то когда и зачем. Ищешь изменение, ищешь соответствующий баг трэкинг айтем, читаешь. Пишешь изменившему (у которого сейчас ночь в Европе), CC: его лиду, спрашиваешь в чём была проблема, что он имел в виду, и нет ли дизайн документа, и ждёшь ответа. И так - снова и снова, каждый день. Так выглядит моя девелоперская жизнь. Если бы я не умел искать кто внёс изменения и зачем, мне бы оставалось сесть и плакать.

[olis]

Все что мне было нужно знать - что нажать чтобы зачекинить код.

Дайте-ка я угадаю. А когфигспек у вас был вот такой, да?

Code: Select all

element * CHECKEDOUT
element * /main/LATEST

А я помню?

[olis]

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

Ну вот я не понимаю. Как можно два года работать и только чекинить код? Ну, только если сугубо в одиночку писать. А вот если тебе говорят - в билде xххх фича работает, в билде yyyy - нет. Лезешь в код, и видишь, что оно в принципе работать не может, и вообще непонятно, что тут имелось в виду. Пофиксить нужно немедленно. Переписывать этот кусок - пол года, да ещё соседние системы непонятно как отреагируют. Вот для этого вершон контрол и нужен. Чтобы посмотреть - изменил ли это кто-то сознательно, или мержбэк из какого-то стрима криво лёг. Если кто-то изменил, то когда и зачем. Ищешь изменение, ищешь соответствующий баг трэкинг айтем, читаешь. Пишешь изменившему (у которого сейчас ночь в Европе), CC: его лиду, спрашиваешь в чём была проблема, что он имел в виду, и нет ли дизайн документа, и ждёшь ответа. И так - снова и снова, каждый день. Так выглядит моя девелоперская жизнь. Если бы я не умел искать кто внёс изменения и зачем, мне бы оставалось сесть и плакать.

Для этого СlearCase ИМХО плохо приспособлен. Вот в P4 да, вся история изменений как на ладони. Когда, кем, какие файлы, что именно менялось в каждом файле. И мерджить код кстати тоже просто.

[АццкоМото]

Все что мне было нужно знать - что нажать чтобы зачекинить код.

Дайте-ка я угадаю. А когфигспек у вас был вот такой, да?

Code: Select all

element * CHECKEDOUT
element * /main/LATEST

А я помню?

Это как раз лишнее доказательство, что конфигспек был или таким, или похожим. Это такой специальный шайтан-конфигспек, который превращает прекрасный ClearCase унылый SVN. Так что ничего удивительного

[Gross]

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

[avitya]

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

Ну вот я не понимаю. Как можно два года работать и только чекинить код? Ну, только если сугубо в одиночку писать. А вот если тебе говорят - в билде xххх фича работает, в билде yyyy - нет. Лезешь в код, и видишь, что оно в принципе работать не может, и вообще непонятно, что тут имелось в виду. Пофиксить нужно немедленно. Переписывать этот кусок - пол года, да ещё соседние системы непонятно как отреагируют. Вот для этого вершон контрол и нужен. Чтобы посмотреть - изменил ли это кто-то сознательно, или мержбэк из какого-то стрима криво лёг. Если кто-то изменил, то когда и зачем. Ищешь изменение, ищешь соответствующий баг трэкинг айтем, читаешь. Пишешь изменившему (у которого сейчас ночь в Европе), CC: его лиду, спрашиваешь в чём была проблема, что он имел в виду, и нет ли дизайн документа, и ждёшь ответа. И так - снова и снова, каждый день. Так выглядит моя девелоперская жизнь. Если бы я не умел искать кто внёс изменения и зачем, мне бы оставалось сесть и плакать.

Ага, а прикиньте в гите встроена фича для двоичного поиска между чекинами для поиска исходника багов, небось такой в КК нету