Una prova pensada per a un altre moment
Quatre dies abans de començar oficialment, vaig anar a l’oficina per a una comprovació de passaport. Mentre hi era, el meu cap em va comentar que hauria de muntar un equip. La meva primera pregunta va ser si podia canviar el procés d’entrevistes. Va dir que sí. Ni tan sols havia tingut el meu primer dia. Quan vaig començar, ja estava construint la nova prova.
Havia entrat com el nou Engineering Manager de l’equip de mobile platform, que estava reconstruint l’app mòbil en React Native: una migració brownfield des de les apps natives d’iOS i Android. Necessitava enginyers que poguessin treballar a nivell de plataforma.
No vaig haver de demanar veure la prova tècnica. L’havia fet jo mateix feia unes setmanes. Així és com em van contractar a mi: un exercici de live coding on construeixes una app petita en més o menys una hora mentre l’entrevistador t’observa, seguit de preguntes tècniques d’un qüestionari. Tota l’entrevista durava uns 90 minuts.
La prova tenia sentit en el seu context original. Quan l’equip era més petit i es contractava per a altres rols, era una manera raonable de filtrar candidats ràpidament. Les nostres necessitats havien evolucionat. Ja no buscàvem algú per muntar pantalles senzilles. Estàvem contractant enginyers de plataforma que es farien responsables de l’arquitectura sobre la qual construirien tots els altres equips mòbils.
Necessitava que la prova respongués preguntes diferents:
- Poden estructurar una app amb múltiples pantalles i navegació que no s’ensorri?
- Poden fer crides a una API real i gestionar què passa quan la xarxa falla?
- Escriuen tests perquè els importa que el software funcioni, o perquè algú els ho ha dit?
- Poden seure davant meu i explicar per què ho van construir així?
La prova existent estava dissenyada per a preguntes diferents. Necessitava una prova construïda a partir de les nostres.
Aquest post cobreix el raonament darrere del redisseny. Els posts complementaris cobreixen el brief del take-home en detall, el sistema de scorecard i en què s’han de centrar els candidats.
El live coding encaixa en una altra mena de rol
El live coding et diu si algú programa còmodament mentre l’observen. Per a alguns rols, això importa. Per al nostre, necessitava veure una altra cosa.
He estat a banda i banda. A principis d’aquest any, en un procés de selecció d’una altra empresa, vaig fer un exercici de live coding per a un lloc per al qual estava qualificat i em vaig quedar en blanc. El problema era senzill, sabia com resoldre’l, i amb algú que t’observa cada tecla tot se’n va anar en orris. Com a entrevistador, he vist com els passava el mateix a candidats: enginyers capaços que es bloquegen en problemes que resoldrien en cinc minuts asseguts al seu escriptori.
Per a un rol d’enginyeria de plataforma, on la feina consisteix en decisions d’arquitectura, components de design system i pipelines de CI/CD, volia veure com els candidats aborden els problemes amb temps i context. El tipus de pensament que la feina realment requereix.
Mostrar vs. explicar
El procés anterior també incloïa un qüestionari tècnic. L’entrevistador triava preguntes d’un full de referència que cobria arquitectura React Native, state management, estratègies de testing i diferències de plataforma, i després comparava les respostes amb les esperades. De vegades els candidats cobrien els temes de manera natural durant el live coding, i l’entrevistador se saltava aquelles preguntes.
Tots són temes vàlids. Són exactament les coses que vull que els meus enginyers entenguin. Demanar a algú que expliqui un concepte et diu si entén la teoria. Veure com l’aplica en el seu propi codi et dona un senyal diferent.
El nou procés avalua els mateixos temes a través del codi del candidat. En lloc de preguntar «com estructuraries la navegació en una app complexa?», puc obrir la seva entrega i veure com l’ha abordat, i després tenir una conversa més rica sobre les decisions que ha pres. El walkthrough segueix cobrint arquitectura, trade-offs i profunditat tècnica, però està ancorat en una cosa que el candidat va construir.
Què vaig construir al seu lloc
Vaig dissenyar un take-home assessment. Una app petita però real: múltiples pantalles, una API pública, navegació, state management amb regles de negoci reals, TypeScript a tot arreu. No una joguina. Tampoc un projecte de cap de setmana. Una cosa que demana pensament arquitectònic de veritat.
Quatre principis van guiar el disseny.
Reflectir la feina real. La prova ha de semblar la feina de debò. Si un candidat pot construir aquesta app, pot contribuir al nostre codebase des del primer dia. Si no pot, això també és informació útil.
Eliminar el boilerplate. Dono als candidats un starter project completament configurat. TypeScript, ESLint, Prettier, Jest, React Native Testing Library, path aliases. Tot preparat. No m’importa si algú sap configurar un bundler. M’importa si sap escriure codi d’aplicació.
Ser clar en el què, no en el com. El brief explica què ha de fer l’app. No diu mai quina biblioteca de state management fer servir, com estructurar les carpetes ni quin client d’API triar. Aquestes decisions són la part més reveladora de l’entrega. Un candidat que tria Redux Toolkit per a una app de tres pantalles em diu una cosa diferent d’un que tria Zustand o React Context. Cap dels dos no s’equivoca. Tots dos són interessants. Desglosso cada decisió de disseny darrere del brief a Com escriure una prova tècnica per fer a casa que els candidats realment vulguin fer.
Respectar el temps de la gent. Els candidats tenen una setmana. La feina hauria de ser d’entre 4 i 6 hores. La gent té feines, famílies, vides. Ningú no hauria de demanar un dia lliure per fer una prova tècnica d’una empresa que potser no el contractarà.
Per què el walkthrough fa la major part de la feina
El codi del take-home és la meitat de l’avaluació. L’altra meitat és una trucada de walkthrough: el candidat fa una demo de l’app, executa els seus tests en directe i recorre el codi.
Aquí és on aprens fins a quin punt algú entén el que va construir. Aquesta comprensió és el que separa un enginyer que pot ampliar el seu propi codi d’un que només pot lliurar-ne una versió que funciona.
Tres coses que busco.
Ownership. «Navega al fitxer on gestiones la resposta de l’API». Si l’ha escrit, hi anirà directament. Si no se sent del tot còmode amb el codi, això es nota ràpidament.
Pensament en trade-offs. Pregunto per cada decisió significativa. «Per què aquest enfocament de state management?» La resposta que vull no és «perquè és el millor». La resposta que vull és «perquè s’ajusta a aquest abast, aquí és on es trencaria, i aquí és cap a on migraria». Els enginyers que pensen en trade-offs construeixen millors sistemes que els que pensen en absoluts.
Autoconsciència. «Què canviaries si tinguessis més temps?» Els candidats forts reben bé aquesta pregunta. Tenen una llista. Saben quines dreceres van prendre. Saben què és fràgil. Han estat pensant en millores des que van entregar. Els candidats amb menys experiència solen dir «n’estic content» i segueixen endavant.
Si t’estàs preparant per a un take-home assessment com aquest, vaig escriure una guia per a candidats: Com aprovar una prova tècnica de React Native.
Avaluació estructurada
Una cosa que vaig voler des del primer dia va ser un scorecard estructurat. Quan estàs fent créixer un equip i múltiples persones participen en la contractació, tothom necessita avaluar les mateixes coses de la mateixa manera. Sense això, dos entrevistadors poden revisar el mateix candidat i arribar a conclusions diferents perquè estan ponderant coses diferents.
Vaig construir un scorecard que divideix la revisió de codi en quatre seccions: l’app funciona, la capa de dades és sòlida, el codi està ben estructurat i està testejat. Cada secció és una llista de comprovacions amb resposta de sí o no que valen un punt cadascuna, i la trucada de walkthrough es puntua a part amb les seves pròpies taules de preguntes. Cada entrevistador avalua les mateixes coses en el mateix ordre.
L’scorecard també mapeja puntuacions a nivells. Un número et diu si algú està a nivell Graduate, Associate, Software Engineer o Senior. Això treu l’ambigüitat de la conversa de nivells. Pensar és feina de la rúbrica. Els humans la verifiquen. Vaig publicar la checklist completa, els llindars de nivell i el disseny de puntuació que va fracassar abans, a Com vaig dissenyar un scorecard de prova tècnica que funciona de Graduate a Senior, i més tard vaig construir una petita app per capturar aquestes puntuacions durant la trucada.
Els candidats sèniors tenen una ronda més difícil
Per a contractacions sèniors, hi ha una conversa addicional de system design. Sense pissarra. Sense «dissenya Twitter en 45 minuts». Parlem d’escenaris reals rellevants per a la plataforma que estem construint. Què canvia quan 20 equips construeixen sobre la mateixa plataforma mòbil? Com gestiones dependències compartides? Quin és el teu enfocament per a backwards compatibility?
És una conversa entre dos enginyers, no una actuació per a un públic. Els millors candidats qüestionen els meus supòsits i fan preguntes d’aclariment. Aquest és el comportament que vull d’un sènior a l’equip.
Primers dies
Durant la meva primera setmana, vaig contractar un Senior Engineer a través del procés existent (això va passar el segon dia, abans que la nova prova estigués llesta). Des d’aleshores, el nou procés va passar a ser l’estàndard per a totes les contractacions de React Native a l’organització. El meu company EM, que lidera un altre equip, va revisar la prova i l’scorecard i va acceptar adoptar-los també per a les contractacions del seu equip. Aquest és l’avantatge d’un sistema ben documentat: funciona més enllà de l’equip d’un sol manager.
Les següents contractacions, dos Software Engineers, van passar pel nou procés: cada candidat va rebre la mateixa prova, el mateix starter project, els mateixos criteris d’avaluació i la mateixa checklist de puntuació. El marge per al biaix es redueix quan estandarditzes.
La lliçó
Si t’estàs incorporant a un equip nou com a engineering manager, mira el procés de contractació aviat. No esperis fins que hagis «après el codebase» o «entès la cultura». La contractació és una de les activitats de més impacte que tens. Cada persona que incorpores dona forma a l’equip durant anys.
I si la teva prova tècnica ja no reflecteix el que estàs buscant, val la pena revisar-la.
Un take-home ben pensat combinat amb un walkthrough estructurat et diu més sobre un enginyer que una hora mirant-lo teclejar.
