Cómo obtuve ofertas de Microsoft, Amazon y Twitter sin un título de Ivy League
Esto es para aquellos de ustedes que están a punto de comenzar su búsqueda de trabajo y que pueden estar preocupados de que no puedan obtener un trabajo de tecnología de primer nivel sin un título de Stanford CS. Alguien te dijo que no eres lo suficientemente bueno para conseguir un trabajo en Microsoft o Facebook. Pero estoy aquí para decirte que puedes conseguir ese trabajo. Así es como lo hice, y conseguí el trabajo de mis sueños en Twitter.
Qué cubre este artículo:
Mi pasado
Cómo conseguí entrevistas con las principales compañías tecnológicas del mundo: Facebook, Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat y otras.
Cómo conseguí múltiples ofertas como ingeniero de software a tiempo completo
Aprendizajes de mi experiencia de entrevista
Antecedentes
No me gradué de una escuela de la liga Ivy. Fui a un colegio comunitario en Idaho durante dos años y luego terminé mi licenciatura en ciencias en una pequeña universidad católica.
Comencé a aprender ciencias de la computación en mi tercer año de universidad, porque en ese momento me pareció divertido. Lo único que se parecía a una computadora que tenía mientras crecía era un imitador chino de Nintendo SNES. Incluso entonces, se rompería cada vez que le pusiera una cinta.
Para mantenerme en la universidad, tomé varios trabajos a tiempo parcial como limpiar pisos y hacer concesiones de pie.
Cuando me gradué, no tenía un trabajo en fila. Solicité el mayor número de empresas tecnológicas que pude y tuve la suerte de conseguir algunas entrevistas telefónicas.
En este punto, no tenía ni una sola idea de cómo sería una pantalla técnica, y mucho menos cómo prepararme para ella. Me dirigí a estas entrevistas pensando que el entrevistador me preguntaría qué era una lista vinculada o un árbol binario.
No pasé ninguna de esas entrevistas.
Avanzando
No profundicé demasiado en si era bueno. Sabía que podía aprender las cosas rápido. Solo necesitaba una oportunidad.
Como dice el refrán, lanza tu red a lo largo y ancho. Entonces eso fue lo que hice.
Lo que hice después es algo de lo que estoy particularmente orgulloso. Escribí una secuencia de comandos simple de Python que recortaba las listas de trabajos en Craigslist con títulos que contenían una lista de palabras clave, y recopilaba los correos electrónicos en una hoja de cálculo.
No era la solución más inteligente, pero las personas que publican en Craigslist son sorprendentemente precisas con sus títulos.
A Craigslist, sin embargo, no le gustaba que la gente raspara su sitio web. Para evitar esto, ejecuté mi script a través de una VPN y tuve un temporizador que pausaría el script cada pocos minutos más o menos. No fue perfecto, pero funcionó lo suficientemente bien.
Al final, recogí unos 500 correos electrónicos de todo San Francisco, Portland, Spokane y Seattle. Filtré los resultados por cuán específicos y recientes eran, y seguí mejorando al agregar más y más funciones.
Al final resultó que, ya había algunos robots en el mercado que rastreaban Craigslist y enviaban correos electrónicos automáticos. En su mayoría, eran compañías offshore que buscaban lanzar su compañía al mercado estadounidense.
Una de mis soluciones fue que elaboré correos electrónicos que usaban palabras clave de sus listados en el título de mis correos electrónicos. Luego agregué más detalles utilizando el cuerpo de las publicaciones para que parezca más agradable. Hice una prueba rápida A / B, y las respuestas que recibí habían aumentado bastante de alrededor del 2-3% al 10%.
De los aproximadamente 500 correos electrónicos, recibí alrededor de 50 respuestas y obtuve pantallas de teléfono con un pequeño porcentaje de ellas. Paré a las 500 porque tenía poco tiempo y necesitaba finalizar un trabajo lo antes posible. Estaba optimizando los resultados en lugar de llegar a ese punto.
Por suerte, finalmente conseguí un trabajo en una startup en Seattle como ingeniero de software junior. La startup estaba ubicada en Kirkland en ese momento, así que tuve que tomar un viaje en autobús de 45 minutos para llegar a tiempo a la entrevista.
Luego me quedé allí durante los siguientes 3.5 años, donde aprendí muchas cosas como Amazon AWS, EC2, DynamoDB, SQS y Docker. Crecí mucho durante este período. Aprendí a escribir código modular y mantenible. Aprendí a razonar sobre el diseño de software. Y aprendí a manejar los problemas de las personas.
Estaba trabajando junto a un grupo de personas inteligentes que tenían trabajos en Microsoft, Amazon y LinkedIn, y traté de ser la “esponja” del grupo. Absorbí cualquier cosa y todo lo que me arrojaron. Creo que esto tuvo un gran impacto en mi carrera.
Días de inicio
Durante mi etapa en el inicio, trabajé casi exclusivamente en el desarrollo de backend, con algunas operaciones intermedias en el medio. Comencé escribiendo algunas funciones para agregar / modificar una característica que en su mayoría tenía un alcance pequeño. Pero fue una gran oportunidad para comprender la base de código y obtener algunas revisiones de código.
Un año después, comencé a poseer partes de la base de código y luego me encargaron convertir un conjunto de características en un servicio. Ese fue el comienzo de la fase SOA para el inicio. Comenzamos a convertir varios componentes del sitio en servicios, y así es como comencé a aprender más sobre los servicios RESTful, autenticación, servicios AWS, pub-sub, sistemas distribuidos, etc.
La parte interesante aquí es que no aprendí nada de esto a través de libros o educación formal. Más bien, necesitaba hacer ese conjunto de características y estaban los cuellos de botella.
Entonces pensé, ¡vamos a resolverlo!
Hubo muchas ocasiones en las que me quedé atrapado en la parálisis del análisis, un estado en el que analicé en exceso los escenarios y terminé sin poder avanzar.
Esos tiempos difíciles fueron las mejores oportunidades de aprendizaje. Empecé a aprender el alcance de las características, las negociaciones, el monitoreo, las alertas y la documentación. Cada paso del proceso reveló más cosas que necesitaba aprender. Crecí más durante estos últimos 2–3 años, tanto como ingeniero individual como de software.
Cómo me preparé para mis entrevistas
Después de sufrir mi primera búsqueda de empleo, me dije que debía estar preparado en futuras entrevistas.
Comencé a prepararme para entrevistas trazando una visión general de lo que era bueno, malo y dónde podía mejorar. Lo dividí en tres categorías: estructuras de datos, algoritmos y diseño del sistema.
Después de haber trabajado en PHP durante la mayor parte de mi carrera profesional y C ++ en la universidad, quería probar algo un poco más simple y menos detallado para las entrevistas.
Por esta razón, elegí Python. Es un excelente idioma para aprender, fácil de aprender, admite muchas estructuras de datos listas para usar y se puede escribir rápidamente en la pizarra. Aprendí Python revisando tutoriales de Youtube como estos, y también leyendo su documentación. Prefiero Python 2.x, pero puedes elegir 2.xo 3.
Además, otra razón por la que elegí Python es que es muy fácil de leer y fácil de escribir en una pizarra. Aquí hay una comparación trivial entre C ++ y Python.
Un programa C ++ para ordenar en orden descendente:
#include
usando el espacio de nombres estándar;
int main ()
{
int arr [] = {1,10,0,4,5}
int n = size (arr) / sizeof (arr [0]);
sort (arr, arr + n, mayor ());
para (int i = 0; i
cout << arr [i] << "";
}
devuelve 0;
}
Compare eso con la versión de Python:
a = [1,2,4,5,1000]
a.sort (reverse = True)
imprimir un
He recibido comentarios de los entrevistadores para errar por el lado de la brevedad en una entrevista. En una entrevista de 45 minutos, desea utilizar la mayor parte de su tiempo para resolver el problema real.
Consejo profesional: elija un idioma que sea menos detallado para que pueda escribir el código más rápidamente en la pizarra
Modo de preparación
Pasé aproximadamente una semana pasando por desafíos simples en LeetCode, HackerRank y Project Euler para familiarizarme con sus interfaces y acostumbrarme a escribir código en Python.
La primera semana me dio información sobre mi nivel de competencia en ciertos lenguajes de programación. Pasé otra semana pasando por algunos desafíos de diseño como “diseño X” y fui lo más amplio y profundo que pude.
Esto fue muy divertido para mí, porque a menudo miraba las aplicaciones de iOS y trataba de descubrir cómo lo hacían. Por ejemplo, ¿cómo construirías Instagram desde cero? (Me preguntaron esto en Facebook).
Mi experiencia es en diseños de API y arquitectura orientada a servicios. Entonces aproveché esta oportunidad para mostrar cómo diseñaría mi propia versión de Instagram. Y debido a que tengo algo de experiencia en programación iOS de mis proyectos paralelos, podría hablar un poco sobre las devoluciones de llamada y las encuestas push / largas aquí.
Comencé la conversación con algunas características que me gustaría tener en mi propia versión de Instagram: me gusta, subir una foto y una línea de tiempo simple. El alcance de características me permitió construir una API muy sólida porque conozco bien estos escenarios.
Luego dibujé algunas imágenes de un diseño de alto nivel, de cómo el cliente interactuaría con el backend y de cómo el backend almacenaría los datos.
Comencé pequeño, y luego agregué más componentes donde era necesario y busqué proactivamente dónde estaban los cuellos de botella. Hice conjeturas educadas (leer conjeturas educadas, no ciegas) sobre cuáles serían los requisitos y cómo cada tecnología encajaría bien. Y también igualmente importante, qué tecnologías no encajarían bien.
Por ejemplo, ¿por qué usaría Cassandra sobre MySQL para almacenar cierta información (sugerencia: escala, velocidad de desarrollo, revisiones de esquemas), por qué usar OAuth sobre autenticación simple, Redis vs Memcached para almacenar datos en caché, transmisión por secuencias o procesamiento por lotes, etc.
Aquí puede explorar muchas áreas, por lo que, por lo general, una sesión de una hora no es suficiente. Para responder bien a estas preguntas, debe leer y aprender sobre las compensaciones. Pros y contras de las tecnologías en la industria. Para esto, recomiendo un sitio como HighScalability.
Tómelo como una típica sesión de lluvia de ideas con un compañero de trabajo, así que explore de la manera más amplia y profunda que pueda.
Es crucial saber que estas entrevistas de diseño están destinadas a explorar cuánto sabe y qué tan bien lo sabe, y es una oportunidad para que brille. Vi este video de Youtube de un ex ingeniero de Facebook sobre cómo resolver problemas de diseño, y me dio ideas que me ayudaron enormemente con mis entrevistas de diseño. Mis dos aprendizajes principales son: conducir la conversación de diseño y mostrar lo que sabes.
Enumeré mi nivel de competencia para: estructuras de datos (lista vinculada, mapa hash, árbol binario, árbol de búsqueda binaria, montón, matriz), algoritmos (búsqueda binaria, hashing, programación dinámica, clasificación), y sintaxis y bibliotecas específicas del idioma ( como ordenar, lambda para Python, agregar, indexar).
Escogí el área en la que estaba peor y comencé a trabajar en ella: algoritmos.
Los algoritmos nunca han sido mi fuerte. Ha pasado un tiempo desde mis días en la universidad, y no pasé mucho tiempo haciendo búsquedas binarias en mi carrera diaria. Tenía una idea de cómo funcionaría cada algoritmo y en qué escenarios usarlos. Pero no estaba 100% cómodo con escribir una búsqueda binaria en menos de 10 minutos. En una pizarra Delante de un entrevistador.
También recogí un montón de marcadores de punta fina de Amazon, que funcionan increíblemente bien. Tal vez solo soy yo, pero los marcadores de punta fina en las salas de entrevistas generalmente no funcionan en absoluto. Por lo general, me apresuro durante 2 a 3 minutos en busca de un bolígrafo que funcione, y eso es 2 a 3 minutos que no puede desperdiciar. Además, los marcadores de punta fina le permiten escribir de 5 a 8 líneas de código en una pizarra blanca típica frente a las más gruesas. 🙂
Consejo profesional: obtenga su propio conjunto de marcadores de punta fina
Obtuve una pizarra de Costco por $ 50, algunos libros de Amazon (que figuran en la sección de herramientas que recomiendo a continuación), y comencé mi práctica de codificación. Me aseguré de aumentar la búsqueda binaria, la recursión, la programación dinámica, BFS y DFS. Muchas preguntas de entrevista giraron en torno a la recursividad y la búsqueda binaria o algunas variaciones de la misma.
Las mejores preguntas de entrevista que he visto tienen muchas soluciones diferentes para ellas, y hay una capa adicional agregada en la parte superior a medida que avanza.
Una pregunta de Google que tenía estaba relacionada con los directorios del sistema de archivos y cómo recorrerlos (pista: recursión). Lo resolví relativamente rápido, y el entrevistador preguntó cómo identificar un archivo perdido en ese directorio. Eso fue un poco más difícil, pero lo superé. Y luego pasamos a cómo reconstruir el directorio, cómo serializarlo / deserializarlo, y pasamos una buena cantidad de tiempo debatiendo cómo funcionan los directorios de archivos debajo del capó. Fue una sesión muy agradable para mí.
Entrevistas en empresas de primer nivel.
Fue una experiencia desgarradora, por decir lo menos. Y qué paseo en montaña rusa.
Asigné mi tiempo de la siguiente manera: 20% de currículum, 20% de investigación y 60% de preparación de entrevistas.
Pasé el 20% de mi tiempo arreglando mi currículum, que no había sido actualizado en al menos tres años. Eché un vistazo a las cosas que he hecho en el pasado y elegí proyectos que manejé de extremo a extremo, independientemente de la complejidad.
La razón para hacer esto es doble. Llevar un proyecto de principio a fin exige disciplina y liderazgo, dos de los rasgos con los que me gustaría identificarme.
En segundo lugar, la propiedad de un proyecto de principio a fin significa que puedo hablar sobre cada aspecto del proyecto en profundidad y en profundidad. Esto resultó crítico para ayudarme a navegar mi ronda de diseño en Twitter, donde me interrogaron no solo sobre los diseños de mis proyectos, sino también las decisiones detrás de ellos.
El 20% de mi tiempo lo usé para investigación. La investigación en este caso significó hacer la debida diligencia en las compañías que me interesaban y buscar referencias. Tener referencias ayuda con las llamadas de regreso.
Desde mi experiencia, envié más o menos 20 mensajes fríos a nuevas empresas y empresas de etapa intermedia, y solo escuché un puñado. Pero, casi todas las empresas a las que me refirió un empleado existente me enviaron un mensaje dentro de una semana. Esto es anecdótico, pero hay valor allí.
No soy tan sociable, y no conocía a muchas personas que pudieran referirme a una empresa que me interesara. Para resolver ese problema, ingresé a LinkedIn. Tienen una funcionalidad de búsqueda que solía buscar para conexiones de primer y segundo nivel. Las conexiones de segundo nivel son personas que están a un salto de tu círculo inmediato. En otras palabras, tenemos amigos en común que pueden dar fe de mi credibilidad.
Búsqueda de LinkedIn
Esto es increíblemente importante, porque llamar en frío a alguien para un trabajo es muy, muy difícil, especialmente en el mercado actual. Las personas tienden a equivocarse con precaución cuando se trata de personas que llaman en frío. Usar LinkedIn fue muy útil para mi fase de investigación.
Mirando hacia atrás en todas las compañías que entrevisté, aquí están mis pensamientos sobre cada una de ellas:
Facebook / Google: muy mecánico. El proceso de entrevista estándar, y no sentí ninguna conexión personal con ellos.
Pinterest: no es la mejor experiencia de entrevista, sino un producto y una compañía geniales.
Microsoft: amaba al equipo y especialmente al gerente y su gerente. Preguntas de entrevista estándar, pero muy agradables. Cerrar-segunda opción. Sin embargo, su millaje puede variar: cada equipo de Microsoft entrevista de manera diferente.
Amazon: proceso de entrevista estándar. Alrededor del 50% de las personas lo aman, los demás no.
Twitter: increíblemente divertido y personal. Me encantó el proceso de entrevistas, le di mucho énfasis al individuo y lo que había hecho en el pasado.
Snapchat: una oficina genial en Los Ángeles, un gran grupo de personas que decidieron subirse al carro de las startups. Sentía que las cosas estaban envueltas bajo una nube de secreto.
Lyft: cerca de donde vivo, bonita oficina, proceso de entrevista estándar. No hay sentimientos fuertes al respecto.
Hablemos de mi favorito
En muchos sentidos, diría que el estilo de entrevista de Twitter fue difícil. Pero al mismo tiempo, fue más interesante y agradable que otras compañías en las que he entrevistado.
Su proceso de entrevista comienza con una llamada telefónica introductoria con un gerente de ingeniería. Eso es seguido por una o dos pantallas técnicas de teléfono, dependiendo de cómo se desempeñe. Si lo haces bien, te llevarán a la oficina para la que estás entrevistando, que era Seattle en mi caso. Hay tres rondas de 1 hora y 15 minutos, cada una con dos entrevistadores.
Las dos primeras pantallas técnicas del teléfono son las pantallas técnicas estándar y corrientes donde resuelve problemas de codificación en un documento de codificación compartido.
Sin embargo, las rondas en el lugar son mucho más conversacionales y se sienten mucho menos intimidantes. Los entrevistadores le harán preguntas en profundidad sobre sus proyectos pasados, y le informarán sobre lo que ha hecho en el pasado. Si reclama la propiedad de un proyecto, debe esperar algunas preguntas al respecto. Te animamos a usarlos para referencias y para intercambiar ideas.
Nunca sentí ninguna presión para llegar mágicamente a una solución totalmente funcional, y me sentí muy colaborativo.
Los demás
En comparación, las entrevistas en Facebook y Google se sintieron mucho más mecánicas. Tienen una o dos pantallas técnicas de teléfono y de cinco a seis rondas de codificación in situ. Cada ronda implica un poco de codificación en una pizarra, y se espera que encuentre una solución casi perfecta en un tiempo razonable.
Facebook tiene dos rondas de codificación, una ronda de diseño y una ronda de comportamiento.
Pasé por una ronda de sombras adicional al final del día, que no contaba para mi puntaje general.
Google tuvo cinco rondas de codificación, ninguna de las cuales se centró en los diseños, y ningún entrevistador me preguntó sobre mis proyectos anteriores. No creo necesariamente que esto sea malo. Pero creo que se sintió muy mecánico y no le dio muchas oportunidades al ingeniero para demostrar de lo que son capaces. A algunas personas les va bien en estos escenarios, al igual que a algunos estudiantes les va bien en los exámenes.
No disfruté mi entrevista con Pinterest. Creo que el producto en sí es interesante, y su equipo de ingeniería parece estar trabajando en problemas técnicos muy interesantes. Pero definitivamente tuve una experiencia negativa durante mi entrevista allí.
Pinterest tiene tres rondas de codificación y una ronda de diseño. De esas cuatro rondas, la ronda de diseño fue muy decepcionante para mí. Este es el por qué:
El entrevistador llegó tarde, y pasó unos minutos mirando mi currículum antes de proceder a dibujar algunas API en la pizarra. Dio una breve descripción de lo que esperaba que hiciera la API, y me preguntó cómo lo resolvería. Aclaramos las características de la API y comencé a describir mi solución usando la pizarra. ¡Aproximadamente 5 minutos después, me di la vuelta y lo vi tomar una siesta!
No es genial
Le di mi opinión al reclutador en una encuesta, y no tuve noticias de ellos después de eso.
No profundizaré en detalles de las preguntas que me hicieron durante todas las entrevistas. En cambio, compartiré algunas de las ideas y consejos útiles que aprendí de mi proceso de preparación.
Que aprendí:
Sé honesto en tu currículum. La mayoría de las compañías le harán preguntas sobre su currículum y pueden decirle si lo inventó. Es mejor saber 100% sobre un proyecto que conocer 10% sobre 10 proyectos diferentes.
Se recomiendan hojas de vida de una página. Esto es especialmente cierto para las empresas de tecnología, y parece que la sabiduría dentro de la esfera de la tecnología es que debe reservar dos páginas y más para el trabajo posdoctoral, o si ha realizado muchos proyectos que conoce y se preocupan profundamente . Un amigo mío dirige una compañía llamada Jobscan que escanea currículums y realiza mejoras específicas y procesables en ellos. Son bastante impresionantes, así que pruébalos 🙂
Socializar y establecer una red. Hay mucha competencia para los trabajos de ingeniería de software, y estas empresas tecnológicas de primer nivel están filtrando miles de currículums por día. Tener una referencia lo ayudará a echar un vistazo a su currículum.
Clava tu tono. Cada compañía que está interesada en ti quiere saber por qué estás interesado en ellas. Una mala respuesta: solo necesito un trabajo ahora mismo para pagar las facturas. Una respuesta menos mala: estaba navegando en línea y los encontré. Parece que estás trabajando en cosas interesantes. Una buena respuesta: Sé que estás haciendo un trabajo interesante en X para lograr Y. He hecho algo de trabajo en el pasado y esto es lo que aprendí sobre A, B, C que podría estar relacionado con X. Me apasiona Y porque bla. (No use esto como plantilla. En su lugar, debería ver el patrón aquí: investigue, use sus antecedentes y muestre a la compañía por qué ambos encajarían bien juntos)
Algunos consejos más
Las entrevistas técnicas son increíblemente difíciles, y a veces es impredecible. Sin embargo, las mejores oportunidades están reservadas para aquellos que están preparados.
Prepárese temprano, prepárese bien. Todos saben que deberían prepararse para una entrevista, pero la mayoría no sabe cómo hacerlo bien. Al igual que con cualquier cosa que valga la pena hacer, se necesita práctica deliberada para hacerlo bien en algo. Y la práctica deliberada significa que necesitas tener un sistema.
Construye un sistema para practicar habilidades técnicas. Comencé calificándome a mí mismo del 1 al 10 en cuanto a lo bueno que era, y trabajé en aquellos en los que era peor. Pasé días en diferentes tipos de preguntas hasta dominar completamente cada concepto. Y escribí notas diariamente en Evernote. Tenía una nota que sirve como un tugurio para todo lo relacionado con la programación. Está lleno de consejos y trucos de programación, errores comunes y conceptos erróneos, marcos para resolver tipos específicos de preguntas y mucho más.
Mantenga un cuaderno de cosas que haya aprendido. Utilizo Evernote y OneNote para hacer un seguimiento de las cosas. OneNote para material / código técnico, porque me gusta, puedo formatear fácilmente la nota de la forma que quiera. Yo uso Evernote para ensayos / pensamientos. La imagen de arriba muestra una nota que guardo sobre arquitectura y diseños de sistemas.
Evernote para pensamientos / consejos
Anote todo, incluso si no cree que lo usará. Tiendo a olvidarlo muy fácilmente, así que todo lo que aprendo lo escribo, incluidos los comandos de shell. De vez en cuando leo blogs técnicos, y si encuentro algo interesante, lo apunto en Evernote de inmediato. Lo revisaré cada semana o mes y lo reorganizaré en consecuencia. Esto me ha ayudado enormemente en mi carrera.
Obtenga entrevistas simuladas. Esto definitivamente fue muy valioso y lo recomiendo encarecidamente. Tuve entrevistas simuladas con amigos e intenté practicar todo lo que pude. Si no puede encontrar amigos para practicar, le recomiendo Refdash, que es una entrevista como servicio. Tienen un grupo de entrevistadores que trabajan en grandes empresas tecnológicas como Google, Facebook y Microsoft. Estos entrevistadores lo evaluarán en sus habilidades de codificación y diseño. La mejor parte es que te darán una puntuación al final con elementos accionables específicos sobre cómo mejorar.
Está bien fallar. Fallé varias entrevistas durante todo este proceso. A veces solo tienes un mal día. No es el fin del mundo si fallas. Las empresas están predispuestas a decir no porque es un riesgo menor para ellas. Un falso positivo cuesta más que un falso negativo a largo plazo. Los primeros rechazos definitivamente dolieron más. Fallé varias pantallas de teléfono cuando comencé a entrevistar por primera vez, y mi nivel de confianza se hundió. Tenía dudas sobre mis habilidades y comencé a temer que mis habilidades no fueran relevantes en el mercado laboral actual. Sin embargo, me di un consejo: si fallas 10 veces, intenta 10 veces más. Todo lo que necesitas es un éxito. Esa tranquilidad me dio mucha confianza para seguir adelante y cuando llegó mi primera oferta, las otras ofertas llegaron mucho más fácilmente.
Me llevó unos 2 meses de práctica deliberada y preparación para mis entrevistas. Pasé unas 20 horas / semana, u 80 horas / mes, aprendiendo y escribiendo notas además de un trabajo a tiempo completo.
Para construir mi currículum, me tomó 3.5 años de trabajo enfocado y deliberado. Escogí intencionalmente cosas que eran difíciles y desagradables para poder aprender más que nadie. Aunque no tengo una universidad de marca o una empresa de tecnología de primer nivel en mi currículum, lo compensé con una comprensión clara y exhaustiva de los proyectos en los que trabajé. Y esto fue posible porque investigué y escribí notas de todo lo que aprendí, y tengo un sistema para revisarlas.
Recuerde: el fuerte sobrevive, el duro prospera.
TL; DR: no te rindas, prepárate para las oportunidades, practica mucho y mantente esperanzado. Concéntrese en el proceso y adopte un enfoque disciplinado y dedicado al proceso.
Herramientas que recomiendo
Elementos de las entrevistas de programación: ideal para problemas de codificación más difíciles
Codificación de la entrevista de craqueo: ideal para cubrir CS fundacional
OneNote: lo uso para almacenar todos los fragmentos de código
Evernote: para todo lo demás
CodeRunner: ¡Me encanta esta aplicación para Mac! Lo usé varias veces para ejecutar scripts / funciones de Python ad-hoc y simplemente funciona increíblemente bien.
Jobscan: Un amigo dirige esta empresa. He escuchado muchas cosas interesantes al respecto, y deberías probarlas para su herramienta de detección de currículums.
Refdash: Dirigido por un grupo de ex-Googlers. La calidad de las entrevistas simuladas aquí es. Mi entrevistador había trabajado en Google, y fue muy útil al señalar en qué debería centrarme y cómo me calificarían en Google. Recomiendo probarlos.
CodePath: una organización sin fines de lucro que ayuda a las personas a prepararse para una carrera en tecnología. Nathan y Tim son grandes personas y he aprendido mucho de ellos. La comunidad es muy útil y todos están dispuestos a echar una mano.
Marcadores de punta fina: funcionan tan bien que los recomiendo.
Entre los dos libros, prefiero CTCI para cubrir mis conceptos básicos, como cómo funciona una lista vinculada, cómo funciona un mapa hash y cómo resolver algunos problemas básicos con ellos.
EPI es ideal para abordar problemas de codificación más difíciles. La forma en que los usaría es que pasaría 2-3 semanas revisando el libro capítulo por capítulo, sintiéndome cómodo con las bibliotecas de un idioma específico.
El resto del tiempo dedicaría mi tiempo 100% a EPI porque comenzaría a hacer problemas más interesantes / difíciles allí, y tener una comprensión completa de la estructura de datos básicos de CTCI me ayudó a resolverlos mucho más fácilmente.
¡Gracias por leer mi historia! Puedes encontrarme en Twitter y LinkedIn. Me encantaría conectarme y hablar más sobre tecnología, nuevas empresas, viajes 😀
Créditos
Brandon O’brien, mi mentor y buen amigo, por corregir la lectura y proporcionar comentarios valiosos sobre cómo mejorar este artículo.
YK Sugishita, una prometedora estrella de Youtube que dejó su trabajo en Google para perseguir sus sueños, para corregir y dar comentarios críticos.
Una cosa más:
¡Como una forma de retribuir, haré entrevistas simuladas y revisaré currículums! Elegiré al azar a 10 personas que se registren aquí. También puedo referirte a Twitter, que es donde trabajo. ¡Me encanta y estamos contratando! 🙂
Copiado del medio
