Не могу сказать. У нас все на англ в компании. Судя по CV он около 5 лет в Германии. Бакалавра получил в Тигеране, а магистра - буквально недавно уже в Германии.
Она же чисто для апи к спарк джабам ... много работал со спарком ...
Вы немного заблуждаетесь. Скала - отдельный самодостаточный ЯП. Даже применительно в Дата Инженерии это не "чисто апи к спарк джобам".
Я просто сам бекендер, который на последнем проекте, не по своей воле
Вот примерно так 7 лет назад в нашей компании начинали строить Дата Платформу :))) Были простые бэкэндеры и фулл-стеки, которых попросили "сделать что-нить на Датабриксе для аналитики", ну они и начали делать :) В итоге через 4 года, когда наняли меня, у меня волосы дыбом встали от сделанного с т.з. архитектуры и от самого кода. То, что минимум 2 раза в неделю что-нибудь да падало на ПРОДе, даже молчу. Мой первый год в компании был посвящен поэтому перестройке и рефакторингу самых больных мест и выстраиванию процессов (от разработки, стандартов и до внедрения CI/CD). Так что хороший разработчик - не значит хороший дата инженер.
Я тут нерелевантен) Когда был мидлом, мне было все новое интересно) Да и сейчас я ничего против не имею, если мне приходится разбираться с чем-то новым, пусть даже используемым весьма ограничено.
Касательно архитектурных решений. Они должны быть долгосрочные и соответствовать бизнес и дата стратегии компании. В частности например, если политика компании "платить в среднем по рынку, незаменимых нет" (знаю кстати примеры таких компаний), то это одна история - тогда, грубо, используем все "самое попсовое", делаем все просто, проблемы решаем экстенсивным увеличением команды за 5 копеек, миримся, что иногда будет "больно" и это будет неожиданно. Если же компания ориентирована на удержание кадров и инвестирование в их развитие, то это другое. Тут имеет смысл использовать что-то менее популярное, но более подходящее вашему бизнесу. ИМХО
Касательно declarative pipeline. Я не сторонник продвигаемых вендорами направо и налево notebook-центричного похода (это делает что Майкрософт, что Датабрикс ...). Полностью понимаю их маркетинговых подход и с этой точки зрения даже не осуждаю - это хорошо продается (развесившим уши "эффективным менеджерам"), выглядит просто и, самое главное, привязывает клиента к твоей экосистеме. Но как архитектор, я стараюсь избегать такого подхода. Конкретно в DBX-воркспейсе нашего юнита (но, к сожалению, не у других) нет ни одного пайплайна, реализованного как notebook. Мой (наш) подход:
все объекты в Unity Catalog создаются через DDL-операции, которые деплоятся как патчи
все пайплайны - только Spark-приложения, упакованные в fat JAR. В случае с Питоном это были бы whl
Если мы говори о Delta Live Tables, то бОльшую часть их функционала доступна так же через SQL-синтаксис, и тогда они деплоятся через DDL-операции как патчи. То есть Питон здесь не нужен. Если же без Питоне в них никак не обойтись, то в 90% это повод задуматься, а действительно ли тут DLT будут хорошим архитектурным решением?
Конкретно этот кандидат утверждал, что знает Скалу, использовал ее на прошлом месте, да и assesment сделал на вполне себе годной Скале. Поэтому вопросы типа "отличие val от var" рассматривались просто как "проверка на вшивость" - мол убедиться, что человек не LLM-ил бездумно и имеет хоть какие-то самые-самые базовые знания о Скале (а остальное - научим, как вы заметили). И подход, ИМХО, оказался верным, так как чел сразу же поплыл, и стало понятно, что знаний и опыта со Скалой у него нет. Потом еще были general-вопросы про организацию загрузки данных, где чел тоже показал себя как джун, действующий по предоставленным ему шаблонам. То есть и сам технический собес и заданные вопросы своей цели достиг - выявить уровень кандидата через призму текущих потребностей команды. Единственное, что по мере найма (и сложностей с поиском Скалистов) приоритеты нанимающего менеджера поменялись, но это уже не относится к самому техническому собеседованию
...за отказ кандидатам по причине overqualified ...Раньше вроде люди примерно с такой периодичностью работу меняли?
Учтите специфику Германии, где люди работают в компаниях десятилетиями) Срок на одном месте меньше 3-5 лет считается уже "минусом" для CV, рекомендуют не меньше 7 %) К тому же только испыталка - полгода, да и первые 3 месяца от нового сотрудника вообще обычно ничего не ждут. Касательно overqualified - я с вами согласен. Но и менеджера понимаю. На его месте, если у меня не "горит", я бы тоже избегал overqualified-сотрудников. У меня перед глазами уже были примеры подобные, когда сотруднику было "тесно" на текущей позиции, но компания по объективным причинам, не могла ничего ему предложить бОльшего в плане проф.развития и задач.
Эх, как бы я не любил Скалу, но вынужден с вами согласиться, что, к сожалению, в Европе Скала превращается в легаси... Но касательно поддержки Скалы Датабриксом не соглашусь с вами. Все, что можно сделать на Питоне, там можно сделать легко и на Скале. Просто про это нет 100500 статей и видео от "условных индусов" на Медиуме и Ютюбе, а надо открыть документацию. Единственно огорчает, и тут вы частично правы, что сам Датабрикс при реализации каких-то Датабрикс-лок фишек сначала выкатывает их для Питона и SQL, и уже попозже - для Скалы. Из последний примеров - тот же Serverless compute. ЗЫ в холиваре Питон/Скала у каждого будет сове мнение и опыт) Я, например, долго был Питонистом, но когда в 2021м впервые был вынужден писать на Скале, достаточно быстро в нее "влюбился". И при следующей смене работы при решении тестовых заданий прям чуть ли не физически "страдал", когда приходилось делать их на Питоне - то, что на Скале было просто и изящно в 1-2 строки, на Питоне было намного "многословнее" и запутаннее и занимало 5-8 строк. Поэтому сейчас с грустью наблюдаю, что в Европе Скала постепенно увядает...
Комментарий точно писал человек а не LLM?) Как Водафон (сотовый оператор) связан с Зубными врачами? Я на всякий случай даже зашел на https://jobs.vodafone.com - никаких вакансий, связанных с зубными врачами, как и указание ЗП вилок там не нашел. Можете пруфлинк дать? В целом я ваше удивление понимаю. Но эмоции - эмоциями, факты - фактами.
В Германии ИТшник - обычная квалифицированная профессия, а не "отдельная каста". ЗП поэтому "как у всех". И кстати врач, и тем более зубной врач - намного более уважаемая профессия и даже более высокооплачиваемая
Разница между грейдами по ЗП - не как в РФ, а скромные процентов 10.
Понятия "индексация ЗП на инфляцию" почти отсутствует
Личные примеры: мне вот буквально за последние 2 месяца через LN прилетали предложения поработать Дата Архитектором по b2b контракту в одном случае за 84К брутто в год, в другом - за 110К бурто в год. И это b2b, то если при сравнении с ЗП "по найму в штате" можете смело делить на 1,5 - 1,8 (чтобы учесть отпуск, праздники, накладные расходы, доп. налоги/соц.взносы и т.п.)
два года назад был пример перед глазами. Одна компания (достаточно крупная) искала Senior Java Developer. Готова была делать оффер кандидату, но тот захотел 80К брутто. Компания не готова была платить столько и они не договорились. К этому моменту компания пыталась закрыть позицию уже 9 месяцев...
Безусловно, "выбросы" есть. Тот же офис Apple в Мюнхене очень неплохо платит. Но мы говорим о медиане, ну или о третьем квартиле.
Спасибо за комментарий. В целом согласен. Единственно прокомментирую "...то скорее требовалась премия к рынку, которой похоже не было..." - Мне вилка неизвестна, но учитывая, что в вакансии нигде она не указана, то на поток и качество CV зарплата не могла никак влиять, кмк.
Я как-то полгода-год назад, обсуждая с моим менеджером процесс найма вообще, попытался предложить ему, что мол давай, когда нам понадобится сотрудник, просто проведем один собес и сами вдвоем по его результату решим, независимо от других. Он не особо разделил подобное предложение - мол компания, процессы, бла-бла-бла... В общем, эта история окончательно меня убедила, что "nice guy" и следование процессам цениться выше, чем технические знания. За какое-нить "некорпоративное поведение" могут уволить быстрее, чем за то, что "уронил прод". Если найм еще в твою команду или тем более "под тебя", то есть смысл как-то упираться. В данном случае для меня смысла не было. Это часть ментальности, как я понимаю, и с ней ничего не сделать. Как в анекдоте:
Фотографии у нас делает Хер Мюллер, а он приходит по вторникам и средам, а сегодня пятница.
Ну вы же можете сами взять свой смартфон и сделать фотографию?
Да, могу. Но фото у нас делает Хер Мюллер, а он будет только во вторник...
Ещё мысль про "переучить человека". По моим личным наблюдениям в Германии развитие среднестатистического работника идёт намного медленнее чем в РФ. "5 лет" опыта легко может означать, что чел писал только шаблонный код и правил конфиги, даже не вникая в "кишки".
Про резон использовать Скалу - живём с тем, что имеем. Не переписывать же все "нажитое непосильным трудом" за много лет... Про ЗП. Нейронки врут. Я бы сказал что обозначенная вами вилка - скорее для Сеньора.
Крутая идея. Спасибо! Плюсую!
Не могу сказать. У нас все на англ в компании.
Судя по CV он около 5 лет в Германии. Бакалавра получил в Тигеране, а магистра - буквально недавно уже в Германии.
Вы немного заблуждаетесь. Скала - отдельный самодостаточный ЯП. Даже применительно в Дата Инженерии это не "чисто апи к спарк джобам".
Вот примерно так 7 лет назад в нашей компании начинали строить Дата Платформу :))) Были простые бэкэндеры и фулл-стеки, которых попросили "сделать что-нить на Датабриксе для аналитики", ну они и начали делать :) В итоге через 4 года, когда наняли меня, у меня волосы дыбом встали от сделанного с т.з. архитектуры и от самого кода. То, что минимум 2 раза в неделю что-нибудь да падало на ПРОДе, даже молчу. Мой первый год в компании был посвящен поэтому перестройке и рефакторингу самых больных мест и выстраиванию процессов (от разработки, стандартов и до внедрения CI/CD). Так что хороший разработчик - не значит хороший дата инженер.
Иранец
Я тут нерелевантен) Когда был мидлом, мне было все новое интересно) Да и сейчас я ничего против не имею, если мне приходится разбираться с чем-то новым, пусть даже используемым весьма ограничено.
Касательно архитектурных решений. Они должны быть долгосрочные и соответствовать бизнес и дата стратегии компании. В частности например, если политика компании "платить в среднем по рынку, незаменимых нет" (знаю кстати примеры таких компаний), то это одна история - тогда, грубо, используем все "самое попсовое", делаем все просто, проблемы решаем экстенсивным увеличением команды за 5 копеек, миримся, что иногда будет "больно" и это будет неожиданно. Если же компания ориентирована на удержание кадров и инвестирование в их развитие, то это другое. Тут имеет смысл использовать что-то менее популярное, но более подходящее вашему бизнесу. ИМХО
Касательно declarative pipeline.
Я не сторонник продвигаемых вендорами направо и налево notebook-центричного похода (это делает что Майкрософт, что Датабрикс ...). Полностью понимаю их маркетинговых подход и с этой точки зрения даже не осуждаю - это хорошо продается (развесившим уши "эффективным менеджерам"), выглядит просто и, самое главное, привязывает клиента к твоей экосистеме. Но как архитектор, я стараюсь избегать такого подхода.
Конкретно в DBX-воркспейсе нашего юнита (но, к сожалению, не у других) нет ни одного пайплайна, реализованного как notebook. Мой (наш) подход:
все объекты в Unity Catalog создаются через DDL-операции, которые деплоятся как патчи
все пайплайны - только Spark-приложения, упакованные в fat JAR. В случае с Питоном это были бы whl
Если мы говори о Delta Live Tables, то бОльшую часть их функционала доступна так же через SQL-синтаксис, и тогда они деплоятся через DDL-операции как патчи. То есть Питон здесь не нужен. Если же без Питоне в них никак не обойтись, то в 90% это повод задуматься, а действительно ли тут DLT будут хорошим архитектурным решением?
Конкретно этот кандидат утверждал, что знает Скалу, использовал ее на прошлом месте, да и assesment сделал на вполне себе годной Скале. Поэтому вопросы типа "отличие val от var" рассматривались просто как "проверка на вшивость" - мол убедиться, что человек не LLM-ил бездумно и имеет хоть какие-то самые-самые базовые знания о Скале (а остальное - научим, как вы заметили).
И подход, ИМХО, оказался верным, так как чел сразу же поплыл, и стало понятно, что знаний и опыта со Скалой у него нет. Потом еще были general-вопросы про организацию загрузки данных, где чел тоже показал себя как джун, действующий по предоставленным ему шаблонам. То есть и сам технический собес и заданные вопросы своей цели достиг - выявить уровень кандидата через призму текущих потребностей команды.
Единственное, что по мере найма (и сложностей с поиском Скалистов) приоритеты нанимающего менеджера поменялись, но это уже не относится к самому техническому собеседованию
Учтите специфику Германии, где люди работают в компаниях десятилетиями) Срок на одном месте меньше 3-5 лет считается уже "минусом" для CV, рекомендуют не меньше 7 %) К тому же только испыталка - полгода, да и первые 3 месяца от нового сотрудника вообще обычно ничего не ждут.
Касательно overqualified - я с вами согласен. Но и менеджера понимаю. На его месте, если у меня не "горит", я бы тоже избегал overqualified-сотрудников. У меня перед глазами уже были примеры подобные, когда сотруднику было "тесно" на текущей позиции, но компания по объективным причинам, не могла ничего ему предложить бОльшего в плане проф.развития и задач.
Эх, как бы я не любил Скалу, но вынужден с вами согласиться, что, к сожалению, в Европе Скала превращается в легаси...
Но касательно поддержки Скалы Датабриксом не соглашусь с вами. Все, что можно сделать на Питоне, там можно сделать легко и на Скале. Просто про это нет 100500 статей и видео от "условных индусов" на Медиуме и Ютюбе, а надо открыть документацию. Единственно огорчает, и тут вы частично правы, что сам Датабрикс при реализации каких-то Датабрикс-лок фишек сначала выкатывает их для Питона и SQL, и уже попозже - для Скалы. Из последний примеров - тот же Serverless compute.
ЗЫ в холиваре Питон/Скала у каждого будет сове мнение и опыт) Я, например, долго был Питонистом, но когда в 2021м впервые был вынужден писать на Скале, достаточно быстро в нее "влюбился". И при следующей смене работы при решении тестовых заданий прям чуть ли не физически "страдал", когда приходилось делать их на Питоне - то, что на Скале было просто и изящно в 1-2 строки, на Питоне было намного "многословнее" и запутаннее и занимало 5-8 строк. Поэтому сейчас с грустью наблюдаю, что в Европе Скала постепенно увядает...
Спасибо!
Поделитесь плз, что друзья скажут)
Прошу прощения, но я потерял нить ваших размышлений и мысль, которую вы хотите выразить
Комментарий точно писал человек а не LLM?) Как Водафон (сотовый оператор) связан с Зубными врачами? Я на всякий случай даже зашел на https://jobs.vodafone.com - никаких вакансий, связанных с зубными врачами, как и указание ЗП вилок там не нашел. Можете пруфлинк дать?
В целом я ваше удивление понимаю. Но эмоции - эмоциями, факты - фактами.
В Германии ИТшник - обычная квалифицированная профессия, а не "отдельная каста". ЗП поэтому "как у всех". И кстати врач, и тем более зубной врач - намного более уважаемая профессия и даже более высокооплачиваемая
Разница между грейдами по ЗП - не как в РФ, а скромные процентов 10.
Понятия "индексация ЗП на инфляцию" почти отсутствует
Личные примеры: мне вот буквально за последние 2 месяца через LN прилетали предложения поработать Дата Архитектором по b2b контракту в одном случае за 84К брутто в год, в другом - за 110К бурто в год. И это b2b, то если при сравнении с ЗП "по найму в штате" можете смело делить на 1,5 - 1,8 (чтобы учесть отпуск, праздники, накладные расходы, доп. налоги/соц.взносы и т.п.)
два года назад был пример перед глазами. Одна компания (достаточно крупная) искала Senior Java Developer. Готова была делать оффер кандидату, но тот захотел 80К брутто. Компания не готова была платить столько и они не договорились. К этому моменту компания пыталась закрыть позицию уже 9 месяцев...
Безусловно, "выбросы" есть. Тот же офис Apple в Мюнхене очень неплохо платит. Но мы говорим о медиане, ну или о третьем квартиле.
Да. Мне тоже с этой точки зрения это опыт был полезен - посмотреть и принять к сведению их ментальность и как все работает.
В Германии часто все должны быть nice & team & culture fit.
Спасибо за комментарий. В целом согласен.
Единственно прокомментирую "...то скорее требовалась премия к рынку, которой похоже не было..." - Мне вилка неизвестна, но учитывая, что в вакансии нигде она не указана, то на поток и качество CV зарплата не могла никак влиять, кмк.
Я как-то полгода-год назад, обсуждая с моим менеджером процесс найма вообще, попытался предложить ему, что мол давай, когда нам понадобится сотрудник, просто проведем один собес и сами вдвоем по его результату решим, независимо от других. Он не особо разделил подобное предложение - мол компания, процессы, бла-бла-бла...
В общем, эта история окончательно меня убедила, что "nice guy" и следование процессам цениться выше, чем технические знания. За какое-нить "некорпоративное поведение" могут уволить быстрее, чем за то, что "уронил прод". Если найм еще в твою команду или тем более "под тебя", то есть смысл как-то упираться. В данном случае для меня смысла не было. Это часть ментальности, как я понимаю, и с ней ничего не сделать. Как в анекдоте:
Фотографии у нас делает Хер Мюллер, а он приходит по вторникам и средам, а сегодня пятница.
Ну вы же можете сами взять свой смартфон и сделать фотографию?
Да, могу. Но фото у нас делает Хер Мюллер, а он будет только во вторник...
Сужу по примерам знакомых и своему личному опыту. Если у вас дугой опыт - буду признателен, если поделитесь
Ещё мысль про "переучить человека". По моим личным наблюдениям в Германии развитие среднестатистического работника идёт намного медленнее чем в РФ. "5 лет" опыта легко может означать, что чел писал только шаблонный код и правил конфиги, даже не вникая в "кишки".
Про резон использовать Скалу - живём с тем, что имеем. Не переписывать же все "нажитое непосильным трудом" за много лет...
Про ЗП. Нейронки врут. Я бы сказал что обозначенная вами вилка - скорее для Сеньора.
Спасибо! Интересная мысль.