Los sesgos en los procesos de selección en equipos de ingeniería – Mi reflexión para el 8M

En vísperas del 8M solemos pararnos a reflexionar sobre distintos aspectos de nuestra sociedad. En mi caso, dado que me estoy encargando del proceso de contratación en mi equipo y tengo experiencia en este tema, quiero describir en qué consisten estos procesos, desde una perspectiva de género feminista.

Espero que este artículo te sirva sobretodo si eres un hombre, si perteneces al equipo de recursos humanos (en adelante RRHH) o People and Culture (en adelante P&C) y también si eres una mujer que no pertenece a un equipo masculinizado.

Las experiencias y datos utilizados a continuación se basan en información recogida en charlas y estudios sobre diversidad e inclusión en entornos de trabajo técnicos, vivencias de compañeras y mi propia experiencia tras 13 años picando código.

Imaginemos, en este ejercicio de reflexión, que eres una programadora en busca de trabajo. Permite que te describa el tablero de juego.

1. No apareces en las listas

Tu nombre no aparecerá en las redes sociales de empleo ni en las listas de las agencias de contratación.

En LinkedIn, InfoJobs y similares, si tu título es “programadorA” o “desarrolladorA” directamente no sales en las búsquedas de “programador”. No existes. Eres invisible a no ser que cambies tu título a “programador”, redactes tu perfil en inglés o apliques activamente a alguna oferta. También puedes aumentar tus posibilidades utilizando “tags” buscados, es decir, incluyendo en tu CV términos como “Java”, “AWS”, “CSS”…

Cuando encuentren tu perfil y vean que eres una mujer, automáticamente tu credibilidad desciende 10 puntos. Deberás demostrar por encima de toda duda que eres válida así que cúrrate el CV. No puedes permitirte ser mediocre.

Por cierto, elige bien la foto. Y no des datos a través de los cuales puedan localizarte físicamente.

Por otra parte, las bolsas de trabajo de las agencias de contratación se generan en base a una determinada caja de eco y no se suelen plantear políticas de diversidad. Por ejemplo, muchas agencias se conforman con captar los recursos recién salidos de la universidad. Sin embargo, sabemos que menos del 30% de las personas que se gradúan en carreras STEM son mujeres. Adivina qué aspecto tiene la susodicha bolsa de trabajo.

Pero en realidad no importa mucho, ya que su objetivo es entregar un recurso a una empresa, no mejorar la industria. Para ello es infinitamente más fácil hinchar CVs de recién licenciados mediocres que ir a buscar candidatas a un bootcamp de mujeres o, dios no lo quiera, asistir a eventos técnicos con mayoría de participación femenina para captar talento.

Tu nombre no aparecerá en las redes sociales de empleo ni en las listas de las agencias de contratación.

2.1. Recurso humano

Como recurso que eres, cuando entres en la empresa, te gestionará RRHH. RRHH es un departamento administrativo que no se preocupa por la diversidad y la inclusión (en adelante D&I). Se ocupan de que firmes el contrato, de tu nómina (que probablemente sea muy inferior a la de tus compañeros, pero nunca lo sabrás porque la política de nóminas es de opacidad absoluta), de tu finiquito, de términos legales, etc. Pero no van a ayudarte si te enfrentas al acoso, a la explotación, al techo de cristal o a la discriminación.

Probablemente tu sueldo sea muy inferior a la de tus compañeros, pero nunca lo sabrás porque la política de nóminas es de opacidad absoluta

Cuando se enfrenten a un conflicto, lo resolverán en favor de la empresa, pidiéndote que no desveles públicamente tu situación, despidiéndote u ofuscando el problema dentro de una iniciativa global.

2.2. People and Culture

A veces la empresa llama “People and Culture” (P&C) al equipo de RRHH cuando quieren darle un rollo más cercano. Este departamento se encarga de fomentar relaciones laborales “familiares” o de amistad entre colegas de trabajo. Puede que de vez en cuando hagan talleres opcionales sobre D&I donde, probablemente, nunca verás a ningún ingeniero.

Porque sus iniciativas no están dirigidas al equipo de ingeniería. A los equipos de ingeniería se les permite que se autogestionen.

P&C, RRHH o como se llame, tiene un filtro de visión que le impide ver a través del velo místico que envuelve a ingeniería. Los ingenieros son seres vacíos con cerebros positrónicos cuyas decisiones responden únicamente a la lógica y jamás se ven afectadas por los sesgos del individuo.

Estos androides no son machistas porque se rigen por un sistema “100% meritocrático”. Casualmente el equipo suele estar formado por hombres blancos cis por aplastante mayoría, por lo que sea, pero vamos que son todos un amor.

