¿Cómo me preparo para una entrevista de trabajo de ingeniería de software?

Prerrequisitos [1]

Veamos las cosas básicas que debe saber si está entrevistando para un puesto de ingeniería de software:

  • Programación en un idioma de su elección: debe tener un fuerte dominio de al menos un lenguaje de programación. Debería poder comprender rápidamente códigos razonablemente complejos y ejecutarlos mentalmente en seco. Debería poder codificar un escenario complejo en dicho idioma.
  • Resolución de problemas / Algoritmos: los algoritmos en sí mismos son un campo enorme. Se espera que conozca los algoritmos básicos. Tendrá una gran ventaja si conoce los enfoques básicos de resolución de problemas.

    Los 2 temas anteriores constituyen el 50-75% de un proceso de entrevista de ingeniería de software.

  • Diseño del sistema: esto es extremadamente importante si usted es un ingeniero de software experimentado. Necesitas ser bueno en:
    • Comprender los requisitos de un sistema
    • Diseño de sistemas escalables y tolerantes a fallas (escala horizontal versus vertical)
  • Conceptos básicos de lo siguiente [2]:
    • Sistemas operativos: subprocesos y procesos, primitivas de sincronización de subprocesos (semáforos y mutex), gestión de memoria (paginación, intercambio)
    • Bases de datos: consulta de un DBMS relacional, indexación, restricciones de clave primaria y externa, normalización, almacenamiento interno
    • Redes: capas de red, TCP y UDP, estructura de paquetes TCP, enrutamiento de paquetes, subredes
    • Web: cookies, gestión de sesiones, almacenamiento en caché, Http / Https

Donde aprenderlos

  • Programación en un lenguaje de su elección: supondré que conoce los conceptos básicos de la programación en al menos un idioma. Luego se reduce a mucha práctica.
  • Resolución de problemas / Algoritmos: Personalmente, creo que mycodeschool hace un buen trabajo al enseñar los conceptos básicos de los algoritmos requeridos.
    InterviewBit tiene tutoriales en video sobre temas sabios aumentados con problemas relacionados con entrevistas históricas para practicar.
    Leetcode tiene una gran selección de problemas para desarrollar habilidades de resolución de problemas.
    Si se siente un poco más aventurero, puede consultar http://www.spoj.com y Problemset – Codeforces. Sin embargo, la mayoría de estos problemas pueden ser demasiado difíciles de calificar para una pregunta de entrevista técnica.
  • Diseño del sistema: Creo que http://www.hiredintech.com/syste… es un gran punto para comenzar. http://book.mixu.net/distsys/ebo… hace una lectura interesante.

Ejecución final

Ahora que ha terminado con la preparación, seguir algunos consejos finales podría ayudarlo a que le vaya bien en una entrevista real:

  • Evitar malentendidos: muchos candidatos obtienen malos resultados en una entrevista de programación porque comienzan a resolver un problema diferente al previsto. Asegúrese de pasar de 2 a 5 minutos preguntándole al entrevistador sobre casos esquimales sobre el problema. Esto garantizará que haya entendido el problema correctamente y que comprenda los casos esquimales que debe resolver en su solución.
  • Estructura del código: esto no solo es aplicable a las entrevistas. Dedicar algo de tiempo a pensar cómo estructuraría el código puede ahorrarle tiempo de codificación y depuración.
  • Comuníquese: debe poder comunicar sus pensamientos al entrevistador. El proceso de entrevista (especialmente la ronda de diseño del sistema) se basa principalmente en ideas y les explica su proceso de pensamiento.
  • Ajuste de la empresa: asegúrese de investigar sobre la empresa antes de solicitar un trabajo allí. La mayoría de las compañías querrían contratar candidatos que se sientan apasionados por el trabajo que está haciendo la compañía.
    Evite hacer preguntas que pueda encontrar fácilmente en Google. Piense en las adiciones emocionantes que podría hacer al producto / servicio de la compañía si tuviera su camino en la compañía.

El proceso mencionado anteriormente puede llevar mucho tiempo. Sin embargo, aumentaría sus posibilidades de múltiples veces si se sigue correctamente.
¡Todo lo mejor!

[1] Los datos anteriores se han compilado en base a las experiencias de entrevistas de candidatos referidos a través de https://www.interviewbit.com/ a empresas de nivel 1.
[2] Aún podrías hacerlo bien en las entrevistas sin saber todo de la lista.

  1. Practique usando el mismo medio (por ejemplo, papel y lápiz) y límites de tiempo (por ejemplo, 30 minutos) como la entrevista real.
    Google y Microsoft usan preguntas de codificación de pizarra, pero a menudo los candidatos practican codificando solos en casa en una computadora con un compilador. Durante la entrevista real, se paran en la pizarra y olvidan cómo inicializar una matriz, sin su resaltador de sintaxis confiable. O están tan nerviosos de que otra persona los vea que entran en pánico y no pueden pensar con claridad.

    En la vida real, si planea nadar en el Canal de la Mancha, ¿limitaría su práctica a las vueltas en la piscina local? No, irías a probar las olas del océano, el agua salada. Haz lo mismo aquí.

    Pregúntele a su reclutador el formato de la entrevista y cualquier pregunta de codificación. Si la empresa les da a los candidatos una hora a solas en una habitación con un editor y sin compilador, practíquelo en casa. Si la empresa hace preguntas en la pizarra con un entrevistador que lo está observando, pídale a un amigo ingeniero que sea su falso entrevistador. Está bien si el amigo es un ingeniero con menos experiencia que tú; de todos modos, sacará a relucir tu nerviosismo por cometer errores frente a los demás, por lo que puedes practicar acostumbrarte a eso.

  2. Durante la entrevista, no te obsesiones con los pequeños errores que suceden.
    En más de una ocasión, cuando le hice una pregunta de codificación a un candidato estrella, se concentró en la solución más óptima, identificó los casos límite y comenzó a escribir código bien diseñado. A la mitad del problema, comete un pequeño error: equivoca el orden de las operaciones en el primer intento, o tiene un error off-by-1, u olvida declarar una variable.

    Cuando lo señalo, el candidato responde con horror y luego se pone tan nervioso que afecta su desempeño durante el resto de la entrevista.
    El miedo es infundado. Un candidato increíble que comete un pequeño error es como un violinista de concierto tocando un desafiante concierto de Brahms y tocando dos notas equivocadas. Claro, el público podría decir que cometió errores, pero no se confunden en cuanto a si realmente está en el nivel Twinkle-Twinkle-Little-Star.

    Incluso si bombardea por completo una pregunta, muchos entrevistadores le hacen varias preguntas y perdonarán un solo contratiempo. Incluso bombardear una entrevista completa es recuperable si las otras entrevistas salen bien.

    Uno de mis antiguos colegas de Google una vez entrevistó a un candidato y fue muy brusco porque encontró irritante el estilo de comunicación del candidato. El candidato demostró su valía durante la entrevista, y el líder tecnológico terminó siendo el mayor defensor de este candidato. Abogó más por ese candidato que por cualquier otra persona en un año.

    Cuando las cosas no van bien, solo sigue adelante y no pierdas la esperanza.

  3. No secuestres la entrevista.
    He tenido un par de candidatos que llegaron a la entrevista con la mentalidad de que DEBEN contarme todo sobre su reciente proyecto Zoolander. Comienzo la entrevista y comienzan a hablar: “Quiero contarles sobre Zoolander. Hace 10 años, este proyecto comenzó como una característica secundaria …” y luego continuaron durante 5 minutos sin respirar.

    A veces deciden que deben contarle a cada entrevistador sobre Zoolander, repitiendo la misma descripción una y otra vez durante el día.
    Su entrevistador tiene preguntas específicas que deben responder. Si secuestra la entrevista, es posible que no tengan suficientes datos de sus propias preguntas para respaldar su contratación. También pueden pensar que sería difícil trabajar con usted.

    Si realmente quiere hablar sobre un proyecto, pregúntele a su entrevistador: “Creo que el proyecto Zoolander realmente muestra mis habilidades. ¿Puede usted u otro entrevistador encajar en 10 minutos para que se lo explique?” Luego, el entrevistador puede reajustar su plan para la entrevista, en lugar de que de repente se modifique su horario.

  4. Al responder preguntas que esperan una respuesta específica, primero dé un resumen de alto nivel.
    A veces hago una pregunta esperando una respuesta corta: “¿Cuántas personas trabajaron con usted en el proyecto Zoolander?” El candidato luego me da un audiolibro, “Bueno, allí estaba Jimmy; él hizo la interfaz de usuario y tuve que guiarlo un poco en eso. Luego estaba Mary, que manejaba los servidores de fondo. Trabajó remotamente desde Pensilvania. Dos años después , tenemos otra persona de back-end David … ”

    Tres minutos después, el candidato todavía está hablando y todavía no sé la respuesta de cuántas personas trabajaron en el proyecto.

    Primero responda y luego explique. “Había 3 cuando me uní y 12 cuando me fui. Primero estaba Jimmy …”

    Mejor aún, dé la respuesta y ofrezca exponer . “Había 3 cuando me uní y 12 cuando me fui. ¿Quieres que te diga lo que hizo cada uno?”

    … Un par de consejos menos importantes y una historia humorística final en la página web de Niniane Wang