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: 

Como automatizar el deployment de Next.JS en Github Pages 

Hace unos días, recibí un mensaje privado vía Twitter, y esta persona me comentaba que sentía que manejó mal la situación, cuando el entrevistador le preguntó cuánto quería ganar.En este episodio de código sin fronteras, te voy a decir los cinco errores más comunes al negociar tu salario. 

Antes que nada, me gustaría comentar que los números que vemos en Twitter, ya sabes, salarios de $10,000 mensuales y cosas por el estilo. Es difícil conseguirlo. Se requiere mucha experiencia y claramente no lo harás en tu primer empleo remoto. 

De hecho, en el episodio anterior, hablé al respecto y di algunos consejos que seguramente te ayudarán, pero el FOMO es real. Ves tu salario de $3K o $4K y te agüitas. Esa es la verdad. Pero quiero decirte que todos comenzamos desde abajo.

No te desanimes. Lo importante es que des ese primer paso y consigas ese primer trabajo remoto internacional a partir de ahí vamos. Todo para arriba.

Ahora bien, el primer error que cometemos al negociar nuestro salario es no hablarlo desde el principio. Hablarlo desde el principio, nos evita perder el tiempo tanto a nosotros que vamos a entrevistar como a la empresa o compañía que nos va a entrevistar.

En el 2018 un startup de educación me contactó, con un puesto que tenían para senior engineer. Me pareció bastante interesante, me gustó la plataforma, investigué sobre el producto y decidí entrar al proceso de entrevistas.

Durante la primera llamada con el reclutador. En ningún momento se mencionó acerca de la compensación y realmente yo tampoco pregunté.

Seguido de eso. Me mandaron un proyecto que tenía que hacer en casa. Lo hice, lo envié. Parece que les gustó porque después me agendaron una entrevista técnica, en la cual me entrevistaron, Me hicieron preguntas de mi proyecto además de otras preguntas sobre diseño de sistemas, mi experiencia. 

Después de eso, siguió una entrevista de cultural fit donde hablé con los manager y todo iba excelente hasta que al final me dieron una oferta, que básicamente es una carta donde te dicen todos los beneficios que vas a tener, además de que te dicen tu compensación que te están ofreciendo.

Fue en este momento donde vi que la compensación era bastante baja, inclusive de lo que yo estaba ganando en ese entonces. Inmediatamente les respondí y les comenté cuál era mi expectativa y claramente era mucho más de lo que ellos me estaban ofreciendo. Cuando me respondieron, me dijeron, sabes que esto es lo máximo que te podemos dar. Y sí, le incrementaron como unos $15,000 extra a la primera oferta.

Pero aun así era un poco menos de lo que yo ganaba en ese momento. Y realmente yo le invertí bastante tiempo en hacer el proyecto en entrevistar en prepararme solo para que la oferta no cumpliera con mis expectativas y también la empresa perdió tiempo. Perdió tiempo entrevistándome, valorándome, oponiendo allí un ingeniero a que me me entrevistara. 

Entonces, realmente lo más importante que yo pienso es hablar esto desde el principio. Me he dado cuenta que las empresas en las que vale la pena trabajar te hacen esta pregunta desde la primera llamada. El reclutador siempre te va a preguntar, oye, cuáles son tus expectativas salariales? Y aquí es donde tú debes de indicarlo, aquí también puedes tú preguntar, si no te hacen esa pregunta, si te recomiendo que tú preguntes y digas a cuál es el rango salarial para este puesto. Si no te quieren decir yo lo tomaría como un red flag completamente.

El segundo error, es decir, cuánto ganas actualmente, y es que en Estados Unidos, en ciertos estados, como Nueva York o en California, es ilegal que te hagan esta pregunta. Sé que en otros estados no es ilegal, no está regulado. Pero sí, en varios estados es completamente ilegal y no se deben de realizar ese tipo de preguntas.

Y la razón de esto es porque cuando tú dices un número, la oferta que te den va a estar anclada a ese número. Hay algo en negociaciones que se llama 

 que básicamente consta, y esto sirve para cualquier tipo de negociación, no solamente con estás negociando tu salario, pero cuando vas a comprar algo, el primero que dice un número a partir de ese número es cuando comienzan a ofertarte o cuando comienzan, a querer cobrarte, no? 

