Así se ha construido el modelo que impulsa la Brújula Salarial
Nuestra nueva brújula salarial YA HA VISTO LA LUZ. Por si no la has visitado o no sabes de lo que hablamos, te dejamos por aquí un post en el que explicamos todo lo que has de saber.
La brújula es un comparador de salarios con el que podrás conocer tu posición real en el sector, compararte con otros roles o características.
Por supuesto, la brújula funciona con los datos de los más de 25.000 manfreditas que ya nos acompañáis.
¿Queréis conocer más a fondo el mecanismo del modelo de datos que lo impulsa? ¡DENTRO POST!
// Cómo está construido el modelo
El sistema utilizado para construir la brújula está basado en una tradicional función de densidad de probabilidad. Sin embargo, no es una distribución sin más. En las siguientes líneas te contaremos por qué, qué decisiones hemos tomado en la evolución del producto y cómo hemos salvado los diferentes obstáculos.
Ahí, pues, ¡vamos con la cronología del desarrollo!
// Cronología y decisiones
En un primer momento, la idea era afrontarlo como un modelo de Machine Learning. Descubrimos, no obstante, que existiría un problema importante con la explicabilidad del modelo. Es decir, el sistema devolvería un resultado con un margen de error y un efecto caja negra, que preferiríamos evitar para que el usuario tuviera más transparencia y una mejor habilidad de interpretar los resultados
En dicho punto, se convirtió en una herramienta más visual. Para cada caso de uso, se muestra la distribución de probabilidad de ganar unas cantidades u otras. De este modo, al mostrarte una gráfica en la que ves, para cada rango salarial, la probabilidad que tienes de ganarlo, se genera una interpretación más accesible y honesta, ya que no incluye ningún modelado de datos.
En la simplicidad de la herramienta se encuentran la honestidad de sus datos y la rendición de cuentas a la persona que la utilice: lo que ves es tanto el resultado como las probabilidades de conseguir otros resultados.
Lo que aspirábamos a construir es una distribución con una lógica por encima. ¿Para qué? Para asegurar la robustez de los datos. Para no mostrar informaciones para las que tengamos poca cantidad de datos y por eso demos resultados extraños.
Hemos validado que la distribución de los estadísticos se corresponden con el tipo de distribución que queremos. Analizando la base de datos, se llegó a la conclusión de que cuando se bajaba de alrededor de las 130 muestras, los estadísticos empezaban a divergir. Por tanto, concluimos que los resultados estables debían estar por encima de esa cifra. Hasta que no se obtienen 200 muestras de un dato, no son tenidos en cuenta.
De este modo, la duda parece ser clave: en esta concepción es muy probable que haya características relevantes, que impactan en el salario, pero quedan ignoradas al no haber muestras suficientes.
Y la respuesta es: sí. Para rescatar características que son relevantes, pero nos la hemos saltado al crear la distribución inicial, hemos implementado un mecanismo de backtracking. Simplificando un poco, para esto, creamos conjuntos de datos diferentes y, viendo el parecido de los usuarios de las diferentes distribuciones, modificamos la distribución original. Por ejemplo, pensemos en un Backend Developer con 10 años de experiencia, con experiencia en Java y Spring y habla inglés, pero en este caso en particular, inglés es una característica que ha quedado fuera de la distribución inicial. La lógica del backtracking tratará de construir una distribución basada en perfiles parecidos que incluyan el inglés y calculará el impacto del inglés en el salario para así computarlo en el resultado final.
// Validación de datos
Nuestra mayor preocupación ha sido en todo momento que los datos que se fueran a ofrecer correspondieran a una visión realista del mercado.
Que la brújula funcione sobre datos reales, los de las personas de nuestra base de datos, es un primer paso. No obstante, para tener la certeza de que los resultados mostrados se corresponden con la realidad, hemos llevado a cabo varias fases de validación.
En unas primeras fases se compararon los resultados con los obtenidos en informes por otras compañías del sector, como pueden ser Randstad o Hays. Estas comparativas nos han permitido identificar arquetipos desalineados y ajustarlos.
También hemos construido nuestro propio sistema de arquetipos interno. Tanto en colaboración con varios de nuestros Scouts, con quienes se han validado los modelos, como a través de la construcción de un sistema de arquetipos, del que puedes saber más AQUÍ, hemos conseguido ajustar los resultados a la realidad del mercado técnico español.
Las validaciones han servido para analizar fenómenos como el de los roles agrupados. En estos análisis descubrimos que había algunos roles, como Frontend-Backend-FullStack o Product Manager-Project Manager, que daban resultados muy parecidos. Lo que sucedía es que muchas de las personas de nuestra base de datos tienen varios roles y un salario deseado global. Además de monitorizar resultados, ajustar arquetipos, podemos y tenemos en mente limitar roles, de alguna manera.
// Qué datos se piden y por qué
Para acceder a la brújula se piden cuatro datos:
- Rol / roles en los que se trabaja
- Salario al que se aspira
- Ubicación geográfica
- Tecnologías y herramientas
- Idiomas
Estos datos son los que más se repiten a la hora de modelar un salario, o el proceso de obtención de un salario. En la elección de los mismos también entra el hecho de que son datos que ya existen en muchos de los Perfiles de la base de datos de Manfred, por lo que la es la mejor opción para poder tener la Brújula funcionando.
La información que no tenemos y creemos que puede ser interesante, se irá añadiendo en futuras releases. Por ejemplo, localización, tipo de empresa, tamaño o sector, que son otras informaciones que hasta que no se acumulen, no nos dirán nada.
La idea para los próximos pasos es ir acumulando esos nuevos datos, aunque el algoritmo YA los soporta. Esto es, si tenemos suficientes datos en una categoría concreta el algoritmo lo va a tener en cuenta. Toda la información que se ha tenido en cuenta para obtener el resultado que el usuario está viendo se le ofrece en la propia pantalla. De este modo, la explicabilidad se cumple.
// Qué sucede cuando no hay datos
Es lo que comentábamos líneas arriba. Sin una muestra de 200 datos, no podemos asegurar que la distribución que ofrezcamos sea robusta. Si los datos que no tienen suficientes individuos son diferentes de ubicación y/o rol, simplemente te detallaremos que no han sido tenidos en cuenta para construir la distribución.
Pero, si los datos para los que no tenemos suficientes muestras son ubicación y/o rol, te mostraremos una pantalla como esta:
Por supuesto, el modelo sois vosotros y vosotras. En ese caso, te pediremos que nos dejes tus datos y te avisaremos cuando tengamos disponible la información para ti.