Todos estamos de acuerdo que las oportunidades para senior engineers abundan. De hecho, conseguir un trabajo remoto internacional como Senior Engineer es mucho más sencillo que para un junior o un entry level.

¡Y ni hablar de la paga! Los salarios para senior son bastante mejor, especialmente en el mercado de Estados Unidos, que en mi experiencia, es el mercado que paga mejor a los ingenieros de software en todo el mundo. La verdad, inclusive en países como Inglaterra o Holanda, Alemania, Japón, realmente que Estados Unidos te van a pagar el doble o triple inclusive.

Pero ¿Cómo sabe si eres Senior Engineer? ¿Es acaso por los años de experiencia? o ¿quizás las tecnologías, librerías, frameworks que manejas? o ¿quizás por los proyectos realizados?, ¿la experiencia que tienes?, ¿cómo defines a un Senior Engineer? Y lo más importante aún, ¿eres tú un Senior Engineer? ¿te consideras senior? ¿te animarías a aplicar a uno de estos puestos en Estados Unidos como Senior Engineer?.

Cuando me ha tocado entrevistar a Senior Engineers, una de las preguntas que me ayuda a identificar el nivel del candidato es la siguiente: 

Please walk me through a feature's life cycle in your company, and all your interactions from planning to release.

Con esta pregunta se le pide al candidato que explique su grado de colaboración en el desarrollo de algún feature en su rol actual.

Y se espera que el candidato mencione otras cosas, no solamente se enfoque en código o sacar tickets en Jira, porque, si solamente se enfoca en codificar, que buenas prácticas, que testing y cosas así, pero olvida todo lo que hay detrás, entonces, yo la verdad no lo consideraría como un Senior y mucho menos un Staff o Principal.

En este episodio de códigos sin fronteras, voy a describir algunas de las características que definen a un Ingeniero Senior, además de que es lo que se espera escuchar como respuesta a la pregunta de entrevista que mencioné hace un instante.

En primer lugar, un Senior Engineer está bastante involucrado en resolver problemas de negocio. Para esto se requiere que, como ingeniero senior, estés bastante involucrado en la definición de 

. Okey, entonces el liderazgo del negocio o de la compañía va a definir estos objetivos.

Cuáles son los objetivos del negocio para, normalmente lo hacen por trimestre, pero algunos lo hacen por seis meses o un año. Depende de cada organización. Pero liderazgo va a definir cuáles son los objetivos para el negocio. Por ejemplo, uno OKR podría ser incrementar. El monthly recurring revenue por un 5%, Podría ser un OKR para un trimestre.  Entonces tú, basado en esos, OKRs que recibiste de parte del liderazgo, con tu equipo vas a definir lo que son los KPIs. 

Los KPIs son los indicadores que te van a llegar a alcanzar esos objetivos en el OKR . Entonces el  ejemplo del OKR anterior, de incrementar el monthly recurring revenue por 5%, un KPI podría ser  incrementar los a los trials por un 10%. Entonces, esos trials  se espera que se conviertan en ventas, que las personas que entran al trial de tu aplicación o de tu producto, al final  de la evaluación puedan adquirir el producto.

Entonces como senior engineer, tú estás involucrado en la definición de estos KPIs, ¿cómo estás involucrado?. Bueno, dando technical input, definiendo los proyectos, ver si son factibles o no. 

Y ese es el segundo punto, básicamente de una característica de un senior engineer, es que colabora con producto y diseño para tener impacto en esos KPIs.

Como mencionaba, de manera a, va a proveer technical input, va a mencionar si es factible realizar tecnológicamente esa solución, ¿tenemos esa información disponible, eh? ¿Tenemos las herramientas y el talento necesario para poder satisfactoriamente realizar este proyecto?. 

Esas son las preguntas que, como senior engineerI, tienes que resolver y tienes que comentar cuando se está haciendo la planeación y sobre todo también dar estimaciones, ayudar a crear ese roadmap basado en las estimaciones que tú estás haciendo. Y es eso, solo son estimaciones. Entonces, un senior, eh…

También hay, también a niveles de senior. En diferentes organizaciones como Senior 1 senior, Senior 2. Los seniors más avanzados son los que estarían bastante más involucrados en lo que viene siendo los OKRs y los KPIs, tanto la definición, quizás también ya hasta, el Staff (Staff Engineer) si o sí, tiene que estar en estas reuniones o en estas definiciones, pero un ingeniero senior, también podría estar aquí aportando valor, aportando ideas, inclusive la planeación, y tener para tener cierto Impacto en el negocio.

Otra característica de un ingeniero senior es que toman full Ownership en iniciativas. Okey? Y esta es una palabra clave que te recomendaría que la utilices cuando estés entrevistando, decir:

I’ve been taking full ownership of this initiative

