Contact Information

Theodore Lowe, Ap #867-859
Sit Rd, Azusa New York

We Are Available 24/ 7. Call Now.
robot
Primero, una advertencia, toma todos mis consejos con pinzas. Hay personas que tienen mucho más éxito que yo y que saben mucho más sobre este tema. Entonces, si encuentras que hay algún aspecto de mi consejo que parece totalmente incorrecto o que otros contradicen, establece tu propio criterio.

Lo he dividido en tres partes: obtener entrevistas, el proceso de la entrevista y negociar. Esta publicación cubrirá las dos primeras partes, y concluiré con muchos consejos sobre el proceso de negociación en una publicación posterior.

Cuando menciono “ingeniería”, simplemente sustitúyelo por tu propio campo. Aunque los detalles pueden ser diferentes, la dinámica subyacente es en gran medida la misma.

Espero que encuentres útil esta publicación en tu propia búsqueda de empleo.

Parte 1: búsqueda de empleo

  • Networking
  • Entrevistas informativas
  • Comenzando la cadena
  • CVs
  • Plataformas de trabajo
  • Solicitud masiva
  • Tamaño de la empresa
  • Estudiar, estudiar, estudiar
  • Estrategia general de estudio
  • Programando la Guía de estudio de la entrevista
  • Circuito de entrenamiento de entrevistas
  • Manteniendo el camino
  • Mentalidad
  • Tu número sigue divirtiéndote

Parte 2: El proceso de entrevista

  • Lo básico
  • Hablando de ti mismo
  • Cómo abordar un problema de entrevista
  • Corrigiendo a tu entrevistador
  • Escribir código
  • Heurística Variada
  • Emociónate

Parte 1: búsqueda de empleo

En primer lugar, la búsqueda de empleo es un juego de números. Debes tener fe en los números.

Si te dijera que tienes un 4% de posibilidades de obtener una oferta de cualquier aplicación, eso podría parecer desalentador. Pero matemáticamente eso significa que 50 de esas aplicaciones le darán un 87% de posibilidades de obtener al menos una oferta de trabajo.

Y, sin embargo, cualquier aplicación dada seguramente no será la que termine convirtiéndose en una oferta.

Esta bien. Espera esas dinámicas. Es raro y contradictorio, pero probablemente deberías esperar que la compañía que finalmente te ofrece una oferta parezca una posibilidad remota. Esto se debe a que casi todas las aplicaciones parecerán una posibilidad remota.

Siéntete cómodo con eso. Confía en la ley de grandes números.

Esto se aplica a las redes, las aplicaciones en bruto, incluso a las pantallas de los teléfonos y sitios web.

Networking

La creación de redes es probablemente la actividad de mayor apalancamiento para obtener ofertas de trabajo.

Las redes suenan intimidantes. Pero te prometo que, en el fondo, es bastante simple.

Solo invita a café a todos.

Y cuando digo a todos, me refiero a todos los que trabajan en una empresa de tecnología.

Cada vez que conoces a alguien en tecnología, y me refiero a cualquier persona, debes decirle: “Oye, eso es genial. Realmente estoy tratando de conseguir un trabajo como ingeniero de software. No sé mucho sobre [lo que haces]. Me encantaría invitarte a un café y hablar de ello. ¿Estás libre en algún momento de esta semana [hora]? ”

Invita a toneladas y toneladas de café a las personas. Hazlo religiosamente y no tengas vergüenza. No me importa si no te lo puedes permitir. Ve a la quiebra invitando a la gente a tomar un café.

De hecho, si te quedas en bancarrota, avísame y financiaré tus cafés hasta que consigas un trabajo increíble y puedas pagarme.

¿Cómo conoces a gente de tecnología en primer lugar? Ves a reuniones. Ir a eventos locales. Ir a las conferencias de desarrolladores. Ve a fiestas en casa. (Los técnicos son personas normales, y las personas están en todas partes).

Se creativo. @Mensajes en Twitter. Envíales un correo electrónico en frío (personas específicas, no empresas). No seas espeluznante, pero está totalmente bien contactar a la gente de la nada, aprender sobre ellos en línea y preguntar directamente si puedes invitarles a café.

Lo más importante, conecta tu red. Lo más probable es que tenga amigos o amigos de amigos que ya trabajan en empresas tecnológicas. Simplemente no estás prestando atención.

Bueno.

Así que ahora tienes un montón de citas de café alineadas con todas estas personas aleatorias que trabajan para empresas tecnológicas. Algunos de ellos pueden ser ingenieros o gerentes, operaciones, diseñadores, atención al cliente, vendedores. No importa: Conoce a cualquiera y a todos.

Una vez que te hayas sentado a alguien a tomar un café, es hora de una entrevista informativa.

Entrevistas informativas

Esto es lo que haces en una entrevista informativa.

Primero, aprende todo lo que puedas sobre esta persona. Aprende todo lo que puedas sobre su compañía. Aprende todo lo que puedas sobre la industria o la tecnología con la que trabajan.

Ten en cuenta que no he dicho “pide un trabajo”. No pidas trabajo. No se trata de que pidas un trabajo. Esto se trata de todo lo que no sea pedir un trabajo.

¡Conócelos! ¡Conoce su compañía! Obtén más información sobre lo que hacen y por qué es importante. Pregunta cosas que realmente quieras saber.

Debe estar hablando la mayor parte del tiempo, de lo contrario lo estás haciendo mal. Cállate y haz más preguntas.

Lo más probable es que si te callas el tiempo suficiente, tendrán curiosidad sobre ti y querrán saber lo que estás haciendo. Cuéntales tu historia. Cuéntales sobre quién eres, qué te ha traído aquí y por qué quieres un trabajo como ingeniero de software.

Al final de la conversación, ve por el cierre, que, la mayoría de las veces, no es pedir una referencia de trabajo. No solicites una referencia a menos que la mencionen. Por el contrario, pregúntales: “¿Con quién más sería una buena idea hablar?” Diles que deseas obtener más información sobre el desarrollo front-end, o la criptografía, o iOS, o lo que sea sobre lo que le hayas preguntado.

Le estabas haciendo preguntas, ¿verdad?

Si no pueden pensar en alguien con quien puedas hablar, pregúntales si conocen a algún otro ingeniero con el que puedas hablar. O cualquier persona que trabaje en otra compañía de tecnología que te interese. Sea lo que sea, obtén contactos para presentarte a más personas. Cada conversación debe conducir a al menos un contacto más.

Entonces, sigue esta cadena. Programa más citas de café, haz más preguntas, obtén más contactos. Todo sin pedir referencias no solicitadas.

Esto puede parecer raro. Pero los estudios han demostrado que esta es la forma más efectiva de conseguir un trabajo. Y, en última instancia, es la forma más efectiva de generar referencias fuera de tu red.

¿Por qué funciona esto?

Funciona porque la gente odia cuando les pides un trabajo.

¿Darte un trabajo? ¿Por qué? No te conocen. ¿Por qué te darían un trabajo? ¿Por qué perderían su tiempo contigo?

El poder de las entrevistas informativas es que en lugar de hacerlo sobre ti, lo haces sobre ellos. A la gente le gusta hablar de sí misma. Les gusta enseñar a otros. Ellos quieren ayudar pero no quieren ser molestados por extraños en busca de favores.

