Data Engineer.

Недавно в дата Джобс было обсуждение, кто есть труЪ дата инженер, а кто так мимо проходил 🙂

Подумал можно чуть-чуть порефлексировать по этому поводу.

А так ли важен тайтл, которым тебя назовут? Многие дата-инженеры, пишущие на хардкорной скале с кетсами и спарком, (или даже на питоне) часто не довольны, что адептов SQL-based решений (К коим я также отношусь) также относят к ДЕ.

Недавно собесился в одну большую шведскую контору на ДЕ и меня спросили, на чем будешь делать задание: на SQL или на Python. А следующие этапы были больше про качество данных, моделирование данных, выбор компонент и т.д. То есть сейчас даже кодинг интервью часто пропускает проверку реального знания ЯП.

Мне больше нравится разделение на Data Platform Engineer и Data Product Engineer/Analyst в больших компаниях. Первые занимаются платформой, обвязками, иногда централизированным дата-каталогом и другими DG приблудами, а вторые деливерят бизнес-логику в дата продукт, который использует конечный потребитель.

И если для первых выбор инструментария бывает критичен, то во втором случае мне кажется, в разы важнее ориентированность на продукт и контроль бизнес-корректности, чем выбор корректного инструментария и прочее. Также стоит учитывать порог входа и вообще состав команды. Довольно редко удается найти специалиста со знанием доменной области, который еще и в SWE умеет. А вот то, что человек сможет в SQL, вероятность уже большая.

Тут понятно, что я немного biased, и для меня решение в виде drag-and-drop или набросанного SQL или python-кода выглядит часто лучше, так как оно может быстро решить нужды бизнеса. Можно сказать про накапливаемый тех долг, но практика показывает, что довольно часто бизнес-логика решения успеет поменяться несколько раз, что приведет к тому, что текущее решение просто исчезнет.

P.S. Благо мы теперь можем звать себя Analytics Engineer 😄