Cómo prepararse para una entrevista técnica: consejos y trucos que le ayudarán a rendir al máximo

Ah, la entrevista de codificación.

"Temed. Huye de él. Destiny llega de todos modos". - Thanos 2018

Ok, tal vez eso sea un poco dramático, pero no conozco a nadie que esté emocionado por pasar por el proceso de entrevista. El proceso de búsqueda de trabajo / entrevista es agotador en el mejor de los casos y muchas otras cosas en el peor.

Mucha gente estudia trucos y tácticas para una entrevista (y también te daré algunos de ellos), pero la mayoría de las personas no piensan en su forma de pensar antes de la entrevista.

Tu mentalidad marca el tono de cómo vas a ver y dar forma a tu situación. Entra con la mentalidad correcta y podrás comprender y navegar por cualquier cosa que se te presente. Entra con la mente dispersa o tímida y te verás sacudido y maltratado.

Tu tambien eres el entrevistador

Una cosa que la mayoría de la gente suele olvidar es que tú también eres el entrevistador.

Sí, estás siendo entrevistado en esta empresa, pero también se está entrevistando a la empresa para ver si ellos son una buena opción para usted.

¿Cuáles son los valores de esta empresa? ¿Cómo es su ética de trabajo? ¿Qué valora la gente?

Pasar la entrevista es importante, pero ¿quieres trabajar en esta empresa si apruebas?

A veces solo necesitamos un trabajo, cualquier trabajo, por lo que no quiero minimizar el simple hecho de conseguir el trabajo. Pero si puede, dé un paso atrás y piense cómo este trabajo afectará su carrera a largo plazo. Decir que sí a un trabajo es decir que no a una docena de personas más; está pagando un gran costo de oportunidad al decir que sí.

Entonces eso es lo primero que debe recordar: esta no es una dinámica de poder unidireccional. Puede parecerlo a veces, pero aquí tienes cierto control y tienes opciones. Esto es empoderador.

Tipos de entrevistas

Ok, por lo que estamos también evaluando la compañía basado en las personas que interactúan con el proceso de entrevista, así que lo que hacemos con esa información?

Bueno, hay algunos tipos diferentes de entrevistas técnicas. Estos tipos de entrevistas nos dicen mucho sobre la mentalidad de la empresa y cómo es trabajar allí. Desgloso los diferentes tipos de esta manera:

  • Pizarra
  • Desafío de código (preguntas o algoritmos de informática)
  • Desafío de código (problema de codificación razonable)
  • Proyecto para llevar a casa

La temida pizarra

Algunos de los primeros ejercicios de entrevistas que adoptó la industria tecnológica fueron ejercicios de pizarra. Se le asignará una tarea y se le pedirá que escriba el código en la pizarra. En general, este enfoque es menospreciado y está siendo eliminado en la industria de la tecnología hoy, pero todavía hay muchas empresas que emplean esta práctica.

No es que codificar en una pizarra sea malo en sí mismo, sino que una pizarra está tan lejos del trabajo que realmente hacemos como programadores que trabajamos en computadoras todos los días. La pizarra es torpe para escribir, editar y no le da ningún comentario: no hay autocompletar, no hay resaltado de sintaxis y no puede ir a Google para buscar las referencias de la biblioteca estándar.

Además de eso, muchos lugares que emplean entrevistas de pizarra también hacen un cierto conjunto de preguntas de entrevista que, francamente, no tienen valor para el 99% de los trabajos de programación que existen. Estos son los temidos algoritmos informáticos: invertir un árbol binario, encontrar el camino más corto en un gráfico, etc.

El problema con estas preguntas es que simplemente no surgen en la vida real como programador. Si estás entrevistando en Amazon o Facebook, seguro, tal vez tengan algún valor allí, pero la mayoría de las personas nunca enfrentarán este problema en su carrera. Y si lo hacen, solo usarán algún paquete o biblioteca que ya haya implementado esa funcionalidad.

Entonces, ¿qué podemos hacer con las pizarras blancas? Bueno, esto es lo que haría: haga todo lo posible, utilice los consejos y trucos que se describen a continuación y evalúe seriamente si esta práctica de entrevista es un síntoma de un problema de mentalidad más grande dentro de la empresa.

Desafíos de código