Si sigues haciendo esto, la gente verá tu curiosidad y tu autenticidad. Creerán en tu historia y querrán recomendarte. El no presionar a las personas para que te recomienden, hará que quieran hacerlo o, como mínimo, conseguirás un aliado en tu viaje.

La realidad es que la mayoría de la gente no puede derivarte. Esto se debe a que su compañía puede ser demasiado pequeña para contratar a desarrolladores junior, o puede que no necesiten personas con tu conjunto de habilidades, o pueden haber sido contratados por el trimestre, o, créelo o no, su compañía podría estar fallando en secreto y no tener dinero.

Esta bien.

Si hacex esto suficientes veces, alguien eventualmente planteará la idea: “Podría recomendarte si lo deseas”.

Si dicen esto, pregúntales amablemente si se sentirían cómodos haciéndolo. Entonces dirán que sí. Ahora di “caramba, eso sería genial”. Luego haz un seguimiento con ellos por correo electrónico, agradéceles y envíeles tu currículum. Felicidades, acabas de conseguir una referencia.

¿Ver? Eso no ha sido tan difícil.

Ahora mantenlos informados sobre tu progreso a través de la cartera de su empresa. No dudes en pedirles también más consejos.

Ah, y, antes de salir de esa cita de café, pídeles más contactos. Lo digo en serio. La cadena no se detiene para nadie.

Comenzando la cadena

¿Pero cómo comienzas la cadena?

Lo más probable es que ya tenga contactos en la industria tecnológica. Incluso si crees que no, probablemente los tengas. Busca en tu LinkedIn, Facebook, pregúntale a tu familia, habla con personas que conoces del instituto. Nada está fuera de los límites.

Haz una hoja de cálculo de cada persona que conozca que trabaje para una empresa de tecnología. Marca para qué compañía trabajan y cuál es su papel en esa compañía.

Luego ordena todos sus contactos por compañía y luego por rol. Debes comunicarte con tu contacto más relevante en todas las empresas de tu lista (un ingeniero es más relevante que alguien en operaciones, etc.).

Llega a todos y cada uno.

Invítalos a un café, almuerzo, cena, lo que sea. Siempre invita. Agrégalos para referencias y otros contactos. Si tiene una red sólida, es probable que esta sea la fuente más poderosa de clientes potenciales para ti.

Esto es genial, porque a menos que tengas un currículum estelar (lo cual supongo que no porque está molestando en leer esta guía), las referencias serán un orden de magnitud más impactante que las aplicaciones en bruto. Esto es especialmente cierto en las principales empresas.

Así que mantén tu embudo saludable. Sigue programando citas de café. Mantén la red, incluso si estás a mitad de camino en tu búsqueda de empleo. No dejes de reunirte con la gente hasta que tengas 4 ofertas, e incluso entonces sigue reuniéndote con gente de empresas que te interesen.

Currículums y carta de presentación

No voy a ofrecer muchos consejos específicos aquí, porque hay mucho que decir y es muy individual para tu experiencia y antecedentes. Busca recursos en Internet. Recomiendo que alguien revise tu currículum vitae y sepa lo que estás haciendo.

Ten una versión corta: mantenga su currículum en una página, siempre. Resalta cualquier cosa que suene un poco matemática o técnica. Mide todo en términos de impacto, no solo describas tus responsabilidades. Haz tu currículum bonito, especialmente si afirmas ser un desarrollador front-end o full-stack. No uses Arial o Times New Roman. Un poco de esfuerzo de diseño será de gran ayuda. Nunca, nunca tengas errores tipográficos.

Algunas personas leen cartas de presentación, otras no. Por lo general, debes escribir una y es probable que termines creando un script que adaptes. Personalízalos siempre; intenta encontrar algún motivo por el que te guste la misión de la empresa o por el que su trabajo sea interesante. Mantenlo corto y minimiza la “paja”. Si necesitaa más consejos, no hay escasez en Internet para los consejos de cartas de presentación.

Plataformas de trabajo

Regístrate en todas las plataformas de contratación de trabajo. Las primeras ofertas de trabajo que recibí fueron de TripleByte, que no puedo recomendar lo suficiente para los ingenieros de software.

También configura un perfil en AngelList, WhiteTruffle, SmartHires y todo lo demás. Aplica a la contratación. Limpia tus perfiles de LinkedIn y Github. Mantén tus proyectos y READMEs presentables.

Incluso si algunas de estas plataformas te rechazan o no recibes ninguna solicitud, representan un enorme retorno de la inversión por el tiempo que pasarás en ellas.

Solicitud masiva

Las referencias y las plataformas de trabajo son estrategias inequívocamente de mayor rendimiento, pero no debes ignorar las aplicaciones en bruto. Esto es especialmente cierto si tienes un currículum sólido, ya que es probable que tenga una tasa de respuesta más alta. Las aplicaciones sin procesar son de baja inversión, por lo que también puedes bombearlas en tu tiempo libre y maximizar el número de picaduras potenciales. También son la forma principal en que he visto a la mayoría de los estudiantes de App Academy conseguir trabajo, por lo que ciertamente funcionan. Pero requieren más volumen.

Recomiendo que la mayoría de las personas mezclen algo de aplicación masiva en su estrategia.

Debes comprometerte previamente con una serie de empresas para presentar su solicitud por día.

La aplicación masiva a las empresas es realmente aturdidora. Es fácil perder el foco. Así que estructura tu tiempo y establece metas para ti mismo. Aplica a lotes de empresas en sprints de 45 minutos. Usa Pomodoros para mantenerse enfocado y responsable.

Tamaño de la empresa

Según mis observaciones, es más probable que las pequeñas y medianas empresas se arriesguen con una aplicación sin procesar.

Las compañías grandes y prestigiosas tienden a tener procesos rígidos de revisión de currículums, y es más probable que destruyan tu currículum si no está repleto de frases emocionantes como “Stanford PhD” o “literalmente un superhéroe”.

Las pequeñas empresas son impredecibles.

Dispara a compañías poco atractivas. Es mucho más probable que obtengas una entrevista, y en esta etapa, lo que importa es tener experiencia en la entrevista.

Comprende: solo tener tu primera oferta es mucho más importante que el origen de la oferta. Incluso si la oferta es de una compañía que no te entusiasma, puedes aprovecharla fácilmente para una compañía que desees más. Hablaremos sobre esto más adelante cuando hablamos de negociación.

Estudiar, estudiar, estudiar

Esta es quizás la pieza más importante, y donde entra gran parte del ajetreo. Necesitas estudiar tu trasero. Sus hábitos de estudio son uno de los principales determinantes de tu desempeño en las entrevistas (sin mencionar su desempeño en tu trabajo posterior).

Estás tratando de entrar en este campo, ¡así que entra!

A continuación, voy a dar mi consejo general a alguien que busque un rol como desarrollador completo o back-end. Si deseas obtener un trabajo haciendo desarrollo front-end, desarrollo de juegos, sistemas integrados o cualquier cosa suficientemente especializada, debes buscar consejos más específicos para esos campos.

Esta es la preparación que usé personalmente. Mi enfoque para estudiar ha sido alimentado por mi conocimiento de la psicología del desempeño y por la ciencia del aprendizaje. Pero tu kilometraje puede variar.

