Entrevisté a un buen número de candidatos de ingeniería de software y liderazgo de ingeniería mientras trabajaba en Google. El proceso puede haber cambiado un poco desde que me fui a fines de 2010, pero así es como era entonces:
- Google tenía un proceso de contratación unificado para la ingeniería. Candidatos entrevistados para Ingeniería, no para ningún equipo en particular. Los ingenieros en el grupo de entrevistas fueron asignados aleatoriamente a candidatos, tanto para pantallas de teléfono como en sitios. Este enfoque fue diseñado para establecer una barra de contratación constante y optimizar la asignación de recursos, pero descubrí que hizo que las entrevistas fueran algo impersonales y desmotivados.
- La pantalla del teléfono generalmente se enfocaría en una pregunta de codificación en la que el candidato trabajaría a través de un documento de Google. Se esperaba que el código fuera código real, no pseudocódigo, pero no se esperaba que se compilara. Las preguntas tampoco fueron tan difíciles, por ejemplo, determinar si dos cadenas eran anagramas. Más que una prueba de humo (es decir, no solo FizzBuzz), pero tampoco da miedo.
- La entrevista en el lugar fue un día completo en una habitación individual, dividida por el almuerzo. Los entrevistadores decidirían qué preguntas usarían, y generalmente no se coordinarían de antemano. En cambio, llenarían una hoja de papel impresa que permanecía en la habitación con el área general que habían cubierto (por ejemplo, Algoritmos, Codificación, Diseño) y qué problema habían usado (por ejemplo, Invertir árbol binario). Los entrevistadores no dieron ninguna indicación del desempeño del candidato en la hoja. Mi problema favorito era la segmentación de cadenas, que Google ahora debería tener en su lista de preguntas prohibidas (cf. Retirar un gran problema de entrevista).
- Para la codificación, Google exigió que los candidatos usaran la pizarra o el papel en lugar de una computadora portátil. Si bien conozco a personas que defienden la codificación de pizarras blancas como una técnica de entrevista, personalmente encontré, y todavía lo encuentro absurdo.
- Después de la entrevista, un entrevistador tuvo que completar comentarios extensos, incluida una transcripción de cualquier código que el candidato escribió. El entrevistador también le asignó al candidato un puntaje de 1.0 a 4.0, donde 3.0 era el umbral de contratación versus no contratación. Los comentarios de los entrevistadores se recopilaron y se enviaron a un comité de contratación, que finalmente decidió si seguir adelante con una oferta, rechazar al candidato o dar otro paso más.
Si bien aprecio que Google haya logrado contratar ingenieros increíbles, a veces me pregunto si eso es a pesar de su proceso de entrevista o por eso. La naturaleza impersonal de la contratación unificada, el uso arcaico de la codificación de pizarra, el tedioso proceso de retroalimentación, me parecen carentes de la eficacia y la eficiencia que esperaría de una empresa de tecnología de primer nivel. Sospecho que Google se sale con la suya porque tiene una cartera de contratación tan fuerte. Advierto a otras compañías que no asuman que lo que funciona para Google funcionará para ellos.
Finalmente, si está pensando en postularse a Google como ingeniero de software y le preocupa el proceso de contratación, hágase un favor y obtenga una copia de la entrevista de Cracking the Coding de Gayle Laakmann McDowell.
- ¿Amazon India rechaza las solicitudes de empleo para un candidato con 9 años de experiencia en una empresa india de servicios de TI y no en ninguna empresa basada en productos?
- Los bancos de inversión suelen contratar a las personas más ambiciosas, estudiosas y trabajadoras. ¿Por qué la banca de inversión todavía está asociada con mucho libertinaje?
- ¿Contratarías a una persona transgénero?
- ¿Por qué Google y otras empresas tecnológicas destacadas se centran tanto en la educación al contratar programadores?
- ¿Por qué booking.com contrata a todos los programadores destacados del mundo?