Com funciona la validació de Conectia: el procés complet darrere d'un filtratge tècnic a nivell de CTO
La majoria d'empreses de nearshore despatxen la seva validació amb un «rigorosa» i prou. Reps un segell en una pàgina web, potser un paràgraf sobre «un filtratge tècnic exhaustiu», i cap visibilitat sobre què passa de debò entre que un candidat es presenta i que el seu perfil t'arriba a les mans.
Aquesta opacitat té un motiu: la majoria de processos de validació són superficials. Una prova de codi, una entrevista de competències i una trucada de referències. N'hi ha prou per descartar els qui clarament no donen la talla, però se li escapen els errors que costen diners de veritat: l'arquitecte incapaç de raonar trade-offs, el desenvolupador sènior que escriu codi que funciona però que no es pot mantenir, l'enginyer que es bloqueja quan ha de comunicar un impediment.
Així que t'explicaré exactament en què consisteix el nostre procés de validació, pas a pas. Sense abstraccions i sense vernís de màrqueting.
Per què importa una validació dissenyada per CTOs
El filtratge tècnic tradicional el van dissenyar reclutadors i equips de recursos humans. Optimitza allò que un reclutador pot mesurar: anys d'experiència, paraules clau al currículum, aprovats i suspesos en trencaclosques algorítmics. Són senyals que correlacionen poc amb el rendiment real en enginyeria de producció.
La nostra validació la vam dissenyar CTOs — jo inclòs — que hem contractat, gestionat i acomiadat enginyers en entorns de producció. Sabem què falla a escala, què es trenca sota la pressió dels terminis i què separa l'enginyer que sap construir una funcionalitat del que sap construir un sistema.
Aquesta experiència dona forma a cada criteri d'avaluació. No avaluem el que és fàcil d'avaluar: avaluem el que de debò prediu l'èxit en un rol d'enginyeria de producció en remot i entre fusos horaris.
Els cinc pilars
Pilar 1: arquitectura i disseny de sistemes
Què hi avaluem: la capacitat de dissenyar sistemes amb restriccions reals, no escenaris de manual.
Cada candidat rep un repte de disseny basat en un escenari de producció real. Les restriccions són concretes: una base d'usuaris definida, una forquilla de pressupost, una mida d'equip, requisits de compliment normatiu, objectius d'escalat. No hi busquem la resposta «correcta». Hi avaluem:
- Raonament de trade-offs. Saben argumentar per què han triat una base de dades i no una altra, un patró de comunicació i no un altre, una estratègia de desplegament i no una altra — i què sacrifiquen amb cada elecció?
- Consciència dels modes de fallada. Pensen en què passa quan un servei cau, quan el trànsit es dispara, quan una API de tercers canvia el contracte? Els enginyers que només dissenyen per al camí feliç construeixen sistemes fràgils.
- Comunicació de les decisions. Saben explicar la seva arquitectura a algú que no era a la sala? Importa perquè, en remot, l'arquitecte ha de documentar decisions que un equip que comparteix oficina absorbiria per osmosi.
Els candidats tenen temps per preparar-s'ho. No és cap emboscada davant d'una pissarra: és una conversa estructurada que reprodueix com es prenen de veritat les decisions d'arquitectura en un equip d'enginyeria ben portat.
Pilar 2: qualitat del codi i ofici
Què hi avaluem: la capacitat d'escriure codi de producció, no codi d'entrevista.
Revisem codi de debò. Els candidats presenten un projecte recent o resolen un exercici per fer a casa que reprodueix feina real de producció — ni un algorisme d'ordenació ni un exercici trivial. Hi avaluem:
- Estructura neta. El codi està organitzat de manera que un altre desenvolupador s'hi pugui orientar sense visita guiada? Noms amb significat, separació lògica de responsabilitats, patrons consistents.
- Gestió d'errors. El codi cobreix casos límit, entrades inesperades i escenaris de fallada? O només funciona en el camí feliç?
- Disciplina de testing. Hi ha tests? Tenen sentit — comproven comportament, no detalls d'implementació? La cobertura és proporcional a la criticitat del codi?
- Separació de responsabilitats. La lògica de negoci està entrelligada amb el codi d'infraestructura? La capa de presentació es barreja amb l'accés a dades? Els enginyers que mantenen les fronteres netes lliuren sistemes mantenibles.
No fem servir cap puntuació automàtica de codi. Un enginyer sènior revisa l'entrega i en redacta una valoració per escrit. L'avaluació té en compte el llenguatge, el framework i el context: el Go idiomàtic no s'assembla al Python idiomàtic, i ho valorem en conseqüència.
Pilar 3: competència en IA
Què hi avaluem: un ús eficaç, i amb criteri, de les eines de desenvolupament amb IA.
Aquest és el pilar que la majoria d'empreses de nearshore se salten directament. El 2025, un enginyer que no treu profit de les eines d'IA renuncia a una part gens menyspreable de la seva productivitat potencial. Però un enginyer que les fa servir sense criteri és un perill.
Hi avaluem:
- Fluïdesa amb les eines. Saben fer servir GitHub Copilot, Cursor, Claude o equivalents per accelerar les tasques rutinàries — generar boilerplate, escriure tests, documentar, refactoritzar?
- Prompt engineering. Saben escriure prompts que produeixin resultats útils? Saben donar context, fixar restriccions i iterar sobre el que genera la IA?
- Judici crític. És el criteri més important. Saben detectar quan el codi generat per IA és incorrecte, té errors subtils o és arquitectònicament inadequat? Revisen la sortida de la IA amb el mateix rigor que aplicarien al pull request d'un junior?
- Límits d'ús. Saben quan toca fer servir la IA i quan no? El codi sensible per a la seguretat, la lògica de negoci complexa i els reptes algorítmics nous sovint demanen un enfocament humà d'entrada. Els enginyers que ho deleguen tot a la IA produeixen sistemes fràgils i mal entesos.
Ho avaluem amb exercicis pràctics: refactora aquest mòdul amb ajuda d'IA, depura aquest codi generat per IA, valora aquesta arquitectura proposada per una IA. La puntuació pesa més el judici que la velocitat.
Pilar 4: comunicació i col·laboració
Què hi avaluem: la capacitat de treballar bé en un entorn remot, asíncron i repartit entre fusos horaris.
L'enginyeria en remot no falla per incompetència tècnica. Falla perquè algú no va avisar d'un impediment fins al standup de tres dies després, o perquè la descripció d'un pull request deia «he arreglat coses» en lloc d'explicar el canvi i les seves implicacions.
Hi avaluem:
- Claredat per escrit. Saben redactar la descripció d'un ticket, un comentari de PR útil, una actualització d'estat que un PM entengui? Els plantegem escenaris i avaluem la qualitat del que escriuen.
- Fluïdesa oral. Anglès parlat (o la llengua de treball que toqui) a un nivell suficient per a discussions tècniques, debats d'arquitectura i trucades amb el client. No cal que sigui sense accent: ha de ser funcionalment clar.
- Avisar dels problemes abans que esclatin. Els presentem escenaris en què un projecte va de dret cap al problema i avaluem si el candidat el posa sobre la taula, proposa alternatives o calla esperant que es resolgui sol.
- Disciplina de fusos horaris. Entenen la mecànica del treball asíncron? Saben estructurar la jornada per maximitzar les hores de coincidència amb el client? Documenten el context perquè la persona següent de la cadena pugui continuar sense esperar ningú?
Aquest pilar elimina més candidats del que la majoria de gent es pensa. L'habilitat tècnica sense habilitat comunicativa produeix enginyers que construeixen el que no toca, lentament i en silenci.
Pilar 5: trajectòria professional
Què hi avaluem: experiència verificada en entorns de producció que s'assemblin als dels nostres clients.
- Verificació laboral. Confirmem càrrecs, durades i responsabilitats anteriors. No amb un formulari: amb verificació directa.
- Referències. Parlem amb antics caps o companys que poden valorar com treballava el candidat, no només confirmar que va passar per l'empresa.
- Encaix cultural. Avaluem l'encaix amb entorns d'startup i scale-up: comoditat amb l'ambigüitat, capacitat de treballar sense especificacions detallades, voluntat de fer-se seus els resultats i no limitar-se a tancar tasques.
Aquest pilar existeix perquè les credencials sense context no són fiables. Deu anys en una gran corporació mantenint un únic servei no preparen ningú per a una startup on haurà de construir tres serveis, desplegar-los i mantenir-los.
Els números
- Un 3% de taxa d'acceptació sumant els cinc pilars. De cada 100 candidats que entren al procés, en surten quatre.
- Experiència mínima dels enginyers acceptats: 6 anys desenvolupant programari en producció.
- Temps des de la candidatura fins a completar la validació: de 5 a 7 dies laborables.
- Seguiment continu del rendiment: enquestes de satisfacció al client als 30, 60 i 90 dies. Els enginyers que cauen per sota dels llindars de rendiment es marquen per revisar-los o substituir-los.
La política de substitució
Si un enginyer no compleix les teves expectatives durant els primers 30 dies, el substituïm sense cap cost addicional. Sense discussions ni negociacions. El candidat substitut surt del mateix grup validat i compleix els mateixos requisits tècnics.
Aquesta política existeix perquè confiem en el procés de validació — i perquè sabem que fins i tot un procés sòlid produeix, de tant en tant, un mal encaix. Quan passa, el cost ha de ser nostre, no teu.
Què vol dir això per a tu
Quan reps un match de Conectia, tots els enginyers que en formen part ja han superat un procés de validació que la majoria de pipelines de contractació sènior no poden igualar. No ets el primer filtre tècnic: ets la comprovació final d'encaix.
Això vol dir que el temps que has de dedicar a avaluar cau en picat. En lloc de muntar el teu propi procés d'entrevistes tècniques de diverses rondes amb desenes de candidats, revises el match: enginyers ja validats que encaixen amb els teus requisits. La majoria de clients confirmen en menys d'una setmana d'haver rebut els perfils.
Vols veure el nivell dels enginyers que superen aquest procés? Demana un match validat per CTOs per a la vacant que tinguis oberta — lliurat en 72 hores.
