Amazon

[Сабина]

Я на фуллтайм никогда не устраивалась в кали, только в чикаго. Алгоритмы на фуллтайм у меня никогда не спрашивали. Конечно, начни я счас на фуллтайм в амазон тот же апплаится, там же будут все спрашивать. Начнет ХР, разговорами о жизни, потом по телефону, потом лично. Не знаю как в Калифорнии но в Чикаго на каждую компанию надо потратить на телефонные разговоры часа три, потом как минимум один раз в офисе еще часа два. На контракте рекрутеры только поо деньги разговаривают и могут минут 5 про проект поговорить, потом по телефону собеседуют. Никогда не было больше 2 х часов.

Я даже и не знала что вопросы на фултайм и контракт как-то отличаются, с меня везде спрашивали фандементалс по полной. Но может сейчас и правда такой дефицит джавистов что берут всех подряд? Я как нашла в апреле прошлого года и не дергалась, но вижу что рекрутеры донимают не по-децки. Неужели и правда дожили до времен когда можно просто ля-ля про прошлые проэкты - и вперед ? Хорошо бы было . Мне интересует разговор с тимом, непосредственно с технарями, HR всякие и рекрутеры - это всегда легко. Что забавно меня тоже после телефонного взяли га две хорошие работы из чего я делаю вывод что in person у меня не очень хорошо получается проходить

[Krys-Krys]

Ля-ля про пшлые проекты? Ну так так и надо собеседоватб народ. Чтобы понять что он уже знает по делу, что уже делал раньше и какой поимел опыт из этого чтобы оценить, сможет ли он делать то что ожидается на новой работе. Как при этом поможет поиск по бинарному дереву? У меня за много проектов такие задачи стояли не часто, скажем так. Задачи тривиальней. Вспоминая что делала на текущем проекте - улучшали поиск, но для этого мы готовый фреймворк использовали и прикручивали, много веб сервисов было, функционала для разных пользователей в кастомер саппорте, улучшение профайла для покупателей чтоб они могли больше информации о себе слить ненавязчиво и им потом предложили чего по делу. Такую работу тоже надо кому- то делать, и где тут деревья поисковые ?

[Сабина]

Ля-ля про пшлые проекты? Ну так так и надо собеседоватб народ. Чтобы понять что он уже знает по делу, что уже делал раньше и какой поимел опыт из этого чтобы оценить, сможет ли он делать то что ожидается на новой работе. Как при этом поможет поиск по бинарному дереву? У меня за много проектов такие задачи стояли не часто, скажем так. Задачи тривиальней. Вспоминая что делала на текущем проекте - улучшали поиск, но для этого мы готовый фреймворк использовали и прикручивали, много веб сервисов было, функционала для разных пользователей в кастомер саппорте, улучшение профайла для покупателей чтоб они могли больше информации о себе слить ненавязчиво и им потом предложили чего по делу. Такую работу тоже надо кому- то делать, и где тут деревья поисковые ?

Я поняла вашу точку зрения и даже где-то разделяю. Просто говорю что в жизни всегда спрашивают много по теории или как минимум очень многие аспекты основной технологии или около нее. Это не меня одну, всех кого я знаю

[Krys-Krys]

Ля-ля про пшлые проекты? Ну так так и надо собеседоватб народ. Чтобы понять что он уже знает по делу, что уже делал раньше и какой поимел опыт из этого чтобы оценить, сможет ли он делать то что ожидается на новой работе. Как при этом поможет поиск по бинарному дереву? У меня за много проектов такие задачи стояли не часто, скажем так. Задачи тривиальней. Вспоминая что делала на текущем проекте - улучшали поиск, но для этого мы готовый фреймворк использовали и прикручивали, много веб сервисов было, функционала для разных пользователей в кастомер саппорте, улучшение профайла для покупателей чтоб они могли больше информации о себе слить ненавязчиво и им потом предложили чего по делу. Такую работу тоже надо кому- то делать, и где тут деревья поисковые ?

