En entrevistas técnicas, ¿debería hablar mientras codifica la solución? Cuando el entrevistador le pide que lo escriba, ¿debe explicar su código al entrevistador mientras lo escribe, o debe escribir el código en silencio?

Si bien puede parecer abrumador hacerlo, es una buena idea hablar durante la entrevista de codificación. Al igual que “mostrar su trabajo” en un examen en la universidad le brinda la oportunidad de obtener un crédito parcial, incluso si no obtiene la solución correcta, hablar durante el proceso de codificación puede brindarle la misma ventaja durante la entrevista.

Ser capaz de demostrar cómo analiza un problema y explicar su proceso de pensamiento le da al entrevistador una visión sólida de cómo resuelve el problema. Hablar durante su entrevista de codificación le da una idea de sus habilidades de comunicación. También les da la oportunidad de interactuar con usted y determinar dónde se equivoca si comete un error, lo que hace que sea más fácil “pasarlo” en la entrevista general.

Si bien puede ralentizarlo, hablar mientras escribe la solución es, en general, una estrategia mucho mejor para una entrevista de codificación. Ayuda al entrevistador a conectarse con sus ideas. También evita que la situación sufra a través de un largo silencio incómodo. Una entrevista es una interacción, así que entusiasmarse para mostrar sus habilidades, no tenga miedo de hablar frente a la persona que lo evalúa. No se deje abrumar y estresarse tratando de equilibrar la escritura del código, pensando en su proceso y explicando verbalmente, pero no tenga miedo de reducir la velocidad para expresar sus pensamientos.

La práctica adicional con herramientas en línea, como Pramp, puede ayudarlo a mejorar su confianza y velocidad, y hacer que sea más fácil hablar sobre su proceso mientras escribe el código.

Desde mi experiencia personal, es muy importante hablar mientras se piensa y se codifica.

¿Por qué hablar mientras piensas? Una entrevista es más como un proceso de trabajar en un problema interesante con el entrevistador que como una prueba. Entonces, su capacidad de análisis, las habilidades de comunicación se evalúan durante este proceso y la única forma de mostrarle al entrevistador estas habilidades es a través de la conversación. También es importante que el entrevistador conozca su dirección, ya que pueden darle una pista o hablar con usted si no está en la pista, lo que podría ahorrarle mucho tiempo. En el peor de los casos en que no resolvió el problema, pero permanezca callado mientras piensa, el entrevistador difícilmente puede darle comentarios positivos, incluso si está muy cerca de la respuesta.

¿Por qué hablar mientras se codifica? En resumen, ayuda al entrevistador a comprender su código. Puede argumentar que se vuelve lento en la codificación cuando habla al mismo tiempo. Sin embargo, puede pasar más tiempo explicando el código al entrevistador para que lo entienda. Además, esto le da la oportunidad de comunicarse con el entrevistador también. Probablemente te quedaste en cierto punto y el entrevistador puede ayudarte si entiende tu código.

¿Cómo practicar esto? Siempre habla mientras preparas tu entrevista. Inicialmente hice esto para cada pregunta que practicaba. Podría ser de http://www.glassdoor.com o también podría ser de http://www.leetcode.com . El punto es hacer exactamente lo mismo que haces en una entrevista real.
Más tarde, obtuve mi entrevista simulada de http://www.gainlo.co, donde puedo practicar esto con un entrevistador simulado de Google / Facebook. Esto me da una buena oportunidad para verificar si mi comunicación es clara porque el entrevistador simulado me preguntará si está confundido.

Si los entrevistadores le piden explícitamente que hable mientras codifica, hágalo. Recientemente solicité un trabajo y los entrevistadores me pidieron que dijera constantemente lo que estaba pensando y haciendo mientras escribía el código. Puedo hablar o cantar fácilmente mientras toco la guitarra, porque lo he practicado durante muchos años. Pero soy pésimo para hablar mientras codifico, porque siempre trabajé en silencio, a menudo escuchando música instrumental, porque me mantenía enfocado. Me puse nervioso porque la entrevista tuvo una duración de 45 minutos y el proceso de hablar-escribir-hablar disminuyó mi pensamiento y mi codificación. Peor aún, la configuración del teclado era tan incómoda que hice muchos errores tipográficos, y los entrevistadores seguían señalando los corchetes y los puntos y comas que omití, así que me puse nervioso y no terminé la prueba a tiempo, y pasé mucho tiempo arreglando esos errores tipográficos e intentando implementar el código. Soy un desarrollador full-stack, y durante muchos años he desarrollado aplicaciones del lado del servidor, servicios web, REST Apis, aplicaciones de teléfonos inteligentes, juegos de teléfonos inteligentes, interfaz front-end html, interfaz del lado del cliente, JavaScript, SVG, Canvas , complementos jQuery, directivas AngularJS, interfaces React, etc. Pasé muchas certificaciones de Microsoft y escribí 44 artículos y gané 22 veces el título de mejor artículo del mes en el sitio web codeproject.com. Pero como no terminé la prueba a tiempo, los entrevistadores me dijeron que no soy un buen desarrollador front-end. Si algunas compañías piensan que soy un mal programador solo porque no puedo comunicar bien todo lo que sucede en mi cabeza mientras estoy codificando, afortunadamente hay muchas otras que me permitirán tomarme mi tiempo para concentrarme y hacer mi trabajo en silencio. .

