Experiencia de entrevista de CodeNation (SDE a tiempo completo, fuera del campus)

Me conecté con las personas que contrataban en CodeNation a través de una empresa externa llamada CareerSocially que me buscó a través de mi perfil de LinkedIn. Después de una breve discusión sobre el puesto de trabajo y una descripción general del proceso de la entrevista, me hicieron pasar al proceso.

Ronda 1 (Teléfono, Evaluación de currículum):  Esta ronda duró aproximadamente 30-35 minutos y se basó únicamente en mi currículum. Inicialmente me pidieron que me describiera y luego tuvimos una discusión de aproximadamente 10 minutos sobre mi currículum en la que el entrevistador saltó sobre varios temas para asegurarse de que sabía lo que había escrito. Luego me pidió que eligiera 3 de mis mejores proyectos y luego me pidió que justificara su elección. Después de eso, tuve que volver a elegir uno de ellos y tuvimos una breve discusión sobre mi enfoque para construirlo y cómo podría haberlo hecho mejor. La entrevista terminó ahí.

Ronda 2 (videoconferencia, estructuras de datos y algoritmo):  esta ronda duró aproximadamente una hora. Las preguntas que me hicieron fueron:

  • Suponga que le han dado un gráfico no dirigido sin bordes paralelos. Cada vértice representa una ciudad y los bordes son caminos para viajar a otra ciudad con diferentes tiempos de viaje (dados). Si ahora el vértice fuente 0 está infectado con Coronavirus, ¿cuál es el tiempo mínimo en el que se infectará todo el gráfico?
    Respuesta:  Inicialmente sugerí un enfoque de programación dinámica en el que para cada  Node n , usaría un BFS o DFS para averiguar primero todos los predecesores (que tienen un enlace directo a él) y el tiempo mínimo para infectar n ser min(xi + ti) (para todos esos Nodes x y tiempo de borde t). No podemos tener un Node que no sea un predecesor y, sin embargo, conducirá a un camino más corto (desigualdad triangular). Pareció satisfecho con la lógica y me pidió que lo codificara  sin errores . Aquí tuve problemas con la relación de recurrencia y como me estaba quedando sin tiempo, le pregunté si podía cambiar mi implementación. Aceptó eso y codifiqué una solución donde ejecuté  Djikstra  desde la fuente a cada Node S para encontrar el tiempo más corto y luego hice un BFS para encontrar el máximo entre ellos, cuál sería la solución.
  • Luego me preguntaron cómo modificaría mi solución para encontrar el tiempo más largo que tardaría en propagarse el virus si tuviera la libertad de eliminar  exactamente un borde . Mi respuesta fue que eliminaría cada borde uno por uno y ejecutaría el algoritmo anterior. Luego me preguntó si las propiedades de MST  con respecto a la eliminación de bordes podrían aplicarse a este problema o no, y tuvimos una discusión sobre algunas de ellas (también codifiqué Kruskal para demostrar mi conocimiento), pero mi respuesta fue que no será aplicable. en este contexto. Su siguiente pregunta fue sobre qué optimizaciones se podrían hacer para acelerar el algoritmo. Sugerí buscar puntos de articulación (que establecerían inmediatamente la respuesta en Infinity), implementar Djikstra a través de Fibonacci Heap, etc.
  • Terminamos discutiendo la complejidad del tiempo de algunos algoritmos estándar, la estructura de datos favorita y su uso (elegí Trie , lo que llevó a discusiones sobre su eficiencia frente a HashMap, Linked Tries, etc.) ,   mis puntos fuertes durante la entrevista, etc.

Ronda 3 (Videoconferencia, Diseño de sistemas): Fue de una hora y 40 minutos. Me dieron dos problemas a resolver, los cuales son:

  • Tenemos concursos de cubos de Rubik en este mundo donde los cubos son barajados al azar por voluntarios antes de dárselos a los concursantes que los resuelven simultáneamente. Ahora, la empresa que organiza tales competencias usa una computadora para generar la secuencia aleatoria y los voluntarios son elegidos entre la multitud. Ahora, hay dos problemas con este enfoque: a), un voluntario puede estropear una secuencia para dañar deliberadamente la oportunidad de un competidor o b) Un voluntario comete un error honesto. Puede que no sea obvio a primera vista que uno de los cubos tiene una disposición ligeramente alterada. Imagine que es un innovador al que se le asigna la tarea de diseñar un sistema que, si se le presenta el cubo, puede dar una  respuesta Sí/No sobre si está en la secuencia correcta. No queremos que el sistema consuma mucho tiempo o sea costoso.
    Responder: Inicialmente sugerí un algoritmo ML basado en Computer Vision que fue rechazado porque no tenía una idea clara de cómo funcionaban esos algoritmos. Mi siguiente enfoque fue sugerir una solución basada en IOT que se basara en el uso de sensores en el cubo de Rubik para detectar los giros realizados y hacer coincidir la secuencia; esto fue rechazado porque no podíamos modificar los cubos estándar de la industria. Sugerí un protocolo que usaba la coincidencia de voz del Asistente de Google que solo introducía nuevos puntos de falla. Finalmente, se sugirió que usaremos una caja fija con cámaras adheridas a sus caras internas; los voluntarios dejarán caer el cubo allí y se tomarán las imágenes de todas las caras que simplemente se compararán píxel por píxel (no ML, y pude describir esto), lo que debería funcionar ya que los valores RGB en el cubo son bastante distintos. La caja será lo suficientemente compacta como para que no haya problemas con la orientación que puedan perturbar la imagen. Estuvo de acuerdo con esto y luego me pidió que lo criticara yo mismo, lo cual hice.
  • El segundo problema fue crear un Diagrama de clase (modelo UML) para el siguiente problema: suponiendo que tiene un dron cuyo trabajo es plantar semillas, ¿cómo escribirá su módulo de navegación para que pueda realizar su trabajo sin fallar y salir a la calle? cuadro delimitador designado? No me dio más información y tuve que interrogarlo para averiguar sobre las interfaces existentes, las funciones de hardware disponibles para mí (como una para obtener altura, posición, etc.) y luego tuvimos una especie de programación en pareja. discusión mientras ambos tratábamos de diseñar la interfaz más limpia posible. Prestó especial atención a los nombres de mi clase/método, acoplamiento débil, separación de preocupaciones, etc.

Ronda 4 (videoconferencia, ronda de CEO/HR):  esta fue la ronda más corta de solo 15 a 20 minutos. Primero explicó la estructura general de CodeNation y luego me hicieron preguntas generales sobre mí mismo, mis expectativas de CodeNation, cómo podía ayudarlos, una discusión sobre una vez que usé la programación para resolver una tarea de la vida real (di ejemplos de algunas tareas de automatización). guiones que había escrito). Después de esto, me preguntó si tenía alguna pregunta para él y ahí terminó la entrevista.

Recibí una llamada diciendo que fui seleccionado para el puesto de SDE al día siguiente y listo, ¡mi carta de oferta me estaba esperando! 🙂

Publicación traducida automáticamente

Artículo escrito por Uni_Omni y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

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