Empleo
Del feed del socio
Ingeniero Full Stack (m/f/d)
Precio a consultar
Detalles
- Tipo de empleo
- Jornada completa
- Remoto
- No
- Empresa
- Glassdollar
Descripción
Traducido automáticamente de English. El texto original es el oficial. Traducción automática — se está preparando una más precisa.
TL;DR Únase a GlassDollar y ayude a construir el sistema que algunas de las empresas más grandes de Europa utilizan para encontrar, probar y adoptar tecnología de inicio.
Buscamos un ingeniero que quiera mucha más responsabilidad que "implementar lo que está en el ticket". Tomará un problema ambiguo, le dará forma junto con el producto, tomará decisiones técnicas importantes, lo enviará y permanecerá lo suficientemente cerca para ver si funcionó.
Esperamos que tengas opiniones. También esperamos que sea lo suficientemente bueno para cambiarlos.
El problema que estamos resolviendo Las grandes organizaciones son notablemente buenas acumulando problemas. Una empresa con 100.000 empleados puede tener miles de desafíos operativos en sus unidades de negocio. En algún lugar fuera de esa organización, una startup probablemente ya haya construido parte de la solución. Lograr que esas dos cosas se cumplan todavía se logra a través de hojas de cálculo, largos hilos de correo electrónico y reuniones cuyo resultado principal es otra reunión.
GlassDollar OS es el sistema operativo para clientes de riesgo: problema → descubrimiento de inicio → evaluación → PoC → adopción, en un flujo de trabajo repetible.
Nuestros clientes son algunas de las organizaciones más grandes de Europa, por lo que el software debe moverse rápidamente y comportarse como algo en lo que una empresa pueda confiar. Esa tensión crea interesantes problemas de ingeniería.
Lo que buscamos Puedes llevar un problema más allá del billete. El trabajo a menudo comienza con algo incompleto, como "los clientes necesitan una mejor manera de gestionar X". Le darás forma al problema con el producto, desafiarás las suposiciones y decidirás qué pertenece a esta iteración. Aquí se esperan opiniones firmes sobre lo que construimos, no solo sobre cómo.
Te preocupas por el producto. Quiere saber para quién está construyendo, por qué es importante el problema y cómo se ve el éxito. Ese contexto debería moldear sus decisiones técnicas.
Tienes criterio técnico. Rara vez existe una arquitectura correcta. Sabes cuándo la solución aburrida supera a la ambiciosa, cuándo una abstracción ayuda y cuándo oculta el problema, y cuándo una pequeña característica está a punto de crear seis meses de deuda técnica. Esperamos que razone sobre los límites de las API, los modelos de datos, los permisos, el rendimiento, los modos de falla, las pruebas, la observabilidad y la implementación, y que plantee sus inquietudes con un argumento claro adjunto.
Usted mejora el sistema, no solo la función. Se corrige el patrón de propagación en lugar de la instancia única, se facilita una API para la siguiente persona y se mejoran las pruebas porque la configuración actual hace que todos tengan miedo de implementar. Su impacto debe mostrarse más allá de las solicitudes de extracción con su nombre.
Puedes trabajar a través de la pila. Una característica podría ejecutarse desde una interacción de React a través de GraphQL hasta un servicio de Nodo, un rediseño de esquema, una actualización de permisos y una migración segura para los clientes existentes. Importa más la curiosidad por seguir el problema que la misma profundidad en todas partes.
Eres dueño de la calidad. Contamos con control de calidad. Ahí no es donde comienza la calidad. ¿Qué se rompe si esta solicitud ocurre dos veces? ¿Qué sucede con los datos antiguos o cuando la API falla a mitad de camino? Usamos Playwright y Jest junto con revisiones y seguimiento. El objetivo no es la cobertura, es la confianza.
Te comunicas como si tus decisiones importaran más adelante. Dentro de seis meses, alguien debería comprender una decisión importante sin tener que revisar diecisiete mensajes de Slack y un comentario de Notion eliminado. Eso significa escribir las cosas cuando son importantes, explicar claramente las compensaciones, brindar revisiones de código útiles y sacar a la luz los riesgos antes de que se conviertan en incidentes.
Subes el listón de la ingeniería a tu alrededor. No es necesario un título directivo para tener influencia. Encontrar el agujero en una arquitectura, desbloquear a alguien sin quitarle el teclado, discrepar sin convertir cada decisión en un referéndum. A medida que ganes confianza, naturalmente te convertirás en la persona a la que la gente le planteará problemas más difíciles.
Qué harás durante tu primer año:
• Integraciones empresariales: en los sistemas, datos, proveedores de identidad y flujos de trabajo de nuestros clientes. Esto es lo que convierte a GlassDollar de un software en el que alguien inicia sesión a una infraestructura en la que opera su organización.
• API y MCP: API REST públicas y servidores MCP para nuestros clientes, sus ingenieros y, cada vez más, sus agentes de IA. Lo interesante no es exponer los puntos finales, sino diseñar una plataforma externa que estaremos felices de respaldar dentro de unos años.
• IA dentro de flujos de trabajo reales: incorporaciones, búsqueda vectorial y LLM en una gran base de datos de startups y datos de innovación corporativa. Estamos menos interesados en agregar un botón ✨ a todo que en encontrar lugares donde la IA elimine el trabajo real.
• Automatización del flujo de trabajo: activadores, notificaciones y automatización que reemplazan a los humanos moviendo información entre sistemas.
• Ingeniería central del producto: interfaces React, API, consultas PostgreSQL, permisos, migraciones, trabajo de rendimiento y algún error ocasional cuya causa raíz hace que todos se queden mirando la pantalla en silencio.
Nuestra pila
• Interfaz: TypeScript, React, Material UI, Cliente Apollo, Dramaturgo
• Servidor: Node.js, GraphQL, Prisma, PostgreSQL, Jest
• Infraestructura: AWS, Terraform, Acciones de GitHub, Sentry
• Cada vez más: API de LLM, incorporaciones, búsqueda de vectores, MCP, flujos de trabajo de ingeniería asistidos por IA
No necesitas experiencia con cada artículo. Nos importa más razonar sobre sistemas que haber memorizado nuestra pila exacta.
Requisitos
• Experiencia sustancial en producción con TypeScript, React y Node.js.
• Razonamiento cómodo sobre bases de datos relacionales, no sólo el ORM
• Puede llevar una característica de forma independiente desde un punto de partida poco claro hasta la producción.
• Puede leer código desconocido sin proponer inmediatamente una reescritura
Es bueno tener:
• Experiencia con GraphQL, Prisma o PostgreSQL a escala
• Exposición a API de LLM, incrustaciones o búsqueda vectorial
• Experiencia en posesión de sistemas, no solo funciones
¿No marcas todas las casillas? Aplicar de todos modos. Preferimos tener la conversación que perder a alguien por un punto...
Fuente: Arbeitnow (https://www.arbeitnow.com/jobs/companies/glassdollar/full-stack-engineer-berlin-413634)
Buscamos un ingeniero que quiera mucha más responsabilidad que "implementar lo que está en el ticket". Tomará un problema ambiguo, le dará forma junto con el producto, tomará decisiones técnicas importantes, lo enviará y permanecerá lo suficientemente cerca para ver si funcionó.
Esperamos que tengas opiniones. También esperamos que sea lo suficientemente bueno para cambiarlos.
El problema que estamos resolviendo Las grandes organizaciones son notablemente buenas acumulando problemas. Una empresa con 100.000 empleados puede tener miles de desafíos operativos en sus unidades de negocio. En algún lugar fuera de esa organización, una startup probablemente ya haya construido parte de la solución. Lograr que esas dos cosas se cumplan todavía se logra a través de hojas de cálculo, largos hilos de correo electrónico y reuniones cuyo resultado principal es otra reunión.
GlassDollar OS es el sistema operativo para clientes de riesgo: problema → descubrimiento de inicio → evaluación → PoC → adopción, en un flujo de trabajo repetible.
Nuestros clientes son algunas de las organizaciones más grandes de Europa, por lo que el software debe moverse rápidamente y comportarse como algo en lo que una empresa pueda confiar. Esa tensión crea interesantes problemas de ingeniería.
Lo que buscamos Puedes llevar un problema más allá del billete. El trabajo a menudo comienza con algo incompleto, como "los clientes necesitan una mejor manera de gestionar X". Le darás forma al problema con el producto, desafiarás las suposiciones y decidirás qué pertenece a esta iteración. Aquí se esperan opiniones firmes sobre lo que construimos, no solo sobre cómo.
Te preocupas por el producto. Quiere saber para quién está construyendo, por qué es importante el problema y cómo se ve el éxito. Ese contexto debería moldear sus decisiones técnicas.
Tienes criterio técnico. Rara vez existe una arquitectura correcta. Sabes cuándo la solución aburrida supera a la ambiciosa, cuándo una abstracción ayuda y cuándo oculta el problema, y cuándo una pequeña característica está a punto de crear seis meses de deuda técnica. Esperamos que razone sobre los límites de las API, los modelos de datos, los permisos, el rendimiento, los modos de falla, las pruebas, la observabilidad y la implementación, y que plantee sus inquietudes con un argumento claro adjunto.
Usted mejora el sistema, no solo la función. Se corrige el patrón de propagación en lugar de la instancia única, se facilita una API para la siguiente persona y se mejoran las pruebas porque la configuración actual hace que todos tengan miedo de implementar. Su impacto debe mostrarse más allá de las solicitudes de extracción con su nombre.
Puedes trabajar a través de la pila. Una característica podría ejecutarse desde una interacción de React a través de GraphQL hasta un servicio de Nodo, un rediseño de esquema, una actualización de permisos y una migración segura para los clientes existentes. Importa más la curiosidad por seguir el problema que la misma profundidad en todas partes.
Eres dueño de la calidad. Contamos con control de calidad. Ahí no es donde comienza la calidad. ¿Qué se rompe si esta solicitud ocurre dos veces? ¿Qué sucede con los datos antiguos o cuando la API falla a mitad de camino? Usamos Playwright y Jest junto con revisiones y seguimiento. El objetivo no es la cobertura, es la confianza.
Te comunicas como si tus decisiones importaran más adelante. Dentro de seis meses, alguien debería comprender una decisión importante sin tener que revisar diecisiete mensajes de Slack y un comentario de Notion eliminado. Eso significa escribir las cosas cuando son importantes, explicar claramente las compensaciones, brindar revisiones de código útiles y sacar a la luz los riesgos antes de que se conviertan en incidentes.
Subes el listón de la ingeniería a tu alrededor. No es necesario un título directivo para tener influencia. Encontrar el agujero en una arquitectura, desbloquear a alguien sin quitarle el teclado, discrepar sin convertir cada decisión en un referéndum. A medida que ganes confianza, naturalmente te convertirás en la persona a la que la gente le planteará problemas más difíciles.
Qué harás durante tu primer año:
• Integraciones empresariales: en los sistemas, datos, proveedores de identidad y flujos de trabajo de nuestros clientes. Esto es lo que convierte a GlassDollar de un software en el que alguien inicia sesión a una infraestructura en la que opera su organización.
• API y MCP: API REST públicas y servidores MCP para nuestros clientes, sus ingenieros y, cada vez más, sus agentes de IA. Lo interesante no es exponer los puntos finales, sino diseñar una plataforma externa que estaremos felices de respaldar dentro de unos años.
• IA dentro de flujos de trabajo reales: incorporaciones, búsqueda vectorial y LLM en una gran base de datos de startups y datos de innovación corporativa. Estamos menos interesados en agregar un botón ✨ a todo que en encontrar lugares donde la IA elimine el trabajo real.
• Automatización del flujo de trabajo: activadores, notificaciones y automatización que reemplazan a los humanos moviendo información entre sistemas.
• Ingeniería central del producto: interfaces React, API, consultas PostgreSQL, permisos, migraciones, trabajo de rendimiento y algún error ocasional cuya causa raíz hace que todos se queden mirando la pantalla en silencio.
Nuestra pila
• Interfaz: TypeScript, React, Material UI, Cliente Apollo, Dramaturgo
• Servidor: Node.js, GraphQL, Prisma, PostgreSQL, Jest
• Infraestructura: AWS, Terraform, Acciones de GitHub, Sentry
• Cada vez más: API de LLM, incorporaciones, búsqueda de vectores, MCP, flujos de trabajo de ingeniería asistidos por IA
No necesitas experiencia con cada artículo. Nos importa más razonar sobre sistemas que haber memorizado nuestra pila exacta.
Requisitos
• Experiencia sustancial en producción con TypeScript, React y Node.js.
• Razonamiento cómodo sobre bases de datos relacionales, no sólo el ORM
• Puede llevar una característica de forma independiente desde un punto de partida poco claro hasta la producción.
• Puede leer código desconocido sin proponer inmediatamente una reescritura
Es bueno tener:
• Experiencia con GraphQL, Prisma o PostgreSQL a escala
• Exposición a API de LLM, incrustaciones o búsqueda vectorial
• Experiencia en posesión de sistemas, no solo funciones
¿No marcas todas las casillas? Aplicar de todos modos. Preferimos tener la conversación que perder a alguien por un punto...
Fuente: Arbeitnow (https://www.arbeitnow.com/jobs/companies/glassdollar/full-stack-engineer-berlin-413634)
Este anuncio proviene de un feed de socios. Solicítalo en el sitio web de origen.
Fuente: Glassdollar
Ubicación
Berlín, Alemania
Publicación proporcionada por Glassdollar.
