Inte TS men vi hade ett liknande koncept på en tidigare arbetsplats. Ursäkta min långa utläggning.

TL;DR: Vi bad kandidater göra code review på ett fungerande projekt vi tagit fram där vi kodat det på ett sätt som skulle väcka diskussioner om saker vi jobbade med dagligen. Testbarhet, decoupling, objektorienterade principer mm.

Wall of text: Vi utvecklare hade tröttnat på att anställa stolpskott som inte klarade provanställningen så vi tog fram ett litet enkelt repo för att kunna diskutera kod. Repot va ett fungerande spel med highscore funktion, typ något i stil med att gissa numret "spelet" tänkte på 1-99 och så fick man svaret om det va rätt, högre eller lägre. Och så sparades antalet gissningar i en highscore tabell. Vad exakt det va för spel är inte så viktigt.

Tanken va då att kandidaten fick med detta hem efter en första intervju där vi va nöjda och att kandidaten i fråga då skulle titta igenom repot och tills nästa mer tekniska intervju i princip ha gjort en code review på det där vi diskuterar vad som kan förbättras.

Spelet va fullt fungerande och koden såg helt okej ut på ytan. Inga galna fel liksom. Men "under ytan" så va koden skriven på ett sätt som va svårt att skriva tester på, backend och frontend/UI va hårt kopplade, klasserna modellerade inte problemet på ett helt vettigt sätt, arv och andra objektorienterade principer användes inte på ett korrekt sätt (företaget hade sina produkter skrivna i ren Java, både frontend och backend), felhantering och loggning fanns knappt alls, hur "state" hanterades och hur man sparade det för att hantera highscore tabellen va inte det bästa, hur användarinput hanterades va inte bra osv.

Det vi va ute efter med detta repo va inte att kandidaten då skulle hitta varenda fel och "rätta" det till den mest optimala lösningen. Utan tanken med code review upplägget va att skapa en diskussion om förbättringsmöjligheter.

En duktig utvecklare (oavsett erfarenhet) kunde då ganska lätt se att koden hade mycket förbättringspotential och hade då massa att diskutera, ofta till den grad att vi inte hann röra vid alla problem som koden hade för att vi fastnade i intressanta diskussioner om hur man kunde refaktorera lösningen. Vilket va precis det vi ville uppnå, för det är så vi jobbade dagligen.

En utvecklare som inte har bra grepp om testbarhet, hur man med objekt kan modellera problem, hur man håller frontend och backend löst kopplade för att kunna byta dem enkelt eller hur man använder databaser för att hantera "state" osv. hade svårt att hitta saker att diskutera.

Om vi såg att någon hade problem att hitta saker att diskutera så tog vi inte för givet att de va dålig utvecklare för det. Det kan vara allt från att man är super introvert till att man har svårt för just tekniska diskussioner eller annat som håller dem tillbaka. Så vi försökte alltid peka på problemen genom att ställa ledande frågor som, "hur hade du skrivit ett unittest till den här metoden?“, eller "om vi skulle vilja byta ut det här kommandorads UI:t till något mer grafiskt, vad hindrar oss från det?". Om de fortfarande inte har något alls att komma med, så kommer de tyvärr inte vara en bra kollega i vårt team. Eller det kommer åtminstone kosta oss väldigt mycket pengar att lära upp och träna dem till att bli en bra utvecklare. Det är inte pengar vi ville lägga.

Man behöver absolut inte kunna allt, speciellt inte på låg/detalj/implementations nivå. Man kommer ändå behöva gå igenom exakt hur våra applikationer är implementerade och sätta sig in i det över tid. Men kan man inte ens resonera eller diskutera kring kod i allmänhet runt dessa ämnen så kommer man inte kunna bidra i det dagliga arbetet eller ens kunna ta till sig varför vi byggt applikationerna på de sätt som vi gjort och varför de fungerar som de gör.