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?

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?

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.

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

Esta es una pregunta muy común en entrevistas técnicas, es una pregunta abierta de la cual se pretende conocer mejor al candidato. A partir de aquí surgirán más preguntas y la idea es tener una conversación interesante al respecto.

La primera vez que entrevisté para una empresa en Silicon Valley, no me prepare nada, entonces al hacerme esta pregunta rápidamente recordé un proyecto, pero ya que había pasado tiempo de haber trabajado en este problema, realmente no recordaba todos los detalles y eso me puso mucho más nervioso.

What's the most difficult technical problem you've had to solve?

Por demás está decir que fallé la entrevista y no pasé al siguiente paso en el proceso de entrevistas, fue una lástima porque de verdad me hubiera gustado trabajar en esa compañía.

Es por eso que uno de los consejos que siempre doy es prepararse con tiempo, parte de la preparación es escribir en un documento el problema más complicado que te ha tocado resolver, puede ser un componente que falló en producción, alguna iniciativa que te tocó trabajar, diseñar una solución a un problema de negocio, etc. realmente esto dependerá mucho de tu nivel de seniority.

Es importante elegir un problema que sea relevante para el trabajo al que estás aplicando y que puedas explicar claramente cómo lo solucionaste.

Si aplicas a un puesto de Backend y hablas sobre un problema de Frontend, puede ser interesante, pero no muy relevante para lo que estás aplicando.

También es importante considerar a tu audiencia, con esto me refiero al background del entrevistador, si esta pregunta te la hace un Product Manager la respuesta debería es diferente si te la hace un Ingeniero. Siempre recomiendo tratar conocer lo más que puedas al entrevistador, para eso puedes ir a LinkedIn o alguna otra red social donde sea activo.

Al describir el problema, asegúrate de proporcionar suficiente contexto para que el entrevistador comprenda la situación. Explica cómo afectó el problema al proyecto o a la empresa, y qué obstáculos enfrentaste al tratar de solucionarlo.

Luego, describe los pasos que tomaste para resolver el problema. ¿Investigaste alternativas? ¿Buscaste ayuda de otros departamentos o colegas? ¿Tomaste medidas inmediatas para mitigar el impacto del problema? La colaboración es algo muy importante que se toma en cuenta, así que no te olvides mencionar si colaboraste con alguien más.

Finalmente, describe los resultados de tus acciones. ¿Cómo se resolvió el problema? ¿Cómo afectó positivamente el proyecto o la empresa? ¿Qué aprendiste de la experiencia? Esto demuestra que te tomas el tiempo para reflexionar y analizar tus resultados, algo que definitivamente hará que sobre salgas sobre el resto de los candidatos.

Recuerda que la clave para responder a esta pregunta es demostrar tus habilidades de resolución de problemas y tu capacidad para manejar situaciones difíciles de manera efectiva. 

Prepara ejemplos relevantes y asegúrate de practicar tu respuesta antes de la entrevista, ya sea escribiendo en un documento todos los detalles, hablando en voz alta frente a un espejo o bien pidiendo ayuda a un amigo que te escuche.

¿Cuál ha sido el problema más difícil que has tenido que solucionar?

Esta es una de las preguntas que suelo realizar en una entrevista técnica, es una pregunta abierta y cada candidato suele decir diferentes cosas. Lo que se busca aquí es conocer su forma de colaborar con diferentes equipos en la organización, especialmente si el candidato está aplicando a un puesto de Senior, Staff o Principal.

A continuación voy a mostrar algunas respuestas que se espera dependiendo el nivel del candidato, entre más Senior se espera más colaboración y autonomía.

Un programador que recién está iniciando necesita más ayuda que alguien más experimentado, entre las respuestas que se esperan son cosas como:

Solicitar 1:1s para dar un overview del sistema

Alguien con un poco más de experiencia debería poder aventurarse al proyecto más fácil, entre las respuestas esperadas sería algo como:

Un programador Senior debería ser más autónomo, no digo que no deba preguntar nunca, por el contrario, debe apoyarse en su equipo haciendo preguntas interesantes sobre la arquitectura o modelo de negocio. Entre las respuestas esperadas sería algo como:

Familiarizarse con la arquitectura del sistema a un alto nivel

Entender como fluye la información en el sistema

Comunicarse con los owners del repositorio para aclarar dudas

Ver los tests existentes para entender funcionamiento esperado

Si te das cuenta, entre más Senior, se espera que el candidato sea más autónomo y también que se enfoque más en el modelo del negocio y el problema que soluciona determinadas partes del sistema. 

A final del día es importante recordar que nuestro principal objetivo es resolver mediante tecnología los problemas de negocio, aportando valor a nuestros usuarios, creo que entre más Senior esto se debe de tener claro.

Algo que me ha funcionado mucho a nivel personal, es participar en incidentes como espectador, ver como se solucionan los problemas y lo que está fallando te ayudará a comprender el sistema mejor, además de que conocerás a gente de otros equipos y te darás a conocer también. Si haces preguntas que ayuden a identificar el problema, mucho mejor.

El Blog

Últimas publicaciones

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

¿Cómo saber cuando ya eres Senior Engineer?

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

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

¿Cuál ha sido el problema más difícil que has tenido que solucionar?

¿Cuál es tu estrategia para ser productivo en un repositorio nuevo?

Conecta conmigo!

Tags

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

También estoy en Youtube