3 entrevistas de pesadilla para desarrolladores de software

Este artículo fue publicado originalmente en .cult por Nadya Primak. .cult es una plataforma comunitaria para desarrolladores con sede en Berlín. Escribimos sobre todo lo relacionado con la carrera, hacemos documentales originales y compartimos muchas otras historias no contadas de desarrolladores de todo el mundo.

La industria de la tecnología no es conocida por tener excelentes procesos de entrevista. Desde notorias entrevistas de pizarra hasta desafíos de algoritmos que requieren un título en informática para comprenderlos, existen todo tipo de estándares y enfoques obsoletos para entrevistar a los desarrolladores que deberían haber desaparecido hace años. Desafortunadamente, como la mayoría de los sistemas heredados que amamos odiar, estos procesos de mantenimiento seguramente aparecerán de vez en cuando en su carrera. O si tienes mala suerte como yo, pueden aparecer un poco más a menudo.

Para ser claros, no estoy escribiendo este artículo para desafiar a empresas específicas o con el propósito de nombrar y humillar. Por cada empresa en la que me he encontrado con estos problemas, hay cientos de miles, si no millones más. Una de las formas más comunes en que las empresas de tecnología practican el control de acceso es hacer que el proceso de la entrevista sea tan difícil que deja a todos, excepto (generalmente) a los hombres blancos graduados en TI, sintiéndose como si no fueran lo suficientemente buenos o no pertenecieran.

En este artículo, leerá algunas de las formas más comunes en que las empresas pueden hacer que su proceso de entrevista sea una pesadilla y, con suerte, podrá reconocerlas desde el principio para que no pierda el tiempo. . Compartiré anécdotas personales de cómo me tocaron y cómo los superé y usted también puede hacerlo.

1. Entrevistas de pizarra

Como dije en la introducción, las entrevistas de pizarra son uno de esos enfoques obsoletos con los que a las empresas tecnológicas todavía les gusta torturarnos. La idea general es pararse frente a una pizarra y escribir un mapeo de pseudocódigo de cómo resolver un algoritmo.

En caso de que no sea inmediatamente obvio por qué este enfoque apesta, déjame explicarte. Obligar a un desarrollador a escribir código a mano es intrínsecamente antinatural porque nos saca del área donde hacemos nuestro mejor trabajo: frente a una computadora. También nos priva de nuestra herramienta más útil: los motores de búsqueda. Sin mencionar que no tiene impacto en la realidad diaria del trabajo.

Esto es especialmente problemático para los desarrolladores autodidactas, ya que los cursos y recursos en línea más baratos tienden a no centrarse en algoritmos, sino en habilidades prácticas más prácticas, como la creación de aplicaciones. Incluso los estudiantes que fueron a una institución tradicional de 4 años y se especializaron en ciencias de la computación a menudo necesitan practicar estos algoritmos cada vez que se presentan a las entrevistas porque son fáciles de olvidar.

He perdido la cuenta de cuántas entrevistas de pizarra he tenido, pero hay algunas que se destacan particularmente en mi memoria. Uno fue para una pequeña empresa en la que estaba entrevistando 1: 1 y el tipo que me entrevistaba era muy torpe. Sabía que el algoritmo que me pedía que escribiera era relativamente simple, pero por alguna razón mi cerebro no podía recordarlo. En lugar de cortar la entrevista antes de tiempo o darme una pista, el entrevistador insistió en arrastrar la parte de la pizarra durante un tiempo ridículamente largo. Pasé más de una hora en su oficina luchando antes de llegar finalmente a la solución. Naturalmente, no conseguí el trabajo, pero estaba tan frustrado después que mi humillación debe haber durado tanto tiempo.

La buena noticia es que las entrevistas de pizarra se están volviendo cada vez más obsoletas. Hay muchas críticas hacia ellos en la comunidad de desarrolladores y probablemente puedo contar con los dedos de una mano cuántos desarrolladores conozco que realmente disfrutan este tipo de entrevistas.

2. Evaluaciones técnicas cronometradas

Si fuiste a la escuela secundaria en los Estados Unidos, probablemente tengas un lugar especial de odio en tu corazón por las pruebas cronometradas. La primera vez que tomé el ACT, obtuve una mala calificación simplemente porque no podía evitar mirar el reloj y preocuparme por cuánto tiempo me quedaba. No ayudó que a la mitad tuviera que ir al baño, pero estaba demasiado nervioso para salir de la habitación por el tiempo que podría estar perdiendo.

Al igual que las entrevistas de pizarra, las evaluaciones técnicas cronometradas tienden a tener componentes algorítmicos. Il y a quelques années, j’ai décidé d’essayer l’une de ces plates-formes où vous passez un test de codage pour créer un profil de développeur pour les entreprises qui souhaitent externaliser les éléments techniques à un tiers (Hired en est un ejemplo).

