¿Qué plataformas realizan entrevistas de código y en qué se diferencian?

El correo de invitación suele indicar la plataforma, y su nombre te dice bastante sobre cómo será la sesión. Las plataformas se dividen en cuatro categorías.

• Editores compartidos en vivo. CoderPad, el modo de entrevista de CodeSignal, HackerRank Interview (antes CodePair) y otros editores similares abren un documento que tanto tú como el entrevistador pueden modificar. La mayoría permite ejecutar código en varios lenguajes; algunas empresas desactivan deliberadamente la ejecución para que razones en lugar de recurrir al ensayo y error.
• Documentos compartidos simples. Algunos equipos todavía envían un documento de Google o un editor de texto vacío por Zoom o Google Meet. No hay resaltado de sintaxis, botón de ejecución ni pruebas; el entrevistador lee tu código como lo haría un revisor.
• Pruebas en línea cronometradas. HackerRank, Codility y CodeSignal ofrecen un conjunto fijo de problemas con un cronómetro y un evaluador automático. No hay nadie en la llamada; la plataforma registra tu sesión y puntúa casos de prueba ocultos.
• Proveedores de entrevistas como servicio. Karat y otros proveedores similares aportan un ingeniero capacitado que realiza una entrevista técnica en vivo en el editor del proveedor y redacta el informe que leerá la empresa. El formato es en vivo, pero la persona al otro lado de la llamada no será tu futuro compañero.

Las empresas combinan estos formatos. Un proceso típico comienza con una prueba, continúa con una o dos rondas en editores en vivo y termina con una conversación de diseño en una herramienta de pizarra o una llamada normal. El tema sobre evaluación de plataformas analiza cada proveedor con mayor detalle.

Cinco características determinan cómo se desarrolla una sesión, y varían más entre plataformas que la dificultad de los problemas.

• En vivo o asíncrona. Un editor en vivo permite conversar: puedes preguntar por las restricciones y recibir pistas. Una prueba es un examen silencioso; la única aclaración disponible es el enunciado del problema.
• Ejecución de código. Los editores con un botón de ejecución te permiten comprobar un caso antes de afirmar que funciona. Los documentos simples y los editores con la ejecución desactivada te convierten en el intérprete, así que debes explicar qué hace cada línea.
• Visibilidad de lo que escribes. En un editor en vivo, el entrevistador ve cada pulsación, pausa y eliminación en el momento en que ocurre. Reescribir una función tres veces es visible; no es necesariamente malo, pero guardar silencio mientras lo haces sí puede serlo.
• Lenguaje y herramientas. La mayoría de los editores admiten los lenguajes más populares, pero el acceso a bibliotecas, el autocompletado y la disponibilidad de un depurador varían. Las pruebas suelen limitarte a los lenguajes compatibles con el evaluador.
• Grabación y supervisión. Las rondas en vivo suelen grabarse para la evaluación posterior. Las plataformas de pruebas ofrecen supervisión opcional, que puede incluir capturas de la cámara web, registros de cambios de pestaña del navegador o alertas por copiar y pegar; activarla es decisión de la empresa, y la invitación rara vez lo indica.

La última característica es la que debes tener en cuenta al planificar. Considera que cualquier prueba cronometrada está supervisada, salvo que las instrucciones digan lo contrario.

Es razonable preocuparse por que la práctica en una plataforma no se transfiera a otra. Esta sección ofrece una rutina de preparación para cada formato; en resumen, las habilidades de programación sí se transfieren, pero los hábitos durante la sesión no, así que practícalos de forma deliberada.

• Para editores en vivo: practica en un editor del navegador sin autocompletado, habla mientras escribes y redacta manualmente un pequeño caso de prueba antes de ejecutar nada. Si el editor tiene un botón de ejecución, úsalo después de explicar tu enfoque, no en lugar de explicarlo.
• Para documentos simples: practica escribir código correcto sin compilador. La sangría coherente y las funciones cortas importan porque el entrevistador lee el código, no lo ejecuta.
• Para pruebas cronometradas: practica contrarreloj teniendo presentes las pruebas ocultas: contempla entradas vacías, duplicados y los tamaños máximos permitidos. Lee primero todo el conjunto de problemas y ordénalos según el esfuerzo previsto.
• Para entrevistas de proveedores: espera criterios de evaluación estandarizados. Los entrevistadores de proveedores similares a Karat puntúan explícitamente la comunicación y la descomposición de problemas, así que expón tu plan antes de programar.

Una ingeniera de backend que entrevista para un puesto sénior en una empresa de pagos recibe tres invitaciones distintas en una semana: una prueba de CodeSignal, una ronda en CoderPad con la ejecución activada y una ronda final en un documento compartido. Ensaya cada formato una vez, y lo único que cambia entre ellos es cuánto explica en voz alta. La herramienta de entrevista simulada de SubcueAI es una forma práctica de ensayar en voz alta esa parte de la explicación.

Solo en los formatos en los que alguien habla contigo. La aplicación de escritorio nativa de SubcueAI para macOS y Windows captura tanto el audio del sistema como tu micrófono, por lo que escucha la pregunta del entrevistador en Zoom, Google Meet o Microsoft Teams y muestra sugerencias en un overlay flotante que solo aparece en tu propia pantalla. El panel lateral de su extensión para el navegador hace lo mismo con las llamadas que se ejecutan en una pestaña de Chrome o Edge; captura únicamente el audio de la pestaña de la reunión, por lo que escucha al entrevistador y nunca te transcribe a ti. Ninguna de las dos interfaces se une a la llamada como un bot ni introduce nada en la página de la reunión o en el editor de código; la versión de la extensión para Firefox solo permite realizar prácticas simuladas.

Ese alcance tiene límites claros. Una prueba cronometrada no incluye ninguna conversación, así que un asistente que escucha no tiene material con el que trabajar, y las pruebas supervisadas que registran tus pestañas o vigilan tu cámara web quedan fuera del propósito de SubcueAI. En un editor en vivo, compartir toda la pantalla haría que el overlay apareciera en la transmisión compartida; comparte solo la ventana del editor o no compartas ninguna. Las rondas grabadas y los dispositivos administrados por la empresa también quedan fuera de su alcance. Aaron Cao, fundador de SubcueAI, diseñó el overlay como una ventana local, en lugar de como un participante de la reunión, precisamente por este motivo: nunca debería formar parte de lo que graba la plataforma. Los pasos de configuración de cada interfaz se encuentran en la página del tutorial, y la página de seguridad explica qué se captura y qué no.