O decir cosas así, con esta entrevistando, es una palabra clave que siempre agrada. Los entrevistadores escucharon no cuando tomas full ownership de algo. 

¿Y qué significa tomar full ownership? Bueno, esto significa que vas a dirigir un nuevo feature en una nueva iniciativa de principio a fin. Ah, vas a tomar esa idea de proyecto y vas a definir una solución tecnológica para ese proyecto.

Entonces tu product manager va a definir un documento, un one pager, también va a definir un product spec (Product Brief), que básicamente es un documento donde se define el problema se define también, eh, cuáles son la la posible hipótesis, la solución y cómo medir éxito, y todos los detalles de la solución como de funcionar.

¿Qué se espera? ¿qué no se espera? ¿cuál es el alcance? Todo eso te lo va a definir en ese documento. Tú vas a tomar ese documento y lo vas a crear una solución tecnológica. Eh donde eh? Bueno, esa es la siguiente parte también de lo que viene siendo un senior engineer. Pero antes de pasar a ese punto, quiere comentar también que full ownership entonces significa que vas a tomar una idea, vas a planear, vas a organizar, codificar, testear y deployar. Eso es full ownership desde la idea hasta tener satisfactoriamente en producción esa iniciativa, ese proyecto, okey.

La siguiente característica de un senior engine es la definición y documentación de la solución, que es lo que comentaba anteriormente, ahora vamos a hablar un poquito más.

Aquí básicamente, lo que tú tienes que hacer, una vez que tomaste ese documento que hizo el product manager. El product designer va a diseñar una solución, pero es bien importante que trabajen en conjunto porque luego el product designer viene con cosas que, o sea, son complicadas, no de no tienes quizás la información o no tienes quizá ciertas piezas, que necesitas para lograr realizar ese diseño, esa solución, que el product designer ha definido. 

Entonces bien importante también que trabajes junto, a la hora que el product designer está trabajando en el diseño de la solución. Una vez que tienes el producto definido y el diseño. Una vez que tu Product Manager y Product Designer te entregan, tú tienes que definir un tech spec. 

Y este tech spec, va básicamente a definir la solución tecnológica donde tú vas a definir allí, las opciones disponibles que tienes para dar esa solución en base a eso, tomar la mejor decisión. 

Luego que tienes esto, puedes crear un Tech Spec para lo que se decida haber tomado y bueno, aquí hay en varias organizaciones. Me ha tocado. Trabajar en organizaciones donde tienen este proceso un poco más definido que otras, eh, por ejemplo, ah, recuerdo que en cierta ocasión trabajé en una empresa donde para antes de realizar el tech spec, se hacía un documento que se llamaba DACI (Driver, Approver, Contributors, Informed), allí ponías todas las opciones disponibles, sus pro, contras y entonces se evaluaba. 

De allí, colaborabas con otros ingenieros, otros tech leads, eh, y bueno, allí entre todos. Ah, bueno, te lo revisaban. No. Alguien dirigía la iniciativa del que tomó full ownership de la iniciativa la dirigía hacia todo esto y las demás personas colaboraban. Entonces, esto, un senior engineer es lo tiene que hacer. Definición y documentación. Un Senior Engineer avanzado,  si o si, tiene que hacer esto.

La siguiente característica de un señor engineer, te diría que es aterrizar esa solución. Ese tech spec que tú creaste en pequeñas tareas, se le llama, cuando esté entrevistando, puedes decir:

La solución que estás proponiendo, porque al final del día, vas a trabajar en pequeñas tareas para que las pueda distribuir a todo el equipo y todos puedan trabajar en conjunto, ciertamente que haber dependencias. Pero la idea es. Hacer las tareas lo más pequeño posible porque va a ser más fácil de probar más fácil de documentar, más fácil de que no haya tantos conflictos. Y bueno, ir deployando a si usas un feature flag, puedes ir deployando continuamente.

Ahora, otra característica de un Senior Engineer, es que, vas a hacer el grooming y la planificación de los tickets que se van a trabajar en diferentes Sprints, si es que usan scrum. 

Pero si no usan scrum, de igual manera, tiene que haber cierta planeación y comunicarlo al equipo de trabajo. Esto en scrum se llama el grooming, donde básicamente tomas un ticket los tickets que ya creaste y lo comunicas al equipo, las demás personas, ingenieros de tu equipo hacen preguntas, ahí está tu product manager para resolver si sale una, una pregunta con respecto al producto, o el diseñador también está allí porque si sale alguna pregunta con respecto a diseño y todo el equipo hace que, esas tareas que tú diseñaste quizá le faltó alguna descripción. Algunos detalles. 

Entonces, en el grooming es donde todo el equipo se junta para definir la tarea y estén de acuerdo y conozcan lo que se tiene que hacer en ese ticket en específico. Aquí se resuelven dudas en cuanto a la solución.