Entonces el primero que dice un número es, ese es el número sobre el cual todo va a ser relativo. Ese número psicológicamente. Van a decir no. Pues esto es más caro que lo que me dijo. Entonces no se van a ir, se van a ir más o menos. Entonces, ése es una de las razones por la que jamás debes decir cuánto estás ganando actualmente. 

Además de que no es obligatorio decirlo y bueno, la diferencia salarial. Comparado con Estados Unidos y América latina es brutal. Entonces realmente no te conviene. Si te la llegan a preguntar, tú simplemente puedes negarte a decirla de una manera educada. Puedes decir: sabes que, este momento no me gustaría compartir esa información. En este momento, no creo que sea necesario. Ellos realmente no, no te van a decir nada más.

Y si te comienzan a presionar, no es el lugar donde debes estar. Yo lo tomaría también como un red flag y preferir no continuar en ese proceso de entrevistas de la misma manera. Si no me dicen cuál es el rango, no yo la verdad preferia no continuar. 

El tercer error que podemos cometer es no investigar los salarios promedios en esa. Para investigar cuál es el promedio que pagan empresa empresa? Existen diferentes plataformas, diferentes comunidades que puedes ir y hacer esta investigación. Hay sitios uno se llama g grandor, que es bastante bastante popular, pero hay otros. Se llama level ello y hay varios sitios.

En estos sitios. Tú puedes ver información acerca de la empresa que tan difíciles son las entrevistas. Cómo es el proceso de entrevistas? Inclusive algunas personas ponen allí algunos ejemplos de preguntas que te hacen, eh, durante la entrevista y muy importante en estos en estos sitios también puedes ver.

Las compensaciones promedio de diferentes puestos. Entonces, con eso, te vas a dar una idea de cuánto es que estas empresas pagan. Y con eso puedes tú, ya sea definir un número antes de la entrevista, dices algo que recomiendo. Siempre tienes que tener bien, claro cuánto quieres ganar. Y esto lo vas a sacar basado en la investigación que vas a hacer, así como en tus necesidades.

Otra cosa que importante a considerar es que el salario es un número anual , el número que tienes que dar es un número anual, no va a ser un número mensual. Y este número claramente es antes impuestos.

Y aquí recuerdo que la primera vez que entrevisté a una empresa en silicon valle, estaba hablando con el entrevistador y llegamos a este punto donde me preguntó y cuál es tu expectativa salarial. Y en ese momento, yo no me había preparado en lo absoluto. Y me quedé así inmediatamente comencé a pensar, mi primer pensamiento fue actualmente estoy ganando más o menos como $30 la hora.

Quizás yo pienso que unos $50 la hora estaré bien. Entonces yo dije tímidamente todavía como que dudándolo le dije $50 la hora. Mi inglés no era el mejor, así que no me entendió del todo bien. Y me dijo $50,000. Yo me quedé $50,000 y fue algo bastante frustrante en ese momento porque tanto el entrevistador como yo nos quedamos así como en un silencio awkward y fue, fue difícil, no?

Entonces, a partir de ya aprendí que el salario es, un número anual. Y antes de impuestos. Entonces, bien importante que tengas en mente ese número que tú vas a decir. Si te llegan a preguntar esto, y si no te lo preguntan tú tienes que preguntar sobre el rango. De esta manera, vas a estar seguro a la hora de responder. Eso es lo más importante, transmitir esa seguridad y esa confianza a la hora de estar entrevista. 

El siguiente error que cometemos muchas veces es tener miedo de pedir lo que quieres. Y el miedo es algo super real. Sentimos que vamos a perder esa oportunidad. A veces también tenemos miedo de que vamos a ser percibidos como avaros o que somos, estamos siendo mercenarios.

Entonces este miedo es real y es bastante válido real. De hecho, tengo amigos con los que somos muy abiertos y compartimos nu con nuestras nuestros salarios y hablamos de finanzas, inversiones, etc, etc. Y un amigo en particular, recuerdo que ya varias veces cuando está en su trabajo, me comenta, oye, estoy ganando tanto, eh?