Я поняла вашу точку зрения и даже где-то разделяю. Просто говорю что в жизни всегда спрашивают много по теории или как минимум очень многие аспекты основной технологии или около нее. Это не меня одну, всех кого я знаю

Вот кроме алгоритмов это у меня уже давно выучено назубок, знаю большинство технических впоросов которые по джаве спрашивают. Обычно на интервью редко когда бывает больше 10 процентов того что я никогда не слышала. Индусы точно так же натаскиваются, поэтому на определенных этапах эти стандартные вопросы спрашивать практически безполезно. Многие делают ставку на то какие мол умные те кто собеседует народ и у них есть такие вопросы которые покажут истинное лицо кандидата. Однако их большинство такое богатой фантазией не обладают и вопросы берут там же где и ответы те кто проходит интервью- в интернете. алгоритмы тоже подучу со временем, это нужно.

[Zorkus]

Я книгу по алгоритмам как начала читать, там по прежнему дальше 20й страницы не продвинулась. Как читать начинаю опять - в сон клонит.

Только что знакомый отчитался об интервью там, в полный рост алгоритмы. Потому если не читается, то оставьте любителям.

Два года назад собеседовался в амазон (до оффера дошел, но по личным причинам ждать окончательного его одобрения не мог). Собеседований было 7 или 8, алгоритмы просили писать на трех как я помню. На остальных интересно так поговорили про DHT, про фильтры Блума, про работу спеллчекеров и прочее. Понравилось вполне.

Интересно, а кого они сейчас ищут на большие базы - ораклистов для поддержки своей реляционной кухни, или же для разработки и поддержки DynamoDB?

[dotcom]

Да там кого угодно искать могут. Амазон большой.

[mynameiszb]

Собеседований было 7 или 8, алгоритмы просили писать на трех как я помню. На остальных интересно так поговорили про DHT, про фильтры Блума, про работу спеллчекеров и прочее. Понравилось вполне.

Какие вы ужасы рассказываете! Какой там Блум от среднестатистического dba
Мы даже байт и бит перестали давно путать местами - просто забыли напрочь, сплошная гигантомания. Если база меньше терробайта - даже не замечаем, не наш размерчик

Интересно, а кого они сейчас ищут на большие базы - ораклистов для поддержки своей реляционной кухни, или же для разработки и поддержки DynamoDB?

А фиг его знает - почему и спрашиваю. Может, у них там облака какие завелись или еще что...

Про ораклистов могу анекдот рассказать (face2face, однако, даже не телефонное общение с попугаями, которым ты до фиолетовой звезды по определению)

- Мы тут почитали внимательно всю фигню, что про себя порассказали, и наш любимый вопрос - где вам было раньше труднее всего работать и почему?
- Труднее всего было в Оракле...
- Что? Вы работали в Оракле?!

И ощущаешь себя полным идиотом, потому что вроде как старался временна саппортной жизни повернуть реальной задницей к себе, а красивым фасадом к людям. А они "мы так читали, так читали"

[NYgal]

Ля-ля про пшлые проекты? Ну так так и надо собеседоватб народ. Чтобы понять что он уже знает по делу, что уже делал раньше и какой поимел опыт из этого чтобы оценить, сможет ли он делать то что ожидается на новой работе. Как при этом поможет поиск по бинарному дереву? У меня за много проектов такие задачи стояли не часто, скажем так. Задачи тривиальней. Вспоминая что делала на текущем проекте - улучшали поиск, но для этого мы готовый фреймворк использовали и прикручивали, много веб сервисов было, функционала для разных пользователей в кастомер саппорте, улучшение профайла для покупателей чтоб они могли больше информации о себе слить ненавязчиво и им потом предложили чего по делу. Такую работу тоже надо кому- то делать, и где тут деревья поисковые ?

Я поняла вашу точку зрения и даже где-то разделяю. Просто говорю что в жизни всегда спрашивают много по теории или как минимум очень многие аспекты основной технологии или около нее. Это не меня одну, всех кого я знаю