Las iniciativas de P&C no están dirigidas al equipo de ingeniería. A los equipos de ingeniería se les permite que se autogestionen.

3. La autogestión de ingeniería

Como el equipo técnico se autogestiona y son todo tíos, probablemente sea un tío el que redacta las ofertas, las anuncia en su caja de eco, diseña el proceso, entrevista y elige a los afortunados. Seguramente no se le pase por la cabeza preguntarse por qué hay 0 o prácticamente ninguna mujer interesada. Si se lo plantea lo resuelve con un rápido “bah, mujeres” y sigue con lo suyo. Nadie está pendiente de esto, todo se autogestiona.

Se acepta y celebra como hito en D&I contratar hombres blancos cis mayores de 40, hombres blancos cis gays o incluso hombres blancos cis hetero con un acento distinto. Imagina lo pequeña que debe ser tu caja de eco para que suponga un shock cultural contratar a un hombre gay.

En fin, imaginemos que por alguna razón has conseguido el puesto incluso siendo una humilde señorita.

El equipo de ingeniería es un grupo de tíos que lleva mucho tiempo autogestionándose. Nadie se ha molestado en escribir un código de conducta y si lo hay nadie vigila que se cumpla. Sobretodo en el caso de los veteranos, que pueden seguir comportándose como unos gilipollas tranquilamente.

Están permitidas las bromas y comentarios de cualquier tipo, porque a ver somos amigos. Te dirán que van a tratarte igual que a los demás, que no son capaces de distinguir tu género, lo cual no sólo cancela la parte más fundamental de tu ser, sino que es mentira, ya que  en realidad eres un estereotipo con patas.

Tus compañeros podrán tener arrebatos, contestar de malas maneras e ir a cara perro todo el día, tú no. Tú debes comportarte, si levantas la voz te llamarán la atención sobre el tono. Si te quejas porque se han apropiado de tus ideas te dirán que somos un equipo, no individuos. Si no sonríes te pedirán que lo hagas. Si le preguntas a algún compañero qué es lo que aportas al equipo, probablemente te cuenten alguna historia sobre lo amable y luminosa que eres. Si reclamas un sueldo equitativo te dirán que eso depende del mérito.

Si le preguntas a algún compañero qué es lo que aportas al equipo, probablemente te cuenten alguna historia sobre lo amable y luminosa que eres.

Simplemente existir supondrá un esfuerzo extra, demostrar que vales será una odisea y sólo lo conseguirás si eres una programadora del copón (y extremadamente cabezota). No esperes sobrevivir siendo mediocre. Y todo esto se suma al esfuerzo habitual de estar labrando una carrera profesional.

4. La programadora

A pesar de ser supuestamente incapaces de ver que eres una mujer, te exhibirán como un trofeo si deben explicar sus méritos en diversidad, incluso cuando te hayas ido y ya no haya mujeres programadoras en el equipo.

Si eres LA programadora, no esperes empatía por parte de tus compañeras de otros departamentos o del equipo de RRHH. Como te he comentado, no entienden tu situación.

Puede incluso que se espere de ti que seas la precursora de la D&I del equipo de ingeniería, la “developer advocate” aunque 1) no sea tu puto trabajo 2) no tengas ningún poder.

Eres un estereotipo con patas que juega a ser programadora, dime cómo te legitima eso para llamarle la atención a un veterano sobre su actitud.

Al cabo de unos años en la industria, si estás un poco harta de la situación y ya tienes algo de estabilidad laboral, podrás empezar a reclamar un espacio seguro. Fíjate que no estoy hablando de colgar banderas moradas de las paredes, sólo de reclamar un pequeño espacio no hostil. Y siempre sin molestar, cuidando las formas, sin crispar el tono y por supuesto sin desenmascarar que esa supuesta meritocracia mística con la que se autogestiona eficientemente el equipo de ingeniería es en realidad machismo puro y duro.

esa supuesta meritocracia mística con la que se autogestiona eficientemente el equipo de ingeniería es en realidad machismo puro y duro

Eso si consigues hacerte un hueco en la industria. Porque si eres una mujer, existe un 40% de probabilidad de que abandones en menos del 10 años. Y no por genética, sino porque habría que estar loca para quedarse tanto tiempo en este caldero al fuego.

5.Una experiencia personal

En mis últimos trabajos he tenido la oportunidad, el apoyo y la energía para colaborar en el proceso de contratación de los equipos de backend. (Actualmente estoy buscando este perfil)

Durante estos años he hecho mi trabajo como programadora y luego, aparte, he dedicado tiempo y esfuerzo a entender el problema e intentar solucionarlo. Se ha dado por hecho que esto era más fácil para mí que para cualquiera de mis compañeros varones, como si yo no me hubiera criado en el mismo campo de nabos que ellos.

He dedicado tiempo y esfuerzo a entender el problema e intentar solucionarlo. Se ha dado por hecho que esto era más fácil para mí que para cualquiera de mis compañeros varones.

Tras entender y enfurecerme por las evidencias, me he enfrentado a muchas barreras con el objetivo de contratar, por mis santos ovarios, a más mujeres:

A la hora de diseñar una oferta o un proceso de selección, da un miedo tremendo hablar de “mujeres”. Se considera discriminatorio para los hombres y los hombres se ofenden fácilmente cuando no se sienten incluidos en algún tema. Hay que ir con pies de plomo.

No sabéis lo duro que es estar compaginando estos dos trabajos y que de repente un compañero te suelte una estupidez sobre la meritocracia o te explique la diversidad. O tener que pasar los filtros de P&C para publicar un artículo sobre este tema. Ya ni hablamos del esfuerzo que supondría hacer que la empresa se declarase abiertamente feminista. Esto último, ni lo he intentado tbh.

Me hace gracia porque RRHH nunca se preocupa de la D&I hasta que la única programadora del equipo levanta la voz. Entonces empieza a ser un problema. Es un problema que la programadora esté levantando la voz, no que el equipo de ingeniería sea machista. Es entonces por lo general cuando gente de otros departamentos empieza a involucrarse en tu lucha feminista para ayudarte aportando un toque “corporativo”.

Todo esto me enfurece, pero sobretodo me entristece, porque en nuestra perspectiva corporativa de ponernos de lado y maquillar el problema, estamos perdiendo oportunidades.

La oportunidad de mejorar la comunidad asegurándonos de que nuestros equipos son espacios seguros y enriquecedores en los que las mujeres pueden crecer y convertirse en veteranas y en referentes.

La oportunidad de mejorar nuestros equipos expulsando a las personas tóxicas y educando en una mejor versión de la masculinidad.

La oportunidad de mejorar, en general, aceptando la diversidad de cada persona, trabajando de verdad como equipo, dando igualdad de oportunidades, pagando equitativamente, cuidando de nuestra salud mental.

6. Despedida

Por suerte, la pesadilla ha acabado. Vuelves a ser el hombre, la persona de RRHH o la mujer en un departamento fenimizado que eras cuando empezaste a leer el artículo.

Te agradezco que hayas llegado hasta aquí y me hayas escuchado. Ahora que puedes entenderme un poco mejor, me gustaría que dedicases un tiempo a reflexionar sobre mi situación y la de tantas otras compañeras, aceptes el problema y nos ayudes a solucionarlo.

Necesitamos que tanto los individuos como las empresas se posicionen claramente y lleven a cabo acciones drásticas, con mano firme, porque sólo con ese poder cambiaremos la industria.

5 Consejos para destacar en la prueba técnica

Cada vez más empresas utilizan pruebas técnicas como parte de su proceso de selección. Una de las más habituales es enviarte el enunciado de un problema de negocio (generalmente relacionado con su actividad) para que lo resuelvas en casa. Tu ejercicio será posteriormente evaluado por tus potenciales colegas de trabajo de forma asíncrona, sin tener contacto contigo. En otras palabras, tu carta de presentación en esta parte del proceso es tu código, por lo tanto, debe transmitir todas tus capacidades.

He estado en ambos lados del muro: He sido candidata y he sido revisora, y esto me ha ayudado a aprender varios trucos y normas de “etiqueta” que me gustaría transmitirte a través de los siguientes consejos:

 

Haz preguntas

Lee con detenimiento el ejercicio y si hay algo que no te queda claro pregúntalo. Una de las capacidades más útiles en programación es la empatía. ¡Programar no cosiste en picar código! En nuestro trabajo es muy importante que entendamos bien el contexto de nuestras tareas, el vocabulario de nuestro sector, las necesidades del cliente. Por lo tanto, no dejes de hacer una pregunta porque pienses que vas a quedar mal, al contrario, vas a dar una imagen muy profesional al mostrar tu compromiso con la entrega de valor.

 

Preocúpate por el enfoque, no por terminarlo

No necesito que termines el ejercicio. No voy a ponerlo en producción ni a venderlo. Lo que necesito es saber cómo programas. Por lo tanto, preocúpate más por cosas como, por ejemplo, tu historial de commits.

Los commits son una buena representación de tu metodología. Sólo leyendo el nombre de tus commits podría conjeturar si has escrito los tests antes que el código, si has dado pasos pequeños, qué importancia tiene para ti la fase de refactor, cuánto tiempo has tenido los tests en rojo e incluso tu capacidad para expresarte y tu nivel de inglés.