Si tiene la suerte de esquivar la pizarra, la mayoría de los lugares le pedirán (y probablemente deberían) que haga algún tipo de desafío de código. Nuevamente, esto puede parecer una dinámica de poder unidireccional, pero este desafío de código es realmente bueno para usted. Aquí es donde puede brillar y mostrar su competencia técnica, y en mi experiencia, esto afecta drásticamente su poder de negociación cuando se trata de rango de trabajo y salario.

Antes de entrar en los consejos específicos, también debemos ser conscientes de que el hecho de que haya esquivado la pizarra no significa que no obtendrá la pregunta sobre el algoritmo informático aquí, solo en una computadora. Si ese es el caso, simplemente respire profundamente y use los consejos y trucos a continuación. Lo superarás.

Si tiene la suerte de esquivar la pizarra y la pregunta de CS, probablemente se le haya presentado un desafío de codificación razonable. Para mí, estas son preguntas como:

Escribe una función que tome una cantidad de centavos (USD) como un número entero menor o igual a 100 e imprima la menor cantidad de monedas necesarias para representarla.

50 => 2 cuartos

11 => 1 centavo y 1 centavo

7 => 1 centavo y 2 centavos

También he recibido preguntas que parecen preguntas de informática, pero en realidad no son tan malas. Por ejemplo, "implementar una lista doblemente enlazada". A primera vista, esto parece un problema de CS debido a la parte de la "lista doblemente enlazada", pero lo que el entrevistador realmente quería era un código que implementaba el mismo comportamiento que una lista doblemente enlazada: no estaba usando punteros y direcciones objetos en la memoria, simplemente imitando el mismo comportamiento. En ese caso, terminó siendo un desafío bastante simple.

Y eso me lleva a mi primer consejo:

Consejo n. ° 1: haga preguntas aclaratorias

En el desafío de la lista doblemente enlazada, me dieron un archivo Ruby en blanco (me estaba entrevistando para un trabajo Ruby) y un conjunto de pruebas en blanco. Algo como esto:

class DoublyLinkedList end 

(Si no está familiarizado con Ruby, no se preocupe. El código aquí será fácil de entender. Solo está aquí para ilustrar los puntos generales).

Entonces, una lista doblemente enlazada, ¿eh? Quizás sepas qué es eso, o quizás no. Si no lo hace: haga preguntas. Este es el primer escollo a evitar. Si no comprende el problema o lo que están pidiendo, siga haciendo preguntas hasta que lo entienda.

He visto a los entrevistados seguir el camino equivocado y el entrevistador simplemente los dejó, mientras que silenciosamente los va a fallar. Si bien no estoy de acuerdo con esta práctica, asegúrese de que está resolviendo el problema correcto.

Vengo de una formación en informática, así que sabía que una lista doblemente enlazada significa una lista que tiene un puntero a un heady un tailnodo, donde cada nodo también apunta a su nodo nexty previous.

Ahora, aunque sabía eso, ¿qué hice? Dije eso en voz alta y pregunté si eso era correcto. Aunque pensé que sabía qué hacer, me aseguré absolutamente de hacerlo.

Una vez que crea que comprende el problema, reafirme su comprensión al entrevistador para que pueda corregirlo o guiarlo.

Lo siguiente que hice fue hacer otra pregunta: "¿Puedo usar una matriz para los nodos?" Y escribí algo como esto:

class DoublyLinkedList def initialize @nodes = [] end end 

(Si no está familiarizado con Ruby, esto es solo un inicializador o constructor donde hago una nueva variable llamada @nodesestablecer en una matriz vacía).

Pero el entrevistador me dijo que no, no podía hacer eso, lo cual tiene sentido. Si hubiera usado una matriz, habría frustrado todo el propósito del ejercicio que es construir los "punteros" falsos entre los nodos.

Y chico, me alegro de haber preguntado. No quería correr el riesgo de que el entrevistador me dejara usar la matriz y luego me fallara.

Así que no hay matriz, bueno, ¿qué hago ahora? Aquí está el consejo n. ° 2:

Consejo n. ° 2: codificado -> tonto -> mejor

Cuando se enfrente a un desafío de codificación, resuelva el problema en el siguiente orden: codificado -> tonto -> mejor -> incluso mejor (si el tiempo lo permite).

En mi experiencia al ser entrevistado y entrevistar a otros desarrolladores, encuentro que la mayoría de la gente trata de hacer demasiadas cosas a la vez.