У меня за много-много лет где-то 10% интервью НЕ спрашивали про outer join
Просто как Отче Наш, господи-прости за богохульство.

[Zorkus]

Собеседований было 7 или 8, алгоритмы просили писать на трех как я помню. На остальных интересно так поговорили про DHT, про фильтры Блума, про работу спеллчекеров и прочее. Понравилось вполне.

Какие вы ужасы рассказываете! Какой там Блум от среднестатистического dba
Мы даже байт и бит перестали давно путать местами - просто забыли напрочь, сплошная гигантомания. Если база меньше терробайта - даже не замечаем, не наш размерчик

Нуу это вы зря так Вон в BigTable он же используется, а там явно данных побольше терабайта лежит

А так, как мне кажется, все компании типа Amazon, eBay, LinkedIn и прочее - они спрашивают две вещи всегда. а) алгоритмы и структуры данных, причем очень радуется, когда им какие-нибудь более-менее редкие структуры данных рассказываешь, что нибудь из Окасаки там:) б) задают практические задачки на горизонтальное масштабирование и смотрят какие вы тут концепции знаете.

[Интеррапт]

Собеседований было 7 или 8, алгоритмы просили писать на трех как я помню. На остальных интересно так поговорили про DHT, про фильтры Блума, про работу спеллчекеров и прочее. Понравилось вполне.

Какие вы ужасы рассказываете! Какой там Блум от среднестатистического dba
Мы даже байт и бит перестали давно путать местами - просто забыли напрочь, сплошная гигантомания. Если база меньше терробайта - даже не замечаем, не наш размерчик

Нуу это вы зря так Вон в BigTable он же используется, а там явно данных побольше терабайта лежит

А так, как мне кажется, все компании типа Amazon, eBay, LinkedIn и прочее - они спрашивают две вещи всегда. а) алгоритмы и структуры данных, причем очень радуется, когда им какие-нибудь более-менее редкие структуры данных рассказываешь, что нибудь из Окасаки там:) б) задают практические задачки на горизонтальное масштабирование и смотрят какие вы тут концепции знаете.

Все-таки очень сильно от позиции зависит, ведь Амазон или прочий Майкрософт - это не только работа с базами данных. Когда меня в Амазон затаскивали на позицию mobile developer, то никто мне вопросы про горизонтальное масштабирование не задавал.

[Stoic]

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

А что спрашивали ?

[mynameiszb]

Нуу это вы зря так Вон в BigTable он же используется, а там явно данных побольше терабайта лежит

Ну, на заборе тоже можно что угодно нацарапать, да только не факт, что читать будут. Биты, байты... Обычно сразу глобальными категориями начинают кидаться: а кластер на чем собирать будем, а в чем выигрыш/проигрыш, а почему...

Потому как багофич понапихали к 11 версии столько, что можно любого консультанта похоронить. Не до муравьев, когда вместо муравейника давно уже стопятый этаж небоскреба лепят.

А так, как мне кажется, все компании типа Amazon, eBay, LinkedIn и прочее - они спрашивают две вещи всегда. а) алгоритмы и структуры данных, причем очень радуется, когда им какие-нибудь более-менее редкие структуры данных рассказываешь, что нибудь из Окасаки там:) б) задают практические задачки на горизонтальное масштабирование и смотрят какие вы тут концепции знаете.

Вы меня до икоты пугаете. Какие структуры данных, вы что? Третья нормальная форма, помноженная на таблицы фактов и словари, приправленные сверху виртуальной базой с разграничением видимости - и еще какой-нибудь новомодный security до кучи. И потом со всем этим взлететь...

Я понимаю, что менеджменту нравится задачки задавать на тему глобализации и спасения африканских эскимосов в Сахаре, одетых в абстрактно-бетонные трусы на лямках. Но тим-лиду такое чудо куда потом девать? Он же при первом инциденте вместо штатной утвержденной процедуры спасения Титаника начнет альтернативую реальность реализовывать...