Asumiré que ya sabes programar. Si no, lee esto como un primer paso.

También debes tener en cuenta que el siguiente consejo está especialmente diseñado para entrevistas en empresas más grandes y prestigiosas. En las empresas más pequeñas, es menos probable que tu entrevista consista en problemas de algoritmos abstractos. Puede que tengas que hacer ejercicios de codificación sin formato, corregir un error en el código de producción o construir un pequeño sistema semi-práctico. También es más probable que se te hagan preguntas sobre idiomas o marcos específicos. Me topé con algunas de estas entrevistas, pero solo en compañías más pequeñas. Ajusta tu plan de estudio en consecuencia.

Descargo de responsabilidad: un refrán común en tecnología es que “las entrevistas de programación están rotas”. Estoy de acuerdo. Creo que las entrevistas tecnológicas estándar son malos predictores de la capacidad de ingeniería de software. Pero como cualquier buen hacker, diseñé este consejo para que sea una ingeniería inversa de la entrevista de programación estándar. Tómalo como lo que es, y no más.

Estrategia de estudio general

Primero, una hoja de ruta de alto nivel.

Ve el curso de Princeton Coursera sobre algoritmos (por Robert Sedgewick), principalmente hasta el algoritmo de Dijkstra y no mucho más que eso. Intenta seguir y codificar a medida que avanzas. No necesita implementar cosas en Java a menos que ya conozca Java.

Lee el Manual de diseño de algoritmos para obtener información general sobre algoritmos generales y estructuras de datos. VEs a través de la mayor parte. (Puedes omitir el apéndice gigante sobre temas algorítmicos específicos).

Compra Cracking the Coding Interview. Usaremos esto como depósito de problemas y soluciones de codificación.

Escucha regularmente podcasts sobre software como Software Engineering Daily o The Bike Shed. Lee las noticias del pirata informático. Hay muchas cosas que no entenderás, pero está bien. Simplemente absórbelo. Con el tiempo, esto te dará cierta familiaridad con las pilas web modernas, las tendencias actuales y cómo hablan los desarrolladores.

Para el diseño y la arquitectura del sistema, recomiendo leer HiredInTech y leer un montón de las principales publicaciones de blog sobre Alta escalabilidad (parece estar inactivo en el momento de la publicación). También hay un repositorio masivo de recursos de Github que puedes consultar específicamente para entrevistas de diseño de sistemas.

Si ya conoces un lenguaje de programación, practica en el idioma que mejor conozcas. A los entrevistadores no les importará. Si tienes una opción entre los idiomas, elige los lenguajes de secuencias de comandos expresivos como Ruby, Python, JavaScript, etc. Hablaremos sobre esto más adelante cuando hablemos sobre consejos para entrevistas.

El diseño orientado a objetos y la organización del código son conceptos muy importantes, y aparecerán en entrevistas. Desafortunadamente, prácticamente no hay forma de aprenderlos más que simplemente escribiendo muchos programas bien estructurados y recibiendo críticas y revisiones de código.

Si no tienes experiencia en programación, este es uno de los lugares donde un campamento de codificación (bueno) ayuda enormemente. Te darán mucha experiencia simplemente escribiendo programas y siendo criticado por tu estilo de codificación. Pero siempre hay comunidades en línea donde puede encontrar sustitutos, como en Stack Exchange.

Si tienes dificultades para comprender un concepto en un libro o en Wikipedia, busca videos de Youtube de personas que lo expliquen de diferentes maneras hasta que lo obtenga. He encontrado esta estrategia increíblemente efectiva.

Pide ayuda a los seres humanos cuando estés luchando. Si no conoces a nadie, ingresa a StackOverflow o encuentre un buen canal de IRC para el idioma en el que estás trabajando. Se una carga para los demás. Pregunta rápidamente y sin vergüenza. Tienes mi permiso.

Si estás trabajando en un problema de algoritmos (como fuera de CTCI) y no puedes resolverlo, no pases más de 20-30 minutos sin progresar. Solo ve a buscar la respuesta. Contrariamente a la creencia popular, la mayoría de los últimos 30 minutos de lucha no tienen sentido.

Algunas personas no estarán de acuerdo con esto.

Al diablo con esas personas.

Dicho esto, si encuentras que tienes que buscar la respuesta a más de 2/3 de los problemas, su conjunto de problemas es demasiado difícil y necesitas degradarlo.

Pero golpearse la cabeza contra la pared o mirar fijamente el código es una pérdida de tiempo. Para problemas de código / algoritmos, desea maximizar la densidad de aprendizaje por hora.

Cada vez que busques la respuesta a un problema de codificación, intenta comprender la solución. Recórrelo con un depurador si es particularmente misterioso. Lee múltiples explicaciones de por qué funciona.

Luego, y esto es extremadamente importante, si no resolviste el problema completamente por tu cuenta, trátalo como si nunca lo hubiera resuelto. Vuelva a colocarlo en tu rotación de problemas. Márcalo como algo que necesitas intentar nuevamente desde cero. Espera al menos un día e intenta resolverlo fresco. Si falla, enjuaga y repite hasta el infinito.

Y finalmente, estructura el infierno de tu aprendizaje. Haz un horario. Tienes que saber exactamente cuándo vas a trabajar en estas cosas, cuándo tomarás descansos, cuándo irá a almorzar, etc. Incorpora flexibilidad a tu horario, pero ten metas claras para cuántas horas al día que pasarás estudiando.

Esa es la mayoría de mis consejos generales de estudio. Ahora aquí está la guía de estudio específica que recomendaría.

Entrevista de programación Guía de estudio

En primer lugar, trabaje a través del curso de algoritmos de Princeton. Debe seguir e implementar todo lo que pueda. En el camino, también implemente todas estas estructuras de datos principales. (Muchos de estos no están cubiertos explícitamente en el curso; impleméntelos usted mismo).

Lista enlazada

  • Matriz dinámica, implementada con un buffer de anillo (use una matriz de tamaño estático debajo del capó)
  • Conjunto de hash
  • Mapa de hash (con encadenamiento)
  • Montón binario (sin tecla de disminución; sepa que existen montones de Fibonacci y conozca sus garantías)
  • Árbol de búsqueda binaria (no es necesario que se equilibre automáticamente; sepa que existen árboles de equilibrio automático y conozca sus garantías)
  • Árbol de prefijos (también conocido como trie)
  • Árbol de sufijos (no se preocupe por la compresión, solo cree una versión tonta; sepa que el algoritmo de Ukkonen existe y conozca sus garantías)
  • Una lista de adyacencia orientada a objetos para gráficos

Conozca todas las complejidades del tiempo para sus operaciones básicas. Ayuda a intuirlos visualmente. Mira las imágenes. Dibujarlos en papel / pizarra.

Una vez que haya eliminado todos esos problemas, implemente este subconjunto de los algoritmos más comunes:

  • Búsqueda binaria (impleméntela tanto de forma iterativa como recursiva)
  • Selección rápida aleatoria (preste especial atención a la subrutina de partición, ya que es útil en muchos lugares)
  • Mergesort
  • Búsqueda de amplitud primero en un gráfico
  • Búsqueda de profundidad primero en un gráfico (aumentarlo para detectar ciclos)
    Recorridos de árboles (pre-orden, en orden, post-orden)
  • Clasificación topológica (utilizando el algoritmo de Tarjan)
  • Algoritmo de Dijkstra (sin tecla de disminución)
  • Subsecuencia común más larga (usando programación dinámica con matrices)
  • Problema de mochila (también programación dinámica)