Al comienzo de la entrevista les digo a mis candidatos que siempre deben escribir o hablar. Está perfectamente bien codificar en silencio si eso le conviene mejor, pero cuando haga una pausa y piense, hágame saber en qué está pensando.

No me malinterpretes, está perfectamente bien hablar mientras escribes código si te parece natural, pero no te obligues a parlotear mientras codificas. De hecho, me resulta un poco desconcertante si un candidato explica cada línea de código en la pizarra con gran detalle (especialmente si ralentiza la entrevista). Conozco muy bien el lenguaje de programación y el problema, no hay necesidad de ayudarme a entender lo que escribiste a menos que tu escritura sea ilegible. Si no lo entiendo (o no puedo leerlo), lo preguntaré.

Es crucial que pienses en voz alta si no estás escribiendo nada. En primer lugar, si estás atrapado y no me dices dónde, no puedo ayudarte. Además, estoy interesado en su proceso de pensamiento, es una parte importante de los comentarios de la entrevista.

Lo hace. En una de mis entrevistas técnicas me pidieron específicamente que hablara en voz alta. El propósito de esta entrevista en particular era evaluar mi capacidad de pensar y encontrar alternativas, aunque encontré el propósito mucho más tarde.

Sin embargo, pensar en voz alta ayuda a informar al evaluador que está pensando en la dirección correcta. Incluso si su solución no es correcta, lo que le dice al evaluador es que está pensando.

Para los programadores, este es el rasgo más importante. La mayoría de las veces, mientras programamos, estamos pensando en hacer las cosas correctamente en un contexto.

Además, en una entrevista se encuentra en un entorno restringido con poco acceso a fuentes de conocimiento externas. Entonces, los buenos asesores entienden esto y lo evaluarán en función de esta desventaja. Sin embargo, en entornos de programación reales, accederá al inmenso poder de Internet, así como a sus pares y personas mayores con más conocimientos.

Entonces un buen asesor pesará en todo esto. En pocas palabras, continúe y hable en voz alta, realmente ayudará incluso si se equivoca al responder preguntas específicas.

Al final del día, la programación se trata de pensar en no obtener una pregunta de programación específica en un período de tiempo limitado.

Sin embargo, si siente que afecta su concentración al pensar en voz alta, no piense en voz alta, pero explíqueles a los entrevistadores a fondo una vez que haya terminado de escribir el fragmento.

Mi experiencia es que cuando se codifica una solución en una entrevista técnica, rara vez es tan simple como levantar el marcador de la pizarra y escribir sin parar hasta que el código haya terminado. La mayoría de las veces, tendrá que tomarse un tiempo para hacer una pausa y pensar. En ese punto, es bueno pensar en voz alta, y realmente no te frena.

Si está escribiendo algo simple donde tiene una imagen clara del código en su cabeza, de todos modos no le llevará mucho tiempo escribirlo, por lo que no es un gran problema si está callado; Puedes discutir el código después.

Según mi experiencia, debe hacer lo siguiente:

1. Comprende la pregunta
2. Analiza la solución en tu mente
3. Comience a escribir la solución en la pizarra. Es posible que no se sienta completamente cómodo escribiendo un código sintácticamente correcto (como la mayoría de las veces codificamos con un IDE u otro). Entonces escriba algún comentario al lado de ese código.
4. Una vez que hayas terminado. Vuelva a evaluar su solución una vez más
5. Comience explicando la solución al entrevistador
6. Siempre es bueno explicar la lógica y si tiene más de una solución, explíquela también. Mostrará su dedicación para resolver la solución.

Deberías pensar en voz alta.

Deje que el entrevistador conozca su enfoque y sus confusiones.

Pensar en voz alta puede buscarte la próxima ronda, incluso si tu código no está completo porque tu entrevistador tuvo la oportunidad de saber lo que estabas pensando.
A veces, esto puede ayudarlo a asegurarse de que ha entendido el problema correctamente.

Debe explicar por qué eligió seguir la ruta que eligió en su solución. A medida que toma decisiones, simplemente dé una razón por la cual es ruidosa para que el entrevistador pueda seguirla y potencialmente hacer preguntas. Por qué elegiste resolver algo de esa manera es tan importante como hacerlo bien.

Creo que debería estar mucho más centrado en el código en lugar de preocuparse por la cantidad de patrones que debería estar haciendo simultáneamente. Si tiene una gran respuesta, no importará. Si tiene una respuesta terrible, tampoco importará. Si está luchando, podría ayudar un poco comunicar lo que está atrapado, ya que puede haber entendido mal la pregunta.