Поэтому админов все же ковыряют на тему знания инструментария, а не горизонтальных связей, imho...

Вон, в мохнатом 2005 я в Австралию собеседовался. Час меня по кишкам гоняли. И вопросы были правильные - по способам восстановления сдохших систем и предупреждению подобного... Жаль, практики у меня такой не хватило, не сошлись... Но зато и про алгоритмы даже не заикались. Потому как dba - они на голову сдвинутые, дикие люди

[ulka]

А кернельщиков по алгоритмам хоть не гоняют? Знакомый будет собеседоваться, переживает.

[Zorkus]

Нуу это вы зря так Вон в BigTable он же используется, а там явно данных побольше терабайта лежит

Ну, на заборе тоже можно что угодно нацарапать, да только не факт, что читать будут. Биты, байты... Обычно сразу глобальными категориями начинают кидаться: а кластер на чем собирать будем, а в чем выигрыш/проигрыш, а почему...

Потому как багофич понапихали к 11 версии столько, что можно любого консультанта похоронить. Не до муравьев, когда вместо муравейника давно уже стопятый этаж небоскреба лепят.

А так, как мне кажется, все компании типа Amazon, eBay, LinkedIn и прочее - они спрашивают две вещи всегда. а) алгоритмы и структуры данных, причем очень радуется, когда им какие-нибудь более-менее редкие структуры данных рассказываешь, что нибудь из Окасаки там:) б) задают практические задачки на горизонтальное масштабирование и смотрят какие вы тут концепции знаете.

Вы меня до икоты пугаете. Какие структуры данных, вы что? Третья нормальная форма, помноженная на таблицы фактов и словари, приправленные сверху виртуальной базой с разграничением видимости - и еще какой-нибудь новомодный security до кучи. И потом со всем этим взлететь...

Я понимаю, что менеджменту нравится задачки задавать на тему глобализации и спасения африканских эскимосов в Сахаре, одетых в абстрактно-бетонные трусы на лямках. Но тим-лиду такое чудо куда потом девать? Он же при первом инциденте вместо штатной утвержденной процедуры спасения Титаника начнет альтернативую реальность реализовывать...

Поэтому админов все же ковыряют на тему знания инструментария, а не горизонтальных связей, imho...

Вон, в мохнатом 2005 я в Австралию собеседовался. Час меня по кишкам гоняли. И вопросы были правильные - по способам восстановления сдохших систем и предупреждению подобного... Жаль, практики у меня такой не хватило, не сошлись... Но зато и про алгоритмы даже не заикались. Потому как dba - они на голову сдвинутые, дикие люди

Ну не ДБА-шник я, простите Оракл люблю (с ДБА-шниками работаю часто вместе), но сам я джавист серверсайдный. Потому и такие вещи мне задавали.

[vm__]

....
- Мы тут почитали внимательно всю фигню, что про себя порассказали, и наш любимый вопрос - где вам было раньше труднее всего работать и почему?
- Труднее всего было в Оракле...
- Что? Вы работали в Оракле?!

- расскажите о своём прошлом опыте поподробнее.
- с чего бы лучше начать? OK. Сначала я создал Землю... (с)

[Сабина]

Интересно, а кого они сейчас ищут на большие базы - ораклистов для поддержки своей реляционной кухни, или же для разработки и поддержки DynamoDB?

Смотря с какой стороны баз. Если это сервер сайд девелопмент - тут просто ораклист никому не нужен. Как правильно сильный server side developer, а знание Oracle ( в основном оптимизация, масштабируемость ) is a must.
Может на DBA позиции или около того и апплаются чисто oраклисты, но это совсем другая сфера с точки зрения skills.

[Сабина]