Cuando hace demasiado a la vez, es fácil cometer errores (que no podrá detectar debido a que tiene InterviewBrain ™). Así que comience de manera simple, de hecho, lo más simple que pueda, codificado de forma rígida, y vaya subiendo.

Entonces tengo una clase Ruby en blanco, ¿cómo puedo codificar algo para avanzar? Miré mi suite de prueba vacía y vi que había una función llamada headque devolvía el primer nodo de la lista, así que intentemos eso:

class DoublyLinkedList def head 'A' end end 

Hice una headfunción y codifiqué la letra mayúscula "A" como una cadena, y ejecuté esa prueba. Pasó.

¿Es esto super simple? ¿Es demasiado obvio? ¡Si! Pero este código hace dos cosas muy importantes:

  • Me permite ejecutar las pruebas y probar que mi configuración funciona (eliminando cualquier error tonto o de sintaxis)
  • Me da una victoria rápida, lo que aumenta mi confianza

Hay innumerables entrevistas que he visto en las que alguien comete un pequeño error al principio, se pone nervioso y luego pasa la mayor parte de la entrevista tratando de recuperarse y arreglar lo que está mal.

No subestime el valor de las ganancias rápidas para su confianza. La acumulación de pequeñas ganancias lo impulsará a través de la entrevista.

Ok, tenemos una cadena codificada 'A'. Ahora, ¿cómo podemos convertir eso en una solución tonta ? Bueno, ¿qué tal convertir esa letra "A" en un hash (o mapa)?

class DoublyLinkedList def head { value: 'A' } end end 

Eso está un poco mejor. Ahora, en lugar de una cadena de un carácter, nuestro "nodo" se representa como un hash con una valuepropiedad. Hemos pasado de codificados a tontos. Ahora, ¿cómo podemos mejorarlo? Bueno, ¿qué tal si introducimos nuestro headpuntero en la lista?

class DoublyLinkedList def initialize @head = { value: 'A' } end def head @head end end 

¿Qué cambiamos aquí? Aquí volvemos a agregar nuestro inicializador y creamos una nueva variable llamada @head, y usamos esa nueva variable en nuestra headfunción. Esto empieza a parecerse a un código real.

Ahora bien, este enfoque puede parecer realmente tonto, pero te prometo que funciona. Cada uno de estos cambios se realiza en segundos de codificación iterativa pequeña, y se acumulan para producir una implementación funcional en poco tiempo.

Si está pensando que este enfoque le parecerá extraño a un entrevistador potencial, aquí está el siguiente consejo, y este es muy importante:

Consejo n. ° 3: hable. En voz alta.

Todo el tiempo que esté haciendo un desafío de codificación debería estar hablando en voz alta.

Di todo lo que estás pensando, todo.

(Bueno, todo lo relacionado con la programación).

Aquí está la cuestión: llegar a una solución correcta es importante, sí, pero igualmente, si no más importante, es mostrar su proceso de pensamiento. El entrevistador quiere saber cómo piensa, cómo resuelve los problemas. Puede hacerlo compartiendo todo lo que está pensando en voz alta.

Cada entrevistador ha sido en algún momento un entrevistado: conocen InterviewBrain ™ y que incluso las cosas simples pueden volverse difíciles en una entrevista. A los buenos entrevistadores no les importa que usted obtenga la solución 100% correcta, solo quieren saber que posee buenas habilidades de pensamiento crítico. La única forma de hacer visibles estos pensamientos internos es decirlos en voz alta.

Si nunca ha hecho esto antes, es posible que desee practicarlo porque es vital para clavar la entrevista.

Para darle algunos ejemplos prácticos, aquí hay algunas cosas que digo cada vez que me entrevista:

"Bien, codifiquemos este valor y asegurémonos de que nuestra configuración funcione". "Primero, consigamos una versión tonta de esto que funcione y mejoremos". "Lo haré así por ahora, y si tenemos tiempo, regresemos y hacer "." Ok, entonces necesitamos una función que tome una matriz, haga X y regrese ".

En algunos escenarios, estas entrevistas pueden empezar a parecer sesiones de programación en pareja.

Ok, estamos diciendo las cosas en voz alta. Pero a veces cometemos un error o nos atascamos. Hemos estado hablando de nuestro proceso de pensamiento en voz alta, pero ahora es posible que debamos cambiar e investigar un problema o error potencial.

Aquí hay un consejo importante para esto:

Consejo n. ° 4: mantén un flujo lógico

Ahora lo admito: este puede ser difícil a veces.

Si está en una entrevista y hay un problema o error con su código, su cerebro desea desesperadamente descubrir qué está mal, pero no se desespere por comenzar a manipular su código o su proceso de pensamiento.

Verá, al igual que el entrevistador quiere ver cómo desglosa un problema, también quiere ver cómo depura un problema. Esto es tan importante como explicar su proceso de pensamiento. Haga todo lo posible para mantenerse en un flujo lógico y evitar estropear el código o sus ideas.

Si va bien

Así que el desafío va bien y estás solucionando el problema y todas las cosas fáciles.

¿Ahora que? ¿Cómo se pasa de pasado a aplastado?

Esta es una parte extremadamente importante de la entrevista, porque aquí es donde obtiene la mayor parte de su influencia para el nivel de trabajo y la negociación de compensación. Y el consejo es:

Consejo n. ° 5: muestra lo que sabes

Estás trabajando en el desafío, estás hablando en voz alta y lo estás haciendo bien. Lo siguiente que debe buscar son oportunidades para mostrar su conocimiento y experiencia.

¿Es este el lugar del código donde puede enviar un correo electrónico? En su lugar, mencione que debe hacerse en un trabajador en segundo plano (probablemente ni siquiera tenga que implementarlo).

¿Está trabajando en la lógica de validación en un modelo? Hable sobre cómo también agregaría restricciones a la base de datos para garantizar la integridad de los datos. ¿Qué índices agregarías? ¿Cómo implementaría las migraciones para evitar el tiempo de inactividad?

Una vez que tenga su codificación rígida -> tonta -> mejor solución, hable sobre cómo la refactorizaría si tuviera más tiempo. ¿Crearías un módulo para esto? ¿Qué pasa con un objeto de servicio? ¿Qué hay de poner algo de esta lógica en un trabajo de fondo? Analice las compensaciones.

Ahora bien, ¿por qué es esto tan importante?

La mayoría de las preguntas de las entrevistas están dirigidas al mínimo común denominador, es decir, los requisitos básicos del trabajo. El desafío o las preguntas en sí mismos generalmente no están diseñados para probar el extremo superior de la habilidad de alguien . Es probable que la entrevista no le saque la información, por lo que debe proporcionar esa información.

Entonces, mientras habla sobre su proceso mental, mencione todas las cosas que incorporaría en una aplicación o base de código de la vida real y discútalas.

Bolsa de trucos y consejos adicionales

Entonces, así es como debe abordar su entrevista y abordar cualquier desafío que se le presente.

Aquí hay algunos trucos adicionales que a veces se pueden emplear para obtener pequeñas ventajas.

Truco n. ° 1: conozca los problemas comunes

Hay algunos problemas comunes que aparecen con frecuencia en las entrevistas (especialmente en las pizarras). Debe estar familiarizado con estos problemas porque son como preguntas que sabe que estarán en el examen.

Dos de los principales son FizzBuzz y resolver la secuencia de Fibonacci (asegúrese de conocerlos).

Ahora una advertencia: nunca querrá dejar una solución memorizada en una entrevista. Eso solo puede salir mal (y he sido testigo de cómo sucedió). Sin embargo, desea familiarizarse con la solución y poder recrearla desde cero.

Por lo tanto, use sus libros de preparación de preguntas para entrevistas, sí, pero asegúrese de comprender la solución, de que pueda explicarla y de poder volver a crearla desde cero. Una respuesta memorizada no te llevará a ningún lado aquí.

Truco n. ° 2: por lo general, está bien mirar los documentos

En todas las entrevistas en las que he estado o en las que he participado, a nadie le ha importado si busca la biblioteca estándar o los documentos del paquete. Los entrevistadores no están de acuerdo con que busques la respuesta (así que evitaría StackOverflow), pero consultar las referencias suele ser un juego justo. En caso de duda, consulte el Consejo n. ° 1 y solicite una aclaración.

Truco # 3: Esté atento a las señales visuales

