La prova que ningú no acaba
La majoria de proves tècniques fallen abans que el candidat escrigui una sola línia de codi.
Clonen el repo. Fan npm install. Alguna cosa peta. Quaranta-cinc minuts després estan depurant un mismatch de versió de Ruby, un CocoaPod que falta o una versió de Node que el bundler rebutja. Quan l’app per fi arrenca, ja han cremat la paciència i mig vespre.
Els millors candidats, els que realment vols contractar, són els que més probabilitats tenen de marxar. Tenen opcions. Triaran l’empresa que respecti el seu temps.
La versió clàssica de la prova també té la seva lògica. Un enunciat prescriptiu amb un stack fix et dona entregues comparables entre candidats, i la fricció del setup filtra per aguant. Si contractes en volum per a un rol estret, aquest senyal és útil. Per a un equip petit que contracta en diferents nivells, on dos enginyers sèniors probablement triarien biblioteques de state diferents el primer dia, estàs filtrant per allò que no toca.
El nostre primer candidat del take-home ho va deixar clar. Dues hores barallant-se amb versions de Ruby abans d’escriure cap línia de codi d’aplicació. El Ruby equivocat a cada pas: el Ruby del sistema massa vell, el Ruby de brew massa nou per al bundler vendoritzat. Missatges amunt i avall durant tot el procés. Zero línies de codi al final.
Les preguntes estaven bé. L’experiència de desenvolupament era el problema.
Tracta la prova com un producte
La prova tècnica és la primera interacció real que un candidat té amb la teva cultura d’enginyeria. Tot el que toca li diu alguna cosa sobre tu.
Si el setup està trencat, pensen que el teu codebase està trencat. Si l’enunciat és vague, pensen que les teves specs són vagues. Si el timeline és irreal, pensen que els teus deadlines són irreals.
Per això tracto la prova de la mateixa manera que tractaria un producte:
| Pensament de producte | Aplicat a la prova tècnica |
|---|---|
| Recerca d’usuaris | Què frustra els candidats de les proves tècniques? |
| Requisits clars | Un brief detallat amb wireframes i regles |
| Experiència de desenvolupament | Projecte starter, script de setup, path aliases |
| Documentació | Guies enllaçades per a cada pregunta que puguin tenir |
| Millora contínua | Actualitzar després de cada ronda segons el que va anar malament |
Després de l’incident amb Ruby vaig afegir un script de setup, vaig fixar la versió de Ruby, vaig fer commit d’un Gemfile.lock amb un bundler modern i vaig afegir una secció de troubleshooting al README. El candidat següent estava escrivint codi en menys de dos minuts.
L’script de setup
La millora més gran va ser un setup.sh que s’encarrega de tot.
./setup.shUna sola ordre. El que fa:
- Comprova la versió de Node (ofereix instal·lar-la via nvm)
- Comprova la versió de Ruby (admet rbenv, rvm i asdf)
- Comprova les Xcode CLI tools i CocoaPods
- Executa
yarn install - Executa
bundle installipod install - Et diu exactament què has d’arreglar si alguna cosa va malament
Una advertència honesta: aquest flux dona per fet un Mac, perquè el brief demana una execució a iOS. Un candidat que no en tingui necessita el camí d’Android ben detallat, així que el README documenta yarn android com a alternativa de primera classe i cap requisit no menciona un simulador pel seu nom.
La decisió de disseny clau: l’script pregunta abans d’instal·lar res. Detecta el que el candidat ja té i hi treballa. Qui fa servir rbenv rep rbenv. Qui fa servir rvm rep rvm. El seu entorn es respecta, no se sobreescriu.
Fixa les versions al repo. .ruby-version, .nvmrc, Gemfile.lock amb un bundler modern. Després escriu un script de setup que les llegeixi. Cada minut que un candidat passa en el setup és un minut que no està escrivint codi.
El projecte starter
Dono als candidats un projecte completament configurat. No un repo buit. Una app que funciona.
| Inclòs | Per què |
|---|---|
| TypeScript en mode estricte | Cap ambigüitat sobre les expectatives del llenguatge |
| React Navigation v7 amb params tipats | La navegació és boilerplate, no una prova d’habilitat |
| Jest + React Native Testing Library | Configurat amb mocks de mòduls natius, a punt per escriure tests |
| ESLint + Prettier | Estil de codi consistent des de la primera línia |
Path aliases (@app/*) | Res de cadenes d’imports ../../../ |
| Wrapper de render custom per a tests | NavigationContainer inclòs, només renderitza i fes assert |
| Tres pantalles placeholder | ”Replace me”: punt de partida clar |
| Un smoke test que passa | Prova que el setup funciona abans que canviïn res |
Tot compila. Tot funciona. L’smoke test passa.
No estic avaluant si algú sap configurar un bundler o depurar un path alias de TypeScript. Estic avaluant si sap construir codi d’aplicació. El projecte starter elimina cada obstacle entre «he clonat el repo» i «estic escrivint el meu primer component».
Alguns candidats comencen des de zero de totes maneres. Cap problema, l’starter és opcional. La majoria el fan servir, però, i en comptes de passar la primera hora lluitant amb configuració la passen prenent decisions d’arquitectura.
El brief: clar en el què, no en el com
Algunes proves tècniques especifiquen exactament com construir les coses. Quina biblioteca de state management, quina estructura de carpetes, quin client d’API. Aquest enfocament val la pena quan necessites entregues directament comparables entre elles, o quan el rol va realment d’encaixar dins de convencions molt tancades. Per a nosaltres, aquestes decisions són la part més interessant de l’entrega, així que fixar-les seria tirar a la brossa el senyal que volem.
El nostre brief fa el contrari. Explica en detall què ha de fer l’app i no diu res sobre el com.
- Els wireframes de pantalles mostren les dades i les interaccions (layouts ASCII, no dissenys pixel-perfect)
- Una taula de requisits detalla les regles (màxim 6 elements, afegir des del detall, eliminar des de la llista)
- Una taula de requisits tècnics llista els no negociables (React Native, TypeScript, React Navigation)
El que falta deliberadament: prescripcions d’arquitectura. El candidat tria l’state management, l’estructura de carpetes, el client d’API, l’estratègia de testing.
Un candidat que tria Redux Toolkit em diu alguna cosa diferent d’un que tria Zustand. Cap dels dos no s’equivoca. Tots dos són interessants. Sobre el raonament darrere d’aquesta tria es construeix la conversa del walkthrough.
Si el teu brief especifica l’arquitectura, estàs avaluant compliment, no enginyeria.
Respectar el temps de la gent
Els candidats tenen 7 dies. La feina hauria de ser d’entre 4 i 6 hores.
Ho diem explícitament, al brief i a la guia d’entrega, dues vegades, perquè la gent ho passa per alt la primera vegada.
7 dies donen flexibilitat. Alguns treballen durant un cap de setmana. Alguns fan una hora cada vespre. Alguns es reserven un dissabte al matí. El timeline té en compte que els candidats tenen feines, famílies i una vida fora del procés d’entrevistes.
L’estimació de 4 a 6 hores és honesta. Jo mateix vaig fer la prova per comprovar-ho. Un desenvolupador competent de React Native pot construir les tres pantalles amb state management, integració d’API, tests bàsics i un README en aquest temps. Alguns trien invertir-hi més. És la seva decisió, no la nostra expectativa.
Si un candidat necessita més temps, li’n donem. Sense preguntes. Quedar-se callat i entregar tres dies tard sense explicació és un senyal diferent d’enviar un missatge que digui «necessito un parell de dies més». La comunicació importa.
Digues-los què busques
Al principi, un candidat va passar una hora donant estil als botons perquè havia donat per fet que el polit visual ens importava. No era així. El que ens interessava era l’arquitectura i el testing. Aquella hora es va malgastar per culpa nostra, no seva, perquè no li havíem dit què comptava.
Ara som explícits:
Com penses l'arquitectura i l'organització del codi
Com descompons un problema en components i fluxos de dades
Com prens i justifiques decisions tècniques
Com gestiones casos límit i estats d'error
Fins a quin punt coneixes el teu propi codi
NO estem avaluant disseny visual ni UI pixel-perfect
NO esperem una app production-ready en una prova per fer a casaQuan els candidats saben que ens importa més l’arquitectura i els trade-offs que l’styling, distribueixen el seu temps en conseqüència. Millor senyal per a nosaltres, millor experiència per a ells.
També els expliquem d’entrada que podem fer servir eines automatitzades com a pre-check, però que cada entrega és revisada i puntuada manualment pel panell de contractació.
El walkthrough és una conversa
El candidat lidera els primers 10 minuts:
- Demo de l’app. Recórrer totes les pantalles, mostrar les features funcionant.
- Executar els tests. Mostrar-los passant en directe.
- Recórrer el codi. Explicar l’estructura i les decisions.
Després de la presentació, fem preguntes. L’enfocament importa. Diem:
«No et preocupis si alguna cosa no funciona com esperaves durant la demo. Passa. Si passa, explica’m què creus que ha fallat i com ho arreglaries. Això em diu més que una demo perfecta».
L’objectiu és el senyal, no l’amabilitat. Veure algú diagnosticar un bug al seu propi codi és un dels senyals més clars que pots obtenir d’un enginyer. Un candidat que diu «Ah, crec que el dependency array del useEffect està malament aquí» t’està mostrant exactament com treballa.
Una demo perfecta et diu, sobretot, que ha assajat.
La documentació com a feature de primera classe
La prova ve amb documentació de veritat. No només un README. Un conjunt de fitxers markdown enllaçats:
| Document | Què cobreix |
|---|---|
| Brief de la prova | Requisits, wireframes de pantalles, regles de l’exercici, requisits tècnics |
| Guia d’API | Endpoints, opcions de GraphQL vs REST, recomanacions de clients |
| Projecte starter | Què inclou, estructura del projecte, ordres disponibles, setup de testing |
| Entrega i Walkthrough | Com entregar, què passa al walkthrough, consells |
| Stretch Goals | Extres opcionals i què demostra cadascun |
La majoria de preguntes que un candidat pugui tenir estan respostes abans que necessiti fer-les. L’objectiu és eliminar l’ambigüitat. No vull avaluar fins a quin punt algú interpreta un brief vague. Vull avaluar com construeix software quan els requisits són clars.
Què canviaria la propera vegada
La prova no està acabada. Això és el que tinc a la meva llista:
- Un walkthrough en vídeo del projecte starter. Un Loom de 3 minuts que mostri l’estructura de carpetes, com executar-lo i per on començar. Algunes persones aprenen millor amb vídeo que amb docs.
- Un fitxer
.env.example. La prova fa servir una API pública sense keys, però fer commit del fitxer marca el patró correcte. - Provar el setup en una màquina neta abans de cada ronda de contractació. Un portàtil de desenvolupador acumula anys d’eines, i qualsevol suposició del tipus «tothom té això instal·lat» cau en el moment en què un candidat executa l’script en una instal·lació d’OS nova.
L’estructura està bé igualment. Script de setup. Projecte starter. Brief clar. Timeline honest. Documentació de veritat. Criteris d’avaluació transparents.
Si estàs dissenyant una prova tècnica i els candidats segueixen abandonant, no miris les preguntes primer. Mira l’experiència de desenvolupament. La millor prova tècnica és aquella en què el candidat passa el temps en allò que realment estàs avaluant, i ni un moment barallant-se amb el setup.
Els altres posts d’aquesta sèrie sobre contractació cobreixen per què vaig redissenyar la prova, consells per a candidats que la fan, com funciona la puntuació i l’app que vaig construir per portar les entrevistes.
