А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил. Так вот теперь я эту задачу сам на собеседованиях спрашиваю. И результат меня удивил, так что я решил с вами поделиться и обсудить. Дело в том, что люди которые буквально только из универа и не знают что такое GC, что такое план запроса, что такое deadlock, не знают что в C# есть свойства (! тут я со стула чуть не упал, т.к. парень с опытом работы на C#). Так вот этот парень решает эту задачу. Но матерые зубры, которые и особенности Oracle и основные проблемы работы с TSQL и паттерны, и DI и CI и Kubernetess — просто красавец, что не спросишь реально знает, грамотно отвечает и Service Discovery и что лучше, что хуже. Видно что работал с технологиями. Даешь задачу — N*N. Зато просто, говорит он... Ну прям как я
Так вот два четких кластера. Зеленые новички — легко. Зубры N*N. Да, бывают в этой статистике вбросы, но я бы сказал так.
Что скажите?
Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
Здравствуйте, Эйнсток Файр, Вы писали:
G>> нет мотивации решать и даже напрягаться из-за нудной фигни...
ЭФ>RussianFellow подобный зубр. Ему лень напрягаться из-за всякой фигни, если можно просто спросить на rsdn.
ЭФ>Ведь реально у него много опыта и широкий кругозор.
Нет, опыт должен быть релевантным. Т.е. при разработке enterprise приложений есть определенные паттерны. Буквально это штук 40 книг достаточно прочитать. Так вот у RussianFellow опыт другой. Ну вот давайте спросим его без гугла он тестирует состояние или поведение в своих проектах? RussianFellow вы здесь?
Здравствуйте, Gattaka, Вы писали:
G>Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
У меня есть другое объяснение. Специализация-с!
Ты работаешь с конкретными технологиями, фреймворками, а с алгоритмическими задачами в последний раз сталкивался, в лучшем случае, в школе.
А в Яндексе хотят именно алгоритмиста, а вопросы по фреймворкам решаются с полпинка на SO.
И то, и другое это опыт. Я вот напрягаться не буду и забью болт, если с меня спросят что-то экзотическое из жизни СУБД (хотя найдется что рассказать), а для тебя это шибко важное.
_____________________
С уважением,
Stanislav V. Zudin
Хз, может в твоём мире гугл другой. Все эти особенности оракл как раз таки на первой строчке гугла и выдаются, а вот алгоритмы фиг ты найдёшь на какой строчке, только прорешивать тысячи олимпиадных задачек, чтобы они в подкорку запали. Другой вопрос, что в работе оно мне лично ни разу не пригождалось за 10 лет, но я и не в яндексе работаю.
простота — сама по себе ценна
не всегда можно себе её позволить, увы
я когда добавляю в код сложный алгоритм чувствую себя довольной свиньей
процесс приятен, но работодатель за это поплатится, когда надо будет это править
Здравствуйте, Gattaka, Вы писали:
G>Так вот два четких кластера. Зеленые новички — легко. Зубры N*N. Да, бывают в этой статистике вбросы, но я бы сказал так. G>Что скажите?
В Яндексе зелень отбирают, чтобы работали не за деньги, а за то, что им там позволили работать
Здравствуйте, vsb, Вы писали:
vsb>Хз, может в твоём мире гугл другой. Все эти особенности оракл как раз таки на первой строчке гугла и выдаются, а вот алгоритмы фиг ты найдёшь на какой строчке,
Те алгоритмы, которые спрашивают, они либо тоже на первой строчке, либо в реальной жизни не встречаются и не применяются.
За исключением прикладных алгоритмов, конечно, но они специфичны для предметной области.
Здравствуйте, Gattaka, Вы писали:
G>Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
Просто, чтобы что-то получалось, этим надо заниматься. В разработке очень редко приходится решать какие-то серьёзные алгоритмические задачки. Достаточно писать алгоритм со сложность N * log N вместо квадрата. Поэтому такой навык не развивается у большинства и знания постепенно забываются. Исключение это преподы и интервьюэры.
Без дополнительных подробностей тут неясно, где засада.
В самом общем случае скажу, что инженер-программист и математик-алгоритмист — это две разных специализации, ну примерно как врач-стоматолог и врач-кардиолог (хотя и у того, и у другого в дипломе написано "лечебное дело"). Ты же не пойдешь с больным зубом к кардиологу, правда?
Мне приходилось сталкиваться и с инженерами, и с алгоритмистами. Вот инжене(г)р действительно может затупить на алгоритме, написать со сложностью N^2 вместо N*log N, но зато организует код проекта с четким разбиением на подсистемы с формализованными интерфейсами, код будет простой и ясный, так что даже junior сможет его поддерживать и развивать. Наоборот, алгоритмист может придумать эффективный алгоритм, зато на его код смотреть без слез невозможно — "а что такого, у меня же все работает!", и этот код в дальнейшем отправляется прямиком в Корзину.
Нет?
Так что наверное надо начинать с того, какие скиллы более важны.....
Здравствуйте, Vlad_SP, Вы писали:
V_S>ну примерно как врач-стоматолог и врач-кардиолог (хотя и у того, и у другого в дипломе написано "лечебное дело").
А вот и нет, у всех врачей написано "лечебное дело", а у стоматолога — "стоматология"
V_S>Наоборот, алгоритмист может придумать эффективный алгоритм, зато на его код смотреть без слез невозможно — "а что такого, у меня же все работает!", и этот код в дальнейшем отправляется прямиком в Корзину.
Подтверждаю. Был случай — математик(весьма продвинутый) писал код, причем архитектура с виду правильная, но слишком сложно и все тормозило жутко.
Очень удивился, что я смог разобраться и найти узкое место тк он сам несколько месяцев над этим бился.
Ну, "архитектура с виду правильная, но слишком сложно и все тормозило жутко" — это еще полбеды. А то и вообще не беда.
Беда — это код математика с функциями по полторы-две тысячи строк, юзающими к тому же кучу глобальных переменных с очень информативными именами типа i, ii, iii, k, kk, kkk.... "ну а что, работает же!"
Здравствуйте, Gattaka, Вы писали:
G>А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил.
Тут есть какой-то психологический эффект. Не иначе. Когда у тебя за плечами годы в разработке систем без преувеличения высокой сложности, годы ковыряния в таких же, разработанных другими, с целью их дальнейшего развития или взлома, сотни тысяч строк кода на самых разных ЯП, и прочее всё такое, то те задачки, которые на собеседованиях предлагают, у тебя просто нет ни малейшего желания решать. Мозг отазывается уделять этим задачкам хоть каплю внимания где-то на уровне подсознания. Ты знаешь где-то на том же уровне, что здесь не нужно париться и что здесь нужно форсить решение с как можно меньшими временными и энергетическими затратами.
Здравствуйте, Gattaka, Вы писали:
G>Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
Значит тебе нечего делать в яндексе. Это не значит что ты "не тянешь", просто им нужны специалисты другого профиля, вот и все.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Беда — это код математика с функциями по полторы-две тысячи строк, юзающими к тому же кучу глобальных переменных с очень информативными именами типа i, ii, iii, k, kk, kkk.... "ну а что, работает же!"
Не, я обычно использую аргументацию "ну, перепиши!". Даже могу поспособствовать выделению бюджета. Но программисты всё равно взвывают.
