Cómo se Diseñan los Procesos de Entrevistas
En este video vemos conceptos fundamentales de cómo se diseña y se piensa un proceso de entrevistas desde el punto de vista de la empresa: qué hace una empresa para entrevistar (y cómo lo hace), revela mucho sobre la empresa y sobre el talento que ya trabaja ahí.
🔗 Recursos
🥅 Objetivos de entrevistas
- Hiring Plan = Candidates * Pass-rate
- Costo del proceso de entrevistas = Candidatos * costo promedio de entrevistar
- (100$ x entrevista) x 2(entrevistas promedio) x 20 candidatos(5% pass-rate) = 4,000$ de costo de entrevista por hire
- Buscando Señal
- Predictivo del performance en el trabajo
- Evaluar al talento efectivamente
- Candidate Experience (Duración, Calidad de la entrevista)
- Importante no pre-filtrar candidatos (hireables)
- Tener una experiencia reputable
🌱 Diseño clásico Seed-Serie A
Las empresas chicas no tienen ni tiempo, ni recursos ni branding para tener un gran volumen de candidatos. Tienen procesos de entrevistas más cortos y más acomodables que empresas grandes.
- Recruiter Screening
- Takehome
- Live Coding con Profile specific challenge
- Cultural Fit
👔 Diseño clásico Serie B+
En esta etapa las empresas ya son conocidas y tienen reputación. Tienen estabilidad y recursos. La competencia es alta y los procesos se enfocan en filtrar.
- Recruiter Screening
- Technical Phone Screen
- Onsite
- Live Coding
- System Design
- Profile specific challenge
- Hiring Manager / Cultural Fit
- Offer Stage
📚 Tipos de Entrevistas
Challenges automáticos
Las plataformas mas populares son CoderByte, CodeSignal y HackerRank.
Los challenges automatizados se usan como reemplazo de la “Technical Phone Screen”. Los ejercicios tienden a ser nivel “Leetcode Easy”.
Algunos challenges te dejan gradear al talento con puntajes , pudiendo hacer un ranking de los Candidatos.
El talento en general no repudia estos ejercicios. No tienen el stress de los LiveCoding ni se usan para challenges demasiado difíciles.
-
Technical Conversation
En esta entrevista un desarrollador Sr. evalúa tu experiencia, como hablas de tecnología y que problemas resolviste en el pasado. Es casi una behavioral.
Este tipo de entrevista hace difícil comparar a candidatos entre sí y tiene un problema serio: el mal talento aprueba al mal talento. Puede ser una entrevista trivial.
Es una entrevista muy común en escaños bajos de talento porque los evaluadores no pueden pasar otro tipo de entrevistas, entonces es lo único que saben tomar.
💡Esta entrevista tiene frecuentes falsos positivos. Hay candidatos con buena articulación que pueden dar una excelente impresión en esta entrevista sin tener alto nivel técnico.
Takehome challenges
El takehome es una tarea de entre 4 y 16 horas de trabajo donde hay que implementar un sistema con algunos requerimientos y objetivos de mediano plazo.
El takehome ha sido la entrevista de-facto para el developer remoto en los últimos 5 años.
En estados unidos esta mal vista por los candidatos y por las empresas. Las mejores empresas del mercado usan Live Coding, entonces el mejor talento del mercado practica para las Live Coding. Entonces los candidatos no prefieren Takehomes que toman mas tiempo, ni respetan del todo a las empresas que dependen de ese tipo de challenge.
Por el lado de las empresas, el método de examinación tiene un bias de calidad: el talento que prefiere Takehomes es el que sabe que no pasa LiveCoding. El candidate pool es peor.
Hay una justificación para utilizar takehomes para el mercado remoto con extranjeros: el handicap de lenguaje.
Las empresas que usan takehomes lo hacen para adaptarse a algun mercado o porque piensan que se ahorran tiempo de entrevistado.
La realidad es que evaluar takehomes es difícil - es subjetivo, es fácil de hacer “trampa” (usar mucha AI o copiar otras soluciones) y requiere diseñar y pulir el ejercicio frecuentemente.
Uno de los desafíos de evaluación es que la cantidad de horas invertidas cambia la calidad de la entrega - y uno puede ver una entrega razonable hecha en 4 horas y una espectacular con 20 horas puestas y “gana” la segunda.
Gabriel recomienda preferir Live Coding sobre Takehomes para la evaluación de talento.
System Design
En esta entrevista se le pide al candidato que diseñe o mejore un sistema de componentes que cumple requerimientos funcionales (features y funcionalidad para el usuario) y no funcionales (scalability, reliability).
Esta entrevista es más importante para roles de backend, data e infraestructura que en frontend, pero cualquier perfil fullstack tiene que tener nociones generales de sistemas.
Estas entrevistas evalùan efectivamente:
- Capacidad comunicacional
- Experiencia trabajando en sistemas complejos
- Conocimiento téorico de como armar sistemas complejos
Esta entrevista se vuelve más importante con el seniority, porque es esa experiencia la que te deja ver sistemas complejos en empresas mas maduras. Por eso, esta entrevista tiende a filtrar calidad de experiencia, y aunque no es una gran evaluación, tiene un Selection Bias muy positivo.
Live Coding
La live coding es un challenge de entre 45 y 60 minutos donde hay que resolver algún tipo de ejercicio de código en vivo.
Leetcode
Las empresas mas grandes del mundo usan el formato Leetcode, que implica implementar algoritmos avanzados y estructuras de datos para resolver problemas bien definidos.
Estos ejercicios requieren tener buenas bases teóricas de programación, práctica y estar en excelentes condiciones al momento de la evaluación.
Desafíos Realistas
Los candidatos y los entrevistadores preferirían tomar ejercicios que se parezcan mas al día a día del trabajo en si - diseño de APIs, crear componentes y librerías y problemas mas cotidianos.
En ambos casos las live coding resuelven problemas que tiene el takehome:
- No se pueden copiar soluciones
- La evaluación es (más) objetiva
- Se descartan candidatos con red flags
- Comunicacionales
- Capacidad de entender y escribir soluciones
El pass-rate de las Live Coding es el más bajo de todas las entrevistas. Eso implica que es la más cara de hacer, y también la que rinde el mejor talento.
La peor desventaja para las empresas de este tipo de entrevista es el costo de hacerlas, ya que requieren tiempo de programadores y requiere más candidatos para conseguir un pass.
Las empresas que no usan Live Coding encuentran dificultades introduciendolas al proceso de entrevistas. Su talento actual posiblemente no pase ese tipo de entrevistas creando el cliché de “hacen entrevistas que no pasan”.
Por eso no hacer LiveCoding desde el inicio es un problema de largo plazo. Gabriel recomienda a empresas siempre tener una instancia de LiveCoding.
Work Tests
El Work Test es un período de prueba pago de 1 o 2 semanas.
En estas semanas, se hace un onboarding ligero y se le asignan tareas con un scope reducido al candidato para ver como se desempeña con todas las herramientas requeridas. Desde poner código en producción, comunicación, manejo de tareas, etc.
No hay nada más parecido a trabajar que trabajar. Este método de evaluación es muy completo y realista.
El problema es de Selection Bias. La gente que puede hacer un work-test va a tender a ser desempleada, trayendote un pool de menor calidad.
Como método de evaluación en si también es caro: no solo por pagarle al candidato, sino porque requiere mucha atención de managers o ingenieros para que el proceso sea fructífero.
Dicho esto, la gente que es muy productiva y con poca preparación para entrevistas tiene mucho que ganar en este tipo de entrevistas.
🛋️ TL;DR
| Entrevista | PassRate (o difficultad) | Señal | Costo | Selection Bias |
|---|---|---|---|---|
| Automated Coding Challenges | 35% | Baja | menos de 10$ | Positivo |
| Technical Conversation | 80%+ | Baja | 100$ | Negativo |
| Takehome | 50% | Media | 50$ | Negativo |
| System Design | 30% | Media | 100$ | Positivo |
| Live Coding | 10% | Alta | 100$ | Positivo |
| Work Test | 30% | Altísima | 2000$+ | Negativo |
♻️ Dificultad de procesos de entrevistas
La dificultad del proceso de entrevistas, usualmente medido con pass-rate, es un indicador muy fuerte de la calidad del talento. Y la calidad del talento es lo más importante que puede tener una empresa.
Una empresa de tecnología va a gastar más del 50% de su presupuesto el talento. Las mejores empresas del mundo hablan constantemente de como encontrar y mejorar al talento porque es lo que hace que todo funcione.
Por eso yo siempre sugieron tanto a las empresas como a los candidatos que se enfoquen en procesos de entrevistas difíciles.
Tanto candidatos como empresas tienen un incentivo de hacer procesos de entrevistas faciles, para reducir costos y esfuerzo. Pero esto a la larga es caro, porque baja la productividad y las chances de que la empresa crezca y comparta botín con los empleados.
El proceso de entrevistas de una empresa revela mucho sobre cuanto invierte la empresa en elegir talento, y si invierten poco, seguramente tomen malas decisiones. En USA, es común que candidatos se bajen de procesos de entrevistas cuando ven que son demasiado fáciles.
📈 Tiers de dificultad y correlación con compensación
Podes catalogar la calidad de la empresa por su proceso de entrevistas - en tiers desde A hasta C. En este cuadro resumimos cómo lucen los procesos de entrevistas de empresas de distinta calidad.
| Entrevista | S-Tier | A-Tier | B-Tier | C-Tier |
|---|---|---|---|---|
| Automated Coding Challenges | ✅ | ✅ | ❌ | ❌ |
| Live Coding (easy/medium) | ❌ | ✅ | ❌ | ❌ |
| Live Coding (hard) | ✅ | ❌ | ❌ | ❌ |
| System Design | ✅ | ✅ | ✅ | ❌ |
| Takehome (easy/short) | ❌ | ❌ | ✅ | ✅ |
| Takehome (hard/lengthy) | ❌ | ✅ | ✅ | ❌ |
| Technical Conversation | ❌ | ✅ | ✅ | ✅ |
La dificultad de entrevistas tiene una relación causal con la compensación. Mientras más difícil más pagan.
| Tier | S | A | B | C |
|---|---|---|---|---|
| Compensación | 150-250k/yr | 100-150k/yr | 70-100k/yr | menos de 70k/yr |