Вовочка подходит к папе:
— Папа, а что такое “ВИРТУАЛЬНО“ и “РЕАЛЬНО“?
— Так, ну вот смотри! — И отец обращается к 15-тилетней дочке:
— Света, ты бы за 2000 баксов дала Эдику, сыну моего друга?
— Конечно, дала бы!
— Хорошо. — И обращаясь к жене: — Эй, Маня, ты бы моему корешу за 2000 баксов дала бы?
— Легко! Только бабки давай!!
— Хорошо. — И к тестю: — Эй, Михал Петрович, ты бы Борису Моисееву за 2000 бакинских дал бы?
— Ясный перец! Только бабки вперёд!!
— Ну вот, Вовочка: ВИРТУАЛЬНО у нас 6000 баксов, а РЕАЛЬНО — две шлюхи и один старый педераст!..
25.08.2011 15:43, Kolobrodin пишет:
> Решений много, люди умеют перестраиваться с разных способов работы. > Вопрос тогда сводится к тому, что вы ищете человека, который не смог бы > перестроиться по ваши порядки, а уже работает так, как принято в компании.
Фактически так и есть. Перестроится он или нет — это неизвестно. А вот
то, что он уже сделал известно.
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 9:30, RGB_Dart пишет:
>> Хорошими ответами на подобный вопрос являются: "спроектировал систему >> бронирования авиаперелетов", "разработал дизайн такого-то сайта", >> "улучшил производительность legacy-системы в полтора раза за счет >> изменения запросов к БД" ... V>И дальше последует еще вопросы: "Так что именно вы сделали?" "Расскажите V>дизайн этой системы бронирования ..." "Вот вам ручка, бумажка, доска"
Так ведь это же прекрасно! Можно рассказать про дизайн системы, почему сделали так или иначе, какие были проблемы, как решались. Можно рассказать, что спустя полгода пришлось там-то и там-то сильно переделывать, а вот этот вот кусок оказался супер-гибким и легко подстраивался под меняющиеся требования. Рассказать про архитектурные подходы, посудачить о кривых фреймворках, в которых пришлось дыры латать костылями...
Это всяко интересней, чем обсуждать чему равно i++ + ++i.
И то, с каким "огоньком" кандидат рассказывает о том, чем он занимался, можно понять — насколько его вообще привлекает то, что он делал на прошлом месте .
25.08.2011 17:02, RGB_Dart пишет:
> > Так ведь это же прекрасно! Можно рассказать про дизайн системы, почему > сделали так или иначе, какие были проблемы, как решались. Можно > рассказать, что спустя полгода пришлось там-то и там-то сильно > переделывать, а вот этот вот кусок оказался супер-гибким и легко > подстраивался под меняющиеся требования. Рассказать про архитектурные > подходы, посудачить о кривых фреймворках, в которых пришлось дыры латать > костылями... > Это всяко интересней, чем обсуждать чему равно i++ + ++i. > И то, с каким "огоньком" кандидат рассказывает о том, чем он занимался, > можно понять — насколько его вообще привлекает то, что он делал на > прошлом месте .
Именно. Вот посему мне и непонятно, что не нравиться Колобродину и ТС в
данном подходе.
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 17:02, RGB_Dart пишет:
>> >> Так ведь это же прекрасно! Можно рассказать про дизайн системы, почему >> сделали так или иначе, какие были проблемы, как решались. Можно >> рассказать, что спустя полгода пришлось там-то и там-то сильно >> переделывать, а вот этот вот кусок оказался супер-гибким и легко >> подстраивался под меняющиеся требования. Рассказать про архитектурные >> подходы, посудачить о кривых фреймворках, в которых пришлось дыры латать >> костылями... >> Это всяко интересней, чем обсуждать чему равно i++ + ++i. >> И то, с каким "огоньком" кандидат рассказывает о том, чем он занимался, >> можно понять — насколько его вообще привлекает то, что он делал на >> прошлом месте . V>Именно. Вот посему мне и непонятно, что не нравиться Колобродину и ТС в V>данном подходе.
=) Рассказ левому человек про дизайн системы и описание решений в другой компании.
Неоконченная мысль всегда казалась Шри Япутре слишком
25.08.2011 17:27, Kolobrodin пишет:
> > =) Рассказ левому человек про дизайн системы и описание решений в другой > компании.
Ну скажи интервьюеру, что если я тебе расскажу, то мне придется тебя
застрелить.
Как человек, который говорил no hire всегда, когда кандидан не мог внятно объяснить что именно он сделал, отвечу:
* Непонятен смысл брать человека, который не показал что умеет делать delivery, если можно взять того кто это умеет. Не просто работать над фичей/модулем X, а _сделать_ фичу/модуль X. Обычно это означает что реализована не только какая-нибудь (может быть отвороченная) логика, которой было интересно заниматься, но и пофикшены куча мелких багов и сделаны вещи, которыми, может быть, было не очень интересно заниматься. Поверьте, есть очень умные и много знающие программисты с нулевым выхлопом, которым слишком интересно _решать_ задачу, нежели _решить_ ее.
* Без понимания того что человек _сделал_ непонятно что он делал вообще: объем реализованной им функциональности, решенные им проблемы и timeframe.
* Я понимаю что не всем компаниям это нужно. Например если хорошо поставлен майкроменеджмент, спецификации очень формальны и штаты раздуты (что IMHO часто идет рука об руку), то компания обычно имеет ресурсы на то чтобы заставлять народ делать delivery нужного качества в нужном темпе. Еще в компании могут быть совсем research-like long shot проекты с первыми майлстоунами через год, которые запускаюся, на них тратятся ресурсы, потом эти проекты умирают.
Здравствуйте, RGB_Dart, Вы писали:
RGB>Поддержу комментаторов выше — это самый главный и правильный вопрос. RGB>Если человек не способен ответить — чем он занимался, значит он либо ничем не занимался, либо так и не понял — чем же он занимался, либо не умеет доносить свою мысль до собеседников. RGB>Хорошими ответами на подобный вопрос являются: "спроектировал систему бронирования авиаперелетов", "разработал дизайн такого-то сайта", "улучшил производительность legacy-системы в полтора раза за счет изменения запросов к БД" ...
Интересно, а как следует отвечать на этот вопрос, если работал в команде со 100% совместным использованием кода? То есть, вчера работал над одним модулем, сегодня переключился на совершенно иную задачу, а над вчерашним модулем работает уже другой человек. При такой организации процесса можно сказать, что сделала команда, но вопрос о том, что сделал конкретный человек бессмыслен.
Здравствуйте, Madruel, Вы писали:
M>Интересно, а как следует отвечать на этот вопрос, если работал в команде со 100% совместным использованием кода? То есть, вчера работал над одним модулем, сегодня переключился на совершенно иную задачу, а над вчерашним модулем работает уже другой человек. При такой организации процесса можно сказать, что сделала команда, но вопрос о том, что сделал конкретный человек бессмыслен.
Ну так и рассказать, в чем проблемы?
Дальше скорее всего будут уточняющие вопросы.
Этот вопрос главным образом служит базой для других вопросов.
25.08.2011 19:02, Madruel пишет:
> Интересно, а как следует отвечать на этот вопрос, если работал в команде > со 100% совместным использованием кода? То есть, вчера работал над одним > модулем, сегодня переключился на совершенно иную задачу, а над вчерашним > модулем работает уже другой человек. При такой организации процесса > можно сказать, что сделала команда, но вопрос о том, что сделал > конкретный человек бессмыслен.
При такой организации процесса работающего продукта на выходе не будет
никогда.
Здравствуйте, michael_isu, Вы писали:
_>А вот вопросы по результатам работы можно и задать. Например — есть задача скачать 100 млн. html-страниц из интернета и их каким-то образом обработать. Как это быстрее всего сделать, в какой части тут нужны потоки, а в какой не нужны, как это хранить и т.д. Вот это нормальный вопрос, из которого можно развить интересный разговор.
По результатам какой работы?
Если проект с тобой вместе делали 10 человек (если ты его делал 1 то не может быть вопросов что делал конкретно ты). И вот лично ты в том прокете исключительно проектировал БД и оптимизировал запросы к ней с учетом аххрененного количества параллельных запросов по таблицам нихреновых размеров (интервьювер же не знает как там у вас было все организовано, а — сюрприз — в разных компаниях разработка по-разному организована). И вдруг тебе бац — и предлагают сделать эффектный парсинг 100 млн страниц. Ну и остается рассказывать на РСДН каие все интервьюверы тупые, не смогли телепатически угадать правильный вопрос по проведенной работе, а почему-то стали спрашивать про проведенную работу..
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 19:02, Madruel пишет:
V>При такой организации процесса работающего продукта на выходе не будет V>никогда.
Наоборот, все делалось в срок, потому что не возникает ситуаций, когда пялишься в код с мыслью "WTF?!?", а писавший этот код человек недоступен.
Любой член команды может сказать, зачем здесь вот эта строчка, что позволяет с легкостью перераспределять разработчиков между задачами в соответствии с их важностью и срочностью (это также может происходить автоматически, без вмешательства руководства).
Разумеется, это работает только при условии постоянного эффективного обмена информацией внутри команды (что вряд ли реализуемо для больших команд).
Здравствуйте, Kolobrodin, Вы писали:
I>>Разговор в стиле "зачем нужно такое-то ключевое слово ?" или "можно ли в конструкторе сделать то-то ?" не говорит о том что человек может реально делать. Матчасть конечно тоже важна, но в без реального опыта ни о чем не говорит.
K>В резюме человек указывает, какие технологии он использовал. Почему сразу не начать предметный разговор по нужной тематике?
Для плодотворного разговора о технологиях требуется контекст, на роль которого отлично подходит описание предыдущих проектов. На примере их можно обсудить, почему использовались именно эти технологие, а не другие, что было сделано правильно, а что нет, с какими трудностями столкнулся, какие могли быть альтернативные решения и т.д.
После такого разговора хорошо видно, что из себя представляет соискатель. Толи он просто нахватался базвордов из википедии, толи он действительно понимает то, о чем написал в резюме. Становится понятно, врал ли соискатель в резюме, или нет.
Здравствуйте, Kolobrodin, Вы писали:
K>Вопрос кандидата может быть такой: K>А расскажите, какие технологии применяете вы? Какие уникальные решения были сделаны в ходе проекта? Какие плюсы и минусы? Как вы относитесь к каким-то решениям своего руководства? Это запатентованные решения? Как обходите проблемы? Ни один интервьюер на это не ответит.
Здравствуйте, ishare, Вы писали:
I>Просто какой то однобокий взгляд на проблему у тебя.
У меня мало требований, но это достаточно высокие требования. Впрочем, речь тут не обо мне.
Здравствуйте, RGB_Dart, Вы писали:
RGB>Так ведь это же прекрасно! Можно рассказать про дизайн системы, почему сделали так или иначе, какие были проблемы, как решались. Можно рассказать, что спустя полгода пришлось там-то и там-то сильно переделывать, а вот этот вот кусок оказался супер-гибким и легко подстраивался под меняющиеся требования. Рассказать про архитектурные подходы, посудачить о кривых фреймворках, в которых пришлось дыры латать костылями... RGB>Это всяко интересней, чем обсуждать чему равно i++ + ++i.
Когда вижу в коде, как ведущий (даже уже не старший) программист с "огоньком" в глазах пишет:
int arr[20];
// double y, z прилетают издалека и их разница может быть отрицательной ))
size_t x = y - z;
if (x < 0) x = 0;
return arr[x];
Или когда другой ведущий программист запрещает использовать stl в коде, утверждая, что в данной реализации он крайне нестабилен, но при этом сам втихомолку делает поиск по std::map обращаясь к элементам через оператор [].... А его подчиненным приходится писать собственные списки с элементами void*, потому что шаблоны ведущий тоже запретил...
то я начинаю думаю, что обсудить i++ + ++i гораздо правильнее, чем начинать с технологий... до них, вероятнее всего, и не дойдет.... Но именно эти ведущие будут в своих компаниях проводить собеседования.
RGB>И то, с каким "огоньком" кандидат рассказывает о том, чем он занимался, можно понять — насколько его вообще привлекает то, что он делал на прошлом месте .
От того, что человеку привлекательно то, что он делал на прошлом месте ни холодно ни жарко, особенно, если он решил сменить это место Или вы только про вчерашних студентов?
Здравствуйте, Vzhyk, Вы писали:
V>Ну скажи интервьюеру, что если я тебе расскажу, то мне придется тебя застрелить.
Я, пожалуй, воздержусь от вашего совета, тем более я его не спрашивал... Это если я правильно понял, кто кому и что должен сказать....
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, mrTwister, Вы писали:
T>Для плодотворного разговора о технологиях требуется контекст, на роль которого отлично подходит описание предыдущих проектов. На примере их можно обсудить, почему использовались именно эти технологие, а не другие, что было сделано правильно, а что нет, с какими трудностями столкнулся, какие могли быть альтернативные решения и т.д. T>После такого разговора хорошо видно, что из себя представляет соискатель. Толи он просто нахватался базвордов из википедии, толи он действительно понимает то, о чем написал в резюме. Становится понятно, врал ли соискатель в резюме, или нет.
Если технолог Кока-колы придет на собеседование в Пепси-колу, то будет ли он рассказывать, какие проблемы были у Кока-колы и как он их решил?
Или инженер BMW на собеседование в Mersedes.
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Kolobrodin, Вы писали:
K>Если технолог Кока-колы придет на собеседование в Пепси-колу, то будет ли он рассказывать, какие проблемы были у Кока-колы и как он их решил? K>Или инженер BMW на собеседование в Mersedes.
Мне, честно говоря, нет дела до технолога Кока-колы и инженера BMW.
K>* Я понимаю что не всем компаниям это нужно. Например если хорошо поставлен майкроменеджмент, спецификации очень формальны и штаты раздуты (что IMHO часто идет рука об руку), то компания обычно имеет ресурсы на то чтобы заставлять народ делать delivery нужного качества в нужном темпе.
майкроменеджмент говоришь?
Ты наверное свой инглиш импрувиш?
P.S. Кстати, а как правильно писать, инглишь или инглиш?
.