Hubo tres desafíos diferentes que tuve que completar con éxito para ser admitido en la plataforma. Todos ellos tenían muchos algoritmos y yo había hecho una práctica relativamente mínima. Terminé atascado en el segundo desafío y no tuve tiempo suficiente para completar el tercero. Puede ser muy desmoralizador tomar una prueba y sentir que casi no tienes idea de lo que estás haciendo. Si eres autodidacta, es probable que te sientas bastante desmoralizado porque no estudiaste algoritmos en la universidad.

La presión adicional del tiempo tampoco refleja la realidad de la mayoría de los trabajos de desarrollador. Casi nunca hay una situación en la que solo tenga 20 minutos para completar una tarea; de hecho, la codificación de nuevas funciones suele llevar días o incluso semanas.

La buena noticia es que han aparecido plataformas para ayudar a los desarrolladores a prepararse para estas evaluaciones tecnológicas cronometradas. Hackerrank es probablemente el más popular y es una gran herramienta para que los desarrolladores autodidactas y los licenciados en ciencias de la computación repasen esas habilidades.

A diferencia de las entrevistas de pizarra, las evaluaciones técnicas cronometradas no conducen a ninguna parte. Son convenientes para los gerentes de contratación porque todo lo que tienen que hacer es enviar un enlace al desarrollador y la plataforma administra la prueba y devuelve los resultados. Los gerentes de contratación que eligen usar estas plataformas no son necesariamente perezosos, es posible que solo estén administrando una pequeña empresa o que tengan muchas otras tareas para hacer malabarismos. Pero aún así vale la pena tener cuidado con este tipo de entrevistas y saber en qué te estás metiendo.

3. Pantallas de teléfono

No todas las pantallas de los teléfonos son técnicas. Algunos de ellos son conversaciones casuales con el reclutador o alguien de recursos humanos. De hecho, eso es lo que suele pensar con la pantalla de un teléfono. Sin embargo, a veces las empresas se vuelven creativas o quieren acortar el proceso de la entrevista omitiendo una evaluación técnica y simplemente realizando una sesión de preguntas y respuestas por teléfono.

En teoría, esto podría ser genial. Sin valoraciones técnicas ni proyectos de vivienda. ¡Una llamada telefónica rápida y listo! Esa era exactamente mi mentalidad cuando me encontré por primera vez con este tipo de entrevista. Pero mi actitud cambió rápidamente después de que obtuve el trabajo. Me di cuenta de que algunos de mis colegas no tenían las habilidades requeridas y podían engañar fácilmente al gerente de contratación para que pensara que eran competentes.

El otro peligro de los controles telefónicos es la jerga técnica. Esto es un problema aún mayor para los desarrolladores autodidactas, pero hay tanta jerga en el mundo de la codificación que nadie es inmune. Si alguien me pide por teléfono que defina un término técnico, es muy probable que conozca el concepto, pero no por su nombre, pero haya olvidado el término con el que está asociado o no lo tenga lo suficiente como para tratar de memorizarlo. significa. Esto me ha llevado a fallar en las evaluaciones telefónicas en el pasado o a que me pidan que haga tareas adicionales.

Es bastante raro que una empresa solo haga una pantalla de teléfono y no realice algún tipo de prueba de codificación en línea o en persona, pero es posible que se encuentre con ella si está haciendo un trabajo por contrato o solicitando una empresa que no lo haga. no son muchos puestos técnicos. Solo proceda con precaución.

Comida para llevar

Los desarrolladores autodidactas deben ser más conscientes y, a menudo, prepararse más para las entrevistas que sus compañeros con títulos en informática. A menudo se reduce a la diferencia de estar menos familiarizado con la jerga técnica y los algoritmos, que se enfatizan demasiado en el proceso de la entrevista en comparación con el trabajo diario real de los desarrolladores de software.

Afortunadamente, algunos de los enfoques de entrevista particularmente desagradables, como las entrevistas de pizarra, se vuelven bastante impopulares, pero siempre vale la pena estar preparado y saber que puede tener algunos acertijos de clasificación o una ensalada de palabras en su camino.

También debe tener en cuenta que hay empresas que ofrecen desafíos prácticos de codificación que reflejan un mejor entorno para los programadores, ya que significa que se preocupan por la experiencia de sus candidatos (y probablemente también de sus empleados). Hay espacio para mejorar, pero también se habla mucho sobre cómo mejorar el proceso de mantenimiento en la industria y, afortunadamente, algunas empresas están escuchando y haciendo grandes mejoras.