Насчёт окладно-премиальной системы — я не вижу в этом проблем, если это озвучивается заранее, в разговоре с HR.
А не во время выставления итогового оффера, после того как человек уже потратил время на техническое собеседование и разговор с менеджером.
Я в свое время отклонил оффер от DINO Systems из-за этого, тоже всплыла «окладно-премиальная система» в последний момент. Это попросту некрасиво
Что бы Вы могли порекомендовать российским Hardcore Data Engineer, которые смотрят в сторону позиции Gentle Data Engineer в западных компаниях типа FAANG?
У меня, к примеру, имеются навыки 6,7 и 8 из Вашей классификации. Навык 1 на уровне intermediate. Остальное — на уровне «читал книги»
Но поможет ли мне простое изучение остальных навыков из Вашего списка, если я на текущей работе именно разработчик, а не аналитик?
Бизнес-частью занимаются аналитики, а не я.
Аналитики общаются с заказчиком, погружаются в данные, они же выставляют задачи на разработку.
А я от бизнеса достаточно далеко.
Просто изучать всё необходимое, и идти на собеседование в желаемую компанию?
Менять работу и искать компанию, где разработчик будет ближе к бизнесу?
Становиться аналитиком? :O
Спасибо автору за статью, с большим удовольствием прочитал!
Если у вас найдётся минутка — я бы хотел задать вопрос.
Мне кажется, что у нас и на Западе (в условной Канаде, к примеру) под Data Engineer понимаются несколько разные вещи.
Я, к примеру, последние пару лет работаю на Big Data стэке (Spark, Hive, etc.), и когда у нас собеседуют людей на такие позиции как моя — общий принцип сводится к «Нам нужен software engineer со знанием java/scala/python, который знает инструменты big data».
А когда я смотрю требования на позицию Data Engineer в том же Амазон, то вижу что процесс интервью сильно отличается
Судя по ответам, при собеседовании на data engineer в Амазон выделяются следующие блоки
— Data Warehousing
— Data Modeling
— Complex SQL
— Big Data Technology
Если последние 2 пункта более-менее совпадают с российскими реалиями, то про dwh и дата моделинг у нас не спрашивает почти никто (коллеги, поправьте если я ошибаюсь).
При этом, судя по всему, у кандидатов data engineer в Амазоне не спрашивают ничего по software engineering.
Собственно, мой вопрос: актуален ли приведенный список скиллов для собеседования на позицию, аналогичную вашей? И если актуален — то почему, на ваш взгляд, так велика разница в требованиях между российским рынком и западным («нам нужен кодер, который еще знает пару big data технологий» VS «нам нужен чувак, который шарит в данных»?)
Я имел опыт работы с Zeppelin лишь однажды, то еще удовольствие. Хотел отобразить данные по работе spark-job, все зубы об него сломал. Не обрабатывает Scala-код и все тут. При этом выбрасывает ошибку на строке, в которой ошибок нет.
Попросил помочь коллегу. Тот подошел, сказал «Аааа, да у него со скобками глюк какой-то» и перенес одну квадратную скобку с текущей строки на следующую, после чего все заработало:)
Неоднократно слышал, что Zeppelin — набитый глюками инструмент, и лучше пользоваться Jupiter. Учитывая мой, хоть и небогатый, опыт склонен с этим мнением согласиться
По содержанию вроде бы вполне ок, во всяком случае те 5 глав, которые я прочитал. Перевод вполне адекватный, устоявшиеся термины типа продюсеров и комсюмеров хоть и переводятся на русский, но хотя бы даются в том же месте в скобках на английском.
Например "… эта штуковина называется производитель (Producer)".
Из минусов — очень удручает код примеров, с кривым форматированием, неправильным количеством скобок и отсутствием точек с запятой (речь о Java, если что).
Скорее всего это огрехи оригинального издания, но менее грустно от этого не становится.
Господа авторы, ну вы бы хоть попробовали это запустить прежде чем помещать в книгу -_-
public int partition(String topic, Object key, byte[] keyBytes,
Object value, byte[] valueBytes, Cluster cluster)
{
List<PartitionInfo> partitions =
cluster.partitionsForTopic(topic);
int numPartitions = partitions.size();
if ((keyBytes == null) || (!(key instanceOf String)))
throw new InvalidRecordException("We expect all messages
to have customer name as key")
if (((String) key).equals("Banana"))
return numPartitions-1;
// Banana всегда попадает в последний раздел
// Другие записи распределяются по разделам путем хеширования
return (Math.abs(Utils.murmur2(keyBytes)) % (numPartitions - 1))
}
В целом же издание вроде адекватное, если хотите освоить Kafka — стоит купить, вполне читабельно и написано неплохим языком
Для тех, кто впервые сталкивается с React — слишком коротко и поверхностно. Бэк и его взаимодействие с фронтом не затронуты вообще.
Собственно, статья называется «Первое приложение на Spring Boot + ReactJS», но итогового работающего приложения нет.
Пример не связан с исходниками статьи, но суть понятна. Используя SpEL, указываете в Query нужную реализацию User'a, которая и будет выступать в качестве T.
Добрый вечер!
Бывает, но только в качестве фич конкретных СУБД:) На мой взгляд, при реализации лучше все-таки держать в голове вероятность смены провайдера.
Добрый день!
В принципе, Вы правы. Об этом как раз говорится здесь:
Стратегия №4 (JOINED) подойдет в случаях, когда требуются полиморфные запросы и ассоциации, но подклассы объявляют относительно много новых полей.
Другое дело, что если их нет, то нет и особого смысла выбирать «заточенную» под них стратегию JOINED, при наличии более выигрышных в плане производительности вариантов.
А не во время выставления итогового оффера, после того как человек уже потратил время на техническое собеседование и разговор с менеджером.
Я в свое время отклонил оффер от DINO Systems из-за этого, тоже всплыла «окладно-премиальная система» в последний момент. Это попросту некрасиво
Хоть бы постеснялись заставлять своих сотрудников спамить «оценками» аж до первого места, учитывая что даже Jet Brains на третьем.
Выглядит в итоге примерно так:
Список топ-100 самых привлекательных работодателей мира:
ИП Криворучкин — 4.99
ООО «Тяпки и жимолость» — 4.88
SpaceX — 4.80
Google — 4.76
Что бы Вы могли порекомендовать российским Hardcore Data Engineer, которые смотрят в сторону позиции Gentle Data Engineer в западных компаниях типа FAANG?
У меня, к примеру, имеются навыки 6,7 и 8 из Вашей классификации. Навык 1 на уровне intermediate. Остальное — на уровне «читал книги»
Но поможет ли мне простое изучение остальных навыков из Вашего списка, если я на текущей работе именно разработчик, а не аналитик?
Бизнес-частью занимаются аналитики, а не я.
Аналитики общаются с заказчиком, погружаются в данные, они же выставляют задачи на разработку.
А я от бизнеса достаточно далеко.
Просто изучать всё необходимое, и идти на собеседование в желаемую компанию?
Менять работу и искать компанию, где разработчик будет ближе к бизнесу?
Становиться аналитиком? :O
Заранее спасибо!
Сколько всего у вас заняла подготовка (к примеру, N месяцев по M часов в день)?
Если у вас найдётся минутка — я бы хотел задать вопрос.
Мне кажется, что у нас и на Западе (в условной Канаде, к примеру) под Data Engineer понимаются несколько разные вещи.
Я, к примеру, последние пару лет работаю на Big Data стэке (Spark, Hive, etc.), и когда у нас собеседуют людей на такие позиции как моя — общий принцип сводится к «Нам нужен software engineer со знанием java/scala/python, который знает инструменты big data».
А когда я смотрю требования на позицию Data Engineer в том же Амазон, то вижу что процесс интервью сильно отличается
К примеру, на Quora есть топик:
How is the Data Engineer interview process at amazon?
Судя по ответам, при собеседовании на data engineer в Амазон выделяются следующие блоки
— Data Warehousing
— Data Modeling
— Complex SQL
— Big Data Technology
Если последние 2 пункта более-менее совпадают с российскими реалиями, то про dwh и дата моделинг у нас не спрашивает почти никто (коллеги, поправьте если я ошибаюсь).
При этом, судя по всему, у кандидатов data engineer в Амазоне не спрашивают ничего по software engineering.
Собственно, мой вопрос: актуален ли приведенный список скиллов для собеседования на позицию, аналогичную вашей? И если актуален — то почему, на ваш взгляд, так велика разница в требованиях между российским рынком и западным («нам нужен кодер, который еще знает пару big data технологий» VS «нам нужен чувак, который шарит в данных»?)
Заранее спасибо!
Попросил помочь коллегу. Тот подошел, сказал «Аааа, да у него со скобками глюк какой-то» и перенес одну квадратную скобку с текущей строки на следующую, после чего все заработало:)
Неоднократно слышал, что Zeppelin — набитый глюками инструмент, и лучше пользоваться Jupiter. Учитывая мой, хоть и небогатый, опыт склонен с этим мнением согласиться
По содержанию вроде бы вполне ок, во всяком случае те 5 глав, которые я прочитал. Перевод вполне адекватный, устоявшиеся термины типа продюсеров и комсюмеров хоть и переводятся на русский, но хотя бы даются в том же месте в скобках на английском.
Например "… эта штуковина называется производитель (Producer)".
Из минусов — очень удручает код примеров, с кривым форматированием, неправильным количеством скобок и отсутствием точек с запятой (речь о Java, если что).
Скорее всего это огрехи оригинального издания, но менее грустно от этого не становится.
Господа авторы, ну вы бы хоть попробовали это запустить прежде чем помещать в книгу -_-
В целом же издание вроде адекватное, если хотите освоить Kafka — стоит купить, вполне читабельно и написано неплохим языком
Собственно, статья называется «Первое приложение на Spring Boot + ReactJS», но итогового работающего приложения нет.
Например, вот так:
Пример не связан с исходниками статьи, но суть понятна. Используя SpEL, указываете в Query нужную реализацию User'a, которая и будет выступать в качестве T.
Бывает, но только в качестве фич конкретных СУБД:) На мой взгляд, при реализации лучше все-таки держать в голове вероятность смены провайдера.
В принципе, Вы правы. Об этом как раз говорится здесь:
Другое дело, что если их нет, то нет и особого смысла выбирать «заточенную» под них стратегию JOINED, при наличии более выигрышных в плане производительности вариантов.