Pero no siempre fue así. En 2015, conseguí un trabajo como desarrollador de software de primer nivel. Y en vano. Yo era un verdadero impostor. Pero mis escasas habilidades en ingeniería no me impidieron que me ascendieran al segundo rango al final. Quiero compartir mi historia para ayudar a otros impostores a tener éxito en las empresas FAANG, bueno, o en cualquier otro.
Cómo me colé en Amazon
Admiro a las personas que lograron pasar por el ciclo completo de selección en una de las empresas FAANG. Se trata de una serie de entrevistas de la mañana a la noche, durante las cuales el candidato es cuestionado por sus conocimientos técnicos y cualidades personales por parte de cinco empleados diferentes de la empresa. Para aprobar este examen, debe dedicar cientos de horas a la preparación, estudiar a fondo estructuras y algoritmos de datos complejos y resolver problemas durante meses. Todo esto requiere tanta paciencia, determinación y perseverancia como el proceso de publicación de un libro.
Mi camino pasó por todas estas dificultades. En 2014, Amazon estaba realizando entrevistas de trabajo en el campus para pasantes de verano. Algunos de mis compañeros de estudios fueron antes que yo. Todos regresaron con historias de desconcertantes preguntas de programación que les habían hecho.
Tuve cuatro exámenes esa semana y dormí un promedio de cuatro horas al día. Me las arreglé para dedicar tres horas a la preparación. Hubo dos entrevistas. Las preguntas de programación que recibí son increíblemente fáciles. Una trataba sobre la manipulación de bits, la otra trataba sobre el uso de listas enlazadas y también tuve que hablar sobre tablas hash. Eso es todo. Tuve suerte.
Los pasantes en Amazon, si les va bien, reciben una oferta para pasar a un desarrollador de tiempo completo del primer rango de nivel de entrada. No tienen que repetir entrevistas. Estaba haciendo mi pasantía en Seattle, esculpiendo minuciosamente un sitio de Ruby on Rails desde cero. Recibí una oferta y comencé como desarrollador de software en 2015 en Virginia.
Sobre la escasez de mis conocimientos
Los desarrolladores de rango 1 deben estar bien versados en estructuras de datos avanzadas: montones, gráficos, árboles de prefijos. Ni siquiera sabía el significado de estas palabras. Los desarrolladores de rango 1 deberían poder estimar la complejidad temporal y espacial de los algoritmos para clasificar, buscar, insertar y dividir. No les diría la complejidad temporal de una búsqueda banal en profundidad en un árbol binario.
¿Por qué tengo tantas lagunas de conocimiento? Hubo dos razones.
Primero, estudié ingeniería informática, no informática. La atención se centró en la integración de software y hardware en lugar del desarrollo de grandes sistemas. Esta orientación me enseñó a resolver problemas complejos en condiciones dudosas, pero el programa no proporcionó un análisis detallado de las estructuras de datos y los algoritmos. En segundo lugar, no pasé por un proceso de preparación completo, no pasé cientos de horas estudiando, por lo que no aprendí.
Yo mismo me di cuenta de que no estaba manteniendo el ritmo. Al principio, el síndrome del impostor me atormentó con una fuerza terrible.
Primeros panqueques
Cada inspección de código fue un desastre. Envié un fragmento para su revisión (en forma de una solicitud para aceptar cambios, por ejemplo), me lo devolvieron con ochenta comentarios. No servirá. Corregí y envié una nueva versión. Cincuenta comentarios más. No servirá. Y así sucesivamente y así sucesivamente.
Con algunos fragmentos, las cosas iban tan mal que los colegas simplemente no sabían cómo explicar la esencia del problema para que yo lo entendiera. Tuvieron que descargar el código y reescribirlo. Querían ayudarme y fueron muy amables, pero literalmente me quemé de vergüenza. Vivía con miedo de que la gente entendiera: no pertenezco aquí. No pasaba un solo día de trabajo sin pensar que hoy me despedirían.
Exponiendo al impostor
Poco a poco me levanté. Finalmente, comencé a cumplir con los plazos y a entregar constantemente el código a producción. Aproximadamente nueve meses después, desarrollé la confianza en mí mismo. Decidí que era hora de deshacerme del síndrome del impostor de una vez por todas. Recurrí a problemas en LeetCode, solo para demostrarme a mí mismo que estaba en mi lugar. Recuerdo haber pensado: “Ahora soy un desarrollador de pleno derecho en Amazon. Tengo compromisos en producción. ¿Por qué no puedo hacer frente a estas sencillas tareas? "
Elegí uno de los fáciles en LeetCode, y no pude resolverlo. Elegí otro, y tampoco pude. Y el tercero y el cuarto. Entonces me quedó claro que no padecía ningún síndrome. Soy un impostor.
Ser, no parecer ser
Después de dos años y medio, me ascendieron a desarrollador de segundo nivel. Un desarrollador de segundo rango puede crear y mantener un gran sistema por su cuenta con una mínima ayuda externa. Entonces, ¿cómo lo hice? ¿Cómo logré reinterpretar las reglas del juego a mi favor?
Bueno ... de ninguna manera. En Amazon, las travesuras no funcionan. El sistema no se puede reproducir. “Finge ser un especialista hasta que lo consigas” es un consejo muy común y muy malo. Esto no funciona. La única forma de que te designen desarrollador de nivel 2 es convertirte en desarrollador de nivel 2.
La promoción es un proceso agotador. Necesita describir sus méritos y logros en más de veinte páginas de documentación, tanto así lo creen sus colegas y jefes. Necesita recopilar constantemente métricas y pruebas de que su progreso está en un nivel superior. Puede contar con un aumento solo si mantiene constantemente el listón del siguiente nivel durante seis meses, o incluso un año entero.
Probablemente haya escuchado la frase: "Nuestra personalidad se compone de lo que hacemos con regularidad". A continuación te contaré qué acciones tomé para dejar de ser un impostor y establecerme como un desarrollador de mayor nivel.
Que hice
Sintonización para maximizar la aceptación de la retroalimentación Los
recién llegados a FAANG a menudo tienen egos inflados. Esto les priva de la capacidad de aceptar y tener en cuenta las críticas constructivas de sus colegas. Pero estos colegas son personas inteligentes, cada uno de los cuales tiene su propia experiencia única en el campo de TI detrás de ellos.
No tuve ningún problema de autoestima. De manera amistosa, no tuve nada que ver con la empresa. Por lo tanto, cuando me dieron retroalimentación, escuché y escuché con atención.
Los comentarios de los colegas fueron verdaderos, controvertidos o incorrectos. Si el comentario era correcto, seguí el consejo sin reservas. Si se trataba de algo controvertido, primero traté de comprender el punto de vista de otro desarrollador, y solo entonces, transmitir el mío. Y, de repente, estaba escuchando incluso los comentarios equivocados.
En este caso, la línea de pensamiento fue: "¿Por qué estoy seguro de que tengo razón? ¿Qué llevó a una persona a tal idea? ¿Puedo aclarar de alguna manera para que no surja tal reacción? " Esto es lo que llamo máxima apertura. Las personas inteligentes, incluso cuando están equivocadas, proceden de algo en sus conclusiones. Descubrí exactamente qué y mejoré mi código con esta información en mente.
Preguntas estúpidas formuladas Los
recién llegados a las empresas FAANG a menudo tratan de no hacer preguntas, tienen miedo de que las piensen mal. Este elemento del síndrome del impostor coexiste paradójicamente con la presunción inflada. Bueno, yo, como un verdadero impostor, entendí perfectamente bien que mis preguntas eran estúpidas. No me molestó.
Por ejemplo:
« , . , ?»
« , ?»
« , . - ?»
Muy pronto conseguí cientos de marcadores, recopilé toneladas de información adicional y tuve mucho éxito participando en las reuniones.
Encontré un inspector de código inquieto
Al principio, es muy importante que tantos otros desarrolladores como sea posible revisen su código. Cada empleado que realiza una inspección tendrá sus propias preferencias, molestias y molestias. Pero es aún más importante descubrir al inspector inquieto.
Hay uno en cualquier equipo. Su trabajo nunca está satisfecho. Se adhiere al nombre de cada variable, cada registro, cada parámetro de API seleccionado. Hice un esfuerzo especial para encontrar a esta persona y lanzarle mi código con la mayor frecuencia posible. ¿Por qué? Porque lo entendí: cuantos más comentarios constructivos reciba, más rápido será el entrenamiento.
Usó patrones existentes para evitar errores. Los
jóvenes a menudo intentan reinventar la rueda. La mayoría de las tareas de desarrollo no son nada nuevo. Antes de comenzar a escribir el código solicitado, estaba buscando soluciones similares en recursos internos. Revisé varios ejemplos diferentes, profundizando en cómo se estructura el código en ellos. Luego recurrí al código de mi equipo y descubrí la mejor manera de vincular el nuevo fragmento al sistema general.
Adopté el mismo enfoque al redactar la documentación de diseño y los informes post mortem. Muestras primero, luego acciones.
Centrado en la corrección y adecuación
Evité la trampa de los costos hundidos. Si estoy haciendo algo mal, no importa que ya haya pasado cuatro horas en ello. Sabía que tendría que dejar de lado lo que había ganado y rehacerlo de la manera correcta.
Por cien líneas de código enviadas para inspección, había doscientas cincuenta líneas de basura que escribí y tiré. Traté de asegurarme de que cada una de estas cien líneas fuera comprensible, estuviera escrita a propósito y fuera necesaria para algo. Ahora mi código generalmente recibe luz verde después de una o dos revisiones.
Lanzarse al calor
Nunca se sentirá "preparado" para trabajar en funciones clave, implementar proyectos en producción, realizar entrevistas y eliminar emergencias. La mejor manera de prepararse para todo esto es tomarlo y hacerlo.
En la primera oportunidad, simplemente le dije a mi jefe: estoy listo. Incluso si antes de eso no tuve la oportunidad de observar las acciones de los demás en detalle, como se suele aconsejar. A veces tuve que pedir ayuda o que alguien de mis compañeros siguiera mi trabajo. Pero en última instancia, me permitió expandir mi zona de confort y acelerar mi crecimiento.
Tomando iniciativa en las pequeñas cosas
noté oportunidades para mejorar la excelencia operativa del equipo, procesos de trabajo, experiencia de desarrollo. Más de una o dos veces, asumí voluntariamente tareas aburridas: automaticé procedimientos que se realizaban manualmente, finalicé la documentación, mejoré la canalización de CI / CD, refactoricé el código heredado.
Traté de ser profesional
La programación es un tipo de creatividad basada en la lógica. Cada tarea, cada nueva función, la percibí como una hoja en blanco en la que puedes mostrar tu habilidad y dejar la creación.
El desarrollador de segundo nivel debe ser un ingeniero de software o un profesional, según Stephen Pressfield, autor de The War of Art. Dediqué todos mis esfuerzos a escribir código limpio (definitivamente debería leer el libro del mismo nombre) y crear soluciones hermosas y elegantes.
Indicó claramente su deseo de un aumento
En las empresas de FAANG nadie ofrece un aumento, se les pregunta usted mismo y más de una vez. Si esto no se hace, el proceso se prolongará durante muchos meses.
En conversaciones privadas con mi jefe, dejé en claro que quería ser ascendido. Pedí retroalimentación para entender qué áreas estaban hundidas. Evalué objetivamente los resultados del trabajo terminado y acepté las críticas cuando me llegaron. Busqué oportunidades para perfeccionar mis habilidades y cerrar las brechas. Si pude mostrar algunas habilidades, traté de mantener los comentarios por escrito. Después de todo, no puede predecir cuándo tendrá lugar la próxima reestructuración y su jefe cambiará.
Poner el trabajo para la promoción antes que otros
Entendí: no se puede trabajar única y exclusivamente para la promoción. Si todos hacen esto, la atmósfera del equipo definitivamente se volverá inadecuada para la vida. Pero al mismo tiempo, puse literalmente las tareas que necesitaba para la promoción en primer lugar.
Es decir, si necesitaba concentrarme en una función importante, cuyos plazos eran ajustados, la asumía por la mañana. De esa forma podía estar seguro de que tenía suficiente tiempo para hacer bien el trabajo. Si necesitaba realizar una inspección del código de manera más activa, entonces las horas de la mañana se dedicaban a ello. Si necesitaba asistir a entrevistas con más frecuencia, comenzaba mi jornada laboral registrándome en las próximas.
Constantemente recolectando evidencia de mi éxito
No se puede prescindir de la capacidad de presentar los propios logros mediante una combinación de indicadores cuantitativos y cualitativos.
Antes de poner la tarea en funcionamiento, busqué métricas que describieran el estado actual del sistema. Al finalizar el trabajo, miré los nuevos indicadores y realicé cálculos para comprender hasta qué punto mis acciones influyeron en la situación. Y finalmente, registré todo lo relacionado con la tarea en la documentación que se suponía que debía servir como justificación del aumento: análisis STAR, indicadores cuantitativos, enlaces a resultados de inspección de código, gráficos y otras reliquias del trabajo.
Me di cuenta de que depende de mi y que no
Llegué a comprender que cualquier cosa puede pasar. A veces, a un equipo le faltan funciones importantes. A veces los proyectos están cerrados. A veces, debido a la reestructuración, la gestión cambia. A veces, la canalización de CI / CD ya es perfecta y simplemente no hay nada que mejorar en ella.
Y al mismo tiempo, me di cuenta de que si me enfoco en trabajar al límite y abordar las tareas de manera profesional, estaré lista para el momento en que aparezca la oportunidad de mostrarme. Surgió la oportunidad: demostró ser un profesional. Esto trajo algunas oportunidades más, nuevamente hice todo en el nivel. Etc.
Reflexiones
¿La “cultura Leetcode” que se ha desarrollado en el proceso de contratación está perjudicando al negocio?
Me las arreglé para afianzarme con éxito en Amazon, aunque cuando llegué por primera vez, las tareas con Leetcode eran demasiado difíciles para mí. Luego, cuando yo mismo comencé a realizar entrevistas, por supuesto, desensamblé a propósito todos los algoritmos y estructuras de datos necesarios para poder evaluar las respuestas de los candidatos.
Creo que el enfoque actual da sus frutos. Las empresas están interesadas en personas que tengan la perseverancia y la motivación para aprender cosas nuevas y utilizar esta información junto con las habilidades existentes. Los procesos establecidos hacen un buen trabajo al seleccionar a esas personas.
Entonces, ¿es más fácil ingresar a los desarrolladores de rango 1 a través de una pasantía?
Yo no diría eso. Estas dos entrevistas no suelen ser más fáciles para los pasantes que cinco entrevistas para los empleados a tiempo completo. Cuando me entrevisté en 2014, no tuve suerte. Si alguien decide que definitivamente obtendrá las mismas preguntas simples que yo, entonces se está saboteando a sí mismo.
En la empresa se imponen a los becarios los mismos requisitos que a los desarrolladores de primer rango. Todos los aspectos del trabajo se examinan casi al microscopio. Conocí a muchos programadores que habían completado su pasantía, pero nunca recibieron una oferta de trabajo.
Durante estos cinco años, yo mismo he enseñado a varios pasantes y ahora, mirando el proceso desde el otro lado, entiendo cuán alto es el listón para ellos. Ahora, mirando hacia atrás y evaluando mi trabajo de pasantía, me doy cuenta de que hice un buen trabajo ese verano y realmente merecía ser ascendido a desarrollador.
¿Entonces Amazon no debería haberte contratado?
Hasta hace poco, me inclinaba a responder afirmativamente. No hay duda de que mis conocimientos de programación en ese momento no cumplían con los requisitos. Pero gradualmente llegué a la conclusión de que, a la larga, la empresa tomó la decisión correcta de contratarme. Definitivamente he aportado beneficios tangibles a Amazon.
Hice que AWS fuera más seguro, participé en programas de educación y ventas. He brindado soluciones a un gran número de clientes internos y externos. He impartido cursos de introducción a un público de varios cientos de personas. Me convertí en mentor de muchos programadores que aspiraban a entrar en desarrolladores de segundo nivel. Antes de unirme a Amazon, fui el capitán de los equipos de fútbol y baloncesto, los cuales llegaron a los cuartos de final en Virginia. A lo largo de los años, he perfeccionado mis habilidades para trabajar con personas y liderarlas; estas habilidades fueron útiles en Amazon. En el futuro, espero darle a la comunidad de desarrolladores aún más porque sé lo que es ser un impostor.