Я в одной конторке маленькой работала, правда меньше года, тухловато мне там показалось ненадежно. Они уже давно не стартaп, но в такой сфере, что деньги зарабатывают, хотя технически бардака хватает в самом продукте. Так вот хоть они и процессят пол трафила всего Интернета у них основная бизнес логика была на PLSQL, просто промашстабировали все ( 80 CPU или что-то вроде того). Джавовые сервера делали препроцессинг послe всяких джава скриптов, а потом все подбиралось Ораклом и кранчилась мощная аналитика.
У меня был опыт 5-летний на 50/50 Java/Oracle, а туда взяли чисто database developer. Я как увидела десятки пакеджей с кверями в четыре страницы (если распечатать) и тонной хинтов и аналитических функций подумала - усе приплыли . Потром привыкла, разобралась и в принципе оценила. Мощная вешь на самом деле, есть веши которые всегда будет проше и быстрее делать в самом Orakle, слава кому там надо за PL/SQL. Не зря financial institutions и телеком на нем сидят: AT&T billing, Wells Fargo collections.
Конторка та насколько я знаю разогнала всех и понанимала индюков и народ на Hadoop, интересно чем дело кончилось ? Особо позабавило что когда я сказала что ухожу мне тут же из рядового db девелопера предложили менеджером на hadoop.
Ну и все это я говорила к тому что знание Оракла самого по себе - это IMHO совсем неконкурентноспособно. Думаю без Джавы шансов на порядки меньше, unless you are DBA of course

[mynameiszb]

Ну и все это я говорила к тому что знание Оракла самого по себе - это IMHO совсем неконкурентноспособно. Думаю без Джавы шансов на порядки меньше, unless you are DBA of course

Вы путаете две совершенно разные профессии - администратора базы и разработчика. Архитект - может вырасти из той или другой, это да. Но он и не занимается непосредственно саппортом базы. А вот администратор - это в первую очередь операционка и ее нагрузка базой и сопутствующими приложениями. Это диски, их потребление и массивы. И это сам Oracle, включая все его багофичи. Я могу перечислить ежедневную рутину что для админа, что для девелопера - они зачастую перпендикулярны. Просто иногда люди путают, что код на PL/SQL могут писать и те, и другие. Но это вовсе не означает, что "сам по себе неконкурентноспособен". Задачи разные. И люди под них - тоже разные.

[Сабина]

Ну и все это я говорила к тому что знание Оракла самого по себе - это IMHO совсем неконкурентноспособно. Думаю без Джавы шансов на порядки меньше, unless you are DBA of course

Вы путаете две совершенно разные профессии - администратора базы и разработчика. Архитект - может вырасти из той или другой, это да. Но он и не занимается непосредственно саппортом базы. А вот администратор - это в первую очередь операционка и ее нагрузка базой и сопутствующими приложениями. Это диски, их потребление и массивы. И это сам Oracle, включая все его багофичи. Я могу перечислить ежедневную рутину что для админа, что для девелопера - они зачастую перпендикулярны. Просто иногда люди путают, что код на PL/SQL могут писать и те, и другие. Но это вовсе не означает, что "сам по себе неконкурентноспособен". Задачи разные. И люди под них - тоже разные.

Все что я пыталась сказать что я не видела конкурентноспособных девелоперов, которые кроме Oracle и PL/SQL ничего не знали. Если речь идет о DBA (да о профессии и о другой), то тут очевидно знаний одного Оракла предостаточно, Oracle DBA всегда были и будут в цене.
Архитектор из DBA - это что-то новое. Архитектор warehouse какого-нибудь что ли ? Или имеется в виду dba -> developer -< архитектор ? Если второе, то уже на этапе developer одного PL/SQL начнет сильно не хватать для того чтобы куда-то расти. Даже в тухлой большой консервативной контoре

[Zorkus]

Интересно, а кого они сейчас ищут на большие базы - ораклистов для поддержки своей реляционной кухни, или же для разработки и поддержки DynamoDB?

Смотря с какой стороны баз. Если это сервер сайд девелопмент - тут просто ораклист никому не нужен. Как правильно сильный server side developer, а знание Oracle ( в основном оптимизация, масштабируемость ) is a must.
Может на DBA позиции или около того и апплаются чисто oраклисты, но это совсем другая сфера с точки зрения skills.

Ну я обычно когда говорю "ораклист" понимаю или DBA, или человека который пишет строго на PL/SQL логику и имеет некоторые админские скилы как минимум. Что сервер-сайдер должен знать БД на некотором уровне, это понятно.

[Zorkus]

Я в одной конторке маленькой работала, правда меньше года, тухловато мне там показалось ненадежно. Они уже давно не стартaп, но в такой сфере, что деньги зарабатывают, хотя технически бардака хватает в самом продукте. Так вот хоть они и процессят пол трафила всего Интернета у них основная бизнес логика была на PLSQL, просто промашстабировали все ( 80 CPU или что-то вроде того). Джавовые сервера делали препроцессинг послe всяких джава скриптов, а потом все подбиралось Ораклом и кранчилась мощная аналитика.
У меня был опыт 5-летний на 50/50 Java/Oracle, а туда взяли чисто database developer. Я как увидела десятки пакеджей с кверями в четыре страницы (если распечатать) и тонной хинтов и аналитических функций подумала - усе приплыли . Потром привыкла, разобралась и в принципе оценила. Мощная вешь на самом деле, есть веши которые всегда будет проше и быстрее делать в самом Orakle, слава кому там надо за PL/SQL. Не зря financial institutions и телеком на нем сидят: AT&T billing, Wells Fargo collections.
Конторка та насколько я знаю разогнала всех и понанимала индюков и народ на Hadoop, интересно чем дело кончилось ? Особо позабавило что когда я сказала что ухожу мне тут же из рядового db девелопера предложили менеджером на hadoop.
Ну и все это я говорила к тому что знание Оракла самого по себе - это IMHO совсем неконкурентноспособно. Думаю без Джавы шансов на порядки меньше, unless you are DBA of course

У нас есть grid scheduler/manager, самописный, сам фреймворк и engines которые на нем работают и, уже, собственно логику в себе содержат, все на Java (внутри engines есть конечно логика на Pl/SQL, есть места где все логика написана как 5-8 тысяч строк на Pl/SQL). Поэтому на Hadoop-е это бы все взлетело до тех пор, пока в самих джобах можно свободно использовать PL-QL когда удобнее.

У меня вообще две мысли на этот счет.

1) Если логика нормально ложится на нереционную модель, как на пример у твиттера, сложной аналитики не требует, то там отлично работает какой нибудь mongo/redis/cassandra + hadoop.

2) Если она лучше ложится на реляционную модель, то оракл масштабируется классно, но дорого. Очень уж дорого, если масштабировать EE версию и использовать встроенные вещи типа partitioning, RAC и т.д. Например, Exadata - отличная вещь, даже возможности половинной стойки очень впечатляют. Но дорого. Масштабировать SE One через соединение отдельных шардов - можно, и сильно дешевле, чем EE, но там уже своими руками надо масштабировать. И в частности поэтому мы много логики стараемся держать на Java. Сколько стоит добавить в кластер начально-среднего уровня 3-4 ява-сервера (rhel/jboss), может виртуальных серверов, и сколько стоит апргейднуть оракловский сервер или добавить в RAC еще нодов? Но при этом сложная аналитика у нас почти везде внутри оракла живет.

[Сабина]

Интересно, а кого они сейчас ищут на большие базы - ораклистов для поддержки своей реляционной кухни, или же для разработки и поддержки DynamoDB?

Смотря с какой стороны баз. Если это сервер сайд девелопмент - тут просто ораклист никому не нужен. Как правильно сильный server side developer, а знание Oracle ( в основном оптимизация, масштабируемость ) is a must.
Может на DBA позиции или около того и апплаются чисто oраклисты, но это совсем другая сфера с точки зрения skills.

Ну я обычно когда говорю "ораклист" понимаю или DBA, или человека который пишет строго на PL/SQL логику и имеет некоторые админские скилы как минимум. Что сервер-сайдер должен знать БД на некотором уровне, это понятно.

My bad значит, но я просто не осилила всей темы, ответила на последнее

