Deixar de fallar entrevistas de codificación en directo: leccións de máis de 100 sesións reais

Aluguei unha vez un desenvolvedor que non resolveu o problema. Eles chegaron a medio camiño, saíron do tempo e o seu código non compilou. Recomendoulles unha oferta de todos os xeitos. Pasaron toda a hora pensando en voz alta, preguntando preguntas de aclaración e tratándome como un compañeiro debugando algo xuntos. Foi entón cando me dei conta de que as entrevistas de codificación en directo están mal nomeadas. Estiven nesta industria durante 12 anos. Entrevistei centos de papeis, pasei máis de 50 roldas técnicas e conduciches máis de 100 entrevistas de codificación en directo en lugares como Monzo e Superbet. O patrón é consistente: os mellores codificadores non sempre se contratan. Os máis vocais o fan. Pode escribir código sen defectos en silencio e fracaso. Pode loitar por unha solución mediocre mentres se comunica belamente e ten éxito. A entrevista está a probar se o equipo quere pasar máis de 40 horas por semana traballando contigo. Por que temos que facer entrevistas de codificación en directo? Lembro unha noite que estaba visitando a miña nai e ela preguntoume: Síntoo mamá, non teño unha resposta para ti. Foi só unha rolda 3 de 7. eu aínda teño un deseño do sistema, unha codificación en directo, un comportamento e equipo para ir. - Ela preguntou, mortificado - Cambio de emprego para ela consiste en pasar 15 minutos cun director médico, principalmente discutiendo salario e hora de inicio e iso é todo. "Como foi a entrevista na empresa X? ¿Fixeches o traballo?" “Que que?” "Non é para o mesmo papel que tiñas antes?" A enxeñaría de software é unha profesión de baixa confianza - e por unha boa razón tamén. A diferenza de habilidades entre desenvolvedores pode ser asombrosa. Pode ter alguén que está a codificar durante 15 anos aínda loitando con algoritmos básicos, mentres que un A adaptabilidade está a ser cada vez máis valorada, mentres que os fundamentos fortes e os principios sólidos están a saír de sabor. Un internista aforra 300.000 dólares a TikTok reconstruíndo un microservizo en Rust Solicitou o seu papel de soño e recibiu unha chamada de HR. e están Comproba o teu calendario. Panic sets in. Comezas a googlar e, por fin, aterrar aquí. imos atopar-lle ese traballo. "Impresionado pola túa experiencia" "Esperando poder avanzar nas próximas etapas" Live coding interview — tomorrow 3PM "Como pasar unha entrevista de codificación en directo" Tipos de entrevistas de codificación en directo Non todas as entrevistas de codificación en directo son creadas iguais. Antes de entrar en pánico, axuda a saber en que formato está indo. : Semellante a unha competición de programación, obterás unha tarefa que require unha comprensión dun algoritmo ben coñecido con antelación. Isto di moi pouco sobre a proficiencia real dun enxeñeiro de software. LeetCode-style interview Grind un sitio web como LeetCode durante un par de semanas, ata que poida facilmente resolver problemas fáciles e medios. Isto debería preparalo para preguntas difíciles tamén. En xeral, necesitará coñecer os mesmos algoritmos (DFS, BFS, FF, etc.) pero usará máis dun como parte dunha solución máis complexa. Se a empresa está específicamente á procura de programadores competitivos, este estilo de entrevista ten sentido. : Comezarás cun exercicio de toma de casa. Unha vez que o envíes, o equipo de contratación fará un pase cursor para revisar a túa solución. Se están satisfeitos con iso, pasarás á rolda 2 - unha sesión en directo onde terás 10-30 minutos para facer un pequeno cambio ou implementar unha pequena nova característica. Isto demostra que realmente podes escribir código e non foi un coñecido útil (cuxo nome rime con Chad Jeep ET) quen o fixo por ti. Take-home exercise with live counterpart : Normalmente só hai unha tarefa, deseñada para levar aproximadamente unha hora. Isto proba as súas habilidades de resolución de problemas de fin a fin. Obterás unha declaración de problema ben definida e un ambiente para escribir código. Colaborarás co/os entrevistador(s) para converxer nunha solución. A miúdo hai unha escala para isto tamén - se non podes rematar toda a tarefa a tempo, a miúdo aínda é aceptable. Pair-coding exercise : Obterá unha morea de preguntas relacionadas coa programación, xeralmente aumentando en dificultade. As primeiras preguntas simplemente comprobar se ten algún nivel de proficiencia no idioma. Os próximos poucos levarán un pouco de tempo para pensar. Pode comezar a tomar notas aquí - usando comentarios de código antes de implementar funciona ben. As últimas 1-3 preguntas están deseñadas para enganar, confundir con vostede, e facer que que queira deixar de traballar no software. Dependendo da linguaxe, isto incluirá pistolas típicas, sospeitosos habituais ao debugar, e ás veces casos de borda exótica que os entrevistadores atoparon. Pode que non resolva estes, e iso está ben. Caminar os entrevistadores a través de como os abordaría. Live programming trivia : O último xefe de entrevistas tecnolóxicas. Teño a sorte de ter participado só en dúas entrevistas de taboleiro na miña carreira. Non son tan populares agora como unha vez foron. A miúdo atoparás que están en uso por empresas tecnolóxicas legados que non revisitaron o seu proceso de contratación neste milenio. Se tes sorte, podes usar pseudo-código para ilustrar as túas ideas. Raramente tes que escribir todo o programa. A visualización da túa solución pretendida usando ilustracións tamén pode axudar (se é permitido). Whiteboard Non todos fan entrevistas do mesmo xeito, así que se queres estar seguro, prepárate para varios formatos. 1 RTFM Lea o Manual amigable ou, neste caso, lea o correo electrónico que lle envía o equipo de contratación. Algunhas empresas enviaranche instrucións detalladas antes da entrevista.Diranche que tipo de problema esperar, que tecnoloxías usarás, canto tempo durará a entrevista e que ferramentas necesitarás.Lea este correo electrónico. Aquí está o que ten que resolver antes de comezar a entrevista: A maioría dos entrevistadores queren verche. É chupar a falar en dúas letras nun círculo durante unha hora. Se a súa webcam do portátil está roto, use o seu teléfono. Se non ten unha webcam en absoluto, déixalles saber de antemán - pero entenda que isto pode ser un trampolín para algunhas empresas. Get your webcam working. Probablemente necesitará compartir a súa pantalla ou usar unha ferramenta de colaboración como , , ou o que a empresa ofrece. Asegúrese de que realmente pode facer isto antes da entrevista. Vin 5 minutos perdidos mentres un candidato tentou descubrir como compartir a súa pantalla. Test your screen sharing. códigos Replicación Se a túa internet é choppy, a entrevista será dolorosa para todos. Cortar audio, compartir pantalla conxelando, código non sincronizando - todo isto mata a sensación colaborativa da entrevista. Se sabes que a túa conexión é pouco fiable, chégate ao equipo de contratación de antemán. Check your internet connection. Ás veces terás un contacto externo de recursos humanos - un recrutador de tecnoloxía dunha axencia, por exemplo. No meu traballo actual en Speakeasy, traballei cun recrutador que explicou minuciosamente cada paso e fixo o seu mellor para prepararme. Work with your recruiter. O peor que podes facer é presentarte á entrevista e pasar os primeiros 15 minutos resolvendo problemas técnicos que poderías ter resolto o día anterior. Proba que es un bo compañeiro Paréceme un pouco aburrido, non si? Pero aquí está a cousa: non estás a ser entrevistado só pola túa capacidade de codificación.Estás a ser avaliado sobre se o equipo quere pasar máis de 40 horas por semana traballando contigo.Vin que os enxeñeiros brillantes son rexeitados porque estaban condescendendo durante a entrevista.Tamén vin que os programadores medios son contratados porque eran agradables de traballar e demostraron que podían aprender. A partir da miña experiencia de realizar máis de 100 entrevistas de codificación en directo, os candidatos máis exitosos teñen unha cualidade en común. Son vocais. Comunican o seu proceso de pensamento, fan preguntas de aclaración e tratan a entrevista como unha sesión de resolución de problemas colaborativa en lugar dun exame no que están sendo probados. Os entrevistadores tratan de responder a unha pregunta: As súas habilidades técnicas importan, pero tamén como xestiona a frustración, como responde a suxestións, e se é gracioso cando está preso. "Queres que este personaxe estea no meu equipo?" Unha boa regra: se o entrevistador parece comprometido, preguntando preguntas de seguimento, e a conversación flúe naturalmente, probablemente está a facer ben na proba de "colega". Conversa, pero non deflecta Parece anormal ao principio - como se estivese contando un documental sobre a natureza sobre o seu propio cerebro - pero é a cousa máis valiosa que pode facer nunha entrevista de codificación en directo. Poderiamos usar un para loop, pero xa que estamos a transformar cada elemento, map Déixeme comezar con iso e podemos optimizar se fose necesario". This serves two purposes. First, it shows the interviewer how you think. They're not just evaluating your final solution; they're evaluating your problem-solving approach. Second, it gives them opportunities to course-correct you before you spend 15 minutes going down the wrong path. Teño entrevistado candidatos que, cando se lles fai unha pregunta directa, lanzarían unha discusión filosófica de 5 minutos sobre os principios da enxeñaría de software para evitar admitir que non coñecen a resposta. Se o entrevistador pregunta e non sabes, non respondas con Só dicir: "Cal é a complexidade do tempo para isto?" Vostede ve, a complexidade depende de moitos factores, e no mundo real, temos que considerar a localización da caché e..." "Non estou seguro da complexidade exacta. O(n log n) debido ao paso de clasificación, pero quero comprobar iso". A honestidade envolta en reflexión vence a desviación cada vez. As súas preguntas son tan importantes como as súas respostas Algunha vez quixeches dicir nunha entrevista: Ben, animamos activamente aos candidatos a usar Google, Stack Overflow e documentación durante as entrevistas de codificación en directo. Moitas empresas seguen este enfoque, pero non todos. O peor que poden dicir é non, e saberás onde estás. "Eu só Google iso" Teño permiso para mirar as cousas?" Pero mesmo con Google dispoñible, facer preguntas aínda é crucial. No traballo real, está constantemente a facer preguntas. Pregunta ao seu xestor de produto para aclaración. Pregunta aos seus colegas sobre a arquitectura existente. Mira a documentación. A entrevista debe reflectir esta realidade. When you're given a problem, don't immediately start coding. Ask questions: "Cal é o tamaño esperado da entrada? estamos a falar de 10 elementos ou 10 millóns?" "Debería optimizar a complexidade do tempo ou a complexidade do espazo?" "Hai algún caso de vantaxe que deba ser especialmente consciente?" "Que pasa se a entrada é nula ou baleira?" Lembro entrevistar a un enxeñeiro senior que pasou os primeiros 8 minutos dunha entrevista de 45 minutos a facer preguntas sobre os requisitos. Comecei a preocuparme de que non terían tempo suficiente para desenvolver unha solución. Teña coidado, porén: as preguntas deben ser aclaracións xenuínas, non peticións finamente veladas de pistas. (Pregunta lexítima) e (A pesca pola solución) "Cal é o tamaño de entrada esperado?" "Sería útil un mapa de hash aquí?" Unha boa regra é, se estás a piques de responder a unha pregunta que comeza con , en vez diso, explica que precisa máis aclaración e lista os factores que a súa solución dependería. “Depende” Se non sabes - preguntar Isto soa idéntico ao consello 4, pero é sutilmente diferente. consello 4 é facer preguntas para aclarar os requisitos. este consello é facer preguntas cando realmente estás atrapado ou non sabes algo. Teño visto candidatos gastar 20 minutos intentando lembrar a sintaxe exacta para algo trivial, moi avergoñado para preguntar. "Só me preguntar, vou dicirlle, e podemos pasar á parte interesante." Se non podes lembrar se o JavaScript Se está baleiro sobre o nome do algoritmo que aprendeu na universidade, describe o que lembra e preguntar se o entrevistador sabe o que se chama. sort() A clave é ser específico sobre o que non sabes. pero "Non sei como facer iso" Estou pensando en usar un conxunto, pero non estou seguro de que ese sexa o enfoque correcto aquí". Isto fai dúas cousas. En primeiro lugar, mostra que non está simplemente desistir - pensou sobre o problema e ten unha hipótese. En segundo lugar, dá ao entrevistador información útil sobre onde axudar. ou ou "O enfoque establecido é bo" "Pense sobre o que necesitas alcanzar cun conxunto" "Hai realmente un enfoque máis sinxelo se sorteas primeiro". Ninguén espera que saibas todo, pero eles esperan que sexas capaz cando non o saibas. Non é o momento de probar cousas novas Durante unha entrevista de codificación que levo a cabo, o candidato mencionou que coñecía mellor C# -un dos idiomas que ofrecemos para a entrevista.Pero eles escribiron Scala durante os últimos anos, e xa que Scala se executa en JVM como Java, decidiron facer a entrevista en Java en vez. A nosa tarefa de codificación en directo é moi simplista - é puramente sobre a comprensión e os conceptos básicos de programación. A aposta non pagou. A entrevista non é o momento de experimentar con ese novo marco que escoitou sobre Hacker News. Non é o momento de probar a programación funcional por primeira vez. Non é o momento de optimizar para o que pensa que o entrevistador quere ver. Use as ferramentas que sabe ben. Se coñeces Python mellor que Java, use Python (se tes a opción). O entrevistador quere ver que resolve o problema, non ver que loita coa sintaxe que non coñece. reduce Hai unha excepción: se o entrevistador pídelle especificamente que use algo que non está familiarizado, iso é diferente. "Eu non usei X moito antes, así que pode que teña que buscar a sintaxe, pero aquí está o meu enfoque..." Os teus entrevistadores tamén son humanos Eles probablemente están nerviosos tamén. Quizais esta é a súa primeira vez conducindo unha entrevista. Quizais tiveron unha mañá dura. Quizais están preocupados se están a facer as preguntas correctas. I've been on both sides of this. As a candidate, I used to treat interviewers like judges — distant, infallible authorities evaluating my worth. As an interviewer, I realised we're just regular developers trying to figure out if we'd work well together. Isto significa algunhas cousas de forma práctica: Se algo non está claro na declaración do problema, é probablemente porque o entrevistador non o explicou ben, non porque teña que intuír magicamente. Se o entrevistador parece distraído ou verifica o seu teléfono, non o tome persoalmente. Se notas un tipo no problema ou pensas que hai un problema cos casos de proba, apúntalo politamente: "Eu creo que pode haber un caso de borda aquí que non cubrimos - o que debería acontecer cando ...?" E aquí está o grande: podes construír un informe.Unha pequena conversa ao comezo axuda. ou Durante a entrevista, cando che dan unha pista, podes dicir Show you value their input. “Como vai o teu día?” "Grazas por tomar o tempo para me entrevistar" "Ah, iso é un bo punto, eu non tiña pensado iso." A entrevista é unha rúa bidireccional.Vostede está avaliando a eles tanto como eles están avaliando a vostede. Un proceso de pensamento claro vale mil liñas de código Prefiro que un candidato escriba 20 liñas de código claro e ben razoado que 200 liñas de parvadas intelixentes. Cando estás codificando nunha entrevista, a claridade vence a intelixencia. non e Pero e Si, mesmo nunha entrevista, leva 3 segundos adicionais e fai que o seu código sexa infinitamente máis legible. Name your variables properly. x y userCount maxRetries Se estás a escribir un gnarly one-liner que fai cinco cousas, divídeo en múltiples pasos con variables intermedias. Break down complex logic. unha rápida antes dunha operación de filtro complexo pode salvar o entrevistador de ter que reverter a súa intención. Add comments if it helps. // Find all users who haven't logged in for 30+ days Digamos Deste xeito, se estás no camiño equivocado, o entrevistador pode corrixirte cedo. Think out loud before you code. "Vou repetir a matriz e construír un mapa de hash de valores a índices" Unha vez entrevistei a un candidato que resolveu o problema cunha solución recursiva incrible elegante que non podía seguir. Cando lles pedín que a explicasen, non puideron articular por que funcionou. Compare iso a outro candidato que escribiu unha solución iterativa sinxela con nomes de variables claros e pasou por min a través de cada paso. O seu obxectivo non é impresionar ao entrevistador co seu brillo. O seu obxectivo é demostrar que pode escribir código que os seus compañeiros de equipo entenderán en seis meses. 9 Coñece os teus límites A xestión do tempo nas entrevistas é brutal.Estás sendo avaliado mentres simultaneamente intenta resolver problemas baixo un reloxo de tempo. Isto establece o seu timer interno e axuda a acelerarse a si mesmo. At the start, clarify the time limit. Xa temos 45 minutos, non si? Dime que: Non queime a metade do seu tempo de entrevista sendo teimoso. If you're stuck for more than 3-5 minutes, speak up. "I've been thinking about this for a few minutes and I'm not making progress. Can I get a hint?" Se a entrevista ten varios problemas e estás atrapado no primeiro, pregúntalle: "Debería seguir traballando nisto, ou quererías que pasase ao seguinte problema?"Ás veces os entrevistadores queren ver amplitude, non só profundidade nun problema. Know when to move on. Non pases 40 minutos codificando e despois non tes tempo para probar a túa solución. Se terminas con 5-10 minutos restantes, camiña polo teu código con algunhas entradas de exemplo. Atopa os teus propios erros antes de que o entrevistador o faga. ! Save time for testing. Asegúrese de que os execute Se tes un traballo solución con 5 minutos restantes, non intente refactorala para Mencione o que optimizaría se tivese máis tempo, pero entregue unha solución de traballo primeiro. Be realistic about optimisation. O(n²) O(n log n) Fracasei nunha entrevista unha vez porque pasei 35 minutos perfeccionando o primeiro dos tres problemas, entón tiven que afrontar os outros dous. Mostra profundidade, pero non a forzas Se traballou con sistemas distribuídos, estratexias de caché, ou patróns arquitectónicos complexos, e o problema leva naturalmente alí, menciona-lo. Entrevistei candidatos que, cando se lles pediu que implementasen unha simple función de reversión de cadeas, lanzaron unha disertación de 10 minutos sobre normalización de Unicode, cúmulos de gráficos e manexo de texto de dereita a esquerda. Se o entrevistador parece interesado e fai preguntas de seguimento sobre a súa experiencia con sistemas distribuídos, esténdese. Aquí está un bo patrón: resolver o problema primeiro, despois ofrecer profundidade. "Esta solución funciona para os requisitos que discutimos.Na produción, eu tamén consideraría [preocupación avanzada específica], pero estou asumindo que está fóra de alcance para este exercicio. Este enfoque mostra que entende o contexto máis amplo sen desviar a entrevista. Unha vez cometín o erro de gastar 15 minutos explicando como implementaría o límite de taxa para un punto final de API cando a pregunta era só Aprende do meu fracaso: responde a pregunta feita, non a pregunta que desexaría que lles fixesen. "Escribe unha función que valida os enderezos de correo electrónico". +1 Sempre pedir feedback A maioría das empresas non lle darán comentarios detallados (razóns de responsabilidade, na súa maioría), pero paga a pena preguntar de todos os xeitos. Se recibes a oferta: "Grazas moito! podo preguntar o que pasou ben na entrevista? Se é rexeitado: Entendo que pode ter políticas en torno ao feedback, pero se é capaz de compartir algo sobre como podo mellorar para futuras entrevistas, eu realmente agradecería. " Algúns entrevistadores ignorarán isto. Algúns darán platitudes xenéricas. Pero de cando en vez, recibirás un feedback auténtico e actuable que che axudará na túa próxima entrevista. "Vostede sobreexplicou as cousas, non considerou o seu público" "A túa solución foi correcta, pero loitei por seguir o teu proceso de pensamento" "Está claro que tes moita amplitude, pero apreciariamos un pouco máis de profundidade nalgúns temas" As entrevistas son unha mina de ouro para a súa viaxe de auto-enriquecemento. Aquí está algo que a maioría dos candidatos non saben: algúns entrevistadores están cómodos de falar sobre a entrevista despois directamente - a través de correo electrónico ou LinkedIn. A maioría dirá que si, e abre unha canle para un feedback máis sincero do que podería proporcionar HR. "Sería bo se contactase con vostede directamente en LinkedIn se teño algunha pregunta de seguimento?" Polo menos, pedir feedback mostra que vostede é alguén que quere crecer. Mesmo se non obtén información útil, deixa unha impresión positiva. Durante o meu tempo en Docler, tivemos un candidato frecuente, que volvía diligentemente, cada seis meses. Sempre deixou con feedback e nunca cometeu o mesmo erro dúas veces. Na última ocasión, fixo unha entrevista perfecta. Aínda traballa alí ata o día de hoxe. O peor resultado é que non escoitas nada.O mellor resultado é que aprendes algo que che trae o seguinte traballo. Good luck! Desexo a mellor sorte na súa próxima entrevista! Se as miñas suxestións axudou a vostede, ou se ten máis trucos útiles para compartir, imos falar!