Y bueno, luego de todo este trabajo viene la parte de codificar y hacer pruebas unitarias también. Como senior engineer, tienes que participar en el desarrollo, eh? Claro, está que entre más avanzado un staff engineer, un principal engineer, tiene todavía participación codificando, pero no tanta necesariamente, porque a veces tiene que agarrar otra iniciativa y trabajar en toda la parte de diseño, etcétera, etc.

A partir de aquí. También eres responsable de apoyar a tu equipo a los ingenieros más juniors. Si tienen alguna pregunta, si están bloqueados en algo, es tu responsabilidad como senior engineer, apoyarlos, ayudarlos en lo que se pueda.

Para que el proyecto salga delante porque recuerda, tú eres el responsable, tú tienes full ownership de la iniciativa. Entonces tienes tú que apoyar a tu equipo para que todo te asegures de que el proyecto salga en el tiempo de preferencia que que definieron.

Otra característica de un ingeniero senior es que estás constante comunicación con tu producto manager en el memento del desarrollo de la codificación cuando estás codificando, porque siempre salen cosas de que no os faltó este componente por acá, o que aquella API de la cual dependía, es legacy, y no sé, siempre salen cosas. 

Por lo tanto, es bien importante que siempre estés en constante comunicación y bien importante que lo menciones cuando estés entrevistando y responda esta pregunta que mencioné al principio, Menciones esto siempre, a los hiring manager les encanta escuchar la palabra colaboración.

I’ve been collaborating with my product manager and product designer to communicate any issues that arise during the development of the feature.

Algo así puedes decir, cuando dices que estás comunicando eso, eso agrada mucho a los entrevistadores. Es algo una palabra clave que tienes también que mencionar.

Como parte de la codificación, también puedes, eh, involucrarte en lo que son las pruebas de integración. Aunque sí he visto en algunas organizaciones que tienen equipos de QA específicamente trabajando en las pruebas de integración, pero en otras organizaciones te toca, como ingeniero senior, la parte de ingeniería le toca también escribir estas pruebas en tu en con herramientas como Cypress o playwright. Hay diferencias, herramientas que puedes utilizar y a partir de allí.

Otra característica es de que normalmente, bueno, dependes de organ la organización, pero tú, como ingeniero senior, también estás a cargo de los deployments, del manejo de release de los feature flags. 

Deployments a diferentes environments cuando vayan a ser, no sé, alguna prueba con tu equipo o que tu product manager quiere ver cómo va el avance. Pues aquí está de loado en en Stalin, etc, etcétera.

Y esto es solo características con respecto al desarrollo de un feature o de una iniciativa. Pero hay otras cosas fuera de esto, como por ejemplo, atender incidentes. Y participaron en rotation-calls, que esto básicamente es cuando sucede algún problema en producción. Entonces esté disponible para ir y ver que es lo que está pasando.

Si puedes ayudar a resolver este problema para que el producto o la aplicación funcione. Esto también sería bueno mencionarlo en una entrevista si lo has hecho. Ah.

¿Cómo saber cuándo ya eres Senior Engineer?

Hace un par de semanas actualicé el diseño de este sitio, decidí usar Next.JS para generar todos los archivos HTML y CSS de manera estática, para luego ponerlos en GitHub pages. Todo mi contenido ahora está en Notion y soy muy feliz escribiendo.

En este tutorial te voy a mostrar como automatizar el deployment, la idea es usar GH Actions para hacer el build y correr los scripts que sacan la información de Notion. Tuve algunos problemas que me gustaría documentar por si le sirven a alguien más.

Lo primero es crear un archivo para el nuevo workflow en tu repositorio, este archivo lo vas a crear dentro del directorio  

, si este directorio no existe lo puedes crear. Puedes nombrar el archivo como 