Conoce las complejidades de tiempo y espacio de todos estos algoritmos (hoja de referencia). Conoce la diferencia entre las garantías de tiempo amortizadas, promedio y en el peor de los casos.

Haz al menos uno o dos problemas donde BFS o DFS a través de una matriz.

Una vez que termines estos, debes tener una buena base en algoritmos y estructuras de datos. Lee todo el Manual de diseño de algoritmos para solidificar su comprensión. Implementa cualquier cosa que encuentres suficientemente interesante.

Algunos puntos de interés: aprende sobre el tipo de montón, pero no te molestes en codificarlo. Tienes que saber que es un espacio O (1) pero prácticamente muy lento debido a la ineficiencia de caché. Aprende sobre selección rápida y mediana de medianas. Codifícalos si quieres.

Aprende los conceptos básicos de la manipulación de bits. Sé capaz de explicar qué hacen AND, OR y XOR. Sepa qué es un entero con signo. Sepa que hay 8 bits en un byte. Sepa qué ensamblaje es (desde un alto nivel) y tenga una idea de las operaciones básicas que expone el hardware.

Aprende sobre las bases de datos SQL. Aprenda a diseñar un esquema de base de datos SQL; aparece en entrevistas a menudo. Lea sobre ACID, el teorema de CAP y BASE (no necesita memorizar los términos, solo comprenda los conceptos a un alto nivel). Comprenda por qué las uniones pueden volverse inescrutables. Aprenda los conceptos básicos de las bases de datos NoSQL.

Lee sobre los cachés y la eficiencia del caché. Sepa lo que es una señorita de caché. Ten en cuenta que la lectura de registros es muy rápida, la lectura de varios cachés es bastante rápida, la lectura de la memoria es lenta y la lectura del disco duro es abismalmente lenta.

Lee cómo implementar un caché LRU y luego escribe uno que obtenga y establezca en el peor de los casos O (1). Este es un problema de entrevista extrañamente común.

Aprenda lo que sucede cuando escribe una URL en su navegador y presiona enter. Siéntete cómodo hablando de búsquedas de DNS, el ciclo de solicitud-respuesta, verbos HTTP, TCP vs UDP y cómo funcionan las cookies. Aparece todo el tiempo en entrevistas.

Aprende las formas estándar de acelerar un sitio web lento. Esto incluye muchas cosas, como agregar índices de base de datos para optimizar consultas comunes, mejor almacenamiento en caché, cargar activos front-end desde un CDN, limpiar oyentes de zombies, etc. También una entrevista clásica, bastante aburrida.

(Estos dos últimos son obviamente específicos del desarrollo web).

Una vez que los hayas cubierto, ahora tienes la mayor parte de la base que necesita. Debería estar listo para comenzar el entrenamiento del circuito de entrevistas.

(Si ya tienes experiencia en CS, probablemente comiences aquí).

Circuito de entrenamiento para entrevistas

Primero, trabaja con los primeros 3 problemas en cada sección relevante de Cracking the Coding Interview. (Es decir, omite secciones como Java o C ++ si no conoces esos idiomas, omite las pruebas, omite la concurrencia a menos que tengas experiencia escribiendo programas concurrentes. Sin embargo, lee sobre ello).

Escribe tus soluciones en código. Asegúrate de que funcionen. Verifica los casos de borde.

Después de haber escrito más de 30 soluciones, deja de codificar cada solución. A estas alturas debería tener una práctica sólida de codificación, y deberías estar desarrollando su intuición de alto nivel sobre cómo determinar el enfoque óptimo para un problema. El resto es reconocimiento de patrones.

Continúa trabajando durante el resto de la entrevista de Cracking the Coding. Pero a partir de ahora, en lugar de escribir código, simplemente escribe una descripción de alto nivel del algoritmo que usarías para resolver el problema.

Aquí hay un ejemplo de lo que quiero decir: “Primero ordena la matriz, luego haz una búsqueda binaria repetidamente a través de ella en cada consulta posterior. Esto debería tomar nlog (n) preprocesamiento y log (n) para cada consulta “.

Eso es suficiente detalle. Una vez que hayas escrito tu solución de alto nivel, compárela con la solución del libro. Si su solución es subóptima, escriba una descripción de la solución óptima. Asegúrate de que tenga sentido para ti. Si incluso no tiene sentido y no estás seguro de poder escribir el código, codifícalo, prueba los casos extremos, etc.

Con este flujo de trabajo, debes codificar solo un pequeño porcentaje de los problemas restantes. Ahora deberías poder resolver muchos más problemas al día.

Asegúrate de tener tus soluciones recopiladas en archivos para poder revisarlas fácilmente. En tus archivos de soluciones, también debes tener la declaración del problema junto con cualquier solución que hayas escrito / descrito.

Siempre que los revises (lo que debe hacer a intervalos semanales), así es como debes revisar: lee solo la declaración del problema, decide cómo resolverías el problema en tu cabeza y luego compárelo con el algoritmo que ha escrito. Nuevamente, reafirma en ti mismo por qué la respuesta correcta es correcta.

Una vez que hayas leído todo el libro, pasa el resto de su tiempo de estudio resolviendo problemas en LeetCode.

LeetCode es una plataforma de codificación en línea como HackerRank o CodeWars que te brinda una declaración del problema y te permite escribir código en casos de prueba.

Recomiendo LeetCode particularmente porque tiene el conjunto de problemas más preciso que he visto para la mayoría de las entrevistas de algoritmos. También tiene una característica impresionante que etiqueta los problemas de programación de las compañías donde se les preguntó el problema. (Si la empresa tiene menos de 2000 empleados, es poco probable que se etiquete en cualquier lugar).

Por lo tanto, cada vez que tengas una entrevista en una gran empresa, resuelve todos los problemas con los que se etiqueta esa empresa en LeetCode. Tienes que pagar una suscripción para ver las etiquetas, pero vale la pena.

GlassDoor también es una buena fuente de problemas específicos de la empresa para resolver. (También puedes probar CareerCup, pero su precisión tiende a ser un poco más dudosa).

Después de todo eso, falta una última pieza: la práctica real de la entrevista. Uno de los principios principales del aprendizaje es la práctica como el desempeño. Es decir, haga que la forma en que practica sea lo más cercana posible al rendimiento real. En este caso, el rendimiento real será pararte frente a una pizarra y ser entrevistado verbalmente por alguien.

Practica para ello.

Encuentra a alguien para simular una entrevista con usted frente a una pizarra (y corresponda con ellos después). Haz que te hagan preguntas que nunca has visto antes. Practica todas tus habilidades de entrevista, incluyendo presentarte, aclarar el problema, hacer bromas, todo lo que planeas hacer en una entrevista real. Trátalo como si fuera real. Debes estar dispuesto a luchar y parecer estúpido. No te permitas romper el carácter.

Esta también es realmente la única forma de practicar entrevistas orientadas a la arquitectura. Haz que tu entrevistador te pregunte sobre el ciclo de solicitud-respuesta o cómo diseñaría Twitter u otros favoritos estándar de entrevistas.