Pero quisiera ganar más. Pero ya ya me comprometí. Ya acepté la oferta. Recuerdo que en esa ocasión yo le comenté, sabes qué? O sea, Igual, no pierdes nada con con pedir más. Dile que sabes que este realmente me gustaría ganar tanto y sé bien honesto, dile me sentí un poco intimidado cuando dije este número, pero realmente este es lo que quiero si se puede estar bien, sino bueno, ya acordamos. Ya acordamos algo y. Días después lo hizo y ya después me contacté y me dijo sabes qué? Si me dieron más el dinero extra que pedí, y es que tampoco estaban pidiendo un montón más, estaban pidiendo que te diga unos $15,000 extra que realmente si vives en en México, es una gran diferencia, no?

Pero aquí en estados unidos, no te diría que guau, es una gran gran diferencia. Entonces, lo importante aquí es no tener miedo por pedir y recordar que esto es una transa. Okey, tú estás dando algo a cambio y ellos también la empresa también. Entonces es algo que ambos deben estar contentos y deben estar de acuerdo. Entonces, aquí lo importante es no tener no tener miedo.

Y el último error que he visto también es no negociar la oferta. Y es que cuando te dan una oferta, ya te dan una carta con un. Aqui es donde este es el momento para negociar. Este es el momento donde tú puedes pedir ms y est. Bien, no se ve mal. Eso es algo muy común que yo lo he visto varias veces

y aquí como aire manager, a mí me ha tocado entrevistar a varias personas y también me ha tocado estar donde le mandamos la carta de eh de la oferta. Y como hay manager, te voy a decir algo cuando mandamos una propuesta, es porque queremos a esa persona en nuestro equipo.

Ya invertimos tiempo ya invertimos esfuerzo. Eh es bastante costoso entrevistar a candidatos porque no entrevistas uno, entrevistas varios. Entonces, cuando tú escoges ya a un candidato sobre todos los que entrevistaste, es porque ya lo decidiste en equipo evaluaste y te das cuenta que este este es el mejor candidato que se adapta al puesto que tú estás ofreciendo.

Por lo tanto, El candidato también tiene cierto liege se le llama? No. Entonces este es el memento donde el candidato puedes, sabes qué? me gusta tu oferta, pero realmente yo estoy esperando esto más y decir algo no sin miedo y con seguridad, no pasa absolutamente nada. Y otra cosa que te voy a decir, como he manager normalmente siempre hay cierto a margen para negocia.

Sí. Si, por ejemplo, se te da una oferta por $100,000, siempre hay como unos cinco o $10,000 extra que se te pueden dar en caso de que tú este de de que tú quieras negociar siempre es algo es algo normal. Entonces, es importante que tú como candidato lo sepas para que este dispuesto a negociar y por pedir no pasa nada si te lo dan perfecto, sino digo igual, está bien, no?

Al final del día, tú vas a decidir. Basado en si el lo que te están ofreciendo a ti te conviene o no.

Y por último, aquí también quiero mencionar algo como hay manager. Ah, cuando tomas una oferta, tú también uno se pone nervioso, no de que, ay, ojalá y me vaya a aceptar ese candidato la oferta porque ya le invertí tiempo ya. Ah, realmente nos guste ese candidato. Por eso le estamos mal la oferta. Y resulta que los candidatos también están entrevistando a varios lugares.

Entonces, no sabes si va a aceptar tu oferta o aceptar la de alguien más. Entonces aquí tú también te esfuerzas para ofrecerle algo. Lo que el candidato quiere.

Así que ya lo sabes la próxima vez que vayas a entrevistar, acuérdate de estos cinco errores que se cometen. Yo he cometido varios de estos a lo largo de mi carrera y bueno, aquí.

Quiero compartirlos contigo para que no te pasen y para que puedas mejorar y para que te puedas superar y puedas obtener ese trabajo remoto que te va a cambiar la vida. Pues eso es todo por el día de hoy. Mi nombre es Crysfel Villa, esto es código sin fronteras, y nos vemos hasta la próxima.

