Career Quest — Valutazione delle competenze → raccomandazioni di lavoro

In breve

Career Quest è la piattaforma di orientamento professionale che ho costruito durante lo stage in Guidya, come lead developer di un team di tre con Aymane Bouras e Yassine Mchereg. L'azienda portava i requisiti di business e il tutoraggio; noi li abbiamo trasformati in funzionalità.

Un candidato sostiene delle valutazioni — cognitive, situazionali, tecniche — e ne ricava un profilo di occupabilità e raccomandazioni di lavoro. Il nostro progetto ha ottenuto il primo posto al concorso degli stage dell'EMSI.

Il problema

Un CV dice che cosa una persona ha studiato, non che cosa sa fare. Il compito della piattaforma era misurare la seconda cosa e renderla utile: quali ruoli sono adatti a questa persona, e perché.

Si divide in due problemi che tirano in direzioni opposte. Il punteggio deve essere difendibile — gli stessi risultati grezzi non devono classificare un futuro product manager come un futuro ingegnere del software, e un candidato a cui si dice che è meno adatto a un ruolo merita una ragione. La raccomandazione deve funzionare per chi si è iscritto cinque minuti fa, senza alcuno storico, quanto per chi il sistema conosce bene.

Architettura

Un front end React sopra un'API Django REST, con il motore dei test, il calcolo dei punteggi e le raccomandazioni come moduli separati.

Valutazioni. Sei tipi di test cognitivi — ragionamento verbale, numerico, logico, astratto, spaziale e diagrammatico — più il giudizio situazionale e prove tecniche, ciascuno gestito come sessione a tempo dal motore dei test.
Punteggio. Ogni domanda ha un coefficiente di difficoltà, da 1,0× per una domanda facile a 2,5× per una da esperto. I risultati sono aggregati per dimensione, pesati secondo il profilo cercato e normalizzati su una scala da 0 a 100.
Le raccomandazioni combinano un filtraggio basato sul contenuto per competenze e requisiti, il filtraggio collaborativo quando c'è uno storico da cui imparare, la similarità del coseno per l'abbinamento e il clustering K-Means per segmentare i candidati.
L'API è autenticata con JWT e descritta da uno schema OpenAPI generato dal codice. PostgreSQL conserva tutto ciò che deve durare, Redis fa da cache per Django e Celery esegue i calcoli di raccomandazione che non devono bloccare una richiesta.

Decisioni e compromessi

I pesi appartengono al ruolo, non al candidato

Un unico punteggio globale sarebbe stato più semplice, e sbagliato. Il profilo da ingegnere del software pesa i risultati tecnici al 35% e la comunicazione al 5%; il profilo da product manager quasi li inverte, con il giudizio situazionale al primo posto. Gli stessi risultati danno un'adeguatezza diversa per ogni ruolo — e poiché ogni peso è esplicito e ha un nome, ogni punteggio si riconduce a una dimensione e a un numero. Un punteggio su cui un candidato può fare una domanda, e ricevere una risposta vera, è l'unico che valga la pena mostrargli.

Un sistema ibrido, per via del primo giorno

Il filtraggio collaborativo è la metà potente — trova i ruoli in cui candidati simili a te hanno avuto successo — ma ha bisogno di uno storico, e un nuovo candidato non ne ha. Il filtraggio basato sul contenuto ha bisogno solo dei risultati del candidato stesso, quindi risponde già alla prima visita. Combinarli significa avere raccomandazioni utili subito e che migliorano man mano che la piattaforma impara, invece di restare vuote finché non sono buone.

Il contratto dell'API è generato, non scritto a mano

Con tre sviluppatori, il contratto tra front end e back end è ciò che permette di lavorare in parallelo. Generare la descrizione OpenAPI dal codice Django impediva alla documentazione di allontanarsi dall'implementazione: il front end si costruiva su ciò che l'API faceva davvero, non su ciò che qualcuno ricordava che facesse.

Cosa è stato difficile

Lavorare su un prodotto vero con altre persone. Tre sviluppatori sulla stessa base di codice, davanti alla roadmap di un'azienda invece che a una consegna scolastica: bisognava accordarsi sulle interfacce prima di costruirci dietro, rivedere il lavoro degli altri e decidere insieme che cosa abbandonare. Abbiamo abbandonato delle funzionalità, e consegnato il resto.

È stata anche la prima volta che guidavo altri sviluppatori: dividere il lavoro perché tre persone avanzassero in parallelo senza pestarsi i piedi, e occuparmi delle parti che collegavano i loro pezzi.

Risultato

Il primo posto al concorso degli stage dell'EMSI, e una piattaforma che l'azienda poteva mettere davanti ai candidati: valutazioni cognitive, situazionali e tecniche, un punteggio che si spiega da sé e raccomandazioni fin dalla prima visita.

I prossimi passi

Consolidare il sistema di raccomandazione. Iterando in fretta come team, nel codice convivono diverse generazioni — un servizio base, uno «enhanced» e uno «advanced» — e una sola versione con una valutazione offline varrebbe più di tre senza. Quella valutazione è il vero passo successivo: mettere da parte candidati di cui si conosce il ruolo finale e misurare quante volte le raccomandazioni li avrebbero trovati.

Il repository porta inoltre ancora il nome originale dello stage e alcuni file d'ambiente versionati per errore; ripulirlo è in ritardo.