Stripes intervjuprocess, omgång för omgång

Du har läst att Stripes intervjuer är ovanliga och vill veta vad det faktiskt betyder för din förberedelse. Det här avsnittet kartlägger de steg kandidater ofta rapporterar, så att du kan rikta övningen mot rätt sak. Formen är stabil även om namnen på enskilda omgångar ändras.

• Rekryterarscreening. Rollpassning, tidslinje, lönespann och vilket team du skulle tillhöra.
• Teknisk telefonscreening. Ett praktiskt kodningsproblem i en delad editor som faktiskt körs, inte pseudokod i ett delat dokument.
• Bug squash. Du släpps ner i en kodbas du inte sett och ombeds hitta och fixa ett fel.
• Integration eller API-bygge. Du bygger en liten fungerande funktion mot dokumenterade endpoints.
• System- eller produktdesign. Vanligtvis nära betalningar: idempotens, återförsök, penningrörelser, felhantering.
• Samtal med hiring manager och om värderingar. Motivation, samarbete och hur du skriver och beslutar.

Inte alla kandidater ser alla omgångar. Team, nivå och år ändrar alla listan, så bekräfta ditt specifika schema med rekryteraren istället för att anta en version du läst online. En bredare karta över arbetsgivares intervjuprocesser finns i navet företags intervjuprocesser.

Det praktiska formatet är en medveten proxy för själva jobbet. Betalningsarbete handlar mest om att läsa befintliga system, förstå varför en förfrågan misslyckades och göra en försiktig ändring utan att bryta penningrörelsen. Ett pussel om att vända upp och ner på ett binärt träd mäter inte det; ett fel i en okänd tjänst gör det.

Konsekvensen för dig är att de bedömda färdigheterna skiftar. Läshastighet spelar roll. Det gör även användningen av verktyg du normalt skulle använda: köra tester, skriva ut mellantillstånd, söka i repot istället för att scrolla igenom det. Kandidater som försöker resonera tyst genom okänd kod, så som du skulle göra på en whiteboard, får oftast slut på tid.

Skrivande dyker upp överallt eftersom Stripe drivs av skrivna dokument. Räkna med att förklara en avvägning i löpande text, i chatt eller i en kort sammanfattning, och räkna med att den förklaringen läses som en del av din bedömning, inte som en formalitet.

Öva formatet, inte bara ämnena. Både bug squash och integrationsomgången belönar vanor som du bara kan bygga genom att öva under samma begränsningar.

• Arbeta i ett riktigt repo med en timer. Klona ett open source-projekt du inte känner till, välj ett registrerat ärende och fixa det på 45 minuter.
• Berätta högt vad du söker efter. Säg vad du grepar efter och vad du förväntar dig hitta. Intervjuare bedömer resonemanget de kan höra.
• Läs ett API-dokument oförberedd. Bygg en liten klient mot något du aldrig använt, med dokumentationen som enda referens.
• Öva felvägar. Var redo på återförsök, dubblerade förfrågningar och partiella fel innan du blir tillfrågad, för alla designsvar.
• Skriv ner ditt resonemang. Efter varje övningspass, sammanfatta ändringen i fem meningar.

En backendingenjör med fem års erfarenhet av betalningar förberedde sig för en Stripe-process genom att slipa algoritmproblem i tre veckor, men klarade sedan inte bug squash eftersom hon aldrig navigerat en okänd tjänst under tidspress. Lösningen var inte fler algoritmer; det var tio tidsbegränsade sessioner i repon hon inte hade skrivit. Om du vill öva beteende- och designomgångarna högt med följdfrågor kör övningsläget mock interview den drillen.

Förberedelse är okontroversiellt. Att öva en designomgång högt, träna på de frågor en hiring manager ställer om ett projekt och granska dina egna inspelade svar är alla vanlig träning.

Live-assistans under intervjun är en snävare fråga, och det ärliga svaret beror på omgången. En konversationsomgång via videosamtal är en annan situation än en kodningsövning där du delar din skärm i en övervakad miljö. När intervjuaren ser din skärm är allt på den skärmen synligt, och inget verktyg ändrar det. Stripes praktiska omgångar involverar ofta precis den uppsättningen, vilket är fallet att planera kring snarare än ett vagt löfte om osynlighet.

Aaron Cao, grundare av SubcueAI, byggde produkten kring den uppdelningen snarare än kring ett påstående om universell osynlighet: en nativ macOS- och Windows-skrivbordsapp håller sitt overlay lokalt på din maskin, ingen mötesbot ansluter till samtalet och inget injiceras på mötessidan. Vad den inte gör är att överleva en delad skärm eller en företagsstyrd enhet. Gränserna finns beskrivna i navet detectability.