5 Errores comunes al negociar tu salario

Esta pregunta me la han hecho varias veces vía Twitter. Y la verdad es que sí, es bastante difícil conseguir ese trabajo remoto que paga $10,000 al mes. Pero la buena noticia es que no es imposible y bueno, hay que trabajar.

Hay que practicar y sobre todo, hay que poner ese esfuerzo para pasar. Ese proceso de entrevistas que varias empresas tienen en estados unidos. Y también hay que tener un poco de suerte porque la verdad es que yo sí creo en la suerte, pero también creo que uno debe estar bien preparado para poder capitalizar esas oportunidades que la vida te va a dar, porque si no tienes la experiencia o si no tienes, las herramientas necesarias para tomar esas oportunidades, simplemente no las vas a poder aprovechar.

Ahora bien, entrevistar es un skill que se debe practicar para mejorar como cualquier otro habilidad que tienes. Si no sé si la practicas una y otra vez, te vas a volver mejor. Ahora bien, si nunca la lo has hecho, si nunca la has practicado, pues vas a ser mal o no, no, no vas a lograr a dar esa buena. No vas a poder comunicar bien, no vas a poder, eh, eh, pasar todo ese proceso de entrevistas.

Por lo tanto, hay que practicar para poder mejorar. Y ahora te voy a dar algunos consejos que puedes seguir para mejorar en estabilidad de entrevistar y que puedas pasar satisfactoriamente todo el proceso de en.

Lo primero que te voy a recomendar es que escribas, tomes un lápiz y papel, o si quieres hacerlo en la computadora también está bien, pero escribe los highlight de tu carrera, okey, con high me refiero a todos tus proyectos más importantes, no todos y cada uno de ellos, pero sí los más importantes que que lo recuerdes.

Escribe los puestos en que has tenido si tienes un log, si has escrito en algún e o libros. Perdón si has escrito algún bloc libros, no si has escrito algún Ebro o quizás algún libro, especialmente también si tienes algún canal de tour y. No sé cualquier cosa que sea ah importante que tú creas que relevante para el puesto que estás aplicando.

Escríbelos, es lo primero que tienes que hacer, porque escribir te permite ordenar tus ideas y al ordenarlas, vas a comunicarlas de una mejor manera. Esto va a permitirte que seas más elocuente al comunicar todas estas ideas que tienes todos. Al final del día, hay que hay que comunicar para convencer al entrevistador de que tú eres el candidato ideal de que tú eres la persona que necesitan para ese puesto que están entrevistando.

Otra cosa que tienes que hacer es seleccionar un proyecto complicado, un proyecto difícil que hayas tenido. Qué fue lo que se complicó de ese proyecto? Quienes estuvieron involucrados esto especialmente para la colaboración, eh? La colaboración es muy, muy importante cuando uno hace software, entonces tienes que, eh, función.

Quiénes con quién estuviste? Colorando quiénes estuvieron involucrados? Qué decisiones se tomaron? ¿Quién las tomó? ¿Por qué se tomaron? ¿Cuáles fueron los argumentos? Y bueno, cuáles fueron los resultados de esas decisiones? No importa realmente si fueron buenos resultados o malos resultados. Lo que importa aquí es ¿cómo navegaste tú esa situación? ¿Y cómo es que se fue dando siguiente? 

Siguiente, Tienes que preparar un ejemplo de un conflicto. ¿Por qué se dio este conflicto? ¿Quiénes estuvieron involucrados? ¿Cómo se resolvió? Qué aprendiste de esta situación? ¿Cuáles fueron los argumentos? Lo importante aquí es, ah. Que tú expliques que comuniques cómo lidias con los conflictos dentro de de tu equipo.

Y es que a final día trabajamos con personas, trabajamos en un equipo, no hacemos software de manera sola. Trabajamos en equipo, colaboramos y siempre hay conflictos. Alguien tiene que ceder. Alguien tiene que sacrificar algo, no? Lo que se busca en un candidato es de que, eh, sepa lidiar con conflictos. 

