Com Funciona la Validació de Conectia: El Procés Complet Darrere la Validació Tècnica a Nivell CTO
La majoria d'empreses nearshore descriuen la seva validació com a "rigorosa" i ho deixen aquí. Reps una insignia en un lloc web, potser un paràgraf sobre "filtratge tècnic exhaustiu" i zero visibilitat sobre què passa realment entre que un candidat aplica i tu reps el seu perfil.
Aquesta opacitat existeix per una raó: la majoria dels processos de validació són superficials. Un test de codi, una entrevista conductual i una verificació de referències. És suficient per filtrar els clarament no qualificats, però falla en detectar els errors que et costen diners reals — l'arquitecte que no sap gestionar compromisos, el desenvolupador sènior que escriu codi que funciona però no es pot mantenir, l'enginyer que es paralitza quan necessita comunicar un bloqueig.
Aquesta pàgina explica exactament què implica el nostre procés de validació, pas a pas. Sense abstracció, sense vernís de màrqueting.
Per Què Importa la Validació Dissenyada per CTOs
El filtratge tècnic tradicional va ser dissenyat per reclutadors i equips de RRHH. Optimitza per coses que els reclutadors poden mesurar: anys d'experiència, coincidència de paraules clau en CVs, puntuacions d'aprovat/suspès en puzles algorítmics. Aquests senyals correlacionen feblement amb el rendiment en enginyeria de producció.
La nostra validació va ser dissenyada per CTOs que han contractat, gestionat i acomiadat enginyers en entorns de producció. Saben què falla a escala, què es trenca sota pressió de deadlines i què separa un enginyer que pot construir una funcionalitat d'un que pot construir un sistema.
Aquesta experiència modela cada criteri d'avaluació. No avaluem el que és fàcil d'avaluar — avaluem el que realment prediu l'èxit en un rol d'enginyeria de producció remot i entre zones horàries.
Els Cinc Pilars
Pilar 1: Arquitectura i Disseny de Sistemes
Què avaluem: La capacitat de dissenyar sistemes sota restriccions reals — no escenaris de llibre de text.
Cada candidat rep un repte de disseny basat en un escenari de producció real. Les restriccions són específiques: una base d'usuaris definida, un rang de pressupost, una mida d'equip, requisits de compliment, objectius d'escalabilitat. No busquem la resposta "correcta". Avaluem:
- Raonament de compromisos. Poden articular per què van triar una base de dades sobre una altra, un patró de comunicació sobre un altre, una estratègia de desplegament sobre una altra — i què sacrificarien amb cada elecció?
- Consciència de modes de fallada. Pensen en què passa quan un servei cau, quan el tràfic es dispara, quan una API de tercers canvia el seu contracte? Els enginyers que només dissenyen per al camí feliç construeixen sistemes fràgils.
- Comunicació de decisions. Poden explicar la seva arquitectura a algú que no era a la sala? Això importa perquè l'enginyeria remota significa que el teu arquitecte necessita documentar decisions que un equip col·locat absorbiria per osmosi.
Els candidats tenen temps per preparar-se. Això no és una emboscada de pissarra — és una discussió estructurada que reflecteix com es prenen realment les decisions d'arquitectura en equips d'enginyeria ben gestionats.
Pilar 2: Qualitat de Codi i Artesania
Què avaluem: La capacitat d'escriure codi de nivell producció, no codi de nivell entrevista.
Revisem codi real. Els candidats envien un projecte recent o completen un exercici per fer a casa que reflecteix treball de producció real — no un algorisme d'ordenació, no un problema de joguina. Avaluem:
- Estructura neta. Està el codi organitzat de forma que un altre desenvolupador pugui navegar-lo sense un tour guiat? Noms significatius, separació lògica de responsabilitats, patrons consistents.
- Gestió d'errors. El codi gestiona casos extrems, entrades inesperades i escenaris de fallada? O només funciona en el camí feliç?
- Disciplina de testing. Hi ha tests? Són significatius — avaluen comportament, no detalls d'implementació? La cobertura de tests és proporcional a la criticitat del codi?
- Separació de responsabilitats. La lògica de negoci està barrejada amb codi d'infraestructura? La capa de presentació està barrejada amb l'accés a dades? Els enginyers que lliuren límits nets lliuren sistemes mantenibles.
No fem servir puntuació automatitzada de codi. Un enginyer sènior revisa l'enviament i proporciona feedback escrit. L'avaluació té en compte el llenguatge, framework i context — Go idiomàtic es veu diferent de Python idiomàtic, i avaluem en conseqüència.
Pilar 3: Competència en IA
Què avaluem: Ús efectiu i amb criteri d'eines de desenvolupament amb IA.
Aquest és el pilar que la majoria d'empreses nearshore s'escapen completament. El 2025, un enginyer que no utilitza eines d'IA de forma efectiva està deixant a la taula el 30-40% de la seva productivitat potencial. Però un enginyer que utilitza eines d'IA sense criteri és un risc.
Avaluem:
- Fluïdesa amb eines. Poden utilitzar GitHub Copilot, Cursor, Claude o eines equivalents per accelerar tasques rutinàries — generació de codi repetitiu, escriptura de tests, documentació, refactorització?
- Prompt engineering. Poden escriure prompts que produeixin resultats útils? Saben com proporcionar context, establir restriccions i iterar sobre resultats generats per IA?
- Judici crític. Aquest és el criteri més important. Poden identificar quan el codi generat per IA és incorrecte, té bugs subtils o és arquitectònicament inapropiat? Revisen la sortida de la IA amb el mateix rigor que aplicarien al pull request d'un desenvolupador junior?
- Límits d'ús apropiat. Saben quan utilitzar IA i quan no? Codi sensible a la seguretat, lògica de negoci complexa i reptes algorítmics nous sovint necessiten enfocaments humans primer. Els enginyers que recorren a la IA per tot produeixen sistemes fràgils i poc compresos.
Avaluem això a través d'exercicis pràctics: refactoritza aquest mòdul utilitzant assistència d'IA, depura aquest codi generat per IA, avalua aquesta arquitectura proposada per IA. La puntuació pondera el judici més que la velocitat.
Pilar 4: Comunicació i Col·laboració
Què avaluem: La capacitat de treballar efectivament en un entorn remot, asíncron i entre zones horàries.
L'enginyeria remota no falla per incompetència tècnica. Falla perquè algú no va assenyalar un bloqueig fins al standup tres dies després, o perquè la descripció d'un pull request deia "arreglat coses" en lloc d'explicar el canvi i les seves implicacions.
Avaluem:
- Claredat escrita. Poden escriure una descripció de ticket clara, un comentari de PR útil, una actualització d'estat que un PM pugui entendre? Proporcionem escenaris i avaluem la qualitat de la producció escrita.
- Fluïdesa verbal. Anglès parlat (o l'idioma de treball rellevant) a un nivell suficient per a discussions tècniques, debats arquitectònics i trucades amb clients. No sense accent — funcionalment clar.
- Senyalització proactiva de problemes. Presentem escenaris on un projecte es dirigeix cap a problemes i avaluem si el candidat planteja la qüestió, proposa alternatives o es queda en silenci esperant que es resolgui sol.
- Disciplina de zona horària. Entenen la mecànica del treball asíncron? Poden estructurar el seu dia per maximitzar la superposició amb les hores de treball del client? Documenten context perquè la propera persona a la cadena de zones horàries pugui continuar sense demora?
Aquest pilar elimina més candidats del que la majoria espera. L'habilitat tècnica sense habilitat de comunicació produeix enginyers que construeixen el que no toca, lentament, en silenci.
Pilar 5: Trajectòria Professional
Què avaluem: Experiència verificada en entorns de producció que s'assemblen als contextos dels nostres clients.
- Verificació d'ocupació. Confirmem rols anteriors, durades i responsabilitats. No a través d'un formulari — a través de verificació directa.
- Comprovació de referències. Parlem amb antics managers o col·legues que poden parlar sobre el rendiment del candidat en un context laboral, no només confirmar que existien a l'empresa.
- Alineament cultural. Avaluem l'encaix amb entorns de startups i scale-ups: comoditat amb l'ambigüitat, capacitat de treballar sense especificacions detallades, disposició per apropiar-se dels resultats en lloc de simplement completar tasques.
Aquest pilar existeix perquè les credencials sense context no són fiables. Deu anys d'experiència en una gran empresa on algú mantenia un únic servei no el prepara per a una startup on necessitarà construir tres serveis, desplegar-los i donar-los suport.
Els Números
- 8% de taxa d'acceptació en els cinc pilars. De cada 100 candidats que entren al procés, vuit el superen.
- Nivell d'experiència mitjà dels enginyers acceptats: 7+ anys en desenvolupament de programari de producció.
- Temps des de la sol·licitud fins a completar la validació: 5-7 dies laborables.
- Monitorització contínua del rendiment: Enquestes de satisfacció del client als 30, 60 i 90 dies. Els enginyers que cauen per sota dels llindars de rendiment són senyalats per a revisió o reemplaçament.
La Política de Reemplaçament
Si un enginyer no compleix les teves expectatives dins dels primers 30 dies, el reemplacem sense cost addicional. Sense discussions, sense negociació. El candidat de reemplaçament ve del mateix pool validat i coincideix amb 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 ocasionalment produeix un desajust. Quan això passa, el cost hauria de ser nostre, no teu.
Què Significa Això per a Tu
Quan reps una llista curta de Conectia, cada enginyer en ella ja ha superat un procés de validació que la majoria dels pipelines de contractació sènior no poden igualar. No ets el primer filtre tècnic — ets la comprovació final d'encaix.
Això significa que la teva inversió de temps en avaluació cau dràsticament. En lloc d'executar el teu propi procés d'entrevista tècnica de múltiples rondes amb dotzenes de candidats, estàs revisant de tres a cinc enginyers pre-validats que coincideixen amb els teus requisits específics. La majoria dels clients fan una selecció dins d'una setmana de rebre perfils.
Vols veure el calibre d'enginyers que passen aquest procés? Sol·licita una llista curta validada pel CTO per al teu lloc obert actual — perfils lliurats en 72 hores.
