Så genomför du en mockintervju för mjukvaruingenjörer
Av Aaron Cao · Uppdaterad

Öva en runda i taget under verklig tidspress, i de verktyg som den riktiga rundan använder, med en intervjuare som avbryter. Bedöm struktur, kommunikation och återhämtning snarare än om du nådde den optimala lösningen. En mockintervju som aldrig går fel övar inte den svåra delen.
Vad täcker en realistisk mockintervju för mjukvaruingenjörer?
Du har antagligen löst gott om problem och känner dig ändå oförberedd, och orsaken är oftast att lösa problem på egen hand inte är det rundan testar. Det här avsnittet delar upp de tre rundor en mjukvaruingenjörsloop använder, för varje behöver en annan sorts övning och att blanda dem slösar bort passet.
- Coding. 35 till 45 minuter, ett eller två problem, tänka högt medan du skriver. Övningsmålet är att berätta om en lösning du fortfarande formar.
- System design. 45 till 60 minuter, en öppen fråga, ingen förtydligande om du inte ber om det. Övningsmålet är att avgränsa problemet innan du designar det.
- Behavioral. 45 minuter med projektberättelser och fientliga följdfrågor. Övningsmålet är att överleva den tredje följdfrågan om ett beslut du ångrar.
Kör en av dessa per pass. En hel loop på tre timmar känns produktiv men ger nästan ingen användbar feedback, för i tredje rundan övar du uthållighet snarare än färdighet. Om du vill ha frågebanken snarare än mekaniken, finns det en separat sida i navet mock interviews.
Hur genomför du en på egen hand?
Soloövningar misslyckas på ett förutsägbart sätt: du väljer ett problem du kan lösa, stoppar timern när du fastnar och avslutar med en bra känsla. Allt detta är motsatsen till de verkliga förhållandena. Återskapa istället begränsningarna.
- Välj inte ditt eget problem. Hämta från en lista du inte har läst, eller låt någon annan välja. Att välja själv betyder att välja något bekvämt.
- Starta timern och stoppa den aldrig. Fast-tid är data. Att pausa tar bort exakt den press du övar på.
- Matcha verktygen. Om rundan använder en delad editor utan autokomplettering, ingen körknapp och ingen testsvit, öva där.
- Prata i ett tomt rum. Det känns absurt och är den enskilt mest värdefulla delen. Tyst problemlösning tränar en färdighet som ingen bedömer.
- Spela in det. Att se dig själv är obehagligt och visar utfyllnad, omtag och minuten du blev tyst.
- Designa till en början utan diagramverktyg. Många designrundor är ett röstsamtal och ett tomt dokument.
Det enda en soloövning inte kan ge är avbrott, och avbrott är den största delen av vad som gör en verklig runda svår. En AI-intervjuare kan täcka just det gapet: den ställer följdfrågan mitt i din mening och väntar inte artigt på att du ska bli klar. Läget mock interview kör rundorna på det här sättet.
Vilken feedback bör du samla in?
De flesta avslutar en mockintervju och antecknar ett utfall, vilket är värdelöst en vecka senare. Samla specifika observationer kopplade till beteenden du kan ändra.
- Tid till första förtydligande fråga. Om det tar över nittio sekunder löser du fel problem.
- Längsta tystnaden. Allt över tjugo sekunder behöver en talad platshållare istället.
- Berättade du din strategi innan du skrev kod? Ja eller nej, varje gång.
- Hur återhämtade du dig när du fastnade? Formulerade om problemet, provade ett mindre fall, eller frös.
- Var komplexitetsdiskussionen efterfrågad eller spontan? Spontan bedöms bättre.
- För design: avgränsade du innan du ritade? Begränsningar och skala först, rutor sedan.
En backendingenjör som förberedde sig för en senior-loop körde tolv mockintervjuer och klarade alla, men klarade sedan inte den riktiga kodningsrundan efter att ha varit tyst i fyra minuter på en okänd variant. Hennes mockintervjuer hade aldrig innehållit ett problem hon inte kunde lösa, så hon hade aldrig övat på det enda som faktiskt gick fel. Hon ändrade en regel, tillät problem över sin nivå, och tystnadsproblemet dök upp direkt.
Hur många mockintervjuer räcker, och vad kan de inte fixa?
Det finns inget magiskt tal, och volym bortom en viss punkt slutar löna sig. Ett användbart mönster är två eller tre mockintervjuer per rundtyp utspridda över två veckor, där granskningen mellan dem betyder mer än passen i sig. Sex mockintervjuer utan granskning är sämre än tre med noggranna anteckningar.
Var tydlig med begränsningarna. En mockintervju kan inte tala om vilket problem du kommer att få, kan inte förutsäga din intervjuares stil och kan inte ersätta att faktiskt kunna materialet. Det den fixar är leveranslagret: att prata medan du tänker, avgränsa innan du bygger och återhämta dig högt när du fastnar. De överförs helt, och de är också sådant läsning inte kan lära ut.
Övning och live-assistans är olika frågor med olika svar. Repetition är okontroversiellt. Assistans under en riktig intervju beror på formatet och arbetsgivarens regler, och skärmdelade eller övervakade kodningsrundor gör det helt otillämpligt. De ärliga gränserna finns i navet detectability.
FAQ
Hur många mockintervjuer bör en mjukvaruingenjör göra?
Kan jag genomföra en användbar mockintervju utan partner?
Ska mockproblem vara på min nivå eller svårare?
Hjälper mockintervjuer med system design-rundor?
Är en mockintervju samma sak som att öva LeetCode?
Relaterade frågor
- Hur genomför du en realistisk mockintervju för produktchef?
- Vilka frågor bör en mjukvaruingenjör öva på i mockintervjuer?
- Hur genomför jag en övningsintervju ensam, utan en övningspartner?
- Finns det en gratis AI-provintervju, och vad ingår i gratisversionen?
- Vilka beteendefrågor bör du träna på i en övningsintervju?
- Förbättrar övningsintervjuer verkligen intervjuprestationen?