Este es probablemente mi truco / consejo favorito. No es el más útil, pero es divertido. Realicé una de mis entrevistas de forma remota, y estábamos usando un programa para compartir pantalla y pude ver la cara del entrevistador en la parte superior derecha de mi pantalla.

Me di cuenta por el rabillo del ojo mientras codificaba que el entrevistador asentía con la cabeza. ¡Ah, ja! Una pequeña señal visual para saber que estaba en el camino correcto.

De nuevo, no es mucho, pero podría ser útil. :)

Truco n. ° 4: si es remoto, tenga una buena configuración

Hablando de ser remoto, si es remoto, intente tener la mejor configuración posible. Esto significa cámara encendida (si es posible, configurada donde estás mirando directamente), buena conexión a Internet, computadora conectada a la corriente, una habitación tranquila, un vaso de agua cerca, etc.

Estas cosas no deberían afectar el resultado de su entrevista, pero no es necesario que moleste al entrevistador o que se sienta más estresado por problemas de ruido o Internet.

Truco # 5: ¡Sea agradable!

Mi último truco para ti es ser agradable.

En su entrevista, ser alguien que usted quiere trabajar con ellos. Muéstrales tu mejor yo.

Las entrevistas pueden ser intimidantes y los desarrolladores son generalmente personas más tranquilas y reservadas, pero debes mostrar a las personas con las que interactúas: "Oye, soy una persona divertida y agradable para trabajar".

No te estoy pidiendo que seas alguien que no eres. Pero no quieres ser, según uno de mis amigos cercanos que entrevista a la gente todo el tiempo, una "criatura marina".

Truco adicional n. ° 6: haga toda la preparación de la otra entrevista (si lo desea)

Si no se siente bien preparado, o si esta es su primera entrevista técnica, haga un trabajo de preparación hasta que se sienta cómodo.

Lea libros como Cracking the Coding Interview o practique algoritmos y acertijos en HackerRank.

Lea las otras publicaciones geniales en Developer News sobre entrevistas.

Si está entrevistando para un puesto completo, prepárese para configurar un nuevo proyecto o archivo de prueba con el conjunto de pruebas desde cero.

Investiga la empresa, prepárate para grandes preguntas sobre la empresa o el trabajo diario, etc., etc.

Al final: es solo una entrevista.

Al final, es lo que es.

Actuará como lo hace.

Serás entrevistado por la persona que te entrevistará.

Su proceso de entrevista será su proceso de entrevista.

Quizás tuviste un mal día, quizás el entrevistador tuvo un mal día.

Después, si se siente avergonzado, derrotado o cualquier otra cosa, ¡respire profundamente y déjelo ir! No dejes que tu cerebro de lagarto te agobie. Una mala entrevista no es el fin del mundo. Tu carrera no está arruinada, tu reputación no está arruinada y tu vida no está arruinada.

Es solo una entrevista. Aprenda de él, adáptese y sea mejor la próxima vez.

Esta bien estar nervioso

La mayoría de la gente (incluido yo mismo) se pone nerviosa antes de cosas como entrevistas, charlas o presentaciones.

Solía ​​pensar en el nerviosismo como algo malo, algo que no quería. Y no importa cuántas veces me dije a mí mismo "no te pongas nervioso", adivina qué: ¡me puso más nervioso!

He aprendido a repensar cómo veo los nervios. El nerviosismo es mi cuerpo preparándose para una pelea, esa respuesta primaria de lucha o huida.

Pero como dijimos antes: esto es solo una entrevista. No hay ningún tigre acercándose sigilosamente a mí en la sala de entrevistas. Esta respuesta primaria no es necesaria.

Empecé a reentrenarme para ver el nerviosismo como algo bueno. Significa que mi cuerpo y mis sentidos se están intensificando para que pueda ofrecer el mejor rendimiento que pueda reunir.

Entonces, abraza los nervios. Solo te están preparando para que rindas al máximo.

Entrevistar es una habilidad

Al final, entrevistar es una habilidad. Se necesita algo de estudio y mucha práctica para dominarlo.

Así que no se castigue si no se desempeña como hubiera esperado. Sigue aprendiendo y practicando, ¡lo conseguirás!

Si tiene alguna pregunta o comentario, no dude en comunicarse conmigo en Twitter, y si desea obtener más información sobre cómo prepararse para una carrera de desarrollo, escribo cosas como esta en mi blog.

¡Gracias por leer!

John