Не везде. Понаехавшие тоже как-то устраиваются.
не, мне пока увольнятся нельзя, пока жена будет на QA интрешипе 
Я понимаю, что для только что приехавшего с минимальным языком нужна любая работа, но в целом-то (особенно учитывая нынешний рынок) не только работодатель выбирает работников, но и вы выбираете работодателя. Один из вопросов, которые я задаю себе на интервью (по обе стороны баррикад) - хочу ли я работать вот с этим конкретным человеком? Это очень важный вопрос. Если в компании работают неадекваты, расчесывающее своё ЧСВ, и их пускают проводить собеседования - мне в такую компанию не надо - мне доводилось вставать посреди интервью и говорить: «спасибо, до свидания, мне это точно не подходит».
Одна важная штука, которой учат на interview тренингах в Амазоне, и которая применима как для интервьюера, так и для соискателя, да и вообще много где - не уверен = нет - для бизнеса гораздо хуже нанять плохого работника, чем прохлопать хорошего. Я один раз больно наступил на эти грабли, больше не хочется. А уж при трудоустройстве это ещё важнее - тут не бизнес-риски, тут своя жизнь.
1 лайк
Есть, и таких должно быть больше - потому что графы, матрицы и последовательности в прикладном программировании встречаются куда реже, чем здравый смысл и умение разложить систему на SOLID.
Все это категорически правда и верно. Проблема в том, что сейчас любая ноунейм компания мнит себя гуглем или как минимум твиттером, и устраивает цирк с конями на тему алгоритмов на графах, NP-complete задач и прочего идиотизма, в то время как job duties - это пойти в базу, взять там данные, сложить в JSON и плюнуть в REST. Или взять сообщение из кафки и куда-то его перенаправить. Или вообще отфильтровать строки в CSV файлах в каком-то ETL.
И потом смотришь в код человека, который умеет писать алгоритмы, но совершенно не обладает инженерной культурой, и его код проще выбросить, чем переписать - и думаешь “ну вот кто-то же тебя нанял, ты на доске накарябал backpack и на пальцах его рассказал, но писать код ты не умеешь и никогда не научишься”. И тебе с ним работать, особенно если он модный data scientist.
Как правило, с человеком достаточно просто поговорить 40-50 минут, чтобы понять кто он и что он.
1 лайк
Ну data scientist - он не программист, так что грех от него SOLID’а ожидать. А так-то да, помимо CS нужно же и OO design, и logical & maintainable coding на собеседовании проверять.
мне вчера тоже заявили, что джойнить и сортировать таблицы в СУБД это прошлый век, надо делать это на бэкенде.
Если я правильно понял ваше высказывание, то соглашусь с теми, о ком вы упомянули. Обрабатывать данные средствами СУБД (для случая высоконагруженных веб-приложений) не совсем рационально. Лучше считать данные как есть, а затем обработать их в отдельно. Для обычных веб-сайтов это непринципиально. Тут вполне можно обойтись средствами СУБД.
И потом ты приходишь на проект, где данные читают как есть, и в требованиях - 25 виртуалок амазона m5.24xlarge и редшифт на 20 партишнов, делаешь два индекса и три джоина, ставишь впереди elasticache - и получаешь свою комиссию за 3 x t2.xlarge.
Люди, которые умеют в (де)нормализацию и explain analyze - становятся редкостью.
Я считаю, что надо больше таких оптимизаций!
Кстати в США на эти $50 в час получится жить довольно скромно с учётом дополнительного на них налога 15% в прибавку ко всем остальным, а на расходы списать особо нечего. Ну и медстраховка только за свой счёт и льготы обамакера на этом уровне дохода уже не действуют.
Рановато. Ещё не везде на докризисные показатели то вышли.
ну да конечно, там же есть индексы, которые только мешают, давайте скачаем 10млн записей, отсортируем их пузырьком, отфильтруем, потом с другой таблицы так же возьмем 10 млн записей и будем джойнить, потом справочники возьмем и пройдемся еще по 4 раза, а потом выведем только первые 50 записей на страницу, потому что это круто делать все на бэкэнде
1 лайк
Я немного не в этой области, но разве СУБД не есть часть бэкенда?
Ничего личного, но если бы я проводил собеседование для сотрудников на высоконагруженный проект, то после такого заявления точно бы отказал претенденту.
Или вы считаете СУБД неким волшебным черным ящиком, способным без всякой нагрузки выполнить приведенные вами условия?
Во-первых, все указанные операции выполняются движком СУБД. Если запросов на такие операции очень много, то это скажется на способности движка СУБД их обслужить. В бэкэнде можно создать массу отдельных процессов по обработке каждого запроса без множества обращений к базе.
Во-вторых, если при каждом запросе появляется необходимость сортировки 10 млн записей, неважно в СУБД или в бэкэнде, то это говорит о рукожопости проектировщика конкретной базы данных.
Смотря с каких позиций рассматривать. В общем, с т.з. пользователя часть бэкэнда. Но с т.з. процессов в бэкэнде это сторонняя часть.
Дивный новый мир. Люди, не слышавшие про кеширование запросов “движком СУБД”, не знающие про кластеризацию баз данных, кеши второго уровня - но свято верующие в силу процессов на бэкенде и проводящие интервью.
2 лайка
Давайте не будем смешивать мух и котлеты.
Каждой задаче свой инструмент. Но не задача под инструмент.
Если на упомянутом выше собеседовании работодателя интересовали навыки обработки данных именно в бэкэнде, то, наверное, у него есть весомые причины для этого.
Старая американская поговорка: мы покупаем дырки, но не сверла.
а еще про индексы, планы запросов, мат. вью, статистику и прочее. я же говорю, что наличие только индексов уже дает фору. в некоторых случаях может и надо “хардкодить” на бэкенде что-то, но в большинстве случаев СУБД справляется с этим лучше и быстрее. иначе бы так бы и хранили в dbf или csv все.
Да никто не сомневается, что вы Гуру с большой буквы по части СУБД. Но вы со своими знаниями пришли туда, где они не нужны, где нужны другие навыки.
На кого вы обижаетесь? Я о вашей реплике в сообщении Форум "Говорим про Америку"
Я уверен, что ваши навыки ооочень долго будут востребованы. Повторюсь: инструмент под задачу, но не наоборот.
да я не обижаюсь, я просто очень много занимался СУБД, даже оффер был от Oracle, но я дурак, прошел все собеседования и отказался 