Lo cierto es que las aplicaciones nunca están terminadas. El código es un ser vivo que muta constantemente a lo largo del tiempo, por lo tanto es irrelevante si te has creado un “Facebook” de una sentada en una noche. Eso sólo demuestra que tenías tiempo para hacerlo. Lo realmente importante es si tu código es legible por otras personas, si eres capaz de transmitir tus conocimientos, si encajas con nuestra cultura ágil.

Piensa: si tuvieras que irte de vacaciones y dejar este código en manos de otra persona, ¿sería fácil para esta persona trabajar con él? Si la respuesta es sí, no importará que no esté terminado.

Escribe un código limpio

Seguramente estoy dejando de hacer otras cosas para revisar tu ejercicio. Tengo poco tiempo: No me obligues a perderlo descifrando tu código.

Hay muchos trucos y recursos que pueden enseñarte a escribir un código legible y expresivo: Leer mucho para adquirir vocabulario, aprender a detectar los olores de código y a refactorizarlos, programar en parejas…

Mejorar en esta habilidad te será muy útil para comunicarte con tus compañeras y compañeros de trabajo, e incluso con tu yo del futuro. Y también será útil, como hemos visto, para la empresa, ya que un código limpio es un código escalable.

Truco: Si necesitas explicarte a través de comentarios por todo el código, algo no va bien. El código debería autodocumentarse a través de la semántica y de los tests.

 

Cuida tu README

El README es el documento en el que se define en qué consiste un proyecto y cómo interactuar con él. Y es lo primero que voy a buscar. Intenta incluir en él toda la información que creas que voy a necesitar:

  • El enunciado del problema: no des por hecho que me lo sé. Puede que hiciera este ejercicio hace meses o años, o tal vez nunca, y ahora está perdido en el laberinto de documentación laboral de la empresa. No me hagas ir a donde quiera que tengamos los enunciados a buscar el tuyo.
  • Cómo levantar la aplicación y ejecutar los tests: En definitiva, cómo utilizar tu programa. No asumas que tengo el mismo entorno que tú instalado en mi ordenador, ponme links a recursos si debo descargarme alguno, concreta versiones, lista requisitos, dime cuál es el comportamiento esperado.
  • Notas: Si quieres decirme algo que no puedes expresar a través del código, puedes reservar una sección del Readme para “Observaciones”. Por ejemplo, si tenías en mente hacer algunas cosas pero no te ha dado tiempo, o no has podido tomar alguna decisión porque preferirías debatirlo con alguien, escribe una lista de “To-Do” explicando qué, por qué y cómo.
    Por otro lado, es importante que cuides las formas. No te tomes confianzas. No soy tu “coleguita de birras”, soy una profesional que está juzgando tu trabajo, por cierto, con un código de conducta bajo el brazo. Dame sólo la información necesaria, de una forma concisa.
    Y sobretodo no utilices el Readme para quejarte de algo o de alguien, para disculparte, o para explicarme tu situación personal. Estas son cosas que debes hablar con tu persona de contacto de la empresa, que es quien debe valorarlo. Si tu situación personal te ha impedido que dediques más tiempo al ejercicio, lo dicho, escribe en la lista de “To-Do” lo que habrías hecho si hubieras podido.

Haznos la vida fácil

En general, lo que se agradece es que tu ejercicio sea fácil de revisar: Fácil de entender y fácil de operar. En este aspecto, mi mayor consejo es que virtualizes tu entorno de pruebas.

Como he comentado seguramente la persona que te lo está revisando tiene poco tiempo y muchos ejercicios en la cola de espera, y es muy incómodo tener que instalarse el entorno concreto que requiera cada ejercicio.

Por eso agradezco mucho cuando una aplicación está Dockerizada, ya que trae todo el entorno preconfigurado, con las versiones necesarias, etc. Ayúdame a centrarme en tu código.

 

¡Espero que estos consejos te sirvan de utilidad en futuras oportunidades laborales! Ten en cuenta que están basados en experiencias y opiniones personales, por lo tanto, no los sigas al pie de la letra. Los ejemplos que he puesto sirven para procesos de selección en los que se valora ante todo la excelencia técnica y el seguimiento de las buenas prácticas, sin embargo puede que no te sirvan si aspiras a un puesto de Data Science o desarrollo de videojuegos, por ejemplo. Investiga siempre qué es lo que se espera de tí y cuáles son los valores de la empresa.

¿Conoces algún otro truco o consejo para superar las pruebas técnicas?

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