Здравствуйте, Vzhyk, Вы писали:
V>egaron пишет: >> >> >> зы) на всех моих работах ни разу не понадобился ЮМЛ. V>И зря, примененный к месту — очень удобная и полезная вещь.
Почему бы то же самое (структуру данных) не описать сразу на С++?
(Или какой там у вас язык для разработки используется)
Зачем лишняя сущность? Я так до сих пор и не помню, что в УМЛ изначает
черный кружочек, а что светлый. Один из них означает ссылку, а другой включение,
но какой именно?
Здравствуйте, Ubivetz, Вы писали:
U>Здравствуйте, frogkiller, Вы писали:
F>>Здравствуйте, Ubivetz, Вы писали:
U>>>Собственно его ЖЖ
U>Нет, я не имею непосредственного отношения к этому собеседованию. Просто нефиг было в ЖЖ писать то, что было там написано. Если хотел с друзьями обсудить, название компании упоминать не стоило, IMHO.
Человек написал свое мнение. У нас свобода слова. А вы, своим поведением мне напоминаете какую-нибудь тетку — наркодилера из криминальных новостей, вопящую "убери камеру, BEEP!". Надо же, обидели мышку, написали в норку — написали отзыв о походе в вашу компанию.
Здравствуйте, alpha21264, Вы писали:
A>Почему бы то же самое (структуру данных) не описать сразу на С++?
Можно. Но начальству приятнее смотреть на красивые разноцветные геометрические фигурки, соединенные линиями, чем на код.
Здравствуйте, AlexFox, Вы писали:
AF>Здравствуйте, shrecher, Вы писали:
S>>Больше 1.5 лет на одном месте не работал. Я бы с таким даже разговаривать не стал.
AF>А почему так категорично? Полтора года — хороший срок для работы на одном месте. AF>Вот если бы он каждые 4-5 месяцев прыгал...
Во-певрых. Полтора года — это его самых длинный срок. А так все больше, несколько месяцев.
Во-вовторых. В возрасте 20-24, чтобы стать вырости в проффи надо отработать года четыре на одной специальности.
Здравствуйте, shrecher, Вы писали:
S>Во-вовторых. В возрасте 20-24, чтобы стать вырости в проффи надо отработать года четыре на одной специальности.
Потрясающе спорное утверждение, в разработке есть различные направления, у которых сильные и слабые стороны различаются. Если человек попробовал и более менее вник(это происходит за полгода-года), он будет , в общем случае, эффективнее и гибче, чем "проффи", который отработал в одной конторе, с одним подходом к разработке, одними корпоративными правилами(очевидно, не идеальными), одними людьми. Кстати, как говорил классик "проффи" подобен "ффлюссу".
Здравствуйте, denisko, Вы писали:
D>Здравствуйте, shrecher, Вы писали:
S>>Во-вовторых. В возрасте 20-24, чтобы стать вырости в проффи надо отработать года четыре на одной специальности. D>Потрясающе спорное утверждение, в разработке есть различные направления, у которых сильные и слабые стороны различаются. Если человек попробовал и более менее вник(это происходит за полгода-года), он будет , в общем случае, эффективнее и гибче, чем "проффи", который отработал в одной конторе, с одним подходом к разработке, одними корпоративными правилами(очевидно, не идеальными), одними людьми.
Есть "человек-лужа", т.е знает поверхносно, но широко, а есть "человек-калодец". За полтора года молодняк становится мелкой лужой. Нахватаются поверхам, кончно, для работы в аутсорсе этого достаточно. Для создания хороших продуктов нужно прожить с технологией много лет.
D>Кстати, как говорил классик "проффи" подобен "ффлюссу".
Здравствуйте, Vzhyk, Вы писали:
V>Lloyd пишет: >> >> А если человек, которого собеседовали, был на позицию C++-ника, то он >> просто не мог этого забыть. V>По ручкам, по ручкам за ромбики и не линейкой, а молотком, если в живом V>коде такое (ну кроме очень экзотических случаев, 1 из 100, может быть).
Ну это конечно жестоко -- в смсыле если работает, то пусть будет. Но при возможности лучше упрощать.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, denisko, Вы писали:
D>>Здравствуйте, shrecher, Вы писали:
S>Есть "человек-лужа", т.е знает поверхносно, но широко, а есть "человек-калодец".
Есть, кто спорит. На ряде позиций гораздо полезнее "лужа" -- например, когда необходимо сделать что-то новое или неожиданное.
У колодца есть один огромный минус -- если задача не попадает в его дырку, то он практически бесполезен. Чаще всего это проявляется в том,
что любая задача решается одним и тем же методом (зачастую -- просто идиотичным). Мамы разные нужны, мамы разные важны. Мне комфортнее работать с лужами. Иногда, на достаточно серьезных проектах. S>кто у нас нынче классик?
А.К. Толстой + еще два мужика, емнип. Это Козьма Прутков.
Здравствуйте, The Lex, Вы писали:
TL>Хочешь понять как мыслит? Задавай классические вопросы "про жирафа в холодильнике". "Про жирафа" — боян? Придумай свои, которые "как мыслит". имхо, вопросы по стандарту и "фишкам" языка-платформы-архитектуры — не самые лучшие для "понять как мыслит человек".
Если б у меня спросили про жирафа в холодильнике я бы решил что человек проводящий собеседование не компетентен в работе с людьми и как и всякий дилетант верит что сложные проблемы (подбор персонала) могут иметь простые решения (тупые вопросы)
alpha21264 пишет: > >> > зы) на всех моих работах ни разу не понадобился ЮМЛ. > V>И зря, примененный к месту — очень удобная и полезная вещь. > > Почему бы то же самое (структуру данных) не описать сразу на С++?
Ну хотя бы потому, что одна структура данных — это такая мелочь. А вот
UM язык очень удобен, когда нужно показать как различные структуры
данных связаны, наследование, аггрегация по значению или по ссылки (да
да бывают места, где это важно).
Второе, к возрасту оное не относится, работал я и 20-летними, которые
очень грамотно и код писали и применяя тот же UML могли легко и быстро
объяснить почему они так сделали или будут делать и 50-летних, которые
писали код, "аки Акым" и объяснить не могли что и почему они так сделали
(и самое главное оное практически не работало). И работал с людьми с
точностью наоборот, 20-летние — тихий ужас, 50-летние — профи и UML их
не напрягал ни на грош, они сами его юзали, потому как им так удобнее было.
А для начинающих программистов — знание и умение пользоваться UML — это
вообще необходимость, позволяет свои программистские идеи в порядок
приводить, представить визуально.
> (Или какой там у вас язык для разработки используется) > Зачем лишняя сущность? Я так до сих пор и не помню, что в УМЛ изначает > черный кружочек, а что светлый. Один из них означает ссылку, а другой > включение, > но какой именно?
Если данный момент важен, то всегда можно открыть доку, так сказать RTFM.
> > PS. сорокалетний.
Я рад за тебя. А это хорошо или плохо? Хвастаешься или жалуешься?
olegkr пишет: > > A>Почему бы то же самое (структуру данных) не описать сразу на С++? > Можно. Но начальству приятнее смотреть на красивые разноцветные > геометрические фигурки, соединенные линиями, чем на код.
А тебе самому?
Здравствуйте, olegkr, Вы писали:
O>Индусов отсеить, слава богу, просто — достаточно посмотреть на имя кандидата...
Оффтоп. Расистский. Кто научился "на глаз" разбирать где у него имя, а где — фамилия? Действительно интересно — и есть ли какая более или менее формальная методика. А то как-то полным именем постоянно старательно называть "мистер Имя1 Имя2" — вроде некошерно. Или как?
O>... а в случае непоняток на внешность во время собеседования. Можешь мне поверить, у индусов с прохождением тестов особых проблем не будет.
Вот! Вот тут начинается самая интересная проблема: что делать с людьми, "натасканными" проходить тесты — и кроме того — больше ничего — а?
Здравствуйте, SkyDance, Вы писали:
TL>>Мое мнение: да, именно _нельзя_ чтобы было "простой логикой догадаться, в каком порядке происходит инициализация объектов" — именно это _правильно_, а не "логика"... имхо логика — зло!
SD>Да и фиг с ним. Можно, нельзя, какая разница-то? Хочется понять, как МЫСЛИТ кандидат. Как он вообще ведет себя при решении задач. Даже если он в итоге вообще не ответит или ответит на вопрос неправильно — да пофигу. Он покажет то, как он мыслит.
Да, кстати: пока домой ехал — придумал как бы я "проверял кандидата на логику на примере мультинаследования". Берем кандидата, рисуем ему диаграмму наследования, ложим рядом стандарт, и просим объяснить последовательность конструирования и деконструирования, причем в идеальном варианте — ссылаясь на пункты в стандарте. Вот такая работа логики будет лично мне полезна — именно такая работа логики используется в _реальных_ проектах, когда надо по RFC-RTFM какому-нибудь реализацию сделать — причем реализовать именно то, что написано в RFC, а не то, о чем "можно было простой логикой догадаться". имхо, именно так и можно проверять на логику и именно на таких постановках задачи "смотреть как человек мыслит и мыслит ли он вообще". Лично я бы работал с такими людьми — может потому что специфика задач у меня такая "нетворческая", а может потому, что "свободного творчества свободных логиков" я уж, простите, наелся по самое нехочу.
И еще: тут ставится странная постановка вопроса — причем это _очень_ распространенная постановка вопроса в сабже "тестирование кандидата". Вы, товарищи "собесодатели", почему-то все время пытаетесь — внимание! — кандидата _изучать_! имхо, совершенно незачем строить из себя психологов и на абстрактных тестах "пытаться понять как человек мыслит дабы потом по его психологическому портрету определить его полезность и применимость" — имхо, _необходимо_ и _достачно_ именно _проверить_ как человек может решать _наши_ задачи — ну и может ли вообще. Приземленнее надо быть и конкретнее — вот в чем на мой нескромный взляд основная и очень распространенная проблема "собеседователей".
Здравствуйте, Vzhyk, Вы писали:
>> A>Почему бы то же самое (структуру данных) не описать сразу на С++? >> Можно. Но начальству приятнее смотреть на красивые разноцветные >> геометрические фигурки, соединенные линиями, чем на код. V>А тебе самому?
Из личного опыта "межобщения" лично я предпочел бы крамотно нарисованные диаграммы.
Здравствуйте, MescalitoPeyot, Вы писали:
TL>>Хочешь понять как мыслит? Задавай классические вопросы "про жирафа в холодильнике". "Про жирафа" — боян? Придумай свои, которые "как мыслит". имхо, вопросы по стандарту и "фишкам" языка-платформы-архитектуры — не самые лучшие для "понять как мыслит человек".
MP>Если б у меня спросили про жирафа в холодильнике я бы решил что человек проводящий собеседование не компетентен в работе с людьми и как и всякий дилетант верит что сложные проблемы (подбор персонала) могут иметь простые решения (тупые вопросы)
Я тебе секрет скажу: самое простое и тупое решение всякой проблемы проблемы любой сложности — самое _лучшее_!
The Lex пишет: > > > Из личного опыта "межобщения" лично я предпочел бы крамотно нарисованные > диаграммы.
Примерчик, можно. Диаграммы вообще, они такие разные.
Позаимствую, если понравиться больше, чем UML (в смысле более понятно
любому программисту будет).
Здравствуйте, Vzhyk, Вы писали:
V>А тебе самому?
А мне самому лень поддерживать UML в актуальном виде. На этапе конструирование еще как-то может пригодится... хотя нет, в коде проще, всплывают невидимые за красивыми фигурками косяки в архитектуре.
Здравствуйте, The Lex, Вы писали:
TL>Кто научился "на глаз" разбирать где у него имя, а где — фамилия?
У меня в мейлере рабочем сначала всегда идет фамилия, потом имя. Если есть сомнения — лезешь в адресбук и разрешаешь их.
Но это проблема не только индусская. У нас как-то при регистрации доменного id на нового сотрудника перепутали местами имя и фамилию, так потом все иностранчики беднягу вместо имени по фамилии звали. Видимо такие же проблемы с пониманием русских имен и фамилий.
TL>Вот! Вот тут начинается самая интересная проблема: что делать с людьми, "натасканными" проходить тесты — и кроме того — больше ничего — а?
Собеседовать. Например, спросить, а почему так, а не эдак. Сложно, конечно, но можно.
olegkr пишет: > > > V>А тебе самому? > А мне самому лень поддерживать UML в актуальном виде.
В смысле? Его за тебе другие поддерживают, как и С с плюсами впрочем.
> На этапе > конструирование еще как-то может пригодится...
Еще как.
> хотя нет, в коде проще, > всплывают невидимые за красивыми фигурками косяки в архитектуре.
Знаешь, голову еще никто не отменял.
А в коде не проще, насмотрелся я таких "кодировщиков", аж тошнит.