Un gran recurso es entrevistas.io, que te permite entrevistar anónimamente y ser entrevistado por otras personas y practicar problemas de programación. Están en beta privada en este momento, pero échales un vistazo.

Si realmente implementas cada parte de este flujo de trabajo, deberías convertirse en una bestia de algoritmos en unos pocos meses. Tu desempeño en una entrevista de codificación será comparable, si no superior, al graduado promedio de CS.

No hay nada mágico en nada de esto. Todo es solo práctica. Toda la información que necesita para pasar una entrevista de codificación está disponible gratuitamente. Depende de ti dedicarle tiempo.

Bueno.

Ahora eres claramente asombroso con los algoritmos, así que sigamos adelante.

Manteniendo el camino

La búsqueda de empleo es difícil. Una vez que comiences a postularte para las empresas, obtendrás muchos, muchos rechazos.

Luchar durante meses y ser rechazado en todas partes es profundamente desmoralizador.

Te sentirás como si fuera tu culpa. Sentirás que algo está mal contigo.

Así es exactamente como comenzó mi búsqueda de empleo. Lo mismo es cierto para muchas personas que conozco que obtuvieron trabajos increíbles. Casi todos pasan por esto.

Hay un par de historias que me gustaría compartir.

Una vez trabajé con un estudiante de App Academy que no tenía un título; había abandonado la universidad. Estuvo buscando trabajo durante 11 meses y había presentado cientos de solicitudes. Estaba listo para renunciar por completo a encontrar un trabajo. Pero con un poco de apoyo y entrenamiento, pudo obtener su primera oferta en una startup. Después de algunas negociaciones, esa oferta terminó siendo la segunda oferta más alta que un estudiante haya recibido en la historia de App Academy.

Otro estudiante con el que trabajé tenía una historia similar. 11 meses de nada más que rechazos después de cientos de aplicaciones. Después de obtener algo de apoyo, finalmente recibió su primera y única oferta, y fue de Uber. Él todavía está trabajando allí.

La moraleja de esta historia es: aguanta. Sigue trabajando. Recuerda que es un juego de números. Sigue exponiéndote, y lo más importante, cuídate.

Las cosas simples son importantes. Sonará estúpido, pero enfócate en el cuidado personal antes que nada en la búsqueda de empleo.

Haz cosas que te desestresen, ya sea meditación, tomar baños, jugar videojuegos, lo que sea. Pasa tiempo con los amigos. Come bien, comida de verdad.

Asegúrate de estar durmiendo. La hora marginal que pasas durmiendo es casi siempre más útil que la hora marginal que pasas trabajando.

Haz ejercicio regularmente, incluso si no lo deseas y odias todo lo relacionado con él. Innumerables estudios han demostrado que el ejercicio es básicamente una panacea. Aumenta el bienestar personal más que cualquier otra intervención psicológica, incluidos los antidepresivos.

La depresión se arrastrará sobre ti.

Si es así, observa que está allí. Habla con la gente al respecto. No te avergüences. Lucha activamente. El ejercicio y la vitamina D son tus aliados. Pase tiempo afuera, al sol. Consulta a un profesional si lo necesitas.

Pero tu mejor defensa es estructurar tu tiempo. Convéncete religiosamente. Tienes que saber lo que debes estar haciendo todos los días.

En muchos sentidos, la libertad es tu enemigo. Deja que la estructura sea tu refugio.

Mentalidad

Solía trabajar como entrenador mental para jugadores profesionales de póker, así como para otras personas en profesiones de alto riesgo. Gran parte de ese trabajo ha informado mi enfoque para la búsqueda de empleo.

Aquí está mi consejo sobre mentalidad.

En primer lugar, trata todo como una experiencia de aprendizaje. Con eso quiero decir, nunca entres en la pantalla de un teléfono o en una entrevista en el sitio esperando un trabajo. No esperes nada en absoluto. Simplemente ves allí para aprender, para equivocarte, para probar cosas y ver de qué se trata toda esta entrevista.

Casi diría: imagina que alguien más fue invitado a esta entrevista, y tu eres simplemente su doble. Puedes ser una mosca en la pared, probar cosas, pero realmente no te importa si lo contratan o no. Simplemente lo estás haciendo porque es interesante. ¿Y por qué no tener más experiencia entrevistando?

Trata cada entrevista así. Deja de preocuparte por el resultado. No esperes que te contraten, solo entra y aprende.

Este enfoque tendrá efectos tremendamente beneficiosos para ti como candidato. No estarás tan nervioso o aterrorizado. Estarás menos apegado al resultado y no serás aplastado si no consigues el trabajo. (Casi nunca un candidato pasa sus primeras dos entrevistas, por lo que deberías esperar eso de todos modos). Y hace que todo el proceso sea más divertido y más fácil de aprender.

El segundo gran consejo es: establece metas continuamente para ti mismo. Pero solo establece metas que estén completamente bajo tu control.

Por ejemplo, una meta como “Quiero tener una oferta de trabajo antes del 20 de enero” es una meta terrible. No depende de ti. ¿Cómo podrías saber si estás progresando hacia esto? Tendrás un trabajo antes o no lo harás.

En cambio, elige objetivos sobre su propio comportamiento. Una meta como “Quiero postularme a 4 trabajos cada día de la semana” o “Quiero pedirle a 4 personas citas de café cada semana” están bajo tu control y son fáciles de medir.

El tercer y último consejo es sobre cómo enmarcar tu búsqueda de empleo. Aquí hay una pequeña parábola que solía contarles a mis alumnos.

Tu número

Imagina que en algún lugar, en la base de datos de Dios, hay un número. Ese número es el número de días que tendrás que trabajar hasta que encuentre un trabajo.

Todos tienen su propio número en la base de datos de Dios. Incluso tú.

Llamemos a tu número N.

Cada día que pasas seriamente buscando trabajo, disminuye N por 1. Por supuesto, no sabes cuál es esa N. Y nunca sabrás qué es N hasta que finalmente obtengas su primera oferta. (Supón que Dios desinfecta sus entradas contra las inyecciones de SQL).

No puedes elegir su N. Muchas cosas afectan el tamaño de su N: tu experiencia, tu educación, tu red, los sesgos sistémicos en la industria y algo de aleatoriedad. Una carga de aleatoriedad, en realidad.

Otras personas tendrán Ns más pequeñas que tú, aunque no sean tan hábiles como tú. Esta bien.

Ignora a otras personas. Lo tienen más fácil, y eso está bien. Pero tu N ya está decidida, y tu único trabajo es reducirla.

Así que trata todos los días como un progreso. Ya sea que te rechacen de una empresa, si arruinas una entrevista, si obtienes una inexplicablemente baja, no importa. Esa N se está volviendo cada vez más baja, y sus habilidades de entrevista son cada vez mejores. Tener confianza. Te estás acercando.

Cada día es progreso.

Y por último…

Sigue divirtiéndote

Esto es realmente importante

Sigue haciendo cosas. Sigue trabajando en proyectos. Encuentra cosas que te emocionen. Aprende nuevas tecnologías, marcos, algoritmos, idiomas. Cuando alguien te pregunta “¿en qué estás trabajando últimamente?” deberías tener una buena respuesta, una que te entusiasme.

Trabaja en cosas que son realmente divertidas. Te mantendrá fuerte, motivado y feliz.