Al final día, de todos queremos trabajar con gente, que es lo suficientemente madura emocionalmente para lidiar con los conflictos de una manera saludable.

Una vez que tienes escrito toda esta información, te recomiendo que lo leas en voz alta, no necesariamente leyendo. Porque no te vas a aprender esto palabra por palabra, pero sí, vas a usar lo que escribiste para que puedas comunicarlo de una mejor manera.

Entonces te recomiendo que lo comiences a decir en voz alta. No lo repita. Palabra por palabra. Pero este también puedes utilizar un espejo para que te veas y veas los gestos que haces. El caso aquí es practicar, practicar, practicar que tú te sientas cómodo explicando que tú te sientas ah, satisfecho con la información que estás transmitiendo.

Ahora bien. Lo que quieres aquí es sonar lo más natural posible. No, no quieres estar leyendo algo o que no quieres sonar como que te memorizaste todo tu escript, quieres sonar lo más natural posible. Por eso es que te digo que no vas a ir leyendo palabra por palabra ni memorizar. Tienes que sonar lo más natural posible para que también eso te va a dar confianza. También te va a dar bastante confianza. 

Y esto es lo que se hace cuando uno va a hablar en público. Me ha tocado participar en varias conferencias, eh, mi y lo que lo que se tiene que hacer antes de pararte en una plataforma. Es tú varias veces, varias horas antes. Tú estuviste practicando. Tu estuviste repitiendo todo, toda la información que quieres transmitir.

Y esto es exactamente lo que tú tienes que hacer también practicar, para sentirte más cómodo, para sentirte confiado. Por último, te recomiendo grabarte con tu celular o con la computadora. En serio que cuando te grabas, te pones muy, muy nervioso la primera vez. Entonces esto te va a ayudar a que te vuelvas más cómodo grabándote con tu celular puede ser, no tiene que ser nada profesional.

Pero sí te va a servir para analizar el vídeo. Vas a poder reproducir el vídeo una vez que termines de grabarte y vas a poder allí, ver errores que estás cometiendo quizás a muletillas que estás usando mucho. O quizás, eh, está repitiendo palabras una y otra vez, eh? Eso te va a ayudar a mejorar. Y para que te puedas auto evaluar.

Adicionalmente, si puedes hacerlo, te recomendaría también que le pidas ayuda a un amigo para que te escuche, para que te haga preguntas, para que te dé feedback también. Esto te va a a servir un montón y especialmente cuando estás enfrente de una persona, es es bastante más diferente y definitivamente te va a ayudar en esa prepararte para tu entrevista.

Pues es todo amigos por el día de hoy. Este, eh, de verdad? Como les decía, ah, esto requiere práctica. Es difícil. Sí, como te decía al principio, pero no es imposible, tú puedes, no te desanimes, eh? Recuerdo que a mí la primera vez me tomó algo de tiempo. La primera primera, primera vez que entrevisté una, una empresa en Silicon Valley me rechazaron vilmente y es algo que hay que.

Hay que trabajar, eh? A finales del día, vas a recibir varios varios rechazos y eso está bien porque así es como uno aprende, pero si te recomiendo que practiques para mejorar, para que puedas lograr ese salario de $10K dólares que definitivamente te va a cambiar la vida, especialmente si vives en Latinoamérica.

En serio que te va a cambiar la vida. Y bueno, eso es todo por hoy. Nos vemos hasta la próxima.

¿Qué tan difícil es conseguir un trabajo remoto en Tech para una empresa en USA?

Hola, mi nombre es Crysfel Villa y el día de hoy comienzo con este proyecto donde quiero darle consejos a mi yo de hace 10 años para compartir mis aprendizajes a lo largo de mi carrera profesional, y de esa manera también, quizás ustedes puedan tomar algunos consejos qué les ayuden a superarse en su carrera profesional como individual contributor (IC) en la industria de tecnología.

Quiero ayudarte a encontrar un trabajo remoto en estados unidos para que puedas mejorar tu salario. Esto lo voy a hacer dándote consejos para que puedas hacer entrevistas técnicas en estados unidos de una manera efectiva. 

Compartiendo las preguntas que normalmente se suelen hacer en entrevistas técnicas también, en entrevistas de cultural fit y bueno, a través de todo el proceso de entrevistas que se requiere para que puedas conseguir ese trabajo que tanto quieres en Estados Unidos.

Durante los últimos cinco años, he trabajado en empresas de producto donde me ha tocado participar en los procesos de entrevista para diferentes candidatos en los roles que tenemos abiertos en estas empresas. Durante este tiempo, he podido realizar entrevistas a candidatos. Por lo tanto, me gustaría compartir esas experiencias, que es lo que suele funcionar, cuáles son las respuestas que generan una mejor impresión de estos candidatos y como tú las puedes utilizar para que puedas tener éxito en este proceso de entrevistas. 

También te voy a dar algunos consejos para mejorar tu carrera y contar algunas historias sobre mi experiencia e historias de éxito, pero también historias de terror que han pasado en algunos proyectos. 

Asimismo, voy a entrevistar otros ingenieros que actualmente están trabajando desde Latinoamérica para empresas en estados unidos de manera remota, para que también podamos aprender de parte de sus experiencias y coger también algunos consejos y tips que nos pueden servir.

Pero seguramente te estás preguntando ¿y quién eres tu? ¿Por qué debería escucharte? Bueno, actualmente soy Engineering Manager, pero he trabajado como Tech Lead y Senior Engineer. De hecho, inicié mi carrera allá por el 2007, esos son ya 16 años de experiencia que tengo. Si suena bastante, la verdad es que sí, son bastantes.

Y durante ese tiempo, principalmente me enfocado en el frontend. Dirigí proyectos específicamente en el frontend, pero también, de hecho inicié mi carrera como Backend Engineer, he hecho fullstack. Y bueno, me apasiona el desarrollo de productos no solamente a nivel técnico, pero también a nivel producto y e inclusive a nivel diseño. Entonces me ha tocado colaborar con Product Manages y Product Designers, si es algo que disfruto mucho hacer, es algo que, provee valor a los usuarios, no. 

Entonces también tengo varios, proyectos personales en los cuales me toca trabajar. Y ahí sí, me toca hacer de todo, product, design y bueno, también la parte técnica, porque, bueno, yo soy responsable de absolutamente de todo.

He trabajado de manera remota desde el que dejé mi trabajo y comencé a hacer freelance en el 2010, fue que comencé a tener clientes de Estados Unidos, Europa. Y bueno, esto me ha llevado a publicar contenido, he publicado dos libros técnicos, uno de JavaScript con un que se llama Ext JS allá por el 2013, y también tengo otro libro que escribí sobre React Native en el me parece.

Me gusta mucho compartir mis aprendizajes y mi experiencias. Por eso que estoy iniciando también este este nuevo proyecto.

Por último, me gustaría decir que me identifico como un mentor. De hecho, fundé una plataforma Open Source llamada coding coach que actualmente está allí. Sigue creciendo. Esta plataforma es interesante, como conocí gente en Twitter y iniciamos este proyecto y ahí hice muy buenas relaciones con con gente alrededor del mundo, gente en Europa, gente en Estados Unidos y bueno, en algún memento, voy a a hablar en un episodio al respecto.

Y bueno, compartir mis aprendizajes. Y no te olvides seguirme en Twitter para que podamos conversar. Ah, me puedes encontrar crysfel. Así es mi nombre y bueno, nos vemos entonces.

Código sin Fronteras: Introducción

Esta es una pregunta bastante común en entrevistas técnicas, su objetivo es identificar si tienes experiencia colaborando con Producto y Diseño, el día de hoy te ayudo a responderla de la mejora manera.

Durante la entrevista técnica es muy probable que te pregunten algo como lo siguiente, la pregunta puede variar un poco pero el concepto es el mismo:

Can you give an example where you had to balance technical, design, and business constraints? What decisions did you make and why?

Si cuentas con la suficiente experiencia, seguro que en alguna ocasión has estado en esta situación. Ya sabes, proyectos con tiempo limitado, requerimientos no muy claros o diseños complicados que tomarán más tiempo de lo que se tiene planeado.

Por lo tanto, al responder esta pregunta estás demostrando que cuentas con esa experiencia, así que prepara un ejemplo antes de la entrevista para que no te tomen desprevenido.

En mi caso, en una ocasión me toco trabajar en un proyecto donde habíamos estimado liberar a producción en X cantidad de semanas, pero cuando comencé a trabajar en ese proyecto, me encontré con dependencias de otros equipos, una API no regresaba la información que necesitaba.

La colaboración es super importante al desarrollar software, asegúrate que en tu respuesta menciones un ejemplo de que estás en constante comunicación con tu Product Manager así como otros stake holders.

Lo importante al responder esta pregunta es comentar cómo comunicaste estos problemas, que fue lo que se decidió y porque. ¿Se extendió el tiempo de entrega? ¿Se quitaron algunos requerimientos? No importa cuál fue el resultado, lo importante aquí es demostrar el nivel de colaboración que has tenido, especialmente si estás aplicando para un puesto Senior, ya que en estos puestos se requiere más colaboración y liderazgo.

Siguiendo con mi ejemplo, lo primero que hice en esa ocasión fue contactar al equipo responsable de la API para preguntar si era posible que ellos agregaran la información que necesitaba, como es de esperarse no era su principal prioridad y me comentaron que podrían hacerlo, pero un par de semanas después.

Inmediatamente se lo comuniqué a mi Product Manager así como al Engineering Manager, para discutir posibles alternativas.

Es muy importante que tanto Producto, Diseño e Ingeniería estén alineados en los objetivos, así que es muy común que alguien tenga que ceder en algo. Esto lleva a que naturalmente, existan conflictos en tu equipo.

Cuando respondas esta pregunta, asegúrate de demostrar como navegaste estas situaciones, ¿quién tuvo que ceder? y ¿cuáles fueron los argumentos?.

Otra cosa a considerar, es que en la cultura de Estados Unidos, (por lo menos en empresas donde vale la pena trabajar) se valora que las ideas se contradigan, que se busquen mejores alternativas, que haya desacuerdos saludables donde se pueda discutir diferentes puntos de vista. De hecho, en algunos casos se asigna el rol de 

 a una persona, su único objetivo es buscar fallas a la idea o solución, buscarle peros y tratar de encontrar problemas.

Siguiendo con mi ejemplo, propuse que yo podría hacer el cambio en la API del otro equipo, dejando claro que ese repositorio era nuevo para mi y que muy posiblemente agregaría algunos días más de lo planeado. También mencioné que podría impactar nuestra estimación inicial, pero la verdad no estaba del todo seguro ya que es difícil estimar sobre algo desconocido.

Otro aspecto a evaluar es tu habilidad para tomar decisiones, entre más Senior, más ejemplos vas a tener de alguna decisión tomada. Asegúrate de comentar las decisiones que se tomaron para resolver el conflicto.

Siguiendo con mi ejemplo, en esa ocasión se decidió que yo actualizaría la API del otro equipo, además se consideró que la fecha de entrega podría ser movida una semana extra.

Finalmente menciona cuales fueron los resultados de las decisiones tomadas, no tienen que ser buenos o malos resultados, lo importante aquí es demostrar que te has tomado el tiempo para analizar y reflexionar en tus decisiones tomadas.

También asegúrate de responder porque crees que esa fue una buena o mala decisión y tus aprendizajes de esa experiencia.

En mi ejemplo diría que lo importante aquí fue comunicar inmediatamente el problema encontrado para poder discutir una solución donde todos estuvimos de acuerdo. A final del día el proyecto salió a producción satisfactoriamente.

El Blog

Últimas publicaciones

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

Como automatizar el deployment de Next.JS en Github Pages

5 Errores comunes al negociar tu salario

¿Qué tan difícil es conseguir un trabajo remoto en Tech para una empresa en USA?

Código sin Fronteras: Introducción

¿Puedes darme un ejemplo donde tuviste que lidiar con limitantes técnicas, de diseño o negocio?

Conecta conmigo!

Tags

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

También estoy en Youtube