[Сабина]

У меня вообще две мысли на этот счет.

1) Если логика нормально ложится на нереционную модель, как на пример у твиттера, сложной аналитики не требует, то там отлично работает какой нибудь mongo/redis/cassandra + hadoop.

2) Если она лучше ложится на реляционную модель, то оракл масштабируется классно, но дорого. Очень уж дорого, если масштабировать EE версию и использовать встроенные вещи типа partitioning, RAC и т.д. Например, Exadata - отличная вещь, даже возможности половинной стойки очень впечатляют. Но дорого. Масштабировать SE One через соединение отдельных шардов - можно, и сильно дешевле, чем EE, но там уже своими руками надо масштабировать. И в частности поэтому мы много логики стараемся держать на Java. Сколько стоит добавить в кластер начально-среднего уровня 3-4 ява-сервера (rhel/jboss), может виртуальных серверов, и сколько стоит апргейднуть оракловский сервер или добавить в RAC еще нодов? Но при этом сложная аналитика у нас почти везде внутри оракла живет.

Та контора очень своеобразная была в плане "дорого/не дорого". Поскольку прибыль они делали - они покупали много железа, не жмотясь. Поэтому у них если что замедлялось - они туда железа бух и готово . Правда до поры до времени. A с Hadoop-ом в те времена что я застала первый опыт был печальный и начальник его в шутку "Хапупом" называл

[mynameiszb]

Архитектор из DBA - это что-то новое. Архитектор warehouse какого-нибудь что ли ? Или имеется в виду dba -> developer -< архитектор ? Если второе, то уже на этапе developer одного PL/SQL начнет сильно не хватать для того чтобы куда-то расти. Даже в тухлой большой консервативной контoре

Нет, имеется в виду именно: dba - architect. В случаях, когда проектируют базу, бывший dba с хорошим опытом совместной работы и саппорта девелоперских процессов - вполне вырастает до грамотного архитекта. Потому как имеет с одной стороны представление о процессе разработки, с другой - знает, как на базу должны ложиться бизнес-требования. Двоих лично таких видел. Очень серьезные люди. Но и там объем перелопаченной документации и доп.скилов был очень большой. А когда они начинали схемы отрисовывать на тему поддержки версионности и пр. - я за мыслью угнаться не успевал

PS. Ораклоидный dba - это не pl/sql. Некоторые админы этот самый pl/sql видят лишь в момент, когда к экзаменам готовятся.

[Kateryna]

контора о которой пишет Сабина не может выступать в качестве наглядного примера Оракл или Pl/SQL системы. Там все с ног на голову поставлено.
Например DBA, когда БД затыкается по какой-либо причине без всякого анализа убивает сессии и если это не помогает перегружает БД
убить 1 (одну) сессию в UNIX-e которая все остальные locked почему-то в голову не приходит. Анализом занимаются девелоперы если есть знания (редко у кого) и или желание (уже нет). Про AWR, ASH, backup, recovery, 24/7, data guard performance tuning я вообще молчу

Элементарная логика и, честно говоря, не гиганткие объемы данных (по меркам 2012) как песня ложаться в HADOOP

Ну про UI and reporting system in pure PL/SQL в и я кажется уже упоминала

десятки пакеджей с кверями в четыре страницы (если распечатать) и тонной хинтов и аналитических функций

говорят о том что в системе:
- нет конфигурационной логики, таблиц (вся логика в ветвистых case непосредственно в SQL),
- статистики (хинты)
- правильной структуры данных (использование аналитических функций для вычисления понедельника-воскресения в репорте вместо использования time dimension)

как бы для этого архитект и нужен

знание Оракла самого по себе - это IMHO совсем неконкурентноспособно

но найти толкового девелопера в зоопарк очень трудно

понанимала индюков

1 (один) толковый молодой парнишка работает около 2-х месяцев
Уж лучше он чем русскоязычные которые сделали весь этот бардак и всех новичков убеждали какая крутая вещь это г....