Data Engineer

Definirás la arquitectura de datos para sus clientes. Para esto, tendrás que entender los objetivos comerciales y las necesidades técnicas que harán que puedas convertir problemas complejos en soluciones alcanzables usando Tinybird :)

En tu día a día, desarrollarás prototipos rápidos para explicar cómo funcionan ciertas cosas o cuál es la mejor manera de hacer algo. Crearás guías técnicas para ayudar a los desarrolladores con problemas recurrentes, publicarás post técnicos y ayudarás a los clientes con sus consultas y correos electrónicos.

Eso sí, en Tynibird todo el mundo programa, y escribir SQL eficiente es muy importante, pues la plataforma se basa en gran medida en ello.

Todos forman parte del equipo de Producto, por lo que toda la experiencia que aporta la relación con los clientes realmente se refleja en impulsar la hoja de ruta del mismo.

Te sumergirás en el motor de la base de datos a bajo nivel, haciendo lo que sea necesario -tirarás código en Python- para alcanzar el máximo rendimiento: velocidad y optimización son las bases de todo el producto.

Pero no todo será optimizar, claro. Desarrollarás nuevas funcionalidades sin dejar de lado los problemas que van surgiendo en los clientes para intentar extraer aprendizajes de cada uno de ellos.

Ellos mismos han compartido con nosotros un día cualquiera. En inglés, como mandan los canones en Tinybird- :)

These days are a little bit different because of the COVID situation but you can get an idea of what's the typical day at Tinybird. I wake up early to read email and catch up with all the basecamp notifications, tickets and so on (other times I go for a run). After that I take care of my daughter during the mornings and after that I spend the afternoon doing all the work that requires focus. If you are in a similar situation, don't worry, we totally understand that.

We use Basecamp for daily coordination and planning, GitLab for issue tracking and milestones and Google Docs to discuss things like product decisions. There is always something to read and discuss.

At this stage, what I like the most is to read emails from users who find problems using the platform. Yes, it sounds weird, but you only find real problems when you actually use the product. In general most of those emails are problems that can be solved with an option or a different way to do the same (but updating our docs to avoid other users hitting the same problem, of course), sometimes it needs a bug fix or add a small feature and others just write a guide.

I usually attend client meetings with Sancha. Before the technical meeting, Jorge has already introduced the product to them, so we just go to the point. We propose a technical solution (and yes, that'd be part of your job too) and send them a proposal.

We discuss the product every day. It needs to be a balance between today and tomorrow's problems so the vision of someone that is working with the product to fix real problems is crucial (that'd be you as well).

Our product design approach is: someone proposes a solution to a problem, explains why it's important and describes how it would work. Then, everyone else asks questions and we decide if that makes sense or not.

I also write code, do some pull requests, my peers review them and when I merge it, the code goes to production. After a release, we publish a blog post and go and tell our users about what we’ve recently launched to gather feedback.

We also take time to write blog posts about how to do things with our product. It's hard to keep up with the pace, especially if we have a problem or an unexpected client request, but writing those helps us a lot.