Cómo manejar a una candidata usando segundo monitor en una entrevista de coding en vivo
La imagen realista
La mayoría de las candidatas tiene setups multi-monitor. Los usan para todo: documentación, problema, sus notas, ventana de chat con reclutadora, tab LLM. Algunos usos están bien. Algunos son problemáticos. Una regla blanket "no segundo monitor" es inforzable, aliena candidatas con razones legítimas (accesibilidad, ergonomía, workflows bilingües), y empuja a los cheaters determinados al teléfono-en-el-escritorio-fuera-de-frame de todas maneras.
La política correcta distingue uso de mal uso.
Qué permitir explícitamente
- Tabs de documentación (MDN, docs de lenguaje, docs de framework)
- El problema abierto en ventana separada
- Una notepad para scratch
- Features IDE que la candidata usa normalmente (autocomplete, linters, language servers)
Qué pedir a las candidatas no hacer
- Usar asistentes IA (ChatGPT, sugerencias inline de Copilot) durante una ronda de coding en vivo donde el objetivo es evaluar el razonamiento, no la fluidez con herramientas.
- Tener una persona separada en la llamada o en la sala.
- Referirse a materiales preparados específicamente para esta entrevista.
Para rondas take-home, "usa lo que te ayude, prepárate para explicar en el walk-through" es mejor política. Distintas rondas, distintas reglas.
Cómo comunicar la política
En el invite de entrevista, explícitamente: "Esta es una ronda de coding en vivo. Queremos ver tu razonamiento, así que por favor no uses asistentes IA ni tengas a alguien más ayudando. Eres bienvenida a usar docs, notas y tu IDE normal. El walk-through de seguimiento sondará tu código."
Las candidatas aprecian claridad. El framing vago "actúa con integridad" es peor que specifics — para la honesta (que se preocupa por hacer algo mal) y para atrapar a la deshonesta (que puede claim ambigüedad).
Qué hacer durante la entrevista
- Cámara on. No porque vayas a detectar segundo monitor visualmente — usualmente no — sino porque la norma social de estar en cámara hace shenanigans off-camera psicológicamente más duros.
- Screen share toda la pantalla, no solo la IDE. Las otras ventanas y tab strip son visibles. Esto atrapa casos obvios (un tab de Stack Overflow llamado "interview answer" — sí, pasa).
- Pregunta proceso, no solo outcome. "Recórreme qué piensas antes de tipear." Una candidata coacheada leyendo de otra ventana a menudo pausa raro entre pensar y tipear. El pattern es más visible en conversación que en código.
El follow-up que importa
Lo que sea que pasó durante la ronda en vivo, un "recórreme qué hiciste" de 5 minutos al final resuelve la mayoría de la ambigüedad. Una candidata que escribió su propio código puede replay su razonamiento. Una que copy-pasteó luchará.
ClarityHire saca a la luz una señal de "frecuencia de tab-switch" y "evento de paste" durante rondas coding en vivo — contexto, no veredicto. La entrevistadora ve si hubo 47 tab switches durante una ronda de 30 minutos y puede decidir sondear.
Cuándo escalar
Si tienes evidencia específica (paste claro de off-screen, segunda voz audible, persona visible en reflejo), pausa la entrevista, abórdalo directamente y decide si continuar o terminar. La mayoría de los entrevistadores under-react a evidencia clara y over-react a señal ambigua. Sesgo hacia abordar casos claros prontamente e ignorar ambiguos.
El resumen
No intentes enforzar reglas que no puedes observar. Establece expectativas explícitas, role-apropiadas. Usa el walk-through como tu check real. Reserva respuestas duras para casos no ambiguos. La meta son decisiones de hiring, no atrapar cheaters.