Cómo diseñar una entrevista técnica telefónica de 30 minutos que produzca señal real

Para qué sirve un screen de 30 minutos

Una entrevista técnica telefónica de 30 minutos existe por una razón: decidir si los siguientes 4–6 horas de un onsite o loop virtual merecen gastarse en esta candidatura. Ese es todo el trabajo. No es un mini-onsite. No es un chat de cultura con algo de código al final. Es una puerta.

Ese marco es liberador. No necesitas evaluar todo. Necesitas evaluar la una o dos cosas que, si fallan, el resto del loop se desperdicia.

El presupuesto de 30 minutos

Un presupuesto funcional que sobrevive el contacto con la realidad:

• 2 minutos — presentaciones rápidas, rol actual de la candidatura.
• 3 minutos — explicar el formato, establecer expectativas, confirmar que el tooling funciona (micrófono, editor de código, compartir pantalla).
• 20 minutos — un problema técnico, de principio a fin.
• 3 minutos — preguntas de la candidatura.
• 2 minutos — cierre, enmarcar el siguiente paso.

El bloque técnico de 20 minutos es la única parte que importa. Todo lo demás es overhead que no puedes comprimir más sin ser grosero.

Elige el problema correcto

Un problema de 30 minutos no es un Leetcode hard. Tampoco es Fizzbuzz. La forma correcta es:

• Solucionable de principio a fin en 15 minutos por una candidatura fuerte, dejando 5 minutos para preguntas de seguimiento.
• Tiene una solución ingenua obvia, así que una candidatura débil puede producir algo y no queda congelada.
• Tiene una optimización de siguiente nivel obvia, así que una candidatura fuerte tiene a dónde ir después del pase ingenuo.
• No requiere memorización. Nada de «implementa un B-tree». Estás probando pensamiento, no memorización.

Ejemplos que funcionan: «dada una lista de reuniones, encuentra conflictos», «implementa un cache LRU contra una interfaz dada», «dado un blob tipo CSV, agrupa filas por una clave». Son todos lo suficientemente simples como para que la solución ingenua quepa en una pantalla de código, y lo suficientemente ricos como para que haya una pregunta de seguimiento real.

Ejemplos que no funcionan en 30 minutos: cualquier cosa con forma de algoritmo de grafo, cualquier cosa que requiera scaffolding, cualquier cosa donde la candidatura pasa 10 minutos entendiendo el prompt.

Qué estás puntuando en realidad

Para un phone screen, tres ejes — no cinco. Cualquier cosa más es teatro a este presupuesto de tiempo.

1. Lee el problema antes de codificar. ¿La candidatura hace una pregunta de aclaración, reformula el problema y propone un enfoque antes de empezar a escribir? ¿O machaca el teclado mientras miras?
2. Escribe código que funcione. No código perfecto. No código idiomático. Código que funcione, con la candidatura notando casos límite mientras avanza.
3. Puede hablar mientras escribe. Codificación silenciosa durante 15 minutos es una señal de no-contratación sin importar si el código funciona, porque cada ronda posterior la necesita pensando en voz alta.

Eso es todo. Si la candidatura toca los tres con un 3-o-mejor, avanzas. La rúbrica estructurada para el loop completo hace el trabajo más pesado después.

Qué eliminar

• Diseño de sistemas en el phone screen. Guárdalo para el onsite. No puedes obtener señal significativa en 8 minutos.
• Preguntas conductuales más allá de «cuéntame sobre tu rol actual». Guárdalas para la ronda dedicada.
• «Cuéntame sobre un proyecto». Es una pregunta excelente. No es una pregunta de screen de 30 minutos.
• Take-home referenciado en el screen. Si tienes un take-home, va antes o después — no plegado en el screen.

Ejecuta el screen en el tooling que usa el loop real

Un screen de 30 minutos en Google Docs seguido de un onsite de 90 minutos en un editor real es un desastre de experiencia de candidatura. La candidatura pasa el screen demostrando que puede escribir Python en un campo de texto sin resaltado de sintaxis — y luego el onsite prueba algo diferente. Usa el mismo editor y el mismo entorno de ejecución de principio a fin. Ve la guía de mejores prácticas de live-coding para la versión más profunda.

Cómo encaja ClarityHire

La sala de entrevista tiene por defecto el editor Monaco con tipado colaborativo Yjs y un contenedor Linux real detrás del botón de ejecutar, así que un screen de 30 minutos está en la misma superficie que tu loop de 90 minutos. El template de scorecard de phone-screen se envía con la rúbrica de tres ejes pre-configurada; elige, personaliza los anclas para tu rol, y listo.

TL;DR

El screen técnico telefónico de 30 minutos es una puerta, no un mini-loop. Un problema técnico, tres ejes de puntuación, el mismo tooling que el loop completo, sin diseño de sistemas, sin conducta más allá de presentaciones. Cualquier otra cosa y estás subestimando la candidatura o corriendo sin tiempo.