Dentro de este archivo vas a definir tres secciones, el nombre (

) del workflow, el evento que lo inicializa (

Aquí está la configuración que yo he usado para mi proyecto. Es importante mencionar que los pasos van a variar dependiendo de cada proyecto.

name: Deploy to GitHub Pages
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14.x'
      - name: Install dependencies
        run: npm install

La configuración anterior define un job llamado 

 que se ejecuta en una máquina Ubuntu con la última versión disponible.

Los pasos definidos son secuenciales y lo primero que hace es descargar el código de GitHub haciendo un checkout con git. Luego instala Node.js con la versión indicada, en este caso la versión 14. Por último instala las dependencias del proyecto.

Como ya mencioné antes, toda mi información de este blog está en Notion, por lo tanto cree dos scripts que se conectan al API Rest de Notion y descargan todos los posts publicados, también van descargando las imágenes asociadas a cada post y generando thumbnails para los posts.

Antes de generar el sitio estático con Next.js, necesito descargar la información y guardarla en archivos JSON que voy a usar en el build, para eso simplemente agrego los dos scripts al job que se definió en el paso anterior.

name: Deploy to GitHub Pages
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14.x'
      - name: Install dependencies
        run: npm install
      - name: Download posts
        run: npm run blog
      - name: Download projects
        run: npm run projects

He definido estos scripts dentro del archivo 

 en mi proyecto, por lo tanto puedo usar 

Una vez que ya tengo toda la información en archivos JSON y las imágenes descargadas a la máquina Ubuntu donde estoy haciendo el build, ya puedo pasar al siguiente paso que es generar todos los archivos  HTML y CSS.

name: Deploy to GitHub Pages
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14.x'
      - name: Install dependencies
        run: npm install
      - name: Download posts
        run: npm run blog
      - name: Download projects
        run: npm run projects
      - name: Build
        run: npm run build
      - name: Export
        run: npm run export

Next.JS provee dos comandos para generar sitios estáticos, 

. Así que simplemente agrego estos dos pasos al job y listo.

El último paso es deployar el build a GitHub pages, lo único que tenemos que hacer es agregar este paso a la lista de jobs.

name: Deploy to GitHub Pages
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14.x'
      - name: Install dependencies
        run: npm install
      - name: Download posts
        run: npm run blog
      - name: Download projects
        run: npm run projects
      - name: Build
        run: npm run build
      - name: Export
        run: npm run export
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./out

nos permite acceder al build, generar un nuevo commit y hacer un push al 

 branch, esto hará que el sitio sea actualizado.

Para poder hacer push, es necesario que le demos el token de github, esta es la llave del repositorio y se puede acceder mediante la variable de entorno 

Otra cosa a considerar en esta configuración es el 

, aquí tenemos que indicarle el directorio dónde está el build, en este caso Next.js pone todos los archivos generados dentro del folder 

Dentro del código fuente, accedo a algunas variables de entorno, ahí tengo el Secret Key para el API de Notion, el número de posts por página y otras cosas más.

Las llaves de Notion no las quiero agregar al repositorio, por lo tanto debo usar variables de ambiente. GitHub te provee una manera de definir environments, cada uno puede tener diferentes valores, por ejemplo, podrías tener uno para 

. En mi caso no requiero tener varios ambientes, así que solo voy a definir uno que se llama 

 de tu repositorio, podrás manejar estos ambientes. Una vez que crees tu ambiente, asegúrate de darle acceso al branch 

 para que se puedan usar estos valores en el build.

Aquí puedes definir todos tus llaves secretas en la sección 

, con esto estamos listos para usar estas llaves en nuestro workflow.

Una vez que has definido tus valores secretos, queda solamente agregarlos a la configuración, aquí vamos a usar la propiedad 

 para indicarle el nombre del ambiente que acabamos de crear con nuestros valores secretos.

Con esto el script podrá acceder a estas variables de entorno, pero estas variables realmente las necesitamos en el código fuente, por lo tanto debemos agregarlas al ambiente del build. Para esto usamos la propiedad 

, aquí podemos acceder a los valores secretos y también definir valores de configuración para nuestros proyecto, por ejemplo aquí puse el número de posts por página, información que no es secreta.

El script final quedaría de la siguiente manera.

name: Deploy to GitHub Pages
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment: github-pages
    env:
      NOTION_PK: ${{ secrets.NOTION_PK }}
      NOTION_DB_ID: ${{ secrets.NOTION_DB_ID }}
      NEXT_PUBLIC_GA_MEASUREMENT_ID: "UA-12345-1"
      POST_PER_PAGE: "6"
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '16.x'
      - name: Install dependencies
        run: npm install
      - name: Blog Data
        run: npm run blog
      - name: Projects Data
        run: npm run projects
      - name: Build
        run: npm run build
      - name: Export
        run: npm run export
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./out

¡Eso es todo! Cada vez que hagas un push al repositorio o merge a un PR al branch main, la acción se ejecutará de manera automática, haciendo que tu flujo de trabajo sea mucho más efectivo y automatizado.

, te recomiendo el curso de mi amigo Armando, es un curso bastante completo donde vas a aprender cosas como integrar Stripe para recibir pagos, autenticación y manejo de sesiones, acceso a base de datos y muchas cosas más, en verdad que te lo recomiendo mucho.

Puedes usar mi cupón para tener un 20% de descuento en la compra del curso: 

también puedes dar click en el siguiente link: 

👋 Hola!

Soy Crysfel Villa

Invierte en tí

¡Adquiere mis libros!

Mi contenido

Hablo sobre

Mis Creencias

¿Por que yo?

Estos son mis valores

El Blog

Últimos Artículos

¿Cómo saber cuándo ya eres Senior Engineer?

Como automatizar el deployment de Next.JS en Github Pages

Te ayudo a mejorar al entrevistar, únete a mi lista de correo.

También estoy en Youtube