Parar de fracasar en las entrevistas de codificación en vivo: lecciones de más de 100 sesiones reales

Una vez contraté a un desarrollador que no resolvió el problema. Ellos llegaron a la mitad del camino, terminaron sin tiempo, y su código no compiló. Yo los recomiendo para una oferta de todos modos. Ellos habían pasado toda la hora pensando en voz alta, preguntando preguntas de aclaración, y tratándome como un colega debugando algo juntos. Eso es cuando me di cuenta de que las entrevistas de codificación en vivo están mal llamadas. He estado en esta industria durante 12 años. He entrevistado a cientos de roles, he pasado más de 50 rondas técnicas, y he llevado a cabo más de 100 entrevistas de codificación en vivo en lugares como Monzo y Superbet. El patrón es consistente: los mejores codificadores no siempre se contratan. Los más vocales lo hacen. Puedes escribir código impecable en silencio y fracaso. Puedes luchar a través de una solución mediocre mientras se comunican hermosamente y tienen éxito. La entrevista está probando si el equipo quiere pasar más de 40 horas a la semana trabajando con usted. ¿Por qué hay que hacer entrevistas de codificación en vivo? Recuerdo una noche que estaba visitando a mi madre y me preguntó: Lo siento mamá, no tengo una respuesta para ti. Fue solo una ronda 3 de 7.Todavía tengo un diseño del sistema, una codificación en vivo, un comportamiento y una ronda de equipo para ir. - Ella preguntó, mortificado - Cambio de empleo para ella consiste en pasar 15 minutos con un director médico, principalmente discutiendo su sueldo y hora de inicio y eso es todo. “¿Cómo fue la entrevista en la compañía X? ¿Tú has conseguido el trabajo?” “¿Y qué?” "¿No es esto para el mismo papel que tuviste antes?" La ingeniería de software es una profesión de baja confianza —y por una buena razón también.La brecha de habilidades entre los desarrolladores puede ser asombrosa.Puedes tener a alguien que ha estado codificando durante 15 años todavía luchando con algoritmos básicos, mientras que El paisaje también está cambiando rápidamente.La adaptabilidad se está volviendo más valorada, mientras que los fundamentos fuertes y los principios sólidos están perdiendo sabor. Un internista ahorra 300.000 dólares a TikTok reconstruyendo un microservicio en Rust Has solicitado tu papel de sueño y has recibido una llamada de HR. y están Verifica tu calendario. Panic sets in. Usted comienza a googlar Entonces, por fin, vamos a conseguir ese trabajo. “Impresionado por tu experiencia” "Esperando avanzarte a las próximas etapas" Live coding interview — tomorrow 3PM Cómo pasar una entrevista de codificación en vivo Tipos de entrevistas de codificación en vivo No todas las entrevistas de codificación en vivo se crean iguales. Antes de entrar en pánico, ayuda a saber qué formato está entrando. : Similar a una competición de programación, obtendrá una tarea que requiere una comprensión de un algoritmo bien conocido con antelación. Esto le dice muy poco sobre la competencia real de un ingeniero de software. LeetCode-style interview Grind un sitio web como LeetCode durante un par de semanas, hasta que puedas resolver fácilmente problemas fáciles y medianos. Esto debería prepararte para preguntas difíciles también. En general, necesitarás conocer los mismos algoritmos (DFS, BFS, FF, etc.) pero usarás más de uno como parte de una solución más compleja. Si la empresa está buscando específicamente programadores competitivos, este estilo de entrevista tiene sentido. De lo contrario, puede señalar su desaprobación rechazando respetuosamente la entrevista. : Comenzarás con un ejercicio de toma de casa. Una vez que envíes esto, el equipo de contratación hará un pase de cursor para revisar tu solución. Si están contentos con ella, pasas a la ronda 2 - una sesión en vivo donde tendrás 10-30 minutos para hacer un pequeño cambio o implementar una pequeña nueva característica. Esto demuestra que realmente puedes escribir código y no fue un conocido útil (cuyo nombre rima con Chad Jeep ET) quien lo hizo para ti. Take-home exercise with live counterpart : Por lo general, solo hay una tarea, diseñada para durar aproximadamente una hora. Esto prueba sus habilidades de resolución de problemas de fin a fin. Obtendrá una declaración de problema bien definida y un entorno para escribir código. Colaborará con el entrevistador(s) para converger en una solución. A menudo hay una escala para esto también - si no puede terminar toda la tarea a tiempo, a menudo todavía es aceptable. Pair-coding exercise : Obtendrás un montón de preguntas relacionadas con la programación, generalmente aumentando en dificultad. Las primeras preguntas simplemente comprueban si tienes algún nivel de competencia en el idioma. Los próximos pocos tomarán un poco de tiempo para pensar. Puedes empezar a tomar notas aquí – usando comentarios de código antes de implementar trabajos bien. Las últimas 1-3 preguntas están diseñadas para engañarte, confundirte con ti, y hacer que quieras dejar de trabajar en el software. Dependiendo del idioma, esto incluirá pistolas de pie típicas, sospechosos habituales al debugar, y a veces casos de borde exótico que los entrevistadores encontraron. Puedes no resolver estos, y eso está bien. Caminar a través de los entrevistadores cómo te acercarías a ellos. Live programming trivia : El último jefe de entrevistas de tecnología. Soy afortunado de haber participado sólo en dos entrevistas de tablero blanco en mi carrera. No son tan populares ahora como eran una vez. A menudo las encontrarás en uso por compañías de tecnología heredadas que no habían revisitado su proceso de contratación en este milenio. Si tienes suerte, puedes usar pseudo-código para ilustrar tus ideas. Rara vez tienes que escribir todo el programa. Visualizar tu solución pretendida usando ilustraciones también puede ayudar (si se permite). Whiteboard No todo el mundo hace entrevistas de la misma manera, así que si quieres estar seguro, prepárate para múltiples formatos. 1 RTFM Lee el manual amigable o, en este caso, lea el correo electrónico que te envía el equipo de contratación. Algunas empresas te enviarán instrucciones detalladas antes de la entrevista.Le dirán qué tipo de problema esperar, qué tecnologías usarás, cuánto tiempo durará la entrevista, y qué herramientas necesitarás.Leer este correo electrónico.Lerlo de nuevo.He visto a los candidatos que aparecen sin estar preparados para las cosas que se expresaron explícitamente en la invitación. Aquí está lo que necesitas resolver antes de que comience la entrevista: La mayoría de los entrevistadores quieren verlo. Se succiona hablar a dos letras en un círculo durante una hora. Si su webcam de portátil está roto, use su teléfono. Si no tiene una webcam en absoluto, déjenlo saber de antemano - pero entienden que esto puede ser un rompecabezas para algunas empresas. Get your webcam working. Probablemente necesite compartir su pantalla o utilizar una herramienta de colaboración como , de Asegúrese de que realmente puede hacer esto antes de la entrevista. he visto 5 minutos perdidos mientras un candidato trataba de averiguar cómo compartir su pantalla. Test your screen sharing. CoderPad Repleto Si su internet es frágil, la entrevista será dolorosa para todos. cortar audio, compartir pantalla congelar, código no sincronizar - todo esto mata la sensación de colaboración de la entrevista. Si sabe que su conexión es poco fiable, acerque al equipo de contratación de antemano. Check your internet connection. A veces tendrás un contacto externo de recursos humanos - un reclutador de tecnología de una agencia, por ejemplo. En mi trabajo actual en Speakeasy, trabajé con un reclutador que explicó minuciosamente cada paso y hizo su mejor esfuerzo para prepararme. Work with your recruiter. Lo peor que puedes hacer es presentarte a la entrevista y pasar los primeros 15 minutos resolviendo problemas técnicos que podrías haber resuelto el día anterior. Probar que eres un buen colega Es un poco aburrido, ¿no es así? Pero aquí está la cosa: no estás siendo entrevistado sólo por tu habilidad de codificación.Estás siendo evaluado sobre si el equipo quiere pasar más de 40 horas a la semana trabajando contigo.He visto ingenieros brillantes ser rechazados porque estaban condescendiendo durante la entrevista.También he visto a los programadores promedio ser contratados porque eran agradables de trabajar con y mostraron que podían aprender. De mi experiencia de llevar a cabo más de 100 entrevistas de codificación en vivo, los candidatos más exitosos tienen una cualidad en común.Son vocales.Comunican su proceso de pensamiento, hacen preguntas de aclaración, y tratan la entrevista como una sesión de resolución de problemas colaborativa en lugar de un examen en el que están siendo probados. Los entrevistadores están tratando de responder a una pregunta: Tus habilidades técnicas importan, pero también cómo manejas la frustración, cómo respondes a las pistas y si eres gracioso cuando estás atrapado.Nadie quiere trabajar con un genio que hace que todos a su alrededor sean miserables. “¿Quieres que esta persona esté en mi equipo?” Una buena regla del pulgar: si el entrevistador parece comprometido, preguntando preguntas de seguimiento, y la conversación fluye naturalmente, probablemente estés haciendo bien en la prueba de "colega". Conversa, pero no desvíe Se siente anormal al principio - como si estuviera narrando un documental sobre la naturaleza sobre su propio cerebro - pero es la cosa más valiosa que puede hacer en una entrevista de codificación en vivo. "Estoy pensando que necesitamos repetir a través de esta matriz.Podríamos usar un para el loop, pero dado que estamos transformando cada elemento, map Deja que empiece con eso y podemos optimizar si es necesario". Esto sirve a dos fines. En primer lugar, muestra al entrevistador cómo piensas. No están evaluando solo tu solución final; están evaluando tu enfoque de resolución de problemas. En segundo lugar, les da oportunidades de corregir tu curso antes de pasar 15 minutos en el camino equivocado. He entrevistado a candidatos que, cuando se les hace una pregunta directa, lanzarían una discusión filosófica de 5 minutos sobre los principios de la ingeniería de software para evitar admitir que no conocen la respuesta. Si el entrevistador pregunta y no sabes, no respondas con Sólo digan: “¿Cuál es la complejidad temporal de esto?” "Bueno, esa es una pregunta interesante.Ves, la complejidad depende de muchos factores, y en el mundo real, tenemos que considerar la localización del caché y..." "No estoy seguro de la complejidad exacta, creo que podría ser O(n log n) por el paso de clasificación, pero me gustaría comprobar eso". La honestidad envuelta en la reflexión gana la desviación cada vez. Sus preguntas son tan importantes como sus respuestas ¿Alguna vez has querido decir durante una entrevista: Bueno, animamos activamente a los candidatos a utilizar Google, Stack Overflow y documentación durante las entrevistas de codificación en vivo. Muchas empresas siguen este enfoque, pero no todos. Lo peor que pueden decir es no, y sabrás dónde estás. “Sólo Google esto” "Am I allowed to look things up?" Pero incluso con Google disponible, hacer preguntas sigue siendo crucial. En el trabajo real, usted está constantemente haciendo preguntas. Pide a su gerente de producto para aclarar. Pregunta a sus colegas sobre la arquitectura existente. Mira la documentación. La entrevista debe reflejar esta realidad. Cuando se le da un problema, no comience a codificar de inmediato. "¿Cuál es el tamaño esperado de la entrada? ¿estamos hablando de 10 artículos o 10 millones?" "¿Debería optimizar para la complejidad del tiempo o la complejidad del espacio?" "¿Hay algún caso marginal que deba ser particularmente consciente?" "¿Qué pasa si la entrada es nula o vacía?" Recuerdo haber entrevistado a un ingeniero senior que pasó los primeros 8 minutos de una entrevista de 45 minutos preguntando preguntas sobre los requisitos. Comenzé a preocuparme de que no tendrían tiempo suficiente para desarrollar una solución. Tenga cuidado, sin embargo: las preguntas deben ser aclaraciones genuinas, no solicitudes de pistas. (Pregunta correcta) y (Pesca para la solución) “¿Cuál es el tamaño de entrada esperado?” “¿Sería útil un mapa de hash aquí?” Una buena regla del pulgar es, si estás a punto de responder a una pregunta que comienza con En su lugar, explique que necesita más aclaraciones y enumere qué factores dependerían de su solución. Esto muestra que comprende los compromisos sin hacer que el entrevistador lo arrastre de usted. “Depende” Si no sabes - Pregunta Esto suena idéntico al consejo 4, pero es sutilmente diferente. Consejo 4 se trata de hacer preguntas para aclarar los requisitos. Este consejo se trata de hacer preguntas cuando está verdaderamente atrapado o no sabe algo. He visto a los candidatos gastar 20 minutos tratando de recordar la sintaxis exacta para algo trivial, demasiado avergonzado para preguntar. "Sólo pregúntame, te lo diré, y podemos pasar a la parte interesante". Si no se acuerda de que JavaScript Si estás vacilando sobre el nombre de ese algoritmo que has aprendido en la universidad, describe lo que recuerdas y pregunta si el entrevistador sabe lo que se llama.Si estás atrapado en un problema y no puedes ver un camino hacia adelante, explica dónde estás atrapado y pide una pista. sort() La clave es ser específico acerca de lo que no sabes. pero “No sé cómo hacer esto” Estoy pensando en usar un Set, pero no estoy seguro de si ese es el enfoque correcto aquí". Esto hace dos cosas. En primer lugar, muestra que no está simplemente renunciando - usted ha pensado sobre el problema y tiene una hipótesis. En segundo lugar, le da al entrevistador información útil sobre dónde ayudarle. o o "the Set approach is good" "Piensa en lo que necesitas lograr con un conjunto" "Hay realmente un enfoque más sencillo si se ordena primero". Nadie te espera que lo sepas todo, pero esperan que seas valiente cuando no lo haces. Este no es el momento de probar cosas nuevas Durante una entrevista de codificación que llevé a cabo, el candidato mencionó que conocían mejor C#, uno de los idiomas que ofrecíamos para la entrevista.Pero habían estado escribiendo Scala durante los últimos años, y dado que Scala se ejecuta en el JVM al igual que Java, decidieron hacer la entrevista en Java en su lugar. Nuestra tarea de codificación en vivo es muy simplista: se trata puramente de comprensión y conceptos básicos de programación.La apuesta no pagó.Pasaron un tiempo precioso luchando con la sintaxis de Java en la que no eran fluidos, cuando podrían haber atravesado el problema en C#. La entrevista no es el momento de experimentar con ese nuevo marco que has escuchado en Hacker News. No es el momento de probar la programación funcional por primera vez. No es el momento de optimizar para lo que crees que el entrevistador quiere ver. Si conoces Python mejor que Java, use Python (si tienes la opción). El entrevistador quiere verle resolver el problema, no verle luchar con la sintaxis que no conoce. reduce Hay una excepción: si el entrevistador te pide específicamente que utilices algo con el que no estás familiarizado, eso es diferente. "No he usado X mucho antes, así que podría tener que buscar la sintaxis, pero aquí está mi enfoque..." Sus entrevistadores también son humanos Probablemente están nerviosos también.Puede que esta sea su primera vez llevando a cabo una entrevista.Puede que tuvieran una mañana dura.Puede que estén preocupados por si están haciendo las preguntas correctas. Como candidato, solía tratar a los entrevistadores como a jueces, autoridades lejanas e infalibles que evalúan mi valor. Esto significa algunas cosas prácticamente: Si algo no está claro en la declaración del problema, es probablemente porque el entrevistador no lo explicó bien, no porque se supone que lo intuya mágicamente. Si el entrevistador parece distraído o controla su teléfono, no lo tome personalmente. Algo podría haber ocurrido en el trabajo. Si nota un tipo en el problema o piensa que hay un problema con los casos de prueba, señale con cortesía: "Creo que puede haber un caso marginal aquí que no hemos cubierto - ¿qué debería ocurrir cuando ...?" Y aquí está el gran: puedes construir un informe.Un poco de conversación pequeña al comienzo ayuda. o Durante la entrevista, cuando te dan una pista, puedes decir Mostre que valoras su aportación. “¿Cómo va tu día?” "Gracias por tomar el tiempo para entrevistarme" "Ah, eso es un buen punto, no lo había considerado". La entrevista es una calle bidireccional.Estás evaluando a ellos tanto como ellos te están evaluando. Un proceso de pensamiento claro vale mil líneas de código Prefiero ver a un candidato escribir 20 líneas de código claro y bien razonado que 200 líneas de tonterías inteligentes y confusas. Cuando estás codificando en una entrevista, la claridad vence a la inteligencia. no y Pero y . Yes, even in an interview. It takes 3 extra seconds and makes your code infinitely more readable. Name your variables properly. x y userCount maxRetries Si estás escribiendo un gnarly one-liner que hace cinco cosas, divídelo en múltiples pasos con variables intermedias. Break down complex logic. Una rápida Antes de una compleja operación de filtro puede salvar al entrevistador de tener que revertir su intención. Add comments if it helps. // Find all users who haven't logged in for 30+ days Dice De esta manera, si estás en el camino equivocado, el entrevistador puede corregirte temprano. Think out loud before you code. "Voy a iterar a través de la matriz y construir un mapa de hash de valores a índices" Una vez entrevisté a un candidato que resolvió el problema con una solución recursiva increíblemente elegante que no podía seguir.Cuando les pedí que lo explicaran, no podían articular por qué funcionaba. Compara eso con otro candidato que escribió una solución iterativa sencilla con nombres claros de variables y me caminó a través de cada paso. Tu objetivo no es impresionar al entrevistador con tu brillo. Tu objetivo es demostrar que puedes escribir código que tus compañeros de equipo entenderán en seis meses. 9 Conoce tus límites La gestión del tiempo en las entrevistas es brutal.Estás siendo evaluado mientras tratas simultáneamente de resolver problemas bajo un reloj. Esto establece tu temporizador interno y te ayuda a acelerarte. At the start, clarify the time limit. “Tenemos 45 minutos, ¿verdad?” Dicen que: No pierdas la mitad de tu tiempo de entrevista siendo teñido. If you're stuck for more than 3-5 minutes, speak up. "He estado pensando en esto durante unos minutos y no estoy haciendo progresos. Si la entrevista tiene múltiples problemas y usted está atrapado en el primero, preguntar: "¿Debería seguir trabajando en esto, o le gustaría que me pasara al siguiente problema?"A veces los entrevistadores quieren ver el ancho, no sólo la profundidad en un problema. Know when to move on. No pases 40 minutos codificando y luego no tienes tiempo para probar tu solución. Si terminas con 5-10 minutos restantes, camina por tu código con algunas entradas de ejemplo. Encuentra tus propios errores antes de que el entrevistador lo haga. Si el entorno ya tiene pruebas, ! Save time for testing. Asegúrese de que los conduzca Si tienes un trabajo solución con 5 minutos restantes, no trate de refactorarlo a Mencione lo que optimizaría si tuviera más tiempo, pero entregue primero una solución de trabajo. Be realistic about optimisation. O(n²) O(n log n) Una vez fallé en una entrevista porque pasé 35 minutos perfeccionando el primero de los tres problemas, luego tuve que apresurarme a través de los otros dos. Mostrar profundidad, pero no forzarla Si ha trabajado con sistemas distribuidos, estrategias de caché, o patrones arquitectónicos complejos, y el problema conduce naturalmente allí, mencionarlo. He entrevistado a candidatos que, cuando se les pidió que implementaran una simple función de reversión de cuerdas, lanzaron una disertación de 10 minutos sobre la normalización de Unicode, los cúmulos de grafemas y el manejo de texto de derecha a izquierda. La clave es leer la habitación.Si el entrevistador parece interesado y hace preguntas de seguimiento sobre su experiencia con los sistemas distribuidos, expanda. Aquí hay un buen patrón: resuelva el problema primero, luego ofrezca profundidad. "Esta solución funciona para los requisitos que discutimos.En la producción, también consideraría [preocupación avanzada específica], pero estoy asumiendo que está fuera de alcance para este ejercicio. ¿Deberíamos discutir eso?" Este enfoque muestra que comprende el contexto más amplio sin desviar la entrevista. Demostra experiencia respetando el tiempo y la agenda del entrevistador. Una vez cometí el error de pasar 15 minutos explicando cómo implementaría el límite de tasa para un punto final de la API cuando la pregunta era sólo Aprende de mi fracaso: responda a la pregunta que se ha hecho, no a la pregunta que te gustaría que se hubiera hecho. Escribe una función que valida las direcciones de correo electrónico. +1 Siempre pide feedback La mayoría de las empresas no le darán comentarios detallados (razones de responsabilidad, en su mayoría), pero vale la pena preguntar de todos modos. Si recibes la oferta: “¡Muchas gracias! ¿Puedo preguntar qué fue bueno en la entrevista? siempre estoy buscando mejorar.” Si te rechazan: "Gracias por dejarme saber. entiendo que usted puede tener políticas en torno a los comentarios, pero si usted es capaz de compartir algo sobre cómo podría mejorar para futuras entrevistas, realmente lo agradecería". Algunos entrevistadores ignorarán esto.Algunos le darán platitudes genéricas.Pero ocasionalmente, obtendrá un feedback genuino y actuable que le ayudará en su próxima entrevista.Algunos comentarios invaluables que he recibido en el pasado: "Usted sobreexplicó las cosas, no consideró a su audiencia" “Tu solución fue correcta, pero yo he luchado para seguir con tu proceso de pensamiento” "Es claro que tienes mucho ancho, pero apreciaríamos un poco más de profundidad en algunos temas" Las entrevistas son una mina de oro para tu viaje de auto mejora. Aquí está algo que la mayoría de los candidatos no saben: algunos entrevistadores se sienten cómodos conversando sobre la entrevista después directamente - a través de correo electrónico o LinkedIn. La mayoría dirá que sí, y abre un canal para un feedback más sincero de lo que HR podría proporcionar. "¿Sería bien si te contactara directamente en LinkedIn si tuve alguna pregunta de seguimiento?" Al menos, pedir feedback demuestra que eres alguien que quiere crecer. Incluso si no obtienes información útil, deja una impresión positiva. Durante mi tiempo en Docler, tuvimos un candidato frecuente, que regresaba diligentemente, cada seis meses. Él siempre dejó con feedback y nunca cometió el mismo error dos veces. En la última ocasión, hizo una entrevista perfecta. Todavía trabaja allí hasta hoy. El peor resultado es que no escuchas nada.El mejor resultado es que aprendes algo que te da el siguiente trabajo.Siempre vale la pena preguntar. Good luck! Deseo la mejor suerte a usted en su próxima entrevista! Si mis consejos le ayudaron, o si tiene más trucos útiles para compartir, vamos a chatear!