Estás entrando en esta industria porque quieres programar, ¿verdad?

¡Así que sigue programando!

Parte 2: El proceso de entrevista

Bueno. Hiciste toda la parte 1 y tienes entrevistas alineadas. Excelente. ¿Ahora que?

Voy a reiterar esto nuevamente: aborda cada entrevista como una experiencia de aprendizaje. Deja de preocuparte si conseguirás el trabajo o no. Las primeras veces, casi seguro que bombardearás. Está bien. Espera eso y progresa con ello.

Las entrevistas son una habilidad, y no particularmente misteriosa. Confía en que cuantas más veces lo hagas y más deliberadamente analices tus errores, mejor lo harás.

No te preocupes por conseguir un trabajo. Es probable que cada entrevista no sea la que lleve a un trabajo. Esta bien. Solo aprende y diviértete. Tendrás mucho mejor rendimiento de esa manera.

Lo básico

Entonces tu entrevista se acerca.

Si no está seguro acerca de algo en particular, puedes preguntarle a tu reclutador o punto de contacto en la empresa. Puedes preguntarles cosas como: ¿Qué tipo de problemas habrá en la entrevista? ¿Algo específico que deba revisar? ¿Puedo usar Python? ¿Habrá algún par de programación? ¿Debo traer mi propio ordenador portátil para codificar? ¿Podré buscar documentación en Google durante la entrevista?

Todas estas son preguntas totalmente buenas. A nadie le importará en absoluto si lo preguntas. He visto a muchas personas agonizar por preguntas como estas. Solo pregunta.

Algunos conceptos básicos:

En una startup tecnológica en la Bahía, vístete bien, pero informal. Algo como un suéter y jeans funciona bien. En mercados más conservadores, usa una camisa de vestir y pantalones. Si no estás seguro, pregúntale a tu reclutador. Esta no es una pregunta tabú.

A menudo te ofrecen algo de beber. Tómalo si lo quieres. Usa su baño. Haz lo que puedas para relajarte.

Cuando te encuentres con tu entrevistador, saluda, preséntate. Relájate. Intenta recordar su nombre. (No es un gran problema si no lo haces)

Siempre hay algún ritual para comenzar una entrevista. No es demasiado complicado.

Tu entrevistador entrará en la sala. Sonríe. Dile tu nombre. Dale la mano con confianza. Míralo a los ojos.

Adopta un lenguaje corporal relajado. Recuéstate en tu silla. Intenta no estar inquieto, solo junta tus manos si no puedes evitarlo.

Estás completamente bien. Esta entrevista es solo para practicar de todos modos. No te analices a ti mismo. No, no es extraño que tus brazos cuelguen así.

Pregúntele a su entrevistador en qué equipo está y en qué ha estado trabajando últimamente. Esto hará que la conversación fluya.

Si estás nervioso, está bien decirles eso. Si estás ansioso por comenzar, también está bien decirles eso.

Hablando de ti mismo

Cuando se trata de hablar sobre ti, la mayoría de las entrevistas tecnológicas son increíblemente formulales.

Casi todas las preguntas que se te harán serán una permutación de uno de estos cuatro:

¿Cuál es tu historia / guíame por tu currículum / por qué dejaste tu último trabajo? (estas son esencialmente la misma pregunta)
¿Porque nosotros?
Háblame sobre un error desafiante que enfrentó y cómo lo resolvió.
Cuéntame sobre un proyecto interesante en el que hayas trabajado.

La primera pregunta es particularmente importante. Esencialmente, quieren escuchar tu narrativa personal. Tu respuesta influirá fuertemente en su percepción de ti.

Esto realmente se reduce a contar historias. Considérate un personaje en una historia y estructura la historia con un principio, un medio y un final. Debe haber puntos de inflexión, caracterización y motivaciones fáciles de entender. Hazlo lo más corto posible, mientras conservas el color y lo que lo hace interesante. Intenta no ser negativo. Enmarca tu historia en busca de desafíos y ganas de mejorarte a ti mismo, en lugar de rechazar o disgustar las cosas.

Contarás esta narración una y otra vez. Si entrevistas lo suficiente, eventualmente se convertirá en un guión. La mejor manera de mejorarlo es, literalmente, practicarlo en voz alta y escuchar una grabación. También trata de obtener feedback de alguien en cuyo juicio confíes, y pídele que sea lo más cruel posible.

Para las tres preguntas restantes, debería tener respuestas prefabricadas. Si no tiene suficientes historias, puede ser útil sentarse y hacer una lluvia de ideas sobre cada historia relevante que puedas recordar (por ejemplo, cada error que recuerdes haber trabajado), y luego reducirla de una lista más grande.

Es difícil practicar esto de manera efectiva en el vacío, por lo que es bueno trabajar con alguien más.

Una vez que hayas respondido todas las preguntas suaves de tu entrevistador, es posible que te pregunten si tienes preguntas para ellos. Diles que guardarás tus preguntas hasta el final de la entrevista. Esto te dará más tiempo para la parte de programación real, que es la mayoría de los lugares donde será evaluado.

Ahora veamos consejos para la entrevista de programación real. Esto va a ser muy específico de la pizarra, pero gran parte de los consejos se aplican también a la codificación en una máquina.

Cómo abordar un problema de entrevista

Antes de responder cualquier pregunta (no trivial), siempre, siempre, repite siempre la pregunta con tus propias palabras. Asegúrate de entender exactamente lo que están preguntando.

Espera que el 10% de las veces, no entiendas lo que realmente están preguntando. Si ese es el caso, cuando repitas la pregunta, se aclararán las dudas. Pero si no lo entiendes y saltas directamente a trabajar en el problema equivocado, no te corregirán.

Esto se debe a que si comienzas a hacer cosas que no tienen sentido, tu entrevistador generalmente solo va a asumir que eres incompetente.

Esto está bien. Tu entrevistador tiene un trabajo difícil, porque la mayoría de las personas son incompetentes, y es su trabajo entrevistar a personas incompetentes.

Por lo tanto, si ven que inicialmente haces algo estúpido, no asumirán caritativamente que eres una persona inteligente que simplemente está teniendo un mal día. Esta bien; gradualmente ganará credibilidad en el transcurso de la entrevista. Pero es importante tener en cuenta esta dinámica inicial.

Por lo tanto, debes ser lo más explícito posible en toda tu comunicación. Explica las cosas con detalles nauseabundos. Esto eliminará cualquier posible falta de comunicación entre tu y tu entrevistador, y también los convencerá rápidamente de que no eres incompetente. Esto es sorprendentemente importante.

Bien, sigamos adelante.

Para cualquier pregunta no trivial, casi siempre comienzo trabajando con un ejemplo de tamaño pequeño a mediano en la pizarra. Esto nuevamente confirma que entiendo el problema y desarrolla mi intuición sobre cómo resolverlo. También vale la pena incluir algunos casos extremos aquí para darte una idea de por qué el problema es complicado.

Nunca saltes directamente a la codificación. Incluso si crees que sabes la respuesta, no saltes directamente a la codificación. Primero, explica tu enfoque en abstracto. Si hay problemas con tu enfoque, su entrevistador a menudo los señalará aquí; al saltar directamente, es más probable que tu entrevistador te permita ahorcarte.

