La IA generativa requiere muchos recursos y un equipo potente. Necesitas comprar tarjetas Nvidia para poder ejecutar con éxito Stable Diffusion u otro modelo. Si eres como yo, puedes buscar soluciones accesibles como AWS. En este tutorial, te voy a mostrar cómo instalar ComfyUI + Flux para generar imágenes increíbles en Ubuntu.

Lo primero que necesitas hacer es iniciar sesión en la consola de Amazon AWS. En la barra de búsqueda superior, escribe 

 y selecciona la primera opción en los resultados. Verás algo como esto:

A continuación, debes hacer clic en el botón naranja 

 para configurar el hardware que necesitamos para ejecutar Flux y generar imágenes.

Completa el formulario con los siguientes valores:

: Selecciona una clave existente o crea una nueva, asegúrate de guardar la nueva clave en un lugar seguro, ya que la usaremos más tarde para conectarnos a la instancia.

Todos los demás valores pueden configurarse con los valores predeterminados. Una vez que termines, haz clic en el botón amarillento 

Después de recibir un mensaje de éxito, vuelve a la lista de instancias, haz clic en la nueva instancia y verás la 

 en la columna central. Copia esta IP ya que la utilizaremos para conectarnos vía SSH.

Abre tu terminal favorita o un cliente SSH y conéctate a la instancia que acabamos de crear. Podemos hacerlo ejecutando el siguiente comando.

$ ssh -i ~/.ssh/[YOUR-KEY-FILE-NAME].cer ubuntu@[YOUR-API_ADDRESS]

Asegúrate de establecer el certificado correcto, de lo contrario, no te autenticarás correctamente. Después de iniciar sesión, deberíamos actualizar nuestro sistema ejecutando los siguientes comandos:

A continuación, necesitamos instalar el controlador NVidia para poder usar las GPUs. He probado otras AMIs que incluían los drivers y todo estaba instalado, pero hubo varios errores al instalar los modelos. Me di cuenta que es más fácil instalar manualmente los controladores y todo lo que necesitamos; toma un poco más de tiempo, pero menos errores. Simplemente ejecuta el siguiente comando:

Luego necesitamos Python, primero debemos agregar el repositorio donde se encuentra la distribución oficial y luego instalar el paquete usando apt:

$ sudo add-apt-repository ppa:deadsnakes/ppa
$ sudo apt install python3.10

Es importante establecer el Python predeterminado al ejecutar comandos 

 en la terminal, así que vamos a crear el alias a continuación:

$ sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.10 2

Para verificar si todo está instalado, podemos imprimir la versión de Python:

AUTOMATIC1111 requiere ejecutar entornos virtuales, por lo tanto, necesitamos instalar 

¡Hemos terminado con las dependecias! Todo lo que necesitamos hacer es reiniciar la instancia y deberíamos poder usar las GPUs NVidia para ejecutar los modelos. Abre la consola de AWS, selecciona la instancia y haz clic en la opción 

Vuelve a iniciar sesión en tu instancia y clona el repositorio de stable diffusion web ui.

$ git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui

 para habilitar la conexión a A1111 desde cualquier computadora, usar el flash attention más rápido cuando utilices modelos y permitir que instalar extensiones cuando te conectes de forma remota.

$ cd stable-diffusion-webui
$ vim nano webui-user.sh

En este archivo, necesitamos encontrar la línea donde se define 

, descomentar la línea y establecer el siguiente valor.

export COMMANDLINE_ARGS="--listen --opt-sdp-attention --enable-insecure-extension-access"

El último paso es instalar y ejecutar A1111, lo hacemos ejecutando el siguiente comando:

, ahora necesitamos abrir ese puerto en nuestra instancia para poder abrirlo en nuestro navegador.

Ve a la consola de AWS y haz clic en la instancia, luego en la pestaña 

. Esto evitará que otras personas usen tus modelos. Si tu IP cambia, tendrás que volver aquí y nuevamente agregar tu nueva IP.

Después de guardar, deberías poder abrir A1111 en tu navegador favorito. Simplemente escribe la IP de tu instancia seguida del puerto, por ejemplo: 

Si todo salió bien, deberías poder ver la consola de A1111. ¡Adelante y pruébalo! Deberías ver algo como esto:

Como puedes ver, las imágenes generadas no se ven muy bien. ¡Necesitamos instalar Flux! Pero antes de eso, vamos a instalar ConfyUI, una herramienta con una mejor interfaz que crea flujos para generar imágenes.

Vuelve a la carpeta de inicio y clona el proyecto ComfyUI desde GitHub.

$ cd ~
$ git clone https://github.com/comfyanonymous/ComfyUI

Ahora vamos a compartir modelos con A1111 duplicando el archivo 

 y estableciendo la ruta a los modelos en A1111. Esto lo hacemos para no descargar los modelos dos veces, es mejor tenerlos compartidos y así ahorramos espacio en el disco duro.

$ cd ComfyUI
$ cp extra_model_paths.yaml.example extra_model_paths.yaml
$ vim extra_model_paths.yaml

Dentro de este archivo, necesitamos localizar la línea donde se define el 

base_path: /home/ubuntu/stable-diffusion-webui

Finalmente, ejecuta ComfyUI con este comando:

Instalar ComfyUI para generar imágenes con Flux

Las primeras entrevistas de trabajo siempre son las peores, especialmente si son en un idioma que no dominas al 100%, como es el caso del inglés. 

Hace unos años, en el 2016 para ser exacto, entrevisté para un puesto de senior en un startup en Nueva York. Es una empresa bastante popular en la comunidad Tech, porque hacen cursos de programación y tiene un producto bastante interesantes, bastante bueno para enseñar a programar.

El día de hoy, les voy a contar mi experiencia al entrevistar en este lugar. Qué salió mal y qué cambiaría para poder pasarla esta vez?

Bienvenidos a código sin fronteras, mi nombre es Crysfel Villa y en este podcast le doy consejos a mi yo de hace 10 años para poder conseguir ese trabajo remoto en empresas en Estados Unidos, así como para mejorar en mi carrera profesional en la industria de tecnología.

Todo empezó cuando recibí un email por parte del reclutador de esta compañía donde me comentaba sobre la misión de esta empresa. Además, me parecía bastante interesante y pedí más detalles del perfil que buscaban. 

Al responderme, me comentó sobre el perfil y las tecnologías que estaban requiriendo, así como también un poco acerca del proyecto que estaban iniciando y al cual yo iba a estar trabajando. Y lo más importante que mencionó fue el rango del salario, razón principal por la cual decidí entrar al proceso de entrevistas.

La primera llamada con el reclutador, me preguntó mis expectativas económicas. Algo sobre mi experiencia y me pidió mi currículum para mandárselo al hiring manager, hasta aquí todo bien. 

Me agendó una entrevista con el hiring manager, la cual fue una entrevista de cultural fit. Aquí hablamos sobre mi carrera. Le llamó mucho la atención, en mi caso particular, que yo he publicado contenido desde hace un montón de años.

En ese momento ya tenía un libro publicado, así como mi blog, mi canal de Youtube y recuerdo que durante la entrevista me pidió links hacia mi contenido que tenía publicado, supongo que para validar que fuera cierto o quizás simplemente por curiosidad.

Ahora que lo pienso mejor, pudo haber sido también, porque como les comentaba, esta empresa se dedica a hacer contenido tech como tutoriales, por lo tanto. Tiene sentido que me haya pedido, links a mi contenido, para conocerme un poco mejor y ver que también quizás, yo hacía ese contenido. No lo sé.

Considero que me fue bien en esta llamada, ya que decidieron mandarme al siguiente paso en la entrevista, la cual fue agendada unos días después. Y esta era una entrevista técnica sobre diseños de sistemas.

Cuando inició la entrevista, recuerdo que una de las primeras cosas, después de presentarme, fue que yo le pedí, le dije:

¿Sabes qué? Me gustaría tomar unos 10 minutos al final de la entrevista para hacer preguntas. 

Y fue bien interesante porque este el entrevistador me dijo pues puedes hacer las de una vez. Vamos a comenzar con las preguntas que tienes. Me interesa saber cuáles son esas preguntas. Y yo así de… okay…

Comencé a preguntarle, yo ya tenía preparada ciertas preguntas, de cómo trabajan, tratando de identificar ciertas red flags y conocer más que el proceso. También me interesaba conocer la cultura de la empresa. Así que pues le hice varias preguntas así, pero recuerdo que fueron así bien chafas mis preguntas, porque una de ellas recuerdo claramente que le pregunté:

¿Qué es lo que te motiva ir a trabajar a de este lugar?

O sea así bien, chafa a mi pregunta. Pero bueno, luego que hice varias de estas preguntas, hablamos sobre mi experiencia también.

Aquí, la verdad es que yo no había seguido ninguno de los consejos que ya di anteriormente en este podcast. Uno de ellos es preparar tu 

 y una descripción de quién eres. No había hecho nada de eso. Así que bueno, allí al vapor, básicamente comencé a describir quién era.

Y el consejo que yo te daría aquí es el mismo que he venido dando desde un principio. Es de que prepares un script para ser consistente con toda la gente que te va a estar entrevistando y que todos tengan una idea común de quién eres y que eres el candidato ideal para ese puesto.

Luego de todas las preguntas que yo hice y de hablar un poco de mi carrera, ya había pasado bastante tiempo aquí, quizás unos 30 minutos cuando, después, el entrevistador me dijo, bueno pues vamos a pasar a lo que son las pruebas técnicas de algoritmos. 

Y fue algo sencillo, recuerdo que usamos Google Docs para esto, me mandó a un link y fueron cosa sencilla, realmente estos algoritmos. Recuerdo que sí, logré resolver algunos, no todos. Pero como les comentaba, como al principio de la entrevista, yo hice pontón de preguntas. Y así, entonces no me dio tiempo terminar todos los problemas y sentí que me fue medio mal la verdad. No me sentí muy confiado, y dije bueno, pues lo intenté.

Esto estaba pasando más o menos a finales de noviembre, por lo tanto, en Estados Unidos, estos días son de holiday, que viene siendo el Thanks Giving. Por lo tanto, pues varias personas fueron de vacaciones en esta empresa, y por tres semanas estuve esperando. 

Yo pensé que ya me había ghosteado, pensé que ya me habían dejado ahí volando y que, bueno, pues ya ni modo, ni un gracias por participar me habían mandado este punto. Pero resulta que el reclutador luego de tres semanas, me mandó un e-mail y me comentó: una disculpa, pero mucha gente está de vacaciones por el Thanks Giving.

Pero me dijeron que iba a continuar en el siguiente paso, que era otra entrevista técnica con otro ingeniero que me iba a estar entrevistando. Para esta entrevista, usamos un editor online que se llama 

Este es un editor que normalmente se usa para entrevistas técnicas. Así que consejo, si van a comenzar a entrevistar, entra en creer una cuenta familiaricen con la interface, porque la verdad, esa vez fue la primera vez para mí, no tenía ni idea cómo funcionaba. No sabía dónde había nada de la UI. Entonces, como fue algo nuevo para mí, no me preparé. Bueno, eso le agregó un poco de presión, también poco de incertidumbre.

Y aquí recuerdo que el problema que me pidieron hacer fue una pequeña aplicación de el tit-tac-toe, en español es el juego del gato, no sé cómo le llamen en en otros países de Sudamérica, pero en México se llama el juego del gato, que básicamente es una grilla, son dos líneas horizontales y dos verticales. Y entonces tú tienes que poner una tacha o un círculo, y hacer una línea y ganas.

Me pidieron hacer algo como eso, también me pidieron que hablara en voz alta para que ellos pudieran escuchar mi proceso como estaba pensando. Y aquí me fue… bueno… comencé yo a escribir, comencé a pensar en voz alta.

Comencé a más o menos tirar ideas y comencé a codificar. Ya tenía una idea más o menos clara cómo resolverlo. Comencé a codificar pero cuando comencé a escribir código. recuerdo que ese punto mi inglés todavía no era el mejor. Entonces había palabras que todavía no, no las tenía bien impregnadas, como decir punto y coma o decir dos puntos o la diagonal cómo se dice en inglés y se me olvidó con la presión, no sabía.

Entonces comencé como que a mezclar un poquito de español allí. Así 

. Puntito lo decía en inglés, pero decía pon en español o cosas así. Y eso me puso extremadamente nervioso porque me estaba enfocando un montón en ¿Cómo se dice esto en inglés? Oh, rayos, no puede ser.

Y esto me comenzó a meter mucha presión porque no solo tenía que concentrarme en el problema técnico que tenía que resolver, sino también en la parte del inglés entonces me comencé también a concentrar en eso, y eso me puso en desventaja. Y es algo que deben ustedes también estar conscientes, los pone también en desventaja si no dominan el inglés. Contra un nativo. 

Sí, claro que nos ponen desventaja, además de que nos quita la concentración del problema en sí que tenemos que resolver, porque ahora no solo no estamos enfocando en la parte técnica, en la parte de la codificación y algoritmo, sino también en la parte del idioma. Nos comenzamos a enfocar en la gramática. Y si estamos diciendo cosas coherentes, entonces esto me agregó mucha, mucha presión, mucho, mucho nerviosismo.

Recuerdo que comencé a sudar, la voz se me comenzó a hacer así un poco a temblar, quizás. Y el entrevistador, supongo que se dio cuenta y comenzó a ayudarme y comenzó a darme ideas de oye, qué te parece si lo haces así? Entonces esto todavía me comenzó a agregar más presión porque digo: rayos!, o sea, estoy en el punto donde ya estoy tocando pared y el entrevistador me está ayudando.

Entonces esto me metió aún más presión. Me metió aún más nerviosismo, al punto donde sentí tanta presión ¡que me bloquié! ¡me bloquié completamente!. Y recuerdo que claramente, recuerdo que estaba escribiendo un `for`, ya sabes, el 

, Luego la condición, el incremento se me olvidó. ¡Se me olvidó hacer eso! ¿Puedes creerlo?

Estaba aplicando para un puesto de senior engineer y se me olvida cómo se escribe un for en JavaScript. are you serious? Creo que esa ha sido la peor entrevista que he tenido. A ese punto, ya estaba completamente bloqueado. Ya no sabía qué hacer. Ya quería que terminara. Todavía recuerdo que al final le dije sabes qué? Sentí mucha presión. Lo siento por hacerte perder el tiempo. Me comencé a disculpar y fue algo algo muy, muy frustrante. 

Me dio mucho coraje conmigo mismo. Y bueno, fue algo que salió todo, fue una muy mala experiencia y obviamente me agüité, obviamente no terminé el programa. No solucione el problema. Y me mis ánimos se me fueron abajo.

Inclusive, creo que sí. De hecho, dejé de entrevistar. Ya no volví a entrevistar con ninguna entre empresas hasta mucho tiempo después. Y todo esto porque no me preparé. Y ahora qué haría diferente? Qué? Qué consejo? Yo le daría mi del yo del 2016. Para para mejorar en este aspecto.

Bueno, en primer lugar, le diría que practicara algoritmos. Sí, realmente no me preparé técnicamente para nada para esta entrevista. Entonces, lo primero que haría ahora. Sería comenzar a practicar porque al fin el día, esto es práctica. Recuerdo que cuando estaba en la universidad algoritmos. Era algo muy sencillo. Se me facilitó bastante, pero por qué estaba haciendo todo el tiempo.

Osea, algoritmos de búsqueda, algoritmos de ordenamiento, pilas, listas, todo eso era muy fácil porque lo estaba haciendo constantemente. Entonces ahora lo que haría. Sería un mes antes o inclusive dos meses antes, todos los días comenzarme a definir 20, 30 minutos para resolver un ejemplo, un problema de leetcode.

Hoy en día tenemos estas plataformas dónde puedes registrarte, hay problemas que tú puedes resolver y esto te va a ayudar un montón. todo requiere práctica. Una vez que practicas, puedes lograrlo. Y bueno, tengo hoy en día montón de años de experiencia, pero en algoritmos realmente que no los uso diariamente.

Si me ha tocado usar en mi trabajo árboles binarios o búsqueda binaria, Pero no más allá de eso. Y son cosas bien específicas. Entonces, al no practicar, al no estar resolviendo eso es difícil. Entonces eso es lo primero que haría hoy en día, practicar algoritmos uno o dos meses antes de cuando fuera a entrevistar.

Lo siguiente consejo que le daría a mi yo de hace cinco, seis, siete años. Sería hablar en voz alta en inglés mientras programas, okey, por qué? Porque esto te va la confianza. Esto va a ser que te acostumbres y sobre todo, va a ser que te familiarises, con los nombres de las cosas o que, por ejemplo, colon, semi colon, slash, dash, todos esos nombres que en ese momento, la verdad es que yo no los usaba y se me complicaban bastante. Entonces. Hoy en día, ya estoy más familiarizado, entonces no me tendría que concentrar tanto en eso.

Otro consejo es hacer lives en alguna red social, aunque nadie te vea o puedes pedirle que a un amigo que se conecte para que te observe. Y bueno, si hay gente que te va a estar observando, la presión, la vas a sentir, esa presión.

Ser observado se siente bastante, es bastante real. Entonces, si comienza a hacer lives y comienzas a hacer codificación y que otras personas te vean, te vas a acostumbrar y te lo digo por experiencia, porque yo en el 2012, 2013 daba cursos de Java Script al principio igual me era difícil, pero todavía lo hice como dos, tres años.

Entonces, después de vario tiempo, después de tiempo de estar codificando y explicando. Claro. Así en español se me facilitaba bastante y ya no sentía esa presión de tener alguien viéndome codificar que cometiera algún error. Yo se suponía, era el experto el que estaba dando el curso. Entonces no tenía que cometer errores.

A veces los cometía, pero los usaba como ejemplos, no de que no miren esto. No se hace por esto y aquello aquí me equivoqué. Entonces era una experiencia. Yo les aconsejo que puedan hacer estos lives, hoy en día es fácil ir a youtube live o twitch  o cualquier de esas plataformas les va a servir un montón para quitarse esa presión y acostumbrarse.

Todo es práctica. Práctica en hacer algoritmos, practica Hablar en voz alta mientras estás codificando y práctica. Cuando alguien te esté observando con esto, vas a poder mejorar y pasar esa entrevista técnica sin problemas.

Y bueno, volviendo a mi historia, recuerdo que al día siguiente, recibí un email del reclutador donde me dijo que, bueno, el equipo había decidido pasar y no me dio más feedback realmente sólo me preguntó qué preguntas se te hicieron complicadas. 

Y yo le dije bueno, la verdad es que me bloque y creo que todo comenzó en el momento, que olvidé cómo se decía en inglés, colon, semi colon. Ese tipo de cosas, todo fue una cadenita que se fue hasta que llegué a un bloqueo absoluto y total de olvidar cómo se escribe la sintaxis de un for loop. Es increíble, pero esas pequeñas cositas van incrementando y todo puede ser un desastre.

Pues bueno, espero que mi experiencia te motive. No importa cuánto tiempo lleves trabajando en la industria o cuántos proyectos has sacado a producción. Si eres un senior, un junior, entrevistar es un skill y sólo vas a volverte buenos si practicas y le dedicas el tiempo suficiente para mejorar.

La peor entrevista que tuve - ¿Qué mejoraría para poder pasarla?

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 cuando 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. 

El Blog

Últimas publicaciones

Instalar ComfyUI para generar imágenes con Flux

La peor entrevista que tuve - ¿Qué mejoraría para poder pasarla?

¿Cómo saber cuando 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?

Conecta conmigo!

Tags

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

También estoy en Youtube