El mejor consejo de entrevista de pizarra que he recibido

Las entrevistas estilo pizarra son omnipresentes en la industria tecnológica. Para aquellos que no tuvieron el placer, la entrevista de pizarra es la práctica de pedirles a los candidatos que resuelvan preguntas técnicas en una pizarra, una hoja de papel o una computadora durante la entrevista. Este tipo de entorno puede sentirse como una olla a presión y hacer que incluso el ingeniero más competente se derrumbe.

En este artículo, tengo la intención de transmitir el mejor consejo que he recibido para pasar por una entrevista de pizarra. Tenga en cuenta que no tengo la intención de abordar la equidad o la eficacia de las entrevistas de pizarra porque, bueno, como entrevistados actualmente tenemos que lidiar con ellas de todos modos.

El consejo: ¡Comunícate!

El mejor consejo de entrevista técnica que he recibido y puedo impartirle es ¡comunicar, comunicar, comunicar! Esto puede parecer un consejo anticlimático, pero espero poder demostrarle que en realidad es la habilidad más importante para prepararse antes de una entrevista.

Nota : como discuto ejemplos en el resto de este artículo, tendrán una inclinación de ingeniería de software, ya que es el dominio más familiar para mí. A pesar de esa inclinación, puede aplicar estas habilidades a cualquier entrevista estilo pizarra.

¿Qué quieres decir con comunicar?

Digamos que estás en la entrevista y tus entrevistadores te lanzan una pregunta de pizarra. ¿Te acercas a la pizarra y empiezas febrilmente a resolver el problema?

¡No!

Ese tiende a ser el instinto de todos, pero definitivamente no es el camino correcto a seguir. Incluso si cree que comprende el problema, debe tomar algunos pasos muy importantes antes de seguir adelante.

Primero, repita la pregunta

¿Entiendes lo que te piden que hagas? Pruébalo. Repita la pregunta para ellos y busque la afirmación. Es posible que se sorprenda al descubrir que no comprende completamente lo que están pidiendo; tal vez la pregunta sea similar, pero no la misma, a un problema de práctica que haya completado en el pasado. Usando el ejemplo probado y verdadero de fizz-buzz, podría volver a plantear el problema de la siguiente manera:

“Así que me gustaría volver a plantearle el problema para asegurarme de que entiendo lo que está buscando. El único parámetro para mi función será un número entero. La única salida de mi función será una matriz incremental, comenzando desde el número 1 y terminando en el número de entrada.

Si un número es un múltiplo de 3, la salida será `fizz`. Si un número es un múltiplo de 5, la salida será `zumbido`. Sin embargo, si la salida es un múltiplo de 3 y 5, la salida será `fizzbuzz`. ¿Es correcto mi entendimiento?”

La entrevista debe darle afirmación o, tal vez, su comprensión es incorrecta y lo ayudarán a comprender. No hay ninguna situación en la que volver a plantear el problema le haga daño; muestra que puede articular un problema y le da tiempo para pensarlo un poco mientras discute. Además, comenzar la discusión de esta manera ayudará a calmar algunos nervios que de otro modo podrían manifestarse al tratar de resolver el desafío real.

Pregunte sobre casos extremos

Todavía no es el momento de sumergirse directamente en la codificación de la solución. Piense un poco en las entradas y el resultado esperado y piense en posibles casos extremos del problema. Pregunta por ellos. En muchos casos, el entrevistador ni siquiera ha pensado en los casos extremos e inventará algo. Eso es genial: demuestra que eres analítico y que trabajarás duro para tratar de evitar errores (que a menudo surgen debido a casos extremos).

Usemos el ejemplo del fizz-buzz. Después de replantear con éxito el problema, una forma válida de preguntar sobre los casos límite sería la siguiente:

“Ahora que confirmé mi comprensión del problema, me gustaría preguntar acerca de algunos posibles casos extremos. ¿Es posible que la entrada sea de otro tipo que no sea un número? Si es así, ¿qué debería hacer la función? ¿La entrada puede ser 0 o negativa? Nuevamente, si es así, ¿qué debería hacer la función?

Preguntar sobre casos de prueba

Esto es gratis y debes aprovecharlo. Simplemente pregunte si hay algún caso de prueba que la función deba pasar. Tu entrevistador podría estar esperando que hagas esta pregunta, por lo que podría ser necesario. Pero también es posible que el entrevistador no se esperaba la pregunta y pensará "¡ah, este candidato sabe de exámenes!".

Escribir pseudocódigo y preguntar si tiene sentido

(Escriba pseudocódigo y verifique su lógica)

Nuevamente, en realidad no desea comenzar a escribir código en un idioma real. Se verá limitado al tratar de recordar los métodos u otras idiosincrasias del idioma en lugar de intentar encontrar la lógica correcta. En su lugar, infórmele a su entrevistador que comenzará escribiendo un pseudocódigo y luego completará el código real. (Casualmente, esta también es una forma razonable de escribir código real).

Aquí está el truco: puedes preguntar si tu pseudocódigo tiene sentido para el entrevistador. Es posible que sean del tipo que no quiere "darte pistas", pero también es posible que estén más interesados en cómo piensas y quieran hablar contigo sobre tu pseudocódigo. Cuando entrevisto a candidatos, me interesan más los últimos; rara vez desarrollamos software en el vacío.

En otras palabras, en el peor de los casos, el entrevistador le dirá que continúe sin ofrecer comentarios. En el mejor de los casos, el entrevistador podría señalar fallas lógicas en su pseudocódigo que le darán un gran beneficio al hacer la transición al código real.

Súper bono : si su pseudocódigo se ve bien pero termina teniendo dificultades para traducirlo a código real, ¡ya ha ganado muchos puntos! Claro, en algunas empresas de élite no aceptarán nada más que código funcional, pero simplemente ser capaz de razonar a través del pseudocódigo es suficiente para muchas grandes empresas.

De acuerdo con nuestro ejemplo de fizz-buzz, digamos que se nos ocurrió el siguiente pseudocódigo. En última instancia, escribiremos nuestro código en javascript, pero en este momento no importa.

 function fizzBuzz ( n ) { // If n is not a number or not an integer greater // than zero, return null // create empty array to store output // Loop through numbers from 1 to n // If number modulo 3 is zero, add 'fizz' // to output array // Else If number modulo 5 is zero, // add 'buzz' to output array // Else If number modulo 3 is zero and // number modulo 5 is zero, add 'fizzbuzz' // to array // Else add the number to the array // return output array }

En este punto, es posible que te des cuenta de que nunca llegarás a la tercera declaración `else-if`. Alternativamente, cuando confirme su pseudocódigo con el entrevistador, es posible que se lo ofrezcan gratis (en serio). En ese caso, puede reescribir su pseudocódigo para asegurarse de verificar primero la tercera condición:

 function fizzBuzz ( n ) { // If n is not a number or not an integer greater // than zero, return null // create empty array to store output // Loop through numbers from 1 to n // If number modulo 3 is zero and // number modulo 5 is zero, add 'fizzbuzz' // to array // Else If number modulo 3 is zero, add 'fizz' // to output array // Else If number modulo 5 is zero, // add 'buzz' to output array // Else add the number to the array // return output array }

Escriba el código real y pregunte si se ve bien

(Finalmente comenzar a escribir código)

Ahora debe convertir su pseudocódigo en código real. Ni siquiera es necesario eliminar los comentarios. En este punto, solo necesita ingresar el código apropiado para su idioma. Si olvida alguna sintaxis o el nombre de un método, debería poder pedirle esta información a su entrevistador sin demasiado dolor. Si te dan problemas, solo di que lo dejarás como pseudocódigo por ahora.

 function fizzBuzz ( n ) { if ( isNaN (n) || ! Number .isInteger(n) || n < 1 ) return null ; let output = []; for ( let i = 1 ; i <= n; i++) { if (i % 3 === 0 && i % 5 === 0 ) { output.push(“fizzbuzz”); } else if (i % 3 === 0 ) { output.push(“fizz”); } else if (i % 5 === 0 ) { output.push(“buzz”); } else { output.push(i); } } return output; }

En este punto, no dude en preguntar si su solución se ve bien. Si no es así, podrían ofrecer algunos consejos para mejorarlo. Toda esta comunicación le otorga puntos: parecerá elocuente y más fácil trabajar con usted si está dispuesto a analizar objetivamente las formas de mejorar su trabajo.

¿Atascado? ¡Pedir ayuda!

(¡Pedir ayuda!)

Si tiene problemas en el camino, no es ilegal pedir ayuda. Simplemente expréselo conversacionalmente. Por ejemplo:

"Estoy un poco atascado aquí, ¿tiene algún consejo para empujarme en la dirección correcta?"

La respuesta podría ser "no, me gustaría ver si puedes resolverlo desde aquí por tu cuenta", ¡pero también podría ser un "sí" con un consejo útil!

Bonificación: comunicación previa a la entrevista

Debe tener un punto de contacto de recursos humanos o entrevista antes de la entrevista. ¿Tiene curiosidad por saber si habrá una parte de codificación de la entrevista? ¡Pregúntales! Además, puedes preguntar si hay algo en particular que debas preparar. Es muy posible que le den sugerencias como especificar el idioma en el que harán las preguntas, la cantidad de preguntas, el estilo de la pregunta (por ejemplo, desarrollar un algoritmo o encontrar el error). Es posible que le digan si estará sentado frente a una computadora o parado frente a una pizarra: información muy útil que podría usar para practicar o, al menos, prepararse mentalmente.

todos somos humanos

Sobre todo, recuerda que todos somos humanos. Su entrevistador ha estado en su posición y comprende el estrés de una entrevista técnica. Su entrevistador probablemente haya visto bastantes candidatos sudando, pero posiblemente muy pocos abiertos que discutan abiertamente los problemas de una manera conversacional. Si puedes lograr esto, estarás en gran forma.

¿Cuál ha sido tu experiencia?

¿Has estado en una entrevista técnica donde la comunicación te salvó? ¿Has tenido la experiencia contraria? ¡Házmelo saber en los comentarios! Me encantaría saber de sus experiencias.