Una vez que comiences a resolver el problema mentalmente, trata de seguir hablando. No dejes de mover la boca. Haz todo lo posible para que el entrevistador sepa todo lo que está pensando en todo momento. No importa cuán pequeño, estúpido o incierto sea el paso que estás dando en tu cabeza, solo dilo en voz alta. Si necesita tiempo para pensar, diga “deme un momento para pensar en esto”. Luego, cuenta los resultados de su pensamiento, incluso si fue infructuoso.

Las entrevistas de ingeniería son tanto sobre comunicación y proceso de pensamiento como sobre resultados. Absolutamente puedes pasar una entrevista solo por comunicación, incluso si no obtienes la respuesta óptima.

Mira a tu entrevistador. Comprométete con ellos. Hazles preguntas. Haz una broma. No pidas ayuda, nunca. Y no te rindas.

Nunca, nunca te rindas. Mientras no se rindan contigo, no te rindas contigo mismo. Sigue presionando, probando cosas diferentes, y si no puedes pensar en ningún lugar productivo para ir, simplemente explica por qué todo lo que se te ocurre no funcionaría.

Obtendrás más ayuda, más libertad de acción y más empatía de su entrevistador si sigues este consejo.

Si una solución eficiente no te llama la atención de inmediato, continúa y describe la solución de la fuerza bruta al problema. Casi siempre obtendrás crédito por algo si al menos enumera una solución correcta pero ineficiente. No tienes que codificarlo necesariamente (depende si se lo piden). Por lo general, es suficiente para describir cómo funciona. Luego diga: “Entonces eso resuelve el problema en tiempo exponencial. Pero definitivamente no es óptimo. Déjame ver si puedo encontrar un enfoque más eficiente “. Esto también lo ayudará a lidiar con el problema y puede darle una idea de cómo resolverlo de manera eficiente.

Una buena heurística para encontrar una solución de fuerza bruta es preguntarse: ¿cuál es el algoritmo que utiliza mi cerebro para tratar de resolver este problema si quisiera resolverlo a mano?

No tengas miedo de parecer estúpido. Está bien estar equivocado. Está bien hacer preguntas si no sabes lo que significa algo. Tómelo con calma y ríase al respecto. En casi todas las entrevistas en las que recibí una oferta, fallé al menos una pregunta. No dejes que te moleste.

Dicho esto, si crees que sabes lo que significa algo pero no estás 100% seguro, confía en tu intuición. Por lo general, tendrás razón. Si no la tienes, está bien que te corrijan.

Corrigiendo a tu entrevistador

A veces puedes pensar que su entrevistador está equivocado sobre algo.

Su entrevistador definitivamente a veces se equivocará. Pero es mucho, mucho, mucho más probable que seas el que se equivoca. Piénsalo: estás estresado y codificando tu vida, mientras tu entrevistador está sentado en una silla y observa a la centésima persona este año luchar para resolver su problema favorito de mascotas.

Por defecto,  asume que estás equivocado. Nunca te pongas a la defensiva. Averigua por qué te equivocas. Si de hecho tienes razón, deberías poder probarlo metódicamente.

De acuerdo, entonces has hablado todo hasta la muerte, ahora estás listo para escribir el código. Primero, di: “¿Quieres que codifique esto?”

Si su entrevistador tiene dudas finales sobre tu enfoque, esto le da la oportunidad de detenerlo. A veces también pueden detenerte si tu algoritmo es aceptable, pero quieren que encuentres un enfoque más óptimo.

Pero por lo general dirán que sí. Entonces, comencemos a escribir código.

Escribir código

Es una broma. Aún no estás listo para codificar.

Antes de escribir algo, primero verifica verbalmente tus suposiciones sobre la entrada. ¿Puedo suponer que nunca recibo entradas negativas? ¿Puedo suponer que todos estos son enteros de 64 bits? ¿Puedo suponer que todo en esta cadena de entrada está codificado en ASCII? ¿Puedo suponer que mi entrada es un mapa hash, formateado así? ¿Debo generar un error para una entrada no válida? ¿Cómo debería comportarse esta función si la entrada es flotante?

Algunas veces, tu entrevistador estará satisfecho con esta atención al detalle y te permitirá agitar manualmente algunos errores en el manejo de entradas no válidas. Pero si no lo mencionas en absoluto, más tarde podrían preguntarle “ah, pero ¿qué pasa si obtiene un número entero negativo?” Luego tendrás que borrar algo y apretar una línea para el manejo de errores y perder más tiempo.

Ya casi estás listo para codificar. Anuncia el idioma en el que vas a escribir esto. Debería preferir un lenguaje de tipo dinámico con una biblioteca estándar rica como Ruby o Python. Elegir un lenguaje como Java o C ++ solo te  perjudicará en cuánto tiempo se tarda en expresar el mismo algoritmo. No se te calificará por lo duro que seas como programador, solo si resolviste el problema en el tiempo asignado.

Ahora también es el momento de mencionar si hay alguna estructura de datos o biblioteca especial que necesites. Es totalmente genial decir “¿Puedo suponer que tengo un árbol de prefijos?” incluso si no conoces una biblioteca de árbol de prefijos en tu lenguaje. Está bien declarar la API sobre la marcha: “Voy a suponer que este montón tiene un método .pop_min”.

Y ahora es tiempo de codificar.

Comienza en la esquina superior izquierda del tablero. La gestión de la junta es sorprendentemente importante en las entrevistas de pizarra. Borra las cosas que están en su camino y deja el mayor espacio posible para el código.

Más consejos de administración de la junta: no cierres los bloques (ya sean llaves o bloques) hasta que llegues a ellos. Cerrarlos pronto hará que las cosas se vuelvan desordenadas si luego tiene que introducir líneas de código inesperadas o borrar muchas veces.

Como hábito general, agregue mucho espacio en blanco alrededor de las líneas. Es muy, muy común tener que agregar líneas adicionales en algún lugar de una función. Cuanto más espacio para respirar salga, más fácil será.

Si no recuerdas el nombre exacto de un método, a su entrevistador no le importará la mayor parte del tiempo. No te estreses por eso. Simplemente invente un nombre lo suficientemente cercano para ello. Si preguntan qué haces, simplemente di: “Podría estar equivocado sobre el nombre aquí, pero este método crea una versión invertida de un mapa hash para que los valores únicos ahora apunten a sus claves”. La mayoría de los entrevistadores estarán satisfechos con eso.

Nombra tus variables descriptivamente, pero mantenlas cortas. Va a ser malo escribir nombres largos de variables repetidamente sin autocompletar.

Mientras escribes, resume tanta lógica como puedas en las funciones de ayuda. Esta es una optimización de pizarra tremendamente útil.

Simplemente invoca las funciones de ayuda sobre la marcha y no sientas la necesidad de escribir sus declaraciones de inmediato. Simplemente di: “Escribiré esta función después, pero esto solo devuelve una tabla hash que asigna cada carácter de la cadena a su frecuencia”.

Continúa y sigue trabajando en tu función principal, y luego preocúpate por los ayudantes. Esto lo mantendrá en tu flujo y hará que sea más fácil leer y razonar sobre tu código.

Después de terminar y establecer las características de la lógica de tu función principal, a menudo su entrevistador confiará en que tú puedes escribir algunos de los ayudantes y no querrá verlos codificarlos.

Simplemente di: “así que esta función auxiliar lo hace [bla, bla, bla]. ¿Quieres que escriba esto también? Si dicen que sí, continúe y escribe todas sus funciones de ayuda. Pero esto al menos les da la oportunidad de decir que no. Esta optimización por sí sola terminó ahorrándome mucho tiempo en mis entrevistas.

Finalmente, una vez que hayas terminado todo el código, revisa todo. Simplemente di “está bien, déjenme revisar esto ahora”. Lee tu código de arriba a abajo y asegúrate de que tenga sentido. Síguelo como si tuvieras un depurador, realmente rastreando la ruta y las transformaciones de una entrada. Arregla cualquier error obvio. Luego comienza a inspeccionar los casos extremos.

Casos límite más comunes: la entrada es nula / vacía, la entrada es 0 o tamaño 0, la entrada es 1 o tamaño 1, o la entrada contiene duplicados. Intenta descubrir las suposiciones que estás haciendo y valora cómo podrían violarse.

Una vez que estés satisfecho de que tu solución tiene en cuenta los casos límite, entonces y solo entonces recurre a su entrevistador y anuncia “Creo que esto resuelve el problema”. Deja en claro que crees que has terminado.

Ahora adelante y analiza el algoritmo. Anuncia la complejidad temporal y la complejidad espacial de tu solución. Habla acerca de cualquier compensación que puedas hacer. “Si quisiera tomar el tiempo O (n ^ 3), podría simplemente memorizar todas las respuestas y devolverlas en el tiempo O (1) para consultas posteriores. Pero eso tiene un gran costo inicial de tiempo y espacio “.

Heurística Variada

Esto es un poco tonto, pero pensé en incluirlo porque la gente parece encontrarlo útil.

Si estás en blanco durante una entrevista, prueba estas reglas generales, más o menos en orden de utilidad:

  1. Prueba los mapas hash.
  2. Si tu problema se descompone fundamentalmente en la búsqueda de algo, considere la búsqueda binaria.
  3. Intenta ordenar tu entrada.
  4. ¿Puedes dividir el problema en subproblemas? ¿Resolver el problema para el tamaño (N – 1) hace que resolverlo para el tamaño N sea más fácil? Si es así, intenta resolver de forma recursiva y / o con programación dinámica.
  5. Si tienes muchas cadenas, intente ponerlas en un árbol de prefijos.
  6. Siempre que tengas que tomar el mínimo o el máximo de una colección dinámica, piensa en montones. (Si no necesita insertar elementos aleatorios, prefiera una matriz ordenada).

Bien, entonces la entrevista finalmente terminó. Ahora es el momento de hacerle preguntas a su entrevistador. Esta parte también es sorprendentemente importante.

Asa a tus entrevistadores

Un tropo común que la gente arroja es “los estás entrevistando tanto como ellos a ti”. Yo digo que si eso es cierto, entonces pónlos a prueba.

Pregúntales por qué decidieron unirse a la empresa. Pregúntales en qué creen que la compañía podría mejorar. Pregúntales sobre el momento en que se equivocaron y cómo se manejó. Pregúntales cómo se ven crecer en esta empresa en los próximos años. Pregúntales qué desearían que alguien les hubiera dicho antes de unirse. Pregúntales si alguna vez piensan en irse, y si se irían, a dónde irían.

Para ser claros, estas no son necesariamente preguntas sobre la empresa. Son preguntas sobre su entrevistador.

Abogo por interrogar a su entrevistador por algunas razones:

Es probable que su entrevistador sea representativo de las personas con las que trabajará si se une. Debería aprender lo más posible sobre el tipo de personas que trabajan aquí.
Le dará mucha más información sobre la compañía que cualquier pregunta genérica.
Te da un poco de impulso en la entrevista. En lugar de estar constantemente a la defensiva, al hacer preguntas difíciles, tienes tiempo para respirar mientras el entrevistador reacciona a sus preguntas.
¡También es más interesante!
Dicho esto, es probable que tengas algunas preguntas candentes que realmente quieras hacerle a tu entrevistador específico, como “¿Cómo te metiste en la ingeniería de datos?” o “¿Cuál es su opinión sobre la transición de la empresa hacia una arquitectura orientada al servicio?”

Eso me lleva a mi segundo consejo cuando se trata de interrogar a los entrevistadores.

La mayoría de las veces no tendrás preguntas rápidas y específicas para hacer. Entonces memoriza un conjunto de preguntas y hazlas una y otra vez. No solo para diferentes compañías, literalmente, pregunta a los sucesivos entrevistadores de la misma compañía exactamente lo mismo.

¿Por qué?

Porque, por un lado, los entrevistadores generalmente solicitan preguntas al final de una entrevista. Para entonces, hay una buena posibilidad de que estés psicológicamente agotado y no tengas ganas de hacer preguntas novedosas e incisivas.

(Nunca, nunca, nunca digas “No tengo preguntas”. ¡Interesado!)

Segundo, los entrevistadores no comparan notas sobre las preguntas que les hizo un candidato. Entonces, si tienes un buen conjunto de preguntas, nadie en la compañía sabrá que hiciste las mismas preguntas.

Tercero, incluso si lo hicieran, no les importaría. Las buenas preguntas siguen siendo buenas y vale la pena escuchar las respuestas de diferentes personas a la misma buena pregunta. He aprendido mucho sobre la dinámica de diferentes compañías de esta manera.

Emociónate

Este es el punto final, y se aplica a todo el proceso de la entrevista.

Tienes que estar entusiasmado con la empresa. Es trivial, pero hace una gran diferencia. Tienes que estar emocionado de entrevistar. Estar emocionado de saber qué hace tu entrevistador y la posibilidad de trabajar con ellos. Diles cuánto te gustan las personas que conoció y que te gusta la cultura de la empresa.

Las entrevistas son sorprendentemente como citas. Es más probable que tu entrevistador está desproporcionadamente entusiasmado contigo si tu estás entusiasmado con ellos. Esa positividad hará que quieran trabajar contigo e incluso ir a por ti cuando llegue el momento de la decisión.

No solo eso, sino que la emoción es una señal de que realmente quieres hacer el trabajo para el que te están contratando, y de que vas a esforzarte para hacerlo bien. Si el rendimiento de tu entrevista estuvo cerca del límite, tu entusiasmo puede terminar empujándolo hacia la línea de meta.

Probablemente te entrevistarás en diferentes compañías, pero siempre debes hablar sobre lo que hace que esta compañía sea única y cautivadora. Si no estás seguro, pregúntales a tus entrevistadores: ¿qué les hace amar trabajar aquí? Luego puedes reflejar esa respuesta.

Al mismo tiempo, no quieres parecer desesperado. Me gusta usar la frase “buscando un buen ajuste mutuo”. Deseas ser discriminatorio, pero también quieres parecer ganador si te hacen la oferta correcta. Si pareces completamente desinteresado en la empresa, probablemente no querrán hacerte una oferta incluso si pasas su límite técnico.

Las empresas varían significativamente en la cultura. Pero mucha “cultura adaptada” realmente se reduce a una simple pregunta: ¿realmente querrían tus entrevistadores ser tus colegas?

Es mucho más fácil para ellos decir que sí si suenas emocionado. Así que hazlo fácil para ellos.